自动化WebLogic平台应用程序供应

领测软件测试网

　　 

摘要

　　BEA WebLogic Platform应用程序供应（provisionin）是一个这样的过程：准备提供一个有效的WebLogic Platform环境来支持已部署好的应用程序的后续应用。

在前一篇文章中，我们介绍了经过几个阶段将WebLogic Platform 8.1应用程序从开发升级到生产阶段时，我们能从中获得什么。在本文中，研究的重点是使用可用于WebLogic Platform产品的工具来自动化每个阶段的应用程序供应。这将允许您自动创建运行WebLogic应用程序所需的环境。

简介

　　BEA WebLogic Platform应用程序供应是一个这样的过程：准备提供一个有效的WebLogic Platform环境来支持已部署好的应用程序的后续应用。WebLogic Platform环境通常由三种资源组成：域级别的资源（如JDBC Connection Pool和DataSources）、客户应用程序和生产数据（如安全角色、缓存策略、门户元数据和贸易合作伙伴管理数据等）。在经过几个阶段将WebLogic应用程序从开发阶段升级到生产阶段时，需要在每个阶段适当地供应这些资源。考虑到配置域级别和应用程序级资源的复杂性，应用程序供应不是一个普通的过程，它常常需要大量的手工劳动并且很容易出错。所以，人们非常期待通过自动化供应过程来提高生产效率和可靠性，同时降低IT成本。

　　本文首先将讨论自动化应用程序供应过程中面临的挑战。然后对可以在WebLogic Platform中使用的供应工具进行概括。通过对一些常见场景的案例分析，比如从开发阶段升级到生产阶段、快速生产复制、生产数据配置和差量供应，本文将演示如何有效使用这些供应工具来自动化供应过程。

　　本文提供的示例均摘自一些实际的客户供应场景。文中引用的WebLogic Scripting Tool（WLST）示例脚本和域模板都已经在WebLogic Platform 8.1 Service Pack 4上开发并通过测试。在即将推出的WebLogic Platform版本中，还将支持JSR-88。因此，目前已经配置好的域级别的一些资源将作为应用程序级资源打包。随着应用程序供应的自动化，我们的生活会更轻松一些。

　　注意，本文并不打算成为一篇关于如何使用供应工具（如Domain Template Builder，或DTB）的教程。通过“参考资料”部分中提供的链接，您可以找到关于这些工具的更多信息。

　　 挑战

　　要运行WebLogic Platform应用程序，就必须创建一个包括适当WebLogic Platform组件和应用程序级资源的域。图1提供了一个升级过程的例子，在这个过程中，应用程序要经历4个阶段：开发、集成、QA/分级测试和生产。在生产阶段，WebLogic Platform应用程序供应还包括为每个应用程序供应需求设置一个集群子网和代理。

图 1. 从开发阶段升级到生产阶段的应用程序升级过程

　　在典型的开发阶段，几个开发人员将同时为一个项目工作，每个开发人员从事不同的模块研究。这些开发人员可能拥有作为沙箱的自己的工作域（开发模式、带有本地数据库的单服务器），并且可以使用源代码控制工具来促进团队开发。在开发模式域中，BEA WebLogic Server和BEA WebLogic Workshop将自动供应一些应用程序资源，比如 Entity Bean表、AsyncDispatcher队列和会话状态表。在生产模式域中，必须显式供应这些资源。QA/分级测试环境通常会模拟真实的生产环境，该环境一般由一个或多个集群域以及一些专用的数据库服务器、负载平衡器和商业证书组成。安全性和高可用性在生产阶段很重要，因为它们可能是开发环境中完全缺乏的东西。此外，如果在生产阶段对托管服务器使用不同的IP地址或端口，那么还需要更新应用程序模块，为定制部署重新生成EAR文件。

　　当经过几个阶段将WebLogic Platform应用程序从开发阶段升级到生产阶段时，自动化这个过程对确保成功实现生产部署很关键。配置自动化所面临的一个主要挑战是识别和捕获正确的配置需要，支持正确的应用程序部署，并将这一点贯彻到每个阶段，然后进行目标环境所需的任何配置定制。

　　WebLogic Platform提供了大量系统工具来促进供应自动化，这些工具包括Configuration Wizard、Domain Template Builder和WebLogic Scripting Tool（WLST）等。关于这些工具的完整列表，请参阅WebLogic Platform Deployment Guide。WebLogic Platform还提供了许多帮助客户完成初始的域配置的预定义域模板、一组用来添加定义良好的应用程序的模板，以及维护现有域的一些服务。根据各种供应场景的特点，可以将供应方法分成基于模板的方法和基于WLST的方法。注意，可以有效组合这些方法来应对复杂的供应场景。

