GCN Tech Blog

By GCN Staff

Blog archive

BPM to vanquish BPEL?

As agency architects look at Service Oriented Architecture as a way to reuse IT components, they soon learn about the Business Process Execution Language, or BPEL. GCN has extolled the potential usefulness of this XML-based language, which architects can use to compose applications by coordinating disparate services. Oracle will use its own BPEL engine to run for its upcoming Fusion platform.

We've always assumed BPEL would supplant Business Process Management software, which also manages multi-app workflows, but encodes the process logic internally. BPEL liberates the business rules in open XML files. Why have your logic locked into the proprietary dungeon of some commercial application?

Taking the opposing view, Phil Gilbert, Chief Technology Officer of BPM vendor Lombardi Software Inc., thinks that BPEL will not trump BPM. In fact, BPM might well render BPEL obsolete, he writes in his own blog.

Why? BPEL adds an extra, unnecessary step. Using a graphical modeling interface of your choice (say Model Driven Architecture), you model the entire process, and then translate that model into a BPEL file, which then can be used as an outline for executable code. This approach works fine until you need to update the business process. 'While the auto-generated code was useful the first time around, if you messed with it, then it was very difficult (read: impossible) to go back to the graphical model when you were ready to make modifications,' he wrote.

In short, BPEL adds an extra step, which allows the possibility of the working code to fall out of synchronization from the model on which it was based. By using BPM, the architect actually links the model to the actual executable code. When the architect changes the model, the executable code changes automatically as well. 'We are moving away from hand-crafted code that is divorced from the graphical editing environment. We are moving toward standard execution of graphical models,' he wrote.

All fine and well, but what about that business logic? By e-mail, he explained that the issue will soon be moot. Most BPM applications use the Business Process Modeling Notation to render models. Soon, BPMN will be easily converted into XML, thanks to the emerging Business Process Definition Metamodel specification, now in the final stages of development. 'Since BPMN and BPDM will work seamlessly together, and since there will be an explicit notation and process object model represented in the XML, this combination is superior to BPEL because it moves us further down the road toward true round-trip engineering of processes,' he responded.

'I think the promise of BPM is to radically alter and increase the business participation in the development, deployment, consumption and measurement of process applications. In order to do this, we must move to a place where the picture is the process, and in order to do this, we must focus on BPMN,' he wrote. By doing so, 'The implementation language becomes irrelevant.'

Posted by Joab Jackson

Posted by Brad Grimes, Joab Jackson on Mar 15, 2006 at 9:39 AM


Featured

  • Telecommunications
    Stock photo ID: 658810513 By asharkyu

    GSA extends EIS deadline to 2023

    Agencies are getting up to three more years on existing telecom contracts before having to shift to the $50 billion Enterprise Infrastructure Solutions vehicle.

  • Workforce
    Shutterstock image ID: 569172169 By Zenzen

    OMB looks to retrain feds to fill cyber needs

    The federal government is taking steps to fill high-demand, skills-gap positions in tech by retraining employees already working within agencies without a cyber or IT background.

  • Acquisition
    GSA Headquarters (Photo by Rena Schild/Shutterstock)

    GSA to consolidate multiple award schedules

    The General Services Administration plans to consolidate dozens of its buying schedules across product areas including IT and services to reduce duplication.

Stay Connected

Sign up for our newsletter.

I agree to this site's Privacy Policy.