Oct 1st, 2006, 08:19 PM
How's contract-first working out for you?
I'm curious how other Spring-WS users are enjoying their experience with contract-first web services via Spring-WS.
For the past 5 years, I've used the code-first approach, mostly with Glue and later with XFire. This approach made a lot of sense at first, in that it made it extremely easy to publish a web service since you never had to worry about creating the WSDL - the framework did it for you. But with both frameworks, I always ran into problems with how the WSDL types were generated. With Glue, we couldn't use any Collection interfaces - we always had to use arrays. With XFire, I couldn't use inherited types - like if a method returned subclasses of a declared type (I believe support may have been added for this since I last used it). Looking back, I felt like any time saved upfront by auto-magic web service publishing was much less than the pain later of trying to get the WSDL types exactly right (if that was even possible).
When I first looked at Spring-WS, I thought the idea of having to write a thin layer of code (i.e. an impl of one of the Endpoint interfaces) on top of existing application objects seemed like too much effort. But after very happily using Spring-WS for a few months, I think there's a short-term cost in having to write that endpoint class (which often is quite trivial) and there's simply no pain later with trying to get the XML correct, since Spring-WS doesn't try to generate anything. Writing the XSD is required since we're using XMLBeans (which we like a great deal), and writing a WSDL is pretty trivial when all the types are defined in the XSD.
So basically, I'm really happy with the contract-first approach. I'm wondering what other frameworks support it, although I'm perfectly content with Spring-WS (and eager to see what the client API will look like). It looks like ActiveSOAP supports it as well, though I can't tell what the activity level there is. I haven't looked closely at JAX-WS annotations, but it seems like that's another code-first approach, though I could be wrong.