----- Original Message -----
Sent: Monday, September 12, 2005 5:36
PM
Subject: [Axis2] More about service
groups
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)
>>>>>>>>>>>>>>>>>>>>>>>>>>
I think we do not need to introduce new archive
file or description to solve this problem , so my idea is this
no matter archive file contain a service or
service-group, the archive file contain service.xml and the it will be like
that
<services >
<service name="Service1">
...........................
............................
</service>
<service name="Service2">
...........................
............................
</service>
</services>
So the existing service.xml has to change to this
format,
and the name of the archive file will be that
name of the service group , if the name of the archive file is foo.aar then
service-group name will be "foo" and the epr of the services
will axis2/services/foo:Service1
and axis2/services/foo:Service2
In addition to that META-INF folder can contain
any number of wsdl file , in this case that can contain
Service1.wsdl , Service2.wsdl in that case
ServiceDescriptions will be created using WSDLs and overide and configure
using srevice.xml
>>>>>>>>>>>>>>>>>>>>>>>>>>>
* 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
