On Fri, Sep 4, 2009 at 11:32 AM, Chinmoy Chakraborty <cch...@gmail.com>wrote:
>
>
> On Fri, Sep 4, 2009 at 10:22 AM, Amila Suriarachchi <
> amilasuriarach...@gmail.com> wrote:
>
>>
>>
>> On Fri, Sep 4, 2009 at 10:05 AM, Chinmoy Chakraborty
>> <cch...@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 <pzf...@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<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
>>>>
>>>
>>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
