中国 [选择]

本文内容包括：
	引言
	集群配置的概述
	样例应用程序的概述
	第 1 阶段：SIBus 的数据库配置及规划
	第 2 阶段：为 SIBus 提交 Application Developer 安装任务
	第 3 阶段：为 SIBus post-install 配置任务
	第 4 阶段：SIBus 创建及服务定义
	第 5 阶段：测试该配置
	结束语
	参考资料
	关于作者
	对本文的评价

相关链接：
	SOA and Web services 技术文档库

developerWorks 中国 > SOA and Web services >

在网络部署环境中配置服务集成总线

集群配置

文档选项

未显示需要 JavaScript 的文档选项

级别：初级

Guy Barden (barden@uk.ibm.com), SIBUS 系统测试技术负责人, IBM

2005 年 4 月 01 日

通过 IBM® WebSphere® Application Server V6.0.x 集群安装并配置服务集成总线（Service Integration Bus，SIBus）场景。这个逐步的信息流程通过脚本实例使您领略了配置过程的每个阶段。

引言

Service Integration Bus（SIBus）是逻辑实体，通过管理控制台（Administration Console）或 wsadmin 脚本语言将其创建并配置成 IBM® WebSphere® Application Server V6.0（Application Server）的 post-install 操作。本文的目的在于提供（特定的）网络部署集群环境下 SIBus 和 WebServices Gateway（WSGW）的配置和使用信息。

可以以 Application Server 集群上的两种模式来配置 SIBus，这依赖于部署的需求。由于 SIBus 是基于消息驱动 Bean（MDB）的物理实现的逻辑实体，所以不存在固有的高可用性（high availability，HA）或负载管理（workload management，WLM）功能。潜在的物理实现必须在 SIBus 创建之前独立地配置好。

回页首

集群配置的概述

高可用性集群配置是默认的配置，当创建单元中的应用程序服务器集群时将其创建。当创建 SIBus 时，一个集群服务器上仅存在一个活动 WPM 消息引擎，并且对于集群成员的所有服务请求都通过该单一消息引擎来路由。因此，对于 n 个服务器的集群而言，存在一个本地的消息 put 操作，用于使用活动消息引擎来路由服务器上的服务请求，并且存在（n-1）个远程消息 put 操作，用于每个使用非活动消息引擎的服务器。

图 1. 高可用性集群的拓扑

该配置的优点在于当消息引擎失败时，另一服务器被激活，并通过新的活动消息引擎路由所有远程 put 操作。同时，由于仅存在单一的服务器将消息路由到目标服务上，所以通过 SIBus 的任何消息序列都是持续的。

该配置的一个缺点是性能，因为在集群配置中实际上存在消息瓶颈，并且（n-1）个服务请求是远程 put 到活动消息引擎中的。

负载管理集群配置需要额外的来源于在创建 SIBus 之前默认的集群安装的配置。该配置的目的是消除了依赖于通过显式地为集群中的每个服务器创建额外的消息引擎及定义 CoreGroup 策略来将消息引擎“分配”给集群中的个别服务器来进行消息引擎远程 put 调用。使用 n 个服务器的集群中的 n 个活动消息引擎来在服务器上本地处理每个服务请求，即接收消息而不是路由到活动消息引擎中。

图 2. 负载管理集群的拓扑

该配置的优点是消除了当每个服务器处理提交给集群元素的服务请求时出现的消息引擎瓶颈。这对于 SIBus 是至关紧要的，它有与每个 Web 服务请求的传输相关的庞大的消息处理开销。

该配置的缺点在于，由于服务请求被提交并由每个服务器本地处理，所以不能确定离散的消息顺序。

回页首

样例应用程序的概述

本文指导 SIBus 的配置，所以您可以使用任何 WSDL 通过 URL 发布的已部署好的 Web 服务。为了达到本文的目的，我使用了标准的 Stock Quote Web 服务，它由如下的 WSDL 所描述：

http://services.xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl

您可以使用 Java Dynamic Interface Invocation 客户端或 WebSphere Studio Application Developer（Application Developer）中的 Web Services Explorer 视图来直接访问 Web 服务（为了证明服务方法调用是可行的）或通过配置的 SIBus 来访问 Web 服务。图 3 中的图表展示了您可以实现的目标安装。

图 3. 实例集群拓扑

实例前提条件

描述 Application Server 的安装和集群配置技术超出了本文的范围。以下是对系统安装的细节的实例指导：

机器 1：

安装 Application Server V6.0
创建 Network Deployment Manager 概要文件。（profileName dm-1-profile，nodeName ${shorthostname}Manager，server dmgr）
创建集群。（clusterName was-cluster-1）
创建管理的节点概要文件。（profileName na-1-profile）
管理的节点联合成 ND Cell（nodeName NDNode1）
添加管理的节点作为集群成员模板（serverName NDServer1）

机器 2：

