Re: Naming the service resource

See inline ...

----- Original Message -----
From: "David Booth" <dbooth@w3.org>
To: "Anne Thomas Manes" <anne@manes.net>
Cc: <www-ws-desc@w3.org>; "Arthur Ryman" <ryman@ca.ibm.com>
Sent: Thursday, July 24, 2003 9:49 PM
Subject: Re: Naming the service resource


>
> At 11:39 PM 7/23/2003 -0400, Anne Thomas Manes wrote:
> >While I think that R120 specifies an important requirement (URI for each
> >element within a WSDL document), I don't think it properly addresses the
> >requirement that I'm making.
> >
> >A wsdl:service element is a definition of a service implementation, but
it
> >isn't the service itself.
>
> I'm a little unclear about what you are advocating.  According to the
> terminology that (I think) the WG uses (and I tried to clarify in [1]),
the
> "service" is the thing defined by the <wsdl:service> element.  But it
> sounds like you are referring to something else more abstract, such that a
> service (using the definition in [1]) may be an implementation of this
more
> abstract thing.  (I'll call this abstract thing the "abstractService" for
> the moment.)

I'm not talking about an abstract service, I'm talking about a specific
resource. I'm proposing that we assign a URI to name a Web service agent --
the piece of code that implements a service. The wsdl:service name attribute
assigns a local name to a wsdl:service element. You use that name to find
the service's description. In an abstract way, that name can also be used to
refer to the agent that implements the service, but you can have multiple
descriptions of a single Web service agent, and each one of these
descriptions should have a different name. So how do you indicate that all
of these descriptions describe the same thing? (A Web service agent can
support multiple interfaces (synch versus asynch, mgmt versus application,
inquiry versus update, etc), so you may have multiple wsdl:service elements
describing the same agent. Plus you might have other description languages
(DAML, UDDI tModel, ebXML BPSS, ebXML CPP, a text document, etc.) all
describing the same Web service agent.) A Web service agent can expose
multiple endpoints, so using the endpoint URL doesn't work.

>
> I agree that if we did this, you could easily recognize when two services
> actually implement the same abstractService.  However, two questions
arise:
>
> 1. Would this be the same as the wsdl:interface?  After all, a
wsdl:service
> implements a wsdl:interface.
>
> 2. If you are suggesting that the WSDL document be able to specify the URI
> of some other resource (the abstractService), then how would this
> abstractService compare with the notion of targetResource, which we
> considered but finally rejected?

The discussion of targetResource is what got me started on this issue. I
didn't like the working definition of targetResource -- it didn't represent
the Web service agent -- it represented the thing that the Web service agent
acted upon. I think that this definition of targetResource exposes too much
of the innards of a service, so I glad that it was rejected.

>
> >And I don't think it's appropriate to ask someone
> >writing a DAML description to use a wsdl:service element to refer to the
> >service implementation.
>
> Presumably, under Arthur's proposal for satisfying R120, they wouldn't
have
> to.  They would instead use the URI that is constructed from the
> wsdl:service's QName.  Of course, some negatives would include:
>
> a. This URI would be constrained to be written a particular way, as
> specified by Arthur's R120 mapping.
>
> b. You need to know Arthur's R120 mapping to know how to produce the URI
> from the QName.  Clearly, this is less obvious than simply copying a URI,
> if the wsdl:service had been identified by a URI to begin with.
>
> c. If the service is first identified using something other than WSDL
(such
> as DAML-S), the URI that is chosen to identify it may not conform to the
> pattern produced by Arthur's R120 mapping, so it may not reverse-map it
> back to a wsdl:service QName.

And d. there may be more than one wsdl:service that describes the service,
so which one becomes the definitive name of the service?

