Perhaps it is a break from REST, but it isn't a break from the core SOAP architecture -- which as a message packaging protocol is designed to be completely independent from the underlying transport. (and we all should admit that SOAP uses HTTP as a transport, not as a transfer protocol)
The SOAPAction parameter may be RESTful, but it isn't SOAPy. Message routing should not rely on any transport-specific parameters. (How can you specify the SOAPAction when using JMS, SMTP, FTP, or Jabber as a transport?)
The W3C WS teams have spent quite a bit of time and effort to make sure that Web services operate as good RESTful citizens, but SOAP is based on an SOA architecture rather than a REST architecture. (Its focus is on services rather than resources and state) There are times when the two architectures clash.
Web services are now based on resources and state, at least according to last week's press releases.
The true power of SOAP is derived from the SOAP processing model -- not from its ability to send and receive messages to a specific URL. A resource always exists at a specific URL. Services are more abstract than resources -- it could be that you might have a number of resources that cooperate in providing the service. You can redirect the URL, but redirection isn't an especially dynamic, policy-driven process. The Web services architecture requires a more dynamic mechanism to route requests.
Some uses of it do, certainly, even if by adopting asynchronous messaging you lose (without time bounded comms) the ability to achieve, in formal terms, agreement or common knowlege.
> WS-Addressing enables support for asynchronous
computing, content-based routing, version management, load balancing, and other capabilities.
1. I can have different versions of a service at different URLS. that is what DNS is for. That is also what UDDI was nominally for.
2. content based routing. hmmm.
3. its a lot easier to load balance based on the URL
Essentially SOAP messages implement the command pattern (GoF 223). You send a document containing the command. The command may be explicit in the action, or it may be implicit in the type of the body of the message itself.
often we forget this with our XML-doc-to-objects-and-method code binding tools, be they Axis or something else, but essentially an endpoint is receiving documents that hint what they want done, either explictly or implicitly. We are already doing content based routing, it just happens to be routing to classes and methods in the same JVM, and the fact that this is taking place is hidden.
But I could do more explicit routing of incoming messages if I wanted to, today.
What ws-addressing does do is permit explicit store-and-forward communications. It also enables the complete abandonment of HTTP as an underlying infrastructure. does that make it a good thing? I dont know. i quite like fact that HTTP and SOAP are mixed, as some other people used to think: http://msdn.microsoft.com/msdnmag/issues/0300/soap/default.aspx
-Steve
