-- Brice Dutheil
Le mercredi 4 janvier 2012 à 20:31, Sergey Beryozkin a écrit : > 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 > > Ok I better understand how it works. > > 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 > > Could it work with other providers (Jackson especially, but Gson 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... > > Yeah, I'm not limiting the discussion of versionning to pure a pure endpoint / serialzed data discussion. IMHO, the way implementation is made is also part of it this discussion in the sense of what would be the best practices, is there any emerging /patterns/ regarding versionning on the implementation's side. In JEE you could craft the following architecture : [EJB-JAR v2] -> [EJB-JAR core] [EJB-JAR v3] ---------^ You see in this model that having multiple EJB-JAR allows isolation and modularity, the versionned EJB-JARs act as facades with adapters. JEE would then allow to expose EJBs as web services or resources. While in a WAR only application, you have one class loader, no isolation, so you need to actually make it explicit in the qualified names > > 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
