Doron Sherman

Subscribe to Doron Sherman: eMailAlertsEmail Alerts
Get Doron Sherman: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal

J2EE Journal: Article

BPEL: Make Your Services Flow

BPEL: Make Your Services Flow

Until now, the options available for implementing business flows in a typical enterprise-computing environment were daunting. IT project managers had to choose between complex high-end EAI/BPM solutions and high-risk application development projects. More often than not, IT decision makers opted to do nothing and wait.

When IBM, Microsoft, and others submitted the BPEL4WS specification to OASIS, a compelling alternative to the traditional options became available. BPEL is to process orchestration what SQL was to data management. Its impact is significant; transforming application integration from a risky and expensive endeavor into a mainstream development practice. BPEL has the potential to create the foundation for new composite, Internet-scale, loosely coupled applications.

Toward Composite Business Flows
Business transactions, often run in isolation and confined to specific line-of-business applications, now require integration across different parts of the organization as well as allowing for manual intervention in support of better exception handling.

This new genre of applications is driving the emergence of an event-driven architecture (EDA) and the development of composite business flows across existing IT assets. It is inspiring renewed interest in EAI, BPM, and workflow solutions, but with radically new requirements. Unlike the stand-alone, monolithic nature of existing solutions, this genre calls for implementation of long-running business processes that coordinate flow and asynchronous conversations while allowing for effective handling of exceptions and performance of manual tasks.

Web services started as the technology answer to the need to ease connectivity to existing IT assets and enable simplified, all-XML application-to-application communication. Business agility, as well as other technical requirements such as scalability, reliability, and flexibility, drives users to assemble Web services into business processes that are themselves exposed as Web services.

An Example
Consider the following composite business flow example (see Figure 1), an availability-to-promise (ATP) application. A chemical manufacturer regularly accepts requests from customers of the form: "I want to buy 15,000 pounds of acrylic acid by September 30th." Processing time for this type of request normally spans several hours. This largely manual process tends to be prone to errors and inaccuracies caused by time latencies and the extensive involvement of humans for its completion. Slow and cumbersome processing of ATP requests often results in unsatisfactory service to customers and entices them to shop for alternative avenues. Reduction of processing time was clearly in the best interest of the chemical manufacturer.

 

In addition, the ATP process involved exception handling and mandated reporting of processing statistics to facilitate gradual on-going improvements to the process. Better management of exceptions and greater visibility to decision makers at the chemical manufacturer are important goals. Finally, the inefficient handling of the manual process resulted in high transaction costs. Being able to handle a larger volume of ATP requests, each costing less to process, will increase profitability.

Technical Challenges of Flow Implementation
Automation of the ATP process through implementation of a composite business flow raises a number of technical challenges - including data mapping - in transforming documents from one format to another to facilitate information exchange among the various applications involved, as well as present information to end users (e.g., customer and sales reps) during execution of the ATP request. Exchanging documents among end users and the various applications and services is inherently asynchronous and poses the technical challenge of handling asynchronous conversations among the cooperating parties.

Controlling proper routing of documents among the various participants also requires flow coordination. For example, an inventory levels check has to occur in parallel to production schedule verification.

The ATP process is a long-running business transaction, where some of its activities may be in need of reversal, or undo, when exceptions occur during execution. Maintaining execution integrity in the context of asynchronous conversations mandates the use of compensating transactions. Hence, cooperating services and applications taking part in the ATP process should provide undo logic to reverse the effect of actions taken during normal processing. This cancellation method is provided in lieu of a conventional atomic transaction mechanism, since resource locking is inappropriate here. Managing compensating transactions requires the use of a transaction coordinator to handle such cancellations.

Emerging Web Service Orchestration Stack
The first phase of evolution of the Web services stack (see Figure 2) focused on making IT assets available. This is the foundation of Web services use, namely publishing, which consists of: Internet-native transport protocols (e.g., HTTP, SMTP), data models based on XML structures, message exchanges over SOAP, and description of service operations and types. Adam Bosworth outlined the requirements for a basic Web services development model in "Developing Web Services" (www.w3.org/2001/03/WSWS-popa/paper53). According to Adam, Web services should support asynchronous messaging (e.g., handle unpredictable processing loads and unreliable communication channels), dynamic hardware scaling (e.g., offer dynamic load distribution and manage distributed state, alongside effective caching), and XML for integration.

 

