将WebLogic服务器和应用程序配置迁移到WebSphere Application Server

本文的目的是帮助您将Java™2平台企业版（J2EE）应用程序从BEA WebLogic Server迁移到IBM WebSphere Application Server平台。

其他developerWorks文章（请参阅参考资料 ）讨论了WebLogic迁移的计划，包括迁移开发环境，生产运行时，应用程序代码等。 本文通过专门关注迁移J2EE应用程序中存在的两种类型的配置来补充这些资源和其他资源：

• 服务器配置是指包含在应用程序文件外部但在源环境的域配置中的设置。 为了迁移服务器配置，将WebLogic特定的资源（例如JMS连接工厂，JMS队列，JMS主题，JDBC数据源，JavaMail会话等）映射到它们的WebSphere Application Server等效项。

• 应用程序配置是指企业归档（EAR）文件的应用程序目录结构中包含的那些设置。 为了迁移应用程序配置，将WebLogic特定的部署描述符映射到它们的WebSphere Application Server等效项。

本文讨论的问题直接适用于将J2EE 1.3（及更高版本）的应用程序从WebLogic Server 7.0和8.1迁移到WebSphere Application ServerV6.x。 此处的大多数信息也适用于WebLogic Server早期版本的迁移应用程序。

迁移服务器配置

迁移服务器配置实质上意味着将WebLogic Server的应用程序文件外部（但在域配置内部）中包含的设置移动到WebSphere Application Server。 这些设置可以包括JMS连接工厂和目标，JDBC数据源，J2EE安全设置，邮件会话等等。

要迁移配置，您必须知道需要迁移哪些设置。 但是，您很有可能没有关于这些设置的任何文档，也没有任何脚本（可能已用于创建服务器配置）供参考。 如果是这种情况，则需要登录每个域中的WebLogic管理控制台以查找设置，以便可以确定需要在WebSphere Application Server环境中创建的设置。

但是，如果您无法（或不允许）访问WebLogic管理控制台怎么办？

无论哪种方式，收集WebLogic服务器配置信息的最有效方法是检查WebLogic域配置文件config.xml和WebLogic启动脚本。 WebLogic管理员通常会为您提供这些文件的副本，因为对其进行检查不会影响任何正在运行的系统。

• WebLogic管理控制台是WebLogic config.xml文件的存储位置，它存储所有资源定义。 无法正确映射这些资源可能会导致应用程序失败。

• 管理员通常会创建一个自定义的启动脚本 ，然后向其中添加系统属性，JVM参数和类。 无法迁移这些设置可能会对新环境中应用程序的性能和可伸缩性产生不利影响。 无论您查看config.xml文件还是管理控制台，都最好检查启动脚本。

收集了这些信息之后，请确保要求开发人员和管理员查看您收集的内容。 这是为了：

• 验证您收集的信息包含最新和准确的设置。
• 标识任何可以删除的无效代码。

另外，请确保您正在查看正确的WebLogic服务器配置； 在开发期间，可以将J2EE应用程序安装在许多不同的运行时环境（开发，测试，QA等）中，每个环境可以具有略有不同的配置设置。 因此，请确保您使用的WebLogic服务器配置是正确的配置。 同样，在每个开发阶段安装应用程序时，请确保为每个相应的环境映射正确的服务器配置。

有了需要迁移的特定运行时配置设置，下一步就是提取它们并将信息插入WebSphere Application Server管理控制台。 尽管这是一个手动过程，但是一旦知道需要创建哪些设置，创建这些设置并不难。 使用WebSphere Application Server管理控制台来设置这些属性使您不必修改XML文件或编写脚本。 如果愿意，还可以提供一些指导性活动来帮助您执行常见任务，例如创建数据源，启用J2EE应用程序安全性等等。 完成后，您可以编写脚本来自动创建服务器配置，特别是针对生产环境。

图1说明了从WebLogic到WebSphere Application Server的服务器迁移。 显示的设置不是唯一的服务器配置设置，但涵盖了您在迁移过程中看到的大部分内容。 您发现的其他设置可能与安全性和邮件会话有关，但是，一般而言，如果您可以处理图中所示的资源，则可以顺利进行服务器迁移。

图1.服务器配置迁移

迁移应用程序配置

迁移应用程序配置实质上意味着将特定于WebLogic的部署描述符中包含的设置移动到WebSphere Application Server。 这些设置包括EJB组件到全局JNDI命名空间的映射，以及与性能相关的各种设置，例如池大小，事务隔离级别，EBJ查询语言的扩展等等。 部署描述符描述了J2EE应用程序所需的执行环境，并且具有两个一般的变体：

本文不讨论Web服务的部署描述符，后续文章将介绍其映射。

• 行业标准部署描述符 （图2）是可移植的，通常不需要进行任何更改，但是WebLogic和WebSphere Application Server之间存在一些值得注意的差异。 例如，IBM的标准部署描述符使用ID将标准描述符中的信息与特定于供应商的描述符中的信息相关联，而WebLogic则使用ejb-names进行相关性。 因此，当您迁移WebLogic部署描述符并创建特定于IBM的描述符时，将需要向它们添加适当的ID。 让您的组装工具（例如IBMRational®Application Developer）为您创建这些ID。 如果尝试自己创建这些ID并弄错了，将很难解决错误。

  图2.行业标准部署描述符

  

• 必须迁移特定于供应商的部署描述符 （图3）。 图3显示了特定于WebLogic的部署描述符和相应的特定于WebSphere的部署描述符。

  图3.特定于供应商的部署描述符

  

  IBM提供了许多工具来帮助您将WebLogic部署描述符迁移到WebSphere Application Server，包括：

  • Xdoclet标签
  • WebSphere Rapid Deployment标签
  • 应用程序服务器工具包（部署描述符编辑器）
  • 用于Rational Application Developer V6的IBM J2EE竞争性迁移器插件。

  请参阅将应用程序从WebLogic，JBoss和Tomcat迁移到WebSphere V6，以了解这些工具的作用，如何以及何时使用它们，在哪里获得帮助等等。 重要的是要了解这些工具，并在适当的时候使用它们。 尽管这些工具将映射特定于供应商的部署描述符中的某些扩展，但它们不会映射所有扩展，因此对于您而言，检查部署描述符并知道如何映射在其中找到的扩展对于您而言仍然很重要。 基于这种理解，使用像Application Server Toolkit这样的组装工具可能会非常有效。

