使weblogic服务器的资源配置自动化(转)

这篇文章中,你已经看到如何将Weblogic服务器资源集成到应用程序中.完成这些工作借助于资源配置的XML文件，以及使用配置器任务按照必要的资源配置去布署。同时我们也看到了,如何使得我们的资源配置文件独立与环境.这些方法有助于机构完全自动化J2EE应用程序的部署和反部署工作


在Weblogic服务器上使用WLST和Ant进行资源配置

概述

企业级的Java程序如果没有进行程序服务器的配置，例如链接池、数据源、JMS队列和安全等的配置，想要准确运行是不太可能的。而这些配置都是在应用程序部署之前进行正确无误地配置的。然而，在考虑程序可能部署到多环境的情况下，这些配置工作就变得复杂起来。自动而集成的资源配置提供了这种便利，尤其是出于系统维护导致系统的配置发生变化或突然出于性能的需要需将程序部署到一个新的服务器上。这篇文章阐述的就是Weblogic服务器下借助 Weblogic的脚本语言和Ant实现这种资源配置自动化。

每种可部署的J2EE组件，要在应用服务器运行准确无误都必须进行相应的配置。对于使用Weblogic服务器的开发人员来说，这种配置可以通过控制台来完成，也可以通过Weblogic Ant的wlconfig和wldeploy两个任务，或直接使用命令行工具weblogic deployer。Ant任务和命令行工具因为依赖于具体的环境特性，所以在Weblogic9.0下，都建议尽量减少这些工具的使用。

因为开发人员与应用程序之间并没有一个统一的维护和沟通配置信息的方式，从而导致一些自定义的脚本配置和手动配置并存。自定义的脚本配置难以维护，而手动配置常常导致错误的发生，获取一个流畅的传播和释放机制对J2EE而言显得艰难无比。在应用程序需部署到多样环境的下（开发，测试和产品），这变得更加复杂，因为这些多样环境使得程序很难做到完全地独立于环境。并且，如果整个程序的维护信息本身并不规范的话，突然变动程序目标将导致过程变得冗长乏味。因此，每一个程序都必须始终如一的将配置信息保持环境独立。也正据于此，一种可以自动读取配置信息并在服务器上进行自动配置的工具，将大大地提供便利，而这种工具也将成为程序部署的一个部分。这样的一个工具在加强标准和指引中起到至关重要的作用。

这篇文章提供了一个样例，在此样例中配置信息得以通过程序来维护。它同时也提供了以Ant任务的方式执行读取配置信息和在服务器部署的工具。此样例已经编译测试过，测试的环境为J2SE 1.4.2_03和Weblogic 8.1，同时也兼容Weblogic7.0，8.1和9.0。

版权声明：任何获得Matrix授权的网站，转载时请务必保留以下作者信息和链接
作者:Tanmay Ambre;leniz
原文:http://www.javaworld.com/javaworld/jw-10-2005/jw-1010-wlst.html
Matrix:http://www.matrix.org.cn/resource/article/44/44624_Weblogic.html
关键字:Weblogic;资源配置

Weblogic服务器配置的种类

J2EE 程序通常使用链接池，数据源，Java信息服务（JMS），储存技术（文件储存或数据链接储存），JMS服务，JMS目标（队列和主题），以及分布式 JMS目标。其中部分资源的创建是处于域级的。有些时候应用程序可以共享配置信息，有些时候却不是那样。这些共享的配置信息，在应用程序反部署的时候并不允许被删除。这篇文章所述的Ant任务和配置需要非常谨慎的处理这种情况,即共享配置不能够被删除。同时，也不能覆盖掉那些已经存在的配置信息。

资源配置和WLST

Weblogic 针对每个配置创建相应的管理Bean（MBeans），并通过java管理扩展（Java Managerment Extensions（JMX））来管理这些Mbeans。所以，每一个配置都有一个对应的MBean 被创建和部署。创建这些MBean 所必须的参数有:它的名字，类别和其它一系列属性。

