Eclipse als Anwendungsframework und Runtime

Was ist Eclipse? Teil 2

Wayne Beaton, Jonas Helming und Maximilian Kögel

Das mittlerweile über zehn Jahre gewachsene Gebilde Eclipse lässt sich nur schwer zusammenfassen. Im ersten Teil dieser Serie starteten wir mit den Ursprüngen: Eclipse als IDE, Eclipse als IDE-Framework und Eclipse als Toolsplattform. Die wesentliche Eigenschaft von Eclipse ist die Modularität, die diese bereits sehr unterschiedlichen Einsatzszenarien ermöglicht. Spätestens als es um Tools wie das Businessanalyseframework BIRT ging, wurde klar, dass Eclipse-Technologie längst nicht mehr nur auf den Arbeitsplätzen von Entwicklern zum Einsatz kam. Konsequenterweise verlassen wir in diesem Teil der Serie die Welt der Entwicklungsumgebung und beschreiben Eclipse als Anwendungsframework sowie als Laufzeitumgebung.

Eclipse als Anwendungsframework

Um die Zeit von Eclipse 2.0, also etwa vor acht Jahren, wurde einigen Entwicklern, die an Eclipse arbeiteten oder Eclipse als Toolsplattform einsetzten, klar, dass man mit Eclipse mehr als nur Tools bauen konnte. Erweiterbare Menüs, das Fenstermanagement mit verschachtelbaren Views und Editoren, die auf verschiedenen Betriebssystemen nativen Widgets, das Adapterkonzept und die generelle Modularität sind alles Lösungen, die für eine Toolsplattform gut funktionierten, aber eben nicht nur dort.

Firmen begannen, auch andere Anwendungen auf Eclipse-Basis zu entwickeln. Zu Beginn war das damals aufgrund des noch fehlenden Framework-Supports teilweise etwas schmerzhaft. Nach einigem Aufwand im Eclipse-Plattformteam wurde mit Eclipse 3.0 im Jahr 2004 zum ersten Mal die Rich Client Platform (RCP) veröffentlicht, auf der heute alle Eclipse-Anwendungen, auch die IDE, basieren.

Die Rich Client Platform ist mehr als ein reines UI Toolkit, es ist ein umfangreiches Applikationsframework, das alles bietet, was in typischen Rich Clients benötigt wird. Softwareentwickler können zahlreiche Funktionen des Frameworks nutzen, anstatt sie für jede Anwendung neu zu entwerfen. Eclipse RCP erlaubt es damit, sich auf die Entwicklung der Komponenten zu fokussieren, die für die eigenen Anwendungen den wahren Wert ausmachen.

Ein sehr frühes, aber trotzdem heute noch prominentes Beispiel einer Adaption von Eclipse RCP liefert die NASA. Im Jet Propulsion Lab (JPL) wird RCP bereits seit 2005 eingesetzt, beispielsweise für Maesto, ein Tool, mit dem Mars Rover gesteuert werden können (Abb. 1).

Abb. 1: Das Maesto Tool für die Steuerung von Mars Rover basiert auf Eclipse RCP

Die Eclipse Foundation pflegt eine Liste mit vielen weiteren erfolgreichen Fallstudien, in denen RCP zur Anwendung kam [1].

Schnell kamen weitere Frameworks hinzu, die das Entwickeln mit RCP zusätzlich unterstützten. Riena beispielsweise ist ein Framework für Client-Server-Businessanwendungen. Riena Widgets, so genannte Ridgets, erweitern SWT um typische Businessanforderungen wie Livevalidierung der Eingabe. Zusätzlich unterstützt Riena den Workflow eines UI sowie die Client-Server-Kommunikation. An dieser Stelle verlassen wir über eine fließende Grenze den Bereich Rich Client. Spätestens wenn es um Serverunterstützung geht, sind wir bei der nächsten Antwort auf die Frage „Was ist Eclipse?“

Eclipse ist Runtime

Jeder Teil dieser Artikelserie, beginnend mit Eclipse als IDE und nun als Anwendungsframework, hat die Definition des Begriffs „Eclipse“ ein wenig erweitert. Das war aber eigentlich nur eine Vorbereitung, denn im Grunde ist Eclipse technologisch gesehen so flexibel, dass es für so ziemlich jeden Zweck eingesetzt werden kann. Und so haben auch Viele, die gar nichts mit Softwareentwickelung zu tun haben, bereits Eclipse-Technologie verwendet, ohne es zu wissen. So steckt Eclipse beispielsweise in den automatischen Kartenlesern von SkiData, die in vielen Skigebieten, aber auch bei Konzerten und Sportveranstaltungen eingesetzt werden. Welcher Teil von Eclipse ist das aber? Ein solcher Automat sieht ja nicht gerade nach SWT aus.

