BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
When it comes to integrating systems and automating workflow, business process execution language (BPEL) holds its own in the SOA world and provides a consistent process for coordinating disparate systems. In the last five years, BPEL hasn't undergone any major changes, but it has received more mature support from vendors. The support hasn't come without a price, but if developers use BPEL for automating technological processes and eschew excessive customization, they can overcome some common problems with the technology, experts say.
BPEL originally started off as an aid for the business end of enterprises, according to Léon Smiers, solution architect at global consulting firm Capgemini. While the only part of the standard that has changed has been a better user interface, BPEL itself has shifted more toward the technical end of enterprises, better suited for integrating different technical services, Smiers said.
Where business process execution language has an edge
Used for small- or large-scale integrations, BPEL helps connect abstractions and route information, as well as combine several technological processes that could be seen by the business as one, Smiers said. For example, a company could enter an invoice, one business process, but that invoice would also need to update a second system and an SAP application for multidepartmental viewing. "From the business perspective, you're entering the invoice information, which is one step, but the technology is three steps, and you have to combine the systems together," he added.
One example of BPEL's usefulness is in the insurance industry, according to Nauman Noor, a New York-based management consultant. A customer might visit a website for an auto insurance quote, entering an address where the car is garaged, and the quote would be based on information provided by a service that provides VINs of other vehicles in the area. On the back end, a BPEL tool would take the address and turn it into a format accepted by the VIN service. After retrieving the information, the BPEL tool would then send information from the VIN service to the next step in the process, he said.
The problem with BPEL is it doesn't solve a lot of issues such as human processes.
Vaughn Bullard, founder and CEO of BuildAutomate Inc.
"One reason why these tools use BPEL instead of BPMN [business process modeling and notation] is because BPEL has robust error handling," Noor said. In the insurance example, BPEL would have a secondary path to send the VIN numbers, should an error occur in the process, he said.
As a standard component in middleware, BPEL has a long future shelf life, with more standardization along the way, according to Smiers. BPEL helps standardize environments and allows for processes to be reused. "One of the reasons we want to have [BPEL] is that you lower risk in your solution," he said. This, in turn, makes it less expensive to run disparate systems.
Reusing processes and code tends to be a strong driver for companies to use BPEL, according to Noor. A lot of third-party tools use similar BPEL flows, and developers can reuse the code rather than starting from scratch. "It decreases the maintenance cost and the effort and time to market," he said.
"Software architects should feel comfortable in using BPEL, knowing that support by vendor tools is fairly mature and most of the implementation kinks have been worked out," Noor added.
Where business process execution language falls short
However, BPEL does come with its downsides. "It's a standard driven by committee, so interoperability across vendor tools will be difficult," Noor said. For example, a company using Oracle for BPEL that wants to switch to Tibco will need to convert the workflows, and the extensions involved can also be challenging, he said.
Another problem that can arise is that while new developments tend to be user-centric with a lot of iterations available. BPEL itself isn't suited to that kind of agile development, since it's impractical to put in a tool to route emails or implement in a heavily user-centric environment, Noor said. "You're not going to call out the workflow separately [in BPEL]," he said.
"The problem with BPEL is it doesn't solve a lot of issues such as human processes," said Vaughn Bullard, founder and CEO of Ashburn, Va.-based consultancy BuildAutomate Inc. An additional specification called BPEL4People exists, but it hasn't gone very far, he said.
Business process execution language in action
BPEL helps on the railroad
AT&T dials in to BPEL
Online real estate moves into BPEL
Verizon calls on BPEL
This is where the BPEL camp splits into two, according to Bullard. BPMN is the other standard, primarily used for human-driven processes. While BPEL isn't well-suited for people-centric processes, it still is a well-defined standard supported by large companies and isn't going anywhere anytime soon, he added.
BPEL also runs up against formal languages to describe business processes, according to Noor. "Typically, for smaller initiatives and in cases of agile development … the team may eschew the overhead of using a formal language like BPEL and enable the end result through custom development," he said.
Another problem that arises with BPEL has to do with normal issues in SOA, according to Smiers. Many times, developers will want to highly customize it, but that just makes the application more difficult and expensive to maintain, which happens in more than just BPEL, he said. "People forget it's there for a reason," he added.
Developers sometimes also want to extract all their functionality in middleware, which typically isn't done in BPEL, Smiers said. "It's good at linking things together," he said, but for batch processes that require a lot of cycles, it's not meant for that.
With solid vendor support and mature implementations that have ironed out the kinks, BPEL is here to stay. Developers working with it can expect consistency, and because there are so many vendors that have adopted it, they can also expect it to grow in popularity and be paired with BPMN to automate more of the business.
Christine Parizo is a freelance writer specializing in business and technology. She focuses on feature articles for a variety of technology and business-focused publications, as well as case studies and white papers for business-to-business technology companies.