From axis-dev-return-76689-apmail-ws-axis-dev-archive=ws.apache.org@ws.apache.org Fri Sep 04 01:23:19 2009 Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 16811 invoked from network); 4 Sep 2009 01:23:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 4 Sep 2009 01:23:19 -0000 Received: (qmail 87822 invoked by uid 500); 4 Sep 2009 01:23:18 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 87705 invoked by uid 500); 4 Sep 2009 01:23:18 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 87696 invoked by uid 99); 4 Sep 2009 01:23:18 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Sep 2009 01:23:18 +0000 X-ASF-Spam-Status: No, hits=3.4 required=10.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.212.187] (HELO mail-vw0-f187.google.com) (209.85.212.187) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Sep 2009 01:23:07 +0000 Received: by vws17 with SMTP id 17so396261vws.30 for ; Thu, 03 Sep 2009 18:22:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.78.205 with SMTP id m13mr14289882vck.61.1252027364862; Thu, 03 Sep 2009 18:22:44 -0700 (PDT) In-Reply-To: References: <9b85c45f0908280730w38a88a7eief7bcd459bcdb8f3@mail.gmail.com> <4A97ED94.1080206@gmail.com> <60708f4b0908290244n44cbde1fnccb2e8530d542eab@mail.gmail.com> <4A992E87.9030301@gmail.com> Date: Fri, 4 Sep 2009 06:52:44 +0530 Message-ID: Subject: Re: Supporting hierarchical service deployment From: Sanjiva Weerawarana To: axis-dev@ws.apache.org Content-Type: multipart/alternative; boundary=001636284df254eba90472b65638 X-Virus-Checked: Checked by ClamAV on apache.org --001636284df254eba90472b65638 Content-Type: text/plain; charset=ISO-8859-1 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 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 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 wrote: >>>> >>>>> >>>>> > >>>>> > >>>>> > On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen >>>>> > > >>>>> wrote: >>>>> > >>>>> > Guys, >>>>> > >>>>> > Are we actually discussing the right question? Looking at the >>>>> patch >>>>> > proposed by Isuru, I have the impression that versioning is >>>>> merely one >>>>> > use case, but that (in contrast to modules) the code doesn't 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/ --001636284df254eba90472b65638 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Isuru, hiding the hierarchy from Web infrastructure by using '!' IM= O is a bad idea. What dispatching problems are caused by using /? Why can&#= 39;t those problems be solved?

Sanjiva.

On Thu, Sep 3, 2009 at 3:47 PM, Isuru Suriarachchi <isurues@gmail.com> wrote:<= br>
Hi all,

As using '/' character may cause problems in dispatc= hing, I just used a separate character ('!') to represent the direc= tory hierarchy in the service. This allows all types of services to be depl= oyed 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 lik= e ../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-44= 79). This patch doesn't contain any changes in dispatching logics. = And also I've implemented the ability to deploy JAXWS, Pojo etc.. (whic= h are coming from the axis2.xml) services hierarchically to make this effor= t 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 tha= t 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 servic= es called foo do not use foo as a top level folder in your hierarchy. Its s= imple as that. I guess been careful is the price you have to pay if you wan= na 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 co= ncept baked into Axis2.

Also it would be good to base arguments on f= acts rather than religious beleifs. Quite a few design desicions made back = then when Axis2 was designed did not take stuff such as this into considera= tion. 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 de= ployers (post 1.2 IIRC), the binding hierarchy concept (post 1.3) are featu= res that were added later in the cycle. I see the hierarchical service depl= oyment 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 &l= t;sanjiva@openso= urce.lk> wrote:
I forgot to address the issue with not being able to support RESTful servic= es. I think we can- we just need to change the REST dispatcher (argh if tha= t's what its called its a terrible name!) to look at the context path o= f the service(s) and try filtering those out first.

Sanjiva.


= On Sat, Aug 29, 2009 at 8:51 PM, Sanjiva Weerawarana <= sanjiva@opensour= ce.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 hie= rarchical service deployment. That was a mistake but as Andreas' commen= t pointed out, this is nothing more than the contextPath concept found in J= ava containers. Versioning is at most a special case but let's just tak= e that out of the discussion because this is not about versioning. If you d= isagree 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 usabilit= y 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 a= xis2's default deployers etc. then no problem.

Now I will explain why this approach is better than alternatives. The b= asic 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 libr= ary 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 wha= t 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 marke= ting orgs both want to have a service called "address". That basi= cally makes the fact that what you have are hierarchically named services o= paque to the Web infrastructure. For example, if you were analyzing http lo= gs to see the traffic you can't get a simple answer to "how many t= imes have UK guys' services been used?". That's *exactly* the = kind of wrong-headed thinking that got WS-* in trouble with the REST guys f= or 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 se= rvice 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 i= dea) - the idea was it would override the .aar file name if thats' ther= e. This is similar- you can have in foo.aar a setting saying contextPath=3D= "finance/foo" and that means that's where the service is depl= oyed.

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 SV= N (which I know a bunch of people do) it gives a simple way to manage autho= rization for deployment for different people.

I actually think we should support a contextPath=3Dxxx option in servic= es.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 dep= loyed 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 ol= d 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:
>
> =A0 =A0 Guys,
>
> =A0 =A0 Are we actually discussing the right question? Looking at the = patch
> =A0 =A0 proposed by Isuru, I have the impression that versioning is me= rely one
> =A0 =A0 use case, but that (in contrast to modules) the code doesn'= ;t make any
> =A0 =A0 assumption about the meaning of the hierarchy in the repositor= y (it
> =A0 =A0 could be version number, but it could also something completel= y
> =A0 =A0 different). Fundamentally the change is not about versioning, = but
> =A0 =A0 about giving the user the possibility to define the structure = of the
> =A0 =A0 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<= br> > site people don't put
> all their .jsp or .html files in the root directory. They manage them<= br> > 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 =A0to handle the they want, even in you case we can<= br> do the same. Let's create a new deployer and manage anyway you like, an= d
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 "-&quo= t; 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 a= dd
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 & C= hief Scientist; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Founda= tion; http://www.apach= e.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/

Blog: htt= p://sanjiva.weerawarana.org/



--
Sanjiva Weerawar= ana, Ph.D.
Founder, Director & Chief Scientist; Lanka Software Found= ation; http://www.o= pensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Founda= tion; http://www.apach= e.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/

Blog: htt= p://sanjiva.weerawarana.org/



--
Keith Chapman

blog: http://www.keith-chapman.org



<= /div>
--
Senior Software Engineer,
WSO2 Inc. http://wso2.org/
Blog : http://isurues.wor= dpress.com/



--
Sanjiva Wee= rawarana, Ph.D.
Founder, Director & Chief Scientist; Lanka Software = Foundation; http://www.opensource.lk/=
Founder, Chairman & CEO; WSO2, Inc.; h= ttp://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; Uni= versity of Moratuwa; http://www.cse.m= rt.ac.lk/

Blog: http://sanjiva.weeraw= arana.org/
--001636284df254eba90472b65638--