RE: proposal for restricting a service to a single interface

+1 to Amy. In the management space it is convenient to break down management
capabilities into different interfaces so that managed object can choose
what sets of capabilities they want to expose for a resource that they
represent. They do this by choosing a set of interfaces they implement.
Those interfaces when grouped in one service are related in the sense that
they provide management capabilities for the same resource.

Like Amy I don't see the benefit of removing this possibility. And I see the
cost of preventing this in cases where it is useful, as illustrated above.

Regards,

William

> -----Original Message-----
> From: Amelia A. Lewis [mailto:alewis@tibco.com] 
> Sent: Wednesday, April 30, 2003 11:51 AM
> To: Glen Daniels
> Cc: sanjiva@watson.ibm.com; www-ws-desc@w3.org
> Subject: Re: proposal for restricting a service to a single interface
> 
> 
> 
> Hey, Glen,
> 
> On Wed, 30 Apr 2003 14:34:14 -0400
> Glen Daniels <gdaniels@macromedia.com> wrote:
> > OK, so here's my take.
> > 
> > - We should restrict <service>s to a single interface.
> 
> No.  It adds no value, and makes things complex that need not be.
> 
> > - We should make clear that a <service> represents a single
> >   entity (i.e. ultimate destination node in SOAP parlance).
> 
> Yes.
> 
> >   Therefore if you happen to be talking to a stateful entity,
> >   and use some non-binding-specific way of maintaining state
> >   (either the state is shared for all users or you use something
> >   like SOAP headers to maintain sessions), you will get the
> >   exact same state no matter which endpoint/binding you use.
> >   (Blah blah blah, translate to spec-ese)
> > 
> > - We should give some guidance as to how to deal with
> >   extension-specific (i.e. bindings or modules) ways of
> >   achieving patterns like asynchrony, pub/sub.  I think this
> >   should be a separate conversation.  As you say, it isn't
> >   solved now, so we need to solve it.  I'd prefer to do so
> >   as a modular entity instead of mixed up with <service>
> >   definitions.
> 
> What?  I don't understand at all, I'm afraid.
> 
> Is this going back to the whole application-level subscription stuff? 
> Most pub/sub protocols don't expose subscription at the application
> level.  It is enough to describe the publication destination; 
> the client
> already knows how to handle subscription, and subscription doesn't use
> XML messages (as a rule).
> 
> It looks like someone *really* wants to make this stuff hard.  Why?
> 
> > - We should give some guidance as to how to represent the
> >   "connectedness" between multiple <services>, either via
> >   something we might ourselves provide, like <serviceGroup>
> >   or somesuch, or by using extensions.
> 
> Or declaratively, by placing ports that are part of a single service
> inside a single service.
> 
> Amy!
> -- 
> Amelia A. Lewis
> Architect, TIBCO/Extensibility, Inc.
> alewis@tibco.com
>

Received on Friday, 2 May 2003 13:56:39 UTC