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 Friday, 2 May 2003 21:11:14 UTC