A second look at BPELJ
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:
- Collaxa's Edwin Khodabakchian's opinions
- Phil Wainewright's blog
- Mike Lehmann's blog
- Howard Smith's article
For an alternative approach to BPELJ, check out the Web Services Invocation Framework.
"WSIF fixes these problems by letting you use WSDL as a normalized description of disparate software, and allows you to access this software in a manner that is independent of protocol or location. So whether it is SOAP, an EJB, JMS (or potentially .NET and other software frameworks), you have an API centered around WSDL which you use to access the functionality."