Correction: So, IMO, trying to derive the version from a service, module or any other artifact is a bad practice. Also see: http://msdn.microsoft.com/en-us/library/ms954726.aspx
-- Azeez On Fri, Aug 28, 2009 at 2:30 PM, Afkham Azeez <afk...@gmail.com> wrote: > IMHO, service versioning & module versioning are two different things. > Module versioning is purely a deployment time concept, while service > versioning is both a deployment & dispatch time concept. So there is no need > to follow the same way of implementing it. I also think that deriving the > module version from the MAR name is messy, and is not necessarily the best > or better way of implementing it. It should come from the module descriptor; > module.xml. Java archives do not have a standard way of having the version > name in the artifact. That is why OSGi introduced the bundle version in the > manifest file. So, IMO, trying to derive the name from a service, module or > any other artifact is a bad practice. > Unfortunately, there is no standard for Web service versioning, and there > are different ways of implementing it. A popular way is to make the WSDL > targetNamespace and/or the types namespace to contain the version. > > Azeez > > On Fri, Aug 28, 2009 at 1:34 PM, Deepal jayasinghe <deep...@gmail.com>wrote: > >> Hi Isuru, >> >> Thank you for taking your time and looking to this issues, but I do not >> agree the way you have address it, please see my comments below. The >> reason I am telling this is, as I can see this has so many issues, and >> you have made it complicated too :) . I believe you might know that we >> have version support for modules and we do not handle that like this. So >> this simply break the consistency, and this introduce new URL patterns , >> though you have not encounter now, I am sure you are going to face a >> number of issues (when it come to dispatching). >> >> > Currently Axis2 can only deploy services at the repository/services >> > level. This makes it impossible to deploy several versions of the same >> > service. >> I do not agree, you can have the version name in the aar file, for >> example foo-1.0.aar and foo-1.1.aar. Then at the deployment time just >> append the version number to the service name (to make the service name >> unique) >> > >> > Therefore, I've improved our deployment engine to deploy services by >> > looking at the hierarchical path of the service. For example this >> > allows us to deploy a service repository/services/foo/bar/version.aar. >> > And also this allows us to deploy any number of services as follows. >> > repository/services/versionService/1.0.0/version.aar >> > repository/services/versionService/1.0.1/version.aar >> Don't you think this is complex ? what is different between >> "services/versionService/1.0.1/version.aar" and >> "services/version-1.0.1.aar" ?. As far as I know second one is better >> than the first one (and you do not need much modification to handle >> that). Which is the commonly used approach for all sort of version >> management. (am I missing something?) >> > >> > In the implementation, I've attached the hierarchical part of the >> > service (versionService/1.0.1/) in front of the service name which is >> > read from the services.xml. And also I've fixed the URI based >> > dispatching logics to dispatch the services correctly. >> Then how about addressing based dispatching ? >> I remember the mess we had when someone introduce portName into the URL, >> I think we still have issues with that (though no one uses the feature). >> > >> > This improvement doesn't affect any of the existing functionalities. >> Of course it does? how do you make sure when you change the dispatcher >> it does not break any of the existing features ? (we do not have enough >> test cases to cover all the cases) I think I have enough experience in >> Axis2, what when someone change something hoping that does not break >> something. >> > The only limitation of this is we can't deploy a RESTful service in >> > this manner. >> This is a problem right? >> When the system move from one version to other, client will notice that >> the service does not work any more? >> > Those can only be supported at repository/service level. That is >> > because, incoming URL of a RESTful service can contain '/' separated >> > parameters to the service. >> oh boy, you are making system tooooooo, complicated. >> >> I am sorry I am -1 on this approach, we need to discuss this before we >> implement. >> In fact I remember we had some discussion on this at one of the >> apachecon, there also we did not come to a conclusion. >> >> Thanks, >> Deepal >> > > > > -- > Thanks > Afkham Azeez > > Blog: http://afkham.org > Developer Portal: http://www.wso2.org > WSAS Blog: http://wso2wsas.blogspot.com > Company: http://wso2.com > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760 > -- Thanks Afkham Azeez Blog: http://afkham.org Developer Portal: http://www.wso2.org WSAS Blog: http://wso2wsas.blogspot.com Company: http://wso2.com GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
