Despite what the toolkits would have us believe, SOAP is not the only way to build services based software. SOAP has some good things going for it: standardization, service metadata, vendor acceptance and rich tooling. However, it's not without its issues, particularly when building very large systems that require a broad reach to consumers. It is no accident that Yahoo, Google and Amazon have chosen not to use SOAP to expose their programmable interf aces. In the first part of this two-part article I'll detail some of the issues that SOAP has in building systems. I'll then move on to explain how REpresentational State Transfer, or REST, is an architecture that doesn't suffer from the problems that SOAP does (although has issues of its own). Then, next month, in part 2, I'll show how you can create and consume REST based services using WCF, ASP.NET and LINQ to XML.
What's wrong with SOAP?
Before looking at REST and what it offers. We need to examine challenges in the SOAP world that are hard or impossible to solve. So let's get a clear picture of how SOAP works. SOAP relies on XML messages being sent to a defined endpoint. The service at the endpoint then works out what to do with the message based on the action header that is part of the WS-Addressing standard. When we are talking about services that are part of heterogeneous environments these messages will be sent using HTTP. However, because of the nature of the payload (textual XML) they are always sent using the HTTP verb POST. They could, in theory, use other verbs but why bother, the intent of the message is in the action header not in the way it uses HTTP. HTTP is purely there as a transport, the message is independent of it. Web Service Description Language (WSDL) is an XML dialect used to describe the endpoint including all the operations available there and what messages they require and what messages they may send back. It all seems pretty reasonable, so what are the problems.
HTTP is only a transport
Having the message independent of the transport would appear to be a good thing, so why is it a problem? The web has been proven, empirically, to be massively scalable. The question is, "how"? How do web requests generally work? When you issue a web request there are two important things that occur: the link is to a specific URL which may not be the same machine that delivered the page you are looking at; you are very often using HTTP GET. The first factor means we can easily spread the workload; one machine (or farm) is not acting as a performance pinch point. The second factor means the caching infrastructure delivered as part of HTTP 1.1 can be leveraged to make sure that a proxy server, or even the client machine itself, can service the request without the target web server ever being touched. Compare this to SOAP: all requests hit the same endpoint before they can be filtered by action header and POST cannot be cached. SOAP cannot use the very infrastructure that makes the web so scalable.
The application protocol is not in WSDL
The application protocol is the sequence of valid operations that a service can perform. Take a shopping cart; we might have a number of operations that could be performed:
a) Log in
b) Search for product
c) Put item in cart
d) Remove item from cart
e) Go to checkout
f) Log out
As a human you can see the various workflows that could occur through this series of operations. You can also spot sequences that are wholly inappropriate: go to checkout before putting any items in the cart; Log out before log in. The problem is machines have no way to determine this sequencing unless it gets documented somehow in a machine readable form and this information is not encoded in WSDL. All the service can do if it receives a message for an inappropriate operation is the service orientated equivalent of throw new InvalidOperationException();.
Now where was I ...?
If a series of operations takes place over an extended period, the client may want to stop and continue the exchanges at a later time or date. To do this they have to, essentially, remember everything they have done so far. Nothing intrinsic about the endpoint will tell them the state of the exchange. Picking up the exchange means understanding the next valid options without the endpoint itself being able to help in any way. Compare this to how the web works – where you got to while using a website is normally encoded in the current URL. In many situations you can pick up the processing simply by re-using the URL. Now obviously business context may preclude this, for example, an insurance quote may only be valid for 48 hours. If you try to purchase the insurance after that by reusing the URL the insurance website would force you to start the process over again. This, however, is a business restriction, not a technical one.
Not everything is XML
In SOAP, if I want to retrieve an image, I have to pack that binary payload into an XML message by either using base64 encoding or by using the MTOM standard. Then when I receive the message I have to decode it to be able to display it. This seems highly over-complicated if I know I am getting an image that I could simply display.
Comments