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 <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
>