Den Kern von Eclipse bildet eine Komponente namens Equinox, die Basis für alle Plug-ins. Equinox erlaubt es den verschiedenen Komponenten von Eclipse zusammenzuarbeiten. Es verwaltet Abhängigkeiten zwischen Plug-ins, je nach Bedarf lädt, startet und beendet dynamisch verwendete Funktionalität und erlaubt es sogar zur Laufzeit, benötigte Komponenten nachzuinstallieren. Neben Komponenten verwaltet Equinox auch komplexe Interaktionen zwischen Services. Kurz, Equinox ist ein umfangreiches und mächtiges Framework, ohne das Eclipse nicht funktionieren würde.

Mit „umfangreich“ ist dabei aber auf keinen Fall gemeint, dass Equinox als Software viel Platz in Anspruch nimmt. So kann Equinox problemlos auch auf Embbeded Devices verwendet werden. Equinox selbst ist eine Implementierung der OSGi-R4-Spezifikation, genauer gesagt sogar die Referenzimplementierung von OSGi R4.2. Über die Bedeutung des Akronyms OSGi wird gerne diskutiert. Machen Sie den Test und fragen Sie ein paar Kollegen, die OSGi täglich verwenden. Sie werden sehr wahrscheinlich sehr unterschiedliche Antworten erhalten. Ursprünglich stand OSGi für „Open Services Gateway initiative“, mittlerweile ist es aber eher ein Eigenname. OSGi wurde ursprünglich entworfen, um Features auf Geräten dynamisch laden und auch wieder entfernen zu können, beispielsweise einen bestimmten Verschlüsselungsalgorithmus auf einer Set Top Box. Die Kernidee ist, dass Funktionalität temporär ist. Sie kann entfernt und durch andere Funktionalität ersetzt werden.

Equinox und OSGi bieten das oft benötigte Komponentenmodell für Java. Jar-Archive selbst sind keine Komponenten, sondern reine Ansammlungen von ausführbarem Java-Code. Das Komponentenmodell steht außerdem konsistent unabhängig von der Java-Version zur Verfügung, es kann auf Java SE, EE und ME verwendet werden. Das gleiche Komponentenmodell kann also auf dem Desktop, im Web und auf mobilen oder eingebetteten Systemen zum Einsatz kommen. Equinox wurde das erste Mal mit der Eclipse-Version 3.0 (2004) veröffentlicht. Davor setzte Eclipse noch auf ein eigenes Komponentenmodell. Die Geschichte der Entstehung von RCP wiederholte sich um die Zeit des Eclipse-Release 3.1 (2005), als Entwickler begannen, Equinox quasi zweckzuentfremden und ganz andere Anwendung als Eclipse selbst auf Equinox laufen zu lassen, insbesondere Serverapplikationen. Heute laufen viele Application-Server auf Basis von OSGi, beispielsweise der WebSphere Application Server, WebLogic Server, GlassFish, JBoss, JOnAS und viele weitere.

Aber das ist nur der Anfang von Eclipse als Runtime-Technologie. Das Eclipse Communication Framework (ECF) [2] ist ein Framework für verteilte Server und Anwendungen. Es bietet APIs und Framework-Support, um basierend auf existierenden Protokollen Kommunikation und Messaging in die eigene Anwendung einzubauen.

EclipseLink, der Eclipse-Persistenzservice, ist die einzige OSGi-fähige Implementierung von JPA [3]. Die Eclipse Rich Client Platform, im ersten Teil des Artikels beschrieben, hat Äquivalente für den Embedded-Bereich, embedded RCP [4], sowie für das Web, die Rich Ajax Platform (RAP) [5]. Mit RAP können Anwendungen entwickelt werden, die mit nur sehr geringen Anpassungen parallel im Web und auf dem Desktop laufen (was unter dem Begriff „Single Sourcing“ bekannt ist). Zum Ausführen von Webanwendungen bietet die Eclipse-Welt den Jetty-Webserver.

Die Eclipse Foundation verwaltet eine Übersicht der Runtime-Technologien [6]. Doch Eclipse war schon immer mehr als eine reine Technologie. Was genau tut die schon oft erwähnte Eclipse Foundation, was hat es mit der Eclipse Public Licence (EPL) auf sich und wo ist das Thema Open Source geblieben? Diesen Themen widmen wir uns im nächsten Teil der Serie „Was ist Eclipse?“.

Wayne Beaton arbeitet für die Eclipse Foundation als Leiter der Committer-Community und Evangelist. Er ist Chefredakteur für die Eclipse Corner, PMC Lead des Technology Project und Project Lead der Projekte Eclipse Examples und Woolsey.

Jonas Helming und Maximilian Kögel sind Eclipse Consultants und Geschäftsführer der EclipseSource München GmbH. Sie leiten die Eclipse-Projekte EMFStore und EMF Client Platform.

Geschrieben von
Wayne Beaton, Jonas Helming und Maximilian Kögel
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.