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...

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.

<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:-)”

  1. You masochist! 😎 P.S. how would anything have changed if you had used “http://ws-web.example.org/index.html” instead of your URN?
  2. Hey Mark… If I had used the ‘http’ scheme I would have effectively suggested that the identified resource would be accessible via the HTTP protocol (according to the semantics of the scheme). This may not be the case, however. Resources are identified independently of the manner in which they are accessed. One could determine at runtime (through metadata for example) that it is possible to do an HTTP GET urn:uuid:bla-bla-bla-bla for a specific resource but also use the same URI with any other application protocol (current or future).
  3. “If I had used the ‘http’ scheme I would have effectively suggested that the identified resource would be accessible via the HTTP protocol”. Not at all. The definition of the http scheme in no way requires that a Web server be setup to answer HTTP requests. If you use a http URI, you get all the advantages of the URN – protocol independent persistent identification – but you also get a convenient low-cost, widely accessible hook into turning that identifier into data… *if* you choose to use it. If you don’t, then you’re almost exactly as functional as an URN, except with a different registrar for the authority component. At what point would your code break if you used an http URI instead of an URN?
  4. Hmmm. 🙂 I feel that i am falling into a trap here 🙂 I am probably going to regret this but… yes… I wouldn’t have a problem at all if the URI used the ‘http’ scheme or the ‘smtp’, ‘ftp’, or any other scheme for that matter. It’s a URI, any URI. However, what I wanted to avoid in my example was any assumption that the resource was seen as an ‘interactive’ architectural entity (i.e. you were able to communicate with it via application protocol verbs suggested by the used URI scheme). In the example, the application protocol is supported by the service and not by the resource (at the abstract level).
  5. Heh. That’s cool, I think we just dissected the “URL vs URN” issue into two parts, and are in synch on one of them; any URI works to identify. Next up, convincing you that the second part – that the identifier include sufficient information to enable direct manipulation – is critical to decentralized extensibility and therefore scalability. That’ll have to wait for another day though. 😎
  6. Mark, I am sorry if I gave the impression of not agreeing that any URI could be used for identity. That has always been my understanding. It would have been fullish of me to support otherwise given the ‘I’ in URI 😀 On the second part, however, I’ll have to be pursuaded. I think WWW2005 would be interesting 😀