11/16/07 :: [SOA] What a strange debate [permalink]
What a strange debate it makes when a community says "All you need is XXX" and another says "You at least need XXX + YYY". The first community says, since you are not on our side, you are against XXX. Nothing could be more wrong. Note that this debate is even more surreal for me since I am a WSPER guy and WSPER's goal is to let you choose whatever you want at the infrastructure layer. I don't care. I only care that I can implement WSPER.
I respect Stefan enough to know that he is 150% sincere on what he writes, though I cannot understand that he does not spend a bit of time looking at what he can't do with REST or could do better with ws-*. I think he understands that remark:
I think Erik is right in that we should maybe focus more on what to do instead of what not to do.
I read Jim Webber's interview, were he talks about MEST, REST and Guerilla SOA:
Operations are an abstraction which I do not believe exists in a service oriented architecture
I also attended Microsoft's Strategic Architecture Forum this week (which explained why I could not answer earlier). I met with the Microsoft's Robotics team which claim to have invented a new REST-based middleware but they had to use 9 verbs and add the concept of "event" to REST. They claim extreme scalability...
So what does REST/MEST/MSR have in common? They look at a very small piece of the problem and they each claim we can cover everyone's use case. Note I did not put the WS-* in it because nobody claims you can do everything with it. Personally, I am in the "apply the most appropriate solution to the problem" camp. I am against all form of fundamentalism. I think of a fundamentalist someone who applies consistently the same solution to all problems. I am a WSPER(WS-*/ebXML/REST/MEST/MSR/...) guy.
I just would like to go back to the debate for a second and express some of the arguments I told the MSR team. Mark does a great job at focusing the debate with extreme precision:
Workflow systems try to use the machine to assist in the coordination of work between actors, that coordination often being tedious and error prone and therefore ideal for automation [don't write this code by hand]. ... Does REST do anything to help us build such systems?
... the real question is how do you model an action to transition a resource from one state to another?
You take for instance WS-CAF, one of the best spec I have ever seen (now defunct and replaced by the sub-standard WS-TX, SOA lost a lot in that swap). WS-CAF is about a generic "Coordination" infrastructure. Do I need it to build a Service Oriented Architecture? Could I built it in a REST compliant way? I believe so, since a coordination context is one of the most well-formed resource you can find. But, would there be reasons for offering an alternative implementation? yes, WS-CAF supported also a "pass-by-value" model for the coordination context. Is that REST compliant? I don't think so. But that's not the point, the point is that the REST community is looking at a very small set of use cases which involve massive scalability and presentation federation (a.k.a. mashups). When the use cases change, they have to invent new concepts like the MSR team. With WSPER for instance I set the context of "Your typical IT information system like CRM, ERP...", I don't claim WSPER is applicable to Google, Yahoo and Robots. If you can apply it great, otherwise, find another solution, always find the solution adapted to your problem (today and the foreseeable future).
The commonality between REST, MEST and MSR is that they seem to have chosen the distributed computing paradigm that fit their problem space (elegantly and efficiently), but they are all wrong in insisting that this is the only paradigm you'll ever need. The mere existence of three groups claiming the same thing should make it clear that neither is right. Frankly I was equally disappointed by Jim Webber's talk but I don't have time, energy and passion to start a debate on "sending/receiving a message is all you need". (Jim, One Ways and Notifications are "operations" in the WSDL sense).
The fundamental question that I asked the MSR team was "where is the business interface", in other words "how do you model an action to transition a resource from one state to another". Incidentally, this is all you do in information systems. This is your only goal. When you have an information system, all you want to do is to change some state in it ( add, change, cancel an order), and you must have a clear shared understanding of the state you want to change. But is it practical to change the state directly at the resource representation level or is it better to have access to a series of actions to change that state? I claim that it does not matter, the result is the same. In the UI, there is always a "button" that you push to cancel an order. Again, I can see how REST simplifies presentation federation and requires no knowledge at all from the user/client perspective to invoke this action but this is only an optimization of two identical concepts. Granted an elegant, important, must-use optimization (ok, no schema means validation hell, but let's pass on that). I get the caching requirement that you can't apply in the WS-* world, but that's also an optimization. I could however understand that REST would claim superiority if it did not require any "server-side" code, if somehow, resources were true resources and there would never be a bit of logic in between the client and the resource, only GETs, and PUTs. But we all know how much client and server code we have to write between a button click and a resource. If Stefan can show me how the goop between the client and the resource magically disappears, I will become a RESTifarian.