Eclipse Ganymede: An in-depth look at ECF (Eclipse Communication Framework)

Posted by Alex Blewitt on Jun 18, 2008

Sections

Development

Topics

Java

Tags

Eclipse Ganymede ,

Eclipse

As part of the upcoming Eclipse Ganymede release, scheduled for June 25th, InfoQ is covering a series of Eclipse subprojects. Today, the topic is the Eclipse Communication Framework. InfoQ spoke with Scott Lewis, project lead for ECF and Principal at his consulting company, Composent, Inc to learn more about ECF and what capabilities it provides.

Lewis describes ECF as providing two things to developers:

• Real-time communication and collaboration features for teams using Eclipse such as peer-to-peer file sharing, remote opening of Eclipse views, screen capture sharing, and real-time shared editing.
• A set of communications APIs and frameworks built upon existing protocols (like Google Talk, XMPP, SSH, HTTP/HTTPS, Rendevous, IRC, and others) for developers to add communications and messaging to their own Equinox-based plugins, or customize and extend the ECF applications. The APIs support peer-to-peer as well as client-server and multipoint messaging, and are focused around specific types of communication, such as peer-to-peer file transfer, presence/IM/chat, dynamic service discovery, remote OSGi services, channels for messaging, etc.

New features for Ganymede include the ability to take a screen shot and send it to a contact, as well as real-time shared editing, which allows a text editor (Java, XML etc.) to be shared with another user via ECF. Changes made to the local developer's editor are sync'd across to the remote developer, and vice-versa.

Lewis explained the relationship between the ECF API and the individual providers that allow communication with different services:

ECF has the general approach of creating APIs that are focussed on the high-level programming need (e.g. to transfer a file, or discover a service, or send text messages, etc), rather than the protocol to accomplish this (bittorrent, skype, xmpp, etc). So, for example, we've created a file transfer API that exposes the ability to send, retrieve files as well as browse remote file systems. This same extensible API is implemented by bittorrent, XMPP, http, ftp, and scp/ssh. Each of the implementations are referred to as 'providers', and these providers know about the details of the relevant protocols.

The ECF filetransfer API is used to provide the file transfer for the new Eclipse Ganymede Install and Update capability referred to as p2 (covered previously by InfoQ). This allows file transfer protocols other than http/https to be used for Eclipse install/update.

ECF isn't just about file transfers, though. The generic Discovery API provides an abstraction over discovery protocols such as SLP (via jSLP) or Zeroconf (via JmDNS). In addition, ECF also ships R-OSGi as part of a provider to allow remote communication (either synchronously or asynchronously), and is participating in the OSGi Enterprise Expert Group.

For more information, watch the ECF webinar or listen to the podcast, the latter of which was recorded over SkyPE and Jingle integrated into Eclipse. As a community-driven project, ECF is always looking for contributors.

Lastly, when asked how ECF would be integrated into or affected by E4, Lewis said:

With the Real-Time Shared Editing work, we've started down a road of integrating distribution and interprocess communication (ECF) with modelling (e.g. EMF or DOM, or other models). What's really happening with real-time shared editing is that the document model is replicated to multiple systems, and changes are distributed (via ECF) in real-time. As soon as you distribute a model, and allow multiple people to edit/manipulate that model, you have to deal with the synchronization difficulties with replicated data. If things get out of sync, then at that point, to the user, the software effectively doesn't work.

We expect that ECF can/will help with the parts of E4 that are looking to distribute and manipulate models among multiple processes, such as a web client accessing Eclipse E4 on a server. We're hopeful that ECF and the asynchronous messaging structures it is built upon should be able to help considerably with E4 in these areas. ECF provides a lightweight set of APIs that can be used to build distributed applications, and keep distributed state in sync.

• Older >