You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Brice Dutheil <br...@gmail.com> on 2012/01/02 16:18:57 UTC
Re: Open question about versionning?
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.
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.
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.
Do the JAX-WS / JAX-RS are good candidates to address or at least provide
support for contract versioning ?
Cheers,
--
Brice
On Fri, Dec 23, 2011 at 19:24, Sergey Beryozkin <sb...@gmail.com>wrote:
> On 23/12/11 01:27, Christopher Riley wrote:
>
>> Hi Brice,
>>
>> There isn't a "standard" in web services versioning however you can check
>> out SOA Design Patterns like Version Identification at
>> www.soapatterns.org.
>>
>> With Web Services, you have the service contract(WSDL) and data contract
>> (XSD). One common approach especially with WSDL is to use the XML
>> Namespace
>> of the Web Service and include the major version details like:
>>
>> xmlns:tns="http://www.example.**com/services/<http://www.example.com/services/>
>> <servicename>/v1"
>>
>> When the consumer invokes the service, this namespace will be in the SOAP
>> request. You should also version the schema and this again can be done in
>> the Namespace or you can use XML Attributes to contain this information.
>> By
>> using this approach the communication includes the version details and
>> technologies like Enterprise Service Bus, Web Service containers etc can
>> sniff the request using XPath etc. to determine the consumer's version and
>> route accordingly.
>>
>> Within REST, check out Foursquare, Twitter and others who embed the
>> version
>> in the URI for the REST service.
>>
>>
> In CXF we can also use Transform Feature to redirect from one destination
> to the other one if the 'differentiator' is in URI:
>
> http://cxf.apache.org/docs/**transformationfeature.html#**
> TransformationFeature-**InputTransformationandRedirect**ion<http://cxf.apache.org/docs/transformationfeature.html#TransformationFeature-InputTransformationandRedirection>
>
> Sergey
>
>
> Chris
>>
>> On Thu, Dec 22, 2011 at 1:58 PM, Brice<br...@gmail.com> wrote:
>>
>> Hi,
>>>
>>>
>>> How and what technologies would you use to version wabservices either in
>>> SOAP or REST ?
>>> This is an open question, there's no real code behind yet.
>>>
>>>
>>> For Rest webservices I was thinking about using a Gson (the google gson
>>> project) MessageBodyWriter that support some trivial versioning.
>>> It is based on annotations on the transferred objects. However these
>>> annotations are com.google.* not really standard.
>>> Do the JAX-RS 2.0 expert group have some versionning in mind ?
>>>
>>> For Soap webservices, I really don't know how I would to start or which
>>> direction to arrive to something elegant. (I have some heavyweight
>>> solutions in mind though).
>>>
>>>
>>>
>>> Cheers and happy holiday also :)
>>>
>>>
>>> --
>>> Brice
>>>
>>>
>>>
>>
>>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com
>
Re: Open question about versionning?
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 08/01/12 18:28, Brice Dutheil wrote:
>
>
> Le vendredi 6 janvier 2012 à 20:42, Sergey Beryozkin a écrit :
>
>> Hi,
>>
>> <snip/>
>>>>>> 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).
>>
>> Those providers may offer something else, I checked the source of the
>> jaxrs Jackson provider, might be possible,
>>
>> Benson, do you know by any chance how easy it is to provide a custom
>> org.codehaus.jackson.map.ObjectMapper, which will wrap the input stream
>> in the CXF specific custom XMLStreamReader and delegate to the default
>> Jackson JAXB-aware mapper ?
>> May be we may ship such a mapper if it were possible
>>
>>
>
> This would be interesting because these Jackson and Gson are really performant (GSon is way better than it was). Jackson offer some interesting annotations, while not standard they bring nice features. Gson has less features but it bring versioning annotations.
> And we still have to see what will emerge from JSR 353.
>
Would you be interested in experimenting with a Jackson JAX-RS JAXB
provider and see what it takes to provide a custom ObjectMapper as well
as check if Jackson can 'recognize' custom XMLStreamReaders such mappers
can create ?
I won't have time to do it in the short term so if you can look into it
then it would help
Sergey
>
>
>>>>>> 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.
>>>
>>> Basically those are the two options that are right now in my head about implementing verisonning …in the java code part.
>>> 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 could make it explicit in the qualified names
>>> and / or you can make use of annotations to help versionning support in your model
>>>
>>>
>>>
>>>
>>>
>>> And whatever the case you will probably need to make the link between the implementation and the contracts such as the WSDL or the WADL. So this why I'm going further than only about how a client consumes the service or the resource.
>>>
>>> Am I clearer ?
>> I think so, I was not quite right anyway to suggest that the server-side
>> issues are out of scope for the web-services versioning...
>>
>>
>
>
> Right now I do not participate or follow what happens or what happened in the expert groups for JAX-RS / JAX-WS or other specs, but this would be interesting to bring "versioning support" discussion on these JSRs.
>
> Anyway as said, this is quite an open minded discussion, no real implementation behind yet, though someday me and others will mind versioning in their application.
>
>
>
> Regards,
>
>
>
>
> --
> Brice Dutheil
>
>
>> Cheers, Sergey
>>
>>>
>>>
>>> Anyway thanks for the informations :)
>>>
>>>
>>> --
>>> Brice
>>>
>>>
>>>>> Cheers, Sergey
>>>>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Open question about versionning?
Posted by dstainer <de...@gmail.com>.
Hi Brice-
The versioning discussion is something that I've been trying to put together
a solid solution to for some time. I figured I'd chime in to discuss what my
current solution is for both an opportunity to share some ideas and accept
some critique in an effort to improve my overall design.
The response is long, however, I'm hoping that the response is enough of
what you are looking for to justify the length.
Much like you’ve found, my SOAP solution for versioning is rather
heavyweight. I’ve tried to do a couple of things to allow the RESTful
versioning to fit nicely but I haven’t really crossed that bridge yet.
For a particular service, let’s just use addressbook as an example, I have
the following package structure:
com.acme.services.addressbook.v1.soap
com.acme.services.addressbook.v1.types
Each package contains a package-info.java file, which set the namespace to
something along the lines of: http://www.acme.com/api/addressbook/v1. We
version at the package and namespace level, as well as, the JAR level when
the API code is packaged up (i.e. address-book-api-1.0.0.jar).
The service endpoint interface and implementation should both reside in the
com.acme.services.addressbook.v1.soap package. However, from a JAR packaging
perspective, they aren’t necessarily packaged together. The service endpoint
interface is packaged in an API specific JAR, while the service endpoint
implementation is kept with the other server code (more on this later).
All message/data transfer objects sent to and from the server, as part of
the service API, reside in the com.acme.services.addressbook.v1.types
package. This was done so that we could, potentially, reuse these types for
RESTful services i.e. register Jackson to de/serialize our JAXB beans into
JSON. But I actually haven’t fully tested this, but based off CXF
documentation and other replies in the mailing list I believe this to be
possible.
New methods and new complex types can be added to the v1 interface and
implementation so long as they are backwards compatible. When you reach a
point where you have a non-backwards compatible change you have to create
version 2.
In this case we would create the additional packages/namespaces/jar files to
support this new interface and would make the appropriate changes there. One
interesting point here would be that the API files would again be packaged
separately than all other implementation and API code i.e.
address-book-api-2.0.0.jar. This jar would not contain any v1 code.
As I mentioned above we also version at the JAR level as well. This has an
impact on deployment. There are two artifacts that result from a build and
both should be versioned independently.
The first artifact is the actual API jar file. The contents of this file
should contain the service endpoint interface and all files from the
com.acme.service.addressbook.v1.types package. As mentioned this should have
it’s own versioning value, the reason for this is that the change frequency
on the API itself should be different from the implementation versioning. In
other words, the API shouldn’t change as much as the implementation.
The second artifact is the actual WAR file. This artifact should contain the
service endpoint implementation, along with all of the critical business
logic and domain objects. As stated above this artifact should also have
it’s own versioning. The idea of having it’s own versioning is that you
might make changes (bugfixes, spring 2 to spring 3) to the implementation
that have no impact on the API itself. Figure it more of an internal version
number because the key version is which version of the API does the server
support.
For instances where you have a v2 that needs to be supported you would bring
in both v1 and v2 of the JARs as dependencies of the service and would
support both versions of the interface until any development/business
agreements allowed for the removal of the v1 interface.
What about REST? Truth be told we have no RESTful services at this moment.
However, I believe it’s reasonable to assume that in the near future this
fact is going to change (look at API trends and you’ll see what I mean).
Therefore, I’ve put some thought into what we are going to do in this
situation. It’s untested so use at your own risk.
The theory goes that you would have an additional package:
com.acme.services.addressbook.v1.rest
The idea here would be that the appropriate Controller (I think that’s right
term) objects would be defined here.
Now in both cases, SOAP and RESTful web services, both the service
endpoint’s and controllers serve as delegators back to the appropriate
business logic component. Therefore, the endpoint implementation (in the
SOAP case) is responsible for mapping to/from data transfer object into
domain object and then delegating to business service component to carry out
the actual business logic. This allows “potential” reuse between RESTful and
SOAP based web services interface.
Other solutions that I considered were doing some sort of message translator
pattern that would add/remove values to messages based off the message
version. However, I’ve had some experience using that style for other
projects that I worked on. I always felt that it was the wrong choice for
that previous project and that bad taste has carried over. So it’s more a
personal bias rather than invalidation of the strategy itself.
There are obviously a bunch of details in here that I can try to elaborate
if you have any questions. But I hope this helps and not confuses.
Derek
Here is additional version resources that I've found to be helpful to me:
- http://blogs.iona.com/sos/20070410-WSDL-Versioning-Best-Practise.pdf WSDL
Versioning Best Practise
-
http://www.infoq.com/resource/articles/Web-Service-Contracts/en/resources/ERL_WSContractVersioning_013613517X_20-22.pdf
Web Service Contract Design and Versioning for SOA (Chapters 20-22)
-
http://www.infosys.com/consulting/soa-services/white-papers/Documents/service-versioning-SOA-1.pdf
Service Versioning in SOA - Part I: Issues in and approaches to Versioning
-
http://www.infosys.com/consulting/soa-services/white-papers/Documents/service-versioning-SOA-2.pdf
Service Versioning in SOA - Part II: Handling the impact of Versioning
-
http://www.activevos.com/content/architects/getting_started/versioningschemasandwsdlsbp.pdf
Versioning Schemas and WSDLs - Best Practices
-
http://wso2.org/library/whitepapers/2011/10/practical-soa-solution-architect
Practical SOA for the Solution Architect (requires reg)
-
http://developer.ebay.com/DevZone/XML/docs/HowTo/eBayWS/eBaySchemaVersioning.html
Schema Versioning Strategy (eBay)
- http://www.infoq.com/articles/contract-versioning-comp2 Contract
Versioning, Compatibility and Composability
- http://www.xml.com/lpt/a/1492 Extensibility, XML Vocabularies, and XML
Schema
-
http://developers.sun.com/jsenterprise/archive/nb_enterprise_pack/reference/techart/design_patterns.html
Introducing Design Patterns in XML Schemas
--
View this message in context: http://cxf.547215.n5.nabble.com/Open-question-about-versionning-tp5095403p5132084.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Open question about versionning?
Posted by Brice Dutheil <br...@gmail.com>.
Le vendredi 6 janvier 2012 à 20:42, Sergey Beryozkin a écrit :
> Hi,
>
> <snip/>
> > > > > 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).
>
> Those providers may offer something else, I checked the source of the
> jaxrs Jackson provider, might be possible,
>
> Benson, do you know by any chance how easy it is to provide a custom
> org.codehaus.jackson.map.ObjectMapper, which will wrap the input stream
> in the CXF specific custom XMLStreamReader and delegate to the default
> Jackson JAXB-aware mapper ?
> May be we may ship such a mapper if it were possible
>
>
This would be interesting because these Jackson and Gson are really performant (GSon is way better than it was). Jackson offer some interesting annotations, while not standard they bring nice features. Gson has less features but it bring versioning annotations.
And we still have to see what will emerge from JSR 353.
> > > > > 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.
> >
> > Basically those are the two options that are right now in my head about implementing verisonning …in the java code part.
> > 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 could make it explicit in the qualified names
> > and / or you can make use of annotations to help versionning support in your model
> >
> >
> >
> >
> >
> > And whatever the case you will probably need to make the link between the implementation and the contracts such as the WSDL or the WADL. So this why I'm going further than only about how a client consumes the service or the resource.
> >
> > Am I clearer ?
> I think so, I was not quite right anyway to suggest that the server-side
> issues are out of scope for the web-services versioning...
>
>
Right now I do not participate or follow what happens or what happened in the expert groups for JAX-RS / JAX-WS or other specs, but this would be interesting to bring "versioning support" discussion on these JSRs.
Anyway as said, this is quite an open minded discussion, no real implementation behind yet, though someday me and others will mind versioning in their application.
Regards,
--
Brice Dutheil
> Cheers, Sergey
>
> >
> >
> > Anyway thanks for the informations :)
> >
> >
> > --
> > Brice
> >
> >
> > > > Cheers, Sergey
> > > >
Re: Open question about versionning?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi,
<snip/>
>>>> 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).
Those providers may offer something else, I checked the source of the
jaxrs Jackson provider, might be possible,
Benson, do you know by any chance how easy it is to provide a custom
org.codehaus.jackson.map.ObjectMapper, which will wrap the input stream
in the CXF specific custom XMLStreamReader and delegate to the default
Jackson JAXB-aware mapper ?
May be we may ship such a mapper if it were possible
>
>>>> 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.
>
> Basically those are the two options that are right now in my head about implementing verisonning …in the java code part.
> 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 could make it explicit in the qualified names
> and / or you can make use of annotations to help versionning support in your model
>
>
>
>
>
> And whatever the case you will probably need to make the link between the implementation and the contracts such as the WSDL or the WADL. So this why I'm going further than only about how a client consumes the service or the resource.
>
> Am I clearer ?
>
I think so, I was not quite right anyway to suggest that the server-side
issues are out of scope for the web-services versioning...
Cheers, Sergey
>
>
> Anyway thanks for the informations :)
>
>
> --
> Brice
>
>
>>> Cheers, Sergey
>>>
>>>>
Re: Open question about versionning?
Posted by Brice Dutheil <br...@gmail.com>.
Please ignore the first message, it got sent too early.
> 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.
Basically those are the two options that are right now in my head about implementing verisonning …in the java code part.
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 could make it explicit in the qualified names
and / or you can make use of annotations to help versionning support in your model
And whatever the case you will probably need to make the link between the implementation and the contracts such as the WSDL or the WADL. So this why I'm going further than only about how a client consumes the service or the resource.
Am I clearer ?
Anyway thanks for the informations :)
--
Brice
> > 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
>
Re: Open question about versionning?
Posted by Brice Dutheil <br...@gmail.com>.
--
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
Re: Open question about versionning?
Posted by Sergey Beryozkin <sb...@gmail.com>.
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