RE: proposal for restricting a service to a single interface

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.

-- 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 11:36:22 UTC