Just joking... I haven't come up with yet another specification. While travelling to Seoul, however, I was thinking about the on going discussion on REST vs SOAP. This is my small contribution to this discussion: An implementation of the 'Web' using SOAP 🙂
Background reading
Lately the REST and SOAP folks have been busy arguing about which approach is better for Internet-scale systems as a result of Carlos Perez's three-part post on "Why REST is better" (part 1, part 2, part 3). First, some background reading...
- Carlos Perez's "SOAP is Comatose But Not Officially Dead!" and "More Nails For SOAP's Coffin"
- Mike Champion's "'SOAP is Dead' - if you believe the echo chamber"
- Bill de Hora's "The integrator's dilemma"
- Chris Ferris' "Bring out your de-ad!" and "1+1=0"
- Stuart Charlton's "Interop with SOAP and REST"
- Steve Loughran's "SOAP not dead, well not quite"
- and many more... via Google and via MSN Search
REST vs SOAP - Apples and Oranges
Some have argued that comparing SOAP and REST is like comparing apples and oranges. I fully agree with this position.
How can one possible compare REST and SOAP when the former is an architectural style while the latter is a piece of technology? In fact, isn't it the case that we can design an application using a particular architectural style for distributed computing and build it using any piece of technology? For example , one can build service-oriented applications using RPC and object-oriented applications using Web Services technologies (e.g. WS-RF). Of course some technologies are better suited for a particular architecture or make it easier to build applications following specific architectural principles (e.g. CORBA for distributed objects, Web Services for service-orientation).
So, in order to prove the point that SOAP should not be compared against REST, I decided to do some coding. Since I had just finished the implementation of WS-Transfer for PlumbworkOrange, I thought that it would be a great idea to use it to build a RESTful application. And of course, what's the most well-known application out there? The Web of course.
WS-Web
The idea is based on the following:
- Follow the REST principles for building the WWW but using SOAP and without assuming HTTP.
- The uniform application semantics of WS-Transfer are assumed.
- Each resource is still associated with its own URI although now the URI can be application/transport-protocol independent (e.g. urn:uuid:bla-bla-bla-bla). This has the advantage that the name or identifier of a resource is not coupled with the technology used to access it.
- A message still relates to one resource at a time although one could imagine that multiple URIs could be included inside a single message. This is not so much because of WS-Transfer but mostly because of the REST principles. In fact, I would personally prefer if the semantics of WS-Transfer and REST were not resource-oriented but rather service-oriented; this would have allowed us to have multiple URIs in a single request so that multiple state representations could be accessed with one message. (This is a topic of a different post and perhaps paper
Architecture
Simple stuff... We have a Web Service that understands WS-Transfer offering access to the state representation of some Web resources and a Web browser that sends appropriately formatted SOAP messages to that Web Service.
Implementation
I used the WS-Transfer implementation, which is now part of PlumbworkOrange for both the browser and the service with WSE 2.0 implementing the underlying pluming.
For the service, I had to write a WS-Web-specific resource provider for the WS-Transfer implementation (as I explained in a previous post) which was a very simple task and only needed few lines of code. With .NET 2.0 I can even process ASP.NET 2.0 pages without needing a Web Server. Indeed, I was able to process the pages of my web site but, unfortunately, the output is not fully XHTML-compliant so I couldn't return the pages as SOAP payloads in XML. I just had to write few simple XHTML pages for testing.
The browser was simple too and only needed about 20 lines of code. I used .NET 2.0's Web Browser control. The Web Browser control is not allowed to navigate when a link in a page is selected (it wouldn't be able to navigate to it anyway since all the links use the 'urn' scheme). Instead, a SOAP message, like the one bellow, is created and sent to the Web Service.
<soap:Envelope xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope"/>
<soap:Header>
<wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/transfer/Get</wsa:Action>
<wsa:MessageID>uuid:7b1fb9e4-7347-47d8-b03d-e3bc05048492</wsa:MessageID>
<wsa:ReplyTo>
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:To>soap.tcp://localhost:10000/web</wsa:To>
<wsweb:WebResourceId xmlns:wsweb="urn:ws-web">urn:ws-web:page1.html</wsweb:WebResourceId>
</soap:Header>
<soap:Body />
</soap:Envelope>
This is a typical normal WS-Transfer request. The <wsweb:WebResourceId> header identifies the resource. The reply to the above message is:
<soap:Envelope xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/transfer/GetResponse</wsa:Action>
<wsa:MessageID>uuid:b0bf1724-8779-4502-bb2b-a8e83c0cd6aa</wsa:MessageID>
<wsa:RelatesTo>uuid:f3590721-b139-4d3b-94e9-8530321fbe96</wsa:RelatesTo>
<wsa:To>http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous</wsa:To>
</soap:Header>
<soap:Body>
<htmlxmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Untitled Document</title>
</head>
<body>
<p>This is page 1.</p>
<p>back to <a href="urn:ws-web:index.html">home</a>.</p>
</body>
</html>
</soap:Body>
</soap:Envelope>
The body of the SOAP message contains the representatin of the resource; in this case an XHTML page. Here's a screenshot of the browser (please note that I am using SOAP over TCP/IP to access my WS-Web site 🙂
Currently, only the GET operation is supported but I think this is enough to prove the point.
Conculsion
We all know that creating a REST-style application is not coupled with the use of HTTP. So, there is no reason why SOAP couldn't be used to create REST-style applications. In fact, I would argue that building the Web on top of SOAP has great advantages like end-to-end security, maintaining the intermediary-based architecture of REST for caching, the header-based extensibility, arbitrary transports even for a single message, tooling support for implementations, etc. The huge disadvantage of the approach, though, is the already widely-deployed HTTP-based infrastructure. I don't expect the Web to move to WS-Web any time soon 🙂
Both the REST and WS communities have a lot to learn from each other. We should constructively educate one-another and learn from what 'the other side' has to say instead of declaring each other's demise. For what it's worth, I feel that I have learned a lot from the discussions with the REST folks and together with Jim we hope to move that understanding forward to service-oriented computing with our upcoming MEST paper.
Update: Formatting fixed.
6 responses to “WS-Web (The Web using SOAP:-)”