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

Hi Jacek!

>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?

We call that entity a Service Instance (technically it is a Grid Service
Instance, because in OGSI, all services must implement the Grid Service
portType).
In preparation for OGSI v1.0, we wanted the notion that each service
instance would have a single "interface" or type.  This makes search (and
some meta-data) easier to articulate.  However, we saw at the time of OGSI
v1.0 finishing (April 2003), it did not appear that W3C WSD WG were going
to put a single "interface" on a service element.  Therefore our meta data
and look ups assume that there is a multiplicity of interfaces that would
define the "type" of a service instance.

So, I want to define a Grid service that mixes in "NotificationSource" (ie
the service instance allows asynch notification for state change events),
"BaseManageableResource" (to mix in base managability behavior),
"FooManagement" (to define domain specific management behavior) and
"FooOperations" (to define the normal domain-specific (non systems
management) operations.

So, we have multiple interface inheritance here.  So mapping the interface
inherits, using the <--- symbol to denote "extends", we have the following

GridService <--- NotificationSource
GridService <--- BaseManageableResource <--- FooManagement
GridService <--- FooOperations.

Now, the major thing that we were looking for is the notion that there is a
single "most derived" interface that defines the total set of interfaces
supported by the services.  This would "force" designers to define one
additional interface "MostDerivedFoo" that mixes in all these interfaces:

{GridService, NotificationSource, FooManagement, FooOperations} <--
MostDerivedFoo.

The service element would then have some information item that associates
MostDerivedFoo with the service.

This would allow clients that are looking for a service instance that has
this combination of interfaces to look for services that implement
MostDerivedFoo and this allows the service instance to offer up meta-data,
so that other system entities can interrogate "what is your interface" and
the response to this interrogation is a single interface (from which the
client can derive all the other interfaces in the inheritance hierarchy).

I hope this helps.

sgg
++++++++
Steve Graham
sggraham@us.ibm.com
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
++++++++



                                                                                                                                       
                      Jacek Kopecky                                                                                                    
                      <jacek@systinet.c        To:       "Amelia A. Lewis" <alewis@tibco.com>                                          
                      om>                      cc:       WS-Description WG <www-ws-desc@w3.org>                                        
                      Sent by:                 Subject:  Re: Complex reference versus containment [WAS: Re: Comments on the            
                      www-ws-desc-reque         pretty pictures]                                                                       
                      st@w3.org                                                                                                        
                                                                                                                                       
                                                                                                                                       
                      06/23/2003 10:56                                                                                                 
                      AM                                                                                                               
                                                                                                                                       
                                                                                                                                       





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 11:25:34 UTC