安装 Application Server V6.0
创建管理的节点概要文件（profileName na-2-profile）
管理的节点联合成 ND Cell（nodeName NDNode2）
添加管理的节点作为集群成员（serverName was-cmas-1）

机器 3：

安装 Application Server V6.0
创建管理的节点概要文件（profileName na-3-profile）
管理的节点联合成 ND Cell（nodeName NDNode3）
添加管理的节点作为集群成员（serverName was-cmas-2）

机器 4：

使用创建的网络上使用的实例来安装 DB2 UDB V8.1（注意：数据库可以是任何网络上使用的数据库，而本例使用 DB2 UDB。）

机器 5：

具备生成的 IP Spray 的插件模块的 Web 服务器

回页首

第 1 阶段：SIBus 的数据库配置及规划

SIBus 安装和配置是 post-install 工作，需要一定的规划。SIBus 操作需要两种数据存储。第一种用于 SDO 存储库，它保存已注册服务的 WSDL 信息，而将 SIBus 特有的 WSDL 展示给每个客户。第二种数据存储用于潜在的消息传递层，它需要稳定的内部消息数据格式。创建这些数据存储，并且它们的使用对于独立服务器的用户来说是透明的，因为服务器和数据库都存在于同一台机器上。对于网络部署的集群来说，集群中的每个服务器都必须访问数据存储，这些不能由 SIBus 安装流程透明地配置。管理员需要在安装之前配置它。

对于本实例，将不同集群结构的数据库配置流程描述并标注为适用于 HA 集群（默认的配置）或适用于 WLM 集群（推荐的配置）。

HA 集群数据库结构

对于高可用性的集群而言，需要独立的消息存储数据库，以便每个集群服务器都能获得锁并访问它。为此，创建空数据库 me0（在机器 4 中如下所示）：

db2 create database me0

WLM 集群数据库结构

对于负载管理集群而言，其中的每个服务器都需要单独的消息存储表格。Application Developer 自动处理表格及模式的创建，并且在此您可以为每个服务器安装独立的数据库或者为每个服务器安装具有独立模式的数据库（在机器 4 中如下所示）：

db2 create database me0
db2 create database me1
db2 create database me2

或

db2 create database me0

注意：当创建消息引擎时为每个消息引擎及表格创建单独的模式。

HA 和 WLM 集群数据库结构

对于任意集群配置都需要 SDO Repository 数据存储（在机器 4 中如下所示）：

db2 create database sdodb
db2 connect to sdodb
db2 create schema sdorep
db2 create table sdorep.bytestore (name varchar(250) not null, bytes blob(1G), timestamp1 bigint not null)
db2 disconnect sdodb

目前随着数据库及表格的创建，需要在 Application Server 中配置它们之间的连通性。

在每台主机上，应当将同类的目录结构创建到 DB2 UDB 的客户端 JAR 文件中，该文件应当被放置好。这样确保 Application Server 可以通过数据库提供的驱动器连接到数据库上。在实例的机器 1、2、3 中，文件 db2jcc.jar、db2jcc_license_cu.jar 和 db2jcc_license_cisuz.jar 都被放置在目录 /opt/db2udb 下。
使用 Application Developer 通过管理控制台来配置 Database Instance ID，使用 Security > Global Security > JAAS Configuration > J2C Authentication Data 面板并创建与 db2 实例登录信息相匹配的新的别名。
使用管理控制台为 Application Developer 配置 JDBC Provider
1. 在 Resources > JDBC Providers 面板中将范围更改成 Cell，并创建新的 JDBC Provider，选择 DB2，Universal JDBC Driver Provider，Connection Pool Data Source（或 XA DataSource）> Next。
2. 更改类路径条目来将目录结构映射到复制的客户端 DB2 JAR 中。
3. 清空 Native Path 条目，选择 OK。
配置了 JDBC Provider 后，必须为每个数据库创建 DataSources。
1. 对于 SDO Repository 而言，选择管理控制台中的 DataSource 面板并创建新的 DataSource。对于所需的每个字段，应当提供以下信息：
  - Name：SdoRep DataSource（将其命名成任何适合于安装的名称）
  - JNDI Name：jdbc/com.ibm.ws.sdo.config/SdoRepository（SDO Repository 应用程序使用该 JNDI 名称，并且必须具备该值）
  - DataSource CMP：将其打勾
  - DataStoreHelper：DB2 Universal 数据存储助手
  - Component-Managed 认证：第 2 步中创建的别名
  - Database Name：sdodb（或者 SDO DB2 数据库具有的任何名称）
  - Driver Type：4
  - Server 名称：DB2 Server 的主机名
  - Port Number：db2 实例的端口号
