Tools Of The Trade: Spring Web Services

In general I think web services are way oversold. Especially when it comes to those of the enterprise SOA/ESB flavor. It seems like it has taken longer than normal for the hype surrounding web services to die down. This is probably because it’s a good area for vendors to push large “solution in a box” tools. The SOA vendors will probably be pushing their products for a while but I think the development community is reaching the point where web services have found their space of usefulness. The days of putting web services in front of every piece of software are fading away. We’ve landed in a place where web services are the right tool for certain jobs, particularly large-scale integration work. Since there are plenty of systems out there that need to talk to each other I think it’s safe to say that web services, in one form or another, are here to stay.

I thought web services would be a good topic for a “tools of the trade” post because it’s another area where there are many tools and technologies available. In addition to that, it’s a very complicated topic. The security alone is enough to make anyone crazy. In my experience, the best way to handle a complicated solution such as this is to avoid it all together. However, there are times when avoidance is not an option and web services are the right solution. In those situations I find the use of good tools can go a long way in helping to mitigate the necessary complexity involved with such a solution.

When it comes to traditional SOAP/WSDL based web services, most of the tools available have fallen short of my expectations. Just when I was beginning to think the terms web service and painful development were synonymous, along came Spring Web Services to save the day. First of all, it’s exclusively contract first. With Spring-WS your web service journey beings and ends at the main integration point – the XSD. This is a big selling point for me because the only situation where I really need web services is when I have to support multiple disparate clients. In those situations getting the service interface right is the most important part. Tools created to bolt web services on to an existing application by generating the contract from existing code have always seemed backwards to me. They create a contract that is tightly coupled to the implementation code. Such a contract is very likely to be difficult for your service clients to consume; those clients don’t speak the same language and that’s why you’re going through all the work of communicating in XML. In the contract first world you are forced to think about how clients interact with your service before it’s implemented. Focusing on the interface first tends to bring important contract issues to the surface quickly.

In addition to the advantage of being contract first Spring-WS also provides good support for the things you expect to find. The usual suspects like message based routing and security are all accounted for and it allows you to use just about any tool under the sun (no pun intended) to deal with the XML. It also passes my “as expected” rule. Things have reasonable names that explain what they do. Objects and configuration are where you expect them to be. The methods you hope to find are usually there and behave as expected. I think these simple things are a large part of what makes a framework easy to use and the software created using that framework easy to maintain. When you’re working with a complicated technology this aspect of a framework is even more important. Staying on top of these simple things takes diligence. It’s surprising how many frameworks don’t do a good job of it. Many seem to be more concerned with functionality and flexibility but what I’m really after is usability.

When it comes down to it, I think the decision of whether or not to use web services is probably more important than what technologies you choose to implement them with. If you don’t need to support remote clients it’s probably not a good idea to add web services “just in case”. If all parties involved talk Java you probably don’t need the overhead and complexity of web services. If you only need to support one remote client things could probably be kept simpler with a POX over HTTP approach. In many cases I think the RESTful web service approach, which Spring 3 MVC supports nicely, is a good alternative to the traditional approach. So there are a lot of things to consider before taking the web service plunge. However, if you’ve analyzed requirements closely and there’s no getting around the fact that you have to support multiple clients making RPC style calls, Spring Web Services is the best approach I’ve seen.