Interesting couple of days with regard to the (never ending) debate between proponents of SOA and proponents of ROA.
On the one hand, the QCon conference (good grief, I wish I could have gone to that) in Heaven appears to have been the blast it was expected to be, and Stefan got some link mojo going with a kind of running diary on his blog.
On the other hand, JJ Dubray has posted a series of rants posts about the drawbacks of REST and the dangers of seeing it as the next silver bullet.
I really like JJ. He’s far and away one of the brightest bulbs in the BPM / workflow / orchestration space, and some of the things he’s thinking about in wsper are real eye openers. I’m reluctant to draw the wrath of JJ, partly because I’m pretty convinced that he’s smarter than I am, and also because I know that on at least one level, he’s absolutely right — REST isn’t a silver bullet, because there is no such thing. Nevertheless, I can’t help but disagree with him. I’ll spare you a long post on the various details — other people (also much smarter than I am) have already done an admirable job of responding to JJ.
James Snell at IBM wrote one of the most interesting set of responses to St…
Interesting couple of days with regard to the (never ending) debate between proponents of SOA and proponents of ROA.
On the one hand, the QCon conference (good grief, I wish I could have gone to that) in Heaven appears to have been the blast it was expected to be, and Stefan got some link mojo going with a kind of running diary on his blog.
On the other hand, JJ Dubray has posted a series of rants posts about the drawbacks of REST and the dangers of seeing it as the next silver bullet.
I really like JJ. He’s far and away one of the brightest bulbs in the BPM / workflow / orchestration space, and some of the things he’s thinking about in wsper are real eye openers. I’m reluctant to draw the wrath of JJ, partly because I’m pretty convinced that he’s smarter than I am, and also because I know that on at least one level, he’s absolutely right — REST isn’t a silver bullet, because there is no such thing. Nevertheless, I can’t help but disagree with him. I’ll spare you a long post on the various details — other people (also much smarter than I am) have already done an admirable job of responding to JJ.
James Snell at IBM wrote one of the most interesting set of responses to Stefan’s notes from QCon, and in many ways, might just as well have been answering JJ’s post(s) too. In particular, the following quote struck me as being aimed squarely at JJ (albeit unintentionally):
When I consider SOA and REST today, I do not see two competing visions, I see an evolution that has brought the industry back to a core set of fundamental design principles that we seemed to have lost sight of for a while.
I also agree with JJ (or at least, with something that JJ’s implying) about one other thing: workflow (or orchestration, or BPM — whatever. At the abstraction level of the following discussion, it doesn’t matter what it’s called) is the hard problem. Bill de hÓra suggests that the need for workflow may be overstated and / or an artificial need prompted by architectural styles that create (their own) problems that need it as a solution. I’m sympathetic to that view, but lacking a whole lot of ROA goodness in the enterprise, it’s too soon to call it. Bill challenges those of us in the “BPM ‘camp'” to explain the value proposition better — I think that’s fairly easy. 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. Note that I tried to be very careful about my choice of words there — “coordination” is a relatively neutral buzzword, and it’s a passive verb. “Actor” can mean pretty much anything, and is certainly neither restricted to a human nor a machine. Etc. Does REST do anything to help us build such systems? No. Does it provide tools and a basis for building such systems? I think it might, and here is perhaps the only halfway intelligent thing I can add to the conversation that might also get JJ’s attention — I’m gnawing on the beginnings of the idea that we might be able to implement an entire BPMS on top of a RESTful infrastructure. What I don’t have is a coherent thesis — I can see the glimmerings of a solution, but no more, and normally, that wouldn’t be enough substance to justify talking about it out loud yet, never mind a blog post.
But what the hell. If my glimmering of an idea serves no other purpose than to get JJ’s attention, and get him thinking something along the lines of “Hmmm… That’s interesting…”, then it will have served it’s purpose. So here goes.
JJ says this:
… 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.
Yes. That’s a great question, if not the question. And I’m pretty sure that the answer is not “you don’t”.
Fundamentally, workflow systems have to handle two dimensions of utility: modeling and execution. To “assist in the coordination of work between actors” you have to do two things: allow for the desired “coordination” to be defined in some abstract way, and then allow for that definition to serve as the template for the real thing by using it to link actors and coordinate work between them. This typically implies two modes of operation: a build-time mode, where you model the processes — you write the “coordination” templates and store them persistently; and a run-time mode, where some sort of an interpreter runs in a (logical) hub, and where instances of the templates are created as the reaction to certain events. The interpreter tends to be an active participant in the process — it drives the coordination — these components are often called “engines” for that reason. The run time paradigm that seems to best suit this particular set of requirements is one in which specific instances of those “coordination templates” (the most common buzzword / jargon here is “process definition”, with a specific, run-time instance being a “process instance”) are assigned to specific actors via queueing mechanisms. A process definition specifies a given “coordination of work”, an actor represents some “doer of work”, and a process instance represents the “state of the work”. The intersection of these three dimensions — current state, current step in a process definition, and current actor — is that unit which is represented by the elements of an actor’s work queue. These are typically called “work items”.
So how on Earth could we map this sort of a system onto a RESTful architectural infrastructure? And here’s my glimmering of an idea — it is the inarticulate sum of the following observations:
- ROAs tend to be directed graphs. Maybe a network of hyperlinks is always a directed graph — I’m too
mathematically illiteratestupid to be able to tell for sure. But obviously some of them are. - I can get from a directed graph to a high level Petri net, in the sense of an isomorphic transform.
- Therefore, it follows that I should be able to model all of the known workflow patterns as a hypermedia directed graph, and it should therefore be possible to derive hypermedia directed graphs from any given Petri net. That seems to solve the modeling problem.
- Feeds in general, and Atom in particular, give us a mechanism of representing queues: worklists for actors to consume.
- The Atom Publishing Protocol, to quote James Snell again, “…was specifically designed to address the use of HTTP and Atom to publish and manage collections of web resources. That’s it. By happy chance it turns out that there are lots and lots of things that can be modeled as collections of web resources and thus are well covered by Atompub.” Thus, APP gives us an API for manipulating our work items.
I haven’t implemented actors yet, but maybe you could do that with the fascinating Atom/LDAP mashup. Security? HTTPS. Authenticated feeds are still somewhat exotic, but nearly ready for prime time. Getting the picture?
I’m not the only one noodling around with this idea. John Mettraux, the lead developer of the Ruby port of OpenWFE, just announced yesterday that Rufus will have worklists as Atom feeds. He and I twittered about just that recently, and he urged me to blog about it, so here ya go, John. 😉 There are probably other examples.
As I’ve already mentioned, this post is nothing more than public brainstorming. There are lots of open questions and problems to be solved inherent in what I’ve discussed here. For example, one of the things that I obsess about is the nastiness of hub-and-spoke architectures. But how could you have a distributed, P2P process management system? That almost sounds like a contradiction in terms. I dunno. But I immediately start thinking about Piles O’ Lamps, and a recent thread on the Rufus mailing list that ruminated on various persistence ideas, and then I think about the recent buzz around CouchDb, and then I think “Hmmm….”. Apart from that, I’ve repeatedly used the term “workflow” here, which may well provoke some ding-a-ling to jump all over me with silliness like “Irrelevant! Workflow is just boring human oriented stuff! We’re only interested in the incredibly complicated task of automated service orchestration, yada, yada, yada…” Yawn. First off, that’s all just so much buzzword bingo. BPM, orchestration, workflow, etc. — all isomorphisms, all fundamentally equivalent. Anybody who claims otherwise is either a) a vendor trying to sell something, or b) somebody who has been hoodwinked by same. So if you’re reading this, and you’re winding up to pitch me a “service orchestration is different!” fastball, please don’t waste your time.
Anyway. I suppose, JJ, the bottom line is this: one of the the most interesting concepts in the REST / social software cloud is the idea of feeds. Which is ironic, because this hasn’t escaped you. However, you do seem to be assuming that the advantages of feeds can be obtained without requiring all of the REST “baggage” (in particular, the uniform interface) that feeds grew up on. I have my doubts about that assumption, and what’s more, as I’ve tried to make clear, I’m beginning to suspect that embracing the various aspects of REST might allow us to build the “next generation” of process management systems. In your rants recent posts you seem to be taking the stand that there’s much of value in the WS-* world, and much less of value in what the RESTafarians are doing. I suspect, with all due respect, that you may be wrong. For my part, I sure wish you would bring the horsepower of the mighty Dubray intellect to bear on some of the things I’m thinking about, rather than dismiss them out of hand.
Soundtrack for this post: Bob Marley and the Wailers, “I Shot The Sheriff”
