在本系列的上一篇文章中，我们介绍了如何实现SOA测试环境的自动化安装，这一章我们将介绍如何自动每天定时安装新的待测SOA组件。

　　SOA的体系架构中很强调“分布式”这个概念，不仅是构架的分布式，开发模式也体现了“分布式”的概念，SOA的开发团队经常分布于全球不同的角落，比如：Service层的开发位于中国、测试组位于中国、UI层的开发位于美国。这种分布式的时区差异导致了如果美国出Build的时间是北京时间的凌晨4：00，中国测试团队每天早上上班的第一件事就是从美国的服务器中取下Build然后把它部署到服务器上，重复的劳动不仅耗费大量的人力物力，且由于SOA组件的配置比较复杂，手工配置很容易出错，加大了测试团队的风险。

　　除了开发和测试的分布式模式带来的挑战之外，由于SOA是一个基于服务的构架，服务粒度的细化导致在一个企业级SOA应用中会有大量的服务需要发布出来，可能导致的部署的EAR包比传统构架的多，体系结构也比较复杂。有一个真实客户的例子，在采用SOA构架后其IT架构包括如下几部分：

　　·50个Websphere的集群(cluster)，200个应用服务器(application server)在40个节点(node)上。
　　·整个应用程序包含26个EAR包在11个独立的实例上(instance)，这就意味这11*26的部署工作。
　　·12个SIBus, 2个JMS queues，每个集群(cluster)一个数据源(dada source)。

　　管理和配置这个复杂的环境无论对测试人员还是客户来说都是一个噩梦，自动化部署不仅可以大大提高测试的工作效率、减少项目风险而且可以向客户提供一种“one click”的解决方案，对客户屏蔽诸多技术的细节和配置的复杂性，提高客户对SOA技术的忠诚度。

　　本文将根据我们在项目中的经验总结出一种每天按需求自动下载、部署、配置Build的自动化方案。

　　自动下载SOA组件

　　SOA的分布式开发环境

　　下图是一个很典型的SOA的开发和测试环境。

                

　　图2.1典型的SOA开发环境
 
　　在图中所示的这种软件开发环境中，Service开发团队和测试团队位于中国，UI开发团队位于美国，Service开发团队和UI开发团队都有自己的Build Server，用于存放自己每天所发布的Build，测试团队有自己的一套SOA测试环境，它需要每天安装和配置SOA的Service组件和UI组件用于测试。本章将介绍测试团队如何在这种分布式环境中实现自动化测试。

　　自动获取Build

　　在当前的脚本语言中Ant和Python是最流行的两种语言：Python是一种非常灵活强大的动态脚本编程语言，具有完整的面向对象特性；Ant是纯Java语言编写的，具有良好的跨平台性，由于Ant的构建文件时以XML书写，容易维护且结构清晰。我们将结合两种语言各自的优点运用于我们的脚本之中。我们以Windows为例，整个自动化脚本的目录结构如下所示：

                      

　　图2.2自动化脚本的目录结构
 
　　有几个目录需要重点介绍一下：

　　EAR：是我们存放下载后Build的路径，他有两个子目录service和UI分别用于存放SOA的服务层和用户界面层的Build。

　　Lib: 存放应用程序所需要的共享库，某些应用程序部署上后需要配置共享库。

　　在BuildScript目录下有一个deployBuild.bat文件，一个buildToTest.py文件。

            
　　
　　图2.3 BuildScript目录下的文件
 
　　deployBuild.bat文件主要用于定义一些WPS profile的位置、Build放置的位置、WPS登录用户名和密码等信息。

                 

　　图2.4 deployBuild.bat文件的内容
 
　　文件中前6行都是运行环境的配置信息：

　　pathProfile: WPS的profile路径。

　　pathProcServer: WPS的安装路径。

　　pathBuildService: service层build的放置目录。

　　pathBuildUI: UI层build的放置目录。

　　authStmt: WPS的用户名和密码，在启动了安全性后用命令行控制WPS时需要提供认证信息，在这个示例中我们的用户名和密码都是IBM。

　　第七行是调用buildToTest.py的python文件，后面的数字(2007102202)是要安装build的版本号，这个版本号需要开发组和测试组共同协商，确定一个build的编号规则，自动脚本下载的Build号将以此为唯一标识。一般来说可以采用日期+序号的方法，如果所示的2007102202就表示的是2007年10月22日的第二个build。

　　buildtoTest.py文件主要定义了一些自动化的主要步骤。

