axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chinmoy Chakraborty <>
Subject Re: Supporting hierarchical service deployment
Date Thu, 03 Sep 2009 10:59:18 GMT

How about introducing a new parameter (e.g ServiceClassNameSpace) in the
services.xml to support directory hierarchy in the service?


On Thu, Sep 3, 2009 at 3:47 PM, Isuru Suriarachchi <>wrote:

> Hi all,
> As using '/' character may cause problems in dispatching, I just used a
> separate character ('!') to represent the directory hierarchy in the
> service. This allows all types of services to be deployed hierarchically
> without any problems (Including RESTful services).
> Ex: if we deploy the Echo service at
> /repository/services/foo/bar/1.0.0/echo.aar, service name will be
> foo!bar!1.0.0!Echo and the EPR will be like
> ../axis2/services/foo!bar!1.0.0!Echo/echoString
> I've attached a new patch to the JIRA (
> This patch doesn't
> contain any changes in dispatching logics. And also I've implemented the
> ability to deploy JAXWS, Pojo etc.. (which are coming from the axis2.xml)
> services hierarchically to make this effort complete. In addition to that,
> I've written some deployment tests for hierarchical services.
> Thanks,
> ~Isuru
> On Sun, Aug 30, 2009 at 2:48 AM, keith chapman <>wrote:
>> I've been out of touch with the Axis2 list for some time. Took a while to
>> read this thread. Just a few thouths on it.
>> I don't think that this patch would effect the RESTfull behaviour in any
>> way. Its just that the user needs to be extra carefull if he wants to use
>> RESTfull services in cunjunction with the hierarchical services concept. i.e
>> if he has a services called foo do not use foo as a top level folder in your
>> hierarchy. Its simple as that. I guess been careful is the price you have to
>> pay if you wanna use hierarchical services.
>> I like the idea of having hierarchical services in Axis2. Well I did it
>> once using the extension points of Axis2 but I'm +1 for having this concept
>> baked into Axis2.
>> Also it would be good to base arguments on facts rather than religious
>> beleifs. Quite a few design desicions made back then when Axis2 was designed
>> did not take stuff such as this into consideration. Well i'm not blaming the
>> initial Axis2 community for that. As the project evolves new features such
>> as this can be added. Good examples are features such as plugable message
>> builders/formatters (post 1.1), custom deployers (post 1.2 IIRC), the
>> binding hierarchy concept (post 1.3) are features that were added later in
>> the cycle. I see the hierarchical service deployment feature as just another
>> addition to the wide variety of features of Axis2.
>> Thanks,
>> Keith.
>> On Sat, Aug 29, 2009 at 1:24 PM, Sanjiva Weerawarana <
>>> wrote:
>>> 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.
>>> Sanjiva.
>>> On Sat, Aug 29, 2009 at 8:51 PM, Sanjiva Weerawarana <
>>>> wrote:
>>>> 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
>>>> 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
>>>> 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)
>>>> 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
>>>> 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
>>>> 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
>>>>> 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,
>>>>> >     about giving the user the possibility to define the structure
>>>>> 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
>>>>> > 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
>>>>> 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
>>>>> > 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;
>>> Blog:
>> --
>> Keith Chapman
>> blog:
>  --
> Senior Software Engineer,
> WSO2 Inc.
> Blog :

View raw message