以文本方式查看主题 - 中文XML论坛 - 专业的XML技术讨论区 (http://bbs.xml.org.cn/index.asp) -- 『 Web Services & Semantic Web Services 』 (http://bbs.xml.org.cn/list.asp?boardid=10) ---- WS-Addressing入门读物:Web 服务寻址(WS-Addressing)对 SOAP 的隐式影响[转帖] (http://bbs.xml.org.cn/dispbbs.asp?boardid=10&rootid=&id=27577) |
-- 作者:admin -- 发布时间:2/21/2006 8:51:00 PM -- WS-Addressing入门读物:Web 服务寻址(WS-Addressing)对 SOAP 的隐式影响[转帖] Web 服务寻址(WS-Addressing)对 SOAP 的隐式影响 SOAP 标准是一项革新吗? 级别: 初级 [URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-address.html?ca=dwcn-newsletter-webservices#author]Doug Davis[/URL], 架构师, IBM Emerging Technologies Web 服务寻址(WS-Addressing)协议可能与第一眼看上去的的样子有很大的不同。但是它构建的消息信息头将使新的 Web 服务消息流模式成为可能——而且它将对 SOAP 引擎以及 SOAP 协议本身的未来造成深远的影响。 如果您正确地了解了事实,那么在所有多余的话之后,Web 服务寻址(WS-Addressing)实际上只包括两个新概念: 端点引用(endpoint reference,EPR)和 SOAP 结构的 消息信息(message information,MI)头。 端点引用(Endpoint reference) 在 Web 服务寻址(WS-Addressing)出现以前,为了找到一个 Web 服务的位置,您不得不请求端点的 URL 或求助于 Web 服务描述语言(WSDL)。这听起来好像够简单了,那么您为什么还需要 Web 服务寻址(WS-Addressing)呢?随着 Web 服务的发展,很自然,它们将开始变得复杂,以便支持企业级的解决方案。例如,可能需要在 SOAP 请求中包含附加信息来帮助惟一地识别您正在与之对话的 Web 服务实例。这将与在请求中包含会话标识符或实例 ID 相类似。这么做并不是非常的重要。 然而,使用会话标识符(通过将某些像 resourceID=123 这样的信息附加到 URL)并不完全类似于 SOAP。SOAP 纯粹主义者可能更愿意回到 SOAP 中定义的可扩展性模型,并使用附加的 SOAP 头包含这个新的信息来处理消息;例如:
URL 编码的另外一个问题是,现在它将特定于 Web 服务的数据紧密地绑定到传输——换句话说,现在特定于 Web 服务的数据在 SOAP 信封以外,处于传输层。 那么,Web 服务寻址(WS-Addressing)有什么用处呢?它定义了称为 端点引用(endpoint reference,EPR)的东西。在它最简单的形式中,EPR 只不过就是由一些 XML 元素包装的 URL。 [URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-address.html?ca=dwcn-newsletter-webservices#listing1]清单 1[/URL]给出了一个示例。 清单 1. 一个简单的端点引用(EPR) <widget:myLocation>
[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-address.html?ca=dwcn-newsletter-webservices#listing2]清单 2[/URL]添加了附加资源 ID 信息。 清单 2. 带有添加的 ReferenceProperties 元素的端点引用(EPR) <widget:myLocation> 清单 3. 使用端点引用(EPR)来返回引用 <soap:Envelope...> 您可能一边看这个例子,一边纳闷,为什么您不是仅仅返回字符串“123“,而是返回整个端点引用(EPR)——为什么您需要增加额外的复杂性?实际上,有几个原因说明了为什么额外的抽象实际上最后会使工作更容易。首先,消息的接收方不需要知道端点引用(EPR)的任何内容。如果您返回像“123”这么简单的信息,那么接收方将不得不既要知道这是一个字符串,而且还要知道这个字符串的含义以及稍后应该如何使用这个字符串。潜在地,接收方可能被要求有区别地解释返回值,这取决于它正在对话的应用程序的类型。通过使用端点引用(EPR),您已经使 Web 服务的引用的格式标准化,更确切地说,也使 Web 服务的实例的引用的格式标准化了。 端点引用(EPR)的另外一个重要方面是必需的元素: Address 。因为端点引用(EPR)具有这个 Address 字段,所以这个字段可以包含与原始请求的 URL 完全不同的 URL。例如, createWidget() 调用的 URL 可能以 .../createWidgetService 结束,而随后服务调用的 URL 可能是 .../WidgetService 。不必理会特定的值,关键是这个端点引用(EPR)的接收方不需要知道任何关于如何解释数据的事情;它仅仅需要知道 Address 字段是应该用于未来消息的 URL,以及所有的引用特性(reference properties)应该都是在那些消息中的 SOAP 头。所以,对于这个端点引用(EPR)的未来请求的 SOAP 信封将采用 [URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-address.html?ca=dwcn-newsletter-webservices#listing4]清单 4[/URL]中所给出的形式。 清单 4. 用于请求我们的样本端点引用(EPR)的 SOAP 信封 <soap:Envelope...>
所以,现在您已经将传送 Web 服务的引用的方法标准化了。标准化是一件好事,但是到目前为止,您几乎还没有看到前面声称的 Web 服务寻址(WS-Addressing)将改变 SOAP 本身所具有的优点。在下一部分中,您会对此有更好的理解,接下来我们介绍 Web 服务寻址(WS-Addressing)的第二个特征: 消息信息(message information,MI)头。 Web 服务寻址(WS-Addressing)规范定义了一些附加的(当然,也是标准的)SOAP 头,它们应该用于帮助传送关于消息的信息。在这一部分中,我将介绍其中比较有趣的一些。 To To 只不过是目标 Web 服务的 URL。一般来说,这个 URL 和 HTTP 请求的 URL 是相同的,但是这并不是必需的。 清单 5. To 头 <wsa:To> http://host/WidgetService </wsa:To>
From From 是消息发送方的端点引用(EPR)。如果消息接收方需要向发送消息的端点发送回消息,那么它应该使用这个端点引用(EPR)。请注意,同样也有一个 ReplyTo 头,它指示响应消息应该去往何处。 From 头将用于这样的情况,如同那些由 WS-ReliableMessage 规范所管理的, Acknowledgement 需要被发送回发送方。 [URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-address.html?ca=dwcn-newsletter-webservices#listing6]清单 6[/URL] 给出了一个运行的 From 头示例。 清单 6. From 头 <wsa:From>
正如所提到的,来自于 Web 服务的任何响应都应该被发送给 ReplyTo 端点引用(EPR)。因为 From 和 ReplyTo 可能是两个截然不同的端点引用(EPR),所以消息的发送方可能并不是想要接收响应的端点。我将在稍后讨论这里的含义。 [URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-address.html?ca=dwcn-newsletter-webservices#listing7]清单 7[/URL] 举例说明了 ReplyTo 头的使用。 清单 7. ReplyTo 头 <wsa:ReplyTo>
如果消息的响应是 SOAP 错误,那么这个错误应该在 FaultTo 头中发送给端点引用(EPR)。 [URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-address.html?ca=dwcn-newsletter-webservices#listing8]清单 8[/URL]给出了一个示例。 清单 8. FaultTo 头 <wsa:FaultTo>
MessageID 只不过就是惟一地识别消息的 URI。 [URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-address.html?ca=dwcn-newsletter-webservices#listing9]清单 9[/URL]给出了一个示例。 清单 9. MessageID 头 <wsa:MessageID>uuid:098765</wsa:MessageID>
在 [URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-address.html?ca=dwcn-newsletter-webservices#listing10]清单 10[/URL] 中显示的 Action 头是 SOAP HTTP Action 头在信封中的版本。 清单 10. Action 头 <wsa:Action> http://host/widgetOp </wsa:Action>
RelatesTo 常常用在响应消息中,用来指示它与先前知道的消息相关并且定义这种关系。 [URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-address.html?ca=dwcn-newsletter-webservices#listing11]Listing 11[/URL]给出了一个示例。 清单 11. RelatesTo 头 <wsa:RelatesTo RelationshipType="wsa:Response">
Web 服务寻址(WS-Addressing)定义了所有这些要使用的特殊的头,但是您可能会这样自问:“谁关心这些?”最初,您事实上已经添加了一定程度的复杂性,似乎直到现在都还没有用上。对于简单的请求/响应 HTTP 消息流,可能是这样的。然而,一旦您开始使用异步消息流或跨多个传输协议发送消息时,这些头就变得非常重要了。 以一个简单的异步消息交换(甚至是在 HTTP 之上)为例,在这里响应消息通过一个新的连接发送回去。服务器是如何知道下一个响应消息需要去往何处呢?一个显而易见的解决方案就是将返回地址(或者端点引用)作为应用程序数据的一部分(即,包含在 Body 中)。然而,如果您使用 Web 服务寻址(WS-Addressing),那么现在您就有一个标准位置用于这个数据: ReplyTo 消息信息头/端点引用(MI header/EPR)。同样地,如果您使用的是类似于 Web 服务可靠消息传递(WS-ReliableMessaging)(参阅 [URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-address.html?ca=dwcn-newsletter-webservices#5]参考资料[/URL])这样的规范,那么在这里潜在地有三个不同的响应消息(传统的 Reply 、可能有的 Fault 以及 Acknowledgement ),Web 服务寻址(WS-Addressing)提供了一个标准机制,所有的 Web 服务通过这个机制就可以表示这个信息。当这三个消息可能需要发送给三个不同的端点时,这就变得尤为关键。这与实际信封所采用的方式毫无差别,在实际信封上有用于书写收信人地址、寄信人地址和粘贴邮票的标准位置。标准化是一件好事。 在所有的信息头(或者包含 Address 元素,或者像 To 头那样对自己进行寻址)中,您可以使用一个特殊的 匿名URI:
虽然最初您可能觉得这个例子只是比较有趣地使用 ReplyTo 和匿名 URI,而实际上,它对于消息处理模型具有非常大的影响。考虑这样一种情况,它的请求消息类似于 [URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-address.html?ca=dwcn-newsletter-webservices#listing12]清单 12[/URL]所示。 清单 12. 使用匿名 URI <soap:Envelope...> 当然,并不只是客户端受到了影响。接收方(或服务器)必须能够基于各种信息头中的值和生成的响应消息来动态地在同步模型和异步模型之间转换。 它还有另外一个有趣的副作用。在大部分服务中,WSDL 描述的是非常简单的请求/响应同步消息模式。但是对于 Web 服务寻址(WS-Addressing)来说,任何 Web 服务(无论是异步地还是同步地)都将简单地通过正确地使用 Web 服务寻址(WS-Addressing)头来隐式地支持异步。这是 SOAP 应用程序现在可用的一个非常强大的工具。某些规范,比如 WS-Transactions (WS-Coordination 和 WS-AtomicTransaction——请查阅 [URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-address.html?ca=dwcn-newsletter-webservices#5]参考资料[/URL]),特意定义了两个不同的端口类型——一个用于同步消息传递模式,一个用于异步消息传递模式。这种差别现在已经变得过时了。 新兴技术工具包(Emerging Technologies Toolkit,ETTK;请参阅 [URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-address.html?ca=dwcn-newsletter-webservices#5]参考资料[/URL]以获得相关链接)包括使用 Web 服务寻址(WS-Addressing)规范的相当多的演示。特别是,基于 Web 的 WS-ReliableMessaging demo 让您可以容易地改变 Web 服务寻址(WS-Addressing)头来查看消息流是如何改变的。 支持 WS-* 规范最一般的原因是由于它带给 Web 服务世界的标准化程度。Web 服务寻址(WS-Addressing)通过定义端点引用(EPR)和消息信息(MI)头来明确地达到这个目的。这个定义提供了单一的机制,通过这一机制,人们能够指定 Web 服务(或者服务的实例)的位置以及服务在 SOAP 消息中使用那些端点引用(EPR)的方式(通过 MI 头)。但是,正是在消息处理模型/流中的隐式改变甚至对 SOAP 具有更加重大的影响。Web 服务寻址(WS-Addressing)的重要性将随着时间而增加——以致到达它将被视为那些规范中的一个成员,它本身应该是核心 SOAP 规范的一部分。
参考资料 您可以参阅本文在 developerWorks 全球站点上的 [URL=http://www.ibm.com/developerworks/library/ws-address.html]英文原文[/URL].
查阅 [URL=http://www.alphaworks.ibm.com/tech/ettk]IBM 新兴技术工具包(Emerging Technologies Toolkit)[/URL]。 Doug Davis 是 IBM 新兴技术部门的架构师。他以前担任过的职务包括 Emerging Technologies Toolkit、WebSphere Machine Translation、Team Connection 和 IBM Fortran 90 的技术总监。您可以通过 [URL=mailto:dug@us.ibm.com]dug@us.ibm.com[/URL]与 Doug 联系。 |
W 3 C h i n a ( since 2003 ) 旗 下 站 点 苏ICP备05006046号《全国人大常委会关于维护互联网安全的决定》《计算机信息网络国际联网安全保护管理办法》 |
62.500ms |