Web Service中使用HTTP和JMS

企业级SOA之路——在Web Service中使用HTTP和JMS 概述

IT业界在早期有一种误解，认为Web Service等同于面向服务架构(SOA)。实际上，SOA远不止这些。虽然SOAP是一种愈加通用的消息格式，但SOA通常还会需要其他的底层transport。当构建SOA的时候，如何选择这些底层transport是最重要的决定之一。为了支持关键业务应用系统的需要，使用的transport必须要灵活、可靠而且可扩展；必须能够支持不同类型的同步或者异步的服务通讯。HTTP和Java消息服务(JMS)是两种最常用的标准SOAP消息transport。

本文分析了HTTP和JMS各自的优点和协议，重点讲述每一种transport在SOA中的什么地方是最适用的并且演示如何使用它们。

企业SOA通讯需求

灵活性，可靠性，可扩展性。要想最大限度的利用所有的连接服务，这是企业SOA中使用的transport都要具有的三个属性。

在SOA架构中，transport需要能实时(同步)地进行消息传输，以对用户或者系统进行响应。通常企业也要求拥有灵活性，以实现异步通讯服务。一个原因可能是服务并不总是处于可用状态。另一个原因可能是不可靠的或者非持续的网络连接，比如无线网络。

在这些情况下，同步传输会产生失败结果，除非服务本身可以进行“重新请求”操作和错误处理。此外，SOA中流程间的通讯并不总是点对点或者一对一的。通常，服务需要同时对多个流程或者系统发送消息，是一对多的关系。当服务也可以被多个“消费者”请求时，就增加了服务本身的复杂度并且使服务和终点紧密关联。

在很多情况下，服务要求有可靠的transport。如果transport没有提供可靠的消息发布，在应用系统中就必须要增加额外的验证。

最后，transport必须是可扩展的。Transport本身不能对发布消息数量，消息发送方和消息接受方数量的增长进行限制。

HTTP的优缺点

HTTP是SOAP消息中最常用的transport。毕竟，它是原始Web服务标准中的第一个官方的SOAP transport。因此HTTP作为标准的与Web服务连接和通讯的方法，被应用系统和系统提供商广泛地采用。

然而，HTTP本身所具有的点对点、同步的特性成为了它作为服务transport的局限。了解HTTP的功能和局限可以帮助我们找到最合适的地方使用它，并且根据情况考虑使用其他的协议替代它。

HTTP只支持点对点和同步方式

HTTP支持的通讯方式有两方面的局限。首先，因为HTTP是点对点协议，它不提供对多个接收方的并发请求能力。在企业SOA中，一个服务提供者可能需要在流程中的某一步完成后通知其他服务提供者。当使用HTTP时，服务必须明确的识别每一个接收者并向其发送消息。

这种限制可以得到某种程度的缓解。解决方案包括开发一个应用系统来进行这些消息的连续传输或者根据OASIS制定的Web服务通知规范进行编码，SOAP扩展程序对通知进行寻址。Web服务通知规范目前正处于标准设置进程的公共评审阶段。

另一个局限是HTTP只支持同步通讯。很明显，在SOA中既需要同步通讯也需要异步通讯。流程经常会等待人工干预或者其他的流程结束。在这种情况下，HTTP的同步特性就不满足SOAP对transport的要求了。HTTP等待请求的响应，要占用宝贵的通讯资源直到它接收到响应信息。在异步的情况下，在接收到响应消息前可能会有很长时间的等待。 一个并不算完善的使用HTTP的SOAP提供异步消息的解决方案是采用Web服务寻址标准。通过使用Web服务寻址，SOAP消息的整个路径(包括它的返回路径)可以在SOAP消息封装中直接描述。Web服务寻址支持单向消息，双向消息(比如请求/响应和点对点通讯)和长连接对话。但是，这个标准增加了复杂度，需要另外编写程序和购买产品。

除去这些解决方案，情况依然如此：为了使消息能够被成功的发送，HTTP需要发送方和接收方同时被连接。如果网络或者接收程序没有连接，HTTP就不能发送消息。

简单的说，HTTP本身并不具备企业SOA所要求的通讯(通知和异步操作)的灵活性。不论是在应用程序级还是在SOAP级，开发人员都必须要额外编程来实现通知和异步操作。 HTTP提供有限的可靠性

