Complex reference versus containment [WAS: Re: Comments on the pretty pictures]

On Fri, 13 Jun 2003 17:36:15 +0200
"Jean-Jacques Moreau" <jean-jacques.moreau@crf.canon.fr> wrote:
> 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.

Well, there's the difference, then.  Vive la.  When I see something
called a "service" as part of "web services description language", I
think that perhaps it describes a web service.

WSDL 1.1 used a very simple, even primitive means of associating
different means of accessing a single service.  It used containment,
fundamental to XML.  Items in the container are part of the container.

By requiring the container to have only identical parts inside, WSDL 1.2
forces the use of multiple containers, which must then be somehow
associated with each other, and once the can of worms called
"association" is opened, the worms will never fit back into the
container.  I seriously doubt that all the ramifications of this
*complicating* assumption (single-interface/service) have yet been
unearthed, and I foresee hours more of debate and mutual incomprehension
for the working group, probably yielding a set of definitions that will
draw heavy fire in the last call/CR/PR process.  I don't expect this
sort of baroque language to survive the process, so I'd really rather
resign from the debate now, and lob pot-shots when it is attacked later.

Most, if not all of these problems could be avoided by remaining with
the definition of a service element as representing a web service, using
containment.  In order to determine whether ports (endPoints) are
semantically equivalent, use the rule in WSDL 1.1: do their bindings
implement the same interface?  Add <assert level="MUST">all endPoints in
a service MUST be associated with the same web service</assert> and
there's actual information provided by the syntax, which otherwise
requires definition of meta-resources, use of another
URI-pointing-at-nothing, and similar difficult-to-explain silliness.

I feel like a passenger in a folk song.  "Mr Jones, this train is goin'
pretty fast!"  But I figure I can always disconnect the caboose before
the inevitable end ....

Amy!
> 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 
> "interfaces/endpoints".
> 
> 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? ;-)
> 
> Jean-Jacques.
> 
> 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!
> 


-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Friday, 13 June 2003 12:36:28 UTC