BPEL can usher in a new era of Business Process Management

Business Process Execution Language promises to aid enterprises in the quest for SOA. Akshay Aggarwal, Solution Architect, BEA Systems, talks to Network Magazine about what BPEL can provide.

Akshay Aggarwal

SOA has been a buzzword for quite a while. What are the roadblocks that the concept faces today?

One of the most significant trends in computing right now is the migration to ‘service oriented architecture,’ or SOA, which is a standards-based organisational and design methodology that more closely aligns IT with business processes using a collection of shared services on a network.

Employing standard interfaces that help mask the underlying technical complexity of the IT environment, SOA enables greater re-use of IT assets resulting in more rapid development and more reliable delivery of new and enhanced business services. However, implementing SOA and successfully putting it to work for your enterprise requires a crucial first step of identifying, optimising and ultimately automating your key business processes. To make this happen as simply as possible, the need for an open, common, standard language and interface is critical.

Do Business Process Management (BPM) solutions available today fulfil this need for open standards?

For several years, a wide range of BPM solutions have been available, and many of these can no doubt meet the challenge of automating business processes, but traditionally each has utilised its own proprietary process language, design tool and run-time engine.

This lack of commonality and openness has essentially trapped customers within the confines of the tools provided by their chosen vendor, and it has also arguably slowed the adoption of BPM technologies at a time when enterprises should be drawing great benefits from them. Adding further complexity to the situation, the historical lack of a standard interface mechanism for interacting with enterprise resources has led many BPM and EAI vendors to invent their own adapter and connector architectures.

Are there any new open standards/technologies that are available or are being developed to solve these integration issues?

Just as the advent of Web services standardisation has simplified the connectivity problem, similar standardisation is sorely needed for business processes logic. Such standardisation will not only provide enterprises with more choices, but will also give them a new level of investment protection and accelerate the adoption of SOA. Fortunately, the first steps are already being taken towards standardisation. One of the key efforts of relevance is WSBPEL (Web Services Business Process Execution Language, often commonly referred to as BPEL), a specification originally co-written by BEA, IBM and Microsoft, and now being standardised via OASIS. Currently in the midst of heavy revision (with the goal of formal standardisation by around late 2005), BPEL will provide a standard way of building automated processes that orchestrate interactions between Web services.

What are the main features that BPEL will provide?

The key goal of BPEL is portability. It will enable customers to protect their investments by allowing them to move their process definitions between a variety of authoring tools and execution platforms regardless of the underlying technology. For example, a user should be able to build their BPEL process in one vendor’s tool, display and edit it in another, and deploy and execute it in a third.

Realistically, the first version of the standard will not entirely achieve this goal, but users will still enjoy a higher level of portability than has traditionally been possible. As BPEL is still in its infancy and not yet a standard, the OASIS technical committee continues to work through issues and the specification continues to change significantly. In late 2005 we expect to see a solid working version of this standard, which we anticipate will bring much-needed portability and standardisation to the world of business process logic.

While there have been previous attempts at creating a standardised business process definition language, BPEL has attracted an unprecedented level of interest and is the first to gain critical mass among software vendors. For those interested in SOA trends, Web services and BPM, this budding standard is definitely one to keep a watchful eye on.

How does BPEL work?

BPEL utilises an XML syntax from which a process diagram can be rendered, enabling developers to build their processes largely by using visual drag-and-drop tools. BPEL processes can automate both simple and complex interactions between multiple SOAP-based Web services using XML documents and types, and can also represent sophisticated logic such as long-running transactions with compensation, parallel execution, and both synchronous and asynchronous interactions.

Does BPEL have any problems or drawbacks as of now?

Since it is intended as an SOA standard for Web service orchestration, BPEL cannot directly interact with resources that do not offer a Web service interface (such as custom applications with proprietary APIs), nor can it represent fine-grained procedural logic or complex data manipulation. It is expected that BPEL will often be extended with other languages and paired with other technologies in order to solve these types of problems.

Although BPEL is clearly poised to become the dominant standard for orchestration of Web services, it does not address a number of significant issues faced today by organisations with heterogeneous IT environments. By design, BPEL only describes interactions between Web services. While nearly all systems or objects can be wrapped in Web service interfaces, this mechanism is itself a heavyweight abstraction that introduces overhead and complexity that may not always be necessary.

When communicating with local resources, lighter-weight interfaces such as Java APIs often provide a more direct approach. In addition, BPEL does not try to be a general-purpose programming language, but instead focusses on business process logic (‘programming in the large’). It is assumed that BPEL will be combined with other languages like Java which are used to implement business functions (‘programming in the small’).

So is any work being done to sort out these issues with BPEL?

It was with these issues in mind that BEA first authored and sponsored JSR 207, which is chartered with exploring and standardising the relationship between process languages like BPEL and the Java language and J2EE platform. As the next major step to defining this Java process standard, BEA and IBM have closely collaborated to create a new specification titled BPELJ.

This specification has also been submitted to the JSR 207 working group for consideration. Described in a joint white paper, BPELJ is a combination of BPEL with Java that allows these two programming languages to be used together to build complete business process applications. By enabling BPEL and Java to work together, BPELJ allows each language to do what it does best. Since BPELJ is implemented via extensions to the BPEL language, any BPEL process is also a valid, executable BPELJ process. By standardising these extensions, BEA and IBM are working to ensure that real world automated business processes will be truly portable and inter-operable across the J2EE platform.