引言SOAP最初是作为一种通过 HTTP（Internet）进行同步RPC调用的简单方式出现的，但是后来它发展成可以通过多种协议进行同步和异步RPC调用。 在过去的几年中，企业级应用使用异步传输已经成为了一种趋势。从可靠性处理的角度来看（也就是重发、超时和复制检测），与异步传输分离能够使应用程序具有更好的可伸缩性，并且简化了应用程序中的处理逻辑。因为Web服务是一种快速集成应用程序的技术，所以将现有的企业应用公开为Web服务（服务提供者）已经成为了一种趋势。这样的服务的客户（服务消费者）可以访问这些具有多层可靠性的服务，取决于访问服务所用的协议。 当通过HTTP访问这些服务时，在传输层可以得到有限的保证，并且客户端应用有责任检查超时、重发和复制检测。对于访问响应时间有限的短期业务流程的低容量应用而言，这是一个低成本的解决方案。因为应用必须处理的事情不只是业务逻辑，所以在多应用中传输的低成本被重复实现的复杂性所抵消。 不过，当通过可靠异步传输访问服务提供者时，服务消费者应用可以减少它的某些责任，因为面向消息的中间件（Message Oriented Middleware，MOM）代表该应用处理这些问题，因而应用可以更多地关注业务逻辑。在将遗留MQ应用（支持 fire和forget模型）公开为服务提供者时尤其如此。 基于异步传输的SOAP是一种应用模式，它由于种种原因而赢得了大量的关注，比如长期的业务流程、服务提供者和服务消费者的松散耦合（从服务可用性和组件边界点的分离的角度看）、增强的服务可伸缩性使异步模型执行路径的长度缩短。可以通过两种方式使Web服务的可靠性提高，第一种方式是在SOAP消息本身使用确认（例如，ebXML），另一种方式是在比HTTP更可靠的传输中携带SOAP有效载荷。本文档的重点是，展示为通过异步协议（如Series）携带SOAP有效载荷设计的可选方案，不过，相同的理论可以应用到其他MOM厂商的产品。 本文档假定您基本理解Web服务堆栈和WebSphere MQ。
使用第一种方法，绑定应该是WebSphere MQ或JMS吗？没有工业标准方式来扩展WSDL绑定， 而不同的厂商正在通过把本地传输协议绑定到传输协议中来实现WSDL扩展，不过，与此同时，基于JMS的绑定应该是一种可行的方式，而且Apache的WSIF接近于为这样的绑定指定XMLSchema。参见参考资料部份可以获得更多关于WSIF的更多信息。但是，更困难的部分在于工具（java2wsdl和wsdl2java）的可用性，这两种工具可以用于生成处理异步传输的stub和skeleton，而在当前的WSIF中，这两种工具是不可用的。 第二种方法的例子是Apache的Axis框架（framework），它允许在客户端和服务器锻连接处理器。第三种方法的例子将在本文中提及（参见参考资料）。
在本文中，我们的兴趣在于评估单向和请求/应答通信模式的设计实现。要求/响应、通知和pub/sub模型是超出了本文讨论范围的传输方式。体系结构中与安全性相关的细节将在下一篇文章中进行讨论。 体系结构下面展示了Axis所用的通过SOAP over HTTP建立调用服务的方式。Java2Wsdl工具生成带有HTTP绑定的WSDL。Wsdl2Java工具生成客户端应用所需的stub和服务器端所用的skeleton。 |
| 优点 | 缺点 |
|---|---|
|
|
部署
要部署上面的服务。就必须在服务器上完成以下任务：
1. 必须将所需的类放入CLASSPATH环境变量中
2. 编译Web服务源文件
3. 启动Simple Axis Server（也可以使用OR Tomcat）
4. 为部署SimpleTransformation服务准备WSDD文件。请注意：在这种情况下，没有WSDD文件生成。必须手工准备WSDD文件。如下所示：
清单3. 用于服务提供者的WSDD
<deployment xmlns="http://xml./Axis/wsdd/" xmlns:java="http://xml./Axis/wsdd/providers/java" name="TransformationService"> <service name="SimpleTransformation" provider="java:RPC"> <parameter value="javaDemos.server.SimpleTransformation" name="className"/> <parameter value="*" name="allowedMethods"/> </service> </deployment>
5. 将“SimpleTransformation”的WSDD文件部署到Axis引擎java org.apache.Axis.utils.Admin server SimpleTransformation.wsdd中[使用java org.apache.Axis.utils.Admin服务器]
6. 现在，我们需要在客户端上配置JMS MQSeries Transport。客户端WSDD文件如下所示：
清单4. 用于消费者的WSDD
<deployment xmlns="http://xml./Axis/wsdd/" xmlns:java="http://xml./Axis/wsdd/providers/java"> <handler name="JMSMQSender" type="java:javaDemos.jms.JMSSOAPSender"/> <transport name="JMSTransport" pivot="JMSMQSender"/> </deployment>
7. 要部署客户端WSDD，请执行以下命令：
java org.apache.Axis.utils.Admin client jmsclient-deploy.wsdd
可选的客户端指示部署信息只用于客户端。您现在所做的是部署您的体系结构。
实现客户端
用于调用Web服务的客户端如下所示。调用“call.addParameter”的就是一个重要的客户端。它在发送请求之前编码SOAP有效载荷。
“base64Binary”表示Base64编码的任意二进制数据。对于base64Binary数据，使用RFC
2045]的6.8节定义的Base64 Content-Transfer-Encoding编码整个二进制流（stream）。
不编码SOAP有效载荷可能会在响应时间上对性能造成严重的影响。
清单5. AXIS客户端代码片断
public static void main(String args[]) {
// Method Name to invoke for the Web Service
String methodName = "setupTransformation";
/* Read the files .xml and .xsl and convert them into byte
* arrays to be sent to the Web service
*/
...
...
JMSTransport transport = new JMSTransport(connectorMap, cfMap);
// Create the Service call
Service service = new Service();
Call call = (Call) service.createCall();
QName qname= new QName("SimpleTransformation", methodName);
call.setOperationName(qname);
call.addParameter(new javax.xml.namespace.QName("", "byte1"),
new javax.xml.namespace.QName(
"http://www./2001/XMLSchema", "base64Binary"),
byte[].class, javax.xml.rpc.ParameterMode.IN);
call.addParameter(new javax.xml.namespace.QName("", "byte2"),
new javax.xml.namespace.QName(
"http://www./2001/XMLSchema", "base64Binary"),
byte[].class, javax.xml.rpc.ParameterMode.IN);
call.setTransport(transport);
call.setReturnType(XMLType.XSD_INT);
result = call.invoke(new Object[] { b1, b2 });
...
...
}执行
在执行客户端程序以访问框架之前，必须完成以下任务：1.
创建MQ对象，比如队列管理器和队列。2. 创建JMS管理的对象，比如队列连接工厂和队列。对于WebSphere
MQ，可以用JMSAdmin创建JMS管理的对象。使用MQSeries安装目录中的“JMSAdmin”进行以下操作：
清单6. JMS provisioning
def qcf(MQ_JMS_MANAGER) qmgr(MQJMS.QManager) press Enter def q(JMS_RequestQueue) qmgr(MQJMS.QManager) queue(RequestQueue) press Enter def q(JMS_ResponseQueue) qmgr(MQJMS.QManager) queue(ResponseQueue) press Enter
现在，我们已经将队列绑定到JNDI对象中。
3. 启动JMS侦听者程序
现在，可以执行客户端程序来访问“SimpleTransformation”Web服务。
性能研究只针对响应时间而不针对吞吐量。假定客户端是单线程模型。
响应时间
| 传输方案 | 运行10次所用的秒数（每个请求所用的秒数） | 运行100次所用的秒数（每个请求所用的秒数） | 运行500次所用的秒数（每个请求所用的秒数） | 运行10000次所用的秒数（每个请求所用的秒数） | 运行50000次所用的秒数（每个请求所用的秒数） |
|---|---|---|---|---|---|
| MAOR MQ | 12（1.2） | 61（0.61） | 285（0.57） | 4941（0.4941） | 24981（0.499） |
| AXIS JMS | 11（1.1） | 64（0.64） | 251（0.502） | 4810（0.481） | 26075（0.5215） |
| Pure HTTP | 7（0.7） | 49（0.49） | 274（0.548） | 3066（0.306） | 14439（0.288） |
不出所料，最初的JVM启动时间和类的装载对数量少的请求有高的开销。随着请求的数量的增加，这种情况得到了缓解。纯HTTP的情况显示了良好的可伸缩性，表明它也可以用于大容量的通信。
根据上面的讨论，两种方法都既有优点也有缺点。新的标准还在不断地涌现，而部署的简易性也在日益提高。HTTP是一种更快速和更便宜的解决方案，但是在节省时间和成本的同时损失的却是可靠性。建议在可靠性不是非常重要的情况下使用HTTP，例如，报告消息而不是数值方面的事务。HTTP的可伸缩性也表明，它可以用于高容量的应用。与HTTP相比，在持久化MQ消息上携带SOAP有效负荷有将近60-80%的额外开销。WSDL生成器简化了客户端代码，同时也使部署更容易。从操作的角度来看，两种方法没有什么大的不同。Axis适配器添加处理器（例如验证）更容易。从互操作的角度来看，接口的设计是非常重要的，而很好地理解参数编码也相当关键。
|
|
