Re: Comments on the pretty pictures

*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!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Friday, 13 June 2003 10:22:28 UTC