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

At 11:05 AM 7/11/2003, Jonathan Marsh wrote:

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

My rationale for supporting targetResource was partially to address the 
Grid requirements and partially to address what I saw as a major problem.

It was not to introduce a general grouping relationship.

The question that targetResource was intended to *help* answer was typified 
by the example of having a printer PRINT interface and a printer PRINTADM 
interface. The question was how can i tell when an instance of the PRINT 
interface and an instance of the PRINTADM interface are operating on the 
"same" printer.

Currently the only way to do this is to define operations on both the PRINT 
and PRINTADM interfaces that can explicitly answer the question. Probably 
the simplest is to define a getTargetResource operation that returns an id 
(a URI?) that is different when they are manipulating different printers, 
and the same when they are manipulating the same printer. Obviously there 
are a million different schemes that can be dreamed up.

My motivation for adding targetResource was to provide a simple, uniform 
way that designers could take advantage of. They weren't forced to. If they 
wanted to have a more complex, robust scheme they could still define their 
own operations, etc. However, it is my belief that we could solve a great 
many cases rather simply by adopting this approach. 80/20, 70/30 ???

The issue I have with changing the notion to group membership is that there 
is no definition, even a loosey/goosey one, of what said membership means. 
Take my example above of PRINT and PRINTADM. I don't think I can infer 
anything useful about the fact that 2 instances have the same group id. It 
might mean they manipulate the same printer, but it might just as well mean 
that they manipulate printers made by the same manufacturer, possibly the 
same printer model, or maybe the printers they manipulate are owned by the 
same company, or are located in the same building.

Personally, I thought the notion that we have of targetResouce served a 
useful purpose in many, many cases. I can't see any real world useful 
purpose in this notion of service group. as currently defined.

So i'm afraid i'd vote to either keep targetResource as is (modulo some 
wordsmithing which I don't think is needed since manipulate is adequately 
enough defined to be useful) or to remove serviceGroup.

[An aside: if someone wants to put the work into defining an operationally 
useful notion of serviceGroup I'd be happy to consider it, IN ADDITION to 
targetResource.]

cheers,
   jeff


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