axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amila Suriarachchi <>
Subject Re: Supporting hierarchical service deployment
Date Sat, 29 Aug 2009 13:19:55 GMT
On Fri, Aug 28, 2009 at 7:04 PM, Deepal jayasinghe <>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)

This may be a possible way of doing versioning. But IMHO not the best way.
Please have a look at here[1]. If we follow what you have mentioned here
then we need to add
all files of axis2 versions into one folder and rename them as pom-1.5.xml,
pom-1.4.xml etc. No need to say this is a mess.
Consider a situation where you have 10 services and 5 versions. you can ask
the question why
can't you keep all in one folder. But the practical way is to have them in
separate folders with the version numbers.

So if we have the hierarchical deployment we can have directory based



> >
> > 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

Amila Suriarachchi
WSO2 Inc.

View raw message