[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ecf-dev] migrating toward remote service admin
- From: Scott Lewis <slewis@xxxxxxxxxxxxx>
- Date: Wed, 05 Jan 2011 10:08:11 -0800
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
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.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.