Web 服务概念性体系结构（WSCA 1.0）
WSCA 1.0 第 2 部分
Heather Kreger, , IBM Software Group
2002 年 4 月 01 日
本文从组件、交互和应用程序开发模式的观点描述了 Web 服务体系结构。这个体系结构是 IBM 对 Web 服务方法进行实例化的一张蓝图。它是构建和部署 Web 服务应用程序的框架。
在本系列文章的 第一部分，我们介绍了Web服务的定义，Web服务的模型， 讨论了Web 服务的一个概念性协议栈以以及选择网络协议的标准，同时回顾了基本的基于 XML 的消息传递分布式计算。接下来，我们将讨论服务描述在 Web 服务体系结构中的角色，说明支持静态和动态 Web 服务应用程序的服务发布技术的范围。我们还将围绕服务发布讨论服务发现的角色。
服务描述：从 XML 消息传递到 Web 服务
服务提供者是通过服务描述将所有用于调用 Web 服务的规范传送给服务请求者的。要实现 Web 服务体系结构的松散耦合，并减少服务提供者和服务请求者之间所需的共识的程度和定制编程与集成的量，服务描述就是关键。例如，不管是请求者还是提供者，都不必了解对方的底层平台、编程语言或分布式对象模型（如果有的话）。服务描述与底层 SOAP 基础结构相结合，足以封装服务请求者的应用程序和服务提供者的 Web 服务之间的这个细节。
基本服务描述
IBM Web 服务体系结构使用 WSDL 作为基本服务描述。WSDL 已经被提交到 W3C 作为标准。WSDL 是一种 XML 文档，它将 Web 服务描述为一组端点，这些端点会处理包含面向文档或面向过程的（RPC）消息的消息。操作和消息都是被抽象描述的，然后它们会被绑定到一个具体的网络协议和消息格式，用来定义端点。相关的具体端点被合并到抽象的端点或服务中。WSDL 可以扩展为允许端点和其消息的描述，不管使用哪种消息格式或网络协议进行通讯都可以。然而，目前经过描述的绑定只能用于 SOAP 1.1、HTTP POST 以及多用途因特网邮件扩展（Multipurpose Internet Mail Extensions，MIME）。
IBM Web 服务体系结构中对 WSDL 的使用按照常规将基本的服务描述分成了两部分：服务接口和服务实现。这使每个部分都可以被分开独立定义，并可以由另一部分重新使用。
图 5. 基本服务描述
服务接口定义是一种抽象或可重用的服务定义，它可以被多个服务实现定义实例化和引用。您可以将服务接口定义想象成接口定义语言（Interface Definition Language，IDL）、Java 接口或 Web 服务类型。这使常见的行业标准服务类型可以被多个服务实现者定义和实现。这类似于在编程语言中定义抽象接口然后得到多个具体实现。服务接口可以由行业标准组织定义，如 RosettaNet，或保健行业的 HL7。
服务接口包含 WSDL 元素，它们组成了服务描述中的可重用部分，这些元素有：WSDL: binding、WSDL: portType、WSDL: message 和 WSDL: type 元素，如图 5 中所描述。WSDL: portType 元素中定义了 Web 服务的操作。操作定义了输入和输出数据流中可以出现的 XML 消息。您可以将操作想象成编程语言中的方法说明。WSDL: message 元素指定哪些 XML 数据类型组成消息的各个部分。WSDL: message 元素用于定义操作的输入和输出参数。WSDL: types 元素中描述消息中复杂数据类型的使用。WSDL: binding 元素描述特定服务接口（WSDL: portType）的协议、数据格式、安全性和其它属性。
服务实现定义是一个描述给定服务提供者如何实现特定服务接口的 WSDL 文档。Web 服务被建模成 WSDL: service 元素。服务元素包含一组（通常是一个）WSDL: port 元素。端口将端点（例如网址位置或 URL）与来自服务接口定义的 WSDL: binding 元素关联起来。
为了说明职责的安排，开放应用程序组（Open Applications Group，OAG）可能会为开放应用程序组集成规范（Open Applications Group Integration Specification，OAGIS）购买标准定义一个服务接口定义。这个服务接口定义会定义 WSDL: type、WSDL: message、WSDL: portType 和 WSDL: binding。该规范可能会在一些知名网站上被发布（例如 http://www.openapplications.org/）。
服务提供者可以选择开发实现 OAGIS 购买订单服务接口的 Web 服务。服务提供者会开发一个服务实现定义文档，描述 WSDL 设备、端口和地址位置元素，这些元素描述提供者的 Web 服务的网址及其它特定于实现的细节。
服务接口定义和服务实现定义结合在一起，组成了服务完整的 WSDL 定义。这两个定义包含为服务请求者描述如何调用以及与 Web 服务交互的足够信息。服务请求者可以要求获得其它关于服务提供者端口的信息。此信息由服务完整的 Web 服务描述提供。
完整的 Web 服务描述
完整的 Web 服务描述建立在服务基本的 WSDL 定义之上。完整的 Web 服务描述可以解决这样的问题：什么企业在托管这个服务？它是何种类型的企业？与服务相关联的产品有哪些？各种公司和产品类别中与该企业或其 Web 服务相关联的分类有哪些？有没有服务的其它方面（如服务质量）会影响到请求者是否选择调用服务？为了使查找该服务更容易，可以提供哪些关键字？
图 6 中描述了一个完整的 Web 服务描述。
图 6. 完整的 Web 服务描述协议栈
UDDI 提供了一个保存 Web 服务描述的机制。虽然 UDDI 通常会被认为是一种目录机制，但是它也定义了一个用 XML 表示服务描述信息的数据结构标准。UDDI 条目中有四种基本数据结构，如图 7 中所示。
图 7. 基本 UDDI 数据结构
UDDI 条目由 businessEntity 开始。businessEntity 元素对关于企业的信息进行建模，包括基本的企业信息（例如企业名称和联系方式信息是什么？）、分类信息（例如这是何种类型的企业？）以及标识信息（即 Dunn and Bradstreet 编号是什么？）。businessEntity 包含一组 businessService 元素，每个元素对应于企业希望发布的每个 Web 服务。每个 businessService 元素都包含和 businessEntity 元素的 Web 服务有关的技术性和描述性信息。businessService 包含一组 bindingTemplate 元素。bindingTemplate 描述访问信息（例如端点地址），还描述 businessService 如何使用各种不同的技术规范。技术规范在这里的模型是 tModel。tModel 可以为很多不同概念建模，如：一种服务、一个诸如 HTTPS 之类的平台技术或一个类别。与 businessService 相关联的那一组 bindingTemplate 元素代表了 businessService 所使用的技术的印记。
在 IBM Web 服务体系结构中，完整的 Web 服务描述包括用于端点描述的一层，这个端点描述使用 UDDI 条目向服务描述添加企业和实现环境。
端点描述遵循 IBM 提出的结合 WSDL 使用 UDDI 的约定。端点描述使用 UDDI 提供企业信息和类别的标准表示。这个 UDDI-WSDL 约定规定了如何从和 Web 服务相关联的 UDDI 条目中得出服务接口定义和服务实现定义的 WSDL 描述。这个约定对于在 IBM Web 服务体系结构中使用 UDDI 作为基于 WSDL 的服务的服务注册中心来说至关重要。
端点描述向应用到服务的特定实现的服务描述添加了另外的语义。安全属性可以定义对 Web 服务的访问进行控制的策略。服务质量属性指定面向性能的能力，例如服务在一定时间内作出响应的能力，或所支持的可靠消息传递的级别。服务开销属性描述服务的资源需求。还可以定义支持哪些对话语义。
服务描述协议栈中的最后一层是协议描述。协议描述反映两个企业伙伴之间为了完成一个多步企业交互而进行的 Web 服务调用的一个简单的编排。例如，“协议定义”定义了购买协议中诸如购买者和出售者之类的角色。协议定义规定了每个角色必须达到的要求。例如，出售者必须有接受报价请求（request for quote，RFQ）消息、购买订单（purchase order，PO）消息和付款消息的 Web 服务。购买者的角色必须有接受报价（RFQ 响应信息）、发票消息和帐户摘要信息的 Web 服务。这个简单的 Web 服务到企业角色的编排对于在企业伙伴之间建立多步的、面向服务的交互来说至关重要。在很多不同的企业协议标准下，一个给定的服务请求者或服务提供者也许能够扮演购买者或出售者的角色。通过显式地建模企业协议和每个节点在企业协议中扮演各种角色的能力，请求者可以选择在面对各种提供者企业伙伴时加入哪种企业协议。
这个领域充满了创新。对于企业协议定义来说，目前还没有一个单独的标准。ebXML 协作-协议概要和协定规范（ebXML Collaboration-Protocol Profile and Agreement Specification）描述了这些概念，但不是根据作为该体系结构的一部分描述的 Web 服务技术而描述的。Web 服务流程描述和 Web 服务端点描述这两层正处于开发中，它们可以提供这个级别的服务描述。
服务描述的发布和发现
服务发布
Web 服务的发布包括服务描述的生成和之后的发布。发布可以使用各种不同机制。
生成服务描述
我们可以生成、手工编码服务描述，也可以根据已有的服务接口定义组成服务描述。开发者可以手工编码整个服务描述，包括 UDDI 条目。有些工具可以从编程模型和可执行 Web 服务的部署生成 WSDL，还有可能生成来自元数据构件的部分 UDDI 条目。部分服务描述可能已经存在（例如，Web 服务可以基于一个行业标准服务接口定义），这样就只须进一步生成一小部分就可以了。
发布服务描述
服务描述可以使用各种不同机制来发布。根据应用程序将使用服务的动态程度，这些不同的机制提供不同的能力。服务描述可以使用多种不同机制发布到多个服务注册中心。
最简单的情况是直接发布。直接发布意味着服务提供者直接将服务发布给服务请求者。这可以通过使用电子邮件附件、FTP 站点甚至光盘分发来实现。直接发布可以在企业伙伴双方就在 Web 上使用电子商务的条款达成一致后进行，或在请求访问服务的服务请求者支付了费用之后进行。在这种情况下，服务请求者可以保留服务描述的一份本地副本。
稍微更动态一点的发布使用 DISCO 或 ADS。DISCO 和 ADS 两者都定义了一个从给定 URL 获取 Web 服务描述的简单的 HTTP GET 机制。增强的服务描述资源库会提供服务描述的一个本地高速缓存，不过还提供了附加的搜索能力。对于在企业内部跨越主机的服务描述资源库来说，服务提供者会向专用的 UDDI 节点发布。我们可以根据发布到节点的 Web 服务的域的范围，使用几种专用的 UDDI 节点。
- 内部企业应用程序 UDDI 节点（Internal Enterprise Application UDDI node）节点：公司内部为了进行内部企业应用程序集成而使用的 Web 服务应该被发布到这一类 UDDI 节点。此类 UDDI 节点的范围可以是部门的或公司的单独的应用程序。这些 UDDI 位于防火墙之后，允许服务发布者对他们的服务注册中心和它的访问权、可用性以及发布要求有更多的控制。
- 门户网站 UDDI 节点（Portal UDDI node）节点：由公司发布以供外部伙伴查找和使用的 Web 服务可以使用门户网站 UDDI 节点。门户网站节点运行在服务提供者的防火墙之外或之间。这种专用 UDDI 节点只包含公司希望向来自外部伙伴的请求者提供的那些服务描述。这允许公司保留对他们服务描述的控制、UDDI 节点的访问以及 UDDI 节点的服务质量。此外，通过使用门户网站中固有的基于角色的可见性，企业将服务描述的可见性局限在允许看到它们存在的伙伴中。
- 伙伴目录 UDDI 节点（Partner Catalog UDDI node）节点：由特定公司使用的 Web 服务可以被发布到伙伴目录 UDDI 节点。伙伴目录 UDDI 节点位于防火墙之后。此类专用 UDDI 节点只包含来自合法企业伙伴的经过允许的、测试过的、有效的 Web 服务。此类 Web 服务的业务环境和元数据可以被定位到特定的请求者。
- 电子市场 UDDI 节点（E-Marketplace UDDI node）节点：对于服务提供者打算用来与其它 Web 服务竞争请求者的业务的 Web 服务来说，服务描述应该被发布到电子市场 UDDI 节点或 UDDI 运营商节点。电子市场 UDDI 节点由一个行业标准组织或社团托管，包含特定行业中的企业的服务描述。我们可以要求这些服务支持特定的标准、可搜索元数据、接口或数据类型。电子市场 UDDI 节点一般会过滤掉某些非法的条目，并提供有保证的服务质量。
UDDI 运营商节点：如果您希望 Web 服务可以被潜在的新的企业伙伴或服务用户发现，还可以将其发布到 UDDI 运营商节点。IBM、Microsoft 和 Ariba 都支持、复制和托管 UDDI 运营商节点。在发布 UDDI 运营商节点的时侯，如果要让潜在的服务请求者发现服务的话，完整的业务环境和经过深思熟虑的分类法是很必要的。
图 8. 服务发现连续体
图 8 展示了从发布和发现中最静态、最简单的技术到最动态、更复杂的技术的连续体。Web 服务的用户或实现者不必严格遵循这个发展顺序。
服务发现
Web 服务的发现包括获取服务描述和使用描述。获取过程可以使用各种不同机制。
获取服务描述
和发布 Web 服务描述一样，根据服务描述如何被发布以及 Web 服务应用程序可能达到的动态程度，获取 Web 服务描述也会有所不同。服务请求者将在应用程序生命周期的两个不同阶段，即设计时和运行时查找 Web 服务。在设计时，服务请求者按照他们支持的接口类型搜索 Web 服务描述。在运行时，服务请求者根据他们通讯的方式或公告的服务质量搜索 Web 服务。
使用直接发布方法时，服务请求者在设计时对服务描述进行高速缓存，以在运行时使用它。服务描述可以被静态地用程序逻辑表示，并存储在文件或简单的本地服务描述资源库中。
服务请求者可以在设计时或运行时在服务描述资源库（简单的服务注册中心或 UDDI 节点）中检索一条服务描述。查找机制需要支持一种查询机制，它提供按接口类型（基于 WSDL 模板）、绑定信息（即协议）、属性（如 QOS 参数）、所需的中介类型、服务分类法、企业信息等等的查找。
不同类型的 UDDI 节点会显示可以选择的运行时绑定 Web 服务的数目、多选一的策略，或者调用服务之前必须由请求者作出预选的量。
内部企业应用程序 UDDI 节点和伙伴目录 UDDI 节点将不需要预选来建立对服务的信任。服务选择可以建立在绑定支持、历史性能、服务质量分类、相似性或负载平衡的基础之上。
电子市场 UDDI 节点将有更多的运行时服务可以选择。必须执行某种预选以保证 Web 服务提供者是有价值的伙伴。我们可以根据价格承诺、开销、经过允许的伙伴列表的出席情况，同样还有绑定支持、历史性能、服务质量分类和相似性来选择服务。
如果服务请求者从 UDDI 运营商节点查询 Web 服务提供者，他们在预选可能的服务提供者时就必须尽可能谨慎和认真。应该有一个有效和准确的机制就位，过滤掉无用的服务描述和没有价值的服务提供者。
使用服务描述
在获取了服务描述之后，服务请求者需要处理它以调用服务。服务请求者使用服务描述生成对 Web 服务的 SOAP 请求或特定于编程语言的代理。该生成可以在设计时或运行时进行，从而对 Web 服务的调用进行格式化。我们在设计时和运行时可以使用各种工具从 WSDL 文档生成编程语言绑定。这些绑定表示应用程序的 API，并封装了来自应用程序的 XML 消息传递的细节。
在下一部分，我们将描述基本 Web 服务体系结构的扩展，电子商务需要这些扩展才能使用 Web 服务。