Oracle Blog´s Who needs a service bus anyway? By Milco Numan

Some time ago I was having a discussion about the setup of a SOA project on which a former colleague was about to work on. The purpose of this project was to implement a synchronous service API for a third party systems to integrate with. This API needed to conform to a B2B standard (written some ten years ago) and in their particular case, it would need to provide data from their legacy ERP system.

The API description consists of several different ‘business operations’ where their request messages come in over HTTP in a variety of predefined formats, e.g. as an HTTP GET operation where the parameters are encoded in the URL string or sending an HTTP POST operation where the request message is contained in the body: in both cases, the response is handed back as an XML message. In order not to exclude third party systems, both flavours of operations would need to be implemented.

One of the other requirements for the API was that it needed to implement an operation to list all operations that it currently supports, together with the endpoints on which these operations need to be invoked.

Restrictions

One of the current implementation of the third party systems they were looking to integrate with was quite quirky in that it required all operations to have the exact same endpoint. So, it was a tough choice to either exclude this system from the possible clients and create a ‘proper’ implementation where all operations have their own endpoints, or to provide an implementation where there’s only one endpoint that basically functions as a dispatcher for the different operations.

Summarizing:

• XML POST interface, request = XML, response = XML for all operations
• HTTP GET interface, request = None, response = XML for all operations
• Provide a single endpoint accepting all these requests at the same address

Service Bus to the rescue

As we were discussing the project and its requirements, it turned out that their internal IT department had already started development using Oracle SOA Suite, as their skills in BPEL were ‘the hammer that made this problem look like a nail’. However, my feeling was that this project would actually be much better off by the introduction of Oracle Service Bus to transform different message formats into a generic XML representation (and depending on the complexity: implement the message flows entirely in Service Bus or offload the more complicated ones to SOA Suite).

Scenario

As I am somewhat branded by my background in chemistry, I will show my proposed implementation using some ‘chemical’ webservices from WebServiceX as an example. For the backend implementation, invariably the SOAP implementation of the service will be used. For my convenience, I am reusing the XML structures that are provided by the WebserviceX implementations, saving myself the hassle of transforming the messages structurally or with respect to their namespaces.

In the following scenario, I am exposing two operations (GetAtomicNumber and GetAtomicWeight) in two different message formats:

HTTP GET: http://server:host/HttpGetAtomicNumber?RequestName=GetAtomicNumber&elementName=boron
XML POST: http://server:host/GetAtomicNumber

Furthermore, all operations will also be available at a consolidated endpoint for both request message formats, at http://server:host/OneProxyForAll

Schematic implementation

The following diagram shows a schematic representation of the desired setup; on the left hand side, you can see the exposed proxies (HTTP GET, XML POST and Generic Gateway), connected through some Service Bus flow logic with a Service Bus Business Service, exposing the actual implementation logic:

Environment

The sample project was built using Oracle’s 12.1.3 Virtual Image, downloadable from Oracle Technology Network. Read the complete article here.