基于模板的供应

　　预定义域和扩展模板包含构建或扩展特殊WebLogic域所需的主要属性和文件。在向域中添加了新的资源和应用程序之后，就可以使用Domain Template Builder来创建定制域模板，稍后可以使用该模板，通过Configuration Wizard创建一个目标域。

　　基于模板的方法利用Domain Template Builder功能来捕获当前域的各种配置细节和工件。为了使用基于模板的方法，将从一个运行中的域开始。这个域可以是一个服务器开发域，也可以是一个集群的生产域。此外，应该完全了解现有域，这样才不会在创建模板时错过关键配置信息。在创建模板时，有一个定制域资源设置的机会，但也可以在以后某个阶段实现定制，即在使用已创建的模板实际配置该域的时候。

基于WLST的供应

　　WebLogic Server Scripting Tool（WLST）是一个命令行脚本接口（使用Jython构建），您可以使用该接口与WebLogic Server交互以及配置WebLogic Server。WLST既支持联机操作模式，也支持脱机操作模式。WLST Online在连接到某台运行中的服务器时才开始运作，而WLST Offline通过添加命令来支持Configuration Wizard功能，它允许在不连接到运行中的服务器的情况下创建和扩展WebLogic域。WLST Offline支持WebLogic Platform中提供的预定义域模板以及使用Template Builder工具创建的定制域模板。

　　 基于WLST的配置方法利用WLST Offline和WLST Online功能来记录一组域脚本中的各种域配置细节，并将这些脚本与一些预定义或定制的域模板一起使用，以创建目标域。使用基于WLST的方法，可以很容易地通过脚本更改域配置，还可以通过源代码控制有效追踪配置变化。关于使用WLST的更多信息，请参阅CodeShare项目wlst，可以从中获得一些示例脚本和最佳实践。

　　 在以下几个小节中，将深入研究一些常见的供应用例，演示并比较基于模板的方法与基于WLST的方法的运用。

用例：从开发阶段转移到分级测试/生产阶段

　　该用例展示了一个在自动供应方面有较高要求的常见配置场景。通常，开发环境与生产环境存在极大差异，这使得基于WLST的方法比基于模板的方法更加适用。通过一个假设的场景，我们将阐述如何组合使用WLST Offline和WLST Online脚本来配置所需的生产域。

　　 该例中，开发团队已经实现了两个应用程序：BEA WebLogic Integration应用程序和BEA WebLogic Portal应用程序。这两个应用程序都是使用单独的服务器实例在单独的平台域中部署的。在从分级测试阶段移动到生产阶段时，该团队想在一个平台域中配置两个单独的集群（wliCluster和wlpCluster），一个用于部署WebLogic Integration应用程序，另一个用于部署WebLogic Portal应用程序。Configuration Wizard和WLST Offline只支持单集群域的自动配置。当通过Configuration Wizard在一个平台域中配置多个集群（例如，有一个wliCluster和一个wlpCluster）时，域级别的资源会自动将目标设定为第一个集群（在这里，是wliCluster）。所以，需要重新指定一些资源（比如与门户相关的应用程序和资源）的目标。组合使用WLST Offline和Online脚本可以有效满足配置多集群域的特殊需求。

　　 通常，可以使用WLST Offline脚本来配置用于任何单集群域的资源。例如，WLST Offline脚本可以添加用户、添加托管的服务器、添加额外的JMS队列、定制JDBCConnectionPool，等等。因为WLST Offline是基于Config Wizard框架的，所以它支持一些良好的自动配置特性，但它在配置多个集群方面存在同样的限制。在创建第一个集群（wliCluster）之后，需要从wliCluster中取消对门户相关的应用程序和资源的目标设定。

cd('/')
unassign('Application', 'paymentWSApp','Target', 'wliCluster')
unassign('Application', 'taxWSApp','Target', ' wliCluster ')
unassign('JDBCConnectionPool', 'portalPool','Target', ' wliCluster ')
unassign('JDBCDataSource','p13n_trackingDataSource', 'Target', ' wliCluster ')
unassign('JDBCDataSource', 'p13nDataSource','Target', ' wliCluster ')
unassign('JDBCTxDataSource','portalFrameworkPool', 'Target', ' wliCluster ')

