Web Service Orchestration (WSO) promises the ability to integrate and assemble individual Web services into standards-based business processes. WSO is an key enabler for an enterprise’s Service Oriented Architecture and a critical layer in the web services technology “stack”. These loosely coupled business processes will be designed, integrated, executed and managed similar to the way proprietary Enterprise Application Integration (EAI) and Business Process Management (BPM) tools operate today. However, business process execution standards and Web services will greatly reduce vendor lock-in to dramatically reduce costs and provide broader interoperability and reusability benefits.

To facilitate WSO, the Business Process Execution Language (BPEL) was created to standardize integration logic and process automation between web services. BPEL 1.0 was jointly developed by IBM, BEA, SAP, Siebel and Microsoft in August 2002. In April 2003, BPEL 1.1 was submitted to OASIS to obtain even broader industry acceptance and open standardization. The resultant open standard currently under development by OASIS is expected to be released to the public in Q1 2004.

BPEL is an XML format like all other Web service-related languages and specifications. BPEL is a convergence of language features from IBM’s Web Service Flow Language (WSFL) and Microsoft’s XLANG, which is the orchestration language used by Microsoft’s BizTalk server. Both WSFL and XLANG are now superseded by the BPEL specification.

BPEL leverages other Web service standards such as SOAP and WSDL for communication and interface description. BPEL describes the inbound and outbound process interfaces in WSDL so that they can be easily integrated into other processes or applications. In turn, this allows consumers of a process to inspect and invoke a BPEL process just like any other Web service.

BPEL is designed to describe process orchestrations and “process interfaces”, i.e. the external process façade referred to as “abstract processes”. This paper focuses on building the orchestrations as executable processes.

Web services are being adopted within and outside of organizational boundaries. The technology industry is rapidly converging on Web services as the common integration fabric. The vendors of large enterprise packages for example are now exposing Web service interfaces as integration points. At the other end of the spectrum, traditional internet businesses, such as the internet store Amazon.com or the search engine Google are looking to generate new revenue streams by providing Web services to make their applications integrate-able as well.

The next logical step in the current shift to a (Web) service centric model is the orchestration of such services into new business processes and higher level services. Microsoft’s .NET and IBM’s e-business on demand are just two SOA-based models that rely heavily on service composition. In these models center around domain experts providing services in their area of expertise. Businesses will assemble their own, services by composing,(or orchestrating) existing and custom-developed services. The existing services can be provided by expert companies, such as ERP vendors or Web service providers, or by other departments within the same enterprise.

Web services provide the common interface technology that unifies the integration model for all services regardless of their origin.

The benefits of Web services, such as run-time discovery and loose coupling, then carry forward into WSO to provide closer real-time business process modeling and execution. This is another great improvement over the brittle integration links used with proprietary BPM and EAI solutions. Building orchestrations without traditional programming tools such as Java or C# will further reduce the overall effort of providing new services and service-based applications.

The business motivations behind WSO are the same motivations behind the use of proprietary BPM and EAI solutions: Increased productivity, reduced operating costs and improved service levels through process automation. The important difference is that WSO solutions provide these benefits using standardized technologies. When an organization doesn’t use BPM and EAI tools, the traditional method for integration and process automation usually means modifying embedded logic inside of functionally oriented IT applications like ERP and CRM. The development, testing and deployment effort required to change these applications make integration and process changes very costly and complex.

EAI and BPM products solve the problem of embedded process logic by abstracting the integration and process automation logic into a new layer of software tools. These software products liberate integration and process tasks from the underlying functional IT applications so they could be more effectively changed, managed and optimized.

WSO and BPEL apply the lessons learned from integrating proprietary EAI solutions and reflect the current movements within the IT industry. They acknowledge that Web services are emerging as the standard integration technology and take next logical step. They provide a standardized integration interface and a standardized language for integration and process automation. BPEL, in effect, has the potential to commoditize the capabilities provided by proprietary EAI and BPM solutions. As it often occurs in a commodity market, the resulting prices for product and services will fall, which is one of the most important business cases for adopting BPEL. Business processes exported to BPEL will be able to execute in a variety of standards-compliant execution engines, offering customers more choice and the ability to mix and match best-of-breed tools.

Development, maintenance and support costs are another reason to choose WSO and BPEL. If your organization has the capability to integrate Web services, then you will also be able to create and invoke BPEL processes by leveraging existing Web services infrastructure and know-how. This will ultimately enable a broader group of developers to perform business integration and process automation tasks that previously required highly specialized skills.

BPEL provides constructs to describe arbitrarily complex business processes. At the highest level, a BPEL process defines the interaction between partners. A process can interact synchronously or asynchronously with its partners, i.e. its clients and with the services the process orchestrates.

The building blocks for a BPEL process are the descriptions of the parties participating in the process, the data that flows through the process and the activities performed during the execution of the process.

BPEL processes can be executed via their own Web service interface, or through internal triggers defined inside the process. An external trigger is a message received on a port exposed by the process, internal triggers are time driven and defined inside the process.

The first step of a BPEL process is the definition of the partners involved in the service. Partners are the services involved in the execution of the service. They can be clients to the process or service providers to the process. Partners are defined through partner links, roles and the WSDL port types associated with a role.

