VOSibilities

Last week, Active Endpoints’ Michael Rowley participated in the quarterly face-to-face meeting of the OASIS Technical Committee working on the BPEL4People and WS-Human Task specifications. In this very engaging podcast, Rowley describes the inner workings of TC’s (something you usually don’t hear much about), describes the work the TC has recently accomplished and articulates the grand vision for business process management (BPM) and workflow that the committee has been working  on.

If you’ve been wondering about the state of standards-based BPM and workflow systems or, frankly, if you think BPEL and BPEL4People have dropped out of sight, I strongly encourage you to listen to this podcast. You’ll hear how some the of most important thought-leaders in the IT world, including IBM, SAP, Oracle, Microsoft, TIBCO and, of course, Active Endpoints, are working towards a BPM world in which standardized systems make it possible to implement business processes in ways we haven’t been able to reach as yet.

We hope you enjoy this look at BPM today and in the future.

 

 VOSibilities podcast #27 An Update on the BPEL4People Standard [24:53m]: Play Now | Play in Popup | Download (373)

I am pleased to post the second episode in our continuing series of product vignettes — short video recordings of important features in ActiveVOS.

This time, Mike Moniz demonstrates how to use ActiveVOS to customize the work list manager (he calls it an “inbox”) that users access in order to process tasks assigned to them by the ActiveVOS BPM system.

Make no mistake: what you are looking at is a fully compliant BPEL4People and the WS-Human Task client which can be easily modified to meet your UI requirements. By leveraging the inter-related BPEL4People and WS-HT standards, ActiveVOS is able to deftly include human activities in complex automated workflows.

Frequent readers of our blog know that there’s a healthy debate (here and here) going on about whether or not BPEL is appropriate for SOA-based BPM. (BPMN is often proposed as the “alternative.”) We think that debate misses the point: computers require precise definition of all the runtime details to run applications. Ergo, an execution-oriented language like BPEL is required.

We think the real question boils down to: does BPEL have what it takes to both run “on the metal” and permit the inclusion of human tasks into running processes? When you see what you can do with BPEL4People and WS-Human Task in ActiveVOS 6, the answer is clearly, “Yes.”

 

 VOSibilities podcast #25: Customizing a BPEL4People and WS-Human Task client worklist manager: Play Now | Play in Popup | Download (1589)
 VOSibilities podcast #25: Customizing a BPEL4People and WS-Human Task client worklist manager: Download (293)

Last week, David Linthicum’s SOA podcast continued a theme he’s been on lately, a discussion of BPEL’s “fallings” [sic]. I think he meant failings…but in any event, he mentions several times in the podcast that a post he’d previously written on this topic had generated quite a discussion (it did) and feedback from unnamed “BPEL vendors” (that’d be us; I can’t imagine why he didn’t name us. (-: )

Anyway, today after I heard the podcast, I asked Chris Keller, our founder and vp of development and one of the most knowledgeable people on BPEL in the world for his feedback. Chris has not only written the BPEL engine that’s at the core of our visual orchestration system (a VOS is a whole lot more than a BPEL engine), he’s active on the OASIS committees that are furthering the standards.

Chris gave me a lot of food for thought, and being in a playful mood, I thought it might be fun to that feedback into a Q&A. Sorta like a game show, with Mr. Linthicum as the contestant. The prize, for correct answers, is a free ActiveVOS license. Let’s see how Mr. Linthicum does…

Question 1: In the podcast, David says that a major problem with BPEL is that it’s synchronous.
Did David get it right? Click the arrow to find out… Then click here to read the correct answer
Sorry, no. Chris points out that the exact opposite is true. BPEL is asynchronous by definition.

Question 2: David says BPEL has a few programmer-level issues including limitations around request/reply exchanges in a heterogeneous architecture.
Did David get it right? Click the arrow to find out…Then click here to read the correct answer
Whooppss…wrong again. Chris points out that this isn’t a problem with BPEL as much as it is a problem with vendor support for standards that make request-response asynchronous, like reliable messaging. It’s one prime reasons for the WS-TF standards effort.

Question 3: David says BPEL has issues with failure recovery, exception handling and multi-programming model support.
Did David get it right? Click the arrow to find out…Then click here to read the correct answer
So very sorry. Chris points that exception handling is covered by the specifications and that recovery isn’t something that belongs in the specification at all (This is a major differentiator among vendors, and something ActiveVOS does brilliantly — ed.). As for multi-programming model support, we aren’t quite sure what David means, but if he’s talking about multi-tasking, the spec has that covered, too.

Question 4: David says BPEL is not very good at adding a human as part of the process and as SOA moves forward, he’s finding that composites and workflows are more applicable than simple service binding and extending.
Did David get it right? Click the arrow to find out…Then click here to read the correct answer
Close…but no cigar. Chris points WS-HT and BPEL4People have been added to the specification for precisely this purpose. While David’s criticism was once correct, it’s not applicable today.

We hope that you’ve enjoyed our little episode of The BPEL Game Show. And sorry, David, but you didn’t win our prize. However, anytime you’d like to be brought up-to-date on why BPEL is at the heart of SOA development, we’re happy to update you so you can win the next time.