Re: [wsrf] [NEW ISSUE] Number of messages needed to retrieve the content ofa service group

[Ian Robinson <ian_robinson@uk.ibm.com>]

We have discussed previously (issue 105) whether we should "simplify" SG by
removing ServiceGroupEntry from the SG model and resolved (at the last F2F)
not to do this. We had a fair amount of discussion on this at the F2F and
in earlier telecons.

The heart of this proposed new issue seems to be the means by which
membership of a SG is determined.
The text for the "definitive test" for membership of a SG might be
considered a little onerous and this could be addressed by a resolution to
remove that text (and therefore allowing a degree of implementational
ambiguity) or by a resolution to make the Entry in the SG RPdoc the
authoratative test for membership (as proposed).

Going beyond this to make SGEntries optional changes the semantics of SG
rather more dramatically and we end up not with a means to group
WS-Resources but just with a means to group their RPDocs. This would raise
a number of questions such as: how would you remove an entry?

I wonder whether we really have 2 proposed issues here which are:
i) the authoratative means to determine membership of a SG
ii) the "complexity" of ServiceGroupEntries for ServiceGroups whose
membership is (largely) static.

Regards,
Ian Robinson
STSM, WebSphere Messaging and Transactions Architect
IBM Hursley Lab, UK
ian_robinson@uk.ibm.com


                                                                           
             "Murray, Bryan                                                
             P."                                                           
             <bryan.murray@hp.                                          To 
             com>                      <wsrf@lists.oasis-open.org>         
                                                                        cc 
             20/08/2005 01:18                                              
                                                                   Subject 
                                       [wsrf] [NEW ISSUE] Number of        
                                       messages needed to retrieve the     
                                       content of a service group          
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Title: Number of messages needed to retrieve the content of a service
group

Description:

Section 5 of WS-SG says "The grouping and membership aspects of a
ServiceGroup are only manifest in the linkage between a ServiceGroup
and a ServiceGroupEntry". And section 5.1.2, in the description of
/wsrf-sg:Entry/ServiceGroupEntryEPR says: "Endpoint reference as
defined in [WS-Addressing] to the ServiceGroupEntry WS-Resource with
which the entry is associated. This WS-Resource is the representation
of the membership of the member in the group. Existence of this
WS-Resource is the definitive test that the member is indeed part of
the group. If the WS-Resource referenced by ServiceGroupEntryEPR is
not available, the consumer MUST NOT assume that the Web service
referenced by the @MemberServiceEPR is a member of the service group."

This means that in order to retrieve the membership of a 100-members
service group, one has to send and receive 101 messages. One to retrieve
the resource properties doc of the group and one to each entry. This
is a huge cost and basically means that service groups of more than a
handful of members cannot be used (or only in a very limited way) if
one obeys the spec.

Proposed resolution:

Remove the wording identified above and as a result make the content
of the service group resource properties document the authoritative
source of membership in the service group. Make Entry services
optional, to be used when additional control on the membership (such
as managing the lifecycle of the membership or registering for
notification)
is offered.