axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <>
Subject Re: Supporting hierarchical service deployment
Date Sat, 29 Aug 2009 17:24:10 GMT
I forgot to address the issue with not being able to support RESTful
services. I think we can- we just need to change the REST dispatcher (argh
if that's what its called its a terrible name!) to look at the context path
of the service(s) and try filtering those out first.


On Sat, Aug 29, 2009 at 8:51 PM, Sanjiva Weerawarana

> Deepal, I've read this entire thread and I'm confused as to why you're
> objecting.
> 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
> explain why.
> 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/ and / 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
> the mistake).
> 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).
> Sanjiva.
> On Sat, Aug 29, 2009 at 7:05 PM, Deepal jayasinghe <>wrote:
>> >
>> >
>> > On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen
>> > < <>> wrote:
>> >
>> >     Guys,
>> >
>> >     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.
>> >
>> >
>> > 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.
>> :)
>> Thanks,
>> Deepal
> --
> Sanjiva Weerawarana, Ph.D.
> Founder, Director & Chief Scientist; Lanka Software Foundation;
> Founder, Chairman & CEO; WSO2, Inc.;
> Member; Apache Software Foundation;
> Visiting Lecturer; University of Moratuwa;
> Blog:

Sanjiva Weerawarana, Ph.D.
Founder, Director & Chief Scientist; Lanka Software Foundation;
Founder, Chairman & CEO; WSO2, Inc.;
Member; Apache Software Foundation;
Visiting Lecturer; University of Moratuwa;


View raw message