IBM and BEA released a whitepaper on an extension to BPEL called "BPELJ" that mixes aspects of Java with BPEL. Oddly enough, I talked at the local Java Users Group on a related topic back on March 16th, although I talked about it in the context of messaging/integration patterns and calling out to external Java "services" as opposed to actually embedding Java into BPEL. (See 2004-03-14#FiveSight_at_March_16_CJUG; I will post the slides sometime soon.) Of course, not all ideas are good ideas; my canonical choice of a bad idea is a glass bottom boat where you can open the window...The whitepaper kicks-off with a reference (without attribution) to the DeRemer-Kron classic (see [1] below) on "programming-in-the-large", which is odd, considering what I recall to be the intent of the piece:[S]tructuring a large collection of modules to form a 'system' is an essentially distinct and different intellectual activity from that of constructing the individual modules.My first thought about BPELJ was that it looked like it was invented by someone who thinks it's a good idea to put the business logic directly in JSP pages. (It also reminds me of embedding assembler instructions in C code.)On one level, there is nothing deeply new or bad about BPELJ. BPELJ adds a Java "snippet" activity and some syntactic sugar for intermixing Java types and XML types in variables. In practical terms, code blocks can be compiled and turned into methods that accept some kind of context object, and type manipulation has already been contemplated in other contexts, e.g., like XML binding (JAXB) and XPath-style JavaBean accessors (JXPath). (For that matter, BPEL already contemplates support for different expression languages to manipulate process variables; use of Java is then a question of the internal representation.)So what's the difference between an integrated approach like BPELJ and simply deploying some session beans or POJOs with a direct invocation protocol used to access methods as services? Encapsulation and abstraction come to mind, and that's a big deal. Think about the difference between having one date routine encapsulated as a service and having Calendar.newInstance() code peppered all over hundreds if not thousands of BPEL processes deployed around a large enterprise. In the same sense that a simple web application can be coded-up in a jiffy without thinking about architecture, simple business process problems will not benefit from the level of abstraction that BPEL (and the accompanying philosophy) offers. Put another way, BPEL and related technologies can be great tools for quickly assembling one-off integration solutions, but thinking about process-oriented applications and systems requires a bigger picture view and approach.Also, one of the driving assumptions of BPELJ seems to be that people will actually write BPEL, but I'll have to write about the separately.[1] Frank DeRemer, Hans H. Kron. Programming-in-the-Large Versus Programming-in-the-Small. IEEE Transactions on Software Engineering, Vol. SE-2, No. 2, June 1976.
Previous Topic
