11/07/07 :: [SOA] Yet, Another REST Fallacy [permalink]
Tonight, I was reading Mark Masterson's blog where he continues his thoughts on an enterprise 2.1 manifesto. One element of the manifesto favors: "Resource orientation over service or object orientation for distributed systems design". I followed the link he referenced to support his assertion and I came across this article from Alex Bunardzic (August 2006). This article seem to have been blessed by Stefan (based on a comment he posted). So I am assuming he considers this is REST compliant.
It is always interesting to play with architecture concept. This is an activity that should be widely encouraged and practiced. Recently I came up with a "Feed Oriented Architecture" concept, but I did not claim to displace anyone, Resource Oriented Architecture or Service Oriented Architecture for instance. Playing, opens your mind, encourages you to explore without pressure whether you are a software architect or say a residential architect.
One day however you have to build something real. So what's real for Alex? The paragraph that caught my eye in Alex's musings was this one:
Once the representation of the resource’s state has been consumed, the requesting client may make a decision to modify that state. For example, if the state of the identified tennis court is that it is free on Saturday morning at 10:00 am, the client may decide to change that state to booked. The client sends another request to the resource, this time using a different aspect of the protocol (basically, using the aspect number 2). The resource handles this request, and, obeying its business logic, makes the transition from its original state (free) to its new state (booked).
Alex claims that resources have states and of course there are transitions between these states. So far so good, that's an established concept. The plot thickens when Alex tells us the "client" may decide (huh...how?) to change the state of the resource. Well the "how" is by sending a request of type 2 (Alex explains: "Each resource knows how to make a transition from one state to another state", what "knows" means? exposes a method?). Once the resource receives the request is executes its logic and make the transition.
So let's replay very slowly what Alex is telling us:
- when he says the "client decides" he means the "user" in the browser, looking at the resource representation, making sense of it (based on a common language, say English and common understanding of a link semantic) and pushing the link to reserve the court.
- How does the resource knows who is reserving? well that's a mystery
(I know I can hack it in, I am talking about achieving it in an
interoperable way).
Now let's look at how a "server" would interact with the resource (not a user). How would the server "know" that this link would reserve the court? Are we assuming a natural language capability embedded in REST? Well in reality, this is probably the untold constraint of REST. This is possible, I did built a natural language engine in 1996 to interact with "objects" using Objective-C (and NXDictionaries to support synonyms of nouns and verbs) at Hughes Research Labs. This was the best piece of code I ever wrote and it looked quite spectacular. I remember a Stanford graduate looking at my experiment and yes, I could interact with it in "natural language". He sat down at the keyboard and started to interact with the experiment too.
I digress, huh.. wouldn't a contract be necessary to establish the semantics of the action? How would the server know otherwise?
I'll leave it there, REST is not viable as a style to support the architecture of enterprise information systems and deliver Presentation, Process and Information federation. I can see a world where REST owns say 80% of the Presentation federation. The other 20% is owned by WS-HumanTask and WS-RemotePortlets. I don't see REST achieving process and information federation in the next 10 years (that's how long it took for WS-* to mature).
Sincerely I am surprised that Stefan considers it to be REST compliant, but it does not change my argument, the real question is how do you model an action to transition a resource from one state to another. The answer is that you don't.
Now I think the burden is on the REST community to explain their plans to support the WS-* application semantic such as Orchestration, Peer-to-Peer, Events, Intermediaries (including pub/sub), Security, State Alignment which are going to be extremely hard to build into the model without doing a copy cat of the WS-* specs.
Good luck with your REST enterprise initiative.