映射config.xml元素

本部分描述如何将这些服务器配置元素从WebLogic映射到WebSphere Application Server：

1. JMSConnectionFactory
2. JMSFileStore
3. JMS服务器
4. 国外JMSServer
5. JDBCConnectionPool和JDBCDataSource

有关每个元素的更多详细信息，请参阅《 WebLogic Server配置参考 》。

1. JMSConnectionFactory

   JMSConnectionFactory元素创建一个连接工厂对象，并将其绑定到JNDI名称空间。 在config.xml文件中为此应用程序配置了三个连接工厂。 每个都启用了XA：

   要将此配置映射到WebSphere Application Server，通常需要在WebSphere默认消息传递提供程序中创建上面显示的JMS连接工厂 。 其他一些预防措施包括：

   • 在WebSphere Application Server中配置这些JMS连接工厂时，请使用正确的JNDIName。 如果JNDI名称不正确，则应用程序将无法找到连接工厂。

   • 通过为指定事务属性“ NotSupported”的非事务性MDB禁用XA来验证消息驱动bean（MDB）是否是事务性的，因为它可能会提高性能。 非事务性MDB不能参与XA事务，并且不需要启用XA的连接工厂。 另一方面，如果MDB将事务属性指定为“必需”，则应为XA的connection-factory-jndi-name启用。

   • 在WebSphere Application Server中创建连接工厂时，默认情况下会启用XA。

2. JMSFileStore

   JMSFileStore元素定义了一个基于磁盘的JMS文件存储，该文件存储在文件系统目录中存储持久消息（用于队列）和持久订户（用于主题）。 此代码片段显示了单个JMS文件存储的定义：

   要将此配置映射到WebSphere Application Server，首先需要知道WebSphere Application Server V6.0缺省消息传递不支持JMS文件存储。 文件存储是6.1版中的增强功能，但是如果使用的是6.0版，则需要为消息传递引擎定义JDBC数据源。

3. JMS服务器

   JMSServer元素定义一个JMS服务器，该服务器管理到其JMS目标的连接和消息（指的是JMSQueue或JMSTopic元素）。 config.xml文件中的此代码片段显示了三个JMS服务器，每个服务器包含两个JMS目标，这里使用JMS队列：

   在此WebLogic配置中，只有一个JMS服务器（JMSServerMailing）使用文件存储。 另外两个根本不指定JMS存储，因此这些JMS服务器中的队列不支持持久消息。

   除非应用程序为目标显式设置传递模式（PERSISTENT或NON_PERSISTENT），否则WebLogic config.xml文件将指定消息是否持久。 因此，那些具有非空文件存储的JMS服务器将使用持久性传递模式到其目的地，而那些没有文件存储的JMS服务器将使用非持久性传递模式。

   要将此配置映射到WebSphere Application Server，请对JMSServerMailing JMS服务器中定义的两个目标使用持久消息传递，对所有其他目标使用非持久传递模式。 再一次，当您在WebSphere Application Server中配置这些JMS队列时，请确保使用正确的JNDIName。 如果JNDI名称不正确，则客户端应用程序将无法找到JMS目标。

4. 国外JMSServer

   ForeignJMSServer元素定义一个JNDI提供程序，该提供程序位于WebLogic JMS服务器外部，并且是ForeignJMSConnectionFactory和ForeignJMSDestination元素的父元素。 这些元素一起提供使WebLogic Server能够访问远程JNDI提供程序的信息，以便客户端可以使用本地JNDI名称来引用远程连接工厂和目标对象。 使用WebSphere MQ作为JMS提供程序时，您经常会看到这种情况。 config.xml文件中的以下代码片段显示了一个外部JMS服务器，一个外部JMS连接工厂和两个外部JMS目标：

   此配置中的外部JMS服务器，连接工厂和目的地将映射到WebSphere MQ JMS provider 。 正确配置LocalJNDINames和RemoteJNDINames非常重要。

5. JDBCConnectionPool和JDBCDataSource

   JDBCConnectionPool和JDBCTxDataSource元素定义JDBC资源的配置。 config.xml文件中的以下代码片段显示了单个连接池和数据源的配置：

   在此代码中：

   • JDBCConnectionPool元素定义在数据源上调用getConnection时从池返回的属性连接。

   • JDBCTxDataSource元素定义了启用了事务的JDBC数据源，并指定了绑定数据源的JNDI名称以及与此数据源关联的连接池。

   要将连接池和数据源映射到WebSphere Application Server，请配置JDBC提供程序，JDBC数据源和JCA认证数据条目。 最重要的元素是JNDIName，DriverName，URL，PasswordEncrypted和Properties。 （您将需要从数据库管理员那里获取密码，因为该密码已在config.xml文件中加密。）

   要映射TestTableName属性，请使用称为PreTest SQL string的WebSphere属性，您可以在其中设置一个SQL语句来测试每个JDBC连接。 您还可以设置连接重试间隔。

   您还应该基于和元素配置池大小。 缺省情况下，WebSphere Application Server连接池将具有最少一个连接和最多十个连接。 WebLogic连接池配置为从25个连接开始，因此您将需要配置WebSphere池大小 。 要做到这一点：

   1. 打开WebSphere Application Server管理控制台，然后选择Resources => JDBC Providers 。
   2. 选择提供者的名称。
   3. 在其他属性下选择数据源条目。
   4. 单击数据源名称。
   5. 选择连接池属性 。
   6. 使用最小和最大连接字段来配置池的大小。

还有其他一些WebLogic特定的属性可用于配置JDBC资源，但是上面列出的那些是最常遇到的。

映射WebLogic启动脚本

本部分描述如何将这些服务器配置元素从WebLogic映射到WebSphere Application Server：

1. JVM参数
2. 系统参数
3. 类路径

请参阅相关主题有关WebLogic配置元素的更多信息。