>
> References
> 1. http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0018.html
>
> >----- Original Message -----
> >From: "David Booth" <dbooth@w3.org>
> >To: "Anne Thomas Manes" <anne@manes.net>
> >Cc: <www-ws-desc@w3.org>; "Arthur Ryman" <ryman@ca.ibm.com>
> >Sent: Wednesday, July 23, 2003 10:41 AM
> >Subject: Re: Naming the service resource
> >
> >
> > > Anne,
> > >
> > > You pose an important question, and I certainly agree that a service
is
> > > important enough to warrant a URI.
> > >
> > > Arthur Ryman has done some excellent work figuring out how to
> > > make the QName --> URI mappings work, given that our QNames are
ambiguous:
> > > http://lists.w3.org/Archives/Public/www-ws-desc/2002Dec/0021.html
> > > Do you think his proposed mapping represents an adequate solution to
the
> > > problem?
> > >
> > >
> > > At 10:25 PM 7/21/2003 -0400, Anne Thomas Manes wrote:
> > > >Effectively, the service QName and a serviceURI perform the same
> >function:
> > > >they name the service. The difference is that the service QName is a
> >QName
> > > >rather than a URI. As long as everything associated with a service
has
> >the
> > > >ability to work with XML and reference a QName, I'd say that this
> >difference
> > > >is mostly irrelavent, but I'm not convinced that everything that
might
> >want
> > > >to reference a service can effectively use a QName to do so.
Certainly a
> >URI
> > > >has much wider application.
> > > >
> > > >But that doesn't really hit the core issue. As TimBL has said
repeatedly,
> > > >all *important* resources should have a URI (not a QName). I consider
a
> >Web
> > > >service to be an important resource.
> > > >
> > > >My expectation is that in the future a service may have many
different
> > > >descriptions -- a WSDL description, a DAML description, a policy
> > > >description, a text description, and who knows what other type of
> >semantic
> > > >description. Is this group audatious enough to claim that the WSDL
> > > >description is *the* primary description that defines the service? If
so,
> > > >then the wsdl:service QName could be the official name of the
service.
> >But I
> > > >wouldn't be that audatious. IMHO, the service is a resource in its
own
> > > >right, whether or not it has a WSDL description, and as such, it
ought to
> > > >have a URI.
> > > >
> > > >Best regards,
> > > >Anne
> > > >
> > > >----- Original Message -----
> > > >From: "David Booth" <dbooth@w3.org>
> > > >To: "Anne Thomas Manes" <anne@manes.net>
> > > >Cc: <www-ws-desc@w3.org>
> > > >Sent: Thursday, July 17, 2003 12:56 PM
> > > >Subject: Re: Naming the service resource
> > > >
> > > >
> > > > >
> > > > > Anne,
> > > > >
> > > > > On today's teleconference, I took an action to ask you what is the
> > > > > difference between your proposed serviceURI and the service QName
that
> >we
> > > > > currently have.
> > > > >
> > > > > In [1] you wrote:
> > > > > >My suggestion is that we name the *service resource*, as opposed
to
> >the
> > > > > >interface to the service or the definition of the service. I
don't
> >think
> > > > > >that it's appropriate to use the WSDL document plus fragment
> >identifier
> > > > > >for this purpose, because the fragment identifier is the URI of
the
> > > > > >definition of the service, not the service itself.
> > > > >
> > > > > Do you mean that you don't think it would be appropriate to use
the
> >URI of
> > > > > a WSDL document, plus the fragID of the service, to identify the
> > > > > service?  If so, I agree, but I don't think that is what others
were
> > > >assuming.
> > > > >
> > > > > I believe we've been assuming that the service QName (i.e.,
> > > >targetNamespace
> > > > > + Local name) would adequately identify the service, independent
of
> > > > > endpoints, though it is true that it is syntactically ambiguous,
since
> > > >WSDL
> > > > > 1.2 treats different element types as being in different symbol
> > > > > spaces.  (You could have a service, interface, operation and
message
> >all
> > > > > called "foo", so they'd all have the same QName, and it would not
be
> >an
> > > > > error in WSDL 1.2.)
> > > > >
> > > > > Would your proposed serviceURI be semantically similar to the
existing
> > > > > QName, aside from the inherent ambiguity of our WSDL 1.2 QNames?
If
> >not,
> > > > > what would be the differences?
> > > > >
> > > > > 1.
http://lists.w3.org/Archives/Public/www-ws-desc/2003Jul/0008.html
> > > > >
> > > > >
> > > > > --
> > > > > David Booth
> > > > > W3C Fellow / Hewlett-Packard
> > > > > Telephone: +1.617.253.1273
> > > > >
> > >
> > > --
> > > David Booth
> > > W3C Fellow / Hewlett-Packard
> > > Telephone: +1.617.253.1273
> > >
>
> --
> David Booth
> W3C Fellow / Hewlett-Packard
> Telephone: +1.617.253.1273
>

Received on Friday, 25 July 2003 12:13:51 UTC