09/27/09 :: [SOA] Boris on Service, Web and REST [permalink]
It is no secret, I really like the kinds of things Boris is writing about SOA. His book is a masterpiece. It is complete, accessible, based on a deep experience and contains zero fluff. And of course someone of his caliber could only have a measured position in the REST vs WS-* debate:
Both REST and WS have their place in real life implementations. The issue should be not which one is better, but rather how they can coexist and when is one more appropriate. The other important thing is to make sure that comparisons are based on merits, not beliefs, no matter how strong they are. There are many useful standards and patterns created by WS* and the issue is whether it makes sense to start over or to see how these patterns can be applied to REST.
Dilip Krishnan, another InfoQ editor, and RESTafarian at large, not surprisingly responded:
Can we finally agree that the word "service" is as, if not more important, then "Web"
What does this even mean? important for what and for who?
I say not surprisingly because RESTafarians have no clear position on "service", they just say REST is the right way to build a Service Oriented Architecture. Yet, REST has no concept of "service" anywhere, just resources and their shiny uniform interface, links and bookmarks. Indeed there are no services in REST. Just read the thesis.
But RESTafarians can't care less, if they don't understand or can't explain something, the solution must be in REST somewhere and they look for it, one hack at a time. It is interesting to see how the mind works, it makes you wonder how come mankind has made any amount of progress, ever since we set foot on this planet, and what progress could we have made if we didn't get stuck in the mode of "the solution must be in this book/thesis/theory somehow, I just have to find it". Well the reality is that the solution is often, if not always, outside the box. Just ask Newton, Einstein and the many less known scientists. In computer "science" we have a very small, actually, we don't even have a box, we just have a square: one axis is Turing-complete and the other one is OO, and everything a developer can be given to do his or her job has to fit on that square. You would surely fall off a cliff if you dared go outside.
But I digress, let's go back to "services". Even Bill, in this REST-* proposal is talking about creating a RESTful interface to non RESTful services. That certainly begs the question, how can a service be non RESTful since REST is all about SOA and replaces in its entirety WS-*.
Ganesh, in all his wisdom, has become a RESTafarian. It is interesting so see someone that understands SOA becoming a RESTafarians, at least you can have a much deeper discussion. He came up with the concept of REST as being Polymorphic CRUD:
IT folk in the enterprise understand both polymorphism and CRUD, so the combined term should make sense. I want to drive home the point that a verb itself is neither coarse- nor fine-grained, it's how each resource interprets it. Fine-grained resources will interpret the REST verbs as CRUD operations. But more coarse-grained resources can interpret the verbs as any arbitrary business operation.
I find also find interesting his use of the word polymorphism, because for me REST is just a better CORBA, i.e. object oriented but it is not service oriented. There is no better post that explains how small the square we are left to play with that Pete Lacey's post in 2006.
They want transactions, and reliability, [bidirectional interfaces, assemblies] and asynchronous messaging, and orchestration, and everything else.
So, Boris committed heresy (defined as proposing some unorthodox change to an established system of belief, especially a religion, that conflicts with the previously established opinion of scholars of that belief such as canon). He dared say that we should focus on Service not just the Web. Unfortunately, Dilip, Ganesh, Bill and so many others, I would like to repeat that there is no evidence today of any application being built in a RESTful way. There are APIs to CRUD data here and there, but the day you'll show me an ERP system built in a RESTful way, we'll talk again.
For me a Service is a software agent which :
- performs a well defined unit of work, invoked by expressing intent, with minimal or no knowledge of the context in which this intent is expressed
- is readily accessible by an arbitrary number of other software agents implemented in arbitrary technologies
- can change the way it performs its unit of work or specify its intent without necessarily breaking the software agents that consume
- the resources involved in the performance of the unit of work, i.e. a service, may participate in more than one service
This is what happens in life every day. We consume countless services by simply expressing intent (e.g. call someone), these services can scale without impacting me (a wireless carrier can add a subscriber without me noticing), and these services can change again without impacting me either (a wireless carrier can add a "favorite list of callers" without me noticing). An airplane can be involved in performing several services simultaneously (transporting people, parcels and letters).
Service orientation is about creating solutions from this type of software agents (instead of tier-ing and integrating) to achieve the same benefits that we realize in a service oriented society. Service orientation is way out of the square. It's not that hard, but it definitely requires some unorthodox change to an established system of belief. The irony is that the RESTafarians, including Roy, are representatives of this square based system of belief. They want no progress to be made whatsoever. On the surface, REST could be easily mistaken for a Service Oriented technology. After all it supports 2) well, and has some aspect of 3) taken care of (It doesn't break anything because there is nothing to break). But that's the problem, there is nothing to break, there is no intent in REST, there is a million RPC-like conventions, mostly at the CRUD level. When Ganesh says that you just have to POST something to /applications, and that replaces submitApplication, where is the intent expressed? is POST an intent? can this application participate in different "services"? No, it is not an intent, because you have to file it yourself in the appropriate hierarchy /applications. This is the tight coupling SOA has worked so hard at trying to remove. Service orientation is about expressing an intent and have no particular reason to know what happens next (hint, an RPC call is not the expression of an intent).
The CORBA guys see all this as the promised land, they just pushed the problem of brittle and chatty interfaces to developers. Interfaces are the problem, so just tell people they don't exist anymore, they have been CRUDed away. All you do in REST is "encode" all your application semantics. They sure can expand without breaking, but they can't change. REST is CRUD and CRUD is a tight a coupling as you can possibly imagine.
So yes, Dilip, Service is almost as important as the "Web", but I am not sure you'll ever figure it out.