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

摘要

BEA WebLogic Platform应用程序供应（provisionin）是一个这样的过程 准备提供一个有效的WebLogic Platform环境来支持已部署好的应用程序的后续应用 在前一篇文章中 我们介绍了经过几个阶段将WebLogic Platform 应用程序从开发升级到生产阶段时 我们能从中获得什么 在本文中 研究的重点是使用可用于WebLogic Platform产品的工具来自动化每个阶段的应用程序供应 这将允许您自动创建运行WebLogic应用程序所需的环境

简介

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

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

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

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

挑战

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

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

在典型的开发阶段 几个开发人员将同时为一个项目工作 每个开发人员从事不同的模块研究 这些开发人员可能拥有作为沙箱的自己的工作域（开发模式 带有本地数据库的单服务器） 并且可以使用源代码控制工具来促进团队开发 在开发模式域中 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 p n_trackingDataSource Target wliCluster ) unassign( JDBCDataSource p nDataSource 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= p n_trackingDataSource p nDataSource 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= p n_trackingDataSource p nDataSource 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窗口（参见图 ） 将已部署好的应用程序所需的其他文件（如JMS Event Generator的jar文件和第三方适配器文件）添加到模板中

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

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

将<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:\ \mon\templates\domains\platform jar ) existingPoolName = cgJMSPool nonXA cd ( / ) cd ( JDBCConnectionPool/ + existingPoolName) cmo setDriverName( oracle jdbc driver OracleDriver ) cmo setUserName( E EDCDB ) cmo setPassword( E EDCDB ) cmo setURL( jdbc:oracle:thin:@ :

: ) loadDB( i 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允许门户管理员有选择性地将数据从一个阶段移动到另一个阶段 注意 该工具目前在dev dev上 它在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= 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 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>/mon/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>/mon/templates/applications/wli jar ) updateDomain() closeDomain()

结束语 lishixinzhi/Article/program/Java/hx/201311/26016

首先要将程序包放到相应目录：

1一般weblogic的存放目录是bea\user_projects\domains\yourdomain\applications文件夹下；

weblogic中应用程序部署方法：

1部署的配置在\bea\user_projects\domains\yourdomain\configxml中修改，如下为EJB的部署配置：

<Application Name="IBSSMSFastFind"

Path="e:\bea\user_projects\domains\yourdomain\applications"

StagingMode="nostage" TwoPhase="true">

<EJBComponent Name="IBSSMSFastFind" Targets="yourserver" URI="IBSSMSFastFindwar"/>

</Application>

注：你想要确认你当前已经部署好的程序放在哪的话，可以查看该configxml文件，搜索war包的名字，可以找到改程序包的URI，以跟踪找到存放目录。

2也可以到weblogic控制台配置，点选左边导航树的路径：域名-Deployments-相应的部署类型：选择你需要配置类型的应用程序，在右边选择Deploy a new XXX Module配置部署即可

一般来说我们都是在应用程序里面配置jdbc数据源，因为这样可以脱离web服务器的设置，比较容易移植，但是也有情况使我们必须使用web容器配置数据源，例如如果要用的多个数据库时，在中间件中配置数据源就比较方便。

先讲下如何在weblogic中配置数据源，以weblogic932为例。启动weblogic，进入console页面， 在左侧Domain Structure面板选择Services，然后选择jdbc—-Data Sources，在这里将会显示现有的所有数据源，点击页面左上角的Lock&Edit，然后点New来新建一个数据源，Name跟JNDI Name由用户命名，一般用相同的，如test，Database Type则是选择你要连接的数据库类型，驱动会自己帮你选择，一般不用做修改。接下来的，用户都应该很熟悉，无非是ip地址，sid，用户名密码等。完成后将在DataSource列表里看到刚新建的数据源，jndi name就是我们待会再Spring中要用到的。在数据源configuration–connection pool中可以配置连接池的初始大小，以及最大大小，以及每次增长长度。

在Spring中ApplicationContextxml中配置如下，一个jndiTemplate，里面可以设置一些属性，这里就不再介绍， dataSource中主要写对jndi的name就ok了，这样这个dataSource就可用了。

以上就是关于自动化WebLogic平台应用程序供应全部的内容，包括:自动化WebLogic平台应用程序供应、在WEBLOGIC中如何部署一个EJB应用：、springmvc使用weblogic发布，怎么配置等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！