2. 对于 HA 和 WLM 集群配置而言，需要为每个已创建的数据库创建数据源。每个数据源的值应当与 SDO Repository 数据源相同，但是使用特有的名称及 JNDI 名。对于本例而言，值如下：
  - Name：ClusterME0
  - JNDI Name：jdbc/com.ibm.ws.sib/was-cluster-1.000-Example（使用为 ME 表格定义的不同模式的 HA Cluster 或 WLM Cluster。）
  or
  - Name：ClusterME0（使用数据库每个 ME 的 WLM 集群）
  - JNDI Name：jdbc/com.ibm.ws.sib/was-cluster-1.000-Example（使用数据库每个 ME 的 WLM 集群）
  - Name：ClusterME1（使用数据库每个 ME 的 WLM 集群）
  - JNDI Name：jdbc/com.ibm.ws.sib/was-cluster-1.001-Example（使用数据库每个 ME 的 WLM 集群）
  - Name：ClusterME2（使用数据库每个 ME 的 WLM 集群）
  - JNDI Name：jdbc/com.ibm.ws.sib/was-cluster-1.002-Example（使用数据库每个 ME 的 WLM 集群）
保存更改。

到此，在本实例中已经创建了数据库、模式和表格，在网络部署集群中建立了数据库连接及认证。这可以使用 Test Connection 按钮为管理控制台上的每个已创建的 Datasource 面板上的每个 DataSource 进行测试。

回页首

第 2 阶段：为 SIBus 提交 Application Developer 安装任务

如前面所述，SIBus 需要在创建 WebSphere 拓扑之后安装并配置。由于 SIBus 是通过拓扑定义的逻辑实体，所以它在许多安装并启动的 Enterprise Applications 中物理上地显示出来。

SDO Repository 应用程序

既然已经定义了数据库连接那么就必须安装 SDO Repository。该应用程序是特殊的实例范围包括集群和 Network Deployment 管理器。因为需要访问 SDO 数据库的场景可能由于 Web 服务请求和基于集群的 SIBus 运行而生成，或者来源于通过部署管理器服务器、dmgr 的 SOAP 连接器的 wsadmin 配置请求。

安装是通过使用 Application Server 运输的 jacl 脚本来执行，并且它可在目录 ${WAS_INSTALL_ROOT}/bin 下找到，它被称为 installSDORepository.jacl。

对于 HA 集群和 WLM 集群结构

安装 SDO Repository 应用程序来部署管理器服务器。该命令具有如下的格式：

${WAS_INSTALL_ROOT}/bin/wsadmin.sh 
	-conntype SOAP 
	-port 8879 
	-f ${WAS_INSTALL_ROOT}/bin/installSDORepository.jacl 
	<nodename> 
	<server>

对于本实例而言，命令如下：

/opt/WebSphere/AppServer/bin/wsadmin.sh 
	-conntype SOAP 
	-port 8879 
	-f /opt/WebSphere/AppServer/bin/installSDORepository.jacl 
	batmanManager 
	dmgr

SDO Repository 需要关于使用的数据库类型的信息。该命令具有如下的格式：

${WAS_INSTALL_ROOT}/bin/wsadmin.sh
	-conntype SOAP 
	-port 8879 
	-f ${WAS_INSTALL_ROOT}/bin/installSDORepository.jacl 
	-editBackendId <DB_ID>

可以在如下的路径下找到支持的数据库标识符的清单：

${WAS_INSTALL_ROOT}/util/SDORepository

对于本实例而言，命令如下：

/opt/WebSphere/AppServer/bin/wsadmin.sh 
	-conntype SOAP 
	-port 8879 
	-f /opt/WebSphere/AppServer/bin/installSDORepository.jacl 
	-editbackendid DB2UDB_V81

最后，必须穿过集群安装 SDO Repository 应用程序。该命令具有如下的格式：

${WAS_INSTALL_ROOT}/bin/wsadmin.sh 
	-conntype SOAP 
	-port 8879 
	-f ${WAS_INSTALL_ROOT}/bin/installSDORepository.jacl 
	-cluster <clustername>

对于本实例而言，命令如下：

/opt/WebSphere/AppServer/bin/wsadmin.sh 
	-conntype SOAP 
	-port 8879 
	-f /opt/WebSphere/AppServer/bin/installSDORepository.jacl 
	-cluster was-cluster-1

SIBUS 应用程序

SIBus 是逻辑实体，它以大量的企业应用程序、资源适配器及活动规范的形式来物理地表现。作为 Application Server post-install 流程的一部分，需要在 SIBus 创建及配置活动开始之前安装并启动这些应用程序。再一次通过 Application Developer 所传输的安装 jacl 脚本来在 ${WAS_INSTALL_ROOT}/util 目录下安装此应用程序，它被称为 sibwsInstall.jacl。调用这个 jacl 用于 SIBus 的每个物理安装步骤，传输不同的参数以区分不同的操作。

对于 HA 和 WLM 集群结构。

安装 Resource Adapter 并配置由 SIBus MDB 所使用的 Activation Specification。该安装命令具有如下的格式：

