Eclipse Zone is brought to you in partnership with:

Scott is a DZone MVB and is not an employee of DZone and has posted 25 posts at DZone. View Full User Profile

ECF 3.4 Remote Services

  • submit to reddit
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 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 :)



Published at DZone with permission of Scott Lewis, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)