[ecf-dev] pub sub example and distributed OSGI service registry

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Peter,

I had a chance to take a look at your pub sub example a little today 
described here:

http://wiki.eclipse.org/index.php/Enhanced_Publish_and_Subscribe_Support

...very cool.  I like the way that the published services are then able 
to provide multicast-like state updates only for the clients that have 
registered interest (subscribed).

While looking at the example running and then looking at the code the 
following question popped into my head:  Why not use this (or something 
like it) to expose a distributed OSGI services registry?  That is, just 
like you distribute PublishedServiceDescriptions, we could replicate the 
information typically contained in the OSGI service registry about a 
service, and then allow remote clients to lookup/find service 
references, and then resolve those service references into 'proxy' 
objects to call remote services.

So, for an example consider the IRemoteServiceContainer interface 
presented here:  http://wiki.eclipse.org/index.php/Remote_OSGI_Services.

public interface IRemoteServiceContainer {
	
	public void addRemoteServiceListener(IRemoteServiceListener listener);
	public void removeRemoteServiceListener(IRemoteServiceListener listener);
	
	public IRemoteServiceRegistration registerRemoteService(String [] clazzes, Object service, Dictionary properties) throws ECFException;
	public IRemoteServiceReference[] getRemoteServiceReferences(ID [] idFilter, String clazz, String filter) throws ECFException;
	public IRemoteService getRemoteService(IRemoteServiceReference ref) throws ECFException;
	public boolean ungetRemoteService(IRemoteServiceReference ref);
	
}


Analogous to the BundleContext.registerService(...) method is the 
IRemoteServiceContainer.registerRemoteService(...) method.  The 
intention is that this would be used upon bundle initialization 
(typically) to connect a given container and register local services 
with that container for remote access (very similar to what services 
have to do to register themselves with the OSGi platform now).

So underneath the covers, this registerRemoteService call could update a 
replicated registry (table) containing information about all of the 
registered services for all of the containers within a given ECF group.  
Such a distributed registry could very well use what you have created 
for distributed services to do its work.

Then, on the client side (those that want to consume services), 
analogous to the BundleContext.getServiceReferences(...) method, the 
IRemoteServiceContainer.getRemoteServiceReferences(...) method would be 
called by clients to search/retrieve IRemoteServiceReference 
objects...which contain the identifying information about a remote 
service (but not actual access to the service itself).  The 
IRemoteServiceContainer.getRemoteServiceReferences(...) call could 
search the current distributed registry contents (with the specified 
search criteria) and use the contents of the registry to return value 
IRemoteServiceReference instances.

Then, analogous to BundleContext.getService(ServiceReference), clients 
could resolve service references into an interface for calling methods 
on a remote service by calling 
IRemoteServiceContainer.getRemoteService(IRemoteServiceReference).  This 
returns an IRemoteService instance, which would allow several kinds of 
interaction with the remote service:  1) IRemoteService.callSynch(...): 
which would provide blocking call/return semantics; 2) 
IRemoteService.callAsynch(...) (either one) which sends a message to 
remote service, and either uses polling (AsynchResult) or notification 
to receive a return value; and 3) IRemoteService.fire(...): which would 
simply send a one-way message to invoke the remote service but not 
expect or wait for a return value.

So perhaps we could use the machinery in Peter's pub sub example code to 
implement this distributed registry.  What do people think about this idea?

Scott