1. JVM参数

   在定制启动脚本中指定JVM参数是WebLogic的一种常见做法。 确保为正确的环境获取正确的启动脚本。 这是显示使用的Sun™JVM选项的示例：

   -server -Xms1024m -Xmx1024m 
   -verbose:gc -Xloggc:wls-gc.log  -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 
   -XX:ParallelGCThreads=8 -XX:PermSize=128m -XX:MaxPermSize=128m

   假设您将在针对WebLogic调整的同一JVM上运行WebSphere Application Server，那么上述扩展应该是为WebSphere Application Server调整JVM的良好起点，但是您可能希望根据负载测试对其进行调整。 要将这些JVM参数添加到WebSphere Application Server：

   1. 从amin控制台中，选择服务器=>应用程序服务器-=> server_name =>进程定义=> Java虚拟机 。
   2. 检查详细垃圾收集 （切记将其关闭）。
   3. 将初始堆大小设置为1024 。
   4. 将“最大堆大小”设置为1024 。
   5. 在通用JVM参数框中将-server添加为第一个参数，然后在其他现有参数之后添加以下参数：

      -XX:ParallelGCThreads=8 
      -XX:PermSize=128m 
      -XX:MaxPermSize=128m
      -Xloggc:wls-gc.log  
      -XX:+PrintGCDetails 
      -XX:+PrintGCTimeStamps

   注意事项：

   • 详细垃圾回收是通过-verbose:gc选项启用的。 在负载测试期间收集垃圾收集统计信息非常好，但是将记录每个主要和次要垃圾收集，因此请记住在运行最终基准之前禁用详细垃圾收集。

   • 默认情况下，启用类垃圾回收，当没有剩余的活动实例时，该类将删除类。 类垃圾回收在其他WebLogic迁移中导致了性能和可伸缩性问题，因此请通过添加以下JVM参数将其禁用：

     -Xnoclassgc

   有关调整Sun和其他JVM的其他信息，请参见调整Java虚拟机 。

2. 系统参数

   WebLogic启动脚本中指定的所有-D参数都应映射到WebSphere Application Server。 未能映射系统参数肯定会导致迁移问题。 要将系统参数映射到WebSphere Application Server：

   1. 在管理控制台中，选择“ 应用程序服务器=> server_name =>进程定义=> Java虚拟机” 。
   2. 在此示例中，启动脚本具有一个启用缓存的参数和另一个指定log4j配置文件位置的参数。 您应该将这些参数添加到所有现有JVM参数之后的“ 通用JVM参数”框中：

      -Dtangosol.coherence.distributed.localstorage=true 
      -Dlog4j.configuration=file:///myprojects/config/log4j.xml

3. 类路径

   您通常会发现在启动脚本中已修改了WebLogic类路径。 这样做可能是为了添加JAR，这些JAR要么不包含在应用程序的企业归档中，要么用于添加目录，以搜索由应用程序加载的配置文件。 要在两种情况下映射它们：

   1. 在管理控制台中，选择“ 应用程序服务器=> server_name =>进程定义=> Java虚拟机” 。
   2. 在此示例中，WebLogic启动脚本将目录添加到类路径，因此您也将其添加到WebSphere Application Server类路径。 将此文件夹添加到“ 类路径”框中：

      C:\myprojects

      在将JAR添加到类路径时要小心，只有在确保它们尚未包含在WebSphere Application Server发行版中时，才这样做。

映射weblogic-ejb-jar元素

本部分描述如何将这些服务器配置元素从WebLogic映射到WebSphere Application Server：

1. 英文名
2. 本地名称
3. 空闲池中的最大beans和空闲池中的初始beans
4. 缓存中的最大豆数和空闲超时秒数
5. 跨超时秒
6. 并发策略
7. 通过引用启用呼叫
8. 事务之间的缓存
9. 延迟更新直到TX结束
10. 查找者负载豆
11. 资源描述
12. 资源环境描述

请参阅相关主题有关WebLogic配置元素的更多信息。

1. 英文名

   jndi-name元素在全局JNDI名称空间中指定EJB的JNDI名称。 要在WebSphere Application Server中设置EJB的JNDI名称，您需要知道EJB项目和正确的EJB。 要找到它们，请在weblogic-ejb-jar文件中搜索以下元素：

   要将jndi-name元素映射到WebSphere Application Server：

   1. 启动组装工具，然后打开EJB项目。
   2. 如果使用的是Rational Application Developer，则双击部署描述符。
   3. 单击适当的EJB组件。
   4. 向下滚动至WebSphere Bindings部分，然后输入该bean的JNDI名称。

2. 本地名称

   local-jndi-name元素在全局JNDI名称空间中为bean的本地宿主定义JNDI名称。 也就是说，WebLogic提供了一种为全局JNDI命名空间中的本地宿主指定JNDI名称的方法-但这使远程客户端可以在全局JNDI命名空间中查找本地接口，这可能会导致运行时错误，因为本地宿主必须与客户端放置在同一容器中。 现在，在研究WebSphere方面之前，请考虑JNDI的背景：

   • J2EE规范未指定EJB到全局JNDI名称空间的映射。 这由供应商决定。 因此，大多数供应商在自己的特定部署中都包含一个元素，以在全局JNDI名称空间中指定远程EJB JNDI名称。

   • 但是，根据定义，本地本地接口只能由本地容器访问，因此供应商不需要将它们绑定到全局JNDI名称空间。 尽管客户端模块可以使用JNDI查找本地房屋，但是容器无需在JNDI名称空间中公开它们。 相反，客户端模块应该定义对EJB的JNDI引用，并使用java：comp / env作为查找的一部分在本地名称空间中对其进行访问。

   • 业界建议您使用JNDI引用访问本地名称空间中的EJB，而不是使用JNDI名称直接在全局名称空间中访问EJB。 使用JNDI引用可将客户端模块与对全局JNDI名称空间的更改隔离开，这是支持同一EJB的多个版本所必需的。 也就是说，可以将使用相同JNDI引用的客户端模块绑定到EJB的新版本，而无需修改任何源代码。 客户端模块仅将其JNDI引用绑定为指向另一个EJB。

   现在，在这种背景下，如何将local-jndi-name元素映射到WebSphere Application Server？

   首先，您需要了解WebSphere Application Server没有提供一种为本地家庭定义JNDI名称的方法。 相反，您必须使用本地名称空间中的JNDI引用访问本地bean，而不是全局名称空间中的JNDI名称。

   不幸的是，某些WebLogic应用程序使用JNDI名称直接在全局JNDI名称空间中引用本地对象，而不是使用本地JNDI名称空间中的JNDI引用间接引用它们。 因此，这些应用程序将需要一些代码更改。 您可以通过几种方法将local-jndi-name元素映射到WebSphere Application Server，这是不支持的或不可行的。 但是您可以使用的一种方法是将本地JNDI引用添加到调用方模块（这是查找本地房屋的标准方法），然后在所有JNDI查找中使用java：comp / env前缀。 这是业界公认的最佳实践，不仅可以访问EJB，而且可以访问其他资源（例如JMS连接工厂），因此这是您应在此处使用的解决方案。

