As Published In November/December 2004

Integration Imperative
By Rich Schwerin

Business Process Execution Language (BPEL) speaks services.

Few, if any, of today's business applications work in isolation. From the moment a sales rep engages a customer to the moment the account is paid and the order fulfilled, numerous heterogeneous applications and services combine behind the scenes to create business processes. Integrating today's heterogeneous applications, activities, events, and services into these end-to-end business processes is a big challenge.

Providing a common standard for this integration challenge is key. Focusing this standard on transactional business processes requires describing how transactions will occur and in what order.

Business Process Execution Language (BPEL) provides a common language for business applications and services. BPEL is the new standard for integrating heterogeneous applications and services into transactional business processes.

"BPEL is a workflow and process flow language, so if you have a number of steps that you need to compose together to form a business process, BPEL is the language you'll use to describe how things should occur and in what sequence," explains Dave Shaffer, an Oracle business consultant and BPEL expert. "One misconception to dispel: You don't need to have Web services everywhere for BPEL to be useful. It allows you to communicate with many different kinds of back-end systems through native protocols."

Before BPEL

"Before BPEL, there were various enterprise application integration (EAI) technologies and proprietary business process management (BPM) technologies," explains Shaffer. "People were able to build connected applications, but it was expensive, complex, and proprietary."

In December 2000, Microsoft published XLANG, an XML business process language used in Microsoft BizTalk Server for orchestrating applications and XML Web services. Three months later, IBM published Web Services Flow Language (WSFL), an XML language for the description of Web services as part of a business process definition. IBM designed WSFL to be part of the Web service technology framework, relying on existing standard specifications such as SOAP, UDDI, WSDL, and XMLP.

In August 2002, IBM, Microsoft, and BEA released the first public draft of the Business Process Execution Language for Web Services (BPEL4WS) specification, which combined the ideas of the WSFL and XLANG specifications. In April 2003, the Organization for the Advancement of Structured Information Standards (OASIS) issued a call for participation in the BPEL technical committee. In May 2003, Sun and Oracle announced support for BPEL.

BPEL Features

BPEL specifies business process behavior based on Web services. BPEL processes export and import functionality by using Web services interfaces exclusively. BPEL fits into the core Web service architecture built atop UDDI, WSDL, XML, and XML Schema.

"BPEL is a lightweight standard language that eases the orchestration of Web services," says Shaffer. "It is layered on top of Web services and XML and different component building blocks. Most people are already working in SOAP, WSDL, XML, and XML Schema, and most companies are already moving toward XML-based integration. So BPEL is on the right highway for developers."

Three Keys to BPEL

Three keys constitute the foundation of BPEL: asynchrony, flow coordination, and exception management. All relate to issues facing developers tasked with orchestrating integration.

Asynchrony. Asynchrony deals with asynchronous interactions, message correlation, and reliability. Asynchrony support is necessary to enable Web services in integration scenarios and is mandatory for optimal use of business time (allowing for user intervention during the course of a business flow or deferred batch processing for better processing distribution). By decoupling service requests from their corresponding responses, asynchrony improves scalability and avoids application execution bottlenecks. It also enables uninterrupted execution when services are temporarily unavailable and when clients are offline or disconnected.

Flow coordination. Flow coordination includes parallel flow of execution, join patterns, and dynamic flow. In real-world applications, business flows might include complex interaction patterns with both synchronous and asynchronous services. Flow coordination includes a WSDL interface, flow activities, XML variables, and handles for compensation. BPEL relies on WSDL to refer to exchanged messages, invoked operations, and port types. Flow activities share XML variables, so compensation handlers must save snapshots of data that can be used by the handler. Compensation handlers can undo steps that have already been completed.

BPEL includes basic and structured activities. Basic activities comprise individual steps to interact with a service, manipulate exchanged data, or handle exceptions encountered during execution. Structured activities define the execution sequence and describe process creation by assembling the activities it performs into structures; these structures include data flow, control patterns, external event handling, fault handling, and message coordination.

Exception management. Exception management handles synchronous faults, asynchronous exception management, and compensating business transactions. For automating business processes, a lot of effort is focused on exception management, and BPEL simplifies exception management for Web services. Local fault handlers associated with Web services are invoked when exceptions are thrown, and the asynchronous service is notified of the exception.

From Services to Processes

BPEL defines the constructs necessary to compose a set of services into collaborative and transactional business processes. "BPEL defines how to send XML messages to remote services, manipulate XML data structures, and receive XML messages asynchronously from remote services," notes Shaffer. "It also lets you manage events and exceptions, define parallel sequences of execution, and undo parts of processes when exceptions occur."

With BPEL, typical business processes can be described as executable business processes, which model actual behavior of a participant in a business interaction, and as business protocols, which use process descriptions that specify the mutually visible message exchange behavior of each of the parties involved in the protocol, without revealing their internal behavior. Descriptions for business protocols are called abstract processes. BPEL models the behavior of both executable and abstract processes.

Beyond BPEL

There are some things BPEL doesn't address, including complex transformations, data translation, trading partner agreements, manual (human) processes, and bindings to specific back-end systems, explains Shaffer, who adds that BPEL isn't trying to be all things to all people.

"BPEL doesn't encompass complex transformations, but products that support BPEL support certain XQueries, so you can tie things together as a service," explains Shaffer. "BPEL has some simple transformations, but for XQuery or XSLT for complex transformations, you'd have to do those separately and integrate them in."

Shaffer adds that BPEL doesn't have the concept of a manual process, but it has key support for asynchronous services and manual tasks; manual tasks are easily supported as a service.

Next Steps READ more about BPEL Oracle BPEL Process Manager oracle.com/technology/bpel oracle.com/technology/products/ias/bpel/htdocs/dev_support.html OASIS BPEL Committee Business Process Execution Language for Web Services (BPEL4WS) DOWNLOAD Oracle BPEL Process Manager

Serving BPEL Support

The OASIS Web Services Business Process Execution Language (WSBPEL) technical committee is working to advance BPEL, and it includes BEA Systems, Commerce One, EDS, IBM, Microsoft, NEC, Novell, Oracle, SAP, Siebel Systems, Sybase, Tibco, and Vignette.

The current BPEL specification under OASIS consideration is 1.1, and it is scheduled to be finalized by the end of 2004. Meanwhile, BPEL server products such as Oracle BPEL Process Manager are shipping today.

Oracle BPEL Process Manager

Oracle BPEL Process Manager is a scalable, BPEL-based orchestration server with support for modeling, connecting, deploying, and managing BPEL processes; it is available both as a standalone product and as an option for Oracle Application Server 10g Enterprise Edition. In addition to BPEL, Oracle Application Server 10g supports SOAP, WSDL, WS-Coordination, WS-Transaction, and XML, all of which let applications flexibly find each other and seamlessly interact in a platform-independent model.

"The core business issue with BPEL is integration," explains Rob Cheng, product director of Oracle Application Server 10g. "The goal of BPEL is to find an easier, more flexible, more lightweight way to address integration problems—not only for connecting legacy applications but also for building more- modular applications in the future.

"BPEL defines how services are orchestrated and choreographed together, and being able to compose things together in process flows and application flows across heterogeneous architectures—regardless of the underlying hardware, programming language, or operating system—is where Oracle's BPEL server excels," says Cheng. "We've got the only production BPEL engine that handles BPEL natively, so it's richer, faster, easier to learn, and more extensible than proprietary alternatives."