Thanks Deepal, this aligns with our thinking here so good to here your views. If you know of any examples out there, I would be interested to see.
On Tue, Oct 21, 2008 at 4:41 PM, Deepal jayasinghe <[EMAIL PROTECTED]>wrote: > Barry Alexander wrote: > > > > Other than "you're on your own" advice, can you provide some > > guidelines or best practices regarding versioning? > > > The only way to get the service version support in Axis2 is to deploy > two different services. And then use their service addresses to > differentiate the two services. If we use this way then the service > version will be automatically visible to outside as well. So for example > if you want to have two version of "foo" service , then you need to have > two different aar files in the repository , called (eg.) foo-1.aar and > foo-2.aar, in addition to that remember the service name of the two > services.xml file should also be different. In other word those will be > two different services in Axis2. > > If you want to have the client transparent version support then one > solution could be to write a handler which does the version based > dispatching. Meaning when a client send a request it will send the > request to the latest service. > > -Deepal > > > > > > > > I thought this was an excellent question and currently of hot > > discussion with my co-workers. > > > > > > > > Some further questions: > > > > > > > > Should message version be embedded as part of SOAP headers using > > WS-Addressing standards? Or part of the wsdl? > > > > Can end point resolution be used during in-flow phases/handlers to > > route services of various versions end points? > > > > Should versioning be handled as part of a 'mediator'? > > > > > > > > On Tue, Oct 21, 2008 at 10:12 AM, Deepal jayasinghe <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > Howell, David wrote: > > > > > > Hi, > > > > > > Is there a recommended or commonly used approach to versioning a > > > service (SOAP, doc/literal) that is to be deployed on Axis2? I'm > > > trying to provide some means of not breaking consumers of an > > existing > > > service if I have to deploy a new version that isn't backwards > > > compatible. We're using AXIOM / no data binding for the service > > > consumers and producers. > > > > > Actually we had some discussion on how to do the version support in > > Axis2 (for service) , but we have not implement that. So only > > option is > > to manage service yourself. > > > > > > In a lot of cases I think I'll just want to move from deploying > > > MyService_V1.aar to deploying MyService_V2.aar. V1 can stay > deployed > > > on the Axis2 server until the consumers have all moved on to V2. > > > > > > I've been looking at including version information in the target > > > namespace specified in the WSDL for the service as a mechanism for > > > consumers to specify which version of the service they want to use. > > > I'm struggling to understand what my options are for deploying > > the old > > > and new versions of my service. Specifically: > > > > > > - I don't seem to need to deploy MyService_V1 and MyService_V2 on > > > different endpoint addresses, but > > > > > > - I assume I do have to give them different names in the <service> > > > element of the wsdl. > > > > > > Is this correct? > > > > > > Finally, is there any way of using a single endpoint and service > > name > > > that accepts requests from consumers that may have different XML > > > namespaces depending on the version of the service they are using? > > > > > > Thanks, > > > > > > Dave > > > > > > > > > -- > > Thank you! > > > > > > http://blogs.deepal.org > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > > > > > -- > Thank you! > > > http://blogs.deepal.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
