Ajith, Good stuff. Let's start with implementing this and see what else crops up :)
thanks, dims On 9/12/05, Ajith Ranabahu <[EMAIL PROTECTED]> wrote: > 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 -- Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
