W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2003

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

From: Steve Graham <sggraham@us.ibm.com>
Date: Wed, 16 Jul 2003 12:41:45 -0400
To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>
Cc: www-ws-desc@w3.org, www-ws-desc-request@w3.org
Message-ID: <OFCA6FD4AF.A4BC9FA0-ON85256D65.005B29F3@us.ibm.com>

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.

Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture

                      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  ?                                                         
                      07/14/2003 04:12                                                                                                 

"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
(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 ..

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:31 UTC