${WAS_INSTALL_ROOT}/bin/wsadmin.sh 
	-conntype SOAP 
	-port 8879 
	-f ${WAS_INSTALL_ROOT}/util/sibwsInstall.jacl 
	-installRoot ${WAS_INSTALL_ROOT} 
	-clusterName <clustername> 
	-nodeName <nodename> 
	INSTALL_RA

对于本实例而言，命令如下：

/opt/WebSphere/AppServer/bin/wsadmin.sh 
	-conntype SOAP 
	-port 8879 
	-f /opt/WebSphere/AppServer/util/sibwsInstall.jacl 
	-installRoot /opt/WebSphere/AppServer 
	-clusterName was-cluster-1 
	-nodeName NDNode1 
	INSTALL_RA

注意：虽然您正在安装集群，但是您仍需指定集群中的某一节点的名称。

安装 SIBus Enterprise Application。该安装命令具有如下的格式：

${WAS_INSTALL_ROOT}/bin/wsadmin.sh 
	-conntype SOAP 
	-port 8879 
	-f ${WAS_INSTALL_ROOT}/util/sibwsInstall.jacl 
	-installRoot ${WAS_INSTALL_ROOT} 
	-clusterName <clustername> 
	INSTALL

对于本实例而言，命令如下：

/opt/WebSphere/AppServer/bin/wsadmin.sh 
	-conntype SOAP 
	-port 8879 
	-f /opt/WebSphere/AppServer/util/sibwsInstall.jacl 
	-installRoot /opt/WebSphere/AppServer 
	-clusterName was-cluster-1 
	INSTALL

注意：对于实际的向集群中安装企业应用程序而言，节点名称不是必须的。

安装 SIBus HTTP Channels Enterprise Application。该安装命令具有如下的格式：

${WAS_INSTALL_ROOT}/bin/wsadmin.sh 
	–conntype SOAP 
	–port 8879 
	–f ${WAS_INSTALL_ROOT}/util/sibwsInstall.jacl 
	–installRoot ${WAS_INSTALL_ROOT} 
	–clusterName <clustername> 
	INSTALL_HTTP

对于本实例而言，命令如下：

/opt/WebSphere/AppServer/bin/wsadmin.sh 
	–conntype SOAP 
	–port 8879 
	–f /opt/WebSphere/AppServer/util/sibwsInstall.jacl 
	–installRoot /opt/WebSphere/AppServer 
	–clusterName was-cluster-1 
	INSTALL_HTTP

安装 SIBus JMS Channels Enterprise Application。该安装命令具有如下的格式：

${WAS_INSTALL_ROOT}/bin/wsadmin.sh 
	–conntype SOAP 
	–port 8879 
	–f ${WAS_INSTALL_ROOT}/util/sibwsInstall.jacl 
	–installRoot ${WAS_INSTALL_ROOT} 
	–clusterName <clustername> 
	INSTALL_JMS

注意：通道应用程序是可选的，仅当使用通道时才安装它。在本实例中，您仅使用 HTTP 通道，所以没有安装 JMS Channel。

这结束了安装 SIBus 的物理方面，可以通过管理控制台上的 Enterprise Applications 清单看到成功安装的确认，在管理控制台中应当安装并启动下列应用程序：

SDO Repository
Sibws.was-cluster-1
Sibwshttp1.was-cluster-1
Sibwshttp2.was-cluster-1

回页首

第 3 阶段：为 SIBus post-install 配置任务

通过将 SIBus 应用程序物理安装到集群，两种类型的集群的配置路径相互分离了。目前，HA 集群准备创建 SIBus 实例来使用，但是 WLM 集群需要配置负载方面。

仅适用于 WLM 集群

对于安装负载管理，集群中的每个服务器都需要具备本地处理输入的 Web 服务请求的能力。这仅通过为集群中的每个服务器创建额外的消息引擎来实现，以便启动自发的消息处理。在创建消息引擎之前，需要定义通过集群的请求处理的行为策略。这被称为 CoreGroup Policy，并且该核心群的结果是将每个消息引擎分配给集群中的独立服务器。

该功能通过 ${WAS_INSTALL_ROOT}/bin 目录下的由 Application Developer 传输的 jacl 脚本实现，它被称为 CreateCoreGroupPolicy.jacl。该 jacl 脚本具有单一的参数，它是创建的属性文件的路径。应当为集群中的每个服务器创建属性文件，并且 jacl 脚本的运行依赖于每个属性文件。不存在 Application Developer 可用的模板属性文件，所以它们必须从初始设计中创建。下面的清单 1 是具有对于需要修正以适合于系统安装的条目的说明的模版。

