Active Endpoints considers the JBoss BPEL Riftsaw project
Thursday, July 23rd, 2009
Yesterday (July 22), Red Hat announced its JBoss BPEL server, available via an open-source project called Riftsaw.
As you can imagine, the whole team at Active Endpoints was interested in the announcement because Active Endpoints is a leader in the BPEL standards effort, ActiveVOS processes are executed as BPEL (but ActiveVOS is most emphatically not “just a BPEL engine”) and the new project will create more interest in next-generation application development.
I wish you could be party to the intense discussions the announcement of the JBoss BPEL server kicked off inside our company. One the one hand, we note with pleasure the validation of BPEL that a new JBoss BPEL server signals to developers. On the other hand, we worry that what we saw (or should I say, ” what we riftsaw” 
) yesterday will be “good enough” for many developers who are new to services-based development and who don’t realize how rich services-based BPM systems have become. In short, we welcome the JBoss BPEL server to the party, but we want to make sure developers understand there’s no reason to set the clock back with systems that deliver elementary tooling, manual command-line deployment, no operational control and hand-editing of XML files. We want to draw a bright line between an integrated, BPEL-based BPMS that development teams love to use and individual technologies that must be pieced together using Notepad++, soapUI, the command line and ant scripts.
Bear with me a minute as we step back and think about where BPEL came from, where it is today and why the JBoss BPEL server is a step back from several years of advancement in the BPM and BPEL world.
First, why even have something like BPEL? Industry standards aren’t just “whipped up” on a collective industry whim, because getting a standard specified and approved is an arduous process. (Just ask Michael Rowley, who labors with other vendors to keep the BPEL and BPEL4People standards moving forward.) To overcome that inertia and make competitors agree, there must be both a pressing need and a general consensus that something has to be done. The shift to services-based development was the pressing need, and Active Endpoints, Oracle, IBM, SAP and others helped create the general consensus. The result? BPEL: a language designed specifically to do what Java, C++ and C# natively can’t: orchestrate services.
But a standard is just that: a specification. To make the standard into a product that developers will love using is a big job, and it’s how vendors approach that product development effort that differentiates their products. The differences between the “raw” implementation of a standard and a fully-integrated product is what makes competitive vendors willing to agree to a standard in the first place. They hope to benefit by delivering complete solutions based on the standard…they differentiate by combining the standard with other features and capabilities to develop whole products that developers will enjoy using because those products are easy, integrated, complete and fun.
Now I believe (and I may upset some folks with this assertion) that the BPEL effort, noble as it is to introduce a purpose-built language for service orchestration, originally shot itself in the foot because it didn’t specify a way to visually design BPEL and because, until BPEL4People, there was no way to integrate human and automated tasks in processes in a standardized way. Both issues have been corrected, but BPEL has had trouble shaking the reputation of being hard to develop and deploy.
We think the JBoss BPEL server is likely to resurrect that misperception because it lacks advanced tooling and it has not implemented BPEL4People. We fear that large numbers of developers will experiment with the JBoss BPEL server, decide that it’s either too complex, or perversely, “acceptable” because they like elemental tooling and never experience what a modern BPMS with a superior development and deployment environment can deliver.
I want to give you just one example contrasting a “raw” BPEL server and a complete development environment based on BPEL. BPEL has core and very confusing concepts called partner link types and partner links. These are powerful concepts but not obvious, especially to developers new to services. If you are a services guru, you can understand it easily. If you are like many developers, the explanation is likely to give you a headache and make you swear off BPEL. But there’s no reason to expose the concept of BPEL partner links to the vast majority of process developers.
So, in ActiveVOS 6, we introduced the concept of the Participant’s View, pictured here:
In ActiveVOS, we know BPEL so you don’t have to. Once you’ve imported the WSDLs, we can automatically set up the partner links and partner link types (e.g., upstream and downstream “participants”) in a handy graphical view. You simply drag them onto the canvas, and voila!, instant creation of the correct partner links and partner link types. Contrast ActiveVOS with the recorded July 22 demo of the JBoss BPEL server, which demonstrates editing partner links with Notepad++.
We think we know which kind of development system developers prefer. (And by the way, if you really have to or want to edit the BPEL partner link types in ActiveVOS, be our guest. What we produce automatically and graphically is 100% pure BPEL…just the way you like it.)
This is just one example of the difference between a fully-developed, mature, standards-based BPMS the entire development team can use and “raw” technology in the form of an open source project. We urge developers to look beyond the headlines of “standards” and “projects” to complete products that are rigorously based on standards but which also make development using those standards simple and quick.
