[ecf-dev] migrating toward remote service admin

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

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 [1] is 
the enhancement request.

This implementation is now working, and nearing completion (see the 
bug[1] 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

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=324215