[axis2] service groups (from chat)

[Sanjiva Weerawarana <sa...@opensource.lk>]

I'm *really* sorry for not being able to make it to the chat, but I
vehemently disagree with one of the apparent decisions of the chat. Its
about the question of visibility of services inside service groups to
other people.

If we're going to add service groups into 1.0 then let's add them
properly. The reason we were pushing to get this in AFAIU was to make
1.0 architecturally complete, and doing a half job does not cut it in my
book. So either we should drop it or do it right .. and now we've
started doing it already; so we have to come to an agreement on what's
"doing it right" :). [Remember that I was against putting it into 1.0 at
all but we decided to do it .. so let's do it right.]

Let's see whether we can agree on the functionality first and then worry
about how to implement it:

1. There is a semantic to service groups; they are not just a convenient
packaging mechanism that is lost at runtime. So if you use the admin
tool and look at a running system, you will see the service groups etc..
Without service groups existing as a real thing, the value they add is
very little. NOTE: the fact that they exist in the engine does not mean
users are aware of it. In particular, users *only* know about services
and know nothing about service groups. See #4 also below.

2. Service groups have the behavior that they share a single service
group context per running service group "instance." This IMO is what
makes service groups interesting - basically the fact that you can share
some state across the different services that belong to a group. Of
course, if you have such a beast then you need to have a way to find
yourself back into a service group instance for subsequent requests.
Doing that requires some correlation key to flow in the message (HTTP
session cookie, reference property, whatever) and for the dispatching
logic to take this into account and dispatch to the instance. 

3. The fact that there is a shared context instance makes service groups
have a session nature to them. This IMO is a necessary feature - if
there's no way to share some state across a group of service instances
which belong to the same group then there's not much value of having
service groups. This is the same behavior at least I had envisioned (and
I thought Glen had advocated?) for the SessionContext stuff which we
never finished .. and which we have now coerced into
ServiceGroupContext.

4. As service groups are packaged as single .aar's, there is no way one
can say that a service S1 in foo.aar will collide with another service
named S1 in a separate bar.aar. If we require all services in all
service groups to be named distinctly, then we are telling users to not
only be aware of already deployed .aar names (which is what we do now
and which is fine) but also that they need to examine each .aar and for
those .aar's which are in fact groups, look at all the names users have
picked for <service>s which are inside the aar and avoid those too.
That's absolutely unacceptable! Thus, services within a service group
are logically "local" to the service group and the names must never
collide. 

5. Following up on the same topic, since service groups are not exposed
to users (clients), the URL of the EPR must somehow carry sufficient
info to indicate which service the message is being targeted to. That's
why one needs some way to have the service group name and the service
name become part of the URL. We came up with the idea of using ":" as
the separator to combine the service group name and the service name to
create the external service name because that's not an XML name
character and it works perfectly for this scenario: the externally
visible name looks like a fixed string but we (the people who create the
EPR) know a bit more and will interpret it as a 2-part string.

OK that's all for now .. more as we continue the discussion.

Sanjiva.

Re: [axis2] service groups (from chat)

[Deepal Jayasinghe <de...@opensource.lk>]

Hi Dev;

I changed code to make sure that a service name is unique across the system 
, but I really really do not like to make the service name unique in this 
way by enforcing service author to do so.

In that case two service author can not write there services independently , 
meaning one service author has to know what are the services in the system. 
Therefore we break the idea of service isolation, because we can not 
download Axis2 service and use that. My idea is for 1.0 keep this but we 
definitely have to improve that.



Thanks,
 Deepal
................................................................
~Future is Open~

----- Original Message ----- 
From: "Sanjiva Weerawarana" <sa...@opensource.lk>
To: <di...@apache.org>
Cc: <ax...@ws.apache.org>
Sent: Thursday, September 15, 2005 11:01 AM
Subject: Re: [axis2] service groups (from chat)


> Hi Dims,
>
>> Guiding principle was that our Service Group concept is an internal
>> detail that should not be visible in any of the artifacts (WSDL, EPR)
>> or on the wire.
>
> +1.
>
>> Let's get enough implementation experience with this
>> before we go the whole hog. Am not convinced that we should let it
>> "leak" via EPR's (as in #5). Also please see below:
>
> The issue of course is whether a string that looks like a string to the
> outsides is a leak .. see my comments under #4.
>
>> #1 - No one said that we should not show SG's in UI's. It's ok to do so.
>> #2 and #3 - We still need to do them, yes, they should work the way
>> you outlined it.
>
> OK cool.
>
>> #4 - is a simple matter of throwing an exception on deployment, it's
>> easy to change it later (depending on #5)
>
> OK let's compromise .. let's do the pattern where we keep the names flat
> (as in a string without colons) for now and we can throw an exception on
> deployment (as you propose above). If (when ;-)) this becomes a problem
> we'll decide how to put the SG name into the URL so we don't have to
> tell users to rename stuff.
>
>> #5 - ':' apprears in IPv6 (and seems non REST-ful).
>
> I agree its non RESTful .. but making it RESTful (which I'd prefer) will
> amount to showing the SG concept in the URLs explicitly. Its kinda neat
> though because then we could have
> SG/SN[/op_name[/message_name[/msgid]]] .. totally RESTful way to refer
> to everything.
>
> Definitely post 1.0 :).
>
>> Let's get some code working w/o leaking our SG's, go thru the Alpha at
>> least and take a checkpoint later if life becomes unbearable.
>
> +1.
>
> Sanjiva.
>
>
> 

Re: [axis2] service groups (from chat)

[Sanjiva Weerawarana <sa...@opensource.lk>]

Hi Dims,

> Guiding principle was that our Service Group concept is an internal
> detail that should not be visible in any of the artifacts (WSDL, EPR)
> or on the wire. 

+1.

> Let's get enough implementation experience with this
> before we go the whole hog. Am not convinced that we should let it
> "leak" via EPR's (as in #5). Also please see below:

The issue of course is whether a string that looks like a string to the
outsides is a leak .. see my comments under #4.

> #1 - No one said that we should not show SG's in UI's. It's ok to do so.
> #2 and #3 - We still need to do them, yes, they should work the way
> you outlined it.

OK cool.

> #4 - is a simple matter of throwing an exception on deployment, it's
> easy to change it later (depending on #5)

OK let's compromise .. let's do the pattern where we keep the names flat
(as in a string without colons) for now and we can throw an exception on
deployment (as you propose above). If (when ;-)) this becomes a problem
we'll decide how to put the SG name into the URL so we don't have to
tell users to rename stuff. 

> #5 - ':' apprears in IPv6 (and seems non REST-ful). 

I agree its non RESTful .. but making it RESTful (which I'd prefer) will
amount to showing the SG concept in the URLs explicitly. Its kinda neat
though because then we could have
SG/SN[/op_name[/message_name[/msgid]]] .. totally RESTful way to refer
to everything. 

Definitely post 1.0 :).

> Let's get some code working w/o leaking our SG's, go thru the Alpha at
> least and take a checkpoint later if life becomes unbearable.

+1.

Sanjiva.

Re: [axis2] service groups (from chat)

[Davanum Srinivas <da...@gmail.com>]

Sanjiva,

Guiding principle was that our Service Group concept is an internal
detail that should not be visible in any of the artifacts (WSDL, EPR)
or on the wire. Let's get enough implementation experience with this
before we go the whole hog. Am not convinced that we should let it
"leak" via EPR's (as in #5). Also please see below:

#1 - No one said that we should not show SG's in UI's. It's ok to do so.
#2 and #3 - We still need to do them, yes, they should work the way
you outlined it.
#4 - is a simple matter of throwing an exception on deployment, it's
easy to change it later (depending on #5)
#5 - ':' apprears in IPv6 (and seems non REST-ful). 

Let's get some code working w/o leaking our SG's, go thru the Alpha at
least and take a checkpoint later if life becomes unbearable.

Thanks,
dims

On 9/14/05, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> I'm *really* sorry for not being able to make it to the chat, but I
> vehemently disagree with one of the apparent decisions of the chat. Its
> about the question of visibility of services inside service groups to
> other people.
> 
> If we're going to add service groups into 1.0 then let's add them
> properly. The reason we were pushing to get this in AFAIU was to make
> 1.0 architecturally complete, and doing a half job does not cut it in my
> book. So either we should drop it or do it right .. and now we've
> started doing it already; so we have to come to an agreement on what's
> "doing it right" :). [Remember that I was against putting it into 1.0 at
> all but we decided to do it .. so let's do it right.]
> 
> Let's see whether we can agree on the functionality first and then worry
> about how to implement it:
> 
> 1. There is a semantic to service groups; they are not just a convenient
> packaging mechanism that is lost at runtime. So if you use the admin
> tool and look at a running system, you will see the service groups etc..
> Without service groups existing as a real thing, the value they add is
> very little. NOTE: the fact that they exist in the engine does not mean
> users are aware of it. In particular, users *only* know about services
> and know nothing about service groups. See #4 also below.
> 
> 2. Service groups have the behavior that they share a single service
> group context per running service group "instance." This IMO is what
> makes service groups interesting - basically the fact that you can share
> some state across the different services that belong to a group. Of
> course, if you have such a beast then you need to have a way to find
> yourself back into a service group instance for subsequent requests.
> Doing that requires some correlation key to flow in the message (HTTP
> session cookie, reference property, whatever) and for the dispatching
> logic to take this into account and dispatch to the instance.
> 
> 3. The fact that there is a shared context instance makes service groups
> have a session nature to them. This IMO is a necessary feature - if
> there's no way to share some state across a group of service instances
> which belong to the same group then there's not much value of having
> service groups. This is the same behavior at least I had envisioned (and
> I thought Glen had advocated?) for the SessionContext stuff which we
> never finished .. and which we have now coerced into
> ServiceGroupContext.
> 
> 4. As service groups are packaged as single .aar's, there is no way one
> can say that a service S1 in foo.aar will collide with another service
> named S1 in a separate bar.aar. If we require all services in all
> service groups to be named distinctly, then we are telling users to not
> only be aware of already deployed .aar names (which is what we do now
> and which is fine) but also that they need to examine each .aar and for
> those .aar's which are in fact groups, look at all the names users have
> picked for <service>s which are inside the aar and avoid those too.
> That's absolutely unacceptable! Thus, services within a service group
> are logically "local" to the service group and the names must never
> collide.
> 
> 5. Following up on the same topic, since service groups are not exposed
> to users (clients), the URL of the EPR must somehow carry sufficient
> info to indicate which service the message is being targeted to. That's
> why one needs some way to have the service group name and the service
> name become part of the URL. We came up with the idea of using ":" as
> the separator to combine the service group name and the service name to
> create the external service name because that's not an XML name
> character and it works perfectly for this scenario: the externally
> visible name looks like a fixed string but we (the people who create the
> EPR) know a bit more and will interpret it as a 2-part string.
> 
> OK that's all for now .. more as we continue the discussion.
> 
> Sanjiva.
> 
> 


-- 
Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform