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
-
The definitive BPEL and Java article (19 messages)
- Posted by: Floyd Marinescu
- Posted on: April 13 2005 10:41 EDT
Threaded Messages (19)
- WS-CDl and BPEL by Stephen Ross-Talbot on April 13 2005 15:42 EDT
- WS-CDl and BPEL by John Davies on April 14 2005 05:58 EDT
- Re: WS-CDl and BPEL by Matjaz Juric on April 14 2005 07:23 EDT
- BPEL extensions by Raghu Kodali on April 13 2005 18:40 EDT
- Interesting Article by Edwin Khodabakchian on April 14 2005 00:28 EDT
- upside down... by joost de vries on April 14 2005 15:10 EDT
- The right perspective by Tom Baeyens on April 14 2005 04:03 EDT
- The right perspective by The Ugly One With The Jewels on April 14 2005 06:22 EDT
- The Wrong Perspective... by Paul O'Connor on April 14 2005 09:48 EDT
- The right perspective? by Greg Pavlik on April 14 2005 10:31 EDT
- FWIW, OpenStorm may not be a viable option by Steve Hoffman on April 14 2005 15:34 EDT
- SeeBeyond's eInsight Business Process Manager by Maurizio Turatti on April 15 2005 05:08 EDT
- BPEL engines by John Davies on April 15 2005 10:49 EDT
-
BPEL engines by PJ Murray on April 17 2005 11:53 EDT
- BPEL engines by John Mettraux on April 17 2005 06:31 EDT
- BPEL engines by John Davies on April 17 2005 10:06 EDT
- Wonders with BPEL4WS and BPMN and BPMs : BPM Talk Maneesh Innani by Maneesh Innani on March 08 2006 08:29 EST
-
BPEL engines by PJ Murray on April 17 2005 11:53 EDT
- BPEL engines by John Davies on April 15 2005 10:49 EDT
- BPEL and CDL once again by Steve Ross-Talbot on April 15 2005 11:50 EDT
- I liked the article by Ali Elshishini on April 17 2005 02:57 EDT
-
WS-CDl and BPEL[ Go to top ]
- Posted by: Stephen Ross-Talbot
- Posted on: April 13 2005 15:42 EDT
- in response to Floyd Marinescu
"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/ -
WS-CDl and BPEL[ Go to top ]
- Posted by: John Davies
- Posted on: April 14 2005 05:58 EDT
- in response to Stephen Ross-Talbot
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- -
Re: WS-CDl and BPEL[ Go to top ]
- Posted by: Matjaz Juric
- Posted on: April 14 2005 07:23 EDT
- in response to Stephen Ross-Talbot
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 -
BPEL extensions[ Go to top ]
- Posted by: Raghu Kodali
- Posted on: April 13 2005 18:40 EDT
- in response to Floyd Marinescu
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 -
Interesting Article[ Go to top ]
- Posted by: Edwin Khodabakchian
- Posted on: April 14 2005 00:28 EDT
- in response to Floyd Marinescu
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 -
upside down...[ Go to top ]
- Posted by: joost de vries
- Posted on: April 14 2005 15:10 EDT
- in response to Edwin Khodabakchian
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 -
The right perspective[ Go to top ]
- Posted by: Tom Baeyens
- Posted on: April 14 2005 04:03 EDT
- in response to Floyd Marinescu
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 -
The right perspective[ Go to top ]
- Posted by: The Ugly One With The Jewels
- Posted on: April 14 2005 06:22 EDT
- in response to Tom Baeyens
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 exampleWorkflow and BPM features should be offered in plain POJO java
this sounds like a limitation to me -
The Wrong Perspective...[ Go to top ]
- Posted by: Paul O'Connor
- Posted on: April 14 2005 09:48 EDT
- in response to Tom Baeyens
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. -
The right perspective?[ Go to top ]
- Posted by: Greg Pavlik
- Posted on: April 14 2005 10:31 EDT
- in response to Tom Baeyens
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 -
FWIW, OpenStorm may not be a viable option[ Go to top ]
- Posted by: Steve Hoffman
- Posted on: April 14 2005 15:34 EDT
- in response to Floyd Marinescu
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). -
SeeBeyond's eInsight Business Process Manager[ Go to top ]
- Posted by: Maurizio Turatti
- Posted on: April 15 2005 05:08 EDT
- in response to Floyd Marinescu
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 -
BPEL engines[ Go to top ]
- Posted by: John Davies
- Posted on: April 15 2005 10:49 EDT
- in response to Maurizio Turatti
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- -
BPEL engines[ Go to top ]
- Posted by: PJ Murray
- Posted on: April 17 2005 11:53 EDT
- in response to John Davies
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 -
BPEL engines[ Go to top ]
- Posted by: John Mettraux
- Posted on: April 17 2005 18:31 EDT
- in response to PJ Murray
wget http://www.manageability.org/blog/stuff/workflow_in_java/view | grep BPEL -
BPEL engines[ Go to top ]
- Posted by: John Davies
- Posted on: April 17 2005 22:06 EDT
- in response to PJ Murray
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- -
Wonders with BPEL4WS and BPMN and BPMs : BPM Talk Maneesh Innani[ Go to top ]
- Posted by: Maneesh Innani
- Posted on: March 08 2006 20:29 EST
- in response to PJ Murray
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 -
BPEL and CDL once again[ Go to top ]
- Posted by: Steve Ross-Talbot
- Posted on: April 15 2005 11:50 EDT
- in response to Floyd Marinescu
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 liked the article[ Go to top ]
- Posted by: Ali Elshishini
- Posted on: April 17 2005 02:57 EDT
- in response to Floyd Marinescu
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