Re: Can someone recap the differences between @serviceGroup vs. definitions-targetNamespace ?

Sorry for the late reply on this one.

OGSI has the notion of serviceGroup.  This concept in OGSI is more like a
"collection" or "registry" or "directory" of service instances.
Personally, I prefer to consider the concept of OGSI serviceGroup as
analogous to collection classes in Java or Smalltalk.

I am not sure the serviceGroup concept in OGSI is similar to what WSD is
referring to by the term serviceGroup.  What Sanjiva mentions is a WSDL
description of a service and addtional metadata to describe the groups in
which it participates.  The serviceGroup concept in OGSI is more like a
collection class, in that the relationship between the collection and each
member is modelled by the collection and the individual members do not
necessarily know which collections it is a part of.

Therefore I must agree with Sanjiva on his point that @groups is not
terribly useful, as most of the serviceGroups we in the OGSI WG are
imagining are much more dynamic than should be modelled in WSDL.

I would prefer WSD not add a serviceGroup element or attribute to WSDL.

sgg
++++++++
Steve Graham
sggraham@us.ibm.com
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
++++++++



                                                                                                                                       
                      "Sanjiva                                                                                                         
                      Weerawarana"             To:       <www-ws-desc@w3.org>                                                          
                      <sanjiva@watson.i        cc:                                                                                     
                      bm.com>                  Subject:  Re: Can someone recap the differences between @serviceGroup vs.               
                      Sent by:                  definitions-targetNamespace  ?                                                         
                      www-ws-desc-reque                                                                                                
                      st@w3.org                                                                                                        
                                                                                                                                       
                                                                                                                                       
                      07/14/2003 04:12                                                                                                 
                      AM                                                                                                               
                                                                                                                                       
                                                                                                                                       





"Jonathan Marsh" <jmarsh@microsoft.com> writes:
>
> If the remaining concept we wish to express is grouping, the
> targetResource is not the most direct way to achieve this.  Instead of
> introducing the "resource" entity, we can introduce an entity
> representing the "group".  The relationship between endpoint(s) and the
> group is that of "member of", instead of the fuzzier "manipulates".
>
> There are several ways this could be manifested in the syntax:
> a) Add a "serviceGroup" attribute that takes a URI.  The URI is an
> arbitrary identifier for the "group" to which this service belongs.  The
> purpose of the group is defined by the creator of the URI.
> b) Add a <serviceGroup> element to group <service>s together into an
> anonymous group.
> c) Both of a) and b).
> d) Use external mechanisms such as RDF.
> e) Conflate grouping with an existing construct such as <description> or
> @targetNamespace.

So one way I can read this is that by doing
    s/targetResource/serviceGroup/g
(in SED syntax for those not fortunate enough to have had the pleasure
of it) we're getting the concept passed. After all, the membership
criteria for the group can be "all <service>s that manipulate the same
resource", right?

Several people have indicated that a <service> should be able to belong
to zero or more groups:
    <service [groups="list-of-qnames"]> .. </service>
I have to agree that a single group concept is rather artificial.

OGSi (the gridders) have a similar concept *shockingly* called service
group!! The idea is similar (or may even be precisely the same): its
a group of services which meet the required membership criteria. So
I suspect that Steve & Steve should like this approach as they can
model service groups directly at the WSDL level.

While I continue to prefer the more rigid @targetResource concept (yes
I do believe its more rigid/focused than @groups), I can live with this
solution too. I think in most scenarios the grouping is very dynamic; so
I don't expect service/@groups to be widely used. That is, I don't believe
service authors will statically declare what groups they belong to
simply because they won't know that statically. Furthermore, the groups
themselves are unlikely to be static.

I'm a bit surprised that @groups isn't getting trashed like
@targetResource was. To me @groups is even worse at supporting the
multiple interface scenario ..

Sanjiva.

Received on Wednesday, 16 July 2003 13:52:59 UTC