（不能贴图，很抱歉。疑惑：这个东西不用图怎么能讲清楚呢？）
1.1 Web Service技术
Web 服务是描述一些操作（利用标准化的 XML 消息传递机制可以通过网络访问这些操作）
的接口。Web服务描述是用标准的、规范的 XML 概念描述的，称为 Web 服务的服务描述，
这一描述囊括了与服务交互需要的全部细节，包括消息格式（详细描述操作）、传输协议
和位置。该接口隐藏了实现服务的细节，允许独立于实现服务基于的硬件或软件平台和编
写服务所用的编程语言使用服务。这允许并支持基于 Web 服务的应用程序成为松散耦合、
面向组件和跨平台、跨语言实现。由于Web 服务以上性能，使它成为在分布式环境中实现
复杂的聚集或商业交易的最佳体系结构。
1.1.1 Web 服务模型
Web 服务体系结构基于三种角色（服务提供者、服务注册中心和服务请求者）之间的交互
。交互涉及发布、查找和绑定操作。这些角色和操作一起作用于 Web 服务构件：Web 服务
软件模块及其描述。
在典型情况下，服务提供者托管可通过网络访问的软件模块（Web 服务的一个实现）。服
务提供者定义 Web 服务的服务描述并把它发布到服务请求者或服务注册中心。服务请求者
使用查找操作来从本地或服务注册中心检索服务描述，然后使用服务描述与服务提供者进
行绑定并调用 Web 服务实现或同它交互。服务提供者和服务请求者角色是逻辑结构，因而
服务可以表现两种特性。图 1 图示了这些操作、提供这些操作的组件及它们之间的交互。
1.1.2 Web服务体系结构
Web服务体系结构包括如下几个方面：
l Web 服务协议栈
l 网络协议
l 基于XML 的消息传递分布式计算，和基本的 XML 消息传递
l 服务描述
l 服务描述的发布和发现
1.1.2.1 Web 服务协议栈
要以一种可互操作的方式执行发布、发现和绑定这三个操作，必须有一个包含每一层标准
的 Web 服务协议栈。图 2 展示了一个概念性 Web 服务协议栈。上面的几层建立在下面几
层提供的功能之上。垂直的条表示在协议栈中每一层必须满足的需求。左面的文本表示协
议栈的那一层所应用的标准技术。
Web 服务协议栈的基础是网络层。Web 服务要被服务请求者调用，就必须是可以通过网络
访问的。因特网上可以公用的 Web 服务使用普遍部署的网络协议。HTTP 因其普遍性，成
为了因特网可用的 Web 服务真正的标准网络协议。Web 服务还可以支持其它因特网协议，
包括 SMTP 和 FTP。内部网域可以使用可靠消息传递和调用基础结构，如 MQSeries 和 C
ORBA 等等。
上一层是基于 XML 的消息传递，它表示使用 XML 作为消息传递协议的基础。
服务描述层实际上是描述文档的一个协议栈。WSDL 是基于XML的服务描述的标准，这是支
持可互操作的 Web 服务所需的最小标准服务描述。WSDL 定义了服务交互的接口和结构。
因为 Web 服务被定义为可以通过 SOAP 从网络进行访问，并由服务描述表示，所以该协议
栈中的前三层需要提供或使用 Web 服务。最简单的协议栈将包括网络层的 HTTP、XML 消
息传递层的 SOAP 协议以及服务描述层的WSDL。所有企业间或公用 Web 服务都应该支持这
种可互操作的基础协议栈。Web 服务，特别是企业内部或专用 Web 服务，能够支持其它的
网络协议和分布式计算技术。图 3 描述了可互操作的基础协议栈。
图 3 中描述的协议栈提供了互操作性，它使 Web 服务能够利用现有的因特网基础结构。
这将使进入普遍存在的环境的成本非常低。由于可以为选择性和增值的技术提供另外的支
持，灵活性并不会因为互操作性需求而有所降低。
协议栈的最下面三层确立了保证一致性和互操作性的技术，而它们上面的两层，即服务发
布和服务发现，可以用多种解决方案来实现。
任何能够让服务请求者使用 WSDL 文档的操作，不管它处于服务请求者生命周期的哪个阶
段，都符合服务发布的标准。该层中最简单、最静态的示例就是服务提供者直接向服务请
求者发送 WSDL 文档。这被称为直接发布。电子邮件是直接发布的载体之一。直接发布对
静态绑定的应用程序来说很有用。另外，服务提供者还可以将描述服务的文档发布到主机
本地 WSDL 注册中心、专用 UDDI 注册中心或 UDDI 运营商节点。
因为 Web 服务如果没有被发布就不能被发现，所以说服务发现依赖于服务发布。该层的各
种发现机制和一组发布机制互相平行。任何允许服务请求者获得对服务描述的访问权，并
在运行时使应用程序能够使用该服务描述的机制都符合服务发现的标准。最简单、最静态
的发现的示例是静态发现，其中服务请求者从本地文件获取 WSDL 文档。这通常都是通过
直接发布获取的 WSDL 文档，或者前面查找操作的结果。另外，也可以通过使用本地 WSD
L 注册中心、专用 UDDI 注册中心或 UDDI 运营商节点在设计时或运行时发现服务。我们
将在“服务发现”部分更详细地讨论各种不同的服务发现机制。因为 Web 服务实现是一种
软件模块，所以通过组建 Web 服务来产生 Web 服务是很自然的。Web 服务的组合可以扮
演很多角色之一。企业内部的 Web 服务可能会相互合作，从而对外显示出一个单独的 We
b 服务接口，或者，来自不同企业的 Web 服务可以相互合作，从而执行机器到机器、企业
到企业的事务。另外，工作流程管理者还可以在参与业务流程的时侯调用每个 Web 服务。
最上面一层，即服务流程，描述了如何执行服务到服务的通讯、合作以及流程。WSFL 用于
描述这些交互。Web 服务这个主题在它自己那一部分，即“业务流程、工作流程和 Web 服
务”中有所描述。
要使 Web 服务应用程序满足当今电子政务的迫切需求，就必须提供企业级基础结构，包括
安全性、管理和服务质量。这几个垂直条在协议栈的每一层都必须得到解决。每一层的解
决方案可以彼此独立。随着 Web 服务范例的采用和发展，将会出现更多此类垂直条。我们
将在“真正电子政务的 Web 服务”部分讨论这些垂直条。
该协议栈的最下面几层表示基础 Web 服务协议栈，它们相对于协议栈中上面几层来说更成
熟，也更标准。Web 服务的成熟和采用将会带动协议栈中上面几层和垂直条的开发和标准
化。
1.1.2.2 网络层
Web 服务协议栈的最底层是网络层。该层可表示任意多个网络协议：HTTP、FTP、SMTP、消
息排队（Message Queuing）、因特网 ORB 间协议（Internet Inter ORB Protocol，IIO
P）上的远程方法调用（Remote Method Invocation，RMI）、电子邮件等等。在任何给定
的情况下使用的网络协议都依赖于应用程序需求。
对于可以从因特网访问的 Web 服务，人们选择网络技术的时侯通常会倾向于选择普遍部署
的协议，如 HTTP。对于内部网中提供和使用的 Web 服务，使用另外的网络技术也会被认
同。我们可以根据其它需求选择网络技术，包括安全性、可用性、性能以及可靠性。这使
得 Web 服务可以利用已有的功能更高级的联网基础结构和面向消息的中间件，如 MQSeri
es。在有多种网络基础结构的企业中，HTTP 可以用来在这些基础结构之间搭建桥梁。
1.1.2.3 基于 XML 消息传递的分布式计算
Web 服务体系结构最基础的支柱是 XML 消息传递。当前 XML 消息传递的行业标准是 SOA
P。
SOAP 是一种简单的、轻量级的基于 XML 的机制，用于在网络应用程序之间进行结构化数
据交换。SOAP 包括三部分：一个定义描述消息内容的框架的信封、一组表示应用程序定义
的数据类型实例的编码规则，以及表示远程过程调用（remote procedure calls，RPC）和
响应的约定。SOAP 可以和各种网络协议（如 HTTP、SMTP、FTP 和 IIOP 或 MQ 上的 RMI
）相结合使用，或者用这些协议重新封装后使用。
1.1.2.4 服务描述：从 XML 消息传递到 Web 服务
Web服务提供者是通过服务描述将所有用于调用 Web 服务的规范传送给服务请求者的。要
实现 Web 服务体系结构的松散耦合，并减少服务提供者和服务请求者之间所需的共识的程
度和定制编程与集成的量，服务描述就是关键。例如，不管是请求者还是提供者，都不必
了解对方的底层平台、编程语言或分布式对象模型（如果有的话）。服务描述与底层 SOA
P 基础结构相结合，足以封装服务请求者的应用程序和服务提供者的 Web 服务之间的这个
细节。
1.1.2.5 基本服务描述
Web 服务体系结构使用 WSDL 作为基本服务描述。WSDL 是一种 XML 文档，它将 Web 服务
描述为一组端点，这些端点会处理包含面向文档或面向过程的（RPC）消息的消息。操作和
消息都是被抽象描述的，然后它们会被绑定到一个具体的网络协议和消息格式，用来定义
端点。相关的具体端点被合并到抽象的端点或服务中。WSDL 可以扩展为允许端点和其消息
的描述，不管使用哪种消息格式或网络协议进行通讯都可以。然而，目前经过描述的绑定
只能用于 SOAP 1.1、HTTP POST 以及多用途因特网邮件扩展（Multipurpose Internet M
ail Extensions，MIME）。
Web 服务体系结构中对 WSDL 的使用按照常规将基本的服务描述分成了两部分：服务接口
和服务实现。这使每个部分都可以被分开独立定义，并可以由另一部分重新使用。
服务接口定义是一种抽象或可重用的服务定义，它可以被多个服务实现定义实例化和引用
。您可以将服务接口定义想象成接口定义语言（Interface Definition Language，IDL）
、Java 接口或 Web 服务类型。这使常见的行业标准服务类型可以被多个服务实现者定义
和实现。这类似于在编程语言中定义抽象接口然后得到多个具体实现。服务接口可以由行
业标准组织定义，如 RosettaNet，或保健行业的 HL7。
服务接口包含 WSDL 元素，它们组成了服务描述中的可重用部分，这些元素有：WSDL: bi
nding、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。该规范可能会在一些知名网站上被发布（例如 ht
tp://www.openapplications.org/）。
服务提供者可以选择开发实现 OAGIS 购买订单服务接口的 Web 服务。服务提供者会开发
一个服务实现定义文档，描述 WSDL 设备、端口和地址位置元素，这些元素描述提供者的
Web 服务的网址及其它特定于实现的细节。
服务接口定义和服务实现定义结合在一起，组成了服务完整的 WSDL 定义。这两个定义包
含为服务请求者描述如何调用以及与 Web 服务交互的足够信息。服务请求者可以要求获得
其它关于服务提供者端口的信息。此信息由服务完整的 Web 服务描述提供。
1.1.2.6 完整的 Web 服务描述
完整的 Web 服务描述建立在服务基本的 WSDL 定义之上。完整的 Web 服务描述可以解决
这样的问题：什么企业在托管这个服务？它是何种类型的企业？与服务相关联的产品有哪
些？各种公司和产品类别中与该企业或其 Web 服务相关联的分类有哪些？有没有服务的其
它方面（如服务质量）会影响到请求者是否选择调用服务？为了使查找该服务更容易，可
以提供哪些关键字？
UDDI 提供了一个保存 Web 服务描述的机制。虽然 UDDI 通常会被认为是一种目录机制，
但是它也定义了一个用 XML 表示服务描述信息的数据结构标准。UDDI 条目中有四种基本
数据结构，如图 7 中所示。
UDDI 条目由 businessEntity 开始。businessEntity 元素对关于企业的信息进行建模，
包括基本的企业信息（例如企业名称和联系方式信息是什么？）、分类信息（例如这是何
种类型的企业？）以及标识信息（即 Dunn and Bradstreet 编号是什么？）。businessE
ntity 包含一组 businessService 元素，每个元素对应于企业希望发布的每个 Web 服务
。每个 businessService 元素都包含和 businessEntity 元素的 Web 服务有关的技术性
和描述性信息。businessService 包含一组 bindingTemplate 元素。bindingTemplate 描
述访问信息（例如端点地址），还描述 businessService 如何使用各种不同的技术规范。
技术规范在这里的模型是 tModel。tModel 可以为很多不同概念建模，如：一种服务、一
个诸如 HTTPS 之类的平台技术或一个类别。与 businessService 相关联的那一组 bindi
ngTemplate 元素代表了 businessService 所使用的技术的印记。
在 Web 服务体系结构中，完整的 Web 服务描述包括用于端点描述的一层，这个端点描述
使用 UDDI 条目向服务描述添加企业和实现环境。
端点描述遵循结合 WSDL 使用 UDDI 的约定。端点描述使用 UDDI 提供企业信息和类别的
标准表示。这个 UDDI-WSDL 约定规定了如何从和 Web 服务相关联的 UDDI 条目中得出服
务接口定义和服务实现定义的 WSDL 描述。这个约定对于在 Web 服务体系结构中使用 UD
DI 作为基于 WSDL 的服务注册中心来说至关重要。
端点描述向应用到服务的特定实现的服务描述添加了另外的语义。安全属性可以定义对 W
eb 服务的访问进行控制的策略。服务质量属性指定面向性能的能力，例如服务在一定时间
内做出响应的能力，或所支持的可靠消息传递的级别。服务开销属性描述服务的资源需求
。还可以定义支持哪些对话语义。
服务描述协议栈中的最后一层是协议描述。协议描述反映两个企业伙伴之间为了完成一个
多步企业交互而进行的 Web 服务调用的一个简单的编排。例如，“协议定义”定义了购买
协议中诸如购买者和出售者之类的角色。协议定义规定了每个角色必须达到的要求。例如
，出售者必须有接受报价请求（request for quote，RFQ）消息、购买订单（purchase o
rder，PO）消息和付款消息的 Web 服务。购买者的角色必须有接受报价（RFQ 响应信息）
、发票消息和账户摘要信息的 Web 服务。这个简单的 Web 服务到企业角色的编排对于在
企业伙伴之间建立多步的、面向服务的交互来说至关重要。在很多不同的企业协议标准下
，一个给定的服务请求者或服务提供者也许能够扮演购买者或出售者的角色。通过显式地
建模企业协议和每个节点在企业协议中扮演各种角色的能力，请求者可以选择在面对各种
提供者企业伙伴时加入哪种企业协议。
这个领域充满了创新。对于企业协议定义来说，目前还没有一个单独的标准。ebXML 协作
-协议概要和协定规范（ebXML Collaboration-Protocol Profile and Agreement Specif
ication）描述了这些概念，但不是根据作为该体系结构的一部分描述的 Web 服务技术而
描述的。Web 服务流程描述和 Web 服务端点描述这两层正处于开发中，它们可以提供这个
级别的服务描述。
1.1.2.7 服务描述的发布和发现
1) 服务发布
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 节点位于防火墙之后。此类专用 UDD
I 节点只包含来自合法企业伙伴的经过允许的、测试过的、有效的 Web 服务。此类 Web
服务的业务环境和元数据可以被定位到特定的请求者。
电子市场 UDDI 节点（E-Marketplace UDDI node）节点：对于服务提供者打算用来与其它
Web 服务竞争请求者的业务的 Web 服务来说，服务描述应该被发布到电子市场 UDDI 节
点或 UDDI 运营商节点。电子市场 UDDI 节点由一个行业标准组织或社团托管，包含特定
行业中的企业的服务描述。我们可以要求这些服务支持特定的标准、可搜索元数据、接口
或数据类型。电子市场 UDDI 节点一般会过滤掉某些非法的条目，并提供有保证的服务质
量。
UDDI 运营商节点：如果您希望 Web 服务可以被潜在的新的企业伙伴或服务用户发现，还
可以将其发布到 UDDI 运营商节点。IBM、Microsoft 和 Ariba 都支持、复制和托管 UDD
I 运营商节点。在发布 UDDI 运营商节点的时侯，如果要让潜在的服务请求者发现服务的
话，完整的业务环境和经过深思熟虑的分类法是很必要的。
2) 服务发现
Web 服务的发现包括获取服务描述和使用描述。获取过程可以使用各种不同机制。
和发布 Web 服务描述一样，根据服务描述如何被发布以及 Web 服务应用程序可能达到的
动态程度，获取 Web 服务描述也会有所不同。服务请求者将在应用程序生命周期的两个不
同阶段，即设计时和运行时查找 Web 服务。在设计时，服务请求者按照他们支持的接口类
型搜索 Web 服务描述。在运行时，服务请求者根据他们通讯的方式或公告的服务质量搜索
Web 服务。
使用直接发布方法时，服务请求者在设计时对服务描述进行高速缓存，以在运行时使用它
。服务描述可以被静态地用程序逻辑表示，并存储在文件或简单的本地服务描述资源库中
。
服务请求者可以在设计时或运行时在服务描述资源库（简单的服务注册中心或 UDDI 节点
）中检索一条服务描述。查找机制需要支持一种查询机制，它提供按接口类型（基于 WSD
L 模板）、绑定信息（即协议）、属性（如 QOS 参数）、所需的中介类型、服务分类法、
企业信息等等的查找。
不同类型的 UDDI 节点会显示可以选择的运行时绑定 Web 服务的数目、多选一的策略，或
者调用服务之前必须由请求者做出预选的量。
内部企业应用程序 UDDI 节点和伙伴目录 UDDI 节点将不需要预选来建立对服务的信任。
服务选择可以建立在绑定支持、历史性能、服务质量分类、相似性或负载平衡的基础之上
。
电子市场 UDDI 节点将有更多的运行时服务可以选择。必须执行某种预选以保证 Web 服务
提供者是有价值的伙伴。我们可以根据价格承诺、开销、经过允许的伙伴列表的出席情况
，同样还有绑定支持、历史性能、服务质量分类和相似性来选择服务。
如果服务请求者从 UDDI 运营商节点查询 Web 服务提供者，他们在预选可能的服务提供者
时就必须尽可能谨慎和认真。应该有一个有效和准确的机制就位，过滤掉无用的服务描述
和没有价值的服务提供者。
在获取了服务描述之后，服务请求者需要处理它以调用服务。服务请求者使用服务描述生
成对 Web 服务的 SOAP 请求或特定于编程语言的代理。该生成可以在设计时或运行时进行
，从而对 Web 服务的调用进行格式化。我们在设计时和运行时可以使用各种工具从 WSDL
文档生成编程语言绑定。这些绑定表示应用程序的 API，并封装了来自应用程序的 XML
消息传递的细节。
--
FROM 166.111.102.8