The current phase of the evolving Web services stack is orchestration; i.e. coordinating interactions among published Web services and composing them into long-running flows. Orchestration is comprised of three pillars: asynchronous conversations, flow coordination, and exception management. In support of these pillars (explained next), and building on its foundation, the Web services stack adds:

  • WS-ReliableMessaging: To guarantee once and only-once delivery of messages
  • WS-Addressing: To define correlation semantics to properly match requests and replies in the context of asynchronous messaging; compensation semantics for undoing of actions in the case of faults, as commanded by application logic
  • BPEL4WS: An execution language for defining service composition and coordinating interactions into business flows

    Pillar 1: Asynchronous Conversations
    Support for asynchrony is essential for enabling "business quality" Web services that need to take part in integration scenarios. Asynchrony is also mandatory for allowing optimal use of "business time" (e.g., allowing for user intervention within the course of an executing business flow or deferred batch processing for better distribution of processing load). Asynchrony improves scalability by decoupling requests for service from their corresponding responses, thereby avoiding a cascade of execution bottlenecks from spreading throughout the application. Asynchrony also enables uninterrupted execution when services are temporarily unavailable and when clients are disconnected or offline.

    The basic interaction pattern involves a business flow initiating a request to an asynchronous Web service. The Web service can take an arbitrarily long time to complete its execution upon receiving a request. Once execution is completed, the service replies to the sender of the request. In order to carry out this interaction, certain information needs to be exchanged between the sender (business flow) and the receiver (async service). The sender needs to provide the receiver with a reply-to address (so that the receiver knows where to send the reply, i.e. invoke a callback once ready).

    The sender also needs to provide the receiver with a correlation ID. Post execution, the correlation ID is sent from the receiver to the sender so that the reply from the receiver can be associated with the correct originating request on the sender side. This basic pattern can be extended to a multi-step interaction when the business flow needs to invoke the service through more than one entry point or vice versa.

    The formalism for asynchronous conversations includes WS-Addressing, WS-ReliableMessaging, and BPEL Service Link. WS-Addressing specifies correlation and callback information. WS-Addressing provides transport-neutral mechanisms for addressing Web services and messages by defining XML elements to identify Web service endpoints and to secure end-to-end endpoint identification in transmitted messages.

    WS-ReliableMessaging allows messages to be delivered reliably between interacting Web services in the presence of software component, system, or network failures. Its primary goal is to create a modular mechanism for reliable message delivery. BPEL Service Link defines the callback interface.

    Pillar 2: Flow Coordination
    Business flows in real-world application scenarios may include rather complex interaction patterns (see Figure 3). The ATP process involves the chemical manufacturing company, its applications, and related service providers. The interactions between the business flow and the services include sequencing of activities as well as running such sequences in parallel and joining their execution using a join pattern. The business flow includes both synchronous as well as asynchronous invocations of services and demonstrates exception handling during its long-running execution. (See Listing 1 for the BPEL code of this example).

     

    Flow coordination is comprised of the WSDL interface, XML variables, partners, flow activities, and compensation handlers. BPEL4WS relies heavily on WSDL descriptions of the services involved in order to refer to exchanged messages, the operations being invoked, and the portTypes they belong to.

    The ATP process uses a WSDL interface to integrate, for example, into a customer portal. XML variables are containers for data exchanged between the interacting services. Partners are external services which participate in the business process. Flow activities are basic and structured commands that define the rules and sequences for interacting with each service. Flow activities will be explained later. Compensation handlers are rules for undoing parts for the business flow in case of exceptions.

    The ATP process includes XML variables such as the credit rating, production schedule, and inventory status. These variables are used for exchanging data with the partners (external services), which include a credit check mainframe application fronted by MQSeries, a production plans SAP application, and an inventory check SAP application. The XML variables are used for holding the data used for requests sent to a partner and for replies received from a partner. They are also used to store intermediate information, such as the combined planning information sent to the supplier hub.

    Compensation handlers are used within a business process, where it might be necessary to undo one of the steps that have already been successfully completed. Compensation handlers define these undo steps at the level of a predefined scope. A compensation handler contains one activity which is run when a scope needs to be compensated. Since activities can share XML variables, completing scopes with associated compensation handlers need to save a snapshot of the data when the scope is completed. This data is used by the handler in case it is invoked (e.g., upon encountering an exception at some later point in time). Compensation handlers become ready to run once the scope they're associated with is completed successfully.

    BPEL Activities
    BPEL4WS is divided into basic and structured activities. Basic activities are the simplest form of interaction with the world outside the business flow. They are not sequenced and comprise individual steps to interact with a service, manipulate the exchanged data, or handle exceptions encountered during execution.

    Structured activities define the order in which activities execute. They describe how a business process is created by composing the basic activities it performs into structures. These structures entail the control patterns, data flow, fault handling, external event handling, and coordination of message exchanges between process instances.

    The control flow is a hybrid model halway between block structured and state transitions. It uses links to establish dependencies between block definitions and put their own constraints on how activities are set to run. Links are associated with conditions based on XPath expressions that evaluate to true or false for determining if an activity is to run or terminate (a join condition). It does not have process composition (i.e., a sub-process) but does have service composition (through use of the WSDL interface of a BPEL flow).

    BPEL will drive the creation of a new generation of assembly tools that allow enterprises to implement coarse-grain processes by visually composing and tying activities and service interactions into collaborative and transactional business flows. The key benefit is developer productivity for creation of business flows but also the ability to quickly adapt to change, an essential requirement in most real-world implementations of organizations' business flows.

    Pillar #3: Exception Management
    According to some analysts, nearly 80% of the programming effort in automating business processes is spent in exception management. Therefore, exception management should be treated as an integral part of any specification for Web service orchestration. In contrast, most workflow and EAI/BPM solutions on the market today have implemented exception management as an afterthought. The notion of business transactions is helpful in the context of simplifying exception management across a network of loosely coupled asynchronous Web services.

    The basic interaction pattern (see Figure 4) is similar to the one described for asynchronous conversations (i.e., a business flow initiating a request to an asynchronous Web service). The use case here involves an exception signaled during the business flow, before the service completes its execution. In BPEL, a local fault handler associated with the Web service, is invoked subsequent to the signaled exception. In addition, the asynchronous service is notified of the exception through a cancellation request using WS-Transaction.

     

    The formalism for exception management includes the use of fault handlers and compensation handlers. Fault handlers are used when exceptions are signaled during the execution of an invoked Web service. Compensation handlers, on the other hand, reverse or undo the effect of an invocation of a Web service that completed its execution.

    Exception management also includes WS-Coordination and WS-Transaction. These specifications provide cancellation requests across a network of services to ensure coordination of interacting services in case of failures, as well as guaranteeing the integrity of the overall execution.

    BPEL Infrastructure
    The three pillars combine to form the foundation of end-to-end business processes that call for a standards-based infrastructure for deploying and managing composite business flows (see Figure 5). The core element of this infrastructure is a BPEL server that implements the various layers of the Web service orchestration standards stack and executes flow logic that is portable and can execute in any compliant BPEL server.

     

    The BPEL server supports orchestration logic provided in BPEL form for execution of business flows. Although not a mandatory requirement, a BPEL server runtime can utilize a J2EE application server for its underlying execution environment (rather than reinventing the wheel with respect to multithreading, database connection pooling, etc.). It also provides native J2EE integration by leveraging the J2EE application server runtime environment. To ensure reliability of long-running business flows involving asynchronous conversations with Web services and loosely-coupled business transactions, it uses context dehydration for executing flows. The dehydration mechanism uses a persistent store, such as a relational database, to safely store, and subsequently retrieve, flow instances.

    The second important element of the infrastructure is the BPEL console, which is designed to provide ease of management for business flows deployed to the BPEL server. It offers essential monitoring and administration facilities to developers as well as operational and business users. These facilities include testing and debugging of business flows, audit trail of flow execution in both textual and graphical form, reporting and statistics, and versioning. The last capability is particularly important for long-running flows since multiple versions of the same business flow must run in parallel at times (e.g., when a new version phases in and an old version phases out).

    The BPEL infrastructure should be equipped with strong support for integration. Integration capabilities are conveniently expressed through connectors that plug into the BPEL server. These connectors should support both synchronous and asynchronous interactions. Common connectors needed for enterprise computing environments include XML Web services, Java/J2EE, .NET, JMS, e-mail, and portal infrastructure (for user interaction). Such connectors should be transparent to flow logic developers and have no effect upon the portability of the BPEL code.

    Conclusion
    BPEL, a standard process flow grammar, provides a new foundation for integration. It empowers developers to tie transactional services, events, and user tasks into easy-to-adapt business flows. This new genre of process-driven applications moves enterprises closer to the realization of the agile real-time enterprise.

  • More Stories By Doron Sherman

    Doron Sherman is the CTO of Collaxa, Inc., a Web Service Orchestration Server vendor and a BEA Partner located in Redwood Shores, California. He has been involved with Java since its early days and pioneered application server technology while being a founder and chief scientist at NetDynamics.

    Comments (3) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    Most Recent Comments
    Doron Sherman 10/28/03 01:50:03 PM EST

    Rahul,

    Weblogic Integration suite (WLI 8.1) and Websphere MQSeries Integrator provide graphical environments for integrating Webservices into flows, though they utilize pre-BPEL models for encoding processes. It is expected that some of these solutions will migrate to BPEL in the future. As you've indicated, Collaxa tools and server are built from the ground up on BPEL.

    Doron Sherman 10/28/03 01:35:10 PM EST

    Rahul,

    At the moment, commercial implementations of the BPEL specification (aka BPEL orchestration servers) are available on both J2EE and Dot-Net platforms. Dot-Net solutions include Microsoft BizTalk 2004 (beta) and OpenStorm ChoreoServer. J2EE solutions include IBM WebSphere and Collaxa BPEL Server.

    BPEL servers leverage J2EE app servers run-time environments, benefiting from the optimized thread pooling and other existing optimizations, rather than re-inventing the wheel. Choice of app server is useful if cost, for example, is an issue. Collaxa, for example, bundles the open source JBoss app server.

    If your goal is to integrate Java apps and Web services into the flow, it is prudent to examine the binding capabilities supported by the BPEL server, unless the Java apps already expose Web service interfaces.

    rahul 10/28/03 07:44:39 AM EST

    Hi,
    Its a very informative article. Thanks. I had a few questions:
    1) Can you let me know the BPEL Servers available in the market. Do these need to be integrated with J2EE appservers or can they run as is if all I want to do is integrate a few Java applications and webservices to the flow.
    2) How powerful are Weblogic Integration suite and Websphere MQSeries Integrator for integrating Webservices using BPEL. Also how easy is it to develop this kind of flow. Collaxa has a more pure BPEL product that seems easier for the above task.

    Thanks in Advance,
    Regards,
    Rahul