时间：2004-03-16
作者：Orchard1

Web是人们使用计算机（Web浏览器）与其他计算机（Web服务器）进行交互的方式。Web服务是计算机之间在没有人控制的情况下进行通信的技术手段。

事实表明人类具有高级的智能。我们可以想出多种交互的方式：
· 如何向不同的页面输入用户名和密码
· 何时停止等待一个页面，返回并重新提交请求
· 当一个站点超时时，如何重新输入数据并获得正确的页面
· 如何在Web表单里输入电子邮件地址，然后转到电子邮件的客户端查看返回的电子邮件信息
· Web页面以何种顺序（或流）完成一项任务

当计算机之间进行通信时，他们却没有这么聪明。人们可以正常处理的事情，如安全性、可靠性、会话或异步，必须要明确地编入计算机的程序里。这就是为什么有这么多"WS-*"规范的原因。计算机需要正式的规范来充分解释我们能正常处理的每件事情。

要使Web服务成功并有成本效益，我们需要在Web服务的每个领域内都有一个单一的标准。因为用户名/密码组合容易被人们理解，所以每个Web站点都需要一个用户名/密码组合（可以以不同的方法输入他们）。这不是问题，每个站点都可以做到。但是想象一下如果每个Web服务使用不同的身份验证机制，那么编写软件来处理每个服务的不同身份验证机制的工作将是巨大的。标准就是为了获得经济上的规模效益以使得提供商能够以同样的方式提供相同的功能。其次，开发人员能够更容易地编写软件来提供或使用Web服务。

本文描述了一组Web服务标准。BEA认为这些标准对用户和开发人员很重要。我们根据以下三个方面将这些标准分类：所处理的问题的类型；规范对投入实际使用的完善程度；规范的功能对Web服务而言是在哪个基础层面上。

Web服务标准

在任何技术讨论中，图表都是必不可少的。图1显示了本文讨论的Web服务规范、规范类型以及他们与所谓的Web服务规范"核心"集的关系。

分类方法

我们选择两个不同的方面来对Web服务规范进行分类。第一个方面根据Web服务的"3－Ds"描述规范的功能，即，交付、描述和发现(delivery, description, and discovery)。交付指的是消息是如何在服务之间发送的；描述规范指描述被交换的消息；发现是指如何发现服务或描述。

第二个方面展示规范的卓越性和选择使用上的时机性。有一组规范是Web服务的核心；我们预计大多数的Web服务会用到他们。例如SOAP和WSDL，他们显然是核心规范。有些核心规范现在就可以使用，有些则要再等一段时间才可用。那些只用于部分Web服务而没有集成到大多数Web服务中的规范被视为扩展规范。

核心标准

因为迄今为止大多数人都已经听说过SOAP、WSDL和UDDI，所以本文不再对目前稳定的规范进行详细介绍。简而言之，就是目前由XML 1.0、XML Schema 1.0、SOAP 1.1、WSDL 1.1、HTTP 1.1、 SSL和TLS构成的核心规范。既然是核心规范，那么他们当中有很多出现在WS-I Basic Profile里也就不足为奇了。

正在出现的核心标准

我们已经能够看到下一代的核心Web服务将要采取的形式。交付(delivery)将被扩展来包括更健壮的异步消息传递、更清楚的消息寻址标准；完善的 Web服务层消息路由选择系统，以及更先进的安全保障。通过增加复杂的策略描述功能使描述(description)得到增强。同时将使用一些机制来增强发现(discovery)能力，使得通过对Web服务功能的描述能够将Web服务动态查询出来。在交付里增加异步、安全性、可靠性和寻址信息；在描述里增加WS-Policy；在发现里增加基于URI的元数据交换；所有这些增加最后产生的结果就是BEA认为的下一代的核心Web服务规范。

交付：异步、寻址和路由选择

Web服务大有希望的一个方面是异步，即能够在当前没有连接的情况下交付响应和消息，以便服务的用户和服务提供商的执行操作可以是松耦合方式的。WS- Addressing定义了用于异步消息传递的基本机制，特别是Reply-To报头允许执行"callback"。

WS-Addressing还通过定义公共报头，如消息标识符、to和from字段，来规定寻址信息（通常用于路由选择）如何在SOAP消息里传递。

最后，WS-Addressing提供了一个EndpointReference结构，该结构含有有关Web服务端点的信息。端点是Web服务的访问点。它是在WSDL 1.2里定义的，由WSDL 1.1 Port重新命名而来。端点含有访问或引用服务所需的信息，如会话ID。交换端点引用常常是必要的，特别是在有回调和长时间运行的会话时。将来会出现WS -EndpointResolution规范，该规范使双方能够协商或者改进EndpointReferences。

交付：可靠性

可靠的消息传递协议为保证发送方和接收方知道一条消息是否被交付而定义的机制。典型的机制是一条带有重试算法的确认消息。WS- ReliableMessaging使用许多不同的SOAP报头和配置信息为Web服务规定了可靠的消息传递协议。这些SOAP报头允许序号通信、对消息序列进行确认、并能够请求对消息序列进行确认。OASIS 委员会，即WS-Reliability，看到Fujitsu、Sun、Oracle、Sonic以及其他厂商正在进行着相似的工作－WS- Reliability。

