Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ecf-dev] handling pub-sub providers with RFC 119

Hi Folks,

Recently, there was a message thread titled "Remote service with ActiveMQ JMS topic using RFC 119 transparent way. " and in this message [0], I described some work I'm doing with the ECF RFC 119 impl to easily deal with these cases (i.e. option 2 in my message). By 'these cases' I mean publish and subscribe groups that are used for remote services between members of those groups (e.g. JMS groups, etc).

Currently, there's no direct support in RFC119 for remote services within pubsub groups...because although RFC119 has the notion of an 'endpoint ID', this endpoint ID gives the location of the remote service's host...which assumes that the host is a server (i.e. can be reached *directly* from a client), rather than indirectly (i.e. via a pub/sub group). ECF's IContainer can represent communication with either an endpoint (server) *or* a pubsub group and this makes it possible to use this capability to support peer-to-peer remote services within a pub-sub group (e.g. a jms topic). In order to make this capability accessible via the ECF RFC119 impl (please add to your thoughts about giving a name to ECF's impl here [1]) , I've added some API to our RFC119 implementation in org.eclipse.ecf.osgi.services.distribution. What it does is expose both the *endpointID* and the *connectTargetID* in the discovery-published meta-data (i.e. see this interface [2]). On the client side, this information about the remote service (both it's endpointID and connectTargetID) can then be used to connect to a pub/sub group at remote service discovery time (but only when the connectTargetID is non-null...note that this has *no* effect/relevance for client-server distribution providers).

I've implemented the mechanism to do this, and am working on some test code using the ActiveMQ (JMS) provider. If others are interested in helping test this, please let me know.

One more thing...in this previous thread [3] I brought up the issue of dealing with the situation where potentially many remote services were published/available on a lan (e.g.) and it was unclear (from RFC119) how this should be handled...e.g. does the announcement of some remote service mean that another remote service doesn't get a proxy? Should all remote service discoveries lead to proxy creation? How can an application provide some control/scope to the proxy creation?

RFC119 doesn't really address this situation yet, but I've added two service interface called IProxyContainerFinder, and IHostContainerFinder [4] that allows other bundles to register themselves as 'container finders'...i.e. to decide which (of potentially many) remote services providers should handle a discovered service publication. Note that these container finders allow full customization of the remote service discovered meta-data (i.e. they can decide to create new IContainers, reuse old ones, ignore some, etc). The way to replace the DefaultProxyContainerFinder is to simply register your own implementation of IProxyContainerFinder (or IHostContainerFinder) as an OSGi service...e.g:

bundleContext.registerService(IProxyContainerFinder.class.getName(),new MyProxyContainerFinder(), null);

And when services are discovered via the discovery impl(s) your container finder will be consulted to make the decision about what IContainer should/will handle the request. Note that currently the service with the highest service ranking will be selected (if there are many), and the DefaultProxyContainerFinder has the lowest service ranking possible (so will only be used if *no* other container finders are registered in the service registry).

Note that there is also a IHostContainerFinder, to allow the same sort of customization for selection of the IContainers to handle the host service publication (with the default being all existing IContainers).

Any comments welcomed. I'm working on testing/debugging this API right now (it already works fine with the r-OSGi and ecf generic providers (i.e. in org.eclipse.ecf.tests.osgi.services.distribution), but I want to verify the correct behavior for ActiveMQ provider also, as above).
To summarize, the two API additions are:

1) IServiceEndpointDescription including both endpointID and connectTargetID
2) Adding IProxy/HostContainerFinder API to allow for customization/extension of the default container selection mechanism for both host and proxy handling.

Thanks,

Scott

[0] http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg02265.html
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=270652
[2] http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/osgi/services/discovery/IServiceEndpointDescription.html
[3] http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg02206.html
[4] http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/osgi/services/distribution/package-summary.html


Back to the top