[Axis2] More about service groups

[Ajith Ranabahu]

Hi all,
We had some discussions among ourselves about the Service groups (refer the IRC chat on 31st of August) and came up with some suggesions. Following is a brief account of what was discussed and how we sought out possible solution.
For the folks who are not familiar with the whole business of service groups, the idea is to deploy a group of services at once (The current implementation allows the deploying of single services only.). Refer to the chat log at http://marc.theaimsgroup.com/?l=axis-dev&m=112549326807148&w=2 for more information on what was mentioned at the initial discussion)

Ok. Back to the original discussion. These are the things that seems to be  needed.

* Introduce a new description and a context. It was decided to call this "ServiceGroup" (context/ description) [Hopefully I'm not starting another naming war here :)] to avoid confusion. These will lie in between the Service  and  Configuration in the respective hierarchies. The archive will have either a service descriptor xml with a single service description or a group description xml with multiple service descriptions. (Again the  naming of the descriptor files is open to discussion. I guess the names service.xml and serviceGroup.xml would be fine for now)

* With the introduction of service groups springs up some issues that requires us to look back (perhaps redefine some of the concepts).

     * How to keep the consistancy? User can deploy services and service groups in a mix !
       The solution to this would be to introduce a default service group per service. So logically all services will live in a service group. The settled way is to have a service group with the name of the service and attach the service as anonymous to that group.

     * Should the group concept be visible to the outside ?
       No. Even if the services live in groups, groups are not visible to the outside world and the services are accessible directly without    going through the group. However the service authors have the flexibility to use service names in the scope of service groups (i.e. service names need only be unique within a service group) so to avoid confusion, the name of the service for the outside world will be service group name : service name. For a service group containing a single service, just the group name would suffice.

     * How to dispatch the services ? Now there is a service group to be identified !
       Actually Service group makes it easier to identify the services. Find the service group and the search is narrowed!  For the URL based dispatcher the modified service name will do. However when addressing is present, a reference property will be the right way to enforce it. The suggested name of the reference property is "axis2:serviceGroupContextId".

Again the discussion of these contexts leads to a rethinking of the lifetimes of the contexts. For now these are the suggested life times for the contexts.
 OperationContext - For an operation instance. The operation context should terminate when the last message relating to it's MEP is sent/received.
 ServiceContext - For a service instance. A service instantiates when a call comes to one of it's operations. It is possible to have multiple service conetexts  lying around (probably per user)
ServiceGroup - This is the tricky one. This should be in scope across services hence it's more in the scope of a session! For the Http case it can directly be mapped to the http session.

That should be enough for the concepts :) Thoughts anyone ?
                                                                                                                      

--
Ajith Ranabahu