清单 1. CoreGroup Policy 文件模版

				
	CoreGroupName=DefaultCoreGroup	
	PolicyName=<policyName>	# Name unique to the ME policy.
	PolicyType=OneOfNPolicy	
	IsAlivePeriodSec=0
	Failback=true	
	QuorumEnabled=false
	PreferredOnly=true
	NumOfMatchCriteria=3
	Name_0=type
	Value_0=WSAF_SIB
	Name_1=WSAF_BUS
	Value_1=<busName>	# Name of the SIBus that is to be created.
	Name_2=WSAF_SIB_MESSAGING_ENGINE
	Value_2=<meName>	# Name of the messaging engine being pinned.
	NumOfPolicyServers=1
	NodeName=<nodeName>	# The node for the server.
	ServerName=<serverName>	# The server being pinned to.

在该实例中，需要三个属性文件。它们都应当被创建在托管 Deployment Manager 的机器上，并且每一个都应当映射到集群中出现的服务器上。策略文件如下所示：

清单 2. 机器 1 策略文件实例

				
	CoreGroupName=DefaultCoreGroup	
	PolicyName=ME0	
	PolicyType=OneOfNPolicy	
	IsAlivePeriodSec=0
	Failback=true	
	QuorumEnabled=false
	PreferredOnly=true
	NumOfMatchCriteria=3
	Name_0=type
	Value_0=WSAF_SIB
	Name_1=WSAF_BUS
	Value_1=ExampleBus	
	Name_2=WSAF_SIB_MESSAGING_ENGINE
	Value_2=was-cluster-1.000-ExampleBus	
	NumOfPolicyServers=1
	NodeName=NDNode1	
	ServerName=NDServer1

清单 3. 机器 2 策略文件实例

				
	CoreGroupName=DefaultCoreGroup	
	PolicyName=ME0	
	PolicyType=OneOfNPolicy	
	IsAlivePeriodSec=0
	Failback=true	
	QuorumEnabled=false
	PreferredOnly=true
	NumOfMatchCriteria=3
	Name_0=type
	Value_0=WSAF_SIB
	Name_1=WSAF_BUS
	Value_1=ExampleBus	
	Name_2=WSAF_SIB_MESSAGING_ENGINE
	Value_2=was-cluster-1.001-ExampleBus	
	NumOfPolicyServers=1
	NodeName=NDNode2	
	ServerName=was-cmas-1

清单 4. 机器 3 策略文件实例

				
	CoreGroupName=DefaultCoreGroup	
	PolicyName=ME0	
	PolicyType=OneOfNPolicy	
	IsAlivePeriodSec=0
	Failback=true	
	QuorumEnabled=false
	PreferredOnly=true
	NumOfMatchCriteria=3
	Name_0=type
	Value_0=WSAF_SIB
	Name_1=WSAF_BUS
	Value_1=ExampleBus	
	Name_2=WSAF_SIB_MESSAGING_ENGINE
	Value_2=was-cluster-1.002-ExampleBus	
	NumOfPolicyServers=1
	NodeName=NDNode3	
	ServerName=was-cmas-2

您需要为每个服务器创建策略。应当为每个属性文件执行 CreateCoreGroupPolicy.jacl，其具有如下格式：

${WAS_INSTALL_ROOT}/bin/wsadmin.sh 
	–conntype SOAP 
	–port 8879 
	–f ${WAS_INSTALL_ROOT}/bin/CreateCoreGroupPolicy.jacl 
	<propsFile>

这完成了 WLM 集群的前总线配置工作。

回页首

第 4 阶段：SIBus 创建及服务定义

在配置过程的这个阶段，您在实例中具备集群拓扑——HA 或 WLM 集群——并且准备将其用于创建 SIBus 的逻辑实体。这些工作可以通过管理控制台或通过 wsadmin 和 jacl 脚本来完成，本文集中于通过 jacl 脚本来配置。对于本实例，配置集群的完整 jacl 脚本的清单被包含在所有步骤之后，并且它可应用于 HA 和 WLM 集群。

首先创建 SIBus 对象，使用所有后续的相关元素。该命令具有如下的格式：

$AdminTask createSIBus –bus <busName>

对于本实例而言，命令如下（具备错误处理）：

if {[catch {set csb [$AdminTask createSIBus –bus ExampleBus]} result]} {
	puts "Error creating SIBus, failed with $result"
}

下一步是将集群作为总线元素添加到总线中。该命令具有如下的格式：

$AdminTask addSIBusMember –bus <busname> -cluster <clustername>\
	-datasourceJndiName <ME datasource jndi name>

对于本实例而言，命令如下：

if {[catch {set csb [$AdminTask addSIBusMember –bus ExampleBus 
	–cluster was-cluster-1 \
	–datasourceJndiName jdbc/com.ibm.ws.sib/was-cluster-1.000-ExampleBus]} \
	result]} {
	puts "Error adding SIBusMember, failed with $result"
}

仅对于 WLM 集群而言，需要创建定义在 CoreGroup Policy 中的额外的消息引擎。该命令具有如下的格式：

$AdminTask createSIBEngine –bus <busname> -cluster <clustername> \
	-datasourceJndiName <jndiName>

对于本实例，您为您的三个服务器集群创建两个额外的引擎。该命令具有如下的格式：

