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

I agree with Amy that naming something that is not a web service a
wsdl:service is confusing, if not outright evil. 8-)

I see the following terminology now:

Turtle, aka Resource, aka the Thing - a set of endpoints
Endpoint - an instance of an interface, living at one URI
Interface - a set of operations

IMHO the turtle, the grand concept of the Web Services Description
Language, should be the Web Service.

So, what do we call the entity that the OGSI folks (unsure here) have
called for, the entity that has multiple endpoints with a common single
interface? What is the usecase and does it suggest a name? I think I
usually heard that the requirement is that the service have a single
interface. Why would that be, if we all agree that the main thing does
have multiple interfaces?

Anyway, I disagree with Amy that apart from naming confusion, the
targetResource approach is significantly more complex for processing.

Best regards,

                   Jacek Kopecky

                   Senior Architect
                   Systinet Corporation
                   http://www.systinet.com/





On Fri, 2003-06-13 at 18:37, Amelia A. Lewis wrote:
> 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!
> > 
>

Received on Monday, 23 June 2003 10:56:28 UTC