RE: [wsrf] Issue: ServiceGroupEntry as a WS-Resource is too Heavyweight.

["Yalcinalp, Umit" <umit.yalcinalp@sap.com>]

Comments/Questions in <umit> tags below.  

-----Original Message-----
From: David Snelling [mailto:David.Snelling@UK.Fujitsu.com] 
Sent: Wednesday, Mar 23, 2005 9:49 AM
To: WSRF
Subject: [wsrf] Issue: ServiceGroupEntry as a WS-Resource is too
Heavyweight.

Issue: ServiceGroupEntry as a WS-Resource is too Heavyweight.

The ServiceGroupEntry is a WS-Resource with lifetime, RPs, and an 
associated EPR. Except for the lifetime information, all information 
associated with it is duplicated in the Entry RPs of the ServiceGroup 
itself. Lifetime MAY also be included in both places, but this is not 
mandated. This duplication creates confusing semantics with respect to 
the coherency of the duplicates.

Furthermore, an EPR is stored in the Entry, returned from the add 
operation, and used by the ServiceGroup and clients to reference the 
ServiceGroupEntry (e.g. for driving a destroy operation to remove the 
service from the group). EPRs however do not possess rich enough 
semantics to serve this function. In particular, they are not 
resilient. What is needed is a reliable 'key' to the Entry. In OGSI 
this was provided by the GirdServiceHandel, which had stronger 
semantics than EPRs.

Specifications:

	- Service Groups

Notes:

Proposed Recommendations:

The recommendation is that the ServiceGroupEntry be removed from the 
ServiceGroup model. The implications of this are:

1) The Entry may need to include it's key as either an element or an 
attribute. I'm not convinced that this is required.

2) The add operation will need to return a 'key' (URI?) that has the 
adequate properties that would allow a client to remove the entry. We 
will also need to include a remove operation to replace destruction of 
the ServiceGroupEntry.

<umit> Can you clarify how the add operation will determine the value of
this key and whether an existing key will be returned if the Entry
already exists? I am wondering whether there is the EPR equality
question that may be lurking there on behalf of ServiceGroup to provide
the mapping to a key value and what that might be. 
</umit>

3) We need to decide what to do about lifetime support for membership 
in a ServiceGroup, the function performed by the ServiceGroupEntry's 
lifetime capability. Options include: 2a) Ignore the issue and let it 
be a property of implementations that extend SG. 2b) Provide an 
(optional) lifetime element within the Entry RP, e.g. 
<MembershipExpires> xsd:dateTime </MembershipExpires>. In this later 
case, SGs have a uniform way to advertise the lifetime of its members 
membership status in the group (note this is not the lifetime of the 
service itself). However, the Registration interface will need an 
operation to manage the lifetime of the Entry, e.g. 
setMembershipExpriyTime (key, time).

Status: Proposed

Contact: David Snelling

Cross Reference: None
-- 

Take care:

     Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
     Fujitsu Laboratories of Europe
     Hayes Park Central
     Hayes End Road
     Hayes, Middlesex  UB4 8FE

     +44-208-606-4649 (Office)
     +44-208-606-4539 (Fax)
     +44-7768-807526  (Mobile)