Deepal, I've read this entire thread and I'm confused as to why you're
First of all, I think Isuru sent this thread into a bad start by using
versioning as the reason for wanting to introduce hierarchical service
deployment. That was a mistake but as Andreas' comment pointed out, this is
nothing more than the contextPath concept found in Java containers.
Versioning is at most a special case but let's just take that out of the
discussion because this is not about versioning. If you disagree please
Secondly, this can be done outside of Axis2 totally. All we need to do is
write a new deployer and a dispatcher. There's no need to waste time with
this type of pretty un-objective / emotional debate. However, it was
proposed as a mod to axis2 because it significantly improves axis2 usability
WITHOUT breaking any existing behavior. Or so was the belief. So let's go
thru the discussion and if the view is that this is not necessary in axis2's
default deployers etc. then no problem.
Now I will explain why this approach is better than alternatives. The basic
requirement is that having a single flat naming scheme for services is
unnecessarily limiting. Why? Because it requires everyone to agree on the
service name as those names are global. If you're using Axis2 as a library
on a single developer machine that's not an issue. However, if you want to
deploy an axis2 engine to host some number of services for a larger
organization then that invariably results in name conflicts. I assume you
agree that's global names are a limitation.
How do you fix it? One option is to use some naming convention like what
Java packages did for Java classes. So you can have
/services/us.finance.address and /uk.services/marketing.address if (say) US
finance and UK marketing orgs both want to have a service called "address".
That basically makes the fact that what you have are hierarchically named
services opaque to the Web infrastructure. For example, if you were
analyzing http logs to see the traffic you can't get a simple answer to "how
many times have UK guys' services been used?". That's *exactly* the kind of
wrong-headed thinking that got WS-* in trouble with the REST guys for
improper use of REST (and I'm absolutely one of the early culprits who made
Another approach is to have a way to specify the context path in the service
itself. If you remember, we used to have the concept of service name you
could specify in service.xml itself (maybe its still there; I have no idea)
- the idea was it would override the .aar file name if thats' there. This is
similar- you can have in foo.aar a setting saying contextPath="finance/foo"
and that means that's where the service is deployed.
The advantage of simply using the file system hierarchy to compute that is
just simplicity. The context hierarchy is visible to everyone by simply
looking at the directory structure. If you check in the repository into SVN
(which I know a bunch of people do) it gives a simple way to manage
authorization for deployment for different people.
I actually think we should support a contextPath=xxx option in services.xml
as well. However, treating the file system hierarchy as a hierarchy is, you
know, rather natural.
I think Isuru has shown that there is no extra performance loss or any other
loss by supporting hierachically deployed services. You DON'T need to use
them unless you want to of course - and if there's no hierarchy there's no
change at all (subject to having enough unit tests to make sure that old and
new behavior for the old feature is not changed).
> > On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen
> > <andreas.veithen@gmai... <mailto:andreas.veithen@gmai...>> wrote:
> > Guys,
> > Are we actually discussing the right question? Looking at the patch
> > proposed by Isuru, I have the impression that versioning is merely
> > 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.
> > yes. this should be the idea. it is to support hierarchical service
> > folder structure to mange
> > services. Versioning is only one possible use case.
> > I think this is a common requirement. For an example if we take a web
> > site people don't put
> > all their .jsp or .html files in the root directory. They manage them
> > in a some meaningful
> > folder structure and even page url maps to it.
> You are mistaken in the case of web site .jsp files are like .class
> files. So even in Web Service we have package hierarchy.
> > I can hardly think of any reason for opposing to introduce such
> > feature to axis2 service deployment provided
> > that it *does not break existing functionality*.
> If you look at the directory structure (as I told you before)
> information repeat it self. It is analogous to "Shop is closed because
> it is not open".
> Just because feature X is good in project Y, we should not introduce
> that to Axis2.
> If you or someone want to do such a feature of course they can do that,
> just ad a new deployer to handle the they want, even in you case we can
> do the same. Let's create a new deployer and manage anyway you like, and
> then if you think it is ok, then commit the new deployer to Axis2.
> However I am not ok with introducing new URL pattern, I think Isuru
> already agreed to replace "/" with "-"
> > Deepal,
> > I feel you have given over weight to the versioning support which is a
> > use case of this. In the way to have told
> > people can have versioning without any support of axis2, by just
> > naming service in the way they need.
> Yes. At the end of the day whether it is "/" or "-" would become a
> unique name. So it is the service name.
> > Comming into the other point of probable break of existing
> > functionality Can you please come up with the
> > set of use case scenarios for this? Then we can ask Isuru to provide
> > integration test for all these scenarios. This may test the existing
> > functionality as well :)
> I am sorry I do not have time to comeup with scenarios when someone add
> new features, specially even without going through the existing JIRA.
> > I think we should not be pessimistic and think deployment engine is
> > done for ever and any change will break it.
> Not at all, how many changes we made, in this case my concern is not the
> deployment engine it is the URL pattern.
> > Isuru,
> > Please provide a set of integration tests for the scenarios mentioned.