The following diagram illustrates these relationships. In the diagram a, partner link connects Partner 1 and Partner 2. Each of the partner link includes multiple roles (labeled A-D and W-Z in the diagram), such as 'shipment tracking service' or 'delivery notification service'. One or more roles are associated with a service port. The partners communicate by exchanging messages (1 – 4) between these ports.

In an orchestration scenario, the messages from the ports are processed by the BPEL instances running at a partner site and are subject to that partner's business rules."

The next step is to define the variables used by the process. The variables are instances of WSDL message types, XML Schema simple types or XML Schema elements. The process uses the variables as input or output containers for service invocations and to store the state of a process instance.

Following the data definition is the definition of fault handlers. These handlers define the activities to perform if the process execution terminates with a fault condition. The definitions follow the same syntax used to define the regular process execution.

Finally, the process defines the activities that make up the process execution under normal circumstances. BPEL defines a number of activities to describe the interaction of the process with the partners of the process. The process can receive messages sent by partners of the process, it can invoke services synchronously or asynchronously and it can reply to the client if the process is set up to execute a request-response message exchange.

A process can also define compensating activities at several levels. Compensation handlers can be attached to a single activity or to a group of activities that can be compensated through a single handler. Compensation handlers themselves can be built from all the BPEL language elements and can access the current state of the process variables.

BPEL also provides a number of constructs to control the flow of these activities. Processes can perform activities sequentially, in parallel or in response to a message received from a partner. To provide control on a finer grained level, BPEL also defines elements to manipulate the content of process variables, build control loops, branches, synchronization and exception handlers as we know them from programming languages like C# and Java.

Processes that rely on the exchange of multiple messages are supported through a correlation construct that allows to route messages to a currently executing process instance. This construct simply identifies the message elements that uniquely identify a process instance via XPath expressions.

The service bindings of the partner services can be defined in the partner’s WSDL document. In that case it is up to the engine implementor to decide if and when to update the partner WSDLs. Alternatively, BPEL allows to dynamically assign endpoint references a partner to handle dynamic service bindings inside the process.

Despite the fact that the standard is not named WS-BPEL, BPEL very much belongs into the WS-* family of second generation Web service specifications, like WS-Addressing and WS-Security for example. Like the other WS-* standards, BPEL also utilizes sister specifications. It explicitly makes use of WS-Addressing for the dynamic assignment of Web service endpoints.

The BPEL authors also expect processes to leverage WS-Transaction for long running business transactions. However, WS-Transaction is currently in flux and the follow up specification WS-BusinessActivity is not published at the time of this writing. It is expected that the next version of BPEL will lay out the relationships between the two specifications in more detail.

BPEL recommends the use the WS-Security framework to address authenticity and other security concerns. However, there are no constructs in the language to support this recommendation. Again it is up to the tool vendors to find the right way to implement this recommendation. One approach is to define security aspects in the process’ WSDL definition using WS-Policy. The BPEL design tools will need to provide the means to add the policy references to the generated WSDL as needed.

WSO products typically consist of a “design time” IDE to model and optimize business processes, and the “run time” engine or server to execute these processes using BPEL and web services.

The design time IDE should be capable of graphically modeling enterprise business processes at any level of complexity. A key differentiator for these products is the usability and intuitive user interface of the IDE. Typically, these IDEs provide a flow-chart like design tool to design processes. The screenshot below shows the process designer shipped with the beta release of Microsoft’s BizTalk Server 2004.

Most modeling tools offer multiple views of the process models, such as a separate process representation for “business analysts” and “systems integrators” to enhance overall productivity.

The WSO run-time engine exposes the BPEL processes as Web service endpoints and executes the business processes in response to external or internal process triggers. The engine also takes care of state management for these processes. For example, some engines store process state of long running processes to allow processes to survive engine shutdown, server outages, etc.

Engines typically also provide some sort of management interface to monitor and control these processes.

Since the release of the initial BPEL draft in the spring of 2003 all of the large vendors involved in the development have announced product support. Microsoft, IBM and BEA are all going to support BPEL based orchestration. Microsoft extends its BizTalk product with the ability to author and execute BPEL processes. Furthermore the Office charting tool Visio will be capable of authoring BPEL processes. Like Microsoft, IBM will incorporate BPEL support into their existing toolset. The WebSphere Process Choreographer will support BPEL in the next release. Likewise, BEA’s WebLogic will support BPEL with the next release.

But the list of support announced for BPEL continues. Siebel will integrate BPEL into their product offering and several other companies, like Collaxa, OpenStorm and Intalio, are currently building BPEL based products . All of these companies are currently working together in the OASIS Technical Committee to clarify grey areas in the last draft of the BPEL specification.

These products will further accelerate the paradigm shifting to build applications based on service-oriented principles. Web services are the delivery vehicle for these services and service orchestration will be the key strategy to build applications. Many companies in the large enterprise space are already evaluating BPEL based solutions, but no major implementation of a BPEL based system has been announced so far. Nevertheless, looking at the supporters of BPEL, selecting BPEL-based tools is the safe bet to build the next generation of orchestration based applications.