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 <[email protected]> > An: [email protected] > 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) <[email protected]>: > > 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