if {[catch {set csb [$AdminTask createSIBEngine –bus ExampleBus 
	–cluster was-cluster-1 \
	–datasourceJndiName jdbc/com.ibm.ws.sib/was-cluster-1.001-ExampleBus]} \
	result]} {
	puts "Error create SIBEngine, failed with $result"
}
if {[catch {set csb [$AdminTask createSIBEngine –bus ExampleBus \
	–cluster was-cluster-1 \
	–datasourceJndiName jdbc/com.ibm.ws.sib/was-cluster-1.002-ExampleBus]} \
	result]} {
	puts "Error create SIBEngine, failed with $result"
}

请注意 JNDI 名称是如何同您设计数据库时创建的数据源名称相关联的。如果该实例使用具有多种模式的单一数据库，那么对于每个消息引擎而言 JNDI Name 都应当是相同的。

最后，通过已创建的总线成员及额外的消息引擎（如果在 WLM 集群中），为数据库和唯一模式而创建的 J2C 认证别名需要与消息传递引擎数据存储对象相关联。该命令具有如下的格式：

		
set schemaId 0
set schemaName "IBMWSME"
set authAlias [list authAlias $authAlias]
set datastoreIDs [$AdminConfig list SIBDatastore]
foreach datastoreID $datastoreIDs {
    set uniqueSchema "$schemaName$schemaId"
    set schema [list schemaName $uniqueSchema]
    set attributes [list $authAlias \
		$schema ]
    $AdminConfig modify $datastoreID $attributes
    incr schemaId
}

其中 <authalias> 是第 1 阶段中定义的认证别名。

既然已经创建了 SIBus 并配置了总线成员及额外的消息引擎，那么下一步就是启动总线中的 Web 服务定义。由于通过 SIBus 来路由 Web 服务，所以需要将 EndpointListener 连接到总线上并且与传输通道相关联。创建及连接 endpointlistener 的命令具有如下格式：

		
set clusterObj [$AdminConfig getid /ServerCluster:<clusterName>]
set epl [$AdminTask createSIBWSEndpointListener $clusterObj \
	–name <soapchannel> \
	-urlRoot <soapchannel url> -wsdlurlRoot <sibws url>]
$AdminTask connectSIBWSEndpointListener $epl –bus <busname> \
	-replyDestination <destname>

其中下列为真：

<clusterName> 是集群的名称用于部署 endpointlistener。
<soapchannel> 是 soap 通道的名称用于监听，换句话说，SOAPHTTPChannel1。
<soapchannel url> 是访问 SOAPChannel servlet 的 URL，即 http://<hostname>/wsgwsoaphttp1。
<hostname> 是 Web Server 的主机名称，用于将请求传递到集群中。
<sibws url> 是 WSDL 的 URL，该 WSDL 用于 SIBus 的 servlet，即 http://<hostname>/sibws。
<busname> 是 SIBus 的名称。
<destname> 是用于创建 endpointlistener 的应答消息的目的文件的专有名称。

下一步是创建网关将来源于客户端的请求路由到目标 Web 服务中。为了完成该任务，使用 Web 服务的 WSDL 和与网关服务 WSDL 相关联的专有的命名空间来创建网关实例。该命令具有如下的格式：

	
set busObject [$AdminConfig getid /SIBus:<busname>] 
set args "{name SwapGateway} {wsdlServiceNamespace http://test.wsgw.ibm.com}"
set wsgw [$AdminConfig create "WSGWInstance" $busObject $args]
set args {}
lappend args [list "WSDLLocation " <targetServiceWSDL>]
$AdminConfig create "SIBWSWSDLLocation" $wsgw $args "defaultProxyWSDLLocation"

其中下列为真：

<busname> 是 SIBus 的名称。
<targetServiceWSDL> 是 WSDL 描述目标服务的 URL。

目前创建了网关实例，应当创建 Inbound Service 并将其与网关相关联。该命令具有如下的格式：

	
set args " -name <serviceName> -requestDestination <reqDest> \
	-replyDestination <rspDest> -targetService <outboundService> \
	-targetBus <busName >"
set swapgw [$AdminTask createWSGWGatewayService $wsgw  $args]

其中下列为真：

<serviceName> 是 Inbound Service 的名称。
<reqDest> 是为该服务创建的目的文件的专有名称。
<rspDest> 是为该服务创建的应答目的文件的专有名称。
<outboundService> 是请求所路由到的 Outbound Service 的名称。
<busName> 是 SIBus 的名称。

