In the Service of Cooperation

July 8, 2003

Kendall Grant Clark

In a previous XML-Deviant column, "Is There a Consensus Web Services Stack?", I surveyed the web services territory, particularly those of its regions which are called "high level." When considering what the top of the web services stack might eventually look like, it becomes clear that the higher one goes, the closer one gets to "the user" or "the business process" and the further away one gets from the network and the machine.

But the idealized web services stack is not only describable in terms of spatializing metaphors (viz., height and depth) but also in terms of stratifying ones (viz., layers and levels). Or, rather, one needs both sorts of metaphors to do the description job adequately. Interestingly, we are entering a period during which the various layers of the top of the web services stack are starting to be shuffled into place. I date the inauguration of this period from the point at which BPEL (or, if you prefer, BPEL4WS) was moved into an OASIS TC for formal standardization. My choice of inaugural moments is admittedly biased against technical details in favor of institutional dynamics; but there is a sense in which clearing away the political and institutional obstacles on the road to interoperability is as important as building it in the first place.

There have been and still are several interesting institutional actors at play in this drama. First, would IBM-BEA-Microsoft submit BPEL to formal standardization--and, thus, presumably waive royalty and other IP claims--at all? Second, to which standards body would IBM-BEA-Microsoft submit BPEL, OASIS, or W3C? (It is arguable that OASIS just is the right choice, given its range of existing standardization efforts as compared to the W3C's.) Third, given that BPEL went to OASIS, rather than to the W3C, where does that leave the W3C's WS-Choreography Working Group and the Web Services Choreography Interface, or WSCI? Fourth, what happens to DAML-S--which I described at some length in the context of semantic web services in "The True Meaning of Service"--and DAML's Semantic Web Services Initiative (SWSI)?

The comment most frequently made in the wake of OASIS taking BPEL into its fold was that BPEL had already won the battle in this period of high-level web services shakeout. But that comment is as wrong as it is glib. And it's wrong for a variety of reasons: first, it's not clear that there has to be a single winner, since this part of the web services stack is likely to be as layered and variegated as every other part of the stack; second, it's not clear that the existing efforts are competing directly.

If one assumes, as most commentators have so far, that the market is unified and cohesive and that the dominant factor is institutional backing, then BPEL seems like a clear, easy winner. BPEL is a fairly mature specification, with at least two nontrivial implementations (IBM's BPWS4J and Collaxa's Orchestration Server), and its main backers (the IBM-BEA-Microsoft troika) jointly own a market segment not easily distinguished from the entire market itself. In other, blunter words: in the area of "enterprise computing and application integration," what IBM-BEA-Microsoft want, they very often get. Sun Microsystems is the only significant outlier here, and Sun has shot itself in the foot more often than those of any of its competitors.

Given these narrow assumptions, then, the obvious prediction is that the W3C's choreography effort fades away, DAML-S hangs on in some form or other, but without a significant user base, and BPEL reigns supreme. But no one likes to pay top dollar for a ringside seat at the biggest fight of the year just to see a first-round knockout. What does the future look like if we broaden our assumptions a bit?

One broadening assumption is that the top of the web services stack is likely to be a variegated space. Under this assumption, it becomes very unlikely that BPEL could "win" in such a way as to crowd out every other technology. It is unlikely that BPEL could crowd out all others because it is unlikely that any single technology could adequately fill every niche of such a variegated space.

There are, in fact, grounds for thinking this assumption is true. First, as I mentioned at the outset, the higher we go up the idealized web services stack, the closer we get to the user and the user's "business process" and the further we get from the machine. That is, the closer we get to people who don't know a socket from a schema from a semaphore. So, in addition to coordinating the interactions of various kinds of web services, the top of the idealized web services stack will likely need technologies for helping high-level users manage, describe, define, and modify these processes. Second, BPEL, the Business Process Execution Language, despite its relative maturity, is not ideally suited for every (relevant) task. The BPEL specification claims that it can be used to "define a business protocol role, using the notion of abstract process", and that it can be used to "define an executable business process." BPEL's semantics is imperative in nature. It has constructs modeled fairly closely to imperative programming languages, including conditionals, loops, and switch statements. I remain unconvinced that BPEL can span the distance between people who understand and can use flow-control constructs and people who arrange business processes. They are typically neither the same people, nor do they have overlapping skill sets.

These (potential) flaws cut deeper when one pays careful attention to some of the claims of the BPEL specification. BPEL should allow "each participant" in a business process to "understand and plan for conformance to the business protocol without engaging in the process of human agreement that adds so much to the difficulty of establishing cross-enterprise automated business processes today" (emphasis added). That's an interesting claim, especially for a technology that is meant to be situated very near, indeed, to the user and to the user's business processes. I am generally skeptical of claims on the part of vendors, and on behalf of technologies of those vendors, which are meant to remove, or decrease the need for, "the process of human agreement." What usually happens in these cases is that the need for human agreement shifts, either from one professionalized group to another (from "programmers" to "MBAs," for example), or from one time to another.

This claim is especially interesting, however, given that another player in this space, that is, DAML-S and SWSI, is explicitly aimed at reasoning about and over declarative descriptions of services, service interfaces, and multi-service compositions--all out of a very rich scientific research tradition of agents, ontologies, knowledge representation systems, and the like. If any of these efforts is likely to shift some of the reasoning burden from people onto machines, the smart money is on the effort that has a proven track record of doing that sort of thing. The declarative semantics of the DAML-S process model, for example, have been designed to work with existing planners and reasoners. BPEL's imperative semantics have mostly been designed to work with Java and C# web service engines.

The BPEL specification seems to grant these claims implicitly:

BPEL4WS takes it as a general principle that compliant implementations MAY choose to perform static analysis to detect and reject process definitions that may have undefined semantics. Such analysis is necessarily pessimistic and therefore might in some cases prevent the use of processes that would not, in fact, create situations with undefined semantics, either in specific uses or in any use.

In other words, they just don't know, and that while not knowing isn't necessarily the case in general, it's necessarily the case given the imperative semantics of BPEL. The advocates of DAML-S, and the SWSL types, make a different set of claims about the semantics of their process and service ontologies--claims that are more likely to shift reasoning burdens from people to machines.

What does that leave for WS-Choreography? In principle I support WS-Choreography, even without understanding exactly what it is aiming at, if only because it is likely to be very RDF and REST friendly, and those are, all other things being equal, among my preferred ways of describing information and building information interfaces. (In particular, I remain committed to the slogan: anything SOAP can do REST can do, too. And the absence of RDF from the BPEL specification is rather conspicuous, since RDF just is the way to say things about web resources.)

Also in XML-Deviant

The More Things Change

Agile XML


Apple Watch

Life After Ajax?

WS-Choreography seems more likely to focus on the global perspective, that is, on describing the entire interface of a multi-service process. It is unlikely to compete directly with BPEL by describing an execution language, focusing rather on an explicit and formal means of describing the entire set of interacting services. In other words, think: "XML descriptions of really big, complex, shared state machines, backed by formal pi and event calculi." While the outcome isn't set in stone yet, there does seem to be some good will on both sides--OASIS and W3C--for seeing BPEL and WS-Choreography mutually flourish. At one of the Choreography WG meetings in June, 2003, BPEL representatives were scheduled to talk about ways in which the two groups might cooperate.

I can see BPEL "winning" in the sense that it becomes the low-level way to specify the process and workflow logic of business processes. And I can see it winning in the sense that the SWSL and DAML-S folks, for example, use BPEL as a compilation target. BPEL and its advocates want it to be the stuff, together with a pile of WSDL files, that you feed to your web services engine in order to get Java classes and C# services. That's an important part of the top of the web services stack, but it's not the only part. And it's arguably not the highest part.