Welcome!

SOA & WOA Authors: Liz McMillan, Elizabeth White, Yeshim Deniz, Pat Romanski, Adine Deford

Related Topics: SOA & WOA, XML

SOA & WOA: Article

Process-Centric Realization of SOA

BPEL Moves Into the Limelight

Agile and adaptive business processes and supporting IT infrastructure are the holy grail of enterprise applications. The industry is heading in the right direction to start delivering on this promise. SOAs (service-oriented architectures) promise to enable businesses to align their business processes to customer needs, and optimize them to improve customer responsiveness and drive efficiency. A process-oriented realization of SOAs is necessary to deliver on this promise.

The process-oriented model is based on an SOA component model augmented with an underlying formal model in which business processes are expressed through orchestration and choreography. This model blends the bottom-up framework of SOA with a top-down, process-centric view. By simplifying the set of activities that are part of the life cycle of business processes, we'll outline how this approach is an effective and efficient way to develop, maintain, and improve best-in-class inter- and intra-enterprise business processes. We'll also emphasize that enterprises looking to automate their business processes around an agile platform can start building, service-enabling, deploying, securing, and managing services - both internal and external - with Business Process Execution Language for Web Services (BPEL4WS or BPEL) business flows today.

The SOA Promise
Traditionally, business information systems have been developed with a functional orientation, often resulting in silos of services and information. However, end-to-end business processes that must span silos can't adapt to change as business needs evolve - they're fragmented and embedded deep within systems. SOA is a software architecture that facilitates the development of enterprise applications as modular and loosely coupled business services.

SOA's intent is to integrate software components, or services, in new runtime contexts and business processes. It creates a unification layer on which business processes and enterprise dashboards can be built. SOA promises to deliver greater responsiveness to business change and provide real-time visibility into business processes. When effectively implemented, it improves business agility by letting you modularize legacy, packaged, and custom applications, and orchestrate them in easily changeable business flows.

The Web services platform, including SOAP and other protocols accessed through Web services binding frameworks, acts as the component model and ubiquitous network fabric through which newly built and existing applications cooperate. Information can be exchanged much more seamlessly, unconstrained by the hardware, operating systems platforms, and programming languages used to implement services.

Whereas a Web services model and SOA often take an essentially bottom-up view, business processes are inherently top-down activities. Bridging the capabilities envisioned by SOA with the requirements of supporting distributed business processes - including trading partner collaborations - is the focus of the process-oriented realization of SOA discussed here.

SOA Realization
The process-centric realization of SOA can provide the glue between modular business services for the end-to-end business processes that companies rely on, such as order-to-cash, procure-to-pay, store order-to-sales compensation, and supplier-invoice to settlement. To complete this picture you must define all forms of business processes, including those of a collaborative nature, and deliver these processes reliably so that they, in turn, can be leveraged by other business processes and services (see Figure 1)

