JAXenter: Hallo Herr Kuppe. Um was geht es beim Eclipse-Communication-Framework-(ECF-)Projekt?
M.A. Kuppe: Das Hauptaugenmerk des ECF-Projekts gilt der Bereitstellung von APIs zur Interprozesskommunikation innerhalb des Java Stacks. Jedoch beschränken wir uns nicht nur auf die reine Anwendungsebene, sondern bieten ebenso Werkzeuge zur Benutzerkommunikation.
Grundsätzlich dient die API als Abstraktion von konkreten Kommunikationsprotokollen und kapselt diese in so genannten Providern. Alternativ ließe sich die Aufgabe der API auch aus einer Mischung aus Adapter und Fassade beschreiben. Verschiedene Provider lassen sich zur Laufzeit kombinieren und ähnlich zu OSGi-Services nutzen. Ein gutes Beispiel ist ein Multi-IM-Client, der mehrere Protokolle hinter einem einzigen User Interface verbirgt. Dasselbe Konzept findet sich in ECF. Sehr schön hat es auch Wayne Beaton auf der diesjährigen EclipseCon ausgedrückt, als er sagte, "ECF ist bereits die Abstraktion". Bisher bietet ECF APIs und diverse Provider für die Bereiche Remote-Services, Discovery, File-Transfer, Shared Editing, Presence, Datashare, Telephony und Shared Objects.
JAXenter: Was ist ein typischer Use Case für das Projekt?
M.A. Kuppe: Der typische Use Case ist wegen der Vielfältigkeit von ECF schwer zu beschreiben. Zum einen eignet sich ECF zum Bau von Werkzeugen zur Teamkommunikation, wie ein Konferenzplaner auf Grundlage unserer asynchronous/synchronous messaging API zeigt. Daneben steht ein Projekt, das mit ECF dezentral OSGi Runtimes steuert. Zum anderen wird es aber auch in p2 und Buckminster als Transport-Layer verwendet, sei es nun mit den Protokollen HTTP, FTP oder Bittorrent. Die Architektur von ECF ermöglicht das einfache Austauschen konkreter Implementierungen. Daher sollte sich prinzipiell jeder ECF genauer ansehen, dessen Projekt die Notwendigkeit zur protokollunabhängigen Kommunikation hat. Anforderungen ändern sich zu rasant, als dass man sich in den ersten Phasen eines Projekts auf ein konkretes Kommunikationsprotokoll festlegen kann.
JAXenter: Was ist neu in der Galileo-Version von ECF?
M.A. Kuppe: Da das Projekt aus einer sehr heterogenen Entwicklergruppe besteht und nicht durch eine einzelne Firma gesteuert wird, decken die Neuerungen in ECF 3.0 viele verschiedene Bereiche ab. So kommt das ECF Galileo-Release mit einem Twitter-Klienten daher, und Real Time Collaboration ist zusammen mit Shared Editing (Cola) durch viele Detailverbesserungen noch besser für verteiltes Entwickeln geeignet. Unter anderem wurden bestehende Provider verbessert oder, sofern sie auf Third-Party-Komponenten beruhen, aktualisiert. Außerdem sind diverse neue Provider entstanden.
Einen großen Teil macht auch die Einführung von Distributed OSGi aus, ebenfalls bekannt unter RFC-119. 119 ist eine (transparente) Erweiterung der OSGi Service Registry. Man könnte von einer verteilten Service Registry sprechen. Der Anwendungsentwickler sieht jedoch nichts von der Verteilung, was sich insbesondere auch für Bestandsservices eignet. Im Kontext dieser Arbeiten wurden Futures implementiert, die auch aus Java5 bekannt sind, im Gegensatz dazu aber auch auf älteren VMs laufen. Mittlerweile wurden diese jedoch an das Equinox-Team übergeben, damit sie allgemein Verwendung finden.
Wo wir gerade beim Equinox-Team sind: p2 wurde dahingehend abgeändert, dass intern von nun an ECF File-Transfer genutzt wird. Eine vollständige Liste aller technischen Änderungen findet sich in unserem New and Noteworthy sowie hier und hier.
Organisatorisch ist das ECF-Projekt aus dem Technology-Projekt ins Runtime-Projekt entwachsen und hat nebenbei neue Teammitglieder gewonnen. Man muss sich also keine Sorgen machen, dass dieses Release das letzte ECF war, ganz im Gegenteil.
