"Sind Sie bereit für Notes 8?" Teil 1 zum Thema Eclipse Rich Client Platform

Für die Java-Programmierer unter uns ist Eclipse schon lange bekannt. Spätestens seit der Verfügbarkeit des Websphere Studio Application Developer – mittlerweile zum Rational Developer gewachsen - ist die Verwendung der Eclipse IDE in der IBM Partnergemeinde geradezu obligatorisch für die Anwendungsentwicklung mit Java. Aber auch außerhalb dieser Gemeinde hat Eclipse einen Siegeszug als Basis für freie und kommerzielle Entwicklungswerkzeuge angetreten. Als ein findiger Kopf das Fehlen einer eigenen Laufzeitumgebung als Bug Report einstellte verging nur vergleichsweise kurze Zeit, bis mit der Version 3 die Eclipse Rich Client Platform verfügbar gemacht wurde. Seitdem hat sich die Eclipse RCP zur vorherrschenden Technologie für Rich Client Anwendungen entwickelt und beispielsweise Swing/AWT in neuen Projekten völlig verdrängt. Auf der offiziellen Website www.eclipse.org finden sich im Bereich Community bereits eine Vielzahl Beispiele, in denen RCP erfolgreich eingesetzt wurde, z.B. bei der NASA und der Schweizerischen Bahn SPP. Gerade auch Softwarehersteller wie BEA (Guardian) oder SAP (Muse) arbeiten intensiv an entsprechenden Projekten.

Positionierung RCP

Endanwender kamen bisher allerdings eher selten mit RCP in Berührung, da die meisten kommerziellen Anwendungen noch nicht auf dieser Plattform basieren. Dies wird sich spätestens mit der Verfügbarkeit des IBM Lotus Notes Clients in der Version 8 ändern, die für Q3 2007 angekündigt ist. Damit migriert auch das Flaggschiff von IBM Lotus im Office-Bereich auf Eclipse RCP, nachdem Lotus Sametime schon im letzten Jahr mit Version 7.5 auf Basis von Eclipse RCP erschien.

Durch die auf Open Source Standards basierende, offene Architektur bietet die Rich Client Platform hervorragende Möglichkeiten zur Integration von Anwendungen auf dem Client. Dies gilt nicht nur aufgrund des genialen Plugin-Konzeptes sondern auch in besonderem Maße durch die Unterstützung der Entwickler: Sind Architektur und Schnittstellen beschrieben können auch Entwickler ohne tiefe RCP-Kenntnisse im Rahmen eines Plugins fachliche Funktionen entwickeln. Gleichzeitig ist es möglich, sehr mächtige und zwischen mehreren Betriebssystem-Plattformen portable Oberflächen zu erstellen, deren Funktionsumfang weit über den eines Browsers hinausgeht.
Eclipse Rich Client Platform
Eclipse wurde ursprünglich von IBM als Entwicklungsumgebung entwickelt und im Jahre 2001 der Open Source Community zur Verfügung gestellt. Seither erfreut sich das Projekt einer schnell wachsenden und ausgesprochen regen Entwicklergemeinde. Als kommerzielle Sponsoren fungieren über 120 Softwarehersteller, darunter Branchengrößen wie SAP, Oracle, BEA, Macromedia und natürlich IBM, welche die Plattform nutzen und zu ihr beitragen. Unter dem Dach des Eclipse Ökosystems wird neben dem Kernprojekt acht weitere Top-Level-Projekte an Themen wie Web Tools (WTP) oder Business Intelligence and Reporting Tools (BIRT).

Bis Version 2 war das Designziel von Eclipse ausschließlich, eine performante und leicht erweiterbare IDE auf Basis von Java zu schaffen. Diese Anforderungen führten zu einem strikt komponentenorientierten Programmiermodell, welches vorsieht, dass eine schlanke Laufzeitumgebung als erweiterbarer Anwendungskern fungiert. Alle Funktionalitäten setzen in Form von in sich abgeschlossenen Komponenten - so genannten Plugins - auf diesem Kern auf.

