WS-Addressing 问题的引出

　SOAP协议定义了在Web Services之间传递消息的规范格式，在此基础上Services之间的消息交换将不再受到各种不同底层(传输层)的传输协议的影响，但是在SOAP协议中并没有定义如何寻址一个Web Services。如果把Web Services的寻址功能交由特定的传输协议来实现，那么SOAP协议为Web Services的Loosely Coupled所做的贡献也就大打折扣。这个现象并不奇怪，而且长期以来广泛存在。如果你曾经查看过你访问Web Service时的Http请求，你就会发现其中的SOAP包并没有任何的地址信息，相反在Http请求中倒是包含了Web Services的寻址信息。比如在下面这个例子中可以看出有关Web Services的寻址信息全部包含在Http请求中。

POST /TravelAgentServices/Hotel.asmx HTTP/1.1 Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "http://www.seu.edu.cn/hotel/PlaceOrder" ＜?xml version="1.0" encoding="utf-8"?＞ ＜soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"＞ ＜soap:Body＞ ＜PlaceOrder xmlns="http://www.seu.edu.cn/hotel/"＞ ＜RoomOrder＞ ＜RoomType＞int＜/RoomType＞ ＜PeopleAmount＞int＜/PeopleAmount＞ ＜RoomAmount＞int＜/RoomAmount＞ ＜Price＞decimal＜/Price＞ ＜/RoomOrder＞ ＜/PlaceOrder＞ ＜/soap:Body＞ ＜/soap:Envelope＞

　　之所以长期以来都采用以上的方案建立在一个前提之下，那就是大多数的Web Services都是通过Http协议来访问的。如同我们访问一个网页仅仅需要输入一个URL, 在通过Http协议访问Web Services的时候底层的Web Services框架帮助我们在传输层自动的生成相应的Http请求，本没有什么不合适的地方。但是“大多数的Web Services都是通过Http协议来访问”这个前提已经不再适用于SOA的应用环境。我们知道Loosely Coupled是SOA的一个显著特征，而不依赖于特定的传输协议也是Loosely Coupled的重要体现之一，并且在广泛的应用中你会发现实现消息的异步传输以及消息的可靠性传输时，往往不再利用Http协议作为SOAP消息的传输协议，而会采用诸如TCP,SMTP等协议来传输SOAP消息，此时SOAP消息如何寻址？难道都依靠特定的传输协议来实现吗？

　　在SOA的背景下，Web Services寻址方式主要面临以下三个问题：

　　1． 访问Web Services将不仅仅限于某个单一的传输协议（如Http）。 在访问Web Service时可能会使用TCP, SMTP等等不同的底层协议。甚至在Web Services的请求中使用一种传输协议，而在回复中使用另一种协议。

　　2． Services之间的交互已不再是简单的synchronous request-response方式，在实际的应用中越来越多的发现异步式的消息交换更加适合业务的需要，在这种情况下Response消息如何寻址，已不再那么简单。

　　3． 在现实业务中，广泛存在一种现象，那就是在Web Services的请求消息发送后，过很长一段时间才能得到回复消息(如下完订单，几个小时或几天才能得到确认消息)。这种情况下，如何依旧将回复消息与请求时发送的消息关联上，从而维持住Web Services的状态？这也是以往的寻址方式所没有考虑到的问题。

　　而WS-Addressing规范则为解决以上三个问题提供了方案。 通过对SOAP消息的扩展，为Web Services的寻址问题提供更强大的支持，并且该规范也是其他各种WS-*规范的重要基础。

查看本文来源