3. 空闲池中的最大beans和空闲池中的初始beans

   max-beans-in-free-pool元素定义特定实体bean，无状态会话bean或消息驱动bean的EJB空闲池的最大大小。 每个bean类都可以使用此元素定义其自己的空闲池的大小。

   initial-beans-in-free-pool元素定义启动时将填充特定bean类的空闲池的bean实例的初始数量。 用实例填充空闲池可改善初始响应时间，因为可以满足对Bean的初始请求，而无需生成新实例。

   在WebLogic中，应用程序中的每个bean都可以指定其最大池大小和初始池大小，并且从一个bean类到下一个bean类，池大小可以有很大不同。 要确定特定的池大小，请在weblogic-ejb-jar.xml文件中查找以下元素之一：

   


   要在WebSphere Application Server中指定EJB池大小，可以将系统参数添加到JVM：

   1. 在管理控制台中，选择“ 应用程序服务器=>服务器名称=>进程定义=> Java虚拟机” 。
   2. 将com.ibm.websphere.ejbcontainer.poolSize添加到所有现有JVM参数之后的“通用JVM参数”框中。 这是一个示例，该示例将名为RuleEngineEJB的bean的池大小最小设置为1，最大设置为5：

      -Dcom.ibm.websphere.ejbcontainer.poolSize
      =myapp#RulesEngine.jar#example.RulesEngineEJB=1,5

   请参阅WebSphere EJB容器调整以获取更多详细信息。

   尽管可以映射池大小扩展，但是应用程序服务器对空闲池的处理方式有所不同：

   • 如果池为空，WebLogic将不会创建另一个实例； 对新bean的请求将必须等待，直到将现有bean返回到池中为止。 如果池的大小不正确，则此策略可能导致死锁情况，但它控制活动对象的数量，这可能有助于扩展性。
   • 如果池为空，WebSphere Application Server将创建一个新实例（而不是等待该请求）。 请求使用该新实例之后，如果池中还没有maxSize bean，则WebSphere Application Server仅将其返回到池中。 （WebSphere Application Server中的缺省池大小最小为50，最大为500。）

   重要的是要注意这些差异，因为在某些情况下，如果Bean池在高负载下耗尽，创建对象的成本很高或消耗的资源过多，它们可能会导致WebSphere Application Server中的性能和可伸缩性问题。 。 例如，考虑这种情况：

   • 应用程序实现了一个会话Bean，该会话Bean创建起来非常昂贵。 此类会话bean的一个示例可能是为规则引擎提供接口，该引擎在堆中缓存其规则库（可能是数百兆字节的数据）。

   • 由于此bean的创建成​​本很高，并且占用了堆中的大量可用空间，因此应用程序将空闲池中的bean的最大数量限制为5，这实际上在任何给定条件下将此类bean的数量限制为5时间。

   • 该应用程序限制了活动bean的数量，因为从5个活动会话bean实例（从可伸缩性的角度来看）更好地为该“规则服务”的所有传入请求提供服务，而不是在重负载下连续创建/销毁其他会话bean 。

   现在，您可以将此池大小（最小为1，最大为5）映射到WebSphere Application Server。 映射工作正常，因为它确实将池大小限制为5，但没有将活动实例的数目限制为5。如果使用所有五个会话Bean的请求数为5，则该池将为空，但是，如果对这些会话bean中的一个请求第六个请求，那么将创建并使用第六个会话对象-只是不返回到池中。 在WebLogic中，对第六个会话对象的请求必须先等待其中一个活动bean返回池，然后才能继续。

   如您所见，池大小的这种直接映射可能导致创建其他会话bean，而在繁重的负载下，其他bean的创建和销毁可能导致可伸缩性问题。 如果应用程序要求对活动会话数进行硬性限制，那么该bean将需要跟踪空闲池中的bean数量，并在没有可用活动时等待一个活动bean完成。

   从该示例中可以汲取的重要教训是，在负载测试期间，您将需要关注活动中的最大bean数，以确保它们不超过池的maxSize。 如果这样做，则可能需要将池的大小调整为更大，以避免连续创建和销毁对象。 否则，您将要对活动bean的数量实施硬性限制。

4. 缓存中的最大豆数和空闲超时秒数

   max-beans-in-cache元素控制可以在任何给定时间处于活动状态的此类的最大对象数。 当达到max-bean-in-cache的值时，WebLogic会钝化客户端最近未使用的某些EJB。

   idle-timeout-seconds元素指定Bean保留在高速缓存中的最长时间。 经过此时间后，如果缓存中的Bean数量接近缓存中的max-beans，则容器将删除Bean。 （在WebLogic 8.1 SP4之前，此元素被忽略。）

   在WebLogic中，可以为单个bean类定义缓存。 可以在内存中的对象随类的不同而不同，空闲超时也可以。 要查找自定义的缓存，请在weblogic-ebj-jar.xml中搜索以下元素之一：

   


   使用WebSphere Application Server，您不能为每个bean类指定高速缓存大小或空闲超时（在WebSphere Application Server中称为清除间隔 ），但是可以为可以在整个EJB中处于活动状态的实例指定高速缓存大小和清除间隔。容器。

   WebSphere Application Server中的高速缓存大小类似于max-beans-in-cache。 它在EJB容器内的活动实例列表中指定存储桶的数量。 尽管一个存储桶可以包含多个实例，但是当活动实例的数量超过存储桶的数量（高速缓存大小）时，容器会通过将某些实例钝化到磁盘上而疲​​倦地删除它们。 因此，如果将缓存大小设置为典型工作负载期间预期的最大活动实例数，则性能最佳。

   WebSphere Application Server中的清理间隔类似于idle-timeout-seconds。 它指定容器尝试从缓存中删除未使用的项目的时间间隔，以将缓存中的项目总数减少到缓存大小的值。

   如果遇到某个应用程序，其中逐级对WebLogic缓存大小进行了调整，则在调整WebSphere EJB缓存大小时应考虑这些缓存大小。 您可以使用一种算法来调整容器的EJB缓存大小，该算法可根据不同种类的bean计算平均EJB缓存需求。

   如果应用程序中有大量实体Bean，则应使用max-beans-in-cache元素的值在任何时候及时计算容器中活动的EJB的预期最大值，并在操作期间监视缓存。进行负载测试以验证是否没有从缓存中逐出； 也就是说，确保没有很高的ejbStores调用率。 此操作很重要，因为WebSphere Application Server中的默认最大高速缓存大小只有几千，并且大量使用实体bean的应用程序可能已经指定了几千的池大小。

