Browse Prior Art Database

Implementing RESTful gateway for Enterprise Service Bus based SOAP services Disclosure Number: IPCOM000199960D
Publication Date: 2010-Sep-22
Document File: 5 page(s) / 214K

Publishing Venue

The Prior Art Database


In Service Oriented Architecture, business applications expose SOAP based Web Services to facilitate integration. The recent advent of Web 2.0 applications promote the use of REST style web services rather than WSDL based SOAP services. To provide an easy integration with Web 2.0 based client applications, many enterprise applications are now exposing a set of RESTful interfaces in addition to the existing SOAP interfaces. This would typically require the applications to provide two end-points corresponding to the two set of interfaces. There are two options to implement these interfaces:

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 30% of the total text.

Page 1 of 5

Implementing RESTful gateway for Enterprise Service Bus based SOAP services

Let us assume there is an existing SOAP based service which exposes certain web services. As an example, here we consider using the Parlay-X standard based SOAP service that exposes Telecom operators network capabilities. In addition to the existing SOAP based web services, in order to cater to the Web 2.0 clients it is required to expose these network functionalities via a REST style gateway. Given the context of the already existing SOAP based mediation flows, this solution proposed here is to provide an additional gateway for REST interfaces, map the REST request data to the SOAP request and direct it to the SOAP gateway. This would ensure that the functionality and infrastructure of the existing mediation flows are being leveraged and results in an efficient, cost-effective solution.

Let us consider an example using a SOAP based request (following Parlay X standard) and a REST-style equivalent request (using GSMA OneAPI standard) for sending a short message, which is shown below:

< soapenv:Envelope xmlns:soapenv = ""
xmlns:loc = "

< soapenv:Header />
< soapenv:Body >

< loc:sendSms >

< loc:addresses > tel:+000111222333 </ loc:addresses >
< loc:senderName > jDoe </ loc:senderName >
< loc:charging >

                  < description > SMS base plan </ description >
< currency > INR </ currency >
< amount > 1.00 </ amount >
< code > 000 </ code >
</ loc:charging >
< loc:message > SMS Test Message </ loc:message >
</ loc:sendSms >
</ soapenv:Body >
</ soapenv:Envelope >

Fig 1: SOAP message for sending a Short Message request (excluding HTTP headers)

POST /ShortMessageService/REST/sms HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/x-www-form-urlencoded
User-Agent: Jakarta Commons-HttpClient/3.1
Content-Length: 67







Page 2 of 5


Fig 2: REST-style request for sending a Short Message (including HTTP headers)

Within the ESB mediation, the interfaces are defined using the WSDL corresponding to the SOAP service. So the current solution is to create a map that maps RESTful request parameters to the SOAP message as shown below:

SOAP message element RESTful URL parameter

sendSms / addresses address
sendSms / senderName sender
sendSms / message message
sendSms / charging / code charging

The existing solution is to create a transformation gateway that does this mapping. The proposed solution is shown in the picture below:

Fig 3: Converged REST/SOAP gateway

In the picture above, it is proposed to create a new binding with the HTTP export, that can receive REST-style requests and map the URL parameters to the Business Object (BO) which is part of the mediation flow's Service Data Object (SDO). The mapping can be done using a mapping configuration file or using a heuristic alg...