A Simple REST to SOAP Gateway with Intel® SOA Expressway - Yes, it's that easy...

It is always good to come across a situation where you have an easy solution to a customer problem. It's even better when the customer thinks the problem is a hard one!

The problem at hand is the dreaded "mediation" problem for cross-domain service interfaces. As most techno-religious battles go, this is one for the record books. One one hand we have large vendors and Enterprises deploying SOAP inside the Enterprise and on the other hand we have the popularity and simplicity of REST-style interfaces, driven by Web 2.0 style APIs and start-ups. To make matters worse, there really is no standard for REST other than HTTP. One may argue that the official definition of REST was given in the famous thesis by Roy Fielding, but the practical reality is that any non-SOAP service based on HTTP is now called a REST service - for better or for worse.

In this post, I am going to show you how to make a simple application using Intel® Services Designer that maps a REST request to a SOAP request with zero coding using Intel® SOA Expressway. If you don't already have a copy of Intel® SOA Expressway, you can request an evaluation over at http://www.dynamicperimeter.com.

Let's get started!

The SOAP Service

If we are mapping REST requests to SOAP requests, we need some SOAP service to start with. For this example I am going to use a simple calculator service that provides four operations: add, subtract, multiple and divide. For reference, you can download copy of the WSDL here

The REST API

The next question we need to answer is what will our REST API look like? Here, there are simply no hard and fast rules. We are free to invent a calling convention and as long as the request itself expresses the necessary components of calculator function and its parameters, it’s a legal REST call. For example, we could shove the parameters in the HTTP header, query parameters, or body of the request. We are also free to use HTTP GET or POST. For this example, we’ll stick with a simple convention based on HTTP GET which will allow us to test the application with a web browser:

http://host:port/servicename?method[add|subtract|multiply|divde]&num1=[value]&num2=[value]

Input Selection

Intel® SOA Expressway can grab part of the HTTP header if we choose the appropriate XPath expression. For the REST API convention we’ve picked, we’ll need three expressions, each of which will be used to grab part of the input. Once we’ve nailed the expressions, the rest of the application is a snap


1. Method: $GetMessageMetadata/md:transport/md:httpRequest/md:query/md:param[@name='method']/text()
2. First Number: $GetMessageMetadata/md:transport/md:httpRequest/md:query/md:param[@name='num1']/text()
3. Second Number: $GetMessageMetadata/md:transport/md:httpRequest/md:query/md:param[@name='num2']/text()

Services Designer uses the GetMessageMetadata variable to store the complete HTTP header information. Once you know where things are stored, you just need the right XPath expression to grab it.

When we make the call in the browser, it will look like this: http://host:port/calculator?method=add&num1=5&num2=4

Expressway will send back the SOAP response which will hit the browser as XML with the answer.

The Application

With the correct expression in hand, the application is a breeze. To keep things simple, this application will only process add requests and throw back an error message if the add operation is not selected. The following thumbnail screen shot shows the completed application:

Simple REST to SOAP Application

For the “Receive” step, we’ll use a plain binding and be sure to set the service endpoint as “calculator”. We will also have to use the GetMessageMetadata step to make the header information available to the application. To create the actual SOAP request, we’ll use the XMLBuilder action and provide the WSDL for the calculator service. In the previous picture, this is the SOAP-Builder action, which is just a renamed XMLBuilder action.

The Method expression is the first place where we use one of the three XPath expressions we created earlier. This step is just storing the incoming method in a variable to be used by the subsequent If statement. Click the thumbnail below to see the entire expression.

Method Expression

The If statement is hard-coded to look for the add method. Here we are doing some simple string checking. If the method is add, we’ll go on to create the SOAP message. If it isn’t we’ll return an XHTML error message, which is just a string that says the method is unsupported. Click to expand the thumnail below.

If Statement

The SOAP builder is where we create the SOAP request for the add method. You can provide the XML Builder with the WSDL and use the XPath expressions directly to map the REST values to the SOAP request. This is where the “magic” happens, so to speak. In the screen shot below we show how the XPath is set for the first number. You'll do the exact same thing for the second number but use the appropriate expression that specifies "num2".

SOAP Builder

Testing the Application

Once the application is deployed to an instance of SOA Expressway and the calculator service is accessible, the application can be easily tested with a browser. Lucky for us we chose a simple REST calling convention that makes testing a snap.




We could always get fancier and return a more browser friendly response, such as an HTML page, but for now we’ll just pass the XML back to the browser.

If we try a method that isn’t supported, such as multiply, we’ll get a nice XHTML error message passed back to the browser. This message is just a string inside a paragraph tag created using XML Builder. I’ve renamed it to HTMLResponse in the application and used it in the reply step inside the error leg.

Firefox Browser Test for the REST Gateway with a negative test

This application is just the beginning: In addition to the basic mapping capabilities described here, Expressway can add message level security, denial of service protection, XML acceleration, message throttling, policy decision point integration and a host of other features to any part of the application level traffic. It's available in three form factors: software on a standard Intel server, a Dell hardware appliance, or virtual image.

Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione