BPEL for Web Services co-author Matjaz Juric discusses the role of BPEL and its relationship with Java in TSS' latest article. The article introduces BPEL and concentrates on the idea of extending BPEL, to be able to compose resources other than web services (EJBs, JMS, etc), and the possibility to mix BPEL and Java code.

BPEL is an important language for the process-oriented approach to SOA. Because BPEL has been designed specifically for definition of business processes it provides good support for various specifics of business processes such as support for long running transactions, compensation, event management, correlation, etc. BPEL is well suited for use with the J2EE platform and many BPEL servers build on top of J2EE. With ideas of combing BPEL and Java (BPELJ), and WSIF, the usability of BPEL is even increasing. We should also look at the emerging JBI (Java Business Integration) specification aka JSR 208 which will give business integration and BPEL an even better documented position in the Java platform.

Read BPEL and Java

"From the perspective of composing web services to execute business processes, orchestration is the more flexible approach compared to choreography"

I don't doubt that the author is correct but it somewhat misses the point that WS-CDL (Choreography) has never attempted to do what BPEL does. It is not about recursive composition but about peer to peer contractual behavior based on a global model. This something that BPEL doesn't do.

"know exactly who is responsible for the execution of the whole business process"

So why is this a good thing. It is server centric with a single point of failure regardless of how you decide to federate. I do not doubt that it has it's place but the statement suggest that it is the be all and end all which it is not. Orchestration may well have a place within the firewall where you can assert control. But you cannot do this across firewall between different domains of control. A good example of this is financial services in which many participants are involved in a transaction. Choreography has a good track record of working with vertical standards such as fpML, FIX and TWIST. They all tried BPEL to encode the peer to peer behavior and all failed. This is why they are working with WS-CDL. If the participaticpating services know what they should do (aka WS-CDL) then do we care if it is "orchestrated". Personally, three companies later, I don't care. I care about results for normal behavior and I care about what happens at the extremes. Server centricity does not one any favours because it moves us back to the days of "the solution is a database" when we all know it isn't.

As to the other bullet points:

"# We can incorporate web services, even those that are not aware that they are a part of a business process.
# We can also provide alternative scenarios when faults occur."

WS-CDL can do all of this so it is hardly a unique selling point. What BPEL does that WS-CDL does not is recursive web service composition. Which is a valuable thing to do.

The author references WSCI as a standard. It is not a standard. It was and is and remains a member submission. Much like BPEL. A standard is something very different and is a result of a hard slog and compromise from the contributors and those involved in the setting of standards. So don't for one minute think that BPEL or WSCI are standards. They are not. From a WS-CDL perspective WSCI is just a footnote in the history of WS-CDL (oddly enough so is BPEL).

As to "support from the industry" the author should perhaps have research further. It is true to say that IBM and Microsoft are not part of the working group. But I can certainly tell TheServerSide that on the shop floor (nearest to customers) both have received attention which may/is/will lead to revenue opportunities.

The author also states that BPEL allows us to:

"Abstract business protocols"

Alas this is just not true. This is why (as I have previously said) vertical standards have come to WS-CDL having tried to use BPEL and failed. Also the Oasis TC is unlikely to support this anyway.

Given the author is a PhD it is a shame that they have not done the necessary research into the space. They would note, from an academic perspective, that WS-CDL has active invited experts such as Prof Robin Milner, Dr Kohei Honda and Dr Nobuko Yoshida and has had contributors such as Lucian Wischik (now at Microsoft).

For those not in the know WS-CDL is complementary to BPEL. Indeed many requirements have come from users of BPEL who need some way of describing a peer to peer contract of behavior so that suitable BPEL processes maybe generated. An interesting thought to anyone wanting to use BPEL and also wanting a solid formal foundation to how services will interact.

Cheers

Steve Ross-Talbot
CEO Pi4 Technologies Ltd
Chair W3C Web Services
Co-Chair W3C Web Services Choreography
www.pi4tech.com
https://www.w3.org/TR/2004/WD-ws-cdl-10-20041217/

Steve,
    An excellent reply, thank you for this enlightening insight into CDL and BPEL's position within CDL.

I think the most exciting part of CDL is its position within B2B world, an area where BPEL is virtually useless outside of the firewall. FpML, Swapswire etc. stand to gain terrifically from CDL support, with perhaps, as I think you suggest, BPEL behind the endpoints.