　　以下WLST Online脚本举例说明了第二个集群（wlpCluster）的配置，并适当地重新设置与门户相关的那些资源的目标，将它们的目标设定为wlpCluster。

def create_wlpcluster(cluster_config):

 clusterName, clusterAddr,multicastAddr,multicastPort, mss = cluster_config

 # create the cluster
 cluster = auto_createCluster(clusterName,clusterAddr, 
multicastAddr, multicastPort)

 # create the managed servers
 for msConfig in mss:
   managedserver = auto_createManagedServer(msConfig,cluster)

 # add the cluster to the target list of the following resources
 wlst.cd('/')

 jcf = wlst.getTarget('JMSConnectionFactory/' + 'cgQueue')
 if jcf != None:
   jcf.addTarget(cluster)

 poolList='portalPool','cgPool','cgJMSPool-nonXA'
 for poolName in poolList:
   pool = wlst.getTarget('JDBCConnectionPool/' + poolName)
   if pool != None:
     pool.addTarget(cluster)
  
 dsList='p13n_trackingDataSource','p13nDataSource'
 for dsName in dsList:
   ds = wlst.getTarget('JDBCDataSource/' + dsName)
   if ds != None:
     ds.addTarget(cluster)

 txdsList='portalFrameworkPool','cgDataSource','cgDataSource-nonXA'
 for txdsName in txdsList:
   txds = wlst.getTarget('JDBCTxDataSource/' + txdsName)
   if txds != None:
    txds.addTarget(cluster)

 wlst.cd('Application/' + 'JWSQueueTransport')

 ejb = wlst.getTarget('EJBComponent/' + 'QueueTransportEJB')
 if ejb != None:
   ejb.addTarget(cluster)
 wlst.cd('/')

　　让我们仔细看看该脚本的其中一部分：

dsList='p13n_trackingDataSource','p13nDataSource'
for dsName in dsList:
  ds = wlst.getTarget('JDBCDataSource/' + dsName)
  if ds != None:
  ds.addTarget(cluster)

　　该脚本要做的就是循环遍历DataSource的名称，我们应该将这些DataSource的目标设定为新的wlpCluster。对于每个DataSource，首先应该调用getTarget()方法来获得DataSource对象，然后将wlpCluster添加到其目标列表中。

　　 可以从wlst CodeShare项目中下载完整的示例脚本。

　　 除了配置域级别的资源，还需要支持关键生产数据的自动供应（或在有时被调用时执行的迁移），这类数据包括WebLogic安全区（security realm）、WebLogic Portal元数据和WebLogic Integration元数据。有关的更多信息，请参阅“生产数据配置”一节。

用例：快速生产复制

　　该用例描述了一个特殊的供应场景，在该场景中，客户已经有了一个在管理服务器上正确配置的正在运行的生产域，并且需要将相同的配置复制到WebLogic集群域中的许多托管服务器中。在多台远程机器上运行基于GUI的工具非常单调乏味，并且很容易出错。基于模板的方法似乎非常适合用来自动化这个复制过程。我们将举例说明如何使用Domain Template Builder来捕获生产域中的东西。

　　 假设这个假定的域是一个WebLogic Integration集群域，叫做wlicluster，客户最初使用Configuration Wizard在WLI域模板中创建了这个域。随后，又部署并配置了以下资源来支持应用程序的需要：

• 一个称为tradeHubApp.ear的应用程序，该应用程序使用了消息代理通道和事件生成器，并调用了一个第三方适配器。
• 一个称为egDistQueue的分布式队列，以及它对应的队列成员。
• 一个称为tradeHubJMSEG的JMS Event Generator，它与egDistQueue和一个现有通道文件有关。
• 一个称为kodo的第三方适配器，它的目标是集群。

　　现在，我们需要创建一个定制域模板来捕获完整的配置。默认情况下，Template Builder会包括这个域直接引用的文件。可以通过Add File窗口（参见图2），将已部署好的应用程序所需的其他文件（如JMS Event Generator的jar文件和第三方适配器文件）添加到模板中。

图2. 在创建定制域模板时添加文件

　　 对于前面提到的生产域，我们需要添加以下文件：

