级别： 初级 娄丽军, 软件部售前工程师, IBM
2005 年 5 月 01 日 本文介绍了 WebSphere Application Server 的最新版本V6 中的一个全新的消息平台WebSphere Platform Messaging（简称WPM）,以及服务集成总线的组成与实现。
面向服务的体系架构(SOA)已经成为新一代电子商务应用的热点规范，利用面向服务的体系结构能够实现企业的应用或资源之间的灵活连接，因为它把每一项应用或资源表达为具有标准接口的服务，能够让应用或服务交换结构化的信息（消息、文档、"业务对象"），并通过企业服务总线（Enterprise Service Bus）调节消息交换。企业服务总线是SOA的核心组成部分，它为SOA提供了连通性基础架构，在SOA架构上发布的业务服务是ESB的"用户"，这些基于SOA架构的业务系统所开放出来的服务通过ESB进行交互。
在WebSphere Application Server(简称WAS)的最新版本V6中，发布了一个全新的消息平台WebSphere Platform Messaging（简称WPM）,它的主要组件是Service Integration Bus, 称为服务集成总线，该总线是一个跨应用服务器的一个虚拟的通讯环境，它不仅支持同步的Web Services的集成，同时支持异步的消息集成，是一个统一的服务和消息集成通讯基础架构，是WebSphere应用服务器本身构建ESB的解决方案。
我们知道，在WAS之前的版本中的JMS实现是通过WebSphere MQ来实现的，而这个消息平台是一个崭新的纯Java的实现，它和整个应用服务器的其他组件更加紧密地融合在了一起。消息和服务通过该总线进行通讯，首先它是一个符合JMS1.1标准的JMS Provider，并且同时它又支持Web Services Provider（提供者）和 Requestor（请求者）的接入。Service Integration Bus是WAS中实现ESB功能的主要部件，它的主要功能特点包括：
- 支持Web Services标准
- 支持J2EE1.4中最新的JMS标准，包括点对点通讯模式和发布/订阅模式
- 确保消息传输的可靠性，支持在WAS V6网络部署版单元(Cell)环境中的高可用性
- 支持对消息计算处理等仲裁功能
- 支持与WebSphere MQ的互连
- 替代了原来的基于MQ的JMS实现，使得与WAS运行环境更加紧密地集成，它与应用服务器运行在同一个运行在同一个JVM中，在安装、管理、安全、扩展性支持和故障分析等方面与WAS的整体架构相一致。
1 服务集成总线：SIBus
1.1 主要功能组件
服务集成总线SIBus由以下几部分组成：
- 服务集成总线：一个支持同步和异步处理的通讯架构；在一个单元或一个独立的服务器上可以有若干个总线；总线由总线成员（Bus Member）、消息引擎(Messaging Engine)和目标(Destination)等部件组成。当服务集成总线用于JMS应用时，它就相当于一个信息总线。
- 总线成员，可以是一个应用服务器或一个集群，当我们新定义一个总线成员时，系统会自动在应用服务器或集群上创建一个消息引擎。我们可以创建附加的消息引擎来实现扩展性和负载均衡。当我们要通过总线发送和接收消息时，需要与总线进行连接。
- 消息引擎，位于应用服务器或集群中，并且管理总线资源，运行于总线成员上的应用实际是通过消息引擎与总线相连，但它对于用户来说是透明的。常见的配置是一个应用服务器创建一个消息引擎，但是一个应用服务器也可以创建多个消息引擎，每个消息引擎有一个唯一标识。
每个消息引擎有其自己的数据存储空间，即JDBC数据库，数据存储空间中存储了消息数据、订阅信息、交易状态等，由此保证了当应用服务器或消息引擎重起之后，数据不会丢失。不同的消息引擎可以共享一个数据库，但要求每个消息引擎使用唯一的表。
- 目标：总线目标是消息或主题的存放地，它与一个或多个消息引擎相关。总线目标可以是永久的或临时的，永久性目标由管理员创建直到被删除，临时性是由应用程序动态创建的。目标的类型有：
队列(Queue)：用于点对点消息通讯
主题(Topicspace)：用于发布/订阅通讯模式
别名(Alias)：是另一个目标的别名
外部(Foreign)：该目标指向另一条总线上的目标
例外(Exception):专门用来处理无法正确发出的消息
1.2 Cell环境中的总线和消息引擎
在一个Cell环境中，可以存在多个服务集成总线，如下图所示：
该CELL中有两个服务集成总线SIBus1和SIBus2，其中ClusterA和ClusterB是SIBus1的成员，ClusterA和ClusterC是SIBus2的成员。每个总线的成员可以是应用服务器或者是集群，如前所述，当应用服务器或集群被添加为总线成员时，系统会自动创建一个消息引擎，这对最终用户是透明的。消息引擎和其他J2EE应用以及各种容器一起运行于应用服务器上。目标是定义在总线上，而不是定义在消息引擎上的。
1.3 对应用类型的支持
服务集成总线支持如下类型的应用：
1）Web Services:
- 使用JAX-RPC API接口的服务请求方
- 作为服务提供方的无状态的会话Bean和Servlets(JSR-109)
- 通过SOAP/HTTP或者SOAP/JMS调用的服务请求方和服务提供方
2）消息类型的应用
- MQ应用
- WAS V5中的JMS应用
- WAS V6中的JMS应用
- 使用JFAP-TCP/IP的Inbound消息，JFAP是服务集成总线中消息提供者(Message Provider)使用的格式和协议。
我们可以通过定义目标上消息的永久性和非永久性属性来决定服务质量，也可以在应用程序中定义服务质量。
1.4 拓扑结构类型
对于WAS Express版和Base版，我们有一个独立的应用服务器，一个集成服务总线，一个消息引擎。在WAS Network Deployment版本中，我们的配置可能会比较复杂。下图中配置了两个应用服务器，一个服务总线，每个应用服务器有一个消息引擎。
常见的拓扑结构有：
1) 一个集成服务总线，一个消息引擎
2) 一个集成服务总线，多个消息引擎
3) 多个集成服务总线，它们之间可以互连，也可以互相独立
4) 不同的cell（单元）有不同的集成服务总线，它们之间互连
5) 一个集成服务总线，一个MQ队列管理器，它们之间互连，在这种情况下，要注意：
- MQ队列管理器和WAS 6的缺省消息服务器可以位于同一台机器上，在V5中，内嵌的JMS服务器和MQ是不能位于同一台机器上的；
- 消息引擎不能参与到MQ的集群环境中；
- WAS应用可以通过服务集成总线将消息直接发送到MQ的队列中；
- 可以与MQ建立多个连接，但是每一个连接必须是不同的队列管理器；
- WAS V5的JMS客户端能够直接与V6的目标相连，同理，V6的JMS应用能够与V5中的内嵌JMS服务器相连。但是，V5的内嵌JMS服务器不能与V6的总线相连。
企业中可能会部署多个服务集成总线，并使之互相连接，不同的总线之间通过Gateway Link相连，Gateway Link由管理员创建。
1.5 平台消息的传输协议
1) 消息引擎之间的传输协议采用JFAP, JFAP是建立在TCP/IP基础之上的；
2) 应用程序和消息引擎之间的通讯协议采用：
- Inbound 基本消息：采用TCP/IP连接
- Inbound 安全消息：采用SSL加密的TCP/IP连接
- MQ通道通讯协议：和MQ网络中的MQ应用程序通讯
- MQ Client通讯协议：使得V5环境中的JMS应用程序和WAS V6的平台消息通讯。
3 仲裁服务
在SOA架构中，企业信息总线主要应该提供三方面的服务，其中包括通讯服务，事件服务以及仲裁服务。
WAS V6的服务集成总线也具有仲裁服务的功能，体现在以下方面：
- 提供消息转换服务；
- 提供消息路由服务；
- 拷贝和转发消息到另外的目标；
- 与非消息工作机制的资源管理器交互，例如：关系型数据库。
我们通过使用Mediation Handler List来控制仲裁服务，该列表是一系列的Java程序，这些Java程序被顺序调用，以完成仲裁服务的功能。
仲裁服务功能是由Mediation Bean（仲裁Bean）来实现的，仲裁Bean就是能够提供各种数据处理功能的普通Java Bean。创建仲裁Bean时要继承AbstractSIMediationBean类，并且实现其SIMediatable 接口，在构造函数中，创建Bean的输入和输出端。
当我们要提供负载的数据处理功能时，我们需要将多个仲裁Bean有机地连接在一起，组成一个仲裁Bean集合。在运行时，对应与每个目标会有一个Mediation Handler，一个Handler列表对应于多个目标，Handler负责当消息到达时从目标中读取消息。Mediation Handler可以被部署为一个简单的JavaBean，也可以是一个无状态的会话EJB，通过WebSphere的工具可以生成EAR包，利用WAS管理控制台将该EAR应用安装到应用服务器上。当Mediation Handler部署成功之后，我们需要把它和某个目标绑定到一起，对于一个目标只能有一个仲裁服务与之对应，每个仲裁服务中可以包含多个仲裁Bean。
4 可用性与扩展性
服务集成总线支持群集功能来实现高可用性和可扩展性。高可用性是指群集中的一个消息引擎工作，当消息引擎或应用服务器出现故障时，位于另一个服务器上的消息引擎将被激活。可扩展性是指一个消息目标可以分跨在群集中的多个活动的消息引擎上，以实现负载均衡。
4.1 可用性
对于单机系统是没有高可用性支持的，只能通过操作系统的HA来实现。
对于Cluster环境，具有高可用性支持，如下图所示：
目标对应于集群中的两个总线成员(应用服务器)，当其中一个消息引擎失败时，可以切换到另外一个消息引擎上，这两个消息引擎共享一个数据存储。当集群添加为总线成员时，会产生一个消息引擎，集群中的任何应用服务器都可以运行消息引擎，但是在某个时刻只能有一个消息引擎是活动的，HA管理器来决定哪个消息引擎处于活动状态，当其失败时，HA管理器激活集群中另外一个服务器上的消息引擎，负载均衡管理器(WLM)将JMS客户端切换到新的消息引擎上。
平台消息的HA策略有
1）Static：不支持Fail Over；
2）1 of N：HA管理器决定谁来接管，可以通过配置指定接管的优先顺序；
3）OS Managed: WebSphere本身不进行管理，由第三方通过JMX管理接口来实现等几种。
平台消息的HA策略可以通过管理控制台进行配置。
4.2 可扩展性
可扩展性可以通过在服务集成总线上部署多个消息引擎来实现，这样，在同一个总线上，有多个消息引擎同时运行，目标被分区到集群中的多个消息引擎上，采用这种方式时，要注意的消息顺序是不能被保证的。
5 服务集成总线的配置和操作
在具体使用服务集成总线功能时，我们需要进行以下具体操作：
- 创建服务集成总线的资源
- 创建JMS资源
- 管理总线资源，包括总线成员，消息引擎，目标，仲裁等
- 对于基础架构的管理：包括关联正确的目标到消息引擎，为消息引擎设置永久存储空间，定义到其他总线的连接，定义到MQ的连接等。
在使用JMS接口时，要定义两种类型的对象：
a）服务集成总线目标，包括SIBus Queue和SIBus TopicSpace
b）JMS目标，包括JMS Queue和JMS Topic
大致的操作步骤如下：
1） 创建服务集成总线: 从管理控制台Service Integration->Buses，选择New。
2) 创建总线成员: 在总线的Additional Properties中，点击Bus Members.
3) 配置消息引擎: Service Integration > Buses > bus_name > Bus Members > bus_member_name->Add Messaging Engine, 为消息引擎指定数据存储：创建数据库和表，创建数据源，配置数据源。
4)创建总线目标：Service Integration->Buses->Additional Properties->Destinations->New，选择正确的目标类型，确定该总线目标位于哪个总线成员上。
5) 管理JMS资源：创建JMS连接工厂，创建JMS队列，为MDB创建Activation Spec。
关于JMS资源的管理和以前没有任何区别，我们都非常熟悉了，在此就不再详述了。关于服务集成总线相关的配置，我们下面会给出一个具体的例子给与说明。
5.1 配置举例
这里我们给出一个小小的配置实例，在此例子中，我们创建了一个集群，一条总线，两个消息引擎，并且配置了FailOver的策略，来保证某一个消息引擎失败时，可以切换到另外一个之上继续运行。
1） 创建集群TestCluster，增加两个集群成员tcServer1和tcServer2，具体步骤就不再详述了；
2） 创建SIBus的数据源：创建数据库sibdb，在此我们使用DB2数据库；创建JDBC Provider；创建Data Source:jdbc/sibdatastore；
3） 创建一个服务集成总线WAS6BUS；
4） 为服务集成总线WAS6BUS，增加总线成员，将我们已创建的集群TestCluster加入到总线中，使用jdbc/sibdatastore作为数据源；
5） 创建额外的消息引擎，在我们将集群添加到总线上时，WAS会自动为我们生成一个消息引擎，这里，我们再创建一个消息引擎。每一个消息引擎要使用自己独立的存储空间，可以是不同的数据库，或者是同一个数据库中不同的表。这里我们使用已创建的数据源jdbc/sibdatastore，但是使用不同的模式名：IBMWSSIB1；
6） 配置消息引擎的HA策略：
通过Servers->Core Groups->Default Core Group->Core Group Settings->Policies，创建一个新的1 of N类型的策略：ME-000，指定它的匹配条件为：名称WSAF_SIB_MESSAGING_ENGINE、值TestCluster.000-WAS6Bus（这是我们第一个消息引擎的名称）,增加它优先选择的服务器为tcServer1，选择Failback，指定isAlive Time。
创建第二个HA策略：创建一个新的1 of N类型的策略：ME-001，指定它的匹配条件为：名称WSAF_SIB_MESSAGING_ENGINE、值TestCluster.001-WAS6Bus（这是我们第二个消息引擎的名称）,增加它优先选择的服务器为tcServer2，选择Failback，指定isAlive Time。
7） 重起集群TestCluster，验证tcServer1和tcServer2都启动，两个消息引擎也正常启动。
6 JMS客户端编程
在使用标准的JMS编程接口编写应用程序时，WAS V6中的服务集成总线、目标以及消息引擎等对应用来说都是透明的，程序编写仍然遵循JMS规范，下面给出了部分示例代码：
javax.jms.ConnectionFactory qcf = (javax.jms.ConnectionFactory)ctx.lookup
("java:comp/env/jms/BankJMSConnFactory");
Destination q = (Queue) ctx.lookup("java:comp/env/jms/BankJMSQueue");
connection = qcf.createConnection();
Session session = connection.createSession(transacted, Session.AUTO_ACKNOWLEDGE);
MessageProducer queueSender = session.createProducer(q);
TextMessage outMessage = session.createTextMessage();
- - - - - -
outMessage.setText(msg);
outMessage.setJMSDestination(q);
queueSender.send(outMessage);
|
7 与WebSphere MQ的互操作
V6的消息引擎和MQ队列管理器的连接通过MQLink来实现，MQLink进行V6的消息引擎和MQ之间的格式和协议转换。从MQ的角度来看，V6的消息引擎就相当于另外一个队列管理器，MQ的应用程序可以将消息直接发送到V6的消息平台上；同理，V6的应用程序也可以直接将消息发送到MQ的队列里。
通过MQLink实现了二者的无缝连接，在一个总线上可以定义多个MQLink，但是要求每个MQLink必须要与不同的队列管理器相连。
关于作者  | | | 娄丽军，IBM公司软件部售前工程师，1998年加入IBM公司软件部，四年来一直从事IBM通讯及业务整合中间件(WebSphere Business Integration家族)产品的技术支持工作，是软件部从事该领域技术支持时间最长的工程师之一，拥有WebSphere Business Integration相关的产品经验，这些产品包括WebSphere MQ家族的所有产品：MQSeries, MQ Integrator, MQ Workflow以及CrossWorlds等，并具有很多大型项目的支持经验，曾参与国家税务总局，人民银行清算系统、华夏银行电子联行系统、中国联通计费系统、海关与国家税务总局互连系统，以及公安部、铁道部、中信实业银行、电信等重要客户的有关项目的技术支持。 |
对本文的评价
| 