Most importantly CDL does not depend on WS, this is probably the single biggest advantage, we can actually use real-world endpoints without having to WebServicise them first.

While I'm sure BPEL will play an important role in BPM it's CDL that is going to glue it all together at the enterprise level.

-John-

Dear Steve,

The objective of my article has not been a comparison of BPEL and WS-CDL and I don’t want to start a discussion on this topic. The fact however is that BPEL has gained support from major vendors, including Oracle, IBM, and Microsoft, and from open source community.

My answer is related to the following:
>> The author also states that BPEL allows us to:
>> "Abstract business protocols"
>> Alas this is just not true. This is why (as I have previously said) vertical standards have
>> come to WS-CDL having tried to use BPEL and failed. Also the Oasis TC is unlikely to
>> support this anyway.

The BPEL4WS 1.1 specification on page 2 (Abstract, Paragraph 2) defines the executable and abstract business processes (also called business protocols):

"Business processes can be described in two ways. Executable business processes model actual behavior of a participant in a business interaction. Business protocols, in contrast, use process descriptions that specify the mutually visible message exchange behavior of each of the parties involved in the protocol, without revealing their internal behavior. The process descriptions for business protocols are called abstract processes. BPEL4WS is meant to be used to model the behavior of both executable and abstract processes."

So I cannot agree with your opinion that what I’ve written in my article "Alas this is just not true".

Cheers,

Matjaz

In the context of BPEL + Java, one of the ways you could do embed Java is using BPEL extensions. These extensions can allow to extend the BPEL language with additional constructs from other namespaces.

Once you have the extension, you can call custom acitivity that can execute a piece of Java Code.

Oracle BPEL Process Manager provides custom activity called <bplex:exec>.
You can the usage in this sample.
http://www.oracle.com/technology/products/ias/bpel/pdf/orabpel-Training-Segment10.pdf


raghu

It would be interesting to extend this article to how BPEL fits into the model view controler paradigm that most Java developers use to build applications. One of the big inhibitors of "workflow" technology in the past is that process centric development was very proprietary and intrusive and forced the developers to think the applications upside down with process logic being the center of the universe.

Kudos on the good article and very good book.

Edwin

It would be interesting to extend this article to how BPEL fits into the model view controler paradigm that most Java developers use to build applications. One of the big inhibitors of "workflow" technology in the past is that process centric development was very proprietary and intrusive and forced the developers to think the applications upside down with process logic being the center of the universe.

Edwin,

You sound like you already have some thoughts on the matter. Would you care to elaborate?

Joost

What I like about this article is that it puts BPEL in the right perspective : on top of web-services as an integration technology.

BPEL has been marketed wrongly as a solution for workflow and Business Process Management (BPM). While BPEL has some features in common with workflow and BPM, it is simply not suited for those purposes because it is hard coupled with web services. Workflow and BPM features should be offered in plain POJO java. And web services transport should be optional on top for integration purposes. That is our approach for simplified development of workflow and BPM.

I have written an article that, together with this BPEL article, give good idea about workflow, BPM and orchestration. My article describes what is missing in Java to support features of workflow and BPM : Graph Oriented Programming.

regards,
Tom Baeyens
JBoss jBPM

While BPEL has some features in common with workflow and BPM, it is simply not suited for those purposes because it is hard coupled with web services. Workflow and BPM features should be offered in plain POJO java. And web services transport should be optional on top for integration purposes.

but what is a web service?

why do you assume that a web service is not a POJO/EJB/etc and that some WS specific transport is used instead of a direct java call or JMS or whatever?

take a look at WSIF for example

Workflow and BPM features should be offered in plain POJO java

this sounds like a limitation to me

Workflow and BPM features should be offered in plain POJO java. And web services transport should be optional on top for integration purposes. That is our approach for simplified development of workflow and BPM.

Sure, let's eshew the standards in lieu of platform tie-in since we work on a particular platform or language or vendor. Scary.

While I agree that BPEL is a great foundation for an integration solution, I think you'll find that as market continues to evolve BPEL solutions will allow the integration of almost any technology component, including Java objects: WSDL can be used as a contract language for almost anything. The Oracle BPEL product is a great example.

Greg

