You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by "Salgar, Mehmet (external)" <Me...@external.t-mobile.de> on 2009/12/01 09:16:14 UTC
Service Versioning - How to handle this scenerio
Hi everybody,
I have a question and theory about how to handle service versioning...
As you may guess, in our project for backward .compatiblity purposes, we
are offering older versions of our services up-to 6 months....
Our current way of solving this way is to created differently named
artifacts in our maven structures (like service_a_v1, service_a_v2m...).
I find this extremely ugly and I have another idea but I am not sure I
can implement it or not (may be you can give me a better idea...)
The best solution would be naturally is to provide a common endpoint and
this endpoint decide itself where delegate the service implementation.
Every service version naturally has another wsdl, this is actually an
advantage and disadvantge...
It is an advantage, while with the wsdl I can understand which
implementation I have to call. It is a disadvantage, while calls to this
one endpoint can't satisfy the three wsdl...
So what I think, also like to ask that is possible or not, is to provide
a http endpoint that is not bound to a wsdl, accepts the request and
looks to the namespace of the request and redirects the message a real
webservice endpoint with correct wsdl and implementation....
Do you think is it possible? Or how do you solve this versioning problem
in your projects....
Thx for the answers...
T-Mobile Deutschland GmbH
Aufsichtsrat: Timotheus Hottges (Vorsitzender)
Geschaftsfuhrung: Niek Jan van Damme (Sprecher), Thomas Berlemann, Thomas Dannenfeldt, Albert Henn,
Dr. Christian P. Illek, Dr. Bruno Jacobfeuerborn, Dr. Dirk Rohweder
Handelsregister: Amtsgericht Bonn, HRB 59 19
Sitz der Gesellschaft: Bonn
WEEE-Reg.-Nr.: DE60800328
Re: Service Versioning - How to handle this scenerio
Posted by Kai Lüdersdorff <lu...@gmx.de>.
Hello,
we provide a major version number to the endpoint URI:
http://localhost:8080/OnlineSearchService/v1
This endpoint of ServiceMix acts as a fascade and we have to assure that new releases are backward compatible regarding the wsdl. A client must be able to use the given URI even if we make modification to the wsdl like adding new operations.
A second endpoint with incompatible changes would contain the incremented version number:
http://localhost:8080/OnlineSearchService/v2
Regards
Kai Lüdersdorff
-------- Original-Nachricht --------
> Datum: Tue, 1 Dec 2009 12:16:14 +0100
> Von: Gert Vanthienen <ge...@gmail.com>
> An: users@servicemix.apache.org
> Betreff: Re: Service Versioning - How to handle this scenerio
> L.S.,
>
> If you provide a single endpoint, it becomes hard for ServiceMix to
> provide the wsdl from that URI. E.g. if you now have a URI
> http://localhost:8192/myservice, the wsdl is available at
> http://localhost:8192/myservice?wsdl. I'm not sure how that would
> work if there are actually three distinct wsdl for the uri.
>
> However, if you're not depending on the wsdl being available at the
> endpoint uri like this, you can definitely use this implementation
> technique. You would have a generic HTTP consumer endpoint that is
> capable of receiving the SOAP message and then sends it to a
> content-based router. The content-based router can then look in the
> message payload to determine the correct service implementation and
> forward the request to the right CXF-SE service implementation.
>
> Regards,
>
> Gert Vanthienen
> ------------------------
> Open Source SOA: http://fusesource.com
> Blog: http://gertvanthienen.blogspot.com/
>
>
>
> 2009/12/1 Salgar, Mehmet (external) <Me...@external.t-mobile.de>:
> > Hi everybody,
> >
> > I have a question and theory about how to handle service versioning...
> >
> > As you may guess, in our project for backward .compatiblity purposes, we
> > are offering older versions of our services up-to 6 months....
> >
> > Our current way of solving this way is to created differently named
> > artifacts in our maven structures (like service_a_v1, service_a_v2m...).
> > I find this extremely ugly and I have another idea but I am not sure I
> > can implement it or not (may be you can give me a better idea...)
> >
> > The best solution would be naturally is to provide a common endpoint and
> > this endpoint decide itself where delegate the service implementation.
> > Every service version naturally has another wsdl, this is actually an
> > advantage and disadvantge...
> >
> > It is an advantage, while with the wsdl I can understand which
> > implementation I have to call. It is a disadvantage, while calls to this
> > one endpoint can't satisfy the three wsdl...
> >
> > So what I think, also like to ask that is possible or not, is to provide
> > a http endpoint that is not bound to a wsdl, accepts the request and
> > looks to the namespace of the request and redirects the message a real
> > webservice endpoint with correct wsdl and implementation....
> >
> > Do you think is it possible? Or how do you solve this versioning problem
> > in your projects....
> >
> > Thx for the answers...
> >
> >
> > T-Mobile Deutschland GmbH
> > Aufsichtsrat: Timotheus Hottges (Vorsitzender)
> > Geschaftsfuhrung: Niek Jan van Damme (Sprecher), Thomas Berlemann,
> Thomas Dannenfeldt, Albert Henn,
> > Dr. Christian P. Illek, Dr. Bruno Jacobfeuerborn, Dr. Dirk Rohweder
> > Handelsregister: Amtsgericht Bonn, HRB 59 19
> > Sitz der Gesellschaft: Bonn
> > WEEE-Reg.-Nr.: DE60800328
> >
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
Re: Service Versioning - How to handle this scenerio
Posted by Gert Vanthienen <ge...@gmail.com>.
L.S.,
If you provide a single endpoint, it becomes hard for ServiceMix to
provide the wsdl from that URI. E.g. if you now have a URI
http://localhost:8192/myservice, the wsdl is available at
http://localhost:8192/myservice?wsdl. I'm not sure how that would
work if there are actually three distinct wsdl for the uri.
However, if you're not depending on the wsdl being available at the
endpoint uri like this, you can definitely use this implementation
technique. You would have a generic HTTP consumer endpoint that is
capable of receiving the SOAP message and then sends it to a
content-based router. The content-based router can then look in the
message payload to determine the correct service implementation and
forward the request to the right CXF-SE service implementation.
Regards,
Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
2009/12/1 Salgar, Mehmet (external) <Me...@external.t-mobile.de>:
> Hi everybody,
>
> I have a question and theory about how to handle service versioning...
>
> As you may guess, in our project for backward .compatiblity purposes, we
> are offering older versions of our services up-to 6 months....
>
> Our current way of solving this way is to created differently named
> artifacts in our maven structures (like service_a_v1, service_a_v2m...).
> I find this extremely ugly and I have another idea but I am not sure I
> can implement it or not (may be you can give me a better idea...)
>
> The best solution would be naturally is to provide a common endpoint and
> this endpoint decide itself where delegate the service implementation.
> Every service version naturally has another wsdl, this is actually an
> advantage and disadvantge...
>
> It is an advantage, while with the wsdl I can understand which
> implementation I have to call. It is a disadvantage, while calls to this
> one endpoint can't satisfy the three wsdl...
>
> So what I think, also like to ask that is possible or not, is to provide
> a http endpoint that is not bound to a wsdl, accepts the request and
> looks to the namespace of the request and redirects the message a real
> webservice endpoint with correct wsdl and implementation....
>
> Do you think is it possible? Or how do you solve this versioning problem
> in your projects....
>
> Thx for the answers...
>
>
> T-Mobile Deutschland GmbH
> Aufsichtsrat: Timotheus Hottges (Vorsitzender)
> Geschaftsfuhrung: Niek Jan van Damme (Sprecher), Thomas Berlemann, Thomas Dannenfeldt, Albert Henn,
> Dr. Christian P. Illek, Dr. Bruno Jacobfeuerborn, Dr. Dirk Rohweder
> Handelsregister: Amtsgericht Bonn, HRB 59 19
> Sitz der Gesellschaft: Bonn
> WEEE-Reg.-Nr.: DE60800328
>