下一步是创建 Inbound Port 来将 endpointlistener 连接到 Inbound Service 中。该命令具有如下的格式：
set args " -name <portName> -endpointListener $eplName -cluster $clusterName " $AdminTask addSIBWSInboundPort $inService $args
其中下列为真：
- <portName> 是用于关联 Inbound Service 的端口的名称。
完成了 SIBus 配置的 Inbound 一方，并需要创建 Outbound Service 及 Port。对于 Outbound Service，命令具有如下格式：
set args [list -name $outBoundService -wsdlLocation <targetServiceWSDL> \ -destination <outDest>] set outService [$AdminTask createSIBWSOutboundService $busObject $args]
其中下列为真：
- <targetServiceWSDL> 是 WSDL 描述目标服务的 URL。
- <outDest> 是为该服务创建的目的文件的专有名称。
该配置的最后一部分是创建 Outbound Port。该命令具有如下格式：
set args [list -name <outboundPort> -destination <portDest> -cluster $clusterName] $AdminTask addSIBWSOutboundPort $outService $args
其中下列为真：
- <outboundPort> 是在目标服务 WSDL 中定义的服务端口的名称。
- <portDest> 是为该 Port 创建的目的文件的专有名称。

配置实例 SIBus 元素

使用 jacl 脚本配置 SIBus 元素的原则已经被提出了。清单 5 展示了在该实例的配置中所用的 jacl 脚本。

清单 5. 实例配置 jacl

				
puts "****Configuring the cluster topology****"
# Pass in the hostname of the deployment manager and the
# database authentication alias
set hostName   [lindex $argv 0]
set authAlias [lindex $argv 3]
set clusterName    "was-cluster-1"
set eplName "SOAPHTTPChannel1"
set busName "ExampleBus"
set inBoundPort "StockPort"
set inBoundService "StockInboundService"
set outBoundService "StockOutboundService"
set outBoundPort "net.xmethods.services.stockquote.StockQuotePort"
# these jndi names are required to use the different datasources - which pin
# the MEs to the individual servers using policies set up by the AIS config
set jndi0 jdbc/com.ibm.ws.sib/was-cluster-1.000-SVTBus
# FOR WLM CLUSTER ONLY WITH MULTIPLE DATABASES
set jndi1 jdbc/com.ibm.ws.sib/was-cluster-1.001-SVTBus
set jndi2 jdbc/com.ibm.ws.sib/was-cluster-1.002-SVTBus
# END OF WLM CLUSTER ONLY
set args "-bus $busName"
puts "Creating bus, $busName"
if {[catch {set csb [$AdminTask createSIBus $args]} result]} { 
  puts "*** createSIBuses $busName FAILED with : $result ***"
  exit
}
puts "Adding cluster $clusterName to Bus..."
set args [list -bus $busName -cluster $clusterName \ 
	-datasourceJndiName $jndi0]
 if {[catch {set csb [$AdminTask addSIBusMember $args]} result]} { 
  puts "*** Add cluster to $busName FAILED with : $result ***"
  exit
}
# FOR WLM CLUSTER ONLY WITH MULTIPLE DATABASES use $jndi1 and $jndi2
# FOR WLM CLUSTER ONLY WITH MULTIPLE SCHEMA use $jndi0 for both 
# -datasourceJndiName options.
puts "Creating additional Messagine Engines..."
set params [list -bus $busName -cluster $clusterName \
	-datasourceJndiName $jndi1]
$AdminTask createSIBEngine $params
set params [list -bus $busName -cluster $clusterName \
	-datasourceJndiName $jndi2]