import os, os.path
from time import strftime,localtime,ctime
import urllib
import smtplib
import sys
top_dir = os.getcwd() 
currentTime = strftime(“%Y%m%d”, localtime())
# Get Ears
retEars = os.system(‘ant -Dbuild.number=%s -buildfile %s/otherTargets.xml ftp-get-ears ‘
 %(sys.argv[1] ,top_dir + ‘/Script’))
# Uninstall and install UI
retunInstall = os.system(‘%s/uninstallAllUI.bat’ %(top_dir + ‘/Script’))
retinstall = os.system(‘%s/installAllUI.bat’ %(top_dir + ‘/Script’))
# Uninstall and install services
retunInstall = os.system(‘%s/uninstallAllApps.bat’ %(top_dir + ‘/Script’))
retinstall = os.system(‘%s/installAllApps.bat’ %(top_dir + ‘/Script’))
 
　　我们在python中定义了3个重要的任务：

　　GetEars: 该步骤用到了ant脚本(otherTargets.xml)的ftp-get-ears下载build到本地目录中，关于otherTargets.xml中ftp-get-ears的编写，我们在后面会做一个示例性的介绍。

　　Uninstall and install UI: 该步骤分别调用了一个卸载旧的UI组件(uninstallAllApps.bat)和装载新的UI组件(installAllUI.bat)的批处理命令, 卸载UI的脚本我们将在后面介绍一个自动化框架。

　　Uninstall and install services: 该步骤和上面基本相似，不同之处是该步骤卸载和安装的对象是service的组件，卸载Service的脚本我们将在后面介绍一个自动化框架。

　　otherTargets.xml的一个下载Build的代码片断如下所示：

<target name=”ftp-get-ears”>
<delete dir=”../Build/”/>
  <mkdir dir=”../Build/”/>
  <ftp action=”get”
   server=”127.0.0.1″ 
   remotedir=”/www/Demo /${build.number}/”  
   userid=”IBM”
   password=”IBM”>
   <fileset dir=”../Build”>
    <include name=”**”/>
   </fileset>
  </ftp> 
</target>

　　这个target由以下几个操作组成：

　　1. 删除Build文件夹：因为每天的build都会放入这个目录，为了保证该文件夹下的build都是最新的我们会在下载之前将该文件夹删除。

　　2. 新建Build文件夹：用于存放即将下载的新build。

　　3. 下载Build：我们在<ftp action=”get”>这个操作里面定义了FTP下载所需要的若干参数：

　　·server: FTP服务器的IP地址。
　　·remotedir: FTP服务器存放build的路径。
　　·userid: 登陆FTP的用户名。
　　·password: 用户名所对应的密码。

　　大家从这段代码可以看出Ant语言的优点：非常简洁，有强大的类库，能用简短的程序完成复杂的操作。如果还要加入其它的任务，只需要加入<target></target>代码片段。

　　自动安装和配置SOA组件

　　当待测试的新SOA组件从各个开发团队的FTP下载到本地服务器之后，我们就要将它们自动部署到测试服务器上，我们将采用WebSphere脚本配置和管理SOA组件。

　　wsadmin简介

　　WebSphere Application Server wsadmin工具提供运行脚本的能力, 支持通过运行脚本来自动化环境的配置任务。wsadmin工具支持整个范围的产品管理活动。

              

　　图2.5 WebSphere Application Server脚本解决方案
 
　　wsadmin工具支持两种脚本语言：Jacl和Jython。当您使用脚本时，有五个对象可用：

　　AdminControl：用于运行操作命令。

　　AdminConfig：用于运行配置命令以创建或修改WebSphere Application Server配置元素。

　　AdminApp：用于管理应用程序。

　　AdminTask：用于运行管理命令。

　　Help：用于获取一般帮助。

　　脚本使用这些对象与运行在WebSphere Application Server进程中的MBean通信。MBean是表示Java管理扩展（JMX）资源的Java对象。JMX是附加于Java 2 Platform Standard Edition（J2SE）的可选软件包。JMX是提供简单和标准方法来管理Java对象的一种技术。

　　要使用脚本执行任务，必须首先执行以下步骤：

　　1．选择一种脚本语言。wsadmin工具仅支持Jacl和Jython脚本语言。Jacl是缺省指定的语言。如果要使用Jython脚本语言，使用-lang选项或者在wsadmin.properties文件中指定。

　　2．按脚本或概要文件，作为单个命令，交互地启动wsadmin脚本客户机。

　　启动wsadmin客户机方法是: 进入特定概要文件所在的bin目录profile_root/bin，如果启用安全性，执行如下命令。

　　wsadmin.bat -user wsadmin -password wsadmin
 
　　成功进入wsadmin的界面如下图所示:

            

