05/08/08 :: [SOA] Open Letter to the (other) Rest Community  [permalink]

|

I know it is far easier to tell me that "You don't understand" than to have an intelligent discussion about the kind of things you dare publishing.

When someone is capable of writing :

The statelessness constraint isolates the client against changes on the server as it is not dependent on talking to the same server in two consecutive requests.

I don't know who does not understand what. Why don't we run a scenario to validate your point? Again, in Roy's world, I see exactly how this works, but when two software agents communicate (say on behalf of two resources inter-acting - a PO and an Invoice), that is pure rubbish. I don't know who convince you of this, but this does not make any sense if unqualified.

I have spent an extensive amount of time reading about your claims and in particular I read your bible, the RESTful Web Services book, front to back. All they explain in this arrogant book is how they created a DAL using REST, and with that they claim victory. Incidentally, to build a decent DAL, the concept of "collection" was missing  in (Roy's) REST, so APP was put together to plug that inconvenient hole after years of efforts.

Let me repeat it, your understanding of SOA is pre-2004, what you say about SOA and Web Services might have been true at some point, but things have evolved and it is antiquated today. As Udi pointed out, this is not SOA 2.0, but the picture that we have of SOA today is a lot clearer for a lot more people than it was before 2004.

You know, or course (but that would be too easy) that the best way to convince me (and many other people) is to show me something that does not look like a DAL, so far all the examples I have seen from you or anybody in your community are DAL-oriented:


Yes, you understood that my questions are relevant so you sugar coated your interface with "SubmitOrder" or "Cancel Order" (did I say interface? did you see the interface? the actions? does not look that uniform to me !).  You proceed to explain (smartly not in the article, but way down as an answer to a reader's question):

a) one is to PUT a new state to the resource, effectively changing its internal e.g. from booked to shipped.

b) Another way is to do a logical move of the resource from one collection (of booked orders) to another (of shipped orders).

c) A third way is to represent the state change as a resource in itself, e.g. by POSTing it to the order where it becomes a sub-resource. This way, you have a history of changes. The mapping to CRUD is not 1:1 -- a POST can create new resources, or simply process something and return a result. In case a POST is used to create a new resource, the server chooses the URI.

So you would easily admit:

a) is an "UPDATE" and you also understand the coupling it creates between the consumer and provider.

b) is an "INSERT" in a collection, but it is not really practical because you'd have to "search" all collections to figure out in which state the resource is. (I assume that when you say a "logical" move, you are not doing a physical move so other links to this resource would not be broken, right?)

c) is funny, now you "INSERT" another resource to the initial resource, of course that's not CRUDy? How does the consumer gets notified that the order submission failed or succeeded? 

And, all the consumer wanted to do is express his or her intent to "submit an order". Do you really think this is a lot simpler than non-CRUD oriented approaches? Who are you fooling? 

The reality of everything that you explain is a "build-as-you-go" CRUDing language that can deal with the complex cases supported by SQL or XQuery and which relies on a million different conventions decided in a common document between the developers of the consumer and the provider. This is not coupling, this is called mortar. These conventions will be done and interpreted differently by different people. So what have you gained? absolutely nothing, we just created a bigger mess than before. Sure, some people can now get back to their familiar CRUD-Oriented Synchronous Client/Server architecture and continue CRUDing happily. They don't realize that COSC/S is the core of the problem in IT today. Some people call that "“Full control without much complexity.” Yeah, that works for me.

But of course "I don't understand". How easy! Why don't you show us the code? Why not? why wait for questions from the readers to even touch that very central question? (BTW, I was not the one who asked the question in case you wonder, I always use my true identity - but of course, I am lonely).

At the end of the day, I have simply never seen any evidence that the (other) REST community would use (Roy's) REST for anything other than a DAL and CRUD around with it. When you talk to Steve Vinoski, the action "interface" does not even exist. Few people are that "extreme", the non-sectarian REST lovers use POSTs and define an action interface with WADL. If I understand Roy correctly, that's considered RESTful not harmful.

You have one way to stop this huge waste of time: why don't you show us a non-trivial scenario implemented with REST principles? Pick your process, insurance, banking, procurement, reserve a tennis court… whatever. Maybe, just maybe, you will realize that you can't build connected systems with just a DAL and a CRUD mentality. You might also realize that even this principle will not work: "REST is limited to the client being told what to do next by the current state of where they are now". The way Roy frames REST is counter to SOA principles. It assumes an "application" boundary. It assumes shackles between the client and the server. SOA is about Peer-to-Peer software agents performing units of work. There is no client, there is no server, there is no-single agent telling everybody else what to do. There are autonomous agents which work Coordination (and not cohesion) is a central concept of SOA. Go read WS-CAF if you don't understand what I mean.

Yes, I have great hopes for the future, I start seeing that there is a strong movement emerging behind SOA. It is built along the lines of SOA-a-la-WSDL with a bi-directional interface asynchronous mechanism, with orchestration at the core, coordination at the center, with resources too !  SCA and the SCA's Widget capability will kill this silly RESTy CRUDing, have no doubt about it.

I think at this point you guys are just wasting everyone's time. Other "You don't understand" won't cut it much longer... hey, you can use it as much as you want, but, funny enough, there is only one thing that I care, it is precisely to "understand" like the most of us. So why don't you explain? No you won't...