$AdminTask createSIBEngine $params
# END OF WLM CLUSTER ONLY
puts "Adding Authentication Alias and Schema to datastore used by Bus..."
set schemaId 0
set datastoreIDs [$AdminConfig list SIBDatastore]
set authAlias [list authAlias $authAlias]
foreach datastoreID $datastoreIDs {
        set uniqueSchema "$schemaName$schemaId"
        set schema [list schemaName $uniqueSchema]
        set attributes [list $authAlias \
                        $schema ]
        $AdminConfig modify $datastoreID $attributes
        incr schemaId
}
set busObject [$AdminConfig getid /SIBus:$busName/]
set clusterObject [$AdminConfig list ServerCluster]
puts "create $eplName EndpointListener on cluster"
set args [list -name $eplName \
	-urlRoot http://$hostName:9080/wsgwsoaphttp1/ \
	-wsdlUrlRoot http://$hostName/sibws]
set epl [$AdminTask createSIBWSEndpointListener $clusterObject $args]
puts "connect $eplName EndpointListener to bus, $busName"
set args [list -bus $busName]
$AdminTask connectSIBWSEndpointListener $epl $args
puts "create Outbound Service, $outBoundService"
set args [list -name $outBoundService \
	-wsdlLocation \
	http://services.xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl  \
	-destination OutBoundServiceDestination]
set outService [$AdminTask createSIBWSOutboundService $busObject $args]
puts "create OutboundPort, $outBoundPort"
set args [list -name $outBoundPort \
	-destination OutBoundServiceDestinationPort \
	-cluster $clusterName]
$AdminTask addSIBWSOutboundPort $outService $args
puts "create Inbound Service $inBoundService"
set args [list -name $inBoundService \
	-destination OutBoundServiceDestination \
	-wsdlLocation \
	http://services.xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl ]
set inService [$AdminTask createSIBWSInboundService $busObject $args]
set args [list -endpointListener $eplName -name $inboundPort \
	-cluster $clusterName]
$AdminTask addSIBWSInboundPort $inService $args
puts "create Gateway Instance StockGateway"
set args "{name StockGateway} \
	{wsdlServiceNamespace http://test.wsgw.ibm.com}"
set wsgw [$AdminConfig create "WSGWInstance" $busObject $args]
set args {}
lappend args [list "WSDLLocation" \
	http://services.xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl]
$AdminConfig create "SIBWSWSDLLocation" $wsgw \
	$args "defaultProxyWSDLLocation"
puts "create Gateway Service StockGW"
set args " -name StockGW -requestDestination StockGWDest \
	-replyDestination StockGWReplyDest \
	-targetService $outBoundService -targetBus $busName "
set swapgw [$AdminTask createWSGWGatewayService $wsgw  $args]
set inService [$AdminConfig getid /SIBWSInboundService:StockGW/]
puts "create Inbound Port StockGWPort for $swapgw" 
set args " -name StockGWPort -endpointListener $eplName \
	-cluster $clusterName "
$AdminTask addSIBWSInboundPort $inService $args
puts "saving..."
$AdminConfig save
puts "script complete"

回页首

第 5 阶段：测试该配置

目前将网关配置成能够将任何 SOAP 请求路由到目标 Web 服务中。检验它的最佳方法是向 Web 服务发出请求。由于特殊的客户端是有限的，所以 WebSphere Application Developer（或 Rational® Application Developer）中的 Web Services Explorer 是完成该任务的最简单的方法。

在 Rational Application Developer 中切换到 J2EE 视图，并且在工具栏上使用按钮来启动 Web Services Explorer。
在 Web Services Explorer 中选择 WSDL 页面按钮，并选择 WSDL Main 链接。
在文本框中输入您的服务的 WSDL URL。它使用如下格式：
http://<hostname</wsgwsoaphttp1/soaphttpengine/<busname>/ \ <inboundservicename>/<inboundportname>?wsdl
注意：hostname 可以是集群中的任一服务器或 ip 喷射器（ip-sprayer）所提交的。对于本例，url 可以如下：
http://batman:9080/wsgwsoaphttp1/soaphttpengine/ExampleBus/ \ StockGW/StockGWPort?wsdl
然后选择 Go 按钮。
这返回了 getQuote 的操作链接。点击该链接并将 IBM 输入到文本框中。
这将返回 IBM 共享价格的结果并且指出已经通过集群上的网关实例将 Web 服务请求成功路由了。

回页首

结束语

通过本文的实践，您深入地了解了用于 SIBUS 部署的集群的准备工作。依照实例的每个阶段进行，您得到了使用 SIBus（用于 Web 服务）的经验，并且您现在准备后续的测试或生产环境下的部署。

参考资料

您可以参阅本文在 developerWorks 全球站点上的英文原文。
获取有关创建 SIBus 上的 Gateway Web Service 的机制的概述，请见文章“使用 WebSphere Application Server V6 创建 Simple Gateway Service”（developerWorks，2005 年 2 月）。
通过 WebSphere Version 6 Web Services Handbook Development and Deployment （Redbook 出版，2005）中的各种视图了解 Web 服务的概念。它展示了 Web 服务所依赖的主要构建模块。这里，提出并讨论了明确定义的标准及新概念。
想了解更多关于 WebSphere Application Server V6.0 的内容，请访问 WebSphere Information Center。您可以在这里找到有关 WebSphere Application Server 和 Network Deployment 的所有在线文档。
着手于应用程序开发工具及 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的中间件产品。您可以免费下载产品的测试版，或选择 developerWorks 免费的 Software Evaluation Kit 的 Linux® 或 Windows® 版本。
访问 Developer Bookstore 来获取技术书籍列表，包含上百篇 Web 服务题目。
通过参与 developerWorks blogs 加入 developerWorks 社区。
IBM developerWorks 小组有成百上千篇各种技术简报可以免费索取。
想获取更多信息吗？developerWorks SOA 和 Web 服务专区有成百上千篇信息文章，以及关于如何开发 Web 服务应用程序的入门级、中级和高级教程。

关于作者


		过去两年 Guy Barden 在 Web Services Test Environment 工作，他参与配置和设计过 Service Integration Bus 的系统测试场景。先前，他从事于 Web Services Invocation Framkework（WSIF）标准和 WebSphere Studio Application Developer V5.x 中的 Web 服务网关方面的工作。

对本文的评价

回页首

IBM 公司保留在 developerWorks 网站上发表的内容的著作权。未经IBM公司或原始作者的书面明确许可，请勿转载。如果您希望转载，请通过提交转载请求表单联系我们的编辑团队。

关于 IBM

隐私条约

联系 IBM

使用条款