Most of the time what I'm working on when I need a proxy has something to do with SOAP and there is actually a MITM proxy in SoapUI but it doesn't have support for HTTPS. If you are working with SOAP and can use HTTP then SoapUI is a great tool. If that doesn't fit the bill then Paros proxy does a good job.

Paros proxy is pretty easy to set up, just download the binary distribution and run it. The only thing I wanted to change was the port that Paros listened on and that can be done by going to the Tools menu option then Options and then selecting Local proxy:

From the description of this option you can see the Paros listens for both HTTP and HTTPS on the same port. Tell Java where to find the proxy server either on the command line with the following system settings:

-Dhttp.proxyHost=localhost -Dhttp.proxyPort=8081 -Dhttps.proxyHost=localhost -Dhttps.proxyPort=8081

or in code using the System.setProperty call:

    System.setProperty("http.proxyHost", "localhost");
    System.setProperty("http.proxyPort", "8081");
    System.setProperty("https.proxyHost", "localhost");
    System.setProperty("https.proxyPort", "8081");

At this point if you try to use the proxy with HTTPS you are going to get an error because the proxy doesn't have the correct certificate or a matching hostname for the proxied service. Luckily you can tell Java to ignore all SSL certificate problems and any hostname miss-matches with the following code:

// The following tells Java to ignore certificate problems
TrustManager[] trustAllCerts = new TrustManager[]
{
  new X509TrustManager()
  {
    public java.security.cert.X509Certificate[] getAcceptedIssuers()
    {
      return null;
    }

    public void checkClientTrusted(java.security.cert.X509Certificate[] certs, String authType)
    {
    }

    public void checkServerTrusted(java.security.cert.X509Certificate[] certs, String authType)
    {
    }
  }
};

try
{
  SSLContext context = SSLContext.getInstance("TLS");
  context.init(null, trustAllCerts, new java.security.SecureRandom());
  HttpsURLConnection.setDefaultSSLSocketFactory(context.getSocketFactory());
}
catch (Exception e)
{
}

// This tells Java to not worry about hostnames matching
HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier()
{
  public boolean verify(String string, SSLSession ssls)
  {
    return true;
  }
});

Make sure the above block of code is executed before any SOAP calls need to be made.

Now if you start Paros proxy and run your application you should see the SOAP requests in their raw form. If you are debugging SOAP messages these raw requests can be exported to text files and then loaded into SoapUI for further processing if need be.

I'm going to assume basic knowledge of the GAE system. If you haven't already tried it out you should read the getting started guide. You shouldn't need to know any more than what is in that guide to work through this example. I also assume knowledge of creating WSDL files by hand. You will need to be able to do this to generate the SOAP server and client. You can find a WSDL tutorial here that may help. I also recommend creating an empty directory that will house your project for this example.

The first step involves getting a library from the Python Web Services project. You will want to download the ZSI 2.1a1 package (grab the the tgz file: ZSI-2.1-a1.tar.gz). This is the current alpha release of ZSI but the current stable release won't work. The stable release has a problem with the expat library but the problem is fixed in 2.1. It is also worth stating that ZSI 2.1 seems to be better put together. Extract the files into a temp directory and then copy only the directory named "ZSI" into your project directory.

Next you will need to get zope.interface. Go to the zope.interface download page and find the file named: zope.interface-3.5.0.zip. Unzip this file in a temp directory and then copy the directory named "zope" into your project.

These two external libraries are all you need to create a Python SOAP service. The next step in creating the service involves using the GAE webapp framework so it would help to read up on that. This framework works with WSGI and it may also help to learn about WSGI as well. I referenced the django example and example of using routes to get an idea of what needed to be done to connect the GAE WSGI up to the ZSI SOAP service. They both use the WSGIApplication webapp call to tie in their output with the WSGI framework and that is common to all applications that use the webapp framework.

Now that all the libraries are in place and the WSGI and GAE webapp interface make some sense it is time to move on to creating a WSDL file. Here is a simple one that I used for the test:

Notice at the bottom I set the address to the location of my test service along with the application domain name. This is where the application will end up in production. If you want to test first you can stick your localhost information in there instead.

Next you will need to run the wsdl2py application that comes with ZSI on your WSDL file to generate the classes needed for the server. To do this I simply copied the wsdl2py application into the project and ran the following command:

After you do this you will find a couple new files in your project directory. I then removed the wsdl2py application so it didn't get uploaded later.

Next create the test endpoint application itself. For this example I named the file echo.py and added the hooks that connect the service to the WSGI interface:

Next create the application description file app.yaml that is needed to upload and install the application in the GAE. For simplicity I just map everything to the main program:

At this point my project directory looked like this:

The application is ready to be uploaded to GAE at this point. After uploading you can stick the endpoint URL into a browser and you should see a message saying "NO RESOURCE FOR GET". If you get some type of error use the logs in your application console to look at the application stack trace. If there are no errors you are ready to build a client to test the SOAP service.

To create the client you use the same WSDL file with wsdl2py again. This actually generates the same class files and you need the same libraries in place to run it. The following example client will test the service:

As long as the service is in the same place as the WSDL location setting you don't need to specify an endpoint for the getServer call.

And that is all there is to it. It is fairly involved but if you already understand some of the concepts here it seems fairly strait forward. Along the way I found a SOAP tutorial for Python that may be helpful as well.

The problem was that using the auto-generated code from the WSDL didn't provide any obvious way of adding the headers I needed to add. After a lot of digging I found an article on adding Support for Custom HTTP and SOAP Headers and that led me down the following path to a solution.

First off you need a custom header class that derives from SoapHeader. This class will contain the attributes that get sent in the SOAP header. Here is an example:

Next you will need an instance of the custom header in the generated service client. The variable name needs to match what gets stuck in something later so make it readable:

The final step is to a reference to the custom header before each call that requires the custom header. This is probably the least obvious part. The first line in the following code is the tie between the custom header instance created above and the generated "echo" service call:

Here is an example of calling the modified service:

The only downside to doing this is that regenerating the code from an updated WSDL will wipe out the changes.

• REST vs HTTP+POX vs SOAP – A simple explanation of REST and SOAP.
• How I Explained REST to My Wife – Another simple explication of what REST is.
• The S Stands for Simple – A conversation that expresses the issues with using SOAP.
• REST for Web Services – The outline for a new REST for web services book.
• The REST Dialogues – A set of fictional dialogs on REST vs SOAP.
• The REST Dialogues, A Real eBay Architect – A response to "The REST Dialogues" by a real eBay architect.
• 85% of Amazon calls are to REST version of their API
• Google turns off SOAP API
• Why SOAP sucks

After looking over the above references you may be interested in looking at Programmable Web's API list and see what others are using. The majority of the public services listed offer REST interfaces with some offering both REST and SOAP and very few offer just SOAP. Even though REST seems to be in favor now I believe there are still plenty of areas where SOAP makes sense when you have resources to devote to feeding and caring for it.

Tags: SOAP, REST, web services