5. 跨超时秒

   trans-timeout-seconds元素指定EJB的容器启动的事务的最大持续时间。 如果事务持续的时间超过trans-timeout-seconds，则WebLogic EJB容器将回滚事务。 通过在所有weblogic-ejb-jar.xml文件中搜索此元素，可以看到此扩展名：

   WebSphere Application Server提供了两种设置事务超时的方法。

   选项1：如果所有Bean都将事务超时设置为相同的值，那么可以使用管理控制台在WebSphere事务服务中设置最大事务超时：

   1. 从管理控制台中，选择服务器=>应用程序服务器=> server_name =>容器服务=>事务服务 。
   2. 将“总事务生存期超时”设置为30 。

   选项2：您可以在Bean的部署描述符中设置事务超时。 要做到这一点：

   1. 在Rational Application Developer中，对于每个EJB项目，双击其部署描述符。
   2. 双击特定的bean设置事务超时。
   3. 将“组件事务超时”整数设置为30 。

   一般建议是更改Bean的部署描述符，而不是更改所有Bean的事务服务。 更改所有bean的事务超时将影响该容器中运行的所有应用程序。 但是，如果应用程序在所有bean中都将事务超时设置为相同的值，并且是在该容器中运行的唯一应用程序，那么在WebSphere Application Server事务服务中而不是在每个bean中一次设置该值将容易得多。 如果不是这种情况，则应为每个bean设置事务超时。

6. 并发策略

   concurrency-strategy元素指定容器应如何管理对实体Bean的并发访问。 WebLogic支持四种不同的并发策略：

   • 当Bean与事务关联时， 排他并发策略使WebLogic Server在缓存的实体EJB实例上放置排他锁。 在事务完成之前，对EJB实例的其他请求将被阻止。

     要查找使用“排他”并发策略的bean，请在weblogic-ejb-jar.xml文件中搜索以下元素：

     Exclusive

     找到它们后，请注意它们的EJB项目和EJB名称，您需要将它们映射到WebSphere Application Server：

     1. 在Rational Application Developer中，打开EJB项目。
     2. 双击部署描述符。
     3. 双击适当的Java bean。
     4. 向下滚动到Bean Cache部分。
     5. 将激活时间设置为一次 。
     6. 将“负载”设置为ACTIVATION 。

     这些参数避免了对ejbLoad函数的调用，但会序列化对Bean实例的访问。 此选项通过在缓存中保持持久状态来提高内存利用率，但是如果通常不并发访问Bean实例，则可以提供更好的响应时间 。 该选项在EJB规范中称为缓存选项A。

   • ReadOnly并发策略用于只读实体Bean。 它为每个事务激活一个新实例，以便请求并行进行。 当WebLogic Server为ReadOnly bean调用ejbLoad（）时，它基于元素。

     read-timeout-seconds元素指定对只读实体bean的ejbLoad（）调用之间的秒数。 它仅适用于具有ReadOnly并发策略的bean。 值为0的read-timeout-seconds指定不从数据库中重新加载只读bean。

     要查找只读bean，请在weblogic-ejb-jar.xml文件中搜索以下元素：

     ReadOnly

     同样，请确保记下EJB项目和EJB名称，以便可以在WebSphere Application Server中将它们标记为只读bean：

     1. 在Rational Application Developer中，打开EJB项目。
     2. 双击部署描述符。
     3. 双击适当的Java bean。
     4. 向下滚动到Bean Cache部分。
     5. 将激活时间设置为一次 。
     6. 将“负载”设置为INTERVAL 。
     7. 将重新加载间隔整数设置为适当的分钟数。 （例如，如果将WebLogic 元素设置为600秒，则可以将WebSphere Application Server的重装间隔整数设置为10分钟。）

     如果在WebLogic中将设置为0，则仅在首次将实例带入缓存时才调用ejbLoad。 在WebSphere Application Server中，重新加载整数间隔值为0也会导致容器从不重新加载Bean。

     （请参阅相关主题 ，了解关于开发在WebSphere Application Server只读Bean的更多信息。）

   • 数据库并发策略使WebLogic Server将对实体Bean的锁定请求委派给基础数据存储。 通过这种策略，WebLogic Server可以分配一个单独的实体bean实例，并允许锁定和缓存由数据库处理。 这是默认选项。

     WebLogic数据库并发策略意味着在事务开始时将Bean激活并添加到缓存中，并在事务结束时将其钝化并从缓存中删除。

     要查找使用数据库并发策略的EJB组件和项目，请在weblogic-ejb-jar.xml文件中搜索此元素：

     Database

     再次注意EJB项目和EJB名称。 要将数据库并发策略映射到WebSphere Application Server：

     1. 在Rational Application Developer中，打开EJB项目。
     2. 双击部署描述符。
     3. 双击适当的Java bean。
     4. 向下滚动到Bean Cache部分。
     5. 将激活位置设置为TRANSACTION 。
     6. 将“负载”设置为“ TRANSACTION” 。

     对于在WebSphere Application Server V6.0 Bean缓存，默认是激活的： 交易和负载均在： 交易 -因为这是默认的，你没有明确设置它为每个豆子，你想有数据库并发策略。 该策略在EJB规范中也称为缓存选项C。

   • 乐观并发策略在事务期间不将锁锁定在EJB容器或数据库中。 EJB容器在提交事务之前验证事务更新的所有数据均未更改。 如果任何更新的数据发生更改，则EJB容器将回滚事务。

     要查找支持乐观并发控制的Bean，请在weblogic-ejb-jar.xml文件中搜索以下元素：

     Optimistic

     一定要注意EJB项目和EJB名称。 您将需要这些值来迁移数据库并发策略。

     找到这些bean并记下它们的名称和它们的EJB项目的名称之后，请在weblogic-cmp-rdbms-jar.xml中搜索元素； 表中的这些列是在将其提交到数据库之前需要验证的列，确保没有其他事务修改过该数据。

     现在，您可以在WebSphere Application Server中配置乐观并发了。

     1. 首先，在部署描述符中启用乐观锁定：

        1. 在Rational Application Developer中，打开EJB项目。
        2. 双击部署描述符。
        3. 选择访问选项卡。
        4. 对于实体2.x（Bean级别）的访问意图，选择EJB并按“ 添加”按钮。
        5. 对于访问意图名称，选择wsOptimisticUpdate并按Finish按钮。

     2. 接下来，指定提交修改后的数据时要包括在合格的更新语句中的字段。 为此，您应该为EJB到DDB映射定义数据库映射。 完成后：

        1. 右键单击EJB项目。
        2. 选择EJB到RDB Mapping => Generate Map 。
        3. 在“概述”部分的“企业Beans”窗格中，选择CMP字段，该字段应用作乐观谓词，以包括在合格SQL更新语句中。
        4. 在“属性”视图中，为OptimisticPredicate选择True 。