　　图2.6启动wsadmin
 
　　使用wsadmin安装和配置SOA组件

　　假设安装和配置SOA组件需要如下几个步骤：

　　·卸载老的SOA组件。
　　·重启服务器：让服务器重新加载所有新的配置，避免由于某些重要的资源没有重新加载而导致新的服务组件验证失败。
　　·安装新的SOA组件。
　　·配置J2C认证条目。

　　下面将分别介绍以上几个步骤Jython和Jacl脚本的编写方法。

　　卸载旧SOA组件：

　　使用脚本卸载SOA组件相当简洁，只需指定要卸载的应用程序名称而不是企业归档（EAR）文件的名称。

　　使用Jacl：

　　$AdminApp uninstall Department
　　$AdminConfig save
 
　　使用Jython：

　　AdminApp.uninstall(‘Department’)
　　AdminConfig.save()
 
　　其中：

             

　　在执行所有的更改操作后都必须执行save命令保存。

　　卸载应用程序从WebSphere Application Server配置和安装了该应用程序的所有服务器中除去此应用程序。从安装目录删除应用程序二进制文件（EAR文件内容）。当为单服务器Application Server版本保存配置时，或当为Network Deployment配置将配置更改从Deployment Manager同步到单个节点时会发生这种情况。

　　重新启动服务器：

　　一个企业级的IT系统需要很多复杂的配置，如果只是替换掉旧的SOA组件并不能保证系统所有的配置都是最新，为了保证系统的一致性一般会卸载SOA组件后重启服务器。用wsadmin重启服务器的方法就是分别调用stop和start命令。

　　使用stopServer命令停止服务器。此命令有若干语法选项。例如：

　　要停止WebSphere Application Server Network Deployment修订版上的服务器，可以在用如下的方法。

　　以下示例指定服务器名和节点名：

　　使用Jacl：

　　$AdminControl stopServer serverName nodeName
 
　　使用Jython：

　　AdminControl.stopServer(‘serverName’, ‘nodeName’)
 
　　要在WebSphere Application Server Network Deployment修订版上启动服务器，可以在用如下的方法。

　　以下示例指定服务器名和节点名：

　　使用Jacl：

　　$AdminControl startServer serverName nodeName
 
　　使用Jython：

　　AdminControl.startServer(‘serverName’, ‘nodeName’)
 
　　安装新SOA组件

　　安装的应用程序必须是企业归档（EAR）文件、Web归档（WAR）文件、servlet归档（SAR）文件或Java归档（JAR）文件。归档文件必须以.ear、.jar、.sar或.war结束，以便wsadmin工具能够安装此归档文件。wsadmin工具使用这些扩展名来判定归档类型。如果文件是WAR或JAR文件，它将自动合并为EAR文件。

　　如果要安装指定AdminApp useMetaDataFromBinary选项的应用程序，那么只能在WebSphere Application Server V6.x部署目标上安装此应用程序。这还适用于在安装应用程序后，使用AdminApp edit命令对其进行编辑。如果使用V5.x wsadmin工具在WebSphere Application Server V6.x单元上安装或编辑应用程序，将只显示V5.x wsadmin工具可以使用的步骤。

　　执行以下步骤以将应用程序安装到运行环境：

　　·确定在配置中安装应用程序时使用的选项。

　　例如，如果配置包含节点、单元和服务器，那么在输入install命令时可以指定该信息。检查AdminApp对象的install、installInteractive、edit、editInteractive、update和updateInteractive命令的选项主题中install和installinteractive命令的有效选项列表，以找到-node、-cell和-server选项的正确语法。对于此配置，Jacl命令是：

　　$AdminApp install “location_of_ear.ear” {-node nodeName -cell
 cellName -server serverName}
 
　　还可以使用options命令获取企业归档（EAR）文件支持的选项列表，例如：

　　使用Jacl：

　　$AdminApp options
 
　　使用Jython：

　　AdminApp.options()
 
　　·选择使用install或installInteractive命令来安装应用程序。

　　可使用install命令以批处理方式安装应用程序，或可使用installinteractive命令以交互方式安装应用程序。交互方式通过一系列任务提示您提供信息。install命令和installinteractive命令支持先前步骤中选择用于安装的选项集。

　　·安装应用程序。对于本示例，仅将server选项与install命令一起使用，其中server选项的值是serv2。使用基于配置选择的选项来定制install或installInteractive命令。

　　使用install命令以批处理方式安装应用程序：（仅限于Network Deployment安装）以下命令使用EAR文件和命令选项信息来在集群中安装应用程序：

　　使用Jacl：

