Hi all, On Fri, Sep 4, 2009 at 10:08 AM, Amila Suriarachchi < amilasuriarach...@gmail.com> wrote:
> > > On Fri, Sep 4, 2009 at 6:52 AM, Sanjiva Weerawarana <sanj...@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 <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/ >>> >> >> >> >> -- >> 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/
