Industry Commentary

The enterprise service bus (ESB) is, arguably, emerging as the preeminent platform for building, deploying, and managing Web services. However, once you have created and deployed your Web services, what's the next step? For many developers, it is the orchestration of those services into composite applications and business processes. In the past, this area has proved troublesome. The majority of existing business process tools are vendor specific and proprietary, using adapters and bridges to integrate with open platforms like Web services. However, the emergence of Business Process Execution Language (BPEL), coupled with the growth of Web services and the ESB, is providing a real, native, service-oriented architecture (SOA)?based alternative.

This potential was brought home to me when I was working with a high-tech manufacturer who faced the perennial problem of managing old, proprietary software that linked their ERP systems with their partners (primarily contract manufacturers). The existing system was complex, required a lot of maintenance, and was difficult to change. The company identified Web services and SOA as an alternative solution that would enable them to rip out the legacy software while, at the same time, reduce the cost and complexity of linking with their partners.

By adopting a Web services approach, they immediately got cross-platform interoperability, standards-based development, location independence, integration with existing systems, and promotion of future service reuse. They used an ESB to build and deploy the Web services, which provided the necessary policy, transformation, and routing capabilities to enable their services to be exposed. The documents exchanged between the company and its partners were defined in XML; partner interfaces were quickly defined in WSDL.

However, Web services alone only partially solved the integration problem. They still needed a mechanism to define and coordinate service interactions to deliver composite applications and automate real-world business processes. These processes varied widely, from automating the selection of partners for delivering a product, to transferring documents with the selected third-party contract manufacturer, and ultimately to delegating the construction and delivery of products. The processes also controlled the exchange of shipping details, component warranty details, and, of course, invoicing.

Given their choice of Web services, the most obvious option for building the business processes was BPEL. Once these processes were described using BPEL, they were deployed as a service on the ESB. The combination of BPEL and the ESB offered a single solution that enabled them to expose their enterprise infrastructure as Web services, to apply policy to the Web services, and to compose the services into powerful and visible business processes.

The customer was pleasantly surprised that BPEL met their requirements. The BPEL server they used was designed to run many processes. Each process typically ran for months after being inactive for considerable periods of time. The BPEL server ensured that critical process state was safely stored in a transactional datastore, should recovery be required in the event of transient service unavailability. The BPEL server also provided their administrators with a Web-based management console that enabled them to query and view the activity history of process instances and remotely control the execution of running or faulty processes.

BPEL enabled them to use off-the-shelf tools to define the process flow in a visual manner, as a series of interactions with SOA service interfaces hosted on the ESB. The BPEL process itself is hosted on the ESB and externally exposed as an SOA service. A stand-alone client driver application triggers the start of each BPEL process instance when an order is created or modified. From then on, all interaction between services takes the form of SOA-style invocations.

As the customer implemented the project, they learned a number of important lessons about BPEL:

• Design BPEL processes from the top down, not the bottom up. When designing and implementing BPEL processes, it is critical to ensure that the BPEL process directly models the underlying business process in the most abstract form possible, without losing any critical process data.
• Fault-tolerant BPEL servers cannot compensate for BPEL scripts that do not implement sufficient fault-handling logic. Be prepared to handle faults, especially when invoking on or receiving from a remote Web service.

As organizations build out services from their existing infrastructure using the ESB, there is no question that the next step is to orchestrate those services to support new and existing business processes. BPEL enables the creation of meaningful service-based business processes that promise to become more important as the adoption of Web services and SOA continues.