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.
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):
- Accept a simple HTTP GET (REST) request from an external client
- Transform the query string into a SOAP request message
- Forward the SOAP message to a defined service
- Receive the response from the defined service
- 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:
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.