I think their parent company, Momentum Software -- a consulting concern, apparently stopped development due to the level of effort and expense required to finish the product. This would seem to be reinforced by their lack of publicity during the past 14 months (their last release was February 16, 2004).

I am a bit biased, as I work for SeeBeyond, but in the list of J2EE-based BPEL servers the author forgot to mention SeeBeyond's eInsight Business Process Manager:

http://www.seebeyond.com/software/einsight.asp

Regards,
Maurizio

I am a bit biased, as I work for SeeBeyond, but in the list of J2EE-based BPEL servers the author forgot to mention SeeBeyond's eInsight Business Process Manager

I think you'll find there's a whole bunch missing, Fuego on the BPM side and and PolarLake on the more EAI side for example.

BPEL is pretty commodity now so it's difficult to provide a comprehensive list, it's interesting to see a few of the more advanced ones are starting to work on CDL finally.

-John-

I am a bit biased, as I work for SeeBeyond, but in the list of J2EE-based BPEL servers the author forgot to mention SeeBeyond's eInsight Business Process Manager

I think you'll find there's a whole bunch missing, Fuego on the BPM side and and PolarLake on the more EAI side for example.BPEL is pretty commodity now so it's difficult to provide a comprehensive list, it's interesting to see a few of the more advanced ones are starting to work on CDL finally.-John-

Do you know of any comprehensive lists?

Better still, any feature comparisons?




PJ Murray

CodeFutures Software

Java Code Generation for Data Persistence

wget http://www.manageability.org/blog/stuff/workflow_in_java/view | grep BPEL

Do you know of any comprehensive lists? Better still, any feature comparisons?

Sorry no but this might give you some ideas... http://www.bpmi.org/members.htm, not everyone on the list is a vendor but you should be able to sort the buyers from the sellers, most of the obvious names seem to be there. This will also explain how BPMI relates to BPEL --> http://www.bpmi.org/aboutus.htm

Just an FYI, BPMI was started by Intelio who also set up ExoLab who gave us OpenEJB, OpenJMS and Castor, just thought you might like to know.

-John-

Its really more miracle to use BPMN notations supported by most of the Process Manager/BPM tools. Definitely use those BPM Engines/Studios like FUEGO/Integrator/Process Choreographer to model the business processes. Its easy to use sub-processes, handle faults and deal with compensation paths.

Its also very easy to integrate BPM engines with J2EE/.net technologies. They can be designed and deployed using other J2EE components like EJB2.1 message driven beans, session beans, web services, entity beans.

Have fun with those tools since more BPM facilities available on weblogic/websphere servers now in march 2006.

Good Luck
Maneesh Innani
Senior Technical Architect

Dear all,

to be clear on this BPEL4WS1.1 is *not* a standard. It *is* a submission to Oasis that is driving what will become a standard. So while the author is correct in his assertions about BPEL4WS1.1 he is not correct about the evolving standard (WS-BPEL). Why is this so? Is is ths case that with respect to business protocols the features have been made obsolete, since the WG decided to remove the
text that talks about Business Protocols from the real spec.

Also, even though many vendors provide support for BPEL, nobody has support for AbsBPEL (which will optional for WS-BPEL 2.0) as of now.

And even if there would be support, WS-CDL is going to be used complementary to BPEL:

                                                            WS-CDL for BusinessProtocols
                                                                |
  ExecBPEL <--FillInDetaliedCode -- AbsBPEL <--generateEndpoints--> AbsBPEL --
                                                                                                           FillInDetaliedCode --> ExecBPEL



Below is a pointer to an article Oracle wrote in WSJ last Nov (hot read ~4500hits), that puts
all things in perspective, since we also provide a great BPEL engine:

http://www.findarticles.com/p/articles/mi_m0MLV/is_11_4/ai_n7071401/pg_1


Cheers

Steve T

I really liked the article, as someone who know nothing about what the heck is BPEL, I think I now had a nice view of this technology.

I believe this key beauty in this article, is that it managed to be very very introductory, without being too naiive or too superficial.

The author, briefly describe the problem, then moved to describing the solution, then elaborated on the tools to implement the solution.

How can this article be better, well, maybe more talk about the problem, and how other technologies tried to solve it, and why he think BPEL is a better solution, technically and even logically.

My thank to the author