6.4 Web Service协议堆栈

2001年4月，W3C联盟召开了第一次Web Service专题研讨会，其目的是为探索W3C应向哪个方向发展，才能更好地实现Web Service架构的标准化，会议期间第一次提出了“Web Service堆栈”的构想。如今，随着Web Service技术的发展，2004年2月11日，W3C提出了最新的Web Service协议栈，其内容如图6-3所示。

在协议堆栈的下层为网络通信部分，Web Service继承了Web的访问方式，使用HTTP（S）作为网络传输的基础，除此之外Web Service还采用了其他的传输协议如SMTP、FTP、JMS、IIOP等。在消息处理方面，Web Service使用了SOAP简单对象访问协议作为消息的传送标准。在此之上是Web Service描述语言WSDL，用以描述WebService的访问方法。位于最顶层的是与Web Service和应用程序，以及Web Service之间相互集成相关的协议，其中包含发现、集成等若干方面。在这一层，我们将介绍UDDI协议，UDDI也是Web Service领域中赫赫有名的动态发现协议。除了底层的传输协议外，整个Web Service协议栈是以XML为基础的，XML语义的精确性和灵活性赋予了Web Service强大的功能。除了这些基本协议，还有一些需要讨论的问题，那就是安全和管理，这两大问题不是Web Service可以独立解决的。比如，在安全方面就需要同PKI、LDAP等相结合。

1．简单对象访问协议

W3C于2000年5月8日发表了Simple Object Access Protocol（SOAP，简单对象访问协议）1.1版本，这是一种基于XML的协议，通过SOAP，应用程序可以在网络中进行数据交换和远程调用。图6-4显示了SOAP在网络应用程序之间交换数据的方式。

看到这里，有的读者会问：SOAP实质上是一个基于XML的RPC标准，它与同为RPC标准的CORBA、COM/DCOM有什么区别呢？首先让我们再回顾一下CORBA和COM/DCOM。

CORBA（Common Object Request Broker Architecture）公共对象请求代理体系结构是由OMG组织制订的，是一种标准的面向对象应用程序的体系规范。由对象请求代理ORB（Object Request Broker）、对象服务、公共设施、域接口和应用接口这几个部分组成。其核心是对象请求代理ORB，ORB提供了一种机制，使对象可以透明地发出请求和接收响应。分布的互操作对象可以利用ORB构造互操作应用。ORB可看做是在对象之间建立客户/服务关系的中间件。基于ORB，客户可以透明地调用服务对象提供的方法。该服务对象可以与客户运行在同一台机器上，也可以运行在其他机器上通过网络与客户进行交互。ORB截取客户发送的请求，并负责在该软件总线上找到实现该请求的服务对象，然后完成参数、方法调用，并返回最终结果。

COM/DCOM（Component Object Model / Distributed Component Object Model）是微软公司提出的分布式组件对象模型标准，支持在局域网、广域网甚至Internet上不同计算机对象之间的通信。DCOM基于COM的应用程序、组件、工具等来处理网络协议低层次的细节问题，因而本身不必关心太多的网络协议细节，使用户能够集中精力解决自身所要求的问题。DCOM位于应用程序的组件之间，将组件以不可见的方式组合在一起，形成具有完整功能的应用程序。

明确了CORBA和COM/DCOM的概念以后马上可以明确的是SOAP同CORBA、COM/DCOM不是同一层面上的概念。SOAP是一个基于XML的分布式对象通信协议，CORBA是分布式应用的服务标准，COM/DCOM则是一个组件模型。无论是CORBA还是DCOM都可以使用SOAP作为分布式对象通信的标准。除了概念上的区别外，SOAP和CORBA、COM/DCOM还有更多的差异。

（1）采用CORBA或COM/DCOM构造的应用程序不能混用，二者不能协作。 但SOAP却可以在二者之间建立联系，实现CORBA和DCOM的整合。

（2）SOAP使用XML进行编码，是一个开放式的协议。 SOAP本身并没有定义信息的语义、服务质量、事务处理等问题，但CORBA和DCOM对这些问题都有相应的约定。

（3）SOAP仅仅是一个对象通信协议，类似于CORBA中的IIOP，是一个层次较低的协议。 相比起来，CORBA和COM/DCOM协议则复杂得多。

