W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2003

RE: proposal for restricting a service to a single interface

From: VAMBENEPE,WILLIAM (HP-Cupertino,ex1) <vbp@hp.com>
Date: Fri, 2 May 2003 13:56:30 -0400
Message-ID: <68157FD469848D45B9CBC2833AD552803F7215@xsun02.ptp.hp.com>
To: www-ws-desc@w3.org
Cc: sanjiva@watson.ibm.com, "'Amelia A. Lewis'" <alewis@tibco.com>, Glen Daniels <gdaniels@macromedia.com>

+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.



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

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:24 GMT