Today, mature standards such as BPEL and Web services effectively enable businesses to implement private processes and collaborative processes based on ad hoc collaboration definitions. The process-centric model of SOA considers processes and collaborations as first-class citizens, much as an object-oriented language would consider objects as first-class citizens, and encourages the same maturity of global standards for the definition of B2B processes. With this vision, business processes, collaborations, information exchanges, and work activities are expressed through service aggregation - a combination of BPEL orchestration and WS-CDL choreography, with operational semantics based on the pi-calculus:

  • BPEL orchestration is concerned with process-flow coordination and implements the behavior of a single participant/ business entity. For example, consider an order-to-cash that implements a business process that handles orders. Orchestration defines the execution logic of application components. Typically, a controller executes a definition of the business process. Standards have tackled process-flow coordination over the years, with the most recent industry consensus occurring around Web services orchestration standards like BPEL. BPEL is used to define the coordination of a process flow as well as related semantics, including parallelism, sophisticated exception handling, data transformation, and transaction compensation facilities.

  • WS-CDL choreography is concerned with multiparticipant collaborations, such as the Order Fulfillment collaboration between a buyer and a seller. The Web Services Choreography Description Language (WS-CDL) standard is emerging as a way to specify contracts of interoperable business processes collaborating to accomplish a common business goal. Examples of the business protocols that can be easily modeled using WS-CDL are the FIX and TWIST financial protocols and the RosettaNet PIPs. Choreography is built on top of BPEL. BPEL and WS-CDL together can express any business process, including trading partner interactions.

    In order to deliver quality of service to enterprise-class business processes a number of supporting services are required. With quality of service, a number of supporting services are required. These include security, reliable messaging, transactions, context and coordination, message translation and transformation services, message validation, and content-based routing. Although these services are vital for the vision of networked-enabled business processes, we'll focus on the service aggregation/business process aspects.

    BPEL: Automating Business Processes
    In the SOA architecture, and within the Web services platform in particular, services must be combined into business processes/business flows. BPEL provides a standard, portable language for coordinating the flow of business process services and builds upon a decade of progress in the areas of business process management, workflow, and integration technologies. Traditionally, such technologies have suffered from proprietary business processes definitions; the resulting applications are seldom portable across implementations, and skills are not transferable. Since BPEL is a standard, it creates a common language for developers. It's built from the ground up around XML and Web services and is supported on both the .NET and Java platforms.

    Asynchrony, parallelism, sophisticated exception handling, long-running processes, and a need for compensating transactions change the fundamental nature of what we think of as an application. In order to support the required executable behavior, BPEL provides constructs for control-flow (conditionals, sequencing, parallelism, loops), variables, and constructs for manipulating them; event handlers, timeouts, exceptions, and forward recovery; and nested scoping units of work.

    The process-oriented realization of BPEL also adds the following capabilities on top of standard BPEL:

    • Advanced data handling and transformation activities that are used to manipulate variables using XQuery
    • Advanced process life-cycle management capabilities such as versioning, Suspend Process instance, and Resume Process instance
    • Activities that use a business rules framework, which lets you model business rules in a purely declarative way
    • Advanced human workflow activities such as assigning tasks to specific users, sending notifications, and approving requests through mechanisms such as task lists
    BPEL provides the basis for implementing enterprise-wide business processes by combining existing business applications, custom applications, packaged applications, non-native services, and partner services into end-to-end business flows.

    WS-CDL: Collaborations Between Peer-to-Peer Business Processes
    In complex integration scenarios, capturing the collaborations between two or more business processes engaging in peer-to-peer business transactions, potentially across trust boundaries, requires a higher-level model. This is the fundamental thrust of WS-CDL, which is based on a variant of pi-calculus. It enables the formal modeling of the common observable behavior of all collaborating participants from a global viewpoint.

    WS-CDL describes the global message exchange of participants during their joint interaction, global reactive rules for declaratively prescribing normal/abnormal progress, common agreement of the outcomes, and a recursive composition model that lets you build choreographies incrementally by combining existing choreographies. In this way, complex inter-organization business processes can be implemented as a collection of services, which, in turn, implement complex business processes themselves.

    Choreography perfectly complements the effort of orchestration and BPEL, offering a global viewpoint into the peer-to-peer interacting business processes that are defined and implemented in BPEL.

    To understand how orchestration and choreography come together, let's consider an example.

    Case Study: Order Management Business Process
    For any business interaction to work, the rules of collaboration must first be agreed upon. These rules can be represented in English. However, since English is unstructured and frequently vague, the rules may not be represented precisely. Choreography, and WS-CDL in particular, lets us write the above rules in a precise and unambiguous manner. So how do orchestration and choreography fit into the larger picture? The case study below demonstrates their complementary role by presenting the example of a localized business process that's concerned with handling purchase orders in a really big corporation (RBC).

    This business process leverages several trading partners and links to a range of back-end services and legacy applications into an end-to-end business process. As Figure 2 shows, the RBC process interacts with different applications such as J2EE, .NET, portals, human workflow, ERP financials, trading partners such as subcontractors, and rules engine interfaces.

    What makes this process interesting is that it requires both the integration of existing applications and new functionality. In our example, a clerk takes an action that causes a PO to be sent out. This is logged against a custom application (which could be J2EE or .NET) that registers the PO and ensures that the total amount does not violate the employee's sign-off authority level. If management approval is required, a workflow is initiated.

    Upon confirmation, the PO needs to kick off a number of business processes, including one that updates the total POs that have been approved by the employee and manager, and one that checks the availability of goods from an existing warehouse or nearby distribution center and requisitions them if they're not available. If the goods aren't available at any location, then the system updates the financials application.

    Notice that in this case, the overall business process is implemented in BPEL. Each of the services can publish a Web service interface that is then orchestrated in BPEL. Using SOAP, WSDL, XML Schema, and BPEL, the business process can be built in a vendor-independent fashion. RBC's business process is shown in Figure 2.

    Using BPEL and other open standards, the task of integrating these systems into an end-to-end business process is straightforward. At any stage, the business process may be changed; for example, by adding extra approval steps, or by updating the BPEL definition of the business process.

    Now consider what's needed when the RBC order process interacts with an outside supplier, STC, which manufactures and distributes t-shirts. RBC and STC are engaged in a collaborative fashion to achieve their common business goal: order fulfillment. For the collaboration to work successfully, RBC must provide the terms under which it's willing to do electronic business with suppliers such as STC.

    RBC has the following simple business rules for collaborating with STC:

    1. RBC places an order for STC t-shirts.
    2. STC acknowledges the purchase order. This initiates a business process in STC that handles the PO. For all RBC knows, STC has an employee at a computer handle the PO, or a sophisticated BPEL process that's linked with back-end manufacturing, logistics, and procurement systems.
    3. After the internal processes within STC regarding the PO are completed - which may take days or even months - STC sends a Purchase Order Completed message back to RBC.
    4. RBC can send a Cancel Order message any time before it receives the Purchase Order Completed message.
    5. If the Cancel Order message arrives at STC before the Purchase Order Completed message is sent, STC aborts its business process and acknowledges this to RBC with the Purchase Order CancelAck message.
    6. If STC has already sent the Purchase Order Completed message, it ignores the Cancel Order message because RBC has agreed that it will honor POs when cancellations are not sent out within an agreed-upon timeframe.
    Based on these business rules of collaboration, the two parties also agree to the following rules of how they exchange messages:
    1. When a PurchaseOrder message is sent from the buyer to the seller and the acknowledgement is received by the buyer, the OrderStatus at both parties is set to New.
    2. When the OrderStatus at both the buyer and seller is New, either a Cancel Purchase Order Message can be sent by the buyer to the seller or a Complete Purchase Order Message can be sent by the seller to the buyer.
    3. When the buyer sends a Cancel Purchase OrderCancel message, the buyer sets itself to CancelPending; when a CancelAck message is sent from the seller to the buyer, this sets both parties to OrderCancelled.
    4. When the seller sends an OrderCompleted message, the OrderStatus at both parties is set to OrderCompleted.
    These terms form the basis of the choreography. The resulting choreography is shown in Figure 3.

    Today, these rules are frequently described in English, and each trading partner's business processes that interact collaboratively can be defined in BPEL or in any other language. What WS-CDL offers is a standardized way to define these interactions, leaving unambiguous documentation of the roles and responsibilities of each. Also, in the future, products that support business process implementation languages such as BPEL could provide tools that would generate, for example, an implementation skeleton for a particular role or validate behavior. Developers looking to define collaborations in B2B situations should keep an eye on WS-CDL. Today, however, BPEL provides the basis for automating business processes on both sides of the firewall.

    Summary
    The maximum value of SOA architecture is realized by blending SOA with a process-centric view that explicitly defines trading partner collaborations. The basic building blocks to do this are already in place and standards like WS-CDL are emerging to support the full life cycle of collaborative business processes.

    Enterprises looking to automate their business processes around an agile platform can build, service-enable, deploy, secure, and manage services (both internal and external) with BPEL business flows today. Looking further down the road, we expect the ways that business-to-business collaborations can be defined will be greatly enhanced through standards such as Web services choreography and we're actively working in these areas. What's clear today is that there is much value to be gained by streamlining your business around SOA with a process-centric view. Go build!

    References

  • Regarding BPEL engines and the code examples in this article, see: http://otn.oracle.com/bpel
  • More Stories By Hal Hilderbrad

    Hal Hilderbrad is a Web services architect at Oracle working in the Oracle Application Server core infrastructure group.

    More Stories By Nickolaos Kavantzas

    Nickolaos Kavantzas is a Web services architect at Oracle working in the Oracle Application Server core infrastructure group. He is the architect of the Web Services Choreography Language and the lead editor of the Web Services Choreography Language in the W3C Choreography Working Group. Currently, he is designing Oracle's Web Services Orchestration/Choreography framework.

    More Stories By Ashwini Surpur

    Ashwini Surpur is a principal member, technical staff working on Web Services Choreography at Oracle.

    More Stories By Mohamad Afshar

    Mohamad Afshar, PhD, is VP of Product Management at Oracle. He has product management responsibilities for Oracle's middleware portfolio and is part of the team driving Oracle's investments in SOA on Application Grid - which brings together SOA and data grid technologies to ensure predictable low latency for SOA applications. Prior to joining Oracle, he founded Apama, a complex event processing vendor acquired by Progress Software. He has a PhD in Parallel Systems from Cambridge University, where he built a system for processing massive data sets using a MapReduce framework.

    More Stories By Dave Shaffer

    Dave Shaffer has been helping customers use the Oracle BPEL Process Manager since 2001, managing implementation projects, providing technical training, and ensuring successful implementations. Prior to joining Oracle, Shaffer was a principal consultant at Collaxa, a managing director at Eleven Acceleration, and manager of a professional services group at Apple Computer.

    Comments (0)

    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.