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

RE: proposal for restricting a service to a single interface

From: Kenneth Chiu <chiuk@cs.indiana.edu>
Date: Thu, 8 May 2003 11:37:45 -0500 (EST)
To: "Sedukhin, Igor S" <Igor.Sedukhin@ca.com>
cc: www-ws-desc@w3.org
Message-ID: <Pine.GSO.4.53.0305081128410.11644@rainier.extreme.indiana.edu>

On Thu, 8 May 2003, Sedukhin, Igor S wrote:
> Let me put my voice into this dicussion. We're -1 on
> single interface per service.
> The reason is techically quite simple -- for aggregation
> purposes it is very covenient. Aggregation may be one of
> the important aspects of defining a possible
> usage/implementation pattern for manageable services.
> Association is NOT always sufficient, so your example,
> Sanjiva, is not the the only solution necessary for
> defining manageability, for example.
> The inheritance solution, proposed by Arthur earlier, I
> believe, does not work well for agregation because of the
> binding limitation. In case of aggregation, I may want to
> bind two interfaces designed for two separate purposes
> with two completely separate bindings, and still call it
> one service. If I try to mimic this with inheritance,
> bindings would have to be able to "partially concretize"
> an interface or dig through the inheritance and pick the
> one to concretize. That is too much of a change to binding
> spec and too much of complication for WSDL processors.

A related approach, but one I consider somewhat cleaner,
is to move the address and protocol information out of the
port element and into the binding elements and subelements.
The result is that one port can have different parts of it
bound to different protocols.  One can even imagine having
different operations of one interface bound to different

This still might be too much of a change to the binding
spec, though.

> -- Igor Sedukhin .. (igor.sedukhin@ca.com)
> -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
> Sent: Friday, May 02, 2003 9:12 PM
> To: VAMBENEPE,WILLIAM (HP-Cupertino,ex1); www-ws-desc@w3.org
> Cc: 'Amelia A. Lewis'; Glen Daniels
> Subject: Re: proposal for restricting a service to a single interface
> "VAMBENEPE,WILLIAM (HP-Cupertino,ex1)" <vbp@hp.com> writes:
> >
> > +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.
> In the management space, how often is it the case that an object manages itself vs. an object has an associate management object? That is, can an object really manage itself (like start/suspend/resume .. if its suspended how do u resume it???)? It seems to me that more often there will be a closely related service that does the management of a given object.
> When we did WSFL, we had a lifecycle interface built into each flow. That worked ok, but in reality the implementation of that interface was not done by the flow itself - it was implemented by a related service and some notifications would be issued to the flow. In BPEL, we changed that and the lifecycle stuff is really outside now in some other service.
> I think what's really needed is a way to say something like this:
>     <service name="s1" interface="x:i1">
>         <port name="p1" .../>
>         <association type="my-management-service">service info</association>
>     </service>
> Then your service's business functionality would be what's in interface i1 and its management interface would be what the associated service does. Similarly there could be lots of other associated services, one that provide reputation information via a BBB like rating system or whatever.
> Sanjiva.
Received on Thursday, 8 May 2003 12:37:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:29 UTC