Enabling a Dynamic, Reusable SOA with Oracle BPEL Process Manager and Oracle Service Registry

by Clemens Utschig , Oracle SOA Suite Product Management

Published November 2006

In another technical note, we demonstrated how to virtualize services by using the Enterprise Service Bus. In this installment, we will introduce another component: the Oracle Service Registry (OSR).

Here you will learn how tightly coupled BPEL processes can be loosened without a decrease of performance, while at the same time creating a repository of reusable, discoverable artifacts that benefits the organization.

Setup

The sample scenario consists of two BPEL processes: a master process (MasterProcess) that calls another process named CalleeProcess. In general, when building this scenario, the master process is tightly coupled to its services by referencing its concrete, bound definitions (WSDLs).

Once a BPEL process is created, the author has already decided which messaging pattern it provides. Either it is asynchronous or synchronous, depending on its operations.

Consider the following definition of the CalleeProcess.

In the above case the service interface of the process provides one operation called "process", which defines an input (CalleeProcessRequestMessage) and an output (CalleeProcessResponseMessage) message within it.

At this point, the BPEL process does not contain any information about where it can be found or on the technology that can be used to invoke it.

After deploying the BPEL process to the server, the WSDL interface will get an implementation and a physical endpoint will be added. At this point its definition morphs from abstract to concrete.

Now that the process (CalleeProcess) has become a service, it can be reused from another process by taking its concrete WSDL location and basing a partnerlink on it.

When successfully deployed, the MasterProcess can be invoked. This will trigger the execution of the CalleeProcess, and its communication is handled entirely in memory.

Decoupling the Binding of the Service From the BPEL Process

Now that the stage is set, the first step toward a loosely coupled system is to decouple the implementation from the definition of the CalleeProcess, which is called from the MasterProcess.

Applying this pattern to the BPEL process provides significant flexibility, as the implementation of a specific service usedcan change without requiring changes to the process itself.

In this step the concrete service definition will be registered with the OSR and as a result become discoverable across the enterprise.

In accordance with the UDDI data model, a service is a detail within a Business, which allows grouping by usage. (NOTE: There's no connection between Business and visibility.)

A service definition—in this case, the one for the CalleeProcess—can be added by simply publishing a WSDL under a UDDI business entity as shown below.

For now, the only thing that can be discovered through the Service Registry's UI is the physical endpoint, which needs to be called to invoke the service. To enable dynamic binding independent of technology and implementation, a new binding may be added. This binding, of type wsdlDeployment, will be used by the BPEL engine at runtime.

As described in "Leveraging BPEL uses ESB to Virtualize Service Enpoints," a partnerlink can contain specific properties, modifying or enhancing its runtime behavior. In this case the flag is named registryServiceKey, a unique UDDI identifier that enables the BPEL server to discover a concrete service definition in the OSR at runtime.

The only information left to enable the lookup is to configure the BPEL server with the information where the target OSR instance is located (uddiLocation), and if secured, a username (uddiUsername) and a password (uddiPassword).

What is the value of applying these changes? The process is now decoupled from the physical implementation of the service, and is able to query the OSR instance to retrieve and invoke the endpoint at runtime. This means the service can move due to hardware or software changes without having to modify the process configuration, as all information is stored in the Service Registry.

The last step is to take the concrete WSDL, the partnerlink refers to out of the picture. It's important to know that the BPEL compiler (bpelc) needs information about the operation and the types to ensure type integrity before deployment. But there is no need to supply any binding information.

This means that instead of supplying the concrete WSDL to the process, the abstract WSDL will instead be used. Another look into the descriptor of the process reveals its location.

Recompiling and deploying the process reveals the loosely coupling that we wanted to achieve.

The process does not contain any information about technology used to implement the service, nor its endpoint.

Conclusion

While at the beginning the MasterProcess knew the technology, and the location of the process it called (CalleeProcess), here you learned how easy it is to enable dynamic binding and administrate endpoints and properties completely outside of the business process.

This critical information now resides within a searchable, UDDI v3 compliant registry—and can be discovered at runtime, to allow the process a maximum of flexibility. Although another component came into the picture, the performance between the consumer and the provider has not dropped much, due to sophisticated in-memory lookup for the registry as well as the endpoint invocation.

Clemens Utschig [blog] works within the Oracle SOA Product Management Team responsible for security aspects and cross-product integration. Aside from technology, Clemens' focus is on project management and consulting aspects coming along with SOA implementations. As a native Austrian, Clemens' Oracle career started in Europe at the local consulting services branch working with customers on J2EE and SOA projects, where he also founded the local Java community. He is a frequent speaker at conferences evangelizing either on technology or the human factor—two key aspects when introducing new concepts and shifts in corporate IT strategy.