In a post I read today on building extensible web services someone is offering a solution for the inflexibility current web service solutions offer when it comes to transforming object graphs to XML.
To get to a more flexible web service interface, changing the Java service interface from
Car[] getCars()
to
Map[] getCars(String[] returnFields, Map searchCriteria)
does the trick the author says. It might be that he meant that the implementation of the second interface actually wraps the first service, hence not replacing it, but that doesn’t really matter. What does matter is the fact that we’re modifying Java code to allow for a more flexible web service interface.
A better solution in our opinion is to facilitate those kind of things in a more framework-oriented way, by allowing the developer to use a framework to customize the XML that is returned the browser. All this instead of having to adhere to stringent requirements of existing web services stacks that only allow for mapping Objects to XML using one, predefined approach.
Customization of the XML being generated, choosing the OXM (Object-XML Mapping) solution to use, it all helps keeping our Java service interface in place while maintaining that same level of flexbility we require to facilitate a service-oriented architecture.
I’m really happy (and this is the last I’m going to say this) that before we announced Spring Web Services, but also since the announcement I’m keep on seeing situations very frequently where our future approach to building web services will really help!
The two points of the “building extensible…” blog entry were:
1. Offer a way to allow a web service to be extensible without the consumers having to recompile or alter their code (this consumer can be .Net, java, PHP or some other language)
2. Reduce the amount of XML sent over the wire
I agree with your thought about support for this in the framework, but seeing how frameworks are rarely available in multiple programming languages (more than 2), I presented this solution as a solution that should work for most programming languages.
The better to ensure stability of the web service interface is to decouple the web service interface from the Java interface.
Implementing a generic (Java or Web) service interface results in some other issues:
the contract and semantics of your interface are completely gone, usability will decrease
the use of a generic service interface prevents you from controlling the finer-grained less generic service methods with AOP or something the like
A generic service interface, just as a generic database is simply a bad idea in my opinion.