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-* 规范的重要基础。