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

Re: Comments on the pretty pictures

From: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
Date: Fri, 13 Jun 2003 17:36:15 +0200
Message-ID: <3EE9EF6F.3020204@crf.canon.fr>
To: "Amelia A. Lewis" <alewis@tibco.com>
CC: Arthur Ryman <ryman@ca.ibm.com>, www-ws-desc@w3.org

Personnally, I see a "Web service" as a higher-level concept, possibly 
implemented via one or more <wsdl:service/> elements, and possibly 
accessing multiple "resources" underneath.

The "resources" are the things which ultimately implement the service 
(though they may be abstract, implemented themselves via several pieces 
of code/scripts/db/etc.) An "interface/endpoint" provides a, let's say, 
network-programmatic access to the "resource". A real-world "Web 
service" may be provided/implemented through several such 

Apparently, you seem to be looking at this field from a different 
mountain, and we don't seem to be seing the same valley underneath. Ah, 
I know, maybe you've moved to Australia and are now seing things like in 
a mirror? ;-)


Amelia A. Lewis wrote:

> *shrug*
> I've pointed out, more than once, that this allegedly simplifying 
> proposal complicates processing.  It does so by introducing an 
> expensive-to-enforce restriction, and the inclusion of redundant 
> information.  It also uses the term and concept "resource" to
> indicate a concept that perfectly reasonable people might label "web
> service", and uses the term and concept "service" to indicate a
> subset of that that happens to have certain characteristics
> (interfaces implemented by bindings pointed to by endPoints are
> equal), making a service a subset of a service.
> Given the utter tangle into which the WG has already worked itself, I
>  have little doubt that a publication including this sort of
> confusion will require interpretation.  So I will recommend that
> implementors treat the restriction as optional, and allow the
> redundant information to not appear.  I will also recommend that
> users be trained to ignore the incomprehensible parts of the spec,
> and told to define their services as they think appropriate.  This
> may require several "compatibility modes" to allow interoperation
> with the other possible interpretations of what the tangle is
> supposed to mean.
> *shrug*
> Given that the current mish-mosh is unimplementable, I'm not too
> worried about it, and don't really want to spend much time on it.  If
> it survives the challenges of last call, I'll worry about it then,
> probably by using the above recommendations.
> On Thu, 12 Jun 2003 16:08:17 -0400 "Arthur Ryman" <ryman@ca.ibm.com>
> wrote:
>> You wrote:
>> "The use of "resource" as a larger thing than "service" is a
>> reversal of common use.  Commonest-of-all use of "resource" is in
>> the terms "uniform resource locator" or "uniform resource
>> identifier"; these terms implicitly define a resource as being an
>> endpoint and an interface; the fact that multiple resources may
>> point at the same abstract [something], or share its state,
>> indicates that the general use of the term"resource" is to indicate
>> a subset of an interface on a service."
>> Look at the following section of the WSDL 1.1 spec: 
>> http://www.w3.org/TR/wsdl#_services
>> "If a service has several ports that share a port type, but employ 
>> different bindings or addresses, the ports are alternatives. Each
>> port provides semantically equivalent behavior (within the
>> transport and message format limitations imposed by each binding).
>> This allows a consumer of a WSDL document to choose particular
>> port(s) to communicate with based on some criteria (protocol,
>> distance, etc.)."
> All correct and up front.  Note that it does not exclude the
> inclusion of ports that do not share a port type.  Which, if included
> in the same service element, would reasonably be taken to indicate
> different port types on the same service.  All done by kindness.
> Note that the above text does not have to introduce the term
> "resource" to refer to a web service.
>> Each endpoint is a resource, but there is also another resource
>> which represents the "equivalence class" of the endpoints. This
>> other resource is conceptually useful since it abstracts out the
>> details of the protocol.
> This amounts to: "When ports of different port types are no longer 
> allowed in a single service, we need another random term to indicate 
> that they actually do belong to the same service."  *Clearly* a 
> simplifying assumption.
> [snip completely obvious example]
> Amy!
Received on Friday, 13 June 2003 11:36:25 UTC

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