7. 通过引用启用呼叫

   按引用启用呼叫元素通常用于按引用而不是按值传递参数，这需要制作参数的副本。 当按引用启用调用为True时，从同一个EAR文件或独立JAR文件中调用的EJB方法将按引用传递参数，这由于未复制参数而提高了方法调用性能。

   在WebLogic中，可以逐个bean启用引用调用，但是在WebSphere Application Server中，可以在容器级别启用引用引用调用。 因此，如果启用了按引用调用，则它将应用于应用程序中的所有远程接口，而不仅适用于它们的一部分。

   要在WebSphere Application Server中启用引用调用：

   1. 在管理控制台中，选择服务器=>应用程序服务器=> server_name =>容器服务=> ORB服务 。
   2. 选中通过引用传递 。

8. 事务之间的缓存

   cache-between-transactions元素指定EJB容器是否将在事务之间缓存实体bean的持久状态。 指定True以启用事务之间的持久状态缓存； 指定False （默认值）以不缓存事务之间的持久状态。

   是否可以缓存事务之间的交互取决于并发策略：

   • 如果并发策略为ReadOnly，则持久状态将始终在事务之间缓存。
   • 如果并发策略是数据库，则持久状态永远不会在事务之间缓存。

   因此，如果实体使用ReadOnly或Database并发策略，则EJB容器实际上将那些bean的cache-between-tansactions元素忽略。

   使用WebSphere Application Server时，不需要映射cache-between-transactions元素，因为WebSphere Application Server的只读bean实现始终在事务之间缓存持久状态，而数据库并发策略的实现则从不缓存持久状态。 这与您使用WebLogic获得的行为相同。

9. 延迟更新直到TX结束

   默认情况下，将delay-updates-until-end-of-tx元素设置为True，以在事务完成时更新事务中所有bean的持久性存储。 这与对所有数据库操作进行批处理直到事务结束一致，这也是WebLogic的默认设置。 如果将此元素设置为False，则每次调用CMP EJB set方法时，更新都会写入数据库。 通常，将其设置为True可以提高性能，但这不会保留数据库事务中数据库更新的顺序。

   在WebLogic应用程序中，您可能会发现一些为delay-updates-until-end-of-tx指定False的bean。 据推测，这将覆盖默认的WebLogic设置，该设置将所有数据库操作推迟到事务结束。 要查找关闭延迟更新直到事务结束的bean，请在weblogic-ejb-jar.xml文件中搜索this元素：

   false

   在WebSphere Application Server中，缺省是在调用每个CMP mutator时执行数据库操作，而不是将它们延迟到事务结束。 您可以将更新延迟到WebSphere Application Server中的事务结束，以进行性能优化，但是您只能为容器中的所有bean打开或关闭更新。

   当您将更新延迟到事务结束时，通常可以提高性能。 折衷是批处理操作不会以与代码中执行的顺序相同的顺序执行更新。 出于其他考虑，请参阅enable-batch-operations和order-database-operations 。

10. 查找者负载豆

    finders-load-bean元素确定在调用返回对Bean的引用的finder方法之后，WebLogic Server是否将EJB加载到缓存中。 如果将此元素设置为True（默认值），并且查找程序返回对Bean的引用，则WebLogic Server会立即将Bean加载到缓存中。 如果将此元素设置为False，则在第一次调用方法之前，WebLogic Server不会自动将bean加载到缓存中。

    在WebSphere Application Server中，缺省设置是在调用查找程序时将Bean装入高速缓存中，因为此行为与CMP 2.0规范一致。 如果要更改此行为以将加载Bean的时间推迟到调用第一个方法之前，可以定义包含那些EJB的EJB JAR来实现EJB1.1规范，因为此行为与该规范一致。

11. 资源描述

    resource-description元素将ejb-jar.xml中定义的映射到实际资源的JNDI名称。 在ejb-jar.xml文件中定义的元素的典型示例是JDBC数据源和JMS连接工厂。 您可以在WebLogic config.xml文件中找到这些资源的实际JNDI名称。

    使用元素可使客户端将资源的逻辑名称绑定到该资源的实际JNDI名称。 客户端使用本地名称空间中的逻辑JNDI引用（例如，java：comp / env / ）而不是实际的JNDI名称（例如，）来查找资源，这样可以使客户端免受JNDI名称更改的影响。

    在WebLogic中，在weblogic-ejb-jar.xml文件中指定了资源到JNDI名称的映射。 例如：

    
          jms/Mailing
          jms/Mailing
    

    在WebSphere Application Server中，使用组装工具指定资源到JNDI名称的映射：

    1. 在Rational Application Developer中，打开适当的EJB项目。 例如： ShippingAutoserviceEJB 。
    2. 双击部署描述符。
    3. 单击引用选项卡。
    4. 展开正确的Java Bean（例如ShipmentManager ）以查看所有JNDI资源引用。 您将需要为每个引用指定一个JNDI名称。 选择一个引用，例如jms / MailingMq 。 （WebLogic将到JNDI名称的映射与到JNDI名称的映射不同（请参阅下一节），但是WebSphere Application Server对待它们的方式相同。因此，当您扩展时Java bean，您将在该bean的ejb-jar.xml文件中看到所有定义的和。）
    5. 向下滚动到WebSphere Bindings部分，然后为该资源输入正确的JNDI名称（在WebLogic config.xml文件中找到）。
    6. 对每个（和每个，如有必要）重复步骤4-5。

