Introduction
Web services interoperability has been always a tough task as the number of features and complexity increases. Recently I came across a requirement for building a .Net client API for a Java Web Service developed using Spring-WS with the Contract First approach.
The service is secured with with Public-Key Cryptography which involves the use of asymmetric key algorithms, and message needed to be encrypted and then digitally signed by a Certificate Authority(CA). Moreover, the message encryption needs to be partial encryption, ie, the service needed the payload root element to be unencrypted and the whole content to be encrypted.
These days web service frameworks and tools have matured considerably. The Microsoft camp especially is well equipped with a strong API and their mighty WCF(Windows Commnunication Foundation) has a well designed and simplified API and a configuration schema supported by excellent documentation. This lead me to think my job would be as easy as writing a straight forward “Hello World” program. My expectation was the WCF tools will generate the client artifacts, including the proxy classes and the configuration files if I provide the URL of the WSDL(Web Service Description Language) of the service end-point.
However the road was not as smooth as I initially expected, in fact it was really bumpy and I faced problems both small and big problems along the way. It took a while to resolve them all and finally go live on production. I posted some of the very difficult problems encountered on several community forums. Many people replied with valuable solutions and suggestions. Some even asked me to send the code as a project, examined it and pointed out the exact root causes of the errors in my program. Thus I was able to fix things and have a working product.
So I thought I would document everything properly and publish it online in the hopes that some one would find it useful.
For the purpose of making the entire solution useful, I have created a sample application for both the web service as well as the client, with and without security. That means, both server and client programs will have two versions for each. One without security implemented in it, and the other one with security. I will be describing the steps of building each of these step by step, so an average programmer who is new to these technologies would find it easy to learn.
Here is a small overview of the technologies used on the both ends of this interoperability exercise.
Web Service | |
| Operating System | Linux |
| Application Server | Apache tomcat |
| Programming Language | Java Standard Edition 6 |
| Web service framework | Spring-WS, JAXB (XML Binding) |
| Security framework | WSS4J |
| IDE | Eclipse Galileo(with appropriate plugins) |
Client Program | |
| Operating System | Windows 2003 Server |
| Client Application | Windows Forms Application |
| Programming Language | C# |
| Web service framework | WCF |
| Security framework | Windows Security |
| IDE | Microsoft Visual C# 2008 Express Edition |
I am not going to publish everything at once, in a single post, but each version of server and client programs in different posts of its own. Thus, there will be a minimum of four further posts besides this introductory post. I will discuss the Public-Key Cryptography and describe the steps to creating the digital certificates on both sides, in Java as well as windows. I will explain the problems that I encountered and the solutions at appropriate points.
Next in this series of posts is about building the web service using Spring-WS, without having the security features implemented in it. Keep your fingers crossed..
