|[ecf-dev] migrating toward remote service admin
Hi Folks, First, Happy New Year.Over the past 4 months, in my off time I've been working on the ECF impl of the OSGi 4.2 Remote Services Admin (RSA) specification. Here  is the enhancement request.
This implementation is now working, and nearing completion (see the bug for details and for access to source). There still is plenty more to do...including some simplification/refactoring, documentation, testing against OSGi TCK, review, bug fixes, some amount of additional specified behavior (for example...security/permissions checks as per spec) and perhaps some renaming of classes/interfaces for clarity. With some assistance from the other committers and contributors, I believe all of these things can be completed for ECF 3.5 (end of Feb).
But, the impl *is* now fully working...for a simple topology manager that duplicates the functionality of the basic remote services implementation (part of the RSA spec is the ability for other TopologyManagers to be created...that can handle more complex use cases for exporting and importing remote services). It uses ECF's discovery API for discovery...so that *all* ECF discovery providers are automatically supported (i.e. Zookeeper, zeroconf, slp, dnssd, others), and *all* ECF remote services providers are automatically supported (i.e. ECF generic, r-osgi, jms, javagroups, rest*, xmpp, others). This means that ECF consumers can now not only write their own standard remote services...and be able to mix and match discovery and/or distribution providers...but they can also customize and control the distribution logic using the remote services admin specification...and also mix and match discovery and/or distribution providers for their use case, deployment environment (e.g. lan vs. wan), and security requirements....using standardized RSA APIs.
IMHO this is pretty cool...because it gives consistency of remote services and admin API through OSGi standardization, but still allows the flexibility to use the protocols and associated providers that fit the particular use case and deployment environment.
Further, since the ECF discovery and remote services API abstractions are completely open...others are completely free to create their own discovery and/or distribution implementations based upon whatever serialization and wire protocol they prefer (e.g. Riena, xml-rpc, rest-based protocols, proprietary/legacy systems, etc). All such implementations will be usable by the Remote Service Admin...since the RSA interacts only with the discovery API and remote services API abstractions. As far as I know...this ability to use a single, standard impl of RS/RSA...with multiple discovery and/or remote services providers...is unique to ECF's implementation.
One issue that I would like to discuss and get community feedback on is this: The new RSA implementation essentially makes obsolete the ECF 3.4 remote service implementation. That is...all the functionality of the existing remote services implementation is available via RSA, and RSA also has other API for more complex use cases. This brings up the issue of migration...from the existing remote services impl to RSA.
The question is how to do such migration. One approach would be to simply start distributing RSA rather than the existing RS impl...but this would create a problem for people updating from 3.4 to 3.5 (as they would then have both active). Another approach would be to modify/remove most of the functionality in the existing RS bundles, and distribute new versions with most of the functionality and API removed (obviously this would be a breaking change for anyone that used the existing API...currently marked as internal). Just to be clear...any apps that use the OSSi 4.2 RS specification only will migrate completely transparently...only apps that use the org.eclipse.ecf.osgi.services.discovery and/or org.eclipse.ecf.osgi.services.distribution classes will be at issue for migration to RSA.
I would like people to comment on the migration strategy that seems best to them...and/or ask any questions that you might have.
Thanks, Scott  https://bugs.eclipse.org/bugs/show_bug.cgi?id=324215
Back to the top