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<cch...@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 <isur...@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 <keithgchap...@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
>>> <sanj...@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
>>>> <sanj...@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 <deep...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> >
>>>>>> >
>>>>>> > On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen
>>>>>> > <andreas.veit...@gmail.com <mailto:andreas.veit...@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
p...@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
