As Published In July/August 2004

Weaving Web Services Together
By Mike Lehmann

Business Process Execution Language streamlines connecting and coordinating Web services.

In previous columns, I have looked at Web services from the perspective of a single Web service. I showed how to create a Web service by using the J2EE Web services API, JAX-RPC, and I gave use cases where a Web services management solution could naturally work together with those JAX-RPC Web services. Through these examples, it was easy to see that there is business value to be gained from individual Web services, but the real justification for most people comes from the ability to integrate multiple Web services into larger applications—often called composite applications or, even more interestingly, business processes.

In the next few articles, I will tackle weaving together several Web services into a business process. The standard I will be using is Business Process Execution Language (BPEL). BPEL is the XML standard that Oracle, BEA, IBM, Microsoft, and other vendors are aggressively working on as a mechanism for orchestrating Web-services-based end-to-end business processes. Although it is still in the standards process at OASIS, the specification is mature enough that product implementations are already available from vendors such as Oracle.

Integrated BPEL Server Oracle recently acquired the leading company in the BPEL server space, Collaxa, and has integrated its offering into Oracle Application Server. This acquisition, branded the Oracle Application Server BPEL Process Manager, complements the existing integration services available within Oracle Application Server, including data integration, data translation, data transformation, business activity monitoring, and support for business-to-business (B2B) protocols. Available immediately, the Oracle Application Server BPEL Process Manager consists of a high-performance BPEL 1.1-compliant runtime environment, a BPEL process management and monitoring console, and an easy-to-use BPEL designer. With this acquisition, Oracle becomes the first technology vendor to offer a fully Web-services-standards-based business process integration solution for service-oriented architectures.

Why BPEL?

Often the first reaction developers have when they hear about BPEL is a question: Why do I need a standard to solve something that could likely be done programmatically? Obviously there is nothing forcing a developer to use BPEL, and a developer can create a simple business process that first calls one Web service and then takes the result and calls another Web service.

But things get more intriguing when you look under the covers of a typical long-running business process. A number of perplexing issues come up:

• How does one handle asynchronous Web service invocations where the called Web service is long-running and has to call back at a later time into the originating Web service?
• How does one correlate requests across many in-flight business processes?
• How does one invoke Web services in parallel rather than in sequence?
• How does one undo a long-running transaction in which there has been a failure?
• How does one compose larger business processes out of smaller business processes?
• How does one guarantee reliable message delivery?

The list goes on and on. And, interestingly, not only have developers tried to solve these issues many times before but there are also a myriad of proprietary process engines that have tackled the problem space. Invariably, each has solved it differently and each has frequently required organizations to lock themselves into specific vendors and nonstandard programming languages.

BPEL is targeted at this problem. Not only does it take into account this history of process language and engine research and development through broad vendor participation but it has also broken with the past by building on the emerging foundation of Web service standards.

With this standards-based foundation, an eye to portability, pragmatism from previous efforts, and academic pedigree, many—including Oracle—believe that BPEL will be the cornerstone of service-oriented architecture implementations.

A Loan Example

Let's start by digging into an example. My goal with this simple business process is to determine what interest rate a prospective loan customer qualifies for when several banks' loan services are queried with his loan requirements.

Figure 1 provides the initial steps necessary to complete the loan process. I will first walk you through the process flow, emphasizing some key BPEL language constructs, and then follow by showing snippets of the actual process language. (The example shown here is downloadable from OTN.) This process flow will focus on the process language syntax rather than on how such a process would interact with an end user.

Figure 1: Initial steps for a loan

Listing 1 provides a listing of the United Loan and American Loan <partnerLinks> and the <variables> expected by these Web services. These constructs are created in the Oracle BPEL Designer at the start of the design exercise before the process itself is written.

Other higher-level constructs, such as global error handlers, called <faultHandlers>, and global transaction failure handlers, called <compensationHandlers>, are also declared in this first section.

Process definition. The second part of a BPEL process contains the process logic—the steps that will be followed and which Web services will be woven together to do something useful. In simple terms, there are two types of activities:

1. Primitive process and data activities for calling and receiving calls from Web services, such as <invoke>, <receive>, and <reply>; activities for controlling the process, such as <wait> and <terminate>; and last, activities for manipulating data, such as <assign>.
2. Structured activities for simple programmatic control over which steps will be executed in a business process, including <case> statements, <while> loops, parallelism constructs such as <flow>, and sequential constructs such as <sequence>.

Listing 2 provides the code behind the invocation of the United Loan Service and American Loan Service. For each bank call, the <invoke> and <receive> are within a sequence, forcing them to run one after another. But the two <sequence> activities are themselves within a <flow> activity, enabling these two subsequences for each loan service to run in parallel.

Next Steps LEARN more about BPEL DOWNLOAD the samples in this article

Conclusion

It doesn't take long to realize the power of standardizing how Web-services-based business processes are created. Not only is the basic process functionality immediately useful within any service-oriented architecture but it also builds upon a standards-based foundation that has unprecedented buy-in across the industry.

An analogy is that of SQL and J2EE—standards that, once accepted, created entire markets for servers, tools, and services. No longer were technology vendors trying to solve the basic problems of querying data and building business logic; instead, they were innovating around a standards-based framework.

BPEL is on the cusp of unleashing the same opportunity for business process integration. In future columns, I will explore further how BPEL processes are built, managed, and run.