12. 资源环境描述

    resource-env-description元素将ejb-jar.xml中定义的映射到实际资源的JNDI名称。 在ejb-jar.xml文件中定义的的典型示例将用于受管理对象，例如JMS目标。 您可以在WebLogic config.xml文件中找到这些资源的实际JNDI名称。

    使用元素可使客户端将资源的逻辑名称绑定到实际的JNDI名称。 客户端使用逻辑JNDI引用（例如java：comp / env / ）而不是实际的JNDI名称（例如java：）查找资源，从而隔离了客户端从更改为JNDI名称。

    在WebLogic中，在weblogic-ejb-jar.xml文件中指定了资源到JNDI名称的映射。 例如：

    
            jms/Queue/RequestMailingMq
            jms/Queue/RequestMailingMq
    

    在WebSphere Application Server中，使用组装工具指定资源到JNDI名称的映射：

    1. 在Rational Application Developer中，打开EJB项目。 例如： ShippingAutoserviceEJB 。
    2. 双击部署描述符。
    3. 单击引用选项卡。
    4. 展开Java bean（例如ShipmentManager ）以查看所有JNDI资源引用。 您将需要为每个引用指定一个JNDI名称。 选择引用之一，例如jms / Queue / RequestMailingMq 。 如前一节所述，WebLogic将到JNDI名称的映射与到JNDI名称的映射不同，但是WebSphere Application Server对待它们的映射相同。 因此，当您扩展正确的Java bean时，将看到为该bean定义的所有和。
    5. 向下滚动到WebSphere Bindings部分，然后输入该资源的JNDI名称 。
    6. 对每个（如果需要，和resource-ref>）重复步骤4-5。

映射weblogic-cmp-rdbms-jar元素

本部分描述如何将这些元素从WebLogic映射到WebSphere Applicatioin Server：

1. 使用选择更新
2. 启用批量操作
3. 订单数据库操作
4. weblogic-ql
5. 最大元素

请参阅相关主题有关WebLogic配置元素的更多细节。

1. 使用选择更新

   use-select-for-update元素基于每个bean强制执行悲观并发。 如果指定True，则每当从数据库加载Bean并在事务期间保持该锁定时，都会使用select update update扩展名。 使用此WebLogic扩展，在第一个事务运行时，另一个事务就无法读取或更新数据。 此扩展通过长时间保留锁来提高数据完整性并减少死锁，但代价是并发性降低。

   要查找使用select for update扩展名的EJB，请在weblogic-cmp-rdbms-jar.xml文件中搜索此元素，并注意EJB项目及其使用的EJB名称：

   要将元素映射到WebSphere Application Server：

   1. 在Rational Application Developer中，打开EJB项目。
   2. 双击部署描述符。
   3. 选择访问选项卡。
   4. 在“实体2.x的访问意图（Bean级别）”部分中，选择Java Bean，然后按“ 添加”按钮。
   5. 对于访问意图名称，选择wsPessimisticUpdate并按Finish按钮。

   如果将访问意图设置为wsPessimisticUpdate，则容器将始终使用select进行更新，这可能会导致性能问题，但会消除死锁。 因此，请保留默认的访问意图策略，直到您能够运行负载测试来确定是否存在数据完整性，死锁或性能问题。 如果是这样，请按照上述步骤设置访问意图。

2. 启用批量操作

   enable-batch-operations元素控制EJB容器是否启用批处理数据库操作，包括批处理插入，批处理更新和批处理删除。 如果是这样，EJB容器将延迟数据库操作，直到事务提交时间为止。

   默认情况下，除非明确关闭，否则WebLogic会在实体Bean上启用批处理操作，您可以通过禁用order-database-operations和enable-batch-operations元素来执行此操作（请参阅下一节）。 要找到这些扩展，请在weblogic-cmp-rdbms-jar.xml文件中搜索此元素：

   false

   同样，批处理操作默认情况下在WebLogic中启用，并且可以在JAR级别上禁用JAR中所有CMP实体bean的批处理操作。 批处理操作默认情况下在WebSphere Application Server中是禁用的，并且可以在EJB容器级别为容器中的所有CMP启用批处理操作。

   由于这是一个全有或全无的扩展，因此您需要确定是否为所有CMP实体启用批处理操作。 您可以从默认值（未启用批处理操作）开始，并更改是否认为可以通过批处理操作解决性能问题。

   要在WebSphere Application Server中启用批处理操作：

   1. 在管理控制台中，导航到“ 应用程序服务器=> server_name =>进程定义=> Java虚拟机” 。
   2. 在所有现有的JVM参数之后，将此参数添加到“通用​​JVM参数”框中：

      -Dcom.ibm.ws.pm.batch=true

   再次需要权衡的是，批处理数据库操作不一定以与代码相同的顺序处理更新，但是它们通常可以带来更好的性能。 因此，考虑在不批处理数据库操作的情况下开始（WebSphere Application Server缺省），如果需要更好的性能，则将其打开。

3. 订单数据库操作

   order-database-operations元素将所有数据库操作推迟到事务结束之前，自动对操作之间的依赖关系进行排序，并将这些操作以避免数据库约束错误的方式发送给数据库。 在WebLogic中，默认情况下启用此元素，因此如果不想订购数据库操作，则必须显式禁用它。

   要禁用order-database-operations，必须禁用此元素和enable-batch-operations元素（请参阅上一节）。 如果您不同时禁用两者，则容器将继续对数据库操作进行排序。

   在WebSphere Application Server中，缺省情况下数据库操作的排序（和批处理）是禁用的，因此您必须显式启用它。 为此，必须使用以下系统参数在创建时启用延迟插入：

   -Dcom.ibm.ws.pm.deferredcreate=true
