Differences between BPEL and ESB

Dave Berry (ESB Product Manager @Oracle) recently brought my attention to a discussion on the Oracle SOA Suite forum: Difference between Oracle ESB and BPEL. In short, the differences are in the problems they address. Confusion arises because there are similar capabilities in both. However, BPEL is about orchestrating business logic and ESB is about highly efficient integration.

The forum discussion is worth a read as there are useful contributions on which tool is right for what job, i.e. when to use BPEL and when to use ESB.

Finding your SOA sweet spot

Quocirca is a UK based research and analysis firm that particularly focuses on the business impact of IT. In a recent article ‘SOA – Dead or Alive?‘, Clive Longbottom raises the issue faced by ISVs in selling SOA solutions. Not all SOA initiatives have to be strategic and at the enterprise level, which is where a lot of the bigger software firms are more comfortable making their pitch.

Reflecting this need for tactical SOA solutions to evolve into a strategic game plan, Oracle outlines a SOA Maturity Model which helps IT folks in these businesses to make the move to SOA. It clearly outlines how benefits can be achieved in incremental steps. There is even a useful survey tool available to help you identify the SOA profile of your own organisation. This is a great place to start understanding the business audience and to begin tailoring the messages around the benefits of SOA to the business where it is today.

Dice service working on WLS

As mentioned in a previous post the Dice service, which is my JAX-WS example for a cross platform service implementation, was not working on BEA WebLogic Servier v10. It turns out I missed a key part of JAX-WS & WLS documentation when putting the build script together. The guidelines in the WLS documentation states that the ant tasks need to have a type=”JAXWS” attribute set. Without this, WLS was treating the web service as a JAX-RPC one and that was the cause of the strange WSDL and the runtime exception.

The build-service target now looks like this:

So the only change is setting the type attribute to JAXWS. The WSDL generated for this service is identical to the one generated on Glassfish.

Generating IFX RqUID in Oracle ESB

Interactive Financial eXchange (IFX) is an XML based inter bank communication standard used by a number of banks around the world. You can find out more about IFX at the IFX Forum. An IFX message must have a request identifier called RqUID. A client uses RqUID to uniquely identify a request message. It is a universally unique ID (UUID) that is generated by the client and is used to correlate responses with requests.

Often with integration exercises the interfaces do not match. Take the simple case where one system must send a request to another system but the request structures are defined differently for both. One example is when a system sends a customer search message which must be provisioned by an IFX system. The customer search message has to be tranformed into a CustInqRq message for the IFX system. This can be facilitated through the ESB. The transformation performed by the ESB can be used to generate field values that are not supplied in the initial request.

To include an IFX RqUID using Oracle ESB you can take advantage of the XPath Extension Function orcl:generate-guid() and format it accordingly like this: 



<xsl:variable name="rquid" 
         select="orcl:format-string(
                   '{0}-{1}-{2}-{3}-{4}', 
                   substring($guid,1,8), 
                   substring($guid,9,4), 
                   substring($guid,13,4), 
                   substring($guid,17,4), 
                   substring($guid,21, 12))" />

This will create a variable called rquid with the required XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX format. You can now assign this variable to the relevant RqUID fields in the transformation. e.g.

Note: If there are mutlitple requests to be sent at the same time then redefine the variable each time it is needed. Otherwise just defined it once at the beginning of the transformation.

ESBREQUEST in Oracle ESB Routing Services

Oracle’s Enterprise Service Bus (ESB) is designed to implement service-oriented architecture (SOA) and event-driven architecture (EDA), providing a responsive, low-cost, high-impact framework for matching technology needs to business problems.

One of the powerful capabilities of Oracle’s ESB is the ‘Routing Service’ which caters for service virtualization through content based routing. It supports one way and request response operations. One of the challenges with service virtualization and the request response pattern is matching the response from the implementation service to the response that the routing service should return. There is no easy answer to this one, but the Oracle ESB provides some help. One is the transformation capabilities, but you would expect this from any ESB system. The really useful feature is being able to refer to the request in the response transformation. Oracle ESB does this by declaring a parameter to the XSLT called $ESBREQUEST.

Elements in the request can be referred to through XPATH. For example:

This is great, but there are a few things I need to draw to your attention:

  1. $ESBREQUEST refers to the root element of the request sent to the service implementation and not the request sent to the routing service. So, if your implementation service request structure is DoMethodRequest/MyParam then refer to MyParam as $ESBREQUEST/MyParam not $ESBREQUEST/DoMethodRequest/MyParam.
  2. You need to enter the XPATH manually because the mapper does not know the structure of the request.
  3. You have to specify ‘Include Request in the Reply Payload’ when defining the routing rule. This can not be added to the routing rule or XSL file through the tools afterwards.

The latter point is what I really wanted to cover in this article. At the moment, in version 10.1.3, you can not retrospectively ‘Include Request in the Reply Payload’ using the JDeveloper or the ESB console. When you use JDeveloper the first time it puts
in the XSL file and sets attachRequestPayload=”true” in the transformation element of the routingRule section of the routing service esbsvc file.

So, you can do this manually to retrospectively add ‘Include Request in the Reply Payload’ to your existing routing rules. Unfortunately the only way I have found to update the running ESB routing service routing rules with these changes is to to delete the routing service (through ESB console), shutdown JDeveloper, edit the esbsvc file manually, restart JDeveloper and then register the ESB project with the integration server.

The Oracle Mapper tool in JDeveloper which is used to edit XSL files does understand the parameter concept, so you can test your stylesheet in JDeveloper before deploying it. Just open the XSL file in JDeveloper, right click in the design view and select Test. Be sure to enter the ESBREQUEST parameter as an XML fragment. Don’t forget that ESBREQUEST corresponds to the request structure sent to the service implementation and not the request received by the routing service!

This ESBREQUEST parameter gives you the benefit of manipulating the reply such as returning correlation information or using the data from the request to perform filtering and other manipulation that the service implementation does not provide.

Should you wish to use data from the original request received by the routing service then you have to add elements manually to the request transformation. This will work at runtime if the implentation service doesn’t validate the request for extra elements not part of the schema. However, once you add these elements to the XSL transformation you will not be able to use the JDeveloper mapper as it does validate the target document structure against the schema.