WS-Addressing

与传输层无关的，传送寻址信息的机制

Web服务寻址（WS-Addressing）是一个W3C推荐标准，为Web服务提供一种与传输层无关的，传送寻址信息的机制。规范主要由两部分组成：传送Web服务端点的引用的数据结构，以及一套能够在特定的消息上关联寻址信息的消息寻址属性。

简介

Web services规范也称为WS-*，主要是主要技术厂商（如Microsoft、Sun、BEA、IBM和SAP）协同工作的结果。其中一些规范（包括WS-Addressing）是在World Wide Web Consortium（W3C）的监督下制定的。WS-Addressing规范（在2004年8月被W3C接受为成员）提供了一种在Web services消息和服务描述中表示消息寻址信息的标准。

W3C的Web Services Addressing Working Group正在修订和最终确定WS-Addressing规范。我们可以明确地期望看到规范进行了很多更改，因为大量的问题仍需要解决。例如，在2005年1月，工作组一致同意去掉下面将要讲述的“参考属性”特性，但是该决议仍未公开发表。尽管更改仍在进行之中，但是WS-Addressing的中心思想是不变的，因此现在非常适合开发人员先了解一下该规范。

WS-*的所有规范都是基于SOAP设计的。他们为在SOAP消息的标头块（header block）中使用定义了XML schema。通过设计，WS-*规范之间的依赖性非常小了。这一点有助于开发人员仅使用他们所需的规范。WS-Addressing和其它WS-*规范之间是相互独立的，但是可以一起使用。举例来说，一种规范可以使用WS-Addressing来识别消息的来源和目的地，还可以使用WS- Security对到目的地的来源进行身份验证。

WS-Addressing还和Web Services Description Language 1.1 (WSDL)有着微妙的联系。它扩展和综合了来自WSDL的一些概念，但是这两者之间没有明确的依赖性。Web services开发人员可以使用其中之一，也可以使用两者，这取决于他们的需求。WSDL提供了一份可以使用抽象（消息发送和接受）和具体两种术语（传输和有线格式）描述服务的词汇表。WS-Addressing利用WSDL的“服务”和“端口”概念，如下所述。

WS-Addressing目前已经发布了三种不同的规范，WS-Addressing Core、WS-Addressing SOAP Binding和WS-Addressing WSDL Binding。核心规范描述抽象属性，而捆绑文档解释了如何分别使用SOAP和WSDL来表示这些属性。核心/捆绑文档分析在Web services规范中很常见。在此，核心规范对应用程序开发人员来说比捆绑文档更为重要，因为Web services资料库和开发人员工具通常封装捆绑文档的细节。

WS-Addressing的目的

SOAP不提供标准的方法，来指定消息的目的地、如何返回响应或者在哪里报告错误。这些细节以前留在传输层中。举例来说，在标准SOAP请求通过 HTTP发送的时候，HTTP请求的URI就作为消息的目的地。消息的响应保存在HTTP响应中，客户端通过HTTP连接来接收。通过JMS异步发送 SOAP请求消息时，则可以在JMS消息标头中指定响应的目的地，将其合并在消息主体中，或者保留在服务实现中。

在传输层上的寻址对很多现有的服务来说已经够用了，但是在其他服务的开发中它却成了一种限制因素。WS-Addressing定义了通过多种传输路由消息或者将响应直接传递到第三方的标准方式。举例来说，客户端应用程序可以通过JMS发送请求，并要求通过电子邮件或者SMS接收响应。为了支持这些规范，WS-Addressing在SOAP信封中综合了交付、答复和错误处理程序的寻址信息。下面的示例说明了使用WS-Addressing的典型SOAP消息：

WS-Addressing还定义了一种标准，用于在一个地址中包含服务特定的属性，该地址可以用于将消息路由到服务中或者由目的地服务自身使用。这些属性对创建有状态的Web services特别有用，这些服务可以从特殊的客户端接收一系列的请求，并记住这些请求之间的一些状态信息。

核心构造

WS-Addressing为Web services词汇表引入了两种新的构造：端点参考和消息寻址属性。“Endpoint”是一个用于访问Web services的目的地的确定术语。端点参考是描述这些目的地的一种新模型。消息寻址属性（可能会包含一个或者多个端点参考）提供了该目的地信息的上下文。

邮递信封提供了一种优秀的非技术性类比：目的地地址的书写位置在信封的中央，而回信地址的书写位置在背面。单个地址的具体格式（姓名、街道、美国城市/州/邮政编码）可以与端点参考进行类比。信封上的地址布局可以与WS-Addressing的消息寻址属性进行类比。

分析端点参考

在WS-Addressing schema中，端点参考被定义为一种复杂类型。端点参考类型包含地址（URI）、参考属性、参考参数、端口类型、服务名称、策略元素（由WS- Policy规范定义）。端点参考唯一必需的元素是地址，因此可能的最简单端点参考就是一个URI：

http://ws.example.com/myservice

端点参考的其他元素全部是可选的，这一点可以使您选用所需的元素更加方便。端口类型和服务名称元素非常类似于它们的WSDL对等物。WSDL将端口类型定义为一种附加到操作的抽象集合中的标识名称。捆绑文档指定了端口类型的具体输入和输出。该类型的端口表示捆绑文档在特定地址上的部署。服务是端口的指定集合。与在WSDL中一样，在WS-Addressing中，端口类型和服务名称是QNames（合格名称）。WS-Addressing端点参考中的端口类型和服务名称必须具备与WSDL的兼容性，而不是完全将其替代。

