RE: proposal for restricting a service to a single interface

Sanjiva,

It is probably going to be very common that managed objects for services are
implemented as a separate web service than the resource web service as you
say. And I agree with you that some management operations (namely
start/stop) cannot be implemented as part of the affected service. But I can
also think of plenty of cases where it is more convenient to implement the
managed object (or some portions of it) inside the managed service. Two
example cases:

- when implementing the management interface requires to be very close to
the service because you need access to the business logic of the service.
For example a chess game service. While the chess service is calculating its
next move you might want to ask it how many possible moves it has currently
explored. This number is changing at neck-breaking speed and the only way to
access it is through the service itself as this is all kept in memory, it
changes too fast to be made available to an outside party (though logging or
DB).

- when implementing a very simple stand-alone service. Think of an automated
weather station on top of a mountain. I might want to embed a very simple
web service in its instruments that allow me to retrieve weather data
(operational interface) and do some simple management (management
interface). This could be a very simple service that doesn't do any URL
parsing, it just provides one endpoint.

But in any case, even if the managed object is implemented as a separate
service, my point was that the managed object itself will implement several
interfaces. There are lots of categories of management operations and
managed object will want to pick and chose which categories they offer
(monitoring, control, performance...). The managed object might offer a
different set of categories based on who the manager is. For this reason,
you won't define one management interface but a set of management
interfaces. And the managed object needs to be able to implement this set of
interface. It doesn't make sense to break down the managed object for a
resource into several services.

BTW, I like your suggestion of an "association" element inside "service" as
a way to discover the managed object for this service (or other associated
services). But this does not in any way replace the need to be able to
implement multiple interfaces in a service.

Regards,

William


> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com] 
> Sent: Friday, May 02, 2003 6: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 Friday, 2 May 2003 21:39:28 UTC