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/
