WS-Web (The Web using SOAP:-)

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

In his posts, Chris made some excellent counterarguments to Carlos‘ position. BTW… Something that Chris didn’t point out to Carlos is that the HTTP operations being used in the examples to support the REST case are also RPC since that’s the nature of the HTTP operations. Which brings me to this… HTTP != REST. HTTP is just an implementation technology that can be used to build RESTful applications but it can be easily abused to build applications following different architectural styles (cookies anyone? 🙂

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.

This is a typical normal WS-Transfer request. The <wsweb:WebResourceId> header identifies the resource. The reply to the above message is:

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.