（4）SOAP是与应用平台完全无关的。 虽然CORBA也可以在各种平台上运行，但CORBA只能同采用CORBA标准的应用程序通信；而COM/DCOM则只能在微软的平台中应用。

我们可以将SOAP理解为：HTTP+XML+RPC。这里，HTTP是网络中的通信协议，XML是数据格式的协议。虽然将SOAP理解为RPC的一种并不准确，因为SOAP并非单纯的远程进程调用，SOAP要强大得多，但以RPC的观点看待SOAP有助于我们理解SOAP。

由于SOAP采用XML和HTTP封装通信消息，所以SOAP需要增加XML解析和HTTP传输的额外开销。但是SOAP同时也继承了XML和HTTP的优点，严格的语法格式使XML在Internet中得到了广泛应用。所以SOAP是一个非常优秀而且潜力巨大的协议，Web Service正是一种建立在SOAP之上的服务模型。

2．Web Service描述语言

我们都知道，在通常的开发过程中，对象接口一定具备相应的SDK描述文档，WebService也是一种对象，是一种被部署在Web上的对象。很自然，我们也完全需要有对Web Service这个对象进行描述的SDK文档。当然这两者不完全相同，一方面，目前在Web上的应用已经完全接受了XML这个基本的标准，WSDL（Web Service描述语言，Web Service Description Language）是基于XML的标准，另一方面Web Service的目标是即时装配、松散耦合，以及自动集成，这意味着SDK描述文档应当具备被机器识别的能力。也就是说，对于使用标准化的消息格式和通信协议的Web Service，它需要以某种结构化的方式（XML）对Web Service的调用和通信加以描述，实现这一点显然非常重要，这是Web Service即时装配的基本保证。WSDL 包含了一套基于XML的语法，将Web Service描述为能够进行消息交换的服务访问点的集合，从而满足这种需求。WSDL定义了可被机器识别的SDK文档，同时WSDL也可用于描述自动执行应用程序在通信中所涉及的细节问题。

因为WSDL的目标是描述如何使用程序来调用Web Service，所以我们可以把WSDL理解为Web Service的SDK标准，或者是Web Service的接口定义。对于服务提供者来说，他们既需要描述他们提供的Web Service是做什么的，还要描述如何使用他们提供的Web Service。

3．统一描述、发现和集成

UDDI（Universal Description Discovery and Integration，统一描述、发现和集成）提供了一种Web Service的发布、查找和定位方法。我们可以将UDDI理解为一种目录服务，Web Service提供者使用UDDI将服务发布到服务注册中心，而Web Service使用者通过UDDI查找并定位服务。UDDI除了目录服务之外，还定义了一个用 XML表示的服务描述标准。在讨论了SOAP之后我们知道，通过SOAP和XML可以很方便地将不同企业的不同应用集成到一起，但仅仅有SOAP和XML仍然是不够的。SOAP和XML不能够提供任何计算机平台都能支持的端到端的解决方案。UDDI在SOAP和XML之上建立了新的层次，通过UDDI不同的企业可以以统一的标准描述自己的Web Service，或查询其他的服务。

除使用UDDI发布和发现Web Service外，还有其他几种服务的发布方式，其中最简单的方式是直接发布。直接发布就是服务提供者直接将服务通过使用电子邮件附件、FTP 站点甚至光盘发布给服务请求者。直接发布一般是企业双方在使用电子商务的各项条款达成一致后进行，或在请求访问服务的服务请求者支付了费用之后进行。在这种情况下，服务请求者可以保留服务描述的一份本地副本。很明显，直接发布是一种静态的服务发布方式，灵活性很差。

直接发布动态的发布方法有DISCO和ADS。DISCO 和 ADS两者都定义了一个从给定URL获取Web Service描述的机制。然而这种简单的获取服务描述的方法也不能够完全满足动态的电子商务模式的要求，UDDI的功能要强大得多。

UDDI定义了一种Web Service的发布方式。首先UDDI注册中心可以为程序或程序员提供Web Service的位置和技术信息。服务提供者可以向专用的UDDI节点发布服务的描述信息，而服务的使用者可以动态地查询并连接到特定的Web Service。我们可以将这几种服务发布技术放到坐标系中，如图6-5所示。纵坐标度量服务发布的能力，横坐标度量发布的灵活度。从图中我们可以看出，UDDI的发布方式是功能最强大、灵活度最高的。