-Dcom.ibm.ws.pm.batch=true

   第一个参数将推迟数据库插入直到事务提交时间； 第二个将推迟所有其他操作发送到数据库，直到事务提交。 如果在负载测试期间发现参照完整性违规，则可能还需要设置容器管理的持久性的序列分组。

   为了说明通过订单数据库操作扩展来维护引用完整性的必要性，请考虑一个示例：

   1. 假设实体bean Cust-A与Sales-A有关。
   2. 进一步假设删除了Sales-A，并为Cust-A分配了一个新的Sales-B。
   3. 如果Cust-A具有指示其必须具有销售人员的完整性约束，则必须先将Cust-A更新为新的Sales-B，然后再删除Sales-A。

   要在WebSphere Application Server中设置序列组 ：

   1. 在Rational Application Developer中，打开EJB项目。
   2. 双击部署描述符。
   3. 单击概述选项卡。
   4. 在“ EJB CMP序列组”部分中，单击“ 添加”以启动EJB CMP序列组向导。
   5. 输入序列组的名称。
   6. 使用所有大写字母键入您的组类型名称： RI_INSERT或UPDATE_LOCK 。 对于删除操作，持久性管理器将反转RI_INSERT组中的顺序，并相应地删除Bean及其对应的数据库行。
   7. 在“可用的豆”列表中，突出显示要放入组中的第一个豆。 单击指向“所选豆”列表的箭头，将其从“可用豆”列表移至“所选豆”列表。
   8. 重复步骤7，直到您已添加了要持久性管理器处理它们的序列中的所有bean。

4. weblogic-ql

   weblogic-ql元素指定一个查询，该查询包含特定于WebLogic的EJB 2.0查询语言（EJB-QL）扩展。 ejb-jar.xml部署描述符中使用了标准的EJB-QL语言功能，而weblogic-cmp-rdbms-jar.xml中使用了WebLogic EJB-QL扩展。 查询中通常使用排序，聚合函数和子查询，但是由于也可以使用其他扩展，因此请务必仔细检查所有weblogic-ql元素。

   WebSphere Application Server还扩展了EJB-QL语言功能，但是WebSphere Application Server并未定义单独的QL，而是为EJB-QL语法提供了排序，子查询和聚合功能。 也就是说，WebSphere扩展了EJB-QL的语法以包括这些扩展。 因此，可以在ejb-jar.xml文件的标准ejb-ql元素中使用EJB-QL及其扩展名。

   要将weblogic-ql元素映射到ejb-ql元素：

   1. 在Rational Application Developer中，打开EJB项目。
   2. 双击“部署描述符”。
   3. 单击适当的Java bean。
   4. 向下滚动到“查询”部分。
   5. 选择适当的查询，然后按“ 编辑”按钮以显示“编辑查找器方法”对话框。
   6. 请按照向导步骤来构造正确的查询语句。

   下一部分显示了查询语句从weblogic-ql元素到ejb-ql元素的映射。

   映射顺序

   orderby WebLogic QL扩展名是与Finder方法一起使用的关键字，用于指定从选择中返回的结果的顺序。 您还可以按多个字段排序，并指定是按升序还是降序返回结果。

   • 示例weblogic-ql元素：

     select object(o) from MeetingAutoservice o where o.idInternAutoservice = ?1 orderby o.numberMeeting

   • 映射的ejb-ql元素：

     select object(o) from MeetingAutoservice o where o.idInternAutoservice = ?1 order by o.numberMeeting

   映射子查询和聚合函数

   子查询WebLogic QL扩展使查询可以嵌入主查询的WHERE子句中，以返回要在主查询中使用的数据，作为进一步限制要检索的数据的条件。 MAX WebLogic QL扩展名返回指定字段的最大值。 此示例显示了子查询和聚合函数及其到WebSphere Application Server的映射：

   • 示例weblogic-ql元素：

     select OBJECT(o) from MeetingAutoservice o where o.idInternAutoservice=?1 AND o.meetingNumber = (select MAX(p.meetingNumber) from MeetingAutoservice p where p.idInternAutoservice = ?1)

   • 映射的ejb-ql元素：

     select OBJECT(o) from MeetingAutoservice o where o.idInternAutoservice=?1 AND o.meetingNumber = (select MAX(p.meetingNumber) from MeetingAutoservice p where p.idInternAutoservice = ?1)

5. 最大元素

   max-elements元素指定multi-finder或ejbSelect方法应返回的最大元素数。 也就是说，它限制了查询中返回的行数，类似于JDBC中的maxRows功能。

   根据J2EE规范，如果不限制结果集的大小，则在执行多对象查找器或ejbSelect方法时，将ResultSet读取到末尾，并且客户端将收到整个集合，以进行迭代。 显然，这种方法对于大型结果集（集合）而言效率不高。

   要查找所有出现的max-elements，请在weblogic-cmp-rdbms-jar.xml中搜索以下元素：

   使用WebSphere Application Server，您不能限制从查找器获取的行数。 如果应用程序正在使用max-elements，则将需要修改代码；否则，请执行以下操作。 一种可能的修改是在外观中编写适当的逻辑以从结果集中获取FETCH FIRST n ROWS。

   也就是说，总的来说，这是一个很好的编程指南，它的结果集大于10的任何查找器都应使用JDBC来实现，从而避免使用相对耗费内存的EJB查找器方法，因为返回十个以上元素的查找器可以如果打算将应用程序设计成大容量，则会出现问题。

结论

本文介绍了如何在应用程序中查找WebLogic专有扩展，以及如何将这些专有扩展迁移到WebSphere Application Server －但这仅仅是因为找到它们并不意味着您应该全部实现它们。 通常，将应用程序从WebLogic迁移到WebSphere Application Server时：

• 仔细检查所有WebLogic专有设置，以便您事先知道已将哪些扩展应用于该应用程序。 这将帮助您更好地测试和调整应用程序，估计迁移将花费多长时间，并帮助您避免意外。

• 实现使应用程序运行所需的那些扩展-并且仅实现那些扩展。 所需的扩展将是那些创建应用程序所需的托管资源（JDBC连接池，JMS连接工厂等）的扩展。

• 应用程序运行后，请根据需要实施那些扩展，以满足应用程序的性能和可伸缩性要求。 也就是说，从缺省的WebSphere Application Server设置开始，然后让负载测试指导您确定可能需要实现的其他扩展。

• 抵制重新构造该应用程序的冲动-至少直到迁移完成为止。 例如，如果应用程序使用悲观锁定，则在迁移期间不要将应用程序更改为使用乐观锁定。 测试和调整应用程序以使其尽可能最佳地运行，然后在以后考虑进行重构。

知道如何识别WebLogic扩展并将其迁移到WebSphere Application Server并遵循这些准则将有助于您成功进行迁移，同时消除许多麻烦。

---

翻译自: https://www.ibm.com/developerworks/websphere/library/techarticles/0706_vines/0706_vines.html