You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Isuru Suriarachchi <is...@gmail.com> on 2009/09/03 12:17:22 UTC
Re: Supporting hierarchical service deployment
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 (
https://issues.apache.org/jira/browse/AXIS2-4479). 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 <ke...@gmail.com>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 <
> sanjiva@opensource.lk> 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 <
>> sanjiva@opensource.lk> 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 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/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
>>> 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 <de...@gmail.com>wrote:
>>>
>>>>
>>>> >
>>>> >
>>>> > On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen
>>>> > <andreas.veithen@gmail.com <ma...@gmail.com>> 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;
>>> http://www.opensource.lk/
>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>> Member; Apache Software Foundation; http://www.apache.org/
>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>>
>>> Blog: http://sanjiva.weerawarana.org/
>>>
>>
>>
>>
>> --
>> Sanjiva Weerawarana, Ph.D.
>> Founder, Director & Chief Scientist; Lanka Software Foundation;
>> http://www.opensource.lk/
>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>> Member; Apache Software Foundation; http://www.apache.org/
>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>
>> Blog: http://sanjiva.weerawarana.org/
>>
>
>
>
> --
> Keith Chapman
>
> blog: http://www.keith-chapman.org
>
--
Senior Software Engineer,
WSO2 Inc. http://wso2.org/
Blog : http://isurues.wordpress.com/
Re: Supporting hierarchical service deployment
Posted by Isuru Suriarachchi <is...@gmail.com>.
On Fri, Sep 4, 2009 at 6:52 AM, Sanjiva Weerawarana
<sa...@opensource.lk>wrote:
> Isuru, hiding the hierarchy from Web infrastructure by using '!' IMO is a
> bad idea. What dispatching problems are caused by using /? Why can't those
> problems be solved?
When the '/' character is used, our incoming EPR will be like
../axis2/services/foo/bar/1.0.0/Echo/echoString (operation is optional). In
the URI based service dispatcher, we have to find the service name by
looking at this EPR. In the existing logic, it always finds the service from
the first part after 'services' (foo). So for hierarchical services, that
won't work. That's the problem we are having..
SOLUTION 1
In my previous patch, I used an algorithm as follows..
1. First take the string segment after 'services' -->
foo/bar/1.0.0/Echo/echoString
2. Check whether there's a service from the first part before '/' --> foo
-- This is the existing behaviour
3. If the service is not found in #2, this can be a hierarchical service.
Now check whether there's a service from the name
'foo/bar/1.0.0/Echo/echoString'.
4. If the service is not found in #3, this can be like
<hierarchical-name>/<operation-name> therefore check for a service from the
name 'foo/bar/1.0.0/Echo'.
Limitaioins :
1. Can't support RESTful services in a hierarchical manner. That's because
the EPR can contain any number of parameters into the operation. Ex:
foo/bar/1.0.0/Student/name/xxx/age/yyy
2. You can't have two services foo and foo/bar/1.0.0/foo. All requests will
be dispatched to the foo service.
SOLUTION 2
We can avoid the limitation 1 above by using the following algorithm to find
the service.
1. Split the 'foo/bar/1.0.0/Echo/echoString' part from '/'.
2. Check whether there's a service by adding one part at a time after
starting from foo.
foo
foo/bar
foo/bar/1.0.0
....
We can limit the hierarchical depth to 10 or something to restrict problms
caused by long EPRs.
Limitations :
1. #2 above is still there..
Thanks,
~Isuru
>
> Sanjiva.
>
> On Thu, Sep 3, 2009 at 3:47 PM, Isuru Suriarachchi <is...@gmail.com>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 (
>> https://issues.apache.org/jira/browse/AXIS2-4479). 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 <ke...@gmail.com>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 <
>>> sanjiva@opensource.lk> 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 <
>>>> sanjiva@opensource.lk> 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 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/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
>>>>> 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 <de...@gmail.com>wrote:
>>>>>
>>>>>>
>>>>>> >
>>>>>> >
>>>>>> > On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen
>>>>>> > <andreas.veithen@gmail.com <ma...@gmail.com>>
>>>>>> 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;
>>>>> http://www.opensource.lk/
>>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>>>>
>>>>> Blog: http://sanjiva.weerawarana.org/
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sanjiva Weerawarana, Ph.D.
>>>> Founder, Director & Chief Scientist; Lanka Software Foundation;
>>>> http://www.opensource.lk/
>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>>>
>>>> Blog: http://sanjiva.weerawarana.org/
>>>>
>>>
>>>
>>>
>>> --
>>> Keith Chapman
>>>
>>> blog: http://www.keith-chapman.org
>>>
>>
>>
>>
>> --
>> Senior Software Engineer,
>> WSO2 Inc. http://wso2.org/
>> Blog : http://isurues.wordpress.com/
>>
>
>
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder, Director & Chief Scientist; Lanka Software Foundation;
> http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> Blog: http://sanjiva.weerawarana.org/
>
--
Senior Software Engineer,
WSO2 Inc. http://wso2.org/
Blog : http://isurues.wordpress.com/
Re: Supporting hierarchical service deployment
Posted by Isuru Suriarachchi <is...@gmail.com>.
Hi all,
On Fri, Sep 4, 2009 at 10:08 AM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:
>
>
> On Fri, Sep 4, 2009 at 6:52 AM, Sanjiva Weerawarana <sanjiva@opensource.lk
> > wrote:
>
>> Isuru, hiding the hierarchy from Web infrastructure by using '!' IMO is a
>> bad idea. What dispatching problems are caused by using /? Why can't those
>> problems be solved?
>
>
> I think we can use / and solve any problem if we use the following simple
> logic.
>
> Current eprs (without hierarchical support looks like this)
>
> services/EchoService/Echostring
>
> since there is no hierarchical support we can determine the service name as
> EchoService. (i.e the entry just after services)
>
> with the hierarchical support this looks like this
>
> services/foo/bar/v1.1/EchoService/Echostring
>
> or with Restfull support
>
> services/foo/bar/v1.1/EchoService/Echostring/param1/param2
>
> Now specially in the second case we can not determine the service name at
> once. So the simple solution is to start from foo and check whether there is
> a service available by adding one part at a time until a service found.
>
> eg first try foo
> then try foo/bar
> then try foo/bar/v1.1
> then try foo/bar/v1.1/EchoService until service name found.
>
> When implementing we can tokenise the input string with '/' and check one
> by one. This won't take much time since this is a hash map look up. To avoid
> any Dos attack we can limit this to some number (eg. 10)
>
> So it is basically extending the existing logic to support hierarchical
> services.
>
I've implemented this algorithm in dispatching hierarchical services and
used the '/' character instead of '!'. And also I've added dispatching tests
to cover this functionality. Patch is attached to the JIRA
https://issues.apache.org/jira/browse/AXIS2-4479.
Thanks,
~Isuru
>
> The only limitation is one can not have a service called 'Echo' and a
> directory name 'Echo' in the same folder since all the requests dispatch to
> first service. IMHO this is not a practical limitation.
>
> thanks,
> Amila.
>
>
>> Sanjiva.
>>
>> On Thu, Sep 3, 2009 at 3:47 PM, Isuru Suriarachchi <is...@gmail.com>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 (
>>> https://issues.apache.org/jira/browse/AXIS2-4479). 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 <ke...@gmail.com>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 <
>>>> sanjiva@opensource.lk> 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 <
>>>>> sanjiva@opensource.lk> 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 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/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
>>>>>> 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 <deepalk@gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>>
>>>>>>> >
>>>>>>> >
>>>>>>> > On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen
>>>>>>> > <andreas.veithen@gmail.com <ma...@gmail.com>>
>>>>>>> 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;
>>>>>> http://www.opensource.lk/
>>>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>>>>>
>>>>>> Blog: http://sanjiva.weerawarana.org/
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sanjiva Weerawarana, Ph.D.
>>>>> Founder, Director & Chief Scientist; Lanka Software Foundation;
>>>>> http://www.opensource.lk/
>>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>>>>
>>>>> Blog: http://sanjiva.weerawarana.org/
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Keith Chapman
>>>>
>>>> blog: http://www.keith-chapman.org
>>>>
>>>
>>>
>>>
>>> --
>>> Senior Software Engineer,
>>> WSO2 Inc. http://wso2.org/
>>> Blog : http://isurues.wordpress.com/
>>>
>>
>>
>>
>> --
>> Sanjiva Weerawarana, Ph.D.
>> Founder, Director & Chief Scientist; Lanka Software Foundation;
>> http://www.opensource.lk/
>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>> Member; Apache Software Foundation; http://www.apache.org/
>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>
>> Blog: http://sanjiva.weerawarana.org/
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
--
Senior Software Engineer,
WSO2 Inc. http://wso2.org/
Blog : http://isurues.wordpress.com/
Re: Supporting hierarchical service deployment
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Sep 4, 2009 at 6:52 AM, Sanjiva Weerawarana
<sa...@opensource.lk>wrote:
> Isuru, hiding the hierarchy from Web infrastructure by using '!' IMO is a
> bad idea. What dispatching problems are caused by using /? Why can't those
> problems be solved?
I think we can use / and solve any problem if we use the following simple
logic.
Current eprs (without hierarchical support looks like this)
services/EchoService/Echostring
since there is no hierarchical support we can determine the service name as
EchoService. (i.e the entry just after services)
with the hierarchical support this looks like this
services/foo/bar/v1.1/EchoService/Echostring
or with Restfull support
services/foo/bar/v1.1/EchoService/Echostring/param1/param2
Now specially in the second case we can not determine the service name at
once. So the simple solution is to start from foo and check whether there is
a service available by adding one part at a time until a service found.
eg first try foo
then try foo/bar
then try foo/bar/v1.1
then try foo/bar/v1.1/EchoService until service name found.
When implementing we can tokenise the input string with '/' and check one by
one. This won't take much time since this is a hash map look up. To avoid
any Dos attack we can limit this to some number (eg. 10)
So it is basically extending the existing logic to support hierarchical
services.
The only limitation is one can not have a service called 'Echo' and a
directory name 'Echo' in the same folder since all the requests dispatch to
first service. IMHO this is not a practical limitation.
thanks,
Amila.
> Sanjiva.
>
> On Thu, Sep 3, 2009 at 3:47 PM, Isuru Suriarachchi <is...@gmail.com>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 (
>> https://issues.apache.org/jira/browse/AXIS2-4479). 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 <ke...@gmail.com>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 <
>>> sanjiva@opensource.lk> 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 <
>>>> sanjiva@opensource.lk> 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 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/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
>>>>> 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 <de...@gmail.com>wrote:
>>>>>
>>>>>>
>>>>>> >
>>>>>> >
>>>>>> > On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen
>>>>>> > <andreas.veithen@gmail.com <ma...@gmail.com>>
>>>>>> 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;
>>>>> http://www.opensource.lk/
>>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>>>>
>>>>> Blog: http://sanjiva.weerawarana.org/
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sanjiva Weerawarana, Ph.D.
>>>> Founder, Director & Chief Scientist; Lanka Software Foundation;
>>>> http://www.opensource.lk/
>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>>>
>>>> Blog: http://sanjiva.weerawarana.org/
>>>>
>>>
>>>
>>>
>>> --
>>> Keith Chapman
>>>
>>> blog: http://www.keith-chapman.org
>>>
>>
>>
>>
>> --
>> Senior Software Engineer,
>> WSO2 Inc. http://wso2.org/
>> Blog : http://isurues.wordpress.com/
>>
>
>
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder, Director & Chief Scientist; Lanka Software Foundation;
> http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> Blog: http://sanjiva.weerawarana.org/
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Supporting hierarchical service deployment
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Isuru, hiding the hierarchy from Web infrastructure by using '!' IMO is a
bad idea. What dispatching problems are caused by using /? Why can't those
problems be solved?
Sanjiva.
On Thu, Sep 3, 2009 at 3:47 PM, Isuru Suriarachchi <is...@gmail.com>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 (
> https://issues.apache.org/jira/browse/AXIS2-4479). 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 <ke...@gmail.com>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 <
>> sanjiva@opensource.lk> 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 <
>>> sanjiva@opensource.lk> 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 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/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
>>>> 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 <de...@gmail.com>wrote:
>>>>
>>>>>
>>>>> >
>>>>> >
>>>>> > On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen
>>>>> > <andreas.veithen@gmail.com <ma...@gmail.com>>
>>>>> 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;
>>>> http://www.opensource.lk/
>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>>>
>>>> Blog: http://sanjiva.weerawarana.org/
>>>>
>>>
>>>
>>>
>>> --
>>> Sanjiva Weerawarana, Ph.D.
>>> Founder, Director & Chief Scientist; Lanka Software Foundation;
>>> http://www.opensource.lk/
>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>> Member; Apache Software Foundation; http://www.apache.org/
>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>>
>>> Blog: http://sanjiva.weerawarana.org/
>>>
>>
>>
>>
>> --
>> Keith Chapman
>>
>> blog: http://www.keith-chapman.org
>>
>
>
>
> --
> Senior Software Engineer,
> WSO2 Inc. http://wso2.org/
> Blog : http://isurues.wordpress.com/
>
--
Sanjiva Weerawarana, Ph.D.
Founder, Director & Chief Scientist; Lanka Software Foundation;
http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
Re: Supporting hierarchical service deployment
Posted by Chinmoy Chakraborty <cc...@gmail.com>.
As I mentioned, if we add the namespace/version (if exists) along with
service name including AAR file name, would it be bad design? May be in this
case we do not need extra parameter in services xml. We get all the info
from the AAR file name itself and the service name should also be with the
namespace/version in the services.xml (if we have one).
Chinmoy
On Fri, Sep 4, 2009 at 12:12 PM, Isuru Suriarachchi <is...@gmail.com>wrote:
>
>
> On Fri, Sep 4, 2009 at 11:32 AM, Chinmoy Chakraborty <cc...@gmail.com>wrote:
>
>>
>>
>> On Fri, Sep 4, 2009 at 10:22 AM, Amila Suriarachchi <
>> amilasuriarachchi@gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Sep 4, 2009 at 10:05 AM, Chinmoy Chakraborty <cc...@gmail.com>wrote:
>>>
>>>> Paul,
>>>>
>>>> May be I dropped in from nowhere but I like to understand the idea. What
>>>> is the purpose of maintaining duplicate data by allowing exact same AAR to
>>>> be deployed in two different parts of hierarchy?
>>>>
>>> It is not exact AAR file. It is basically organise your AAR file in a
>>> directory structure without putting all of the in the root directory.
>>>
>>> eg.
>>> repository/services/admin/AdminService.aar
>>> repository/services/management/Management.aar
>>> repository/services/tech/v1.1/Tech.aar
>>> repository/services/tech/v1.0/Tech.aar
>>>
>>> if you take latter two cases, it may be two versions of same .aar file
>>> which user wants to active at the same time.
>>>
>>
>> CHINMOY>> OK.
>>
>>
>>>
>>>
>>>> I guess Axis2 should also support same service name with different
>>>> namespaces. I have this kind of requirement in our project but right now
>>>> it's a limitation.
>>>>
>>> if you can describe your requirement then we can see how it can be
>>> supported.
>>>
>>> As I understood what you want to have is same service name with different
>>> name spaces to distinguish the version.
>>> (I assume version depends on the namespace in your case)
>>>
>>
>> CHINMOY>> Not exactly. I have two different services with same service
>> name and they do absolutely two different tasks. let me explain: I have one
>> function called ABS (returns absolute value, generally long) and a
>> routine called ABS (does some other work than ABS function). Let's say
>> the namespace for ABS function is abc.function.ABS and the namespace for
>> ABS routine is abc.routine.ABS.
>>
>> So we can have two different services for the same service name. In AXIS
>> 1.x we could do that since there was concept of jws deployment and the
>> directory structure was part of the url.
>>
>>>
>>> Now the problem is what is the epr for these two services. In the above
>>> solution epr is mapped to the folder structure. So people can invoke two
>>> services with different eprs.
>>>
>>> In your solution how to determine the service to invoke once a request
>>> receive?
>>>
>>
>> CHINMOY>> If we have a parameter in services.xml like
>> <serviceNameSpace>abc.function/routine</serviceNameSpace> then in the url
>> the service name should be appened with namespace. e.g
>>
>> ../services/ABS (now)
>> ../service/abc.function.ABS
>>
>> The logic should be just add namespace along with the servicename and the
>> namespace is available from the services.xml.
>>
>
> Then how are we going to do this for the services like POJO, JAXWS etc..
> which doesn't contain a services.xml?
>
> And also, even with AAR services, you have to name your .aar file
> differently as they are in the same folder.
>
> Actually hierarchical services using directories address wider range of
> problems. It allows you to manage your services separately as you wish.
> That is the natural way of managing stuff. And also that concept caters your
> requirement as well.
>
> Put your first ABS service in abc/function/ folder.
> Put your second ABS service in abc/routine/ folder.
>
> Thanks,
> ~Isuru
>
>
>>
>> Chinmoy
>>
>>>
>>> thanks,
>>> Amila.
>>>
>>>>
>>>> Chinmoy
>>>>
>>>> On Thu, Sep 3, 2009 at 4:46 PM, Paul Fremantle <pz...@gmail.com>wrote:
>>>>
>>>>> Chinmoy
>>>>>
>>>>> I think that is cool, but I guess the aim of Isuru's initial proposal
>>>>> was to allow the exact same AAR to be deployed independently in two
>>>>> parts of the hierarchy. To me that is a good objective.
>>>>>
>>>>> Paul
>>>>>
>>>>> On Thu, Sep 3, 2009 at 11:59 AM, Chinmoy Chakraborty<cc...@gmail.com>
>>>>> wrote:
>>>>> > Guys,
>>>>> >
>>>>> > How about introducing a new parameter (e.g ServiceClassNameSpace) in
>>>>> the
>>>>> > services.xml to support directory hierarchy in the service?
>>>>> >
>>>>> > Chinmoy
>>>>> >
>>>>> > On Thu, Sep 3, 2009 at 3:47 PM, Isuru Suriarachchi <
>>>>> isurues@gmail.com>
>>>>> > 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
>>>>> >> (https://issues.apache.org/jira/browse/AXIS2-4479). 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 <
>>>>> keithgchapman@gmail.com>
>>>>> >> 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
>>>>> >>> <sa...@opensource.lk> 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
>>>>> >>>> <sa...@opensource.lk> 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 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/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
>>>>> >>>>> 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 <
>>>>> deepalk@gmail.com>
>>>>> >>>>> wrote:
>>>>> >>>>>>
>>>>> >>>>>> >
>>>>> >>>>>> >
>>>>> >>>>>> > On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen
>>>>> >>>>>> > <andreas.veithen@gmail.com <mailto:andreas.veithen@gmail.com
>>>>> >>
>>>>> >>>>>> > 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;
>>>>> >>>>> http://www.opensource.lk/
>>>>> >>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>>>> >>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>>> >>>>> Visiting Lecturer; University of Moratuwa;
>>>>> http://www.cse.mrt.ac.lk/
>>>>> >>>>>
>>>>> >>>>> Blog: http://sanjiva.weerawarana.org/
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> --
>>>>> >>>> Sanjiva Weerawarana, Ph.D.
>>>>> >>>> Founder, Director & Chief Scientist; Lanka Software Foundation;
>>>>> >>>> http://www.opensource.lk/
>>>>> >>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>>>> >>>> Member; Apache Software Foundation; http://www.apache.org/
>>>>> >>>> Visiting Lecturer; University of Moratuwa;
>>>>> http://www.cse.mrt.ac.lk/
>>>>> >>>>
>>>>> >>>> Blog: http://sanjiva.weerawarana.org/
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> --
>>>>> >>> Keith Chapman
>>>>> >>>
>>>>> >>> blog: http://www.keith-chapman.org
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Senior Software Engineer,
>>>>> >> WSO2 Inc. http://wso2.org/
>>>>> >> Blog : http://isurues.wordpress.com/
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Paul Fremantle
>>>>> Co-Founder and CTO, WSO2
>>>>> Apache Synapse PMC Chair
>>>>> OASIS WS-RX TC Co-chair
>>>>>
>>>>> blog: http://pzf.fremantle.org
>>>>> paul@wso2.com
>>>>>
>>>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Amila Suriarachchi
>>> WSO2 Inc.
>>> blog: http://amilachinthaka.blogspot.com/
>>>
>>
>>
>
>
> --
> Senior Software Engineer,
> WSO2 Inc. http://wso2.org/
> Blog : http://isurues.wordpress.com/
>
Re: Supporting hierarchical service deployment
Posted by Isuru Suriarachchi <is...@gmail.com>.
On Fri, Sep 4, 2009 at 11:32 AM, Chinmoy Chakraborty <cc...@gmail.com>wrote:
>
>
> On Fri, Sep 4, 2009 at 10:22 AM, Amila Suriarachchi <
> amilasuriarachchi@gmail.com> wrote:
>
>>
>>
>> On Fri, Sep 4, 2009 at 10:05 AM, Chinmoy Chakraborty <cc...@gmail.com>wrote:
>>
>>> Paul,
>>>
>>> May be I dropped in from nowhere but I like to understand the idea. What
>>> is the purpose of maintaining duplicate data by allowing exact same AAR to
>>> be deployed in two different parts of hierarchy?
>>>
>> It is not exact AAR file. It is basically organise your AAR file in a
>> directory structure without putting all of the in the root directory.
>>
>> eg.
>> repository/services/admin/AdminService.aar
>> repository/services/management/Management.aar
>> repository/services/tech/v1.1/Tech.aar
>> repository/services/tech/v1.0/Tech.aar
>>
>> if you take latter two cases, it may be two versions of same .aar file
>> which user wants to active at the same time.
>>
>
> CHINMOY>> OK.
>
>
>>
>>
>>> I guess Axis2 should also support same service name with different
>>> namespaces. I have this kind of requirement in our project but right now
>>> it's a limitation.
>>>
>> if you can describe your requirement then we can see how it can be
>> supported.
>>
>> As I understood what you want to have is same service name with different
>> name spaces to distinguish the version.
>> (I assume version depends on the namespace in your case)
>>
>
> CHINMOY>> Not exactly. I have two different services with same service name
> and they do absolutely two different tasks. let me explain: I have one
> function called ABS (returns absolute value, generally long) and a routinecalled ABS (does some other work than ABS function). Let's say the namespace
> for ABS function is abc.function.ABS and the namespace for ABS routine is
> abc.routine.ABS.
>
> So we can have two different services for the same service name. In AXIS
> 1.x we could do that since there was concept of jws deployment and the
> directory structure was part of the url.
>
>>
>> Now the problem is what is the epr for these two services. In the above
>> solution epr is mapped to the folder structure. So people can invoke two
>> services with different eprs.
>>
>> In your solution how to determine the service to invoke once a request
>> receive?
>>
>
> CHINMOY>> If we have a parameter in services.xml like
> <serviceNameSpace>abc.function/routine</serviceNameSpace> then in the url
> the service name should be appened with namespace. e.g
>
> ../services/ABS (now)
> ../service/abc.function.ABS
>
> The logic should be just add namespace along with the servicename and the
> namespace is available from the services.xml.
>
Then how are we going to do this for the services like POJO, JAXWS etc..
which doesn't contain a services.xml?
And also, even with AAR services, you have to name your .aar file
differently as they are in the same folder.
Actually hierarchical services using directories address wider range of
problems. It allows you to manage your services separately as you wish.
That is the natural way of managing stuff. And also that concept caters your
requirement as well.
Put your first ABS service in abc/function/ folder.
Put your second ABS service in abc/routine/ folder.
Thanks,
~Isuru
>
> Chinmoy
>
>>
>> thanks,
>> Amila.
>>
>>>
>>> Chinmoy
>>>
>>> On Thu, Sep 3, 2009 at 4:46 PM, Paul Fremantle <pz...@gmail.com>wrote:
>>>
>>>> Chinmoy
>>>>
>>>> I think that is cool, but I guess the aim of Isuru's initial proposal
>>>> was to allow the exact same AAR to be deployed independently in two
>>>> parts of the hierarchy. To me that is a good objective.
>>>>
>>>> Paul
>>>>
>>>> On Thu, Sep 3, 2009 at 11:59 AM, Chinmoy Chakraborty<cc...@gmail.com>
>>>> wrote:
>>>> > Guys,
>>>> >
>>>> > How about introducing a new parameter (e.g ServiceClassNameSpace) in
>>>> the
>>>> > services.xml to support directory hierarchy in the service?
>>>> >
>>>> > Chinmoy
>>>> >
>>>> > On Thu, Sep 3, 2009 at 3:47 PM, Isuru Suriarachchi <isurues@gmail.com
>>>> >
>>>> > 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
>>>> >> (https://issues.apache.org/jira/browse/AXIS2-4479). 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 <
>>>> keithgchapman@gmail.com>
>>>> >> 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
>>>> >>> <sa...@opensource.lk> 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
>>>> >>>> <sa...@opensource.lk> 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 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/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
>>>> >>>>> 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 <
>>>> deepalk@gmail.com>
>>>> >>>>> wrote:
>>>> >>>>>>
>>>> >>>>>> >
>>>> >>>>>> >
>>>> >>>>>> > On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen
>>>> >>>>>> > <andreas.veithen@gmail.com <ma...@gmail.com>>
>>>> >>>>>> > 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;
>>>> >>>>> http://www.opensource.lk/
>>>> >>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>>> >>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>> >>>>> Visiting Lecturer; University of Moratuwa;
>>>> http://www.cse.mrt.ac.lk/
>>>> >>>>>
>>>> >>>>> Blog: http://sanjiva.weerawarana.org/
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> --
>>>> >>>> Sanjiva Weerawarana, Ph.D.
>>>> >>>> Founder, Director & Chief Scientist; Lanka Software Foundation;
>>>> >>>> http://www.opensource.lk/
>>>> >>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>>> >>>> Member; Apache Software Foundation; http://www.apache.org/
>>>> >>>> Visiting Lecturer; University of Moratuwa;
>>>> http://www.cse.mrt.ac.lk/
>>>> >>>>
>>>> >>>> Blog: http://sanjiva.weerawarana.org/
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> --
>>>> >>> Keith Chapman
>>>> >>>
>>>> >>> blog: http://www.keith-chapman.org
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Senior Software Engineer,
>>>> >> WSO2 Inc. http://wso2.org/
>>>> >> Blog : http://isurues.wordpress.com/
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Paul Fremantle
>>>> Co-Founder and CTO, WSO2
>>>> Apache Synapse PMC Chair
>>>> OASIS WS-RX TC Co-chair
>>>>
>>>> blog: http://pzf.fremantle.org
>>>> paul@wso2.com
>>>>
>>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>>
>>>
>>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
>
>
--
Senior Software Engineer,
WSO2 Inc. http://wso2.org/
Blog : http://isurues.wordpress.com/
Re: Supporting hierarchical service deployment
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Sep 4, 2009 at 11:32 AM, Chinmoy Chakraborty <cc...@gmail.com>wrote:
>
>
> On Fri, Sep 4, 2009 at 10:22 AM, Amila Suriarachchi <
> amilasuriarachchi@gmail.com> wrote:
>
>>
>>
>> On Fri, Sep 4, 2009 at 10:05 AM, Chinmoy Chakraborty <cc...@gmail.com>wrote:
>>
>>> Paul,
>>>
>>> May be I dropped in from nowhere but I like to understand the idea. What
>>> is the purpose of maintaining duplicate data by allowing exact same AAR to
>>> be deployed in two different parts of hierarchy?
>>>
>> It is not exact AAR file. It is basically organise your AAR file in a
>> directory structure without putting all of the in the root directory.
>>
>> eg.
>> repository/services/admin/AdminService.aar
>> repository/services/management/Management.aar
>> repository/services/tech/v1.1/Tech.aar
>> repository/services/tech/v1.0/Tech.aar
>>
>> if you take latter two cases, it may be two versions of same .aar file
>> which user wants to active at the same time.
>>
>
> CHINMOY>> OK.
>
>
>>
>>
>>> I guess Axis2 should also support same service name with different
>>> namespaces. I have this kind of requirement in our project but right now
>>> it's a limitation.
>>>
>> if you can describe your requirement then we can see how it can be
>> supported.
>>
>> As I understood what you want to have is same service name with different
>> name spaces to distinguish the version.
>> (I assume version depends on the namespace in your case)
>>
>
> CHINMOY>> Not exactly. I have two different services with same service name
> and they do absolutely two different tasks. let me explain: I have one
> function called ABS (returns absolute value, generally long) and a routinecalled ABS (does some other work than ABS function). Let's say the namespace
> for ABS function is abc.function.ABS and the namespace for ABS routine is
> abc.routine.ABS.
>
> So we can have two different services for the same service name. In AXIS
> 1.x we could do that since there was concept of jws deployment and the
> directory structure was part of the url.
>
This is what now we going to add to Axis2 :)
Once we add this, in your case you can have to ABS services like this
repository/services/abc/function/ABS.aar
repository/services/abc/routine/ABS.aar
Then two services maps to the urls (epr) like this
services/abc/function/ABS
services/abc/routine/ABS
I think this is the proper solution for your problem.
I think, you tend to think in the way you think because Axis2 currently does
not have this concept. This is why this concept is important.
thanks,
Amila.
>
>> Now the problem is what is the epr for these two services. In the above
>> solution epr is mapped to the folder structure. So people can invoke two
>> services with different eprs.
>>
>> In your solution how to determine the service to invoke once a request
>> receive?
>>
>
> CHINMOY>> If we have a parameter in services.xml like
> <serviceNameSpace>abc.function/routine</serviceNameSpace> then in the url
> the service name should be appened with namespace. e.g
>
> ../services/ABS (now)
> ../service/abc.function.ABS
>
> The logic should be just add namespace along with the servicename and the
> namespace is available from the services.xml.
>
> Chinmoy
>
>>
>> thanks,
>> Amila.
>>
>>>
>>> Chinmoy
>>>
>>> On Thu, Sep 3, 2009 at 4:46 PM, Paul Fremantle <pz...@gmail.com>wrote:
>>>
>>>> Chinmoy
>>>>
>>>> I think that is cool, but I guess the aim of Isuru's initial proposal
>>>> was to allow the exact same AAR to be deployed independently in two
>>>> parts of the hierarchy. To me that is a good objective.
>>>>
>>>> Paul
>>>>
>>>> On Thu, Sep 3, 2009 at 11:59 AM, Chinmoy Chakraborty<cc...@gmail.com>
>>>> wrote:
>>>> > Guys,
>>>> >
>>>> > How about introducing a new parameter (e.g ServiceClassNameSpace) in
>>>> the
>>>> > services.xml to support directory hierarchy in the service?
>>>> >
>>>> > Chinmoy
>>>> >
>>>> > On Thu, Sep 3, 2009 at 3:47 PM, Isuru Suriarachchi <isurues@gmail.com
>>>> >
>>>> > 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
>>>> >> (https://issues.apache.org/jira/browse/AXIS2-4479). 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 <
>>>> keithgchapman@gmail.com>
>>>> >> 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
>>>> >>> <sa...@opensource.lk> 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
>>>> >>>> <sa...@opensource.lk> 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 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/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
>>>> >>>>> 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 <
>>>> deepalk@gmail.com>
>>>> >>>>> wrote:
>>>> >>>>>>
>>>> >>>>>> >
>>>> >>>>>> >
>>>> >>>>>> > On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen
>>>> >>>>>> > <andreas.veithen@gmail.com <ma...@gmail.com>>
>>>> >>>>>> > 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;
>>>> >>>>> http://www.opensource.lk/
>>>> >>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>>> >>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>> >>>>> Visiting Lecturer; University of Moratuwa;
>>>> http://www.cse.mrt.ac.lk/
>>>> >>>>>
>>>> >>>>> Blog: http://sanjiva.weerawarana.org/
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> --
>>>> >>>> Sanjiva Weerawarana, Ph.D.
>>>> >>>> Founder, Director & Chief Scientist; Lanka Software Foundation;
>>>> >>>> http://www.opensource.lk/
>>>> >>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>>> >>>> Member; Apache Software Foundation; http://www.apache.org/
>>>> >>>> Visiting Lecturer; University of Moratuwa;
>>>> http://www.cse.mrt.ac.lk/
>>>> >>>>
>>>> >>>> Blog: http://sanjiva.weerawarana.org/
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> --
>>>> >>> Keith Chapman
>>>> >>>
>>>> >>> blog: http://www.keith-chapman.org
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Senior Software Engineer,
>>>> >> WSO2 Inc. http://wso2.org/
>>>> >> Blog : http://isurues.wordpress.com/
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Paul Fremantle
>>>> Co-Founder and CTO, WSO2
>>>> Apache Synapse PMC Chair
>>>> OASIS WS-RX TC Co-chair
>>>>
>>>> blog: http://pzf.fremantle.org
>>>> paul@wso2.com
>>>>
>>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>>
>>>
>>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Supporting hierarchical service deployment
Posted by Chinmoy Chakraborty <cc...@gmail.com>.
On Fri, Sep 4, 2009 at 10:22 AM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:
>
>
> On Fri, Sep 4, 2009 at 10:05 AM, Chinmoy Chakraborty <cc...@gmail.com>wrote:
>
>> Paul,
>>
>> May be I dropped in from nowhere but I like to understand the idea. What
>> is the purpose of maintaining duplicate data by allowing exact same AAR to
>> be deployed in two different parts of hierarchy?
>>
> It is not exact AAR file. It is basically organise your AAR file in a
> directory structure without putting all of the in the root directory.
>
> eg.
> repository/services/admin/AdminService.aar
> repository/services/management/Management.aar
> repository/services/tech/v1.1/Tech.aar
> repository/services/tech/v1.0/Tech.aar
>
> if you take latter two cases, it may be two versions of same .aar file
> which user wants to active at the same time.
>
CHINMOY>> OK.
>
>
>> I guess Axis2 should also support same service name with different
>> namespaces. I have this kind of requirement in our project but right now
>> it's a limitation.
>>
> if you can describe your requirement then we can see how it can be
> supported.
>
> As I understood what you want to have is same service name with different
> name spaces to distinguish the version.
> (I assume version depends on the namespace in your case)
>
CHINMOY>> Not exactly. I have two different services with same service name
and they do absolutely two different tasks. let me explain: I have one
function called ABS (returns absolute value, generally long) and a
routinecalled ABS (does some other work than ABS function). Let's say
the namespace
for ABS function is abc.function.ABS and the namespace for ABS routine is
abc.routine.ABS.
So we can have two different services for the same service name. In AXIS 1.x
we could do that since there was concept of jws deployment and the directory
structure was part of the url.
>
> Now the problem is what is the epr for these two services. In the above
> solution epr is mapped to the folder structure. So people can invoke two
> services with different eprs.
>
> In your solution how to determine the service to invoke once a request
> receive?
>
CHINMOY>> If we have a parameter in services.xml like
<serviceNameSpace>abc.function/routine</serviceNameSpace> then in the url
the service name should be appened with namespace. e.g
../services/ABS (now)
../service/abc.function.ABS
The logic should be just add namespace along with the servicename and the
namespace is available from the services.xml.
Chinmoy
>
> thanks,
> Amila.
>
>>
>> Chinmoy
>>
>> On Thu, Sep 3, 2009 at 4:46 PM, Paul Fremantle <pz...@gmail.com>wrote:
>>
>>> Chinmoy
>>>
>>> I think that is cool, but I guess the aim of Isuru's initial proposal
>>> was to allow the exact same AAR to be deployed independently in two
>>> parts of the hierarchy. To me that is a good objective.
>>>
>>> Paul
>>>
>>> On Thu, Sep 3, 2009 at 11:59 AM, Chinmoy Chakraborty<cc...@gmail.com>
>>> wrote:
>>> > Guys,
>>> >
>>> > How about introducing a new parameter (e.g ServiceClassNameSpace) in
>>> the
>>> > services.xml to support directory hierarchy in the service?
>>> >
>>> > Chinmoy
>>> >
>>> > On Thu, Sep 3, 2009 at 3:47 PM, Isuru Suriarachchi <is...@gmail.com>
>>> > 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
>>> >> (https://issues.apache.org/jira/browse/AXIS2-4479). 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 <
>>> keithgchapman@gmail.com>
>>> >> 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
>>> >>> <sa...@opensource.lk> 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
>>> >>>> <sa...@opensource.lk> 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 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/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
>>> >>>>> 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 <
>>> deepalk@gmail.com>
>>> >>>>> wrote:
>>> >>>>>>
>>> >>>>>> >
>>> >>>>>> >
>>> >>>>>> > On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen
>>> >>>>>> > <andreas.veithen@gmail.com <ma...@gmail.com>>
>>> >>>>>> > 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;
>>> >>>>> http://www.opensource.lk/
>>> >>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>> >>>>> Member; Apache Software Foundation; http://www.apache.org/
>>> >>>>> Visiting Lecturer; University of Moratuwa;
>>> http://www.cse.mrt.ac.lk/
>>> >>>>>
>>> >>>>> Blog: http://sanjiva.weerawarana.org/
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Sanjiva Weerawarana, Ph.D.
>>> >>>> Founder, Director & Chief Scientist; Lanka Software Foundation;
>>> >>>> http://www.opensource.lk/
>>> >>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>> >>>> Member; Apache Software Foundation; http://www.apache.org/
>>> >>>> Visiting Lecturer; University of Moratuwa;
>>> http://www.cse.mrt.ac.lk/
>>> >>>>
>>> >>>> Blog: http://sanjiva.weerawarana.org/
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Keith Chapman
>>> >>>
>>> >>> blog: http://www.keith-chapman.org
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Senior Software Engineer,
>>> >> WSO2 Inc. http://wso2.org/
>>> >> Blog : http://isurues.wordpress.com/
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Paul Fremantle
>>> Co-Founder and CTO, WSO2
>>> Apache Synapse PMC Chair
>>> OASIS WS-RX TC Co-chair
>>>
>>> blog: http://pzf.fremantle.org
>>> paul@wso2.com
>>>
>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
Re: Supporting hierarchical service deployment
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Sep 4, 2009 at 10:05 AM, Chinmoy Chakraborty <cc...@gmail.com>wrote:
> Paul,
>
> May be I dropped in from nowhere but I like to understand the idea. What is
> the purpose of maintaining duplicate data by allowing exact same AAR to be
> deployed in two different parts of hierarchy?
>
It is not exact AAR file. It is basically organise your AAR file in a
directory structure without putting all of the in the root directory.
eg.
repository/services/admin/AdminService.aar
repository/services/management/Management.aar
repository/services/tech/v1.1/Tech.aar
repository/services/tech/v1.0/Tech.aar
if you take latter two cases, it may be two versions of same .aar file which
user wants to active at the same time.
> I guess Axis2 should also support same service name with different
> namespaces. I have this kind of requirement in our project but right now
> it's a limitation.
>
if you can describe your requirement then we can see how it can be
supported.
As I understood what you want to have is same service name with different
name spaces to distinguish the version.
(I assume version depends on the namespace in your case)
Now the problem is what is the epr for these two services. In the above
solution epr is mapped to the folder structure. So people can invoke two
services with different eprs.
In your solution how to determine the service to invoke once a request
receive?
thanks,
Amila.
>
> Chinmoy
>
> On Thu, Sep 3, 2009 at 4:46 PM, Paul Fremantle <pz...@gmail.com> wrote:
>
>> Chinmoy
>>
>> I think that is cool, but I guess the aim of Isuru's initial proposal
>> was to allow the exact same AAR to be deployed independently in two
>> parts of the hierarchy. To me that is a good objective.
>>
>> Paul
>>
>> On Thu, Sep 3, 2009 at 11:59 AM, Chinmoy Chakraborty<cc...@gmail.com>
>> wrote:
>> > Guys,
>> >
>> > How about introducing a new parameter (e.g ServiceClassNameSpace) in the
>> > services.xml to support directory hierarchy in the service?
>> >
>> > Chinmoy
>> >
>> > On Thu, Sep 3, 2009 at 3:47 PM, Isuru Suriarachchi <is...@gmail.com>
>> > 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
>> >> (https://issues.apache.org/jira/browse/AXIS2-4479). 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 <
>> keithgchapman@gmail.com>
>> >> 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
>> >>> <sa...@opensource.lk> 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
>> >>>> <sa...@opensource.lk> 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 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/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
>> >>>>> 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 <
>> deepalk@gmail.com>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> >
>> >>>>>> >
>> >>>>>> > On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen
>> >>>>>> > <andreas.veithen@gmail.com <ma...@gmail.com>>
>> >>>>>> > 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;
>> >>>>> http://www.opensource.lk/
>> >>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>> >>>>> Member; Apache Software Foundation; http://www.apache.org/
>> >>>>> Visiting Lecturer; University of Moratuwa;
>> http://www.cse.mrt.ac.lk/
>> >>>>>
>> >>>>> Blog: http://sanjiva.weerawarana.org/
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Sanjiva Weerawarana, Ph.D.
>> >>>> Founder, Director & Chief Scientist; Lanka Software Foundation;
>> >>>> http://www.opensource.lk/
>> >>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>> >>>> Member; Apache Software Foundation; http://www.apache.org/
>> >>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>> >>>>
>> >>>> Blog: http://sanjiva.weerawarana.org/
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Keith Chapman
>> >>>
>> >>> blog: http://www.keith-chapman.org
>> >>
>> >>
>> >>
>> >> --
>> >> Senior Software Engineer,
>> >> WSO2 Inc. http://wso2.org/
>> >> Blog : http://isurues.wordpress.com/
>> >
>> >
>>
>>
>>
>> --
>> Paul Fremantle
>> Co-Founder and CTO, WSO2
>> Apache Synapse PMC Chair
>> OASIS WS-RX TC Co-chair
>>
>> blog: http://pzf.fremantle.org
>> paul@wso2.com
>>
>> "Oxygenating the Web Service Platform", www.wso2.com
>>
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Supporting hierarchical service deployment
Posted by Chinmoy Chakraborty <cc...@gmail.com>.
Paul,
May be I dropped in from nowhere but I like to understand the idea. What is
the purpose of maintaining duplicate data by allowing exact same AAR to be
deployed in two different parts of hierarchy?
I guess Axis2 should also support same service name with different
namespaces. I have this kind of requirement in our project but right now
it's a limitation.
Chinmoy
On Thu, Sep 3, 2009 at 4:46 PM, Paul Fremantle <pz...@gmail.com> wrote:
> Chinmoy
>
> I think that is cool, but I guess the aim of Isuru's initial proposal
> was to allow the exact same AAR to be deployed independently in two
> parts of the hierarchy. To me that is a good objective.
>
> Paul
>
> On Thu, Sep 3, 2009 at 11:59 AM, Chinmoy Chakraborty<cc...@gmail.com>
> wrote:
> > Guys,
> >
> > How about introducing a new parameter (e.g ServiceClassNameSpace) in the
> > services.xml to support directory hierarchy in the service?
> >
> > Chinmoy
> >
> > On Thu, Sep 3, 2009 at 3:47 PM, Isuru Suriarachchi <is...@gmail.com>
> > 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
> >> (https://issues.apache.org/jira/browse/AXIS2-4479). 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 <keithgchapman@gmail.com
> >
> >> 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
> >>> <sa...@opensource.lk> 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
> >>>> <sa...@opensource.lk> 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 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/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
> >>>>> 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 <
> deepalk@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> >
> >>>>>> >
> >>>>>> > On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen
> >>>>>> > <andreas.veithen@gmail.com <ma...@gmail.com>>
> >>>>>> > 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;
> >>>>> http://www.opensource.lk/
> >>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> >>>>> Member; Apache Software Foundation; http://www.apache.org/
> >>>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >>>>>
> >>>>> Blog: http://sanjiva.weerawarana.org/
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Sanjiva Weerawarana, Ph.D.
> >>>> Founder, Director & Chief Scientist; Lanka Software Foundation;
> >>>> http://www.opensource.lk/
> >>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> >>>> Member; Apache Software Foundation; http://www.apache.org/
> >>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >>>>
> >>>> Blog: http://sanjiva.weerawarana.org/
> >>>
> >>>
> >>>
> >>> --
> >>> Keith Chapman
> >>>
> >>> blog: http://www.keith-chapman.org
> >>
> >>
> >>
> >> --
> >> Senior Software Engineer,
> >> WSO2 Inc. http://wso2.org/
> >> Blog : http://isurues.wordpress.com/
> >
> >
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
Re: Supporting hierarchical service deployment
Posted by Paul Fremantle <pz...@gmail.com>.
Chinmoy
I think that is cool, but I guess the aim of Isuru's initial proposal
was to allow the exact same AAR to be deployed independently in two
parts of the hierarchy. To me that is a good objective.
Paul
On Thu, Sep 3, 2009 at 11:59 AM, Chinmoy Chakraborty<cc...@gmail.com> wrote:
> Guys,
>
> How about introducing a new parameter (e.g ServiceClassNameSpace) in the
> services.xml to support directory hierarchy in the service?
>
> Chinmoy
>
> On Thu, Sep 3, 2009 at 3:47 PM, Isuru Suriarachchi <is...@gmail.com>
> 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
>> (https://issues.apache.org/jira/browse/AXIS2-4479). 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 <ke...@gmail.com>
>> 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
>>> <sa...@opensource.lk> 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
>>>> <sa...@opensource.lk> 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 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/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
>>>>> 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 <de...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> >
>>>>>> >
>>>>>> > On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen
>>>>>> > <andreas.veithen@gmail.com <ma...@gmail.com>>
>>>>>> > 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;
>>>>> http://www.opensource.lk/
>>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>>>>
>>>>> Blog: http://sanjiva.weerawarana.org/
>>>>
>>>>
>>>>
>>>> --
>>>> Sanjiva Weerawarana, Ph.D.
>>>> Founder, Director & Chief Scientist; Lanka Software Foundation;
>>>> http://www.opensource.lk/
>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>>>
>>>> Blog: http://sanjiva.weerawarana.org/
>>>
>>>
>>>
>>> --
>>> Keith Chapman
>>>
>>> blog: http://www.keith-chapman.org
>>
>>
>>
>> --
>> Senior Software Engineer,
>> WSO2 Inc. http://wso2.org/
>> Blog : http://isurues.wordpress.com/
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
Re: Supporting hierarchical service deployment
Posted by Chinmoy Chakraborty <cc...@gmail.com>.
Guys,
How about introducing a new parameter (e.g ServiceClassNameSpace) in the
services.xml to support directory hierarchy in the service?
Chinmoy
On Thu, Sep 3, 2009 at 3:47 PM, Isuru Suriarachchi <is...@gmail.com>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 (
> https://issues.apache.org/jira/browse/AXIS2-4479). 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 <ke...@gmail.com>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 <
>> sanjiva@opensource.lk> 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 <
>>> sanjiva@opensource.lk> 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 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/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
>>>> 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 <de...@gmail.com>wrote:
>>>>
>>>>>
>>>>> >
>>>>> >
>>>>> > On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen
>>>>> > <andreas.veithen@gmail.com <ma...@gmail.com>>
>>>>> 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;
>>>> http://www.opensource.lk/
>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>>>
>>>> Blog: http://sanjiva.weerawarana.org/
>>>>
>>>
>>>
>>>
>>> --
>>> Sanjiva Weerawarana, Ph.D.
>>> Founder, Director & Chief Scientist; Lanka Software Foundation;
>>> http://www.opensource.lk/
>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>> Member; Apache Software Foundation; http://www.apache.org/
>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>>
>>> Blog: http://sanjiva.weerawarana.org/
>>>
>>
>>
>>
>> --
>> Keith Chapman
>>
>> blog: http://www.keith-chapman.org
>>
>
>
>
> --
> Senior Software Engineer,
> WSO2 Inc. http://wso2.org/
> Blog : http://isurues.wordpress.com/
>