[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[ecf-dev] Re: pub sub example and distributed OSGI service registry
|
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 there would be no explicit Java interface binding? How would
complex types as parameters be handled? Personally, I feel much
safer about model replication along w/ MDD/MVC style applications
rather than code calling code in a distributed fashion. Given what
I've read regarding Peter's work with this, I'd love to see it
working in a pure OSGi context.
-Ken
On Jul 17, 2006, at 11:33 PM, Scott Lewis wrote:
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