• 将<wliconfig>文件夹添加到<Domain Root Directory>（注意，不必在<wliconfig>文件夹下包含托管服务器的子文件夹）。
• 将<script>文件夹添加到<Domain Root Directory>。
• 将对应于tradeHubJMSEG事件生成器的jar文件（即WLIJmsEG_tradeHubJMSEG.jar）添加到<Domain Root Directory>。
• 将DefaultAuthorizer.ldift文件添加到<Domain Root Directory>，因为它定义了默认授权角色以及用来访问消息代理通道的策略。
• 将适配器工具所在的文件夹添加到<Application Root Directory>/wlicluster。

　　上面展示了域和应用程序资源的一个列表，该列表已经捕获在域模板中。如果还有其他资源（比如安全角色和策略），那么还需要单独使用WebLogic Platform提供的其他工具来捕获这些资源。下一个用例举例说明了如何使用这些工具来供应生产数据。

用例：生产数据供应

　　通常，WebLogic Platform生产环境中的数据由安全角色、缓冲策略、门户元数据、贸易合作伙伴管理（TPM）数据和其他通常存储在各种持久性存储器（如嵌入式LDAP、外部数据库和储存库文件）中的数据组成。该用例的重点在于自动化生产数据的供应过程。

WebLogic域级别的表

　　每个WebLogic域模板（除了WebLogic Server域模板）都有一组预定义的SQL文件，在启动服务器之前，需要将这些文件加载到目标数据库中。例如，WebLogic Portal域模板定义了Content Management Database Object和WSRP Object表，在启动WebLogic Portal域之前，需要加载这两个表。这些域级别的表将被加载到生产数据库中，并被域中的所有服务器共享。可以通过Configuration Wizard，在创建域期间加载这些表，或者通过WLST Offline中的loadDB()函数加载这些表，以下脚本对此进行了描述：

readTemplate('D:\\common\templates\domains\platform.jar')
existingPoolName = 'cgJMSPool-nonXA'
cd ('/')
cd ('JDBCConnectionPool/' + existingPoolName)
cmo.setDriverName('oracle.jdbc.driver.OracleDriver')
cmo.setUserName('E2EDCDB')
cmo.setPassword('E2EDCDB')
cmo.setURL('jdbc:oracle:thin:@::')
loadDB('9i',existingPoolName)
closeTemplate()

WebLogic安全区

　　每个WebLogic Platform域都是在一个默认安全区中配置的，通常存储在嵌入式LDAP中。每个安全区都由一组已配置的安全提供者、用户、组、安全角色和安全策略组成。可以定制默认安全区来支持各种安全需要，比如说，替换一个安全提供者和添加用户。为了支持将安全数据从一个安全区迁移到另一个安全区，WebLogic Platform通过WebLogic Console和MBean接口提供了一些特殊的导出/导入工具。

BEA WebLogic Enterprise Security 策略数据

　　BEA WebLogic Enterprise Security（WLES）(现称为AuqaLogic Enterprise Security)服务使用一些不同种类的策略来保护应用程序和资源。为了使客户轻松地将策略数据转移到生产环境中，WLES提供了Policy Export/Import工具。策略导出工具允许您将数据从策略数据库输出到叫作“策略文件”的文本文件中。也可以使用Policy Import工具将这些策略文件导回同一策略数据库或另一个策略数据库。这些工具有一些命令行接口，可以很轻松地集成这些接口来支持自动供应。

WebLogic Portal元数据

　　在配置和定制WebLogic Portal应用程序时，有各种门户对象（比如权利和委托管理），这些对象存储在嵌入式LDAP和门户数据库中。通过筛选不应传播的元数据和遗弃不应更新的不受影响的目标数据的能力，WebLogic Portal Propagation Utility允许门户管理员有选择性地将数据从一个阶段移动到另一个阶段。注意，该工具目前在dev2dev上，它在WebLogic Platform的下一个版本中也将受到支持。

WebLogic Integration TPM 数据

　　贸易合作伙伴管理（Trading Partner Management ，TPM）数据包括贸易合作伙伴配置文件、来自keystore的证书、服务定义和服务配置文件。Bulk Loader是一个命令行工具，可以用它来导入、导出和删除TPM数据。Bulk Loader导入的是XML表达形式的TPM数据，导出的是XML文件。

bulkloader [-verbose] [-config <blconfig.xml>] [-wlibc]

 -import <data.xml>

 -export <data.xml> [-nokeyinfo] [-select <selector.xml>]

BEA Liquid Data for WebLogic服务器设置

