ECF 3.4 Remote Services

ECF 3.4 was recently released. This release (along with Helios/3.3 and upcoming releases) heavily emphasized the implementation of OSGi 4.2's Remote Services specification. Our community is pushing us to continue this emphasis, and so we will.

Here are some reasons to use ECF's OSGi 4.2 Remote Services implementation:

1. Standards Compliant: It is fully compliant with the Remote Services standard. No lock-in...now and forever


2. Asynchronous Remote Services: Unlike other implementations of this standard, right now it provides support for Asynchronous Remote Services


3. Multi-Transport: Right now it supports multiple network discovery protocols (e.g. Zookeeper, DNS-SD, SLP, Zeroconf, static xml-file), and multiple distribution transports (e.g. r-OSGi, ECF generic, XMPP, JMS, Http/REST-based protocols, JavaGroups)


4. Extensibility through Modularity: The open discovery and remote services APIs allow new discovery and distribution implementations to be substituted at will...proprietary or open...without requiring any additional work to support the OSGi standard


5. Enterprise support: We are completing (for ECF 3.5) our implementation of the Remote Services Admin specification. The progress on this can be easily and publicly tracked...contributions, test/testing, and early uses are welcomed and encouraged.


6. Open Community: ECF is not just open source, but also has a completely open, diverse, growing, active...and most importantly...a contributing community


7. Open Process: We've moved to GIT, to make community support and contributions easier


8. Multi-Framework: ECF remote services now runs on Felix (and probably other OSGi frameworks as well)


9. Robustness through Community Usage


10. Low-license fee: $0 :)