WLST（Wblogic Scripting Tool）是一个脚本工具，它使得用户可以访问并操作MBean，类似于在文件系统中对普通文件的操作。这是一个脚本接口，使得开发人员可以借此配置 Weblogic服务器并与之交互。WLST与Weblogic 9.0相应而生，提供了在线和离线两种工作方式。当在线操作时，WLST可以以以下三种模式工作：
+脚本模式
+交互模式（命令行和GUI）
+Java封装模式

这篇文章重点放在Java封装模式上。这种模式因为可以在不需要开发人员了解WLST的脚本语法的情况下，用基于Java的工具（例如 Ant任务）很便捷地创建出WLST环境下的配置。

创建和维护资源配置

最好的维护资源配置的方法就是使得资源配置模块化。每一个可部署的应用程序都必须维护它自身的资源配置，所以这也使得我们很容易决定哪些资源是程序必须的。应用程序的资源配置可以跟着程序架构被带到各种不同的环境中。因此，针对一个机构的J2EE多环境下的程序资源配置变得易于维护和管理。

再也找不到比xml格式更适合于保存配置的了！这种格式可以通过结构化的方式来维护配置并通过模式提供有效性检测。XML文件保存着名字，类型和Weblogic服务器资源的一系列属性。你所需要注意的无非只有如下一些信息。
+MBean的类型（比如 JDBCConnectionPool）
+MBean中必须设置的属性

类型都不会改动，而通常每个MBean必须设置的属性也无外乎那些。因此完全有可能创建一个通用的配置模板，并将它结合到一些通用的IDE开发工具中（比如 IDEA和Eclipse）。XML文件中使用的值都必须独立于环境，并且这个XML文件必须要有版本控制。在程序发放阶段也必须包含它们的自己的资源配置。

参看资源部分的源码，这些源码是依据这篇文章提出的XML模式定义的，是配置文件的一个样例。现在把它称为Weblogic服务器资源配置XML。

资源配置的配置器任务

一旦应用程序开始维护它的资源配置，你需要定义一个Ant的常规任务，这个任务将执行如下的操作。
+读取Weblogic应用程序服务器的资源配置XML文件
+可以读取环境变量和其它一些来自或文件或URL或资源的默认的属性
+在给定的目标服务器上运行配置文件
+配置文件部署失败将触发程序的部署失败

这些配置任务可以通过任何一个开源的XML绑定框架(Castor, XMLBeans,或Java Architecture for XML Binding)来解析XML文件。在例子中，我使用的是XMLBeans.接下来任务必须产生一个WLST兼容的脚本，并触发它。为了在线运行这个脚本，我们必须连接到管理服务器，并在这个服务器上触发配置。下列的是配置任务的输入参数。
+url：  管理服务器的URL
+username：管理服务器的用户名
+password：管理服务器的密码
+configfile: 配置文件路径
+action: 动作(创建，删除，部署，反部署) 


配置任务首先解析配置文件。接着连接到一个域管理服务器.依据输入参数,按照XML文档给定的参数将产生一个WLST脚本,并以嵌入的模式执行此脚本.在完成所有配置的部署之后,这个task将优雅从容的断开与管理服务器的链接

生成的WLST脚本将首先检测bean是否存在,如果存在的话,将不创建配置.配置器任务也同时检查依赖性.(比如数据源是依赖于数据链接池的).在删除阶段,也将进行依赖性检测已确定删除万无一失.

参看资源部分的配置器源代码样例.

Ant 任务示例

Ant任务名称为com.tanmayambre.wls.tools.anttaskdefs.
WLSTConfigurator.它拥有如下的输入参数.
+url: 管理服务器 的URL
+username: 管理服务器 的的用户名
+password: 用户密码
+configFile: 配置文件路径
+propertiesFile: 包含环境变量的属性文件
+action: 创建,删除,部署,反部署,重部署

部署与反部署动作都将内在地先触发创建动作去创建一份配置.属性可以是环境变量
示例:


