Eclipse als Anwendungsframework und Runtime

Was ist Eclipse? Teil 2

Jonas Helming, Maximilian Kögel, Wayne Beaton
Preis

Kostenlos

Titel

Eclipse

Hersteller

Eclipse Foundation

Lizenz

Eclipse Public Licence (EPL)

Preis

Kostenlos

Download
Link

Das mittlerweile über etliche Jahre gewachsene Gebilde Eclipse lässt sich nur schwer zusammenfassen. Im ersten Teil der Reihe „Was ist Eclipse?“ 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 im Jahr 2002, 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 Remote Application Platform (RAP, früher: Rich Ajax Platform) [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 dieser Serie. 

Serie: Was ist Eclipse?

Teil 1: Eclipse als Java IDE, IDE Framework und Tools-Plattform
Teil 2: Eclipse als Anwendungsframework und Runtime
Teil 3: Open Source, Eclipse Foundation, EPL und das Eclipse-Ökosystem

Geschrieben von
Jonas Helming
Jonas Helming
Dr. Jonas Helming ist Geschäftsführer der EclipseSource München GmbH sowie Consultant, Trainer und Software Engineer im Bereich Eclipse-Technologie. Seine Schwerpunkte liegen neben Java auf den Technologien Eclipse RCP, Eclipse-Modellierung und Eclipse 4. Weiterhin verfügt er über mehrjährige Erfahrung in der Etablierung und Anwendung von agilen Prozessen. Jonas ist aktives Mitglied der Eclipse-Community, leitet mit der EMF Client Plattform und dem EMFStore zwei bei der Eclipse Foundation gehostete Open-Source-Projekte und ist in einigen weiteren aktiv beteiligt. Als Berater und Trainer verfügt er über mehrjährige Erfahrung in der Vermittlung von Themen rund um Java und Eclipse sowie agilen Prozessen und hält einen Lehrauftrag der Technischen Universität München. Darüber hinaus ist er als Speaker regelmäßig auf Kernkonferenzen wie der JAX oder der EclipseCon. Kontakt: jhelming@eclipsesource.com
Maximilian Kögel
Maximilian Kögel
Dr. Maximilian Kögel ist Geschäftsführer der EclipseSource München GmbH und arbeitet als Senior Software Architect im Bereich Eclipse- und Web-Technologie. Neben seiner Fokussierung auf das Eclipse Modeling Framework und Eclipse RCP ist er auch mit der Entwicklung von Webapplikationen mit AngularJS, Web Components und JSON Schema vertraut. Ein Kernthema seiner Arbeit ist das Erstellen von Modellierungswerkzeugen basierend sowohl auf einem Eclipse- als auch einem Web Technologiestack. Er ist ein aktives Mitglied der Eclipse-Community, regelmäßiger Sprecher auf EclipseCons, Leiter und Committer bei mehreren Eclipse Projekten, u.a. EMFForms und EMF Core und nicht zuletzt Mitglied im Eclipse Architecture Council. Auch außerhalb des Eclipse Ökosystems ist er in Open-Source-Projekten aktiv und leitet z.B. das JSONForms-Projekt zur Entwicklung von Web-Applikationen. Als Berater und Trainer verfügt er über langjährige Erfahrung in der Anwendung und Vermittlung von Expertenwissen rund um Java, Eclipse und Web-Technologien sowie agilen Prozessen.
Wayne Beaton
Wayne Beaton
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.
Kommentare

Schreibe einen Kommentar

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