[
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