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.

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.