Xml代码
<target name="create-configuration" depends="init-demo"> 
   <echo message=">>>>>> Creating the Configuration"/> 
   <wlsconfig 
      username="${weblogic.user}" password="${weblogic.passwd}" 
      url="${weblogic.url}" 
      configFile="${basedir}/samples/wlsconfig/example.xml" 
      propertiesFile="${basedir}/samples/wlsconfig/environment.properties" 
      action="create"/> 
</target> 
 
<target name="delete-configuration" depends="init-demo"> 
   <echo message=">>>>>> Deleting the Configuration"/> 
   <wlsconfig 
      username="${weblogic.user}" password="${weblogic.passwd}" 
      url="${weblogic.url}" 
      configFile="${basedir}/samples/wlsconfig/example.xml" 
      propertiesFile="${basedir}/samples/wlsconfig/environment.properties" 
      action="delete"/> 
</target> 
 
<target name="deploy-application" depends="init-demo"> 
   <echo message=">>>>>> Deploying the application"/> 
   <wlsconfig 
      username="${weblogic.user}" password="${weblogic.passwd}" 
      url="${weblogic.url}" 
      configFile="${basedir}/samples/wlsconfig/example.xml" 
      propertiesFile="${basedir}/samples/wlsconfig/environment.properties" 
      action="deploy"/> 
</target> 
 
<target name="undeploy-application" depends="init-demo"> 
   <echo message=">>>>>> UNDeploying the application"/> 
   <wlsconfig 
      username="${weblogic.user}" password="${weblogic.passwd}" 
      url="${weblogic.url}" 
      configFile="${basedir}/samples/wlsconfig/example.xml" 
      propertiesFile="${basedir}/samples/wlsconfig/environment.properties" 
      action="undeploy"/> 
</target> 
 
<target name="redeploy-application" depends="init-demo"> 
   <echo message=">>>>>> Redeploying the application"/> 
   <wlsconfig 
      username="${weblogic.user}" password="${weblogic.passwd}" 
      url="${weblogic.url}" 
      configFile="${basedir}/samples/wlsconfig/example.xml" 
      propertiesFile="${basedir}/samples/wlsconfig/environment.properties" 
      action="redeploy"/> 
</target> 

<target name="create-configuration" depends="init-demo">
   <echo message=">>>>>> Creating the Configuration"/>
   <wlsconfig
      username="${weblogic.user}" password="${weblogic.passwd}"
      url="${weblogic.url}"
      configFile="${basedir}/samples/wlsconfig/example.xml"
      propertiesFile="${basedir}/samples/wlsconfig/environment.properties"
      action="create"/>
</target>

<target name="delete-configuration" depends="init-demo">
   <echo message=">>>>>> Deleting the Configuration"/>
   <wlsconfig
      username="${weblogic.user}" password="${weblogic.passwd}"
      url="${weblogic.url}"
      configFile="${basedir}/samples/wlsconfig/example.xml"
      propertiesFile="${basedir}/samples/wlsconfig/environment.properties"
      action="delete"/>
</target>

<target name="deploy-application" depends="init-demo">
   <echo message=">>>>>> Deploying the application"/>
   <wlsconfig
      username="${weblogic.user}" password="${weblogic.passwd}"
      url="${weblogic.url}"
      configFile="${basedir}/samples/wlsconfig/example.xml"
      propertiesFile="${basedir}/samples/wlsconfig/environment.properties"
      action="deploy"/>
</target>

<target name="undeploy-application" depends="init-demo">
   <echo message=">>>>>> UNDeploying the application"/>
   <wlsconfig
      username="${weblogic.user}" password="${weblogic.passwd}"
      url="${weblogic.url}"
      configFile="${basedir}/samples/wlsconfig/example.xml"
      propertiesFile="${basedir}/samples/wlsconfig/environment.properties"
      action="undeploy"/>
</target>

<target name="redeploy-application" depends="init-demo">
   <echo message=">>>>>> Redeploying the application"/>
   <wlsconfig
      username="${weblogic.user}" password="${weblogic.passwd}"
      url="${weblogic.url}"
      configFile="${basedir}/samples/wlsconfig/example.xml"
      propertiesFile="${basedir}/samples/wlsconfig/environment.properties"
      action="redeploy"/>
