WebService中使用HTTP和JMS.docx

企业级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的一项基本功能。为了保证全部流程的每一步都能持续地进行，发送者的发送的信息必须保证能被指定的接收者接收到。??? 一个提升企业架构可靠性的方法就是提升网络和应用系统的可靠性，防止网络和应用系统