因为HTTP只能提供很有限的错误码，只能根据这些错误码区分很小一部分可能的错误情况，所以这个协议本身是不能保证发送方的消息确实被发送了。然而确保信息被发送是任何企业SOA的一项基本功能。为了保证全部流程的每一步都能持续地进行，发送者的发送的信息必须保证能被指定的接收者接收到。

一个提升企业架构可靠性的方法就是提升网络和应用系统的可靠性，防止网络和应用系统过载。另一个方法是为应用系统额外创建错误处理和修复功能。第三种方法是在SOAP层编写程序，使他符合Web服务可靠消息标准(可靠的Web服务消息)。但是，每一种方法都会增加成本和复杂度，而且他们也无法完全的避免失败。

HTTP缺乏有效的可扩展性

通过HTTP进行通讯的基础架构无法有效的进行扩展。HTTP服务器的架构限制了在任何时候同时连接的端口的个数。理论上端口的数量可以达到65536个，但是为了避免服务器过载，可用的端口的最大数量要小很多。这些连接占用了宝贵的机器资源，限制了可扩展性。一旦达到了限制的数量，就需要增加额外的硬件(比如其他的Web服务器)以增加容量，并且要设置负载均衡。这些额外的手段增加了系统架构的成本和复杂度。

Asynchronous

JMS JMS

当使用JMS作为消息transport，上面表格中的四种消息发送方式组合中的任何一种都可以使用。这种既能使用同步操作又能使用异步操作，既能进行点对点方式，又能进行发布/订阅方式的功能使得JMS在作为消息传送机制时比HTTP有明显的优势，因为HTTP本身只能支持同步和点对点传送。更多的消息传送方式使得流程设计人员在为服务之间的通讯选择最合适的方式时，提供了更灵活的选择。

JMS消息还可以设置优先级，使得对时间敏感的信息流有更多的控制，还可以作为定义服务通讯相关质量的方式。管理员通常使用这种功能调整服务级别，完善整体服务性能。这样在网络拥堵、系统临时宕机或者灾难恢复时，能确保那些拥有相关优先级的关键系统能够正常运行并进行通讯。

JMS更可靠

当应用程序或者网络出现间歇性的失效甚至停止运行，JMS能确保消息从发送者(生产者)传送到接收者(消费者)，HTTP就不能。JMS通过将消息存放在中间服务器上来实现这种可靠的传输。比如，在保证消息传送的情况下，消息会被重发或者重复解析来保证消息确实被传送了。与HTTP不同，JMS内置有错误恢复和消息重传机制，不需要在应用系统或者SOAP层进行编程。

JMS扩展性更强

JMS能更有效的使用系统资源，不论是在一台单独的机器上纵向线性增长的资源还是横向增长跨系统的资源都比HTTP更高效。

Scaling up：JMS可以在消息发送者和接收者之间配置单连接，甚至是在发送大量的并发消息的时候。HTTP需要为每一个请求和响应服务建立socket连接，消耗了大量的系统资源，JMS就没有这种问题。大量减少socket连接可以很好的节省系统资源，能支持更多的通讯量，因此提高了服务器的扩展性。

Scaling out：HTTP和JMS的一个最大的区别是JMS将目的地址与物理主机或者应用系统名称分离。这种独立的命名空间使得JMS实现可以更加的动态。比如，对于一些JMS提供商，发送程序、路由服务器和接受程序可以被添加到相同的topic或者queue上，能够动态的增加负载。这种负载均衡是通过软件来实现的，而不是额外的硬件设备。 基于JMS的SOAP比基于HTTP的SOAP更简单

相比HTTP，很明显JMS的消息传送更灵活、更可靠和更可扩展。所有这些特性都是JMS本身所具有的。不需要像HTTP一样，在应用系统或者SOAP层作开发。使用JMS代替HTTP可以减少编写代码的时间和降低通讯的复杂度，使得开发的周期更短。

何时用HTTP，何时用JMS

服务重用。与HTTP和JMS一样，ESB是一项成熟的技术。自从2001年开始，超过1000家用户使用了TIBCO BusinessWorks ESB产品，使那些基于HTTP、JMS和其他协议的软件系统能够作为企业级SOA的一部分进行协同工作。简而言之，你想要灵活的选择协议或者技术，就要走上通往企业级SOA的道路。