端点参考的一个重要方面是通过参考属性或者参考参数在自己的XML名称空间中附加数据的能力。这两种元素都是属性和值的集合，您可以使用这些属性和值将元素从自己的XML名称空间（或者任意XML名称空间）综合到端点参考中。参考属性和参考参数之间的主要区别不在于格式，而是既定的用途不同。

参考属性可以用于识别服务部署的端点。共享同一个URI，但是指定了不同参考属性值的两个端点参考表示两种不同的服务。参考属性用于将请求发送到恰当的服务中。举例来说，您可以部署两种不同版本的服务，并让请求在其参考参数中指定目标版本。如果一个服务接收到一个请求并执行该请求，则其行为应当等同于参考属性中的响应。

对比来说，参考参数必须识别特定服务托管的资源。参考参数向服务说明要处理的资源。他们无法识别服务。具有不同参考参数的两个端点参考参考相同的服务。

以下示例说明了向大众提供天气预报信息服务的端点参考，同时还可以向高级用户提供更加详细的信息。服务的URI在Address元素中指定。参考属性指出，请求适用于基础版本的服务。参考参数指定需要天气预报的城市：

消息寻址属性

如上所述，端点参考在消息寻址属性中使用。消息寻址属性定义了可以附加到SOAP消息中的寻址信息的完整集合。大多数字段是可选的；唯有To和Action两个字段是必需的，每个字段指定一个URI。在HTTP请求中，它们将是同一个URI。

在非HTTP请求中，To URI可能不同于Action URI。To URI是请求提交到的位置，而Action URI指出需要采取的操作。Action URI应当表示一种符合WSDL端口类型的服务（参看上文）。举例来说，通过电子邮件或者SMS发送的请求可以到达WSDL端口类型不表示的目的地中。将To URI和Action URI分开为配置Web services目的地提供了很多灵活性。举例来说，电子邮件地址可以接收不同服务的请求，全部通过其Action URI值进行识别。To URI指定“where”，而Action URI指定“what”：

除了必需的To和Action URI，消息寻址属性还包含几种可选的元素。ReplyTo和FaultTo元素的作用是不解自明的。ReplyTo端点必须仅在发送方期望进行响应的时候才能指定，但是它可以将响应路由到任何有效的端点中。FaultTo始终是可选的，它可以将SOAP错误消息路由到指定的端点参考中。此外，服务的消费者可以使用From端点参考元素来向服务标识他们自身。明确地区分消息源端点、预期的回复端点和错误处理端点可以帮助WS-Addressing支持我们通常与Web services关联的简单请求/回复交互之外的多种消息模型。

需要回复时，无论是发送方期望该回复还是由第三方端点在ReplyTo标头中指定，都必须表示MessageId元素。消息的ID是一个独特的URI。由于Web services可以通过不可靠的传输使用，因此端点就很可能会接收到重复的消息复本。消息ID可以用于避免重复处理同一消息。

当服务接收到使用WS-Addressing寻址的消息时，它还会在回复消息中包含WS-Addressing标头。原始消息的消息ID成为了回复地址中的RelatesTo元素。目前，唯一受支持的关系类型是“Reply”。如果客户端正在发送多个Web services请求和接收异步响应（可能通过不同的传输），那么RelatesTo元素就会提供一种标准方法，以关联接收到的回复和相应的请求。

用于开发人员的WS-Addressing

使用WS-Addressing的开发人员工具正在推广过程中，但是仍没有得到广泛应用。如果您现有的Web services应用程序依靠WebLogic Workshop、Apache Axis或者其他可以生成Java API Web services接口的工具，那么您需要等待这些环境的扩展才能包括WS-Addressing。因为WS-Addressing是由主要的大型企业厂商推动开发的，新的适用于开发人员的WS-Addressing工具应当会在2005年推出。

对于使用Web services通过HTTP直接远程访问对象的应用程序来说，WS-Addressing不是一款解决方案。因为HTTP请求和响应通过单个HTTP连接同步发生，寻址意义不大。BEA的Dave Orchard（WS-Addressing合著人员）最近发表了一篇blog entry来探讨WS-Addressing和HTTP的可能性。即使对于WS-Addressing的编写人员来说，在这一点上通过HTTP体现出来的WS-Addressing的价值也不是显而易见的。如果Web services仅仅是为HTTP客户端提供的，则WS-*规范的“按需使用”本质会更容易地忽略WS-Addressing（直到其变得相关）。

WS-Addressing为通过异步传输使用Web services的开发人员提供了更多优势。跨多种传输使用一致的寻址模式可以简化一些集成问题和帮助开发人员实现系统，在该系统中，调度程序使用端点参考将请求路由到几个相关服务中的一个中。随着移动计算变得日益重要，异步Web services对支持具有有限网络访问权限的移动客户端来说非常有用。寻址的一般模型可以帮助最大程度减少将Web services暴露给多个异步客户端所需的工作。如上所述，我们之中关注应用程序开发的人需要等待厂商推出适当的工具后才能充分利用这些机遇。

与其他新推出的Web services规范一样，WS-Addressing的值价仍然有待在实践中验证。如果它产生了一个错误，那么当然不能说明首次推出它的主要厂商不具有继续支撑它的能力。无论WS-Addressing会成为下一个重要规范，还是昙花一现，本文都希望您深入地了解一下规范的内容和可能需要对它进行的一些变更。

全国各地天气预报查询

上海市

云南省

云南省

云南省

云南省

云南省