Nach Erscheinen der Version 2 war die Entwicklergemeinde zunehmend bestrebt, das Komponentenmodell von Eclipse auch für eigene Applikationen zu nutzen. So kam es mit Version 3 durch ein umfangreiches Redesign zur Grundlage dessen, was heute als Eclipse Rich Client Platform (RCP) bezeichnet wird. Seitdem verfügt Eclipse über Programmierschnittstellen, die es ermöglichen, die Laufzeitumgebung nach eigenem Bedarf zu nutzen und zu erweitern. Neben dem als Equinox bezeichneten Kern, einer Implementation der OSGi R4 Specification (Open Services Gateway Initiative - http://www.osgi.org/), beinhaltet RCP Komponenten für Suche, Hilfe und Update.


Abb. 1: Architektur der Eclipse Plattform(en)

Einstieg in die ECLIPSE RCP Entwicklung

Mittlerweile hat sich im Eclipse Ökosystem eine Vielzahl nutzbarer Hilfen herausgebildet. Durch ihre komponentenbasierte Architektur unterstützt Eclipse die modulbasierte Entwicklung und ist durch die zugrunde liegende OSGI Runtime in der Lage, den gesamten Lebenszyklus der Komponenten während der Laufzeit zu verwalten: Von der Registrierung einzelner Module über das Auflösen ihrer Abhängigkeiten, das Laden/Entladen und ggf. das automatische Aktualisieren. Die Oberfläche von RCP-Anwendungen wird mit dem Standard Widget Toolkit (SWT) und JFace geschrieben. Dabei werden UI-Elemente und Controls des Betriebssystems verwendet. Dies hat neben einer im Vergleich z.B. zu Swing besseren Performance auch den Vorteil, dass sich die Anwendung an das Aussehen des jeweiligen Betriebssystems anpasst. Ein umfangreicher Bestand von Middleware-Komponenten ermöglicht die Anbindung von Datenbanken und anderen externen Komponenten. Die Plattform macht somit an vielen Stellen die Eigenentwicklung grundsätzlicher Komponenten unnötig und hilft dadurch, Zeit einzusparen bzw. mehr Zeit auf die Lösung fachlicher Probleme verwenden zu können.

Natürlich ist für die Einarbeitung in RCP die Beherrschung von Java erforderlich. Die oben beschriebenen Komponenten und Konzepte sind jedoch selten Teil von Java-Schulungen. Auf RCP speziell abgestimmte Schulungen, die z.B. SWT und JFace vermitteln sind bisher noch rar gesäht. Über dieses Handwerkszeug hinaus ist es jedoch am wichtigsten, sich mit den zugrundeliegenden Standards und Konzepten auseinanderzusetzen. Hier hilft wie so oft vor allem viel Lesen und Ausprobieren, Literatur ist mittlerweile in guter Qualität verfügbar.

Erfahrungsbericht Entwicklung einer großen RCP Anwendung

Für die Gothaer Versicherungen in Köln realisiert und begleitet TIMETOACT seit 2005 ein Grossprojekt auf Basis Eclipse RCP. Die Gothaer Versicherungen stattet ihren selbständigen Außendienst mit einer neuen Beratungssoftware aus, welche die Sparten Sach, Leben und Kranken umfasst. Auf diese Weise können die Kunden ganzheitlich kompetent beraten und damit Cross-Selling-Potentiale eröffnet werden. Gleichzeitig erfüllt die Anwendung durch Dokumentation des Beratungsergebnisses bereits die Anforderungen der neuen EU-Vermittlerrichtlinie.

Dabei sind eine Reihe vorhandener Anwendungen unter einer einheitlichen, nutzerfreundlichen Oberfläche zu integrieren – im konkreten Fall das Agentursystem sowie die zur Beitragsberechnung erforderlichen Tarifrechner. Neben der reinen Darstellung müssen die Daten unter dieser Oberfläche komfortabel manipulierbar gemacht werden und alle für die Anwendung relevanten Funktionalitäten der externen Anwendungen bedienbar sein.

Die höchste Priorität hatte die Anbindung des bestehenden Agentursystems. Hierbei handelte es sich um eine propietäre Kundenbestandsverwaltung auf Basis von Visual FoxPro, die per Java-COM-Bridge (JACOB) über bereits existierende COM-Schnittstellen angesprochen werden sollte. Die von diesem System erhaltenen Kundendaten können in der Anwendung auf Personen- oder Familien/Haushaltsebene mit Beratungsdaten erweitert werden. Um diese Zusatzinformationen wieder in den Bestand zurückfließen zu lassen, war eine minimale Erweiterung des Datenmodells der Bestandsdatenbank notwendig, um die XML-Daten der Beratung dort abzulegen.
Ebenso komplex war die Integration der verschiedenen Rechenkerne, die für Bedarfsermittlung und Beitragsberechnung benötigt werden. Die meisten dieser Rechner waren als eigenständige Applikationen implementiert. Naturgemäß gab es hier eine Vielzahl unterschiedlicher Datenmodelle und unterschiedlichste Integrationsmöglichkeiten zu berücksichtigen. Neben der bereits angesprochenen Java-COM-Kopplung waren an anderen Stellen auch reine Java-Schnittstellen oder die Anbindung nativen Codes per JNI gefragt.

Separation of concerns

Um diesen Anforderungen gerecht zu werden, wurde frühzeitig ein stark modularisierter Anwendungsschnitt geplant. Ein nicht zu unterschätzender Aspekt dieser Herangehensweise ist, dass man schon auf Ebene der beteiligten Entwickler eine „Separation of concerns“ erreichte. Dies machte es einfach, der Besonderheit Rechnung zu tragen, dass einige der Rechner Kontributionen von Drittanbietern mit spartenspezifischem Fachwissen waren. Diese konnten die Anbindung der von ihnen entwickelten Komponenten unabhängig von anderen Modulen vornehmen. Es war nicht zuletzt der hohe Parallelitätsgrad der einzelnen Implementierungsschritte, der die zeitnahe Fertigstellung der Anwendung ermöglichte. So konnten in der Hauptphase ohne die sonst häufig exponentiell steigenden Reibungsverluste über 20 Entwickler parallel im Projekt tätig sein.

Abb. 2: Komponenten des Anwendungsrahmens

Fazit

Je komplexer die zu erfüllenden Anforderungen sind, desto mehr ist man darauf angewiesen, frühzeitig den passenden „Klebstoff“ zu finden. Die Eclipse Rich Client Platform bietet sich durch ihre Flexibilität gerade in Szenarien an, in denen großer Wert auf die Integration verschiedenartiger Systeme gelegt wird. Neben dem Funktionsumfang, den Eclipse schon von Haus aus bietet, ist ein Hauptgrund für die universelle Eignung sicherlich die Philosophie eines schlanken Programmkerns, welcher ausschließlich durch Plugins erweitert wird. Damit bietet Eclipse eine Plattform, welche die Umsetzung komplexer Anwendungen erheblich erleichtert und Entwicklungszyklen verkürzen hilft. Die hier dargestellte Lösung konnte so in einem extrem kurzen Zeitraum fertiggestellt werden. Gleichzeitig war ein sehr agiler Entwicklungsprozeß möglich, durch den flexibel auf neue oder sich ändernde Anforderungen reagiert werden konnte.