VOSibilities

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.

I’ve been waiting to post this video podcast episode for a couple of weeks because I wanted to understand better all the vitriol and confusion in the marketplace between BPMN promoters on one side and BPEL proponents on the other

No less an authority than Bruce Silver noted over two years ago “…that the world of BPMS is divided into BPEL-lovers and BPEL-haters…” And as soon as I arrived at Active Endpoints last January, I could really feel the tension…an internecine battle among people who believe in the same outcome and passionately hold that standards-based technology is ultimately the correct path for customers.

But at the end of the day, there are two inescapable facts. First, BPMN is not executable. BPEL is. Together, they are a more potent, winning combination for customers than peanut butter and jelly. I just can’t understand why BPMN promoters skip over this fact.

This BPMN-bigot blind-spot this allows Lombardi, SAP and others to claim ”support” for standards and yet execute the processes on a proprietary execution engine. Isn’t that the maximum possible deprecation of BPMN? Isn’t it a violation of the original intent of BPMN to run it on proprietary engines, ensuring customers lose agility and increasing their costs? Why don’t BPMN people just loathe that idea?

We do, and that’s the second inescapable fact: no modelling-direct-to-execution technology has ever succeeded. That’s why BPEL4People is so important (and why we are on the BPEL4People Technical Committee and have implemented the current capabilities of BPEL4People in ActiveVOS 5).

It’s really pretty simple (and here comes a mixed metaphor I can’t believe I’m posting): dolphins don’t talk but old dogs can be taught new tricks. Dolphins may actually be smarter than humans, but they don’t speak in words. BPMN may be great, but it won’t run “on the metal.” OTOH, BPEL can be extended with human activities that are first-class participants in a BPEL orchestration. That ole dog sure can hunt.

Bottom line: BPEL and BPMN together is what kumbaya sounds like for BPMS. And today’s podcast episode is a proof point: watch how Mark Ford shows an orchestration that includes human workflow as a first-class participant and which is 100% standards-based. (And watch for us to shortly say a whole lot more about ActiveVOS and BPMS.)

 

 VOSibilities podcast #6: Mark Ford on BPEL4People [2:35m]: Play Now | Play in Popup | Download (339)

 

 VOSibilities podcast #6: Mark Ford on BPEL4People [2:35m]: Play Now | Play in Popup | Download (35)

David Worthington of SD Times covers the release of ActiveVOS 5.0 and writes that we have “…cracked the code to bring Web services into mass deployment for line of business applications.” The entire article is here.

Well, this is my first real “content” post and I am about to challenge no less than eminent industry notable and EDS Fellow Fred Cummins, who recently took the opportunity to declare BPEL4People dSOAoa (pronounced d-SEW-ah-oh-ah and meaning “Dead SOA on arrival”).

I am not sure if Fred’s problem core problem is with BPEL4People as much as it is with BPEL itself, which he dismisses as “for programmers.” But it’s clear he doesn’t think much of either standard, favoring instead BPMN. And I’ll be the first to admit that I am not the one who can specifically refute many of his technical arguments.

But I do know one thing: being “for programmers” when it comes to standards-based workflow ain’t a bad thing. That’s because from my relatively non-technical perspective, two things have always been true about workflow systems. First, the support for them in programming languages has been abominable and, second, every single end-user workflow system that has ever been tried has been a failure.

If the charge is “BPEL (and therefore BPEL4People) is a programming language,” then my counter-charge is that BPMN is about non-executable pretty pictures. Wikipedia says, “The primary goal of BPMN is to provide a standard notation that is readily understandable by all business stakeholders…”

Pretty diagrams do not a business application make.

In short, workflow is something that has to be developed into an application, not “specified” by some end-user on a canvas. That’s because while you can expect a developer to be capable of understanding the workflow process and adapting it to the application, you can be certain an end-user won’t be able to integrate his or her expert-level knowledge of the business process into a database or transaction system.

One area I suspect Fred and I agree on, though, is the need for standards. Another reason workflow has been ineffective in business applications is that business are loathe to lock up their processes in proprietary formats. What BPEL4People and BPMN offer users is the opportunity to free themselves from proprietary workflow engines, which is surely a good thing.

Our first podcast episode features our CEO, Mark Taber, detailing Active Endpoints’ vision for making possible the mass adoption of services-based applications. Mark touches on the problems facing developers and project teams who struggle with today’s overweight, expensive and hard-to-use tools. He also details how ActiveVOS is the most open and flexible solution to what has until now seemed like an intractable problem.

We hope you enjoy this podcast. If you have any comments or questions, please email us or leave a comment on the blog.

 

 VOSibilities podcast #1: Mark Taber on Visual Orchestration Systems [2:38m]: Play Now | Play in Popup | Download (456)

Today, Active Endpoints announced availability of ActiveBPEL Community Edition Server 5.0. The community edition contains the first implementation of BPEL4People.

Also today, OASIS announced the formation of a technical committee focused on finalizing the BPEL4People specification. We are participating in this technical committee and look forward to BPEL4People once and for all eliminating proprietary workflow from enterprise applications.

You can read more about Community Edition in our press release, attached to this post.

 Active Endpoints announces milestone 1 of Community Edition with BPEL4People: Download (330)