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

"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 Monday, 14 July 2003 04:17:17 UTC