BPEL (Business Process Execution Language for Web Services, also WS-BPEL, BPEL4WS) is a language used for composition, orchestration, and coordination of web services. It provides a rich vocabulary for expressing the behavior of business processes. In this chapter, we introduce BPEL, define its role in the SOA (Service Oriented Architecture), and explain the process-oriented approach to SOA and the role of BPEL. We also provide short descriptions of the most important BPEL servers—the run‑time environments for execution of business processes specified in BPEL—and compare BPEL to other business process languages. In this chapter, we:
Discuss the role of business processes and their automation
Overview web services, ESB (Enterprise Service Bus), and SOA
Discuss the composition of services
Explain the role of BPEL in web service composition
Explain the most important BPEL features
Overview BPEL orchestration servers
Compare BPEL with other standards
Discuss the future of BPEL
Enterprise applications and information systems have became fundamental assets of companies. Companies rely on them to be able to perform business operations. Enterprise information systems can improve the efficiency of businesses through automation of business processes. The objective of almost every company is that the applications it uses should provide comprehensive support for business processes. This means that applications should align with business processes closely.
Although this requirement does not sound very difficult to fulfill, the real-world situation shows us a different picture. Business processes are usually of dynamic nature. Companies have to improve and modify, act in an agile manner, optimize and adapt business processes to their customers, and thus improve the responsiveness of the whole company. Every change and improvement in a business process has to be reflected in the applications that provide support for them. Only companies where applications can be quickly and efficiently adapted to the changing business needs can stay competitive on the global market.
We all know that changing and modifying applications is a difficult job, which requires time. This means that information systems cannot react instantly to changes in business processes—rather they require some time to implement, test, and deploy the modifications. This time is sometimes referred to as the information systems gap time. It is obvious that the information systems gap time should be as short as possible. However, in the real world this is again not always the case. Let us discuss the reasons.
The time required for modifying applications is related to several factors. The most important factor, in addition to the complexity and size of the modification, is the state of the application being modified. If an application has a well-defined architecture and has been constructed keeping in mind future modifications, then it will be easier to modify. However, each modification to the application makes its architecture less robust with respect to future changes. Applications that have been maintained for several years and have gone through many modifications usually do not provide robust architecture anymore (unless they have been refactored constantly). Modifying them is difficult, time consuming, and often results in unexpected errors.
The situation gets even more complicated. Several applications still in use in companies (particularly legacy applications) have not been developed with the objective of providing support for entire business processes. Such applications, often called stovepipe applications, provide support for certain functions or tasks only. For an information system to provide complete support for business processes, it has to be able to use the functionalities of several existing applications in a coordinated and integrated way. This makes the primary objective of information systems—to provide timely, complete, and easy modifiable support for business processes—even more difficult to achieve.
Based on what we have said so far, we can conclude that for efficient automation of business processes through IT we need to:
Provide a standardized way to expose and access the functionality of applications as services.
Provide an enterprise bus infrastructure for communication and management of services, including message interception, routing, transformation, etc.
Provide integration architecture between the various services and existing and newly developed applications used in business processes.
Provide a specialized language for composition of exposed functionalities of applications into business processes.
For many years the software industry has been searching for efficient architectures, technologies, and methods that would make the realization of the above mentioned aspects as simple and as quick as possible. Let us briefly describe each of the four aspects.
The requirement to expose functionalities of applications and access them remotely has resulted in several distributed architectures and middleware products, which emerged over time. The latest distributed architecture, which combines both synchronous and asynchronous communications, is Web Services. Web services are the most suitable distributed architecture for exposing the functionality of applications as services.
The enterprise bus infrastructure for communication and management of services provides answers related to the usage of services in complex enterprise information systems. In such environments support for centralized, declarative, and well-coordinated management of services and their communications is required. Because of existing middleware, the integration of different middleware products and interoperability with web services is required. These features are provided by the Enterprise Service Bus (ESB).
Integration between applications is a well-known topic. This integration is needed because enterprise information systems usually consist of several different applications, which address certain (sometimes isolated) functions and tasks and not whole business processes. Achieving efficient integration is related to the definition and realization of sound integration architectures, which are often very complex, particularly in large companies. Best methods and practices for building integration architectures are today known as Service Oriented Architectures (SOA).
The final aspect is the composition of exposed services of integrated applications into business processes. The most popular, commonly accepted, and specialized language for business process definition is BPEL, the main topic of this book. BPEL promises to acheive the holy grail of enterprise information systems—to provide an environment where business processes can be developed in an easy and efficient manner and quickly adapted to the changing needs of enterprises without too much effort.
The following figure shows the relation between SOA, web services, ESB, and BPEL:
Before starting the discussion on BPEL let us first have a quick look at web services, the enterprise service bus, and SOA.
Web services are the latest distributed technology and, as we will see, the most suitable technology for realization of SOA. They have become the commonly used technology for interoperability and integration of applications and information systems. Web services provide the technological foundation for achieving interoperability between applications using different software platforms, operating systems, and programming languages. They are built on XML. While XML is the de facto standard for data-level integration, web services are becoming the de facto standard for service-level integration between and within enterprises.
From the technological perspective, web services are a distributed architecture. The distributed computing paradigm started with DCE (Distributed Computing Environment), RPC (Remote Procedure Call), and messaging systems, also called message‑oriented middleware (products such as MQ Series, MSMQ, etc.). Then distributed objects and ORBs (Object Request Brokers), such as CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model), and RMI (Remote Method Invocation), emerged. Based on them component models, such as EJB (Enterprise Java Beans), COM+ (Component Object Model), .NET Enterprise Services, and CCM (CORBA Component Model) have been developed. RPC, ORBs, and component models share similar communication model, which is based on synchronous operation invocation. Messaging systems are based on the asynchronous communication model.
Web services are similar to their predecessors, but also differ from them in several aspects. Web services are the first distributed technology to be supported by all major software vendors. Therefore they are the first technology that fulfills the promise of universal interoperability between applications running on disparate platforms. The fundamental specifications that web services are based on are SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language), and UDDI (Universal Description, Discovery, and Integration). SOAP, WSDL, and UDDI are XML based, making web services protocol messages and descriptions human readable.
From the architectural perspective, web services introduce several important changes compared to earlier distributed architectures:
Web services support loose coupling through operations that exchange data only. This differs from component and distributed object models, where behavior can also be exchanged.
Operations in web services are based on the exchange of XML‑formatted payloads. They are a collection of input, output, and fault messages. The combination of messages defines the type of operation (one-way, request/response, solicit response, or notification). This differs from previous distributed technologies. For more information, please refer to WSDL and XML Schema specifications.
Web services provide support for asynchronous as well as synchronous interactions.
Web services introduce the notion of endpoints and intermediaries. This allows new approaches to message processing.
Web services are stateless. They do not follow the object paradigm.
Web services utilize standard Internet protocols such as HTTP (Hyper Text Transfer Protocol), SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol), and MIME (Multipurpose Internet Mail Extensions). So, connectivity through standard Internet connections, even those secured with firewalls, is less problematic.
In addition to several advantages, web services also have a couple of disadvantages. One of them is performance, which is not as good as that of distributed architectures that use binary protocols for communication. The other is that plain web services do not offer infrastructure and quality‑of-service (QoS) features, such as security, transactions, and others, which have been provided by component models for several years. Web services fill this important gap by introducing additional specifications:
WS-Security: Addresses authentication and message-level security, and enables secure communication with web services.
WS-Coordination: Defines a coordination framework for web services and is the foundation for WS-AtomicTransaction and WS-BusinessActivity.
Transactions specifications (WS-AtomicTransaction and WS-BusinessActivity): Specify support for distributed transactions with web services. AtomicTransaction specifies short duration, ACID transactions, and BusinessActivity specifies longer running business transactions, also called compensating transactions.
WS-Reliable Messaging: Provides support for reliable communication and message delivery between web services over various transport protocols.
WS-Addressing: Specifies message coordination and routing.
WS-Inspection: Provides support for dynamic introspection of web service descriptions.
WS-Policy: Specifies how policies are declared and exchanged between collaborating web services.
WS-Eventing: Defines an event model for asynchronous notification of interested parties for web services.
These specifications constitute the web services technology stack, which is described in detail in Chapter 2, and is required (at least partially) for serious use of web services in enterprise applications.
Because of their flexibility, interoperability, and other features, web services are regarded as the most appropriate technology for exposing the functionalities of applications as services and are therefore the most appropriate technology for realization of SOA. Because of their wide support by all major software vendors, web services provide the possibility to use the same technology to expose services implemented in a variety of different applications ranging from mainframe-based legacy applications to the modern multi-tier applications.
While web services are an appropriate technology for SOA, some other aspects need to be considered:
In most enterprises, web services are not the only middleware solution used. Usually enterprises already have one or more middleware products, such as messaging systems and ORBs. They cannot afford to replace them overnight with web services. Therefore, there is a need to integrate different middleware products, and provide interoperability with web services.
In order to provide connectivity between services, the use of SOAP in complex environments is not adequate. In such environments, we need ways to connect, mediate, manage, and control the services and particularly the communication between them.
SOAP over HTTP might not be robust enough for heavy enterprise use. Enterprise information systems require dependable, robust, and secure service infrastructure.
The Enterprise Service Bus (ESB) is the software infrastructure, acting as an intermediary layer of middleware that addresses the above-mentioned requirements. An ESB adds flexibility to communication between services and simplifies the integration and reuse of services. An ESB makes it possible to connect services implemented in different technologies (such as EJBs, messaging systems, CORBA components, and legacy applications) in an easy way. An ESB can act as a mediator between different, often incompatible protocols and middleware products.
The ESB provides a robust, dependable, secure and scalable communication infrastructure between services. It also provides control over the communication and control over the use of services, including:
Message interception capabilities: This allows us to intercept requests to services and responses from services and apply additional processing to them. In this manner, the ESB acts as an intermediary.
Routing capabilities: This allows us to route the messages to different services based on their content, origin, or other attributes.
Transformation capabilities: These allow us to transform messages before they are delivered to services. For XML formatted messages, such transformations are usually done using XSLT (Extensible Stylesheet Language for Transformations) or XQuery engines.
Control over the deployment, usage, and maintenance of services: This allows logging, profiling, load balancing, performance tuning, charging for use of services, distributed deployment, on-the-fly reconfiguration, etc.
Other important management features include the definition of correlation between messages, definition of reliable communication paths, definition of security constraints related to messages and services, etc.
Currently there are several products on the market that claim to provide ESB functionality. A good ESB should provide at least quality‑of‑service support of enterprise level, including reliability, fault-tolerance, and security. If provided by an ESB, services can depend on these features and do not need to implement them themselves. The ESB should also allow configuring any combination of these quality‑of‑service features and provide flexibility.
An ESB should provide support for a variety of technologies on which services are implemented. In addition to web services, an ESB should provide connectors for a broad range of technologies, such as J2EE and .NET components, messaging middleware, legacy applications, and TP monitors. The ESB needs to provide flexibility to bind any combination of services without technological constraints. It should also support a combination of different interaction models, such as queuing, routing, etc., without changing the services or requiring writing code.
An ESB should make services broadly available. This means that it should be easy to find, connect, and use a service irrespective of the technology it is implemented in. With broad availability of services, an ESB can increase reuse and can make the composition of services easier. Finally, an ESB should provide management capabilities, such as message routing, interaction, and transformation, which we have already described.
An ESB that provides these features becomes an essential part of the SOA. It provides several benefits, including increased flexibility, reduced deployment, development, and maintenance costs, and increased reliability and manageability. Therefore the ESB is an essential part of SOA, which we will discuss in the next section.
Information systems need to support business changes quickly and efficiently. However, they also need to adapt to the fast development of new technologies. The majority of enterprise information systems are heterogeneous, containing a range of different systems, applications, technologies, and architectures. Integration of these technologies is crucial as only integrated information systems can deliver business values, such as efficient decision-making support, instant access to information, data integrity, along with decreased cost of software development and maintenance.
To manage problems related to changing requirements, technology development, and integration, different methods have been proposed and used over time. Service‑oriented architecture is the latest architectural approach related to the integration, development, and maintenance of complex enterprise information systems.
SOA is not a radically new architecture, but rather the evolution of well-known distributed architectures and integration methods. Integration between applications has evolved from early days to well‑defined integration methods and principles, often referred to as EAI (Enterprise Application Integration). EAI initially focused on integration of applications within enterprises (intra-EAI). With the increasing need for integration between companies (B2B, business-to-business), the focus of EAI has been extended to inter-EAI.
SOA improves and extends the flexibility of earlier integration methods (EAI) and distributed architectures, and focuses on reusability of existing applications and systems, efficient interoperability and integration of applications, and composition of business processes out of services (functionalities) provided by applications. An important objective of SOA is also the ability to apply changes in the future in a relatively easy and straightforward way.
SOA defines the concepts, architecture, and process framework, to enable cost-efficient development, integration, and maintenance of information systems through reduction of complexity, and stimulation of integration and reuse. Let us look at the definition of SOA, as provided in a paper by Bernhard Borges, Kerrie Holley, and Ali Arsanjani:
SOA is the architectural style that supports loosely coupled services to enable business flexibility in an interoperable, technology-agnostic manner. SOA consists of a composite set of business-aligned services that support a flexible and dynamically re-configurable end-to-end business processes realization using interface-based service descriptions.
SOA is more than just a set of technologies. SOA is not directly related to any technology, although it is most often implemented with web services. Web services are the most appropriate technology for SOA realization. However, using web services is not adequate to build SOA. We have to use web services according to the concepts that SOA defines.
The most important SOA concepts are:
Services
Self-describing interfaces with coarse granulation
Exchange of messages
Support for synchronous and asynchronous communication
Loose coupling
Service registries
Quality of service
Composition of services into business processes
Services provide business functionalities, such as an application for a business travel, an application for a loan, etc. This differs considerably from technology-oriented functionalities, such as retrieving or updating a table in a database. Services in SOA must provide business value, hide implementation details, and be autonomous. Service consumers are software entities, which call the service and use its functionality.
Service consumers access the service through its interface. The interface of a service defines a set of public operation signatures. The interface is a contract between the service provider and a service consumer. The interface is separated from the implementation, is self-describing, and platform independent. Interface description provides a basis for the implementation of the service by the service provider and a basis for the implementation of the service consumers. Each interface defines a set of operations. In order to define business services, we need to focus on correct granulation of operations. SOA services are best modeled with coarse granulation.
Operations are defined as a set of messages. Messages specify the data to be exchanged and describe it in a platform‑ and language‑independent way using schemas. Services exchange only data, which differs considerably from object‑oriented and component approaches, where behavior (implementation code) can also be exchanged. Operations should be idempotent (an operation is idempotent if repeated invocations have the same effect as one invocation). WSDL is a service description language that meets SOA criteria.
Service consumers access the services through the service bus. This can be either a transport protocol, such as SOAP, or an ESB. Service consumers can use synchronous or asynchronous communication modes to invoke operations of services. In synchronous mode, a service operation returns a response to the service consumer after the processing is complete. The service consumer has to wait for the completion. Usually we use synchronous mode with operations complete processing in a short time. In asynchronous mode a service operation does not return a response to the consumer, although it may return an acknowledgement so that the consumer knows that the operation has been invoked successfully. If a response is needed, usually a callback from the service to the consumer is used. In such a scenario, correlation between messages is needed.
Through the self-describing interfaces, coarse granulation, exchange of data structures, and support for synchronous and asynchronous communication modes, loose coupling of services is achieved. Loosely coupled services are services that expose only the necessary dependencies and reduce all kinds of artificial dependencies. This is particularly important when services are subject to frequent changes. Minimal dependencies assure that there will be a minimal amount of changes required to other services when one service is modified. Such an approach improves robustness, makes systems more resilient to changes, and promotes reuse of services.
To simplify and automate searching for the appropriate service, services are maintained in service registries, which act as directory listings. Service providers publish services in registries; service consumers look up the services in the registries. Lookup can be done by name, service functionality, or business process properties. UDDI is an example of a service registry.
Services usually have associated quality‑of‑service attributes. Such attributes include security, reliable messaging, transaction, correlation, management, policy, and other requirements. The infrastructure must provide support for these attributes. Quality‑of‑service attributes are often important in large information systems. In web services, quality‑of‑service attributes are covered by WS-* specifications, such as WS-Security, WS-Addressing, WS-Coordination, etc. Quality of service is also provided by the ESB.
The final, and probably the most important, SOA concept is composition of services into business processes. Services are composed in a particular order and follow a set of rules to provide support for business processes. Composition of services allows us to provide support for business processes in a flexible and relatively easy way. It also enables us to modify business processes quickly and therefore provide support to changed requirements faster and with less effort. For composition, we will use a dedicated language, BPEL, and an engine on which business process definitions will be executed. Only when we reach the level of service composition can we realize all the benefits of SOA.
The figure bellow shows the architectural view of SOA and positions the above-mentioned concepts:
Let us now fill the technologies into the above picture to understand the connection between SOA concepts and technologies that provide means for their realization. Notice that the mere use of a specific technology does not guarantee that we build SOA‑compliant architecture. For example, with web services we can develop business services (for example, a loan application), but we can also develop technology‑focused services (updating the database, for example). So, it is essential that technologies are used according to the guidelines provided by SOA concepts:
For this picture, we can have two views. The bottom-up view of SOA sees different applications exposing their functionalities through business services. This enables access to functionalities (services) of different existing and newly developed applications in a standard way. Access to services is important because a typical enterprise has a large number of applications, which have to be integrated.
Developing business services, either through reuse of existing applications or by new development, is not sufficient. We also need to compose services into business processes—this is the second, the top-down or process-oriented approach to SOA. We would obviously prefer a relatively simple and straightforward way to compose and modify business processes. This is where the BPEL becomes important. In the next section we will discuss service composition and BPEL.
We have seen that services provide business-aligned operations. To fulfill the SOA promise services need to be composed into new larger services. We compose services until the aggregate services provide support for the whole business processes. Business processes are thus defined as a collection of activities through which services are invoked. For the outside world—that is for the clients—a business process looks like any other service. In real-world scenarios we will usually create two kinds of business processes: those that will contain services from within enterprise only, and those that will consume services provided by several companies. With service composition we can use services provided by business partners in our processes, and business partners can use our services in their processes.
Note
A business process is a collection of coordinated service invocations and related activities that produce a business result, either within a single organization or across several.
For example, a business process for planning of business travel will invoke several services. In an oversimplified scenario, the business process will require us to specify the employee name, destination, dates, and other travel details. Then the process will invoke a web service to check the employee status. Based on the employee status it will select the appropriate travel class. Then it will invoke web services of several airline companies (such as American Airlines, Delta Airlines, etc.) to check the airfare price and buy the one with the lowest price. The structure of services composed into the business process is shown in the following figure. In Chapter 3 we will discuss this example in detail and show how to define this process using BPEL:
From the perspective of our business process, we do not care whether the web service for checking the employee status accesses a legacy system, a database directly, or retrieves the status in any other way. We also do not care whether the web services of airline companies are composed of other, lower-level services. From the perspective of the client for our business process the client sees the process as any other service and does not care whether the process is implemented through composition of other services, or some other way. This stimulates reuse and further composition. Real-world business processes will usually be much more complicated than our example. Usually they will contain several services and invoke their operations either in sequence or in parallel. They will also contain flow logic, handle faults, take care of transactions and message correlation, etc.
Composition of services into business processes requires the definition of collaboration activities and data‑exchange messages between involved web services. WSDL provides the basic technical description and specifications for messages that are exchanged. However, the description provided by WSDL does not go beyond simple interactions between the client (sender) and the web service (receiver). These interactions may be stateless, synchronous, or asynchronous. These relations are inadequate to express, model, and describe complex compositions of multiple web services in business activities, which usually consist of several messages exchanged in a well-defined order. In such complex compositions, synchronous and asynchronous messages can be combined, and interactions are usually long running, often involving state information that has to be preserved. An important aspect is also the ability to describe how to handle faults and other exceptional situations. Given the limitations of WSDL, we need a mechanism to describe the composition of web services into more complex processes.
The composition of services into business processes could be realized using one of the well-known programming languages (Java, C#, …). But it turns out that the composition of services differs somehow from traditional programming. With composition, we merge functionalities (services) into larger services and processes. In other words, we do programming in the large, which differs from traditional programming in the small. Programming in the large refers to representation of the high-level state transition logic of a system. Using programming languages, such as Java, C#, etc., for composition often results in inflexible solutions, particularly because there is no clear separation between the process flow and the business logic, which should not be tightly coupled.
In addition to these facts, the composition of business processes has other specific requirements, such as support for many process instances, long-running processes, compensation, etc. All this makes the use of dedicated solutions reasonable. This is why over the years several proprietary BPM (Business Process Management) products have been developed, such as Dralasoft Workflow and Tibco Business Process Management . The disadvantage of using proprietary BPMs is that these are traditionally niche products, sold from a top-down perspective to large business users. Such products usually are expensive and bound to a certain provider.
General adoption of business process automation solutions requires a standard foundation and a specialized language for composing services into business processes that provides the ability to express business processes in a standardized way, using a commonly accepted language. BPEL is such a language and is quickly becoming the dominant standard. The main goal of BPEL is to standardize the process of automation between web services.
Note
With BPEL we can define business processes that make use of services and business processes that externalize their functionality as services.
Within enterprises, BPEL is used to standardize enterprise application integration and extend the integration to previously isolated systems. Between enterprises, BPEL enables easier and more effective integration with business partners. BPEL stimulates enterprises to further define their business processes, which in turn leads to business process optimization, reengineering, and the selection of the most appropriate processes, thus further optimizing the organization. Definitions of business processes described in BPEL do not influence existing systems. BPEL is the key technology in environments where functionalities already are or will be exposed via web services. With increases in the use of web service technology, the importance of BPEL will rise further.
IBM, BEA, and Microsoft developed the first version of BPEL in August 2002. Since then SAP and Siebel have joined, which has resulted in several modifications and improvements and adoption of version 1.1 in March 2003. In April 2003, BPEL was submitted to OASIS (Organization for the Advancement of Structured Information Standards) for standardization purposes, where the WSBPEL TC (Web Services Business Process Execution Language Technical Committee) has been formed. Many vendors have joined the WSBPEL TC (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel) since. This has led to even broader acceptance in industry.
BPEL represents a convergence of two early workflow languages, WSFL (Web Services Flow Language) and XLANG. WSFL was designed by IBM and is based on the concept of directed graphs. XLANG was designed by Microsoft and is a block-structured language. BPEL combines both approaches and provides a rich vocabulary for the description of business processes.
BPEL uses an XML-based vocabulary to specify and describe business processes. BPEL version 1.1 is based on the WSDL 1.1, XML Schema 1.0, and XPath 1.0 specifications. Familiarity with them is helpful for learning BPEL.
With BPEL we can define simple and complex business processes. To a certain extent, BPEL is similar to traditional programming languages. It offers constructs, such as loops, branches, variables, assignments, etc. that allow us to define business processes in an algorithmic way. BPEL is a specialized language focused on the definition of business processes. Therefore, on one hand it offers constructs, which make the definition of processes relatively simple. On the other hand, it is less complex than traditional programming languages, which simplifies learning.
The most important BPEL constructs are related to the invocation of web services. BPEL makes it easy to invoke operations of web services either synchronously or asynchronously. We can invoke operations either in sequence or in parallel. We can also wait for callbacks. BPEL provides a rich vocabulary for fault handling, which is very important as robust business processes need to react to failures in a smart way. BPEL also provides support for long-running process and compensation, which allows undoing partial work done by a process that has not finished successfully. Listed below are the most important features that BPEL provides. With BPEL we can:
Describe the logic of business processes through composition of services
Compose larger business processes out of smaller processes and services
Handle synchronous and asynchronous (often long-running) operation invocations on services, and manage callbacks that occur at later times
Invoke service operations in sequence or parallel
Selectively compensate completed activities in case of failures
Maintain multiple long-running transactional activities, which arealso interruptible
Resume interrupted or failed activities to minimize work to be redone
Route incoming messages to the appropriate processes and activities
Correlate requests within and across business processes
Schedule activities based on the execution time and define their order of execution
Execute activities in parallel and define how parallel flows merge based on synchronization conditions
Structure business processes into several scopes
Handle message-related and time-related events
Depending on the requirements, composition of services can address private or public processes, for which two terms are used:
Orchestration
Choreography
In orchestration, a central process (which can be another web service) takes control over the involved web services and coordinates the execution of different operations on the web services involved in the operation. This is done as per the requirements of the orchestration. The involved web services do not know (and do not need to know) that they are involved into a composition and that they are a part of a higher business process. Only the central coordinator of the orchestration knows this, so the orchestration is centralized with explicit definitions of operations and the order of invocation of web services. Orchestration is usually used in private business processes and is schematically shown overleaf:
Choreography on the other hand does not rely on a central coordinator. Rather, each web service involved in the choreography knows exactly when to execute its operations and whom to interact with. Choreography is a collaborative effort focused on exchange of messages in public business processes. All participants of the choreography need to be aware of the business process, operations to execute, messages to exchange, and the timing of message exchanges. Choreography in web services composition is as shown in the following figure:
From the perspective of composing web services to execute business processes, orchestration has an advantage over choreography. Orchestration is a more flexible paradigm, although the line between orchestration and choreography is vanishing. Orchestration has the following advantages:
We know exactly who is responsible for the execution of the whole business process.
We can incorporate web services, even those that are not aware that they are a part of a business process.
We can also provide alternative scenarios when faults occur.
BPEL provides support for orchestration and choreography through executable and abstract business processes.
With BPEL, we can describe business processes in two distinct ways:
We can specify the exact details of business processes. Such processes are called executable business processes and follow the orchestration paradigm. They can be executed by an orchestration engine. .
We can specify the public message exchange between parties only. Such processes are called abstract business processes . They do not include the internal details of process flows and are not executable. They follow the choreography paradigm.
Executable business processes are processes that compose a set of existing services and specify the exact algorithm of activities and input and output messages. Such processes are executable by BPEL engines. Executable processes are important because they are the direct answer to the problem of business process automation through IT that we have discussed earlier in this chapter. With BPEL executable processes, we are able to specify the exact algorithm of service composition in a relatively simple and straightforward way, and execute it on a BPEL‑compliant engine. Executable processes fill the gap between the business process specifications and the code responsible for their execution.
When we define an executable business process in BPEL, we actually define a new web service that is a composition of existing services. The interface of the new BPEL composite web service uses a set of port types, through which it provides operations like any other web service. To invoke an executable business process, we have to invoke the resulting composite web service. You can see that executable business processes are the most important way of using BPEL. In the majority of cases, BPEL is used to specify executable processes.
Abstract business processes, on the other hand, are not executable. They specify public message exchange between parties only—the externally observable aspects of process behavior. The description of the externally observable behavior of a business process may be related to a single service or a set of services. It might also describe the behavior of a participant in a business process. Abstract processes will usually be defined mainly for two scenarios:
To describe the behavior of a service without knowing exactly in which business process it will take part.
To define collaboration protocols among multiple parties and precisely describe the external behavior of each party.
Abstract processes are rarely used. The most common scenario is to use them as a template to define executable processes. Abstract processes can be used to replace sets of rules usually expressed in natural language, which is often ambiguous. In this book, we will first focus on executable processes and come back to abstract processes in Chapter 4.
BPEL is not the only language for business process management and modeling. Before we start discussing the technical aspects of BPEL let us overview the relation of BPEL to other languages. Recently, several languages have been proposed, including:
XLANG and the new version XLANG/s from Microsoft
BPML (Business Process Modeling Language) from BPMI.org, the Business Process Management Initiative
WSFL (Web Services Flow Language) from IBM
WSCL (Web Services Conversation Language) from HP, submitted to W3C
BPSS (Business Process Specification Schema), part of the ebXML framework
WSCI (Web Services Choreography Interface), co-developed by Sun, SAP, BEA, and Intalio and submitted to W3C
WS-CDL (Web Services Choreography Description Language), at the time of writing a W3C Working Draft
The following figure shows a timeline of the mentioned languages, as they have been developed:
We have already mentioned that BPEL represents a convergence of XLANG and WSFL. HP’s WSCL has been submitted to W3C in 2002 as a W3C Note. Since then it has not been very active and has not gained much support from the industry. In the following sections we will briefly describe ebXML BPSS, BPML, WSCI, and WS-CDL.
ebXML (Electronic Business XML) is a framework that provides a set of technologies, BPSS (Business Process Specification Schema) being one of them. ebXML has been developed under the initiative of OASIS and UN/CEFACT and consists of the following technologies:
Messaging: Uses SOAP with attachments for communication between partners
Registry and repository: Similar to UDDI registry, but offers additional functionality through the repository
Core Components: Used for construction of business documents
CPP (Collaboration Protocol Profile): Used to express a partner profile
CPA (Collaboration Protocol Agreement): Used to express an agreement between partners
BPSS (Business Process Specification Schema): Used for the specification of business processes
BPSS covers the same domain as BPEL. The BPSS approach to the process specification follows the choreography pattern and is therefore comparable to abstract BPEL processes. In addition to specifying the process logic, BPSS also specifies the communication protocol details.
BPSS is designed around the concept of business transactions, which is, however, not fully conformant with the Web Services Transactions specifications. A BPSS business transaction is used to describe message exchange between two abstract roles: the sender and the responder. Each message consists of an XML document and optional attachments, which can be XML or binary. For each responding message, we specify whether it is a positive or negative message. Each message is associated with a business transaction protocol. Collaboration in BPSS can be bilateral or multi-party and is described by the business transaction protocol.
We can see that BPSS is not a direct alternative to BPEL and is used in environments where ebXML is applied. For more information on ebXML, read the following books:
ebXML: Concepts and Application by Brian Gibb and Suresh Damodaran, John Wiley & Sons, October 21, 2002, ISBN: 0-7645-4960-X
ebXML: The New Global Standard for Doing Business over the Internet by Alan Kotok and David RR Webber, SAMS, August 23, 2001, ISBN: 0-7357-1117-8
ebXML Simplified: A Guide to the New Standard for Global E‑Commerce by Eric Chiu, John Wiley & Sons, June 15, 2002; ISBN: 0-471-20475-7
BPML (Business Process Markup Language) has been developed by BPMI.org (Business Process Management Initiative). Intalio has played an important role, and has been the initiator of BPML. BPML is a meta-language for modeling business processes and provides an abstract execution model for describing collaborations and transactions. It defines a formal model for expressing abstract and executable processes, and supports:
Data management
Conformity
Exception handling
Operation semantics
BPML can describe a process in a specific language, defined on top of the extensible BPML scheme. Business processes are defined as groups of flows (control flows, data flows, and event flows). Formatting features, security rules, and transactional contexts can also be defined. BPML offers support for synchronous and asynchronous distributed transactions and can be used for process components of existing applications.
Comparing BPML to BPEL shows that both share similar roots in web services and leverage other web services specifications, particularly WS-Security, WS-Coordination, and WS-Transactions. BPML, however, supports modeling more complex business processes through its support for advanced semantics such as nested processes and complex compensated transactions. BPML can therefore be regarded as a superset of BPEL. The extensions of BPEL with business rules, task management, human interactions, etc. are defined in BPXL (Business Process Extension Layers). The fact that both BPEL and BPML share the same idioms and have similar syntax can be a basis for possible future convergence. This is interesting because BPMI.org provides solutions for analysis and design of business processes (Business Process Modeling Notation—BPMN), a semantic model (Business Process Semantic Model—BPSM), and a query language (Business Process Query Language—BPQL). Find out more at http://www.bpmi.org/.
WSCI (Web Services Choreography Interface) version 1.0 has been developed by Sun, BEA, SAP, and Intalio. WSCI is a language for describing flows of messages exchanged by web services in the context of a process. It allows us to describe the observable behavior of a web service in a message exchange. WSCI also describes the collective message exchange among interacting web services, providing a global and message-oriented view of a process involving multiple web services.
In WSCI, message exchange is described from the viewpoint of each web service. Each exchange can be qualified by message correlations, transactions descriptions, and location capabilities. WSCI therefore describes the observable behavior of web services. However, WSCI does not address the definition of the processes driving the message exchange. It also does not address the definition of the internal behavior of each web service.
Since WSCI follows the choreography pattern and does not address defining executable business processes, it compares directly only to BPEL abstract processes. WSCI has a cleaner interface, which makes it a little easier to learn than BPEL. The WSCI specification has also been submitted to W3C, which has published it as a W3C Note. Further, W3C has formed a WS-Choreography working group, which will address the choreography of web services, but has only released the requirements specification so far.
WSCI has not gained industry support comparable to BPEL and the only company that has provided support in tools is Sun with the SunONE WSCI Editor. The industry consensus seems to support BPEL. The WSCI specification is accessible at http://www.w3.org/TR/wsci/.
WS-CDL is a language for specifying the choreography of collaborating services. It targets the composition of interoperable collaborations between services. With WS-CDL we can specify peer-to-peer collaboration of web services through the definition of their observable behavior. We can define sets of rules that define how and in what order different services should act together. Such specification provides a flexible systemic view of the process.
Its authors position WS-CDL as a complementary language to BPEL (and other business process languages). While BPEL focuses on behavior specification of a specific business partner, WS-CDL focuses on the description of message interchanges between business partners. WS-CDL provides the global model needed by BPEL processes to ensure that the behavior of endpoints is consistent across all cooperating services.
A business partner can use the WS-CDL choreography specification to verify if their internal processes have their outside behavior defined in a way that will allow them to participate in choreography. WS-CDL choreography specifications can be used to generate public interfaces, for example, specified using BPEL abstract processes. WS-CDL specifications are also useful at run time to verify the execution of message exchange between business partners.
As WS-CDL is a complementary language to BPEL we cannot make a direct comparison. However, WS-CDL differs considerably from BPEL. With WS-CDL we define the message flows exchanged by all partners, while with BPEL we focus on message flow and the behavior of a specific partner—that is on the internal behavior of a business process. The WS-CDL description of message flows is done from a general perspective, while BPEL specifies message exchange from the point of view of a specific partner. A BPEL process specifies activities that are executed. WS-CDL specifies reactive rules, which are used by all participants of a collaboration.
At the time of writing WS-CDL has been under development and has been published as a W3C Working Draft. This is why WS-CDL has not yet gained wide industry support. It is also difficult to predict how important the role of WS-CDL will be in the future. The WS-CDL specification is accessible at http://www.w3.org/TR/ws-cdl-10/.
BPEL servers provide a run-time environment for executing BPEL business processes. BPEL is strongly related to web services and to the modern software platforms that support web service development, particularly to Java Enterprise Edition and Microsoft .NET. BPEL servers leverage Java Enterprise Edition or .NET application server environments, where they can make use of the services provided by application servers, such as security, transactions, scalability, integration with databases, components such as EJBs (Enterprise Java Beans) and COM+ (Component Object Model), messaging systems such as JMS (Java Message Service) or MSMQ (Microsoft Message Queue), etc.
BPEL servers exist for Java Enterprise Edition, .NET, and other platforms. The most important commercial servers are listed below:
Oracle BPEL Process Manager (http://www.oracle.com/technology/products/ias/bpel/index.html)
Microsoft BizTalk (http://www.microsoft.com/biztalk/)
IBM WebSphere Business Integration Server Foundation (http://www.ibm.com/software/integration/wbisf)
IBM alphaWorks BPWS4J (http://www.alphaworks.ibm.com/tech/bpws4j)
BEA WebLogic Integration and the related AquaLogic (http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/weblogic/integrate/)
OpenStorm Service Orchestrator (http://www.openstorm.com/)
Active Endpoints ActiveWebflow (http://www.active-endpoints.com/products/index.html)
Sun Java Integration Suite for Java Enterprise Suite (http://www.sun.com/software/javaenterprisesystem/), formerly known as SeeBeyond eInsight Business Process Manager (http://www.seebeyond.com/software/einsight.asp)
Cape Clear Orchestration Studio (http://www.capeclear.com/products/)
OpenLink Virtuoso Universal Server (http://virtuoso.openlinksw.com/)
Parasoft BPEL Maestro (http://www.parasoft.com/jsp/products/home.jsp?product=BPEL)
Fiorano Business Integration Suite (http://www.fiorano.com/products/fesb/fioranobis.htm)
PolarLake Integration Suite (http://www.polarlake.com/en/html/products/integration/index.shtml)
Fuego BPM (http://www.fuegotech.com/fuego_software.html)
Digité Enterprise Business Process Management (http://www.digite.com/4.0/products/digite_ent_business-process.htm)
There are also a few open‑source implementations:
ActiveBPEL Engine (http://www.activebpel.org/)
FiveSight Process eXecution Engine PXE (http://www.fivesight.com/pxe.shtml)
bexee BPEL Execution Engine (http://sourceforge.net/projects/bexee)
Apache Agila (http://wiki.apache.org/agila/), formerly known as Twister (http://www.smartcomps.org/twister/)
Several BPEL design and development tools are also available. These tools enable graphical development of BPEL processes. Some design tools are bundled with servers. Provided below is a list of important stand-alone design and development tools that support BPEL:
Oracle JDeveloper 10g (http://www.oracle.com/technology/products/jdev/index.html)
Oracle BPEL Designer for Eclipse (http://www.oracle.com/technology/products/ias/bpel/index.html)
IBM WebSphere Studio Application Developer Integration Edition (http://www.ibm.com/software/integration/wsadie/)
iGrafx BPEL (http://www.igrafx.com/products/bpel/index.html)
itp Process Modeler for Microsoft Visio (http://www.itp-commerce.com/)
The following sections provide an overview of some BPEL servers.
The Oracle BPEL Process Manager 10g supports BPEL version 1.1. It provides a complete run-time environment for orchestration of web services with support for long-running transactions. The server is developed in Java and comes in three versions:
The regular version uses the Oracle 10g Application Server (Oracle Containers for Java—OC4J).
Versions for BEA WebLogic application server (with native integration with BEA Workshop) and JBOSS are available.
Manual installation and configuration is possible on top of IBM WebSphere and SunONE application servers.
In addition to the usual features Oracle BPEL Process Manager provides support for automatic passivization of processes that wait for asynchronous callbacks. This is called dehydration. Through the BPEL console, it is possible to visually monitor the execution of BPEL process definitions. It is also possible to review audit trails and track transactions. The server also provides a BPEL Debugger, which simplifies the debugging of BPEL processes considerably. An important feature is native integration with Java Enterprise Edition, which simplifies inclusion of Java Enterprise Edition resources, such as EJB (Enterprise Java Beans), JMS (Java Message Service), JCA (Java Connector Architecture), or JDBC databases, through Web Services Invocation Framework (WSIF).
Oracle also provides two graphical development tools. Oracle JDeveloper 10g provides integrated support for graphical development of BPEL processes and related WSDL and XML documents. It also provides support for direct deployment, testing, and debugging. Oracle BPEL Designer for Eclipse is an Eclipse plug-in that provides a graphical environment for the development of BPEL processes and related WSDL documents. Preview versions of all Oracle BPEL products can be downloaded from the company’s website. Chapter 5 and Chapter 6 are dedicated to Oracle BPEL Process Manager and BPEL features of JDeveloper.
Microsoft BizTalk Server 2004 and the upcoming 2006 use the Microsoft .NET framework. BizTalk is more than just a BPEL execution environment. It is an integration server product with support for integrated business processes and web services. It provides integration between messaging and orchestration as well as security. The changes in the BizTalk Server 2004 and 2006 architecture, compared to previous versions, reflect the focus on more comprehensive support for web services. One of the functions is support for BPEL version 1.1, which enables existing BizTalk processes to be exported to BPEL, or BPEL processes from other partners to be imported. Chapter 7 is dedicated to Microsoft BizTalk Server.
IBM WebSphere Business Integration Server Foundation (WBISF) is a BPEL server built on top of the IBM WebSphere Application Server. It is a Java Enterprise Edition based product, which supports BPEL version 1.1. It can be used in conjunction with WebSphere Studio Application Developer, Integration Edition, which is a graphical integrated development environment and enables visual drag-and-drop development of BPEL processes. It also provides a visual debugger.
The WBISF server provides full support for BPEL. It also provides dehydration, compensation, clustering, and versioning capabilities. It provides a built-in XSLT engine as well as integration capabilities with the Java platform, particularly through JCA (Java Connector Architecture). Through JCA we can integrate BPEL processes with CICS, IMS, and other IBM products. Other interesting features of WBISF include Business Rules Beans, which enable us to define and manage business rules in an easy way, and human workflow support, which enables us to include human interactions in BPEL processes.
IBM BPWS4J version 2.1 has been developed by alphaWorks and provides support for BPEL version 1.1. The acronym stands for the IBM Business Process Execution Language for Web Services Java Run Time and includes the run-time support for execution of BPEL processes, a BPEL validating tool, and an Eclipse plug-in with a simple editor for creating and modifying BPEL documents.
BPES4J is developed in Java and has to be deployed on top of an existing Java Enterprise Edition application server. It has been tested with IBM WebSphere Application Server and with Apache Tomcat. It provides process integration with web services and EJBs. The product can be downloaded from the IBM alphaWorks website.
ActiveBPEL engine is an open‑source BPEL implementation written in Java. It supports BPEL version 1.1. In addition to BPEL process execution the engine provides support for persistence, queues, and alarms. It runs within a Java Enterprise Edition compliant web or application server, such as Tomcat or any other commercial or open‑source Java Enterprise Edition server. ActiveBPEL is currently the only open‑source BPEL engine, which gives it a unique position, comparable to JBoss among application servers. JBoss and ActiveBPEL have even announced that they will combine their technologies to deliver a comprehensive open‑source BPEL development and deployment platform.
The ActiveBPEL engine is developed and maintained by Active Endpoints. Therefore ActiveBPEL is also the foundation for BPEL solutions developed by Active Endpoints, particularly for the ActiveWebflow BPEL Server and Designer. ActiveWebflow is a commercial business process management solution based on BPEL standard. It includes a visual designer, which is based on the Eclipse platform, and a Java Enterprise Edition server. In addition to visual design of BPEL processes, the designer offers the ability to perform visual simulations of execution scenarios. The server offers native integration with Java Enterprise Edition, particularly with EJBs and JMS.
OpenStorm provides versions of its Service Orchestrator suite for Java Enterprise Edition as well as .NET. Full lifecycle development of BPEL processes is supported. For design and development there is an integrated studio, which provides the ability to visually define XML mappings using XPath, in addition to designing the BPEL processes and corresponding WSDLs. The Java Enterprise Edition version of the server provides integration with Java Enterprise Edition technologies and the .NET version provides integration with .NET technologies. At the time of writing OpenStorm does not provide demo or preview versions of its products.
OASIS is responsible for further development of BPEL since April 2003. An OASIS Technical Committee, called WSBPEL TC, has been formed for the development of a new BPEL version, called WS-BPEL 2.0. The technical committee, which supervises and influences further development of BPEL, has many new members. This ensures that BPEL will be extended with new features and also ensures continuity of development. The number of participants involved in BPEL shows that industry support is large and still increasing. More information on WSBPEL TC can be found at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel.
WS-BPEL version 2.0 is at the time of writing in the working draft stage, without any dates announced for final release. Based on the working drafts, WS-BPEL 2.0 does not show major differences from BPEL 1.1. The concepts on which BPEL is based on will stay unchanged. Version 2.0 will, however, introduce improvements and enhancements to the language, which will make it even more powerful. There will be a few new activities for loops (such as <repeatUntil> and <forEach>), variable assignments will be simplified, and improvements will be made to fault handling, compensation, and event handling. Partner links will be improved and will enable automatic initialization. There will probably also be some minor changes in function names and a few new standard faults will be defined. At the time of writing it is not clear whether WS-BPEL 2.0 will also provide support for user interactions, a field not covered by the current BPEL specification.
We can see that WS-BPEL 2.0 will be an evolution of the current BPEL version 1.1. To upgrade business processes specified in BPEL 1.1 to version 2.0 will take only minor effort.
In this chapter, we have become familiar with the BPEL, its role in the SOA, and basic concepts related with service composition and the definition of business processes. BPEL provides a rich vocabulary for defining processes and has several features not found in programming languages. This makes BPEL the preferred choice for composition of services. Major software vendors on Java and Microsoft platforms support BPEL, and even open‑source implementations exist. Based on the comparison to other technologies and languages, we have seen that BPEL plays important role in service composition.
BPEL fits very well into the SOA, and with BPEL, we can define executable business processes and abstract business processes. Executable processes are the most important and allow us to define the exact order in which services are composed.
Note
To continue reading, you have two choices:
If you are interested in the web services technology stack, which covers WS-Addressing, WS-Security, WS-Coordination, WS-AtomicTransaction, WS-BusinessActivity, and other specifications, you should continue with Chapter 2.
If you are interested in BPEL only then you should proceed directly to Chapter 3.