</target>

实现环境独立性

某些运行期的配置会因为运行环境的不同而有所不同.比如链接数据库服务器的用户ID和用户密码在测试阶段和实际运行阶段可能不一样.对开发者而言,针对每种环境都要编写一个配置文件将是一个冗长乏味的工作.他们要考虑各种各样的环境下的配置可能.
所以不太可能这样做,一个更为有效的方法将抽象出配置文件中的信息,并将这些信息作为一个独立的属性文件(或作为环境变量).此文件将由系统管理员进行维护,而开发者所要做的无非只是从这些属性文件中提取属性值
配置器使用一个属性读取器(com.tanmayambre.wls.tools.utils.
PropertiesReader)读取不同环境的属性值,那些属性值将依照如下的顺序依次读取.后面读取的属性将覆盖之前读取的同名的属性.
+系统属性(System properties)
+环境变量(Environment variables)
+来自文件的属性(Properties from a file

环境变量可以声明为常用变量,比如环境名称或域名称.属性文件包含默认的值,比如,用户ID,用户密码,最大容量,最小容量.此文件关联着环境,所以单独的属性文件将对照不同的环境进行维护.

资源配置的XML文件不允许使用任何特殊环境下的变量,而必须使用那些声明为系统的或环境的变量,或特定环境下属性文件的某属性值.

这种解决方案的好处在于,无论开发者或是程序的编译者只需一次配置好所有环境下的配置.示例代码包含了一个这样的属性读取器,这个读取器可以读取环境相关变量.配置器使用这个属性读取器替换资源配置XML中的环境变量.此解决方法类似于Maven读取环境变量所使用的方法.

资源命名约定

因为我们要使创建的配置文件具有环境独立性，所以必须制定相应的命名规则来规范程序员和应用程序开发者对资源的命名.这也使得在跨平台使用时有统一的标准, 有助于有效的维护系统.命名规格必须加于公布,文档化,并由开发者和部署人员达成共识.下列有几条关于命名规范的的指导:
+域级资源,比如数据链接池,JMS存储库等, 因为部署于跨服务器实例,所以不应该使用依赖特定服务器的变量.
+在命名时使用匈牙利字符命名方式
+根据应用程序命名的资源做为特定应用资源。


处理过程

下列步骤,概要的说明了开发和维护配置的过程.
1.针对每个环境,创建一个包含环境特性的属性文件(一次性).
2.发布资源命名约定的规范方针
3.将创建Weblogic服务器资源配置文件, 这是程序开发的一部份
4.在builder.xml中, 将创建和删除配置以及布署和反布署程序与ant任务相结合, 确保布署相关的任务依赖于资源配置任务。
5.在版本控制系统里, 检查Weblogic服务器配置和build.xml。
6.告知应用程序开发者, 环境变量已经可用.
7.在发布阶段,先发布Weblogic服务器资源配置.
8.使用ant的任务来完成部署工作.配置器任务能够创建资源配置,同时也能不熟应用程序.


优点

所建议的解决方案可以自动化以及维护Weblogic服务器配置.这些步骤具有如下的优势:
+对每个应用程序,模块化Weblogic服务器配置.部署应用程序变得异常简单.
+一种结构化的维护配置的方法.
+Weblogic9.0 使得WLST官方化
+创建配置文件只需要很少的工作量
+因为工具使用的是Ant的任务的方式,所以可以很方便地将此工具集成到Maven.


结论
这篇文章中,你已经看到如何将Weblogic服务器资源集成到应用程序中.完成这些工作借助于资源配置的XML文件，以及使用配置器任务按照必要的资源配置去布署。同时我们也看到了,如何使得我们的资源配置文件独立与环境.这些方法有助于机构完全自动化J2EE应用程序的部署和反部署工作,同时缩小错误出现的范围.如果对资源配置的XML文件加上版本控制的话,将更有利于对程序资源变动的追踪.