An attempt to move on from “processThis”

The “processThis” idea that Jim and I have been discussing for some time now has won us a place in Mark Baker‘s progress highlights for Web Services. Like Jim, I too am flattered. This is really significant coming from someone like Mark whose opinion and ideas, as he already knows, I really value. We’ve been exchanging offline messages and blog entries with Mark for some time now and it has been really educating for me and helped me tremendously when working and developing ideas in the area of Web Services. I only wish that others were as open minded and willing to participate in discussions (hint: part of the community that borrows its name from the US National Grid power network 🙂

I am now thinking that it is time to explore whether it would be possible to take the “processThis” idea to a next level. First, we really need to change the name; perhaps something like “processDocument” or “processMessage”; I like the latter better. Then, we need to demonstrate that we are not that far really from REST and, in fact, the REST approach can be seen as a subset of our model where the protocol verbs are effectively modelled as a submission of documents to the “processMessage” abstract operation.

This last observation answers Mark’s point about the semantics of GET in this post. The semantics of GET can be captured through an appropriate SOAP message. An HTTP request-response pattern can also be described as a message exchange pattern in which the receiver of the request will send a message to the “processMessage” operation of the sender.

Finally, we need to write collect all the discussions and present them as concrete proposal, as a model for reasoning about the Web Services Architecture.

Matt Garland has two related posts (post 1, post 2). In the second one Matt talks about my concern that the use of URIs as references to resources may lead to fragile applications due to the potential complex webs of references and interrelationships that may be created. He argues that the same problem may exist with references to Web Services. It is true that a Web Services may fail and the “processMessage” abstract operation may no longer be available. However, since there is no binding and dependence to state, there is no problem. We can always discover an equivalent service and use that one. Of course, if there is no equivalent service we are in trouble. The point is that there are no state-depended interrelationships.

As for the use of a URI or a URN, I really don’t have a strong opinion. I argue for the decoupling of identity from protocol-specific semantics. If one decides to use a URI of the form http://bla.bla.bla.com/resource as an identity ignoring the semantics of the HTTP verbs, that’s fine with me. It just seems odd.