[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ecf-dev] pub sub example and distributed OSGI service registry

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