[转载]企业级SOA之路——在Web Service中使用HTTP和JMS

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/steelren/archive/2007/08/23/1756683.aspx

 

原文：http://www.tibco.com/resources/solutions/soa/enterprise_class_soa_wp.pdf
概述
    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服务器)以增加容量，并且要设置负载均衡。这些额外的手段增加了系统架构的成本和复杂度。
    尽管Web服务器可能有很多端口连接在使用，但可能同时只有一小部分在发送消息。在这种情况下，服务器即使还没有满负荷运行，也不能接受更多的连接。服务器的资源并没有被高效的利用。
基于HTTP的SOAP复杂度高
    综上所述，简单的HTTP通讯方式可以被扩展成灵活的、可靠的和可扩展的通讯方式，来充当基于的Web服务的SOA的通讯基础。进行这些改进是通过扩大SOAP层进行的。这些改进，处于不同的批准和采用阶段，充分证明了SOAP的扩展性。然而，他们同样带来了额外的复杂性，并且需要额外的开发资源和/或额外的软件来执行，因此增加了成本。
JMS降低复杂度
    JMS是由Java通讯程序制定的规范。它提供了标准的编程接口用来发送和接收消息，支持同步消息、异步(发布/订阅)消息和请求/响应(点对点)消息。JMS提供商的每个JMS产品，都对如何进行消息发布进行了规范，这些规范涵盖了消息转换、安全、错误处理和服务器与客户端之间的底层通讯协议。这样，为服务传送消息就变得简单易行，不需要在应用系统中额外的编程去实现错误处理和恢复。要获得更多的JMS方面的资料，可以访问java.sun.com/products/jms/index.jsp。
    正因为有这些功能，JMS作为消息transport在应用集成和SOA中被广泛的采用。包括使用JMS作为基于SOAP的服务的transport 。
JMS支持更多的通讯方式
   JMS相比HTTP能进行更灵活的消息发布。JMS支持“发射后不管”通讯，消息在发送后不必等待应答，并且可以存放在持久存储或者Queue中。基于Queue的方式可以进行异步通讯，消息发送时，消息的最终消费者不需要连接到服务器上。当消息的消费者连接到JMS服务器上时，消息就可以被发送到消息的消费者。HTTP就明显不能支持这种异步的通讯方式。当使用HTTP时，开发人员必须编程使应用系统支持异步方式，并且要有效的重新创建消息传送。
    除了在消息生产者和消费者之间进行点对点的消息通讯，基于JMS Topic的架构可以支持发布/订阅方式，使用这种方式一个消息生产者可以与多个消息消费者同时进行通讯。生产者向给定的Topic上发送任何消息都可以被订阅了这个Topic的每一个消费者接收到。HTTP不能提供这样的功能，除非增加SOAP消息的复杂度或者编程使应用系统实现一对多的消息发送。OASIS的Web服务通知(WSN)技术委员会定义了一套规范，用来对Web服务使用“通知”和“事件”的交互进行标准化。它们构成了使用Web服务架构事件驱动的基础。
Modes of Transport for HTTP and JMS
  Point-to-Point Publish/Subscribe
Synchronous HTTP, JMS JMS
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
    虽然JMS提供了更强大的transport功能，HTTP已经在企业中被广泛的使用。这些事实决定了在企业SOA中，这两种协议会同时存在。不只是你的企业，你的客户和合作伙伴也一样会同时使用这两种协议。所以，你在选择SOAP消息的transport的时候就要考虑在什么时候是用HTTP，什么时候是用JMS。
    你可以尝试是用一些简单的规则，比如在企业内部使用JMS作为transport，在与合作伙伴和客户通讯的时候是用HTTP。但是，这种方法也过于简单。可以通过考虑使用哪一种transport更有意义或者使整合变得更简单来选择，来代替使用位置(比如企业的内部或者外部)进行选择。
以下情况适合使用SOAP/HTTP：
l         流程和/或者服务已经使用了基于HTTP的SOAP
l         客户或者合作伙伴正在使用基于HTTP的SOAP，或者想要使用
l         通讯端点的一方是瘦客户端，比如Portal或者Web浏览器
以下情况适合使用SOAP/JMS：
l         需要与移动设备或者非持久连接的服务进行异步或者发布/订阅通讯
l         可靠性和扩展性要求高的服务，比如关键任务服务，数据发布或者同步
l         必须与那些没有Web服务接口并且要求整合的应用系统连接的时候
l         客户或者合作伙伴使用基于JMS的SOAP
    大多数企业都可能会用到多协议，为不同的情况选择最合适的transport协议，这是最基本的要求。
实现企业级SOA
    为了使企业SOA的作用达到极致，不论在底层使用的是什么样的通讯协议，所有的企业中的服务都要被重用。在企业级的SOA中，服务之间使用多种不同的协议进行通讯。比如HTTP，还有其他很多种协议。JMS由于提供了更好的灵活性、可靠性和扩展性，经常被要求严格的、关键任务的服务所使用。这就意味着SOA需要在使用不同的transport和协议的服务间进行通讯，不管他们是不是Web服务。
    要对不同的协议进行无缝的连接，提供各个服务间的连接能力(使企业中的服务实现重用)，需要企业服务总线(ESB)来完成这个工作。TIBCO BusinessWorks产品提供所有的ESB功能，包括高级ESB服务和服务集成环境，使开发人员可以不去关心底层系统的复杂性并提高生产效率。
    SOA的最主要的目标之一，就是使那些使用HTTP，JMS和其他协议的系统能够一起工作，实现企业范围内的服务重用，但是实现这个目标是很困难的。幸运的是，客户可以通过ESB在SOA中选择和使用多种协议。通过ESB本身支持的基于HTTP、JMS或者其他协议的SOAP和XML，跨协议路由，数据转换或者其他功能，可以最大限度的实现跨协议的服务重用。与HTTP和JMS一样，ESB是一项成熟的技术。自从2001年开始，超过1000家用户使用了TIBCO BusinessWorks ESB产品，使那些基于HTTP、JMS和其他协议的软件系统能够作为企业级SOA的一部分进行协同工作。简而言之，你想要灵活的选择协议或者技术，就要走上通往企业级SOA的道路。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/steelren/archive/2007/08/23/1756683.aspx