【IT168 技术文章】

　　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 工具支持整个范围的产品管理活动。

　　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.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 相关技术部门多年实践经验的结晶，在实际的项目中起到了非常重要的作用。本系列下一篇文章将介绍如何自动执行测试用例。