There's a common misconception that Business Process Execution Language for Web Services (BPEL) is useful only if all of your systems are Web services. This article describes how Web Services Invocation Framework (WSIF) enables BPEL to orchestrate nearly any legacy system as if it were a Web service - without having to explicitly wrap or publish it as one. It also highlights how JSR-208 will standardize this capability in the not-too-distant future.

Introduction
As Web services begin to take hold as an enterprise integration strategy, BPEL has rapidly become the undisputed standard for business process integration. BPEL provides a standard, portable language for orchestrating services into end-to-end business processes and builds upon a decade of progress in the areas of business process management, workflow, and integration technologies. Built from the ground up around XML and Web services, BPEL is supported on both the Microsoft .NET and Java platforms.

Many existing systems, however, do not currently expose Web services interfaces, and systems architects may not want to create Web services wrappers for all their legacy systems, either for performance reasons or to simplify implementations. This leaves some enterprises wondering if they can effectively use BPEL to compose business processes before they've adopted Web services (strictly defined as a SOAP envelope, a WSDL interface, and an XML data model, and usually HTTP as a protocol) throughout their IT infrastructure.

While a quick read of the BPEL specification may leave the impression that all integration components must be exposed as pure Web services, this is not true. BPEL requires you to provide a WSDL interface for services that will be incorporated into a business process - it doesn't constrain the protocol used to interface to a system. In other words, BPEL just requires that the services look like Web services.

WSIF to the Rescue
Web Services Invocation Framework (WSIF) is a flexible binding framework from Apache that lets you access back-end systems via a variety of transports, protocols, and even data models, while providing a WSDL interface to the client-in this case, the BPEL process that will invoke the service. WSIF enables a best-of-both-worlds strategy where back-end systems can be accessed through native protocols and data formats, but can still be incorporated into 100% standard BPEL processes just like full-fledged Web services. Developers can still expose or wrap legacy systems as Web services, however, and WSIF is not needed when all the systems to be orchestrated have Web services interfaces. But the capability to use the BPEL standard to orchestrate services that are not Web services lets you realize the full power of the BPEL standard - even within existing heterogeneous IT environments.

This approach is not theoretical as BPEL software from both IBM and Oracle supports it. The overall architecture is shown in Figure 1.

Let's look at a few use cases to see how WSIF is being employed in the real world:

• A Global 500 consumer packaged goods supplier wanted to be able to orchestrate requests to a large number of SAP systems using its preferred Java Connector Architecture (JCA) vendor, for which it had a source license. A WSIF binding for JCA let the supplier orchestrate SAP Business Programming Application Interfaces (BAPIs) directly from its BPEL processes.
• A prescription drug supplier had existing HTTP GET interfaces in front of mainframe batch processes and wanted to be able to include those in its BPEL flows. A custom WSIF binding to support HTTP GET requests was built. Now, the WSDL interface to this HTTP "Web service" means that standard BPEL processes can interact with the mainframe applications without requiring support for a new interface.
• A media research vendor built and supported EJB interfaces for hundreds of back-end services but did not want to wrap them in SOAP, for performance reasons and speed of implementation. Several options were considered, including using the WSIF Java binding to communicate with Java objects as if they were Web services, as well as embedding Java code directly in the BPEL process.

For any given project, a few key questions can help determine whether the best approach is a true Web service or a WSIF binding to a back-end system. These include:

• Will a Web services/SOAP interface let other clients who may not support WSIF access the service?
• Is a Web services management tool being used?
• What are the other management, administration, and performance criteria for the production environment?

A Detailed Example
Some tools support WSIF bindings, including JMS, JCA, Java, and others that developers can use out of the box. Let's look at how an SAP BAPI that provides inventory information can be integrated into a BPEL process using a JCA binding. The business process in this case is an availability-to-promise flow where a BPEL process is used to automate the response to a customer's product availability request (see Figure 2). The BPEL flow checks inventory in an SAP system, and interacts with other systems that may or may not be Web services before returning a response.

To integrate the SAP BAPI into this BPEL process, a developer would first use JCA to select and expose the BAPI. Most JCA providers provide a GUI interface by which the back-end system functions can be browsed and selected graphically.

Next, a WSDL needs to be created to define the JCA method as a WSDL operation and to specify the appropriate WSIF binding for this operation. This WSDL can be generated automatically at design time; an example of the generated operation and binding is shown in Listing 1. Note that the operation looks like any other WSDL operation and the binding specifies a built-in JCABinding (see Listing 1).

Once a WSDL exists, a BPEL process can call this service as if it were any regular Web service. For example, the BPEL process that invokes this list would set up a partnerLink for it, just like any other Web service:

<partnerLink name="sapInventory"
         partnerLinkType="ic1:inventoryServiceLT"
         partnerRole="inventoryServiceProvider"/>

And then invoke the service:

<invoke partnerLink="sapInventory"
        portType="ic1:sapInventoryService"
    operation="BAPI_MATPHYSINV_GETDETAIL"
        inputVariable="request"
        outputVariable="response"/>

Figure 3 shows the visuals for the SAP inventory service partnerLink and the iBPEL activity to invoke the SAP service/BAPI. Note that these visuals, like the use of this service in both BPEL and the design tool, are exactly the same as for SOAP Web services.

In addition to built-in WSIF bindings, it's also important to consider how much effort is required to create new WSIF bindings. For example, a single consulting engineer wrote the custom HTTP binding described in the customer use case of a prescription drug supplier in two days. Any developer who wants to use it needs only to create a WSDL describing the interface to each HTTP "service." With a few more days of work, a tool could also be created to help generate this WSDL. New bindings are registered using a simple API provided by WSIF.

Next Up: Standards for Binding (JSR-208)
WSIF is an open source framework available from Apache and is supported by several Java/J2EE BPEL vendors. However, because bindings are such a key component of business process integration, the process to create a standardized binding framework has already begun. Java Business Integration (JSR-208) proposes to standardize the ways in which J2EE assets, and therefore BPEL servers implemented on J2EE platforms, can bind to back-end systems. JSR-208 will define a standard business protocol representation that is then mapped to a specific communication protocol by a binding. In addition, JSR-208 will standardize the packaging and deployment of bindings. In this way, JSR-208 will let enterprises implement 100% standard processes, including both the process orchestration language and back-end connectivity.

Summary
As the standardization process continues, the use of flexible binding frameworks such as WSIF is likely to grow. However, WSIF already provides a de-facto standard to bind to back-end systems using native protocols and data formats, while exposing a Web service interface to a business- process client. In addition, the fact that WSIF is open source technology and is supported by the major J2EE-based BPEL vendors has already contributed to its broad adoption. By combining the WSIF binding framework with the BPEL Web service orchestration language, a 100% standard approach to business-process integration will become possible.

References
For more information