Generic Rest Gateway in Oracle Service Bus (OSB)

Generic REST Gateway

Having built up an enterprise with primarily SOAP services, from time to time, one encounters lightweight client systems that require a simple HTTP (REST) based interface to those existing services. The options were either to add another class of “Adapter” services that converted one-to-one REST-to-SOAP for the existing services, to keep the canonical pattern (SOAP interfaces in this case) and find some kind of application to do the translation. There are quite a few out there, but this is not the place to advertise their services/products.

This is an “insight” post; it aims to stimulate discussion around the subject it discusses; these articles may appear prescriptive and perhaps dogmatic, but the objective really is for debate that leads to reusable knowledge and that is accessible to the wider community of software engineers in the area of focus.

Below is a diagram that illustrates the simple design for this service.

REST Gateway Sequence Diagram
Generic REST Gatewau

The simple approach that we have adopted at my present client is to create a generic REST gateway, since these lightweight clients do not impose any unique use cases on the enterprise, their needs could be met with a standard algorithm (abstraction of the solution follows):

  1. Accept a simple HTTP GET (REST) request from an external client
  2. Transform the query string into a SOAP request message
  3. Forward the SOAP message to a defined service
  4. Receive the response from the defined service
  5. Return the response (converted or not) to the external client

The solution implementation in OSB for each step was:

1). Create a Messaging (Text/XML) proxy service with HTTP transport
2). Use dynamic XQuery to transform the request from REST to SOAP, based on query-string parameters:
serviceName=???
serviceVersion=???
operationName=???

The combination of serviceName, serviceVersion and operationName can be used to dynamically select the appropriate XQuery to use for converting the incoming request from REST (URL, XML or JSON) to a SOAP request.  The same combination is then used to locate an XQuery to reverse the transform, i.e. from a SOAP body to a simple XML or JSON structure.

3). Use dynamic routing to forward the output of the XQuery to the target SOAP service
4). Receive the response from the SOAP service
5. Use dynamic XQuery to transform the response from SOAP to REST, based the on query-string parameters

This solution took only a few hours to develop, and can be used for any service, as long as:

  • The required XQuery resources for converting from/to SOAP have been created
  • There is an algorithm or mapping table for determining the URL of the target SOAP service from the input parameters

For sites that are waiting for the release of Oracle 12c and the promise of a REST gateway, this handy service can be used as a stop-gap solution.
See attachment for a sample project that implements this concept.

GenericRESTGatewayV1


Oyewole, Olanrewaju J (Mr.)
Internet Technologies Ltd.
lanre@net-technologies.com
www.net-technologies.com
Mobile: +44 [0] 793 920 3120

1 Comment

  1. wajid

    Good to know about this new feature translation feature in 12c and thanks for sharing.

    I have worked on Oracle Fusion MW where almost all the service components comply to SOAP specification.

    However in today’s enterprises which are widely driven by performance driven platforms like mobile the focus is purely on REST. And by just having a wrapper around your SOAP service and converting it to REST interface you are defying the REST design principles.

    Creating a RPC style REST interface is as good as making a SOAP call from the client but a pure REST implementation has its own benefits making your enterprise lean and modular.

    http://stackoverflow.com/questions/25679643/is-wrapping-soap-jms-as-rest-using-api-mgmt-tools-practical

    Cheers,
    Wajid

Leave a Reply