John Reynolds's Blog: J2EE Archives

I have had time to re-read the joint IBM and BEA whitepaper on BPELJ. My initial reaction was "Yuck". Intermingling Java snippets with XML invoked a gag reflex, and it was hard for me to keep reading. I missed the relationship between JSR 207 and BPELJ.

I cannot include examples from the whitepaper in this blog, the copyright explicitly states that no part of the document may be reproduced or transmitted without the explicit consent of BEA and IBM. Forgive me, but I will have to paraphrase. I encourage you to read the whitepaper to get a clearer idea of what the authors have proposed: "BPELJ: BPEL for Java technology"

The authors of the BPELJ whitepaper lost me with their opening statements:

BPELJ enables Java and BPEL to cooperate by embedding snippets of Java code into BPEL documents.

This statement is almost as attractive to me as the idea of embedding Java snippets into HTML pages. Paul Brown's blog on BPELJ mirrors my opinions.

The following statement is more compelling: BPELJ will make it possible to use BPEL to orchestrate long-running interactions with Web Services and J2EE components. This is a good thing.

BPEL uses "partner links" to enable web services to collaborate within a larger process. BPELJ adds "partner links" that use Java interfaces in addition to WSDL port types. A simple example of this would be a process that incorporates Web Services and Session Beans. With generic BPEL, each Session Bean must be wrapped in a Web Service to participate in a process. With BPELJ, any Session Bean can participate in a process without a wrapper. In addtion, serialized Java objects can be passed between the Java services rather then limiting all messages to XML documents.

This is a very pragmatic approach. BPELJ processes give up language neutrality to make it easier to use legacy Java components. BPELJ processes also promise to execute more quickly (assuming that the marshalling Java objects is faster then parsing XML payloads).

I have a philosphical problem with including Java snippets in BPELJ, but I understand the intent.

The justification for Java snippets is the plan to use BPELJ as the notation for JSR-207 Java class annotations. Annotations will be used to define BPELJ fragments for specific classes (much like XDoclet tags for EJBs). With the proper BPELJ annotation, any POJO class can be transformed into a process step... No need for a Session Bean wrapper, just annotate the POJO and it can be deployed into a BPELJ "container" (much like EJBs and their containers). I have to admit that the concept is pretty cool.

BEA is firmly commited to BPELJ and will be supporting it in the next major release of WebLogic Workshop. BPELJ was designed specifically with BEA's JPD and JSR 207 in mind.

Will the benefits of being able to use Java specific interfaces as process steps outweigh the benefits of language-neutral services? Processes are comprised of steps that implement business logic. In the environment where I work, the flexibility to reuse our business logic across heterogenous systems is pretty valuable. I may implement "Java only" interfaces for some minor services, but I imagine that I will generally wrap our key services in XML interfaces for wider reuse.

On the minus side, I am wary of BPELJ because it mingles XML and Java, and because I miss the language-neutral flexibility. On the plus side, I understand what the proponents are trying to accomplish, and I support their goals. Hopefully I will learn more at the BEA eWorld session on BPELJ on May 27th (in San Francisco).

There are some good concepts here. Let's hope the JCP process will iron out the kinks and deliver something we will all be happy to use.

The authors of the IBM/BEA whitepaper state that BPEL does not try to be a general-purpose programming language. They assume that BPEL should be combined with other languages to implement business functions. I can agree with that statement, but I think they have erred in their interpretation of what "combined" means. I believe that the BPEL authors assumed that business functions would be embedded within the Web Services that BPEL orchestrates. The implementation of these functions would be hidden, making it irrelevant what language was used. In contrast, the BPELJ authors feel that languages should be used to extend BPEL itself, to make the combination a general-purpose language. This seems like a very problematic position.

Extending BPEL to allow the control of Services that can use language specific interfaces is a good concept. Embedding language specific logic within a BPEL document goes much further, and is an idea that should be widely debated and discussed by the Java community.

Other blogs on BPELJ:

Is Java popular in spite of its standards?

Posted by johnreynolds on April 19, 2004 at 02:30 PM | Permalink | Comments (9)

Mention JSPs positively in a blog and you will undoubtably get flamed. Encourage colleagues to use Entity Beans and you may never be taken seriously again. JDO was crippled for many by the lack of a standard for O/R mapping. EJBQL, and JDOQL lacked the functionality that many legacy RDBMS schemas demanded.

These are just a few of the "standard" features of Java that are reviled by ardent Java supporters... but for some reason developers stay loyal.

Are we loyal because we fear domination by Microsoft? Judging by the paranoid reactions of many to the Microsoft-Sun cease fire there's probably some truth to that conjecture.

Are we loyal because we ignore "standards"? Ignore might too mild a term, armed resistance might be more accurate. From the very beginning we've engaged in civil disobediance, rolling our own solutions and banding together to support projects that openly challenge the wisdom of the "standards". For every Jakarta project that implements a JCP standard, there's at least one that opposes the same standard.

So what should we make of all this?

I'm not sure myself, but I do think that the "major" players need to take notice and adjust their approaches. The user community does not respond to edicts from "on high", and doesn't care how much money has been spent to push a feature. In the egalitarian world where anyone can post an opinion the best laid plans of corporate marketeers aren't worth much. Bad solutions may linger, but they'll never prosper.

At this particular time, we're at a crossroads. The major players are either working on tools to hide the ugly guts (BEA's Weblogic Workshop's Controls), distract us with shiny new window dressings (Sun Creator Studio's Java Server Faces), or decouple the whole model (JBoss's AOP/Hibernate). All agree that creating a J2EE application is difficult and error prone, and all are scrambling for a fix.

Let's hope the result isn't another set of standards that developers love to hate.

Powered by
Movable Type 3.01D

java.net RSS Feeds