Small-minded orchestration

BEA and IBM this week published an ill-conceived mongrel specification called BPELJ. Edwin Khodabakchian has done a great job of listing the technical shortcomings in a posting to his blog. I'm simply appalled at the defective thinking that is being used to promote this mongrel spec.

Its authors attempt to justify their poisonous cocktail of BPEL and Java by introducing their whitepaper with some sanctimonious twaddle about BPEL being geared towards "programming in the large," while the role of languages like Java is to perform "programming in the small."

What this fine-sounding rhetoric attempts to obscure is that BPELJ is a fix for Java programmers who can't get to grips with developing proper, platform-neutral BPEL code, and instead allows them to build as much as possible of their orchestration logic using Java and J2EE.

I don't have a problem with people writing mongrel code if that's what they want (or are obliged by circumstances) to do. But if it's a dog, let's call it a dog, and let's put up some warning signs so people understand what they're taking on here.

What the authors really mean by the phrase "programming in the small" is software that's tightly coupled to a specific environment. This requires an approach that we can usefully describe as "small-minded programming," since it combines advanced skills inside its narrow focus with a complete lack of concern about what happens when attempting to link with other systems. It's a totally appropriate programming style to use when developing a high-peformance system that's dedicated to carrying out a specific function — in other words, the sort of system that very often sits behind an individual service interface within a loosely coupled orchestration.

It's no surprise that IBM and BEA would want to encourage and preserve this kind of approach among Java programmers, since they both market very popular Java development and deployment platforms, and it is clearly in their interests to encourage developers to increase their commitment to those platforms. But it strikes me as frankly irresponsible to dress it up as something that is respectable and acceptable to mix with the loosely coupled "programming in the large" of BPEL service orchestration, which is designed to co-ordinate processes irrespective of the underlying environments.

Effective use of BPEL requires an approach that is best described as "globally-minded programming." It means writing code that recognises the likelihood of encountering resources that have been created using unfamiliar notions, in unknown environments. One of the fundamental tenets of writing this kind of code is that you include external functions by calling services. Thus if, as the authors of BPELJ quite rightly state, there are computational functions that native BPEL doesn't do, the correct way to make those available to the orchestration are by providing them as services. I know this will seem an unnecessarily verbose and convoluted way of doing things to a small-minded programmer, but a globally-minded programmer understands why things have to be done that way when building an effective, adaptable orchestration.

BPELJ is a sleazy compromise that some projects will be tempted to adopt as a shortcut to reaching a working solution. That's fine, so long as those involved remember that at some point in the near future they'll have to go back and refactor their BPEL code to replace all the Java snippets with proper service calls. It ranks on a par with creating an enterprise application on the assumption that you can add internationalization later on. This specification should come with a health warning slapped on the side of it.

posted by Phil Wainewright 10:58 AM (GMT) | comments | link