Hi
On 02/01/12 15:18, Brice Dutheil wrote:
Hi all,
Thanx for your replies. Sorry for the belated reply, you know christmas /
nuyear holidays... So happy new year to all.
Anyway many interesting reads.
Yeah managing WSDL versioning through XSD was one of the heavyweight
solution I had in mind, but I'm not sure many people have the right tools
in hand to make versioned WSDL. I'm not an expert but in the approach
you mentioned, it leads to one WSDL document, correct ? Then how can we
address those mappings on the Java side.
CXF can handle this via the Transformation feature that Sergey just
mentioned. The wiki is not really clear on how to redirect things given a
certain differentiator.
http://cxf.apache.org/docs/servlet-transport.html
explains how CXFServlet redirection can be set up. more info is here
http://sberyozkin.blogspot.com/2011/11/cxf-tranform-feature-and-redirection.html
Also it might be possible to use this transformation feature on the target
endpoint to match the Java API. However it does seem to work only on the
XML not on other content such as JSON which is common which JAX-RS services.
Works when a default Jettison-based provider is used too
In all the things I read here and there, it seems all the techniques about
versioning avoids to handle this on the Java side be it possible, limited,
or experimental at best.
For example, what would you do if you need to expose two different
versions, with difference in object/property names, in some value (ex:
splitting old value to indicate different sub-cases), etc.
In a previous mission we were using EJB-JARs and WARs, this way we could
use different objects with the same qualified name (due to the JEE
classloader architecture), services were exposed with a version number in
the URI (.../ws/5_0/quote) and in the JNDI name (.../ejb/5_0/quote), and of
course one WSDL per services (no versioning on this front). While clean,
this approach is also pretty heavyweight to maintain and is limited to
people that use JEE and EJB-JARs or people that can work in multi
classloader environment.
The annotation approach seems more code centric and probably easier for
people that don't follow the contract first approach. But you need to deal
with annotating your code then.
But if you share your API artefact with your partners (or your colleagues)
so they don't have to generate code from the WSDL or from the WADL, you
will expose fields object that belong to the upper version or the lower
version.
Sorry, I'm not sure I understand. I think that as far as the web
services are concerned, the versioning & extensibility is to do with
updating the way the consumers of the service use this service at the
moment, so the way the implementation code is managed is kind of
orthogonal to it...
Cheers, Sergey
Do the JAX-WS / JAX-RS are good candidates to address or at least provide
support for contract versioning ?
Cheers,
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
