I finally got an opportunity to work with web services. I had of course read about these in the past and in fact implemented web service like applications prior to the emergence of SOAP, but I had never really had a chance to actually work with web services on a project. On my current project, I am using Apache Axis to expose some of our functionality to third parties, a prime example of what web serices are good for. Axis makes it very easy to expose existing Java classes through a web service, as well as (although we are not currently using this functionality) access an arbitrary web service through a set of automatically generated proxy classes, based on the service’s WSDL. Still, I had to at first catch up on WSDL and SOAP in order to define a clean web service that will (hopefully) work with most SOAP / web service client implementations.
One of the main things I was not aware of is the fact that there are several styles of WSDL. Mainly, there’s the traditional RPC-encoded style, the newer document-literal style, and the wrapped variant of the latter. I am not going to explain the differences here, but this article helped me understand the pros and cons of the various WSDL styles. In the end, I decided to go with the document-literal wrapped style, which should work well for our purposes and seems to be the direction in which WSDL and SOAP are evolving. It allows us to fully define the input and output parameters of our web service using XML Schema notation embedded within the WSDL file, while allowing for an RPC-style invokation mechanism.
So far, I have been able to easily access our web service using the client stub that Axis was able to generate from our WSDL, as well as using very simple, low-level SOAP code using the SAAJ (Soap with Attachments API for Java), for which Axis also provides an implementation. Based on what I have read, it should be straightforward to access the same service using .NET or other web service clients.
I originally used Axis to generate the WSDL file based on a Java interface that I had written for this purpose, but I ended up customizing the WSDL to come up with a nicer XML Schema for input and output types. Based on various sources on the web, the recommended way to implement a web service using Axis seems to be to use some kind of tool to generate the WSDL file, and then use Axis to auto-generate the necessary glue (the actual web service, marshalling / unmarshalling code, etc.).
Another invaluable tool that Axis provides is a simple TCP monitor. This essentially acts as a proxy that sits between the web service client and the actual service and that provides a nice UI to inspect SOAP requests and responses. Very nice for debugging a service.
Definitely fun to work with.