　　$AdminApp install “c:/SOADemo/Department.ear” {-cluster cluster1}
 
　　使用Jython列表：

　　AdminApp.install(‘c:/SOADemo/Department.ear ‘, [‘-cluster’, ‘cluster1’])
 
　　使用Jython字符串：

　　AdminApp.install(‘c:/SOADemo/Department.ear ‘, ‘[-cluster cluster1]’)
 
　　使用installInteractive命令以交互方式安装应用程序。下列命令提示您通过一系列安装任务来更改应用程序信息：

　　使用Jacl：

　　$AdminApp installInteractive “c:/SOADemo/Department.ear”
 
　　使用Jython：

　　AdminApp.installInteractive(‘c:/SOADemo/Department.ear’)
 
　　·保存配置更改。

　　使用Jacl：

　　$AdminConfig save
 
　　使用Jython：

　　AdminConfig.save()
 
　　如果系统成功安装应用程序，那么此任务中的步骤将返回成功消息。安装大型应用程序时，该命令可能会在系统解压缩每个二进制文件前返回成功消息。在系统解压缩所有二进制文件后，才能启动应用程序。如果安装了大型应用程序，请在启动应用程序前使用AdminApp对象的isAppReady和getDeployStatus命令来验证系统是否已解压缩二进制文件。

　　如果系统已准备好，可启动应用程序，那么isAppReady命令将返回值true；如果系统未准备好，无法启动应用程序，那么返回值false，如以下示例所示：

　　使用Jython：

　　AdminApp.isAppReady(‘Department’)
 
　　使用Jacl：

　　$AdminApp isAppReady Department
 
　　如果系统未准备好，无法启动应用程序，那么系统可能正在展开应用程序二进制文件。使用getDeployStatus命令来显示有关二进制文件展开状态的更多信息，如以下示例所示：

　　使用Jython：

　　AdminApp.getDeployStatus(‘Department’)
 
　　使用Jacl：

　　$AdminApp getDeployStatus Department
 
　　配置新的J2C认证数据条目：

　　配置J2C认证的过程比以上步骤复杂一些，需要脚本完成如下几个步骤 :

　　·识别父标识：

　　使用Jacl：

　　set security [$AdminConfig getid /Cell:mycell/Security:/]
 
　　使用Jython：

　　security = AdminConfig.getid(‘/Cell:mycell/Security:/’)
print security
 
　　示例输出：

　　(cells/mycell|security.xml#Security_1)
 
　　·获取必需的属性：

　　使用Jacl：

　　$AdminConfig required JAASAuthData
 
　　使用Jython：

　　print AdminConfig.required(‘JAASAuthData’)
 
　　示例输出：

　　Attribute Type
　　alias String
　　userId String
　　password String
 
　　·设置必需的属性：

　　使用Jacl：

　　set alias [list alias myAlias]
　　set userid [list userId myid]
　　set password [list password secret]
　　set jaasAttrs [list $alias $userid $password]
 
　　示例输出：

　　{alias myAlias} {userId myid} {password secret}
 
　　使用Jython：

　　alias = [‘alias’, ‘myAlias’]
　　userid = [‘userId’, ‘myid’]
　　password = [‘password’, ‘secret’]
　　jaasAttrs = [alias, userid, password]
　　print jaasAttrs
 
　　示例输出：

　　[[‘alias’, ‘myAlias’], [‘userId’, ‘myid’], [‘password’, ‘secret’]]
 
　　·创建JAAS auth数据：

　　使用Jacl：

　　$AdminConfig create JAASAuthData $security $jaasAttrs
 
　　使用Jython：

　　print AdminConfig.create(‘JAASAuthData’, security, jaasAttrs)
 
　　示例输出

　　(cells/mycell|security.xml#JAASAuthData_2)
 
　　·保存配置更改。

　　·仅在Network Deployment环境中使节点同步。

　　验证安装

　　当脚本执行完之后，我们应该验证整个自动化过程是否成功，一般来说有两种方式：

　　1. 查看log日志 : 让所有控制台的输出全部重定向到文件系统中，通过控制台输出可以检查是否所有自动化脚本都成功执行。

　　2. 查看console页面：需要逐个检查欲配置的页面，比如我们要在console中查看要安装的Application是否成功：

             

　　图2.7应用安装成功
 
　　查看其它的自动化步骤是否成功就需要切换到相应的console中。

　　总结

　　本章主要介绍了SOA环境下如何自动化部署测试环境，这些自动化技术都是IBM SOA相关技术部门多年实践经验的结晶，在实际的项目中起到了非常重要的作用。本系列下一篇文章将介绍如何自动执行测试用例。