值得注意的是BEA已经在这一领域发布并实现了很多独立的规范：WS-Acknowledgement、WS-MessageData、WS- Callback和SOAP-Conversation。BEA这样做是为了其他厂商能够与BEA合作，早日向我们的客户提供这些功能并提供有益的实现经验。我们预计我们的经验和实现将有助于上述规范成为稳定的、功能完善的标准。

交付：安全性

WS-Security由OASIS Web Service Security技术委员会制定的一个规范和相关规范的路线图组成。WS-Security（WSS）规范有三个主要功能：
· 消息完整性/身份验证： 保证消息在被发送后没有被改动
· 消息机密性： 保证只有应该看到该消息的人能够看到消息
· 消息授权：在决定能否同意请求时提供所需信息

WSS规范使用XML Digital Signatures规范和XML Encryption规范，并引入了新的授权元素。所有这些WSS特征都表示成SOAP报头块。很多提供商都已经实现了WS-Security，更多的提供商则将参与WSS互用性的测试。

WS -Security路线图含有其他三个最近发布的规范。WS-SecurityPolicy定义了如何以WS-Policy语言表达WS- Security策略（见下文）。WS-Trust提供了一个协议，该协议用于请求和接收WS-Security令牌，其中包括一个具有挑战性的响应协议。WS-SecureConversation定义了一个安全语境，双方在进行长时间的会话时可以共享该语境。WS- SecureConversation还定义了一个改进的WS-Trust用于设置语境。

描述：策略

Web服务目前面临的一个问题是对端点功能和要求的描述。例如，WS-Security描述了很多安全机制，但是却没有强制服务使用哪个具体的机制。同样，WS-ReliableMessaging中有几个配置选项允许服务和这些服务用户微调消息交换的性质。目前，由于WSDL不能解决这些问题，这些问题以及其他Web服务操作的问题必须通过私下协商来解决。

虽然能够逐点指明这些问题并可以协商解决，但是在Web服务里为配置、需求和功能（统称为Policy）定义一个通用架构仍不失为明智之举。WS-Policy的目标就是使用三个相关的规范来填补这个空白。

WS-PolicyFramework描述了一个全面的方法，该方法可以表达策略断言（例如，"我支持DES加密算法"，"那条消息需要的是SOAP 1.2"）并对他们进行组合（例如，需要一个数值列表中的一个值，或者需要一个集合中的所有元素）。

WS-PolicyAssertions定义了一些特定的断言，如文档的编码或者对特定规范的支持，来演示架构的使用并允许对通用组件重用。最后，WS-PolicyAttachment规定了如何将策略断言与XML元素、WSDL-type定义和UDDI条目关联起来。

发现：基于URI的发现

Web服务的核心规范还需要一项功能，那就是在指定URI后如何发现与特定Web服务或服务提供商有关的WSDL和WS-Policy语句。我们期望WS -MetadataExchange规范能够实现基于UR的发现。

扩展

扩展是这样一些规范，他们非常有用，只不过他们用在更细分的领域内，而不是我们所说的核心领域内。

WS -Transaction定义了各种原子事务的协调（两个阶段提交和四种其他类型）和补偿事务。它使用WS-Coordination作为模式为客户和协调者注册和交换协调消息。WS- Transaction和WS-Coordination包括一个或多个协调者，他们参与了交互的完成。

WSBPEL（Web Services Business Process Execution Language）是一个OASIS技术委员会。该委员会致力于产生一种用于编写Web服务控制逻辑的，独立于平台的、基于XML的编程语言。W3C Choreography Working Group也在研究类似的技术，但在本文编写时，要说他们的工作具有互补性还为时尚早。

结束语

我们期望，本文介绍的规范集能够为满足客户的应用程序和业务流程的需要提供一个坚实的基础。这些规范正在逐渐成为标准。从SOAP、WSDL和UDDI开始，一直到最近的WS-Security和BPEL4WS。我们期望所有这些规范都能标准化。

假设您是BEA Weblogic开发人员，我将把这些规范与BEA和BEA的领导地位结合起来。BEA是大多数WS-*规范的共同起草者。在WebLogic产品里，BEA还是一个极富进取心的规范实现者。例如，尽管WS-Security TC还没有进行正式的互用性测试，BEA WebLogic Platform 8.1还是实现了WS-Security规范的一个非常有用的部分。

总之，开发人员可以期望，使用当前的和即将出现的Weblogic版本里的这些规范来建立具有互用性的Web服务。

关于作者

David Orchard是BEA Systems' CTO Office的技术总监，主要负责Web服务标准。他是W3C Technical Architecture Group、Web Services Architecture、XML Protocol以及Advisory委员会的成员。他发表过很多技术文章，并经常就多种与Internet相关的技术发表观点。

图 1