axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Isuru Suriarachchi <isur...@gmail.com>
Subject Re: Supporting hierarchical service deployment
Date Sat, 12 Sep 2009 05:34:29 GMT
Hi all,

On Fri, Sep 4, 2009 at 10:08 AM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:

>
>
> On Fri, Sep 4, 2009 at 6:52 AM, Sanjiva Weerawarana <sanjiva@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 <isurues@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 <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 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 <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:
>>>>>>> >
>>>>>>> >     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/

Mime
View raw message