A developer's perspective on BPEL

BPEL (business process execution language) is the XML-based language of Web services “orchestration” — that is, a means to connect multiple Web services to create end-to-end business processes. Recently, InfoWorld Test Center Lead Analyst Jon Udell interviewed BPEL expert Edwin Khodabakchian about the future of this language. Khodabakchian is CEO of Collaxa, a pure-play BPM startup whose BPM orchestration product has supported BPEL for more than a year. Collaxa was acquired by Oracle earlier this month, and its BPEL Server product is now marketed as Oracle BPEL Process Manager. Audio excerpts of the interview are available on Jon Udell’s Weblog.

IW: You describe BPEL as a standard language for service composition, but can anybody actually write the stuff?

EK: Yes. Developers do need the visual abstractions, but they also write XML directly in Emacs.

IW: Should there be a middle ground — a scripting language that is not XML?

EK: The tool we’ve built, although it’s visual, is 100 percent targeted at the developer. BPEL is the major abstraction. Sometimes you need a visual modeler, and sometimes you need source. If you look at the history of Collaxa, we started with a scripting language which was based on Java. What we learned was that XML as a scripting language was more powerful in this specific case. With scripting languages, people tend to think about coupling things together in a very synchronous way. Also, scripting hides the persistence, the transaction boundaries, the parallel branching, the compensation. The fact that it’s XML helps you clarify that [BPEL] is a new language with things that traditional procedural languages don’t have. What we do need is a better source editor, so you’ll see us make editing the XML source easier and more productive with code completion, linking, and refactoring.

The idea is: Accept BPEL as a first-class language, understand the tasks of the developers, and create the equivalent of the JDT [Java Development Tools] for BPEL within Eclipse. And we have the visual [tool] as well, for when the visual is important. But we never lose focus that it’s a development tool. We’re not trying to build a high-level Visio-type thing.

IW: That is, of course, what a lot of people are expecting to see.

EK: The way I describe the evolution is that it’s similar to J2EE and the portal. When you’re building a Web app with Struts, it’s very flexible and not targeted at somebody who would declaratively build things. But if you look at a portal framework, it becomes completely data-driven. What we see here is SIs [system integrators] taking our technology, building templatized business processes, and building wizards for people to be able to go and change them. It’s going to be a two-step process. First you need to have the layer underneath get baked and become more mature. I think it’s a couple of years before we can deliver the Holy Grail of having more parametric processes that nontechnical people can change and configure more easily.