REST JSON to SOAP conversion tutorial

March 31, 2010

I often get asked about ‘REST to SOAP’ transformation use cases these days. Using an SOA gateway like SecureSpan to perform this type of transformation at runtime is trivial to setup. With SecureSpan in front of any existing web service (in the DMZ for example), you can virtualize a REST version of this same service. Using an example, here is a description of the steps to perform this conversion.

Imagine the geoloc web service for recording geographical locations. It has two methods, one for setting a location and one for getting a location. See below what this would look like in SOAP.

Request:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <geo:getPosition xmlns:geo="http://test.layer7tech.com/geolocws">
      <geo:trackerId>34802398402</geo:trackerId>
    </geo:getPosition>
  </soapenv:Body>
</soapenv:Envelope>

Response:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <geo:getPositionRes xmlns:geo="http://test.layer7tech.com/geolocws">
      <geo:latitude>52.37706</geo:latitude>
      <geo:longitude>4.889721</geo:longitude>
    </geo:getPositionRes>
  </soapenv:Body>
</soapenv:Envelope>

Request:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <geo:setPosition xmlns:geo="http://test.layer7tech.com/geolocws">
      <geo:trackerId>34802398402</geo:trackerId>
      <geo:latitude>52.37706</geo:latitude>
      <geo:longitude>4.889721</geo:longitude>
    </geo:setPosition>
  </soapenv:Body>
</soapenv:Envelope>

Response:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <geo:setPositionRes xmlns:geo="http://test.layer7tech.com/geolocws">OK</geo:setPositionRes>
  </soapenv:Body>
</soapenv:Envelope>

Here is the equivalent REST target that I want to support at the edge. Payloads could be XML, but let’s use JSON to make it more interesting.

GET /position/34802398402

HTTP 200 OK
Content-Type: text/json

{
  'latitude' : 52.37706
  'longitude' : 4.889721
}
POST /position/34802398402
Content-Type: text/json

{
  'latitude' : 52.37706
  'longitude' : 4.889721
}

HTTP 200 OK

OK

Now let’s implement this REST version of the service using SecureSpan. I’m assuming that you already have a SecureSpan Gateway deployed between the potential REST requesters and the existing SOAP web service.

First, I will create a new service endpoint on the gateway for this service and assign anything that comes at the URI pattern /position/* to this service. I will also allow the HTTP verbs GET and POST for this service.

REST geoloc service properties

Next, let’s isolate the resource id from the URI and save this as a context variable named ‘trackerid’. We can use a simple regex assertion to accomplish this. Also, I will branch on the incoming HTTP verb using an OR statement. I am just focusing on GET and POST for this example but you could add additional logic for other HTTP verbs that you want to support for this REST service.

Regex for REST service resource identification

Policy branching for GET vs POST

For GET requests, the transformation is very simple, we just declare a message variable using a SOAP skeleton into which we refer to the trackerid variable.

SOAP request template

This soap message is routed to the existing web service and the essential elements are isolated using XPath assertions.

Processing SOAP response

The REST response is then constructed back using a template response.

Template JSON response

A similar logic is performed for the POST message. See below for the full policy logic.

Complete policy

You’re done for virtualizing the REST service. Setting this up with SecureSpan took less than an hour, did not require any change on the existing SOAP web service and did not require the deployment of an additional component. From there, you would probably enrich the policy to perform some JSON schema validation, some URL and query parameter validation, perhaps some authentication, authorization, etc.


Connecting the enterprise to the cloud marketplace

March 11, 2010

With Google launching its new cloud-based enterprise apps marketplace these days, many people are paying closer attention to a maturing overall cloud offering. One of its components which caught my attention today is ironically something that you are meant to install enterprise-side: the Secure Data Connector (SDC).

The SDC lets the enterprise control access to its private resources (resources behind the enterprise’s firewall) from google apps. This illustrates an increasingly popular pattern relating to enterprise cloud adoption where applications deployed on the cloud need to access private resources located securely behind the enterprise’s firewalls. This pattern is also referred to as the ‘distributed SOA’, the idea that an enterprise’s SOA spans across multiple service zones both on and off-premise.

Google’s SDC is essentially reverse-proxy software, which you install on a server deployed in your DMZ. SDC maintains a secure link with Google apps and enforces basic rules relating to access control. Although some aspects of the solution borrow concepts from standards such as OAuth, the solution as a whole is mostly proprietary.

There is no doubt that this pattern is very important to address for any enterprise leveraging cloud-side applications. However, before deploying Google’s own gateway, and the ones of each cloud provider that you will eventually rely on, consider a best-of-breed specialized piece of infrastructure (SOA gateway) that works across cloud providers using standards and meets the highest threat protection requirements.

As it is, google apps access private resources through such an SOA gateway just as well as they will through the proprietary SDC. This type of openness is crucial in your choice of cloud provider. Proprietary security mechanisms increase vendor lock-in – perhaps one of the most important barrier to adoption for rich enterprise cloud use. Investing in security solutions that only works with one cloud platform affects your long term ability to switch provider.