核心标准

　　因为迄今为止大多数人都已经听说过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服务。