　　BEA Liquid Data for WebLogic(现称为AquaLogic Data Service Platform)服务器设置包括Data Sources、Custom Functions和Stored Queries。这些设置存储在<ldrepository>文件夹下的储存库文件中。以下Ant脚本描述了如何调用Liquid Data工具从Ldconfig.xml文件导入服务器设置。相同的类也支持服务器设置的导出。

<java classname="com.bea.ldi.util.CfgImpExp" fork="true">
 <classpath>
  <pathelement location="<WL_HOME>/server/lib/weblogic.jar"/>
  <pathelement location="<REPOSITORY_DIR>/import-export-tools/CfgImpExp.jar"/>
  <pathelement location="<WL_HOME>/liquiddata/server/lib/wlldi.jar"/>
 <pathelement location="<WL_HOME>/liquiddata/server/lib/castor-0.9.3.9.jar"/>
 <pathelement location="<WL_HOME>/liquiddata/server/lib/xercesImpl.jar"/>
 <pathelement location="<WL_HOME>/liquiddata/server/lib/APP-INF/lib/LDS.jar"/>
 </classpath>
 <arg line="<ADMIN_ADDR> <ADMIN_PORT> <ADMIN_USERNAME> <ADMIN_PASSWORD> 
 import <DOMAIN_HOME>/ldrepository/import_export/LDconfig.xml"/>
</java>

特定于应用程序的表

　　在生产模式域中，WebLogic Server不会在部署应用程序时尝试自动供应所依赖的资源。例如，如果应用程序包含会话式Web service或Entity Bean，那么在部署应用程序之前，需要加载会话状态表和Entity Bean表。因为知道需要供应的内容，所以很容易通过脚本自动供应这些内容。关于加载会话状态表和Entity Bean表的更多信息，请参阅前一篇文章。

　　 自动化生产数据配置的需求已经通过典型平台环境中的各种生产数据得以证实。其中一些数据可以通过WLST Online/Offline脚本进行供应，而其他一些数据则可以通过WebLogic Platform提供的特殊工具（例如，Portal Propagation工具和WLES Import/Export）来导出或导入。在极少数情况下，可能需要使用数据库级别的工具来导出或导入存储在外部数据库实例中的关键信息。

差量供应

　　随着生产环境的发展，可能需要对现有环境进行更进一步的定制。例如，管理员可能需要更改安全区中的一些安全提供者，或者更新现有缓存策略。这有时也称为差量供应。大多数差量供应操作都是通过WebLogic Console和MBean调用来完成的。也可以使用基于模板的方法或基于WLST的方法来支持各种差量供应需要。

　　 例如，可以使用WLST Online将一个额外的JMS队列作为分布式队列进行配置，并跨集群设置相应的物理队列成员。wlst CodeShare项目中的一个代码示例演示了如何将Application AsyncRequest Queues作为Distributed Queues添加到Cluster中。另一个代码示例阐述了如何通过WLST Online配置嵌入式LDAP或外部LDAP。

　　 WebLogic Console和WLST Online脚本支持活动服务器的差量供应，而WLST Offline和扩展模板可以用来供应附加的应用程序和服务，比如JDBC或JMS组件，以及启动/关闭类。要应用扩展模板，则需要关闭服务器。以下WLST Offline脚本演示了一个差量供应场景，在该场景中，首先创建的是WebLogic Workshop域，而WebLogic Integration域模板被应用于使用addTemplate()和updateDomain()操作的WebLogic Workshop域。结果，就有了一个既支持WebLogic Workshop功能又支持WebLogic Integration功能的域。

readTemplate('<WL_HOME>/common/templates/domains/wlw.jar')
cd('/')
cd('Security/mydomain')
cd('User/weblogic')
cmo.setPassword('weblogic')
setOption('OverwriteDomain', 'true')
writeDomain('<BEA_HOME>/user_projects/domains/wlw-wli')
closeTemplate()
readDomain('<BEA_HOME>/user_projects/domains/wlw-wli')
setOption('ReplaceDuplicates','false')
addTemplate('<WL_HOME>/common/templates/applications/wli.jar')
updateDomain()
closeDomain()

结束语

　　通过几个阶段来自动化WebLogic Platform应用程序供应，需要完全了解每个阶段的特定需求，并采用正确的工具来实现这个自动化过程。在本文中，我们重点研究了基于模板的方法和基于WLST的方法，并举例说明了如何有效使用这些方法来自动化一些常见的供应场景。

文章来源于领测软件测试网 https://www.ltesting.net/