Andreas, you are right. It is not only about the version number. The
hierarchy may semantically reflect the version number. It could be used for
many things. e.g. in a multi-user/multi-tenant deployment, all services of a
particular user/tenant can be stored under a certain directory. This
structure is also reflected in the endpoint addresses.
> Are we actually discussing the right question? Looking at the patch
> proposed by Isuru, I have the impression that versioning is merely one
> use case, but that (in contrast to modules) the code doesn't make any
> assumption about the meaning of the hierarchy in the repository (it
> could be version number, but it could also something completely
> different). Fundamentally the change is not about versioning, but
> about giving the user the possibility to define the structure of the
> endpoint URL.
> I share Deepal's concern about the possible impact of this change. He
> mentioned the WS-Addressing case, but I believe that this change will
> also break autogeneration of WSDLs: probably the endpoint URLs in the
> WSDLs will be wrong.
> On Fri, Aug 28, 2009 at 16:45, Deepal jayasinghe<deepalk@gmai...> wrote:
> >> IMHO, service versioning & module versioning are two different things.
> >> Module versioning is purely a deployment time concept,
> > of course not, we can have two different version of the same module and
> > engage the one we want based on our requirement, it is not deployment
> > concept, it is also there in run time too.
> >> 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.
> > There is a way that you can specify the name in the module.xml.
> > It may be messy, but we discussed in the mailing list and implement that
> > way.
> >> 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.
> > I do not mind having version number in the services.xml, but I do not
> > agree the way Isuru has implemented the version support.
> > File name has to be unique right? I mean just because OSGi handle the
> > version number using manifest file file name has to have the version
> > number of some sort of unique suffix right?
> >> 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.
> > I agree, sometime you need to reflect the version form tns and URL.
> >> Azeez
> >> On Fri, Aug 28, 2009 at 1:34 PM, Deepal jayasinghe <deepalk@gmai... > >> <mailto:deepalk@gmai...>> 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,
> >> you have made it complicated too :) . I believe you might know that
> >> 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
> >> > 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
> >> append the version number to the service name (to make the service
> >> name
> >> unique)
> >> >
> >> > Therefore, I've improved our deployment engine to deploy services
> >> > 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
> >> > 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
> >> 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
> >> Of course it does? how do you make sure when you change the
> >> 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
> >> 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
> >> > 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 '/'
> >> > 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
> > --
> > Thank you!
> > http://blogs.deepal.org > > http://deepal.org > >