邓 斌 (dengbin@cn.ibm.com), 高级软件工程师, IBM
2008 年 2 月 28 日 在应用集成的过程中,我们往往会遇到各种各样不同层面的问题:数据格式定义的不一致、不同的接口描述方式、不同的传输协议等等。WPS中内置的服务组件体系结构 (SCA) 实现通过导入 (import) 和导出 (export) 提供的多种服务绑定 (binding) 方式,可以实现服务组件通过 Web Service、MQ、JMS、EJB 等等方式与外界系统的交互。由于服务集成本身是一个很宽泛的话题,本文仅仅通过一个简单的样例描述了 MQ binding 在 WPS 中的实现以及涉及到的相关知识,如果想全面的了解 SCA 在 WPS 中的实现,请参考附录中的相关链接。
WPS及SCA, SDO简述
“面向服务的体系结构”(SOA)核心是为在 WebSphere Process Server 上运行的应用程序提供统一的调用、数据表示编程模型以及监视和管理功能。SOA 就组件及其提供的服务方面而言是软件系统结构的概念性描述,而不会考虑这些组件、服务和组件之间连接的底层实现。服务组件体系结构(SCA)和业务对象(BO)是 SOA 核心的一部分,它们为部署在WPS 上的应用程序提供统一的调用和数据表示编程模型。一个基于组件的框架描述了所有类型的集成,如图:
图1. WPS体系架构图
SCA(服务组件体系结构)
服务组件体系结构(SCA)由一组规范组成,使用面向服务的体系结构描述构建应用程序和系统的模型。面向服务的体系结构(SOA)是一个框架,它将单个业务功能和流程(称为服务)组合起来以实现复杂的业务应用程序和过程。在 SOA 框架中,将相对较大的业务组件作为服务。SOA 将 IT 资产作为一系列可重新使用的服务来构建,这些服务之间松散耦合,与平台和实现无关。
服务组件的实现
服务组件体系结构(SCA)以面向服务的方式提供了业务交易的所有元素 - 访问 Web Service、企业信息系统(EIS)服务资产、业务规则、工作流程和数据库等。服务组件体系结构将业务逻辑与实现分开,以便您可以集中精力组装并集成应用程序,而不必知道有关实现的详细信息。服务组件体系结构支持若干种标准服务实现类型:
-
用于实现 Java 类的 Java 对象。与在 Java 编程语言中一样,处于运行时的 Java 组件的实例被称为 Java 对象。
-
用于实现业务流程的业务流程组件。实现语言是业务流程执行语言(BPEL)及其 IBM 扩展。
-
人员任务组件,用于提供和实现通常由人员在业务流程或集成应用程序中执行的任务。
-
业务状态机组件,当应用程序与具有一组状态的工件配合工作时将使用这些组件。状态机定义了工件在某个时间点可执行的操作。
-
业务规则组件,用于根据上下文来确定业务流程的结果,并可设计为 if-then 规则、决策表或决策树。业务流程中的业务规则允许应用程序对不断变化的业务情况快速地作出响应。规则独立于业务流程本身,您可以随时更改它们,而不必重复流程。
服务组件的导入(import)和导出(export)
服务组件体系结构中的导入和导出功能为 WPS 定义了服务模块的外部接口或访问点。可以导入和导出同一应用程序中的其他模块,也可以导入和导出企业信息系统(EIS)上的其他应用程序。导入过程确定模块外部的服务,使它们可从模块中调用。导出过程允许模块中的组件向外部客户机提供其服务。导入或导出使模块能够访问其他模块,并使应用程序能够访问 EIS 系统上的应用程序,就像它们是本地组件一样。
SDO(服务数据对象)
服务数据对象和业务对象(BO)定义了在服务组件体系结构中定义的组件之间流动的数据。WebSphere Process Server 包含的业务对象是增强型 SDO。这些业务对象基于名为SDO的数据访问技术。SDO 提供了描述异构数据(例如,JDBC ResultSet 和 XML 模式描述的数据)的通用方法。业务对象包含一些对集成解决方案极为重要的扩展,它们可用于进一步描述在服务组件体系结构服务之间交换的数据。业务对象是 WebSphere Process Server 的面向服务体系结构(SOA)核心的一部分。业务对象是一组属性,描述了业务实体(例如职员)、数据操作(例如创建或更新操作)和处理数据的指示信息。集成应用程序的组件使用业务对象来交换信息和触发操作。由于业务对象可表示多种数据,所以它们是很灵活的。
样例场景和相关技术简述
样例中我们使用Java作为SCA服务组件的实现,此Java组件的接口包含两个操作,分别对应华氏温度和摄氏温度的双向转换的一种。对于这个服务,通过导出组件的MQ binding方式来对外界消息客户端提供调用。这里的消息客户端通过IBM的rfhutil工具把消息发送到MQ的请求队列上,实际应用可能会是已有的消息系统应用发出消息到MQ队列上。使用rfhutil工具构造不同的请求消息格式来达到调用Java组件服务接口的不同操作,服务调用的结果同样会通过导出组件(MQ Export Binding)把返回消息发送到MQ的相应队列上。
下面简单介绍一下本样例中涉及到的一些基本概念:
Export Component
导出组件代表了SCA模块对外提供的服务,它会暴露出一个接口以供外部服务调用者或其他SCA模块调用。当调用SCA模块时,导出组件通过绑定(binding)将接口与一种具体的物理实现机制进行映射。WPS支持以下几种绑定方式:SCA binding,Web Service binding,JMS binding,MQ binding,MQ JMS binding。
Messaging Binding
绑定说明了服务如何与外部应用系统进行交互,WPS中的绑定就是针对export和import对应的接口设置相应的协议、传输方式以及消息格式,通常绑定包含SCA binding,Messaging binding和Web Service binding等,其中Messaging binding又包含以下三种消息绑定方式,分别为:
JMS Binding
JMS绑定提供SCA组件与外部JMS系统的集成交互,这种交互由符合JCA1.5规范的JMS资源适配器提供支持,WPS中有针对SIB(Service Integration Bus) JMS资源适配器的完整支持。
MQ JMS Binding
MQ JMS绑定通常用于从WPS运行环境直接与基于MQ的JMS系统进行集成。BO与JMS消息格式的映射由JMS Data Binding完成。
MQ Binding
本文样例中使用的绑定方式,这里重点介绍一下。MQ binding提供一种对于MQ用户更加熟悉的方式来工作,通常用来与WebSphere MQ或WebSphere Message Broker应用系统交互。当安装一个包含MQ binding 的SCA模块时,WPS运行环境会自动配置与WebSphere MQ进行连接所需要的资源。不过,MQ的管理员必须事先配置相应的队列管理器和目标队列等资源。
当设置MQ binding的属性时,消息资源的指定方式有两种:一种是hard-coded方式,如我们在样例中使用的(参考3.2),另一种为通过事先定义的WebSphere MQ资源的JNDI名字指定,可以通过WPS的管理控制台配置WebSphere MQ连接工厂和队列目标,连接工厂的配置主要包含下表中的几项:
表1 连接工厂配置项
|
名称
|
JNDI名称
|
队列管理器
|
主机
| |
MQ_QCF
|
jms/mq_qcf
|
QM1
|
localhost
| |
端口
|
通道
|
传输类型
|
CCSID
| |
1414
|
SYSTEM.DEF.SVRCONN
|
CLIENT
|
819
|
然后再配置两个队列目标,如下表所示:
表2 队列目标配置项
|
名称
|
JNDI名称
|
基本队列名
|
目标客户机
| |
WPS_MQ_Request
|
jms/wps_mq_request
|
MQRequest
|
MQ
| |
WPS_MQ_Reply
|
jms/wps_mq_reply
|
MQResponse
|
MQ
|
这里需要注意,当使用JNDI方式设置MQ Binding的消息资源时,必须给WebSphere MQ连接工厂设置必须的定制属性,如下图所示:
图2. 连接工厂定制属性
配置连接工厂和队列目标之后,需要重新启动WPS实例使之生效。
下一步就是具体MQ Binding的设置了,以MQ Export Binding为例,配置界面分为三个部分,Message Resource Configuration、Data format和Function Selector。Message Resource Configuration部分就是我们预先定义的相关JNDI资源,Data format用于指定具体的MQ Data Binding(参见2.3)实现,Function Selector(参见2.4)用来说明把接收消息与接口的操作进行映射,设置界面如下图所示:
图3. JNDI方式配置MQ Export Binding
MQ Data Binding
Data Binding用来进行SCA应用程序与EIS中数据不同格式的映射工作。Export和Import组件都会用到它。MQ Data Binding也就是用来处理SDO和MQ中消息格式的转换。WPS中内置了实现Data Binding的Java类,同时也提供接口给用户实现自己的Data Binding类,这个接口是commonj.connector.runtime.DataBinding。内置的MQ Data Binding实现如下表所示:
表3 内置MQ Data Binding实现类
|
名称
|
实现类
| |
Unstructured Text Message
|
com.ibm.websphere.sca.mq.data.impl.MQDataBindingImplText
| |
Unstructured Binary Message
|
com.ibm.websphere.sca.mq.data.impl.MQDataBindingImplBinary
| |
Serialized as XML
|
com.ibm.websphere.sca.mq.data.impl.MQDataBindingImplXML
| |
Serialized Java Object
|
com.ibm.websphere.sca.mq.data.impl.MQDataBindingImplJava
|
Function Selector
当外部系统发送消息到监听队列时,消息本身必须有一种机制说明它将被服务接口上的哪个方法处理。具体来说,当一个SCA Export组件提供接口供外部系统调用时,这个Export组件会绑定到一个接收队列上。当有一个消息到达此队列,接口会被调用,假设接口本身包含多个操作(operation),那么哪个操作会被调用呢?这个操作选择的过程就是由Java实现的Function Selector来完成,这个Java类需要实现commonj.connector.runtime.FunctionSelector接口。WPS提供了以下四种MQ Function Selector的实现:
表4 内置MQ Function Selector实现类
|
名称
|
实现类
| |
Use handleMessage as the native function
|
com.ibm.websphere.sca.mq.selector.impl.Constant
| |
Use message body's format as the native function
|
com.ibm.websphere.sca.mq.selector.impl.Format
| |
Use Type information as the native function
|
com.ibm.websphere.sca.mq.selector.impl.Type
| |
Use JMS default function selector
|
com.ibm.websphere.sca.mq.selector.impl.TargetFunctionNameProperty
|
场景实现描述
MQ队列管理器和队列创建步骤:
-
首先确认Windows管理工具的本地安全策略中,把目前运行用户加入到“作为服务登录”和“以操作系统方式操作”,如是其他操作系统请参考MQ手册或联机帮助文档。
-
在Windows管理工具的服务窗口中,确认IBM MQSeries服务启动成功。
-
通过开始菜单,启动“WebSphere MQ 资源管理器”。
-
在“WebSphere MQ 资源管理器”中创建新的队列管理器“QM1”,点击“完成”按钮,等待创建成功。
-
此时队列管理器“QM1”应该正确启动,注意此队列管理器的监听端口,默认为1414,我们可以通过netstat 进行验证。
-
创建用于发送服务请求消息的请求队列和接收服务应答消息的接收队列,此样例中请求队列为:MQRequest, 接收队列为:MQResponse。创建成功后如下图所示:
图4.MQ资源管理器配置界面
WPS中服务组件实现步骤
-
新建模块(Module),取名为“MQBindingTest”。
-
双击MQBindingTest项目导航图的Dependencies,打开Predefined Resources按钮,选中其中的“Schema for simple JMS DataBindings”,然后保存,如图所示。
图5 Dependency配置界面
这样,在项目导航图的数据类型(Data Types)区域会自动加载用于消息绑定方式的数据对象定义,我们会在后面的接口定义中用到JMSTextBody。
-
接下来定义一个Interface,命名为ConvertTemprature,加入两个双向操作CtoF和FtoC,如图所示:
图6. 接口定义
-
把接口ConvertTemprature拖拽到装配图上,在弹出的窗口中选择“Component with no Implementation Type”,点击OK。把组建的名称改为“TempratureConverter”,从右键菜单中选择“generate Implementation…”,然后选择Java。在package选择页面接受default package并点击OK。这时在TempratureConverterImpl.java中实现CtoF和FtoC的业务逻辑,代码如下:
清单1 Java组件业务逻辑实现
//摄氏温度转换为华氏温度
public DataObject CtoF(DataObject centigrade) {
System.out.println("CtoF is called!");
float c = centigrade.getFloat("value");
float f = c*9F/5F + 32F;
BOFactory boFactory =
(BOFactory)ServiceManager.INSTANCE.locateService("com/ibm/websphere/bo/BOFactory");
DataObject F =
boFactory.create("http://com.ibm.websphere.jms.data.bindings/schema","JMSTextBody");
F.setFloat("value",f);
System.out.println
("Temprature Centigrade " + c + " equals to Temprature Fahrenheit " + f);
return F;
}
//华氏温度转换为摄氏温度
public DataObject FtoC(DataObject fahrenheit) {
System.out.println("FtoC is called!");
float f = fahrenheit.getFloat("value");
float c = (f - 32F)*5F/9F;
BOFactory boFactory =
(BOFactory)ServiceManager.INSTANCE.locateService("com/ibm/websphere/bo/BOFactory");
DataObject C =
boFactory.create("http://com.ibm.websphere.jms.data.bindings/schema","JMSTextBody");
C.setFloat("value",c);
System.out.println
("Temprature Fahrenheit " + f + " equals to Temprature Centigrade " + c);
return C;
}
|
-
在装配图上右键点击TempratureConverter组件,选择generating Export…—>Messaging Binding…—>MQ Binding,这时弹出窗口用来设置MQ Export Binding的相关属性,对消息资源的配置提供两种方式,“Specify properties for configuring WebSphere MQ resources”和“Specify JNDI name for pre-configured WebSphere MQ resources”。JNDI方式在2.2节已经介绍过,本例实现采用前一种方式,配置如图所示:
图7. MQ Export Binding配置
-
点击确定,在装配图上选中刚生成的Export组件并切换到Properties视图,Detail标签中显示的是导出组件对应的接口信息。Binding标签如下图所示:
图8. Function Selector设置
可以看到输入和输出数据的序列化类型都是Unstructured Text Message,对应到我们使用的数据对象为JMSTextBody。另外Function Selector Type选择“Use message body’s format as the native function”。这个方法选择的实现类已经在2.4节介绍过。“End-point Configuration”标签如下图所示:
图9. MQ Export Binding端点配置
这里的设置正是我们创建绑定时填入的信息,只是要特别注意:CCSID的设置要与MQ上队列管理器的CCSID设置一致,不然可能由于编码字符集不一致造成无法正常通信。
再切换到“Method Bindings”标签,如下图所示,请注意Native Method的设置,这将是我们通过工具rfhutil放在消息体中的信息,Function Selector用来与接口中的方法名进行对应,native method的名称可以和方法名不一致:
图10. Native Method设置
-
到此在WPS中Java组件及MQ Binding导出组件都已开发完成,下一步就是在Project菜单中选择编译(如果没有选中自动编译的话)和生成部署代码,之后在已经启动的WPS服务器上点击右键,在菜单中选择“add and remove projects…”,选中左边的应用程序TempratureConverterEAR点击“Add”,这时应用程序会出现在右边窗口中,最后点击完成。这时经过一段时间应用程序就会部署到服务器上并且处于启动状态。
MQ Export Binding测试
应用程序启动成功后,我们可以利用IBM提供的工具软件rfhutil.exe发送消息到MQ Export Binding的接收队列上。消息体中包含输入的温度值。由于此例中Function Selector Type使用“Use message body’s format as native function”,那么在构造消息时,需要在MQ Message Format部分输入Method Bindings中设定的Native Method值,CtoF或FtoC。如下图所示:
图11. rfhutil工具配置界面
注意
MQ Message Format只允许最多8个字符的值,所以在为MQ Export Binding设置Method Bindings时也要注意Native Method的值不要超过8个字符。
点击Write Q按钮发送消息到MQRequest队列上,查看SystemOut.log日志会有以下输出:
清单2 测试结果输出日志
[07-12-26 15:02:13:740 CST] 0000007d SystemOut O CtoF is called!
[07-12-26 15:02:13:740 CST] 0000007d SystemOut O Temprature Centigrade 20.0 equals
to Temprature Fahrenheit 68.0
|
切换到WebSphere MQ的资源管理器,会看到服务组件已经通过MQ Export Binding把返回消息写入MQResponse队列,也可以通过WebSphere MQ的资源管理器浏览此返回消息。
小结
本文主要介绍了WPS中SCA组件如何与消息系统进行集成,涉及到MQ Export Binding、Data Binding、Function Selector等基本概念。并通过简单样例演示了一个温度转换服务如何为外界的消息系统提供服务。如果希望对消息绑定机制有更进一步的全面了解,请参考附录中的资料。
参考资料
关于作者  | |  |
邓 斌 IBM 软件部 WebSphere 技术工程师,主要为 IBM 业务合作伙伴提供 WebSphere Application Server
和 WebSphere Process Server 的技术支持工作。 |
对本文的评价
|