Digg Digg
DZone DZone
Furl Furl
Reddit Reddit

 Subscribe in a reader

Book Cover B = mC2

Business Strategy in a Multidimensional World

11/20/07 :: [SOA] REST, Processes and Resources [permalink]

Assaf pointed out an interesting article from Micheal zur Muehlen et al that explore the question of REST vs SOAP in terms of process integration.

IMHO, the article is focusing the discussion on the pros and cons at the protocol level.

The question I am raising is quite different, it has nothing to do with a "protocol", in the end you can decide that REST "as a protocol" is better than SOAP (I don't care about this answer, and really the answer is "it depends"). Of course the RESTifarians are outraged that this question could even be asked -and I understand why, because this has nothing to do with REST.

The question I have is on the pure application semantic level. The question is Does a resource have a lifecycle? if yes, there is a follow up question what is the understanding that needs to be shared between a resource and a resource representation consumer to transition from one state to another? So to be clear, the question is not on GET but on PUT. I also argue that the question's answer is quite different depending on whether a user or a system is the resource consumer. (This is also a question on GET with respect to "search", can "search" be modeled in a RESTful way? I am not sure the answer is yes, but that's secondary).

So if indeed, resources have lifecycles, and if indeed you need a shared understanding of "actions" expressing your intent to transition the resource from one state to another, I would argue that the debate REST vs WS-* is really at the protocol level. They are just two ways of encoding the same semantics. When a user is in the loop, REST wins hands down, if we are talking server-to-server, I would argue that WS-* wins hands down except where Amazon-like scalability is needed.

Now, since the article from Michael and his colleagues talks about "Process integration" I would like to clarify my position on the relationship between "Process" and "Resource lifecycle". This is not about process integration but rather how do you factor resource lifecycle within a business process. Here is a Job Application Process modeled using BPMN (click on it for a larger view).

job application process

As you can see, the states of the Job Application resource are not visible in BPMN (nothing wrong with that, this is not necessarily a concern of the process designer, this is rather a constraint for the process implementation). More importantly, the activities performed by the participants are orthogonal to the actions invoked as part of these activities. The activity boundaries can span multiple actions or match exactly the actions that will result in state transitions.

The job application service is assembled with other services (such as human tasks) to perform the process.

the job application service operations are constructed from the transitions within the state machine  

In effect a process is merely an assembly of services (click on the picture to zoom in), i.e. wiring service operations (both inbound and outbound) with each other:

assembly of services as a process

This why SCA is so critical to BPM. A process container is an SCA container. Steve, the very reason you say:

I believe that it’s important to avoid specialized interfaces whenever possible and prefer a uniform interface instead. Interface specialization, even of the minimal variety you mention, inhibits reuse.

is because you don't understand the concept of an assembly and what it does for reuse in a server-to-server scenario. It is not by moving to a minimalist interface that you will promote reuse. You cannot ignore the semantics of an action. The solution that you are recommending to improve reuse is the worst I have heard in the context of server-to-server communications. You are pushing the reuse problem at the developer level: "figure it out", read the doc, script the reuse. 

In this picture, BPEL is the implementation language of composite services such as the Job Application Service. a few lines. Resources and resource lifecycles are at the foundation of composite application models. At the end of the day I can't care less about which protocol the REST community, Microsoft or IBM wants me to use, all I care about is having the correct application semantics to build composite information systems. That's all I need, that's all I want. If you want a more detailed discussion, I have written a nibook on the subject available to download oon infoQ.

Sadly, and I repeat, the thought leaders that define programming models (Assaf was one of them in the BPM space) have ignored systematically this factoring. Resources and Resource lifecycle remains a concept that you have to code over and over no matter which programming model you turn too (including Erlang). After almost 10 years of "thinking" on Service Orientation this is the best thinking you get:

Don Box: Personally, my dream stack would be ubiquitous WS-Security/WS-Trust over HTTP GET and POST and tossing out WSDL in favor of doing direct XML programming against payloads from VB9 (or XQuery), but hey, I have unusual tastes.

Assaf Arkin: The orchestration landscape is a mine field of different opinions. For some, it's all about top-down static endpoints using infrastructure to exchange control messages in the background. For others, well at least me, it's about message passing between processes, and REST fits nicely in that.

Bill de Hora (speaking for the RESTifarians): So, in a business process where GET and PUT (and friends) apply to *all* business entities and are not just per process defined methods, why can't I GET the state and have a well-understood formal document returned citing the state of that entity? Or for that matter PUT the updated state to that entity? What's the actual  limitation induced by applying REST?

Steve Vinoski: I know from significant first-hand experience what both sides of the coin look like, and there’s no question that REST-oriented systems are easier and less expensive to develop, and far less costly to extend and manage. Like Dare said, anyone who thinks otherwise is either so emotionally or monetarily attached to WS-* that they can’t be objective, or they don’t actually write any code or build or maintain any actual systems. It’s no contest, really."

At this point, I start wondering who is not writing code. This is why I am a bit upset at the REST community, at Stefan and Bill, and others. Only you, have the concept of a resource within your programming model. This is the opportunity to revolutionize the way we construct information system, this could be a benefit almost as big as the web itself. Yet this community wastes all its time, and other's time, trying to funnel all application semantics through two verbs. That's all they care about. In the process, they have lost sight completely of what a resource is.

Again I am not selling technology, but I want to point out that the application semantics offered by the SOA technologies at large make sense, they fit with one another, and it is not because Don, Bill, Assaf, Steve and others can't figure it out that we have to throw it all away.

This whole stack is available today in the Java world (open source or commercial). The only piece missing in the .Net world is an "interoperable" assembly model. SDO is available in .Net. XCalia has built it. Microsoft, with the help of Dave Chappell, is trying to convince you that you don't need SCA. They argue that this is a "portability" problem. Note that I am not arguing that Microsoft should adopt the programming model of SCA, that's a very different question. They have innovated and invested massively in WCF and I don't see a need to change that. But hopefully I have convinced a few more folks in Redmond (and Armonk) that they need to offer an interoperable assembly mechanism. The value is in what you assemble on-premise or off-premise, not in the assembly mechanism itself. In some ways, I don't care, because someone like Xcalia will build it based on SCA without Microsoft's control and value add. This is just a matter of time.