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

Yep, the conclusion you reached is the one we reached.  It makes searching
and metadata more complicated.  It was a complication we hoped to avoid,
admittedly by shifting that complication onto the designers to create a
"most derived portType".



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



                                                                                                                                       
                      Jacek Kopecky                                                                                                    
                      <jacek@systinet.c        To:       Steve Graham/Raleigh/IBM@IBMUS                                                
                      om>                      cc:       "Amelia A. Lewis" <alewis@tibco.com>, WS-Description WG <www-ws-desc@w3.org>, 
                                                www-ws-desc-request@w3.org                                                             
                      06/23/2003 11:50         Subject:  Re: Complex reference versus containment [WAS: Re: Comments on the            
                      AM                        pretty  pictures]                                                                      
                                                                                                                                       
                                                                                                                                       




Steve, thanks for the information.

I don't see a value in forcing the most-derived-interface on everyone,
especially if it is overridden by the targetResource mechanism anyway.

You see, I believe that if I want a service that implements
NotificationSource, FooManagement, FooOperations, I'll search for
precisely that and I won't rely on everyone agreeing that the
combination of all these three interfaces is MostDerivedFoo. Anyway, in
many cases I'll search for a subset, say for FooManagement and
FooOperations only, because I don't care about the notifications. Does
that mean every combination of interfaces has to have a unique
most-derived interface? I hope not. (Who defines the combinations of
interfaces from different namespaces? If the combining interface is not
unique, it doesn't help.)

In cases where an interface combining multiple (or all) interfaces from
a segment makes sense, it will be created, otherwise forcing everyone to
add it won't help.

I'd say let's revert the decision on single interface per service.

Best regards,

                   Jacek Kopecky

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



On Mon, 2003-06-23 at 17:19, Steve Graham wrote:
>
>
>
> 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
> ++++++++

Received on Monday, 23 June 2003 11:54:05 UTC