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

Here are my thoughts on how the @serviceGroup idea might work.  The
relationship to grouping via the targetNamespace or definitions element
has not yet been thoroughly explored.

In WSDL 1.1, a <service> element could contain a number of ports.  Those
ports implementing the same portTypes are assumed to be alternative
bindings to operations of the same "targetResource".  The relationship
between ports implementing different portTypes is not specified, but the
containment within the same <service> implies that the services belong
to a group of some sort.

In the WSDL 1.2 status quo, a <service> contains only endpoints
implementing a single interface.  The targetResource attribute can be
used to describe the relationship "manipulate" with a third entity, the
"target resource".  One can infer a grouping of endpoints that all have
the same relationship ("manipulate") with the same entity
("targetResource").  Part of the rationale for doing this is to link Web
services in with the rest of the Web architecture (through the term
resource), but it's no longer clear that this was helpful to our various
audiences.

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.

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
On
> Behalf Of FABLET Youenn
> Sent: Friday, July 11, 2003 1:24 AM
> To: www-ws-desc@w3.org
> Subject: Can someone recap the differences between @serviceGroup vs.
> definitions-targetNamespace ?
> 
> 
> I am a little bit confused by the serviceGroup debate now that we only
> want to group services (possibly with an attribute @serviceGroup)
> without defining more specifically any relationship between them.
> Service elements can already be grouped through the definitions
element
> or via the targetNamespace. I am not sure to clearly see the
differences
> between these means of grouping and the newly @serviceGroup proposed
> one. Can someone recap why we shouldn't use the definitions element
> (static case)  or targetNamespace (dynamic case) ?
> Clealry WSDL allows to separate services/instances elements
definitions
> from interfaces/classes definitions.
> I believe that in most cases, the owner of the services instances is
> also the owner of the targetNamespace uris and definitions element
> containing those instances. It could be part of a best practice
> guidelines to create definitions elements or targetNamespaces
containing
> only services elements if services grouping semantics are needed...
> 
>     Youenn

Received on Friday, 11 July 2003 14:05:46 UTC