Ausarbeitung - Department of Information Systems

Transcription

Westfälische Wilhelms-Universität Münster
Ausarbeitung
Varianten-freundliches Software-Design:
Die Eclipse-Rich-Client Platform
im Rahmen des Hauptseminars Variantenmanagement
Glenn Schaare
Themensteller: Prof. Dr. Herbert Kuchen
Betreuer: Dipl.-Wirt.Inform. Roger A. Müller
Institut für Wirtschaftsinformatik
Praktische Informatik in der Wirtschaft
Inhaltsverzeichnis
1
Einleitung................................................................................................................... 1
2
Überblick über die Eclipse-Rich-Client-Platform ..................................................... 1
3
2.1
Positionierung von Eclipse als Rich-Client ...................................................... 1
2.2
Funktionsweise der Plug-in-Architektur........................................................... 3
2.3
Lebenszykluskonzept auf Basis des OSGi-Frameworks .................................. 4
2.4
Grundlegende Plug-ins ..................................................................................... 5
Implementierung am Beispiel.................................................................................... 8
3.1
Umsetzung mit Hilfe der Runtime.................................................................... 8
3.2
Erweiterung des Plug-ins ................................................................................ 10
3.3
GUI-basierte Applikationen............................................................................ 12
4
Rich-Clients auf Basis der Eclipse-RCP.................................................................. 13
5
Bewertung der Eclipse-RCP .................................................................................... 15
6
Zusammenfassung und Ausblick ............................................................................. 16
Literaturverzeichnis ........................................................................................................ 17
II
Kapitel 1: Einleitung
1 Einleitung
Der Einsatz von Variantenmanagement kann den Aufwand der Softwareentwicklung
verringern und somit die Kosten der Bereitstellung unterschiedlicher Softwarevarianten
reduzieren. [Ti94] Die Eclipse-Rich-Client-Platform (RCP) unterstützt die Bildung von
Softwarevarianten durch ihren modularen Aufbau. Dabei kann eine neue Anwendung
nach dem Baukastenprinzip durch die Zusammensetzung unterschiedlicher Plug-ins
erstellt werden. Ab der Version 3.0 ist die Trennung von IDE-spezifischen Plug-ins und
Basis-Plug-ins vollzogen, so dass sich die Eclipse-RCP für die Entwicklung
verschiedenartiger Anwendungen empfiehlt. Grundlage dieser flexiblen Architektur ist
die Runtime Engine der Open Services Gateway Initiative (OSGi), die die Ausführung
und Verwaltung unterschiedlicher Plug-ins steuert. Die Plug-ins zur Gestaltung der
Benutzeroberfläche machen dabei den wesentlichen Teil der Eclipse-RCP aus.
Das Ziel der vorliegenden Arbeit besteht in der Untersuchung der Eclipse-RCP vor dem
Hintergrund des Variantenmanagements. Dazu soll zunächst in Kapitel 2 die Plattform
und deren wesentlichen Plug-ins beschrieben werden. Kapitel 3 bildet den Schwerpunkt
dieser Seminararbeit und thematisiert die Plug-in-Architektur der OSGi und deren
Implementierung in der Eclipse-RCP. Kapitel 4 zeigt exemplarisch das Potenzial einer
Rich-Client-Architektur an Hand des IBM Lotus Workplace, der als vollständiger
Rich-Client realisiert ist. Kapitel 5 bewertet die Eclipse-RCP hinsichtlich der im
Variantenmanagement verfolgten Ziele.
Das abschließende Kapitel fasst die wichtigsten Erkenntnisse zusammen und gibt einen
Ausblick auf die weitere Entwicklung.
2 Überblick über die Eclipse-Rich-Client-Platform
2.1 Positionierung von Eclipse als Rich-Client
Die Eclipse-Plattform entstand als Nachfolger von IBM's IDE Visual Age und sollte
zunächst als zentrale Entwicklungsplattform für Small-Talk, Java und weitere Sprachen
dienen. Nach der Freigabe als Open-Source Ende 2001 trug die durch IBM gegründete
Eclipse-Community dazu bei, dass sich die Anzahl der verfügbaren Plug-ins schnell
vergrößerte und die Eclipse-Plattform an Popularität hinzugewann. Ab der Version 2.1
wurde die Eclipse-Plattform experimentell zur Entwicklung von Desktop und
1
Kapitel 2: Überblick über die Eclipse-Rich-Client-Platform
Rich-Client-Anwendungen
verwendet,
wobei
die
Trennung
zwischen
den
Entwicklungskomponenten der IDE und den Basiskomponenten zu dieser Zeit nicht
vollständig realisiert war. Diese Lücke ist mit Eclipse-RCP 3.0 geschlossen worden.
Der Plug-in-Mechanismus ist ab dieser Version konsequent etabliert, so dass die
Eclipse-IDE selbst nur noch eine spezifische Rich-Client-Anwendung darstellt. [Da05]
Die Eclipse-Runtime-Umgebung ist die gemeinsame Basis aller Plug-ins. Diese wurde
in der Version 3.0 auf die OSGi-Runtime umgestellt. Das OSGi-Konsortium wurde
durch eine große Zahl namhafter Firmen gegründet und hat die Bereitstellung einer
offenen Diensteplattform für unterschiedliche vernetzte Geräte zum Ziel. Als
besonderen Vorteil bietet die OSGi-Plattform neben der Standardisierung auch eine
Möglichkeit, Plug-ins dynamisch zur Laufzeit zu (de)installieren.
Die Eclipse-RCP wird explizit als Rich-Client positioniert und grenzt sich damit
bewusst von den vorherrschenden Konzepten eines Slim-Clients bzw. Thick-Clients ab.
Obwohl Slim-Clients in Form von Webapplikationen in den letzten Jahren an
Bedeutung gewonnen haben, sind parallel Anwendungsfelder entstanden, die die
Entwicklung von Rich-Clients rechtfertigen. [Ga04] Hierzu gehören bspw. mobile
Anwendungen, die über keine konstante Verbindung zum Datennetz verfügen. Im
Folgenden werden die grundlegenden Charakteristika eines Rich-Clients beschrieben:
[Da05]
1. State-of-the-Art Benutzeroberfläche: Eine Rich-Client-Benutzeroberfläche sollte
sich an eine native Benutzeroberfläche anlehnen, so dass dem Nutzer die
wesentlichen Bedienelemente vertraut sind.
2. Offline- und Onlinebetrieb: Ein Rich-Client sollte auch dann funktionieren, wenn
keine Verbindung zum Server besteht. Dies setzt neben einer Anwendungslogik vor
allem die Fähigkeit voraus, Daten zu speichern.
3. Server-managed-Clients: Wartung und Installation sollten durch einen zentralen
Server unterstützt werden.
Die Eclipse-RCP greift weitgehend auf betriebssystemeigene Widgets zurück und bietet
dem Nutzer dadurch eine vertrautes Look & Feel. Die beiden übrigen Punkte hängen
maßgeblich von der spezifischen Ausgestaltung der Applikation ab, die auf Basis der
Eclipse-RCP entwickelt wird. Potenziell werden beide Anforderungen unterstützt.
2
2.2 Funktionsweise der Plug-in-Architektur
Das für die vorliegende Betrachtung konzeptionell wichtigste Merkmal von Eclipse ist
dessen Plug-in-Architektur. Im Gegensatz zu anderen Plug-in-fähigen Applikationen,
bei denen sich Erweiterungen ausschließlich auf bestimmter Funktionsbereiche
beziehen (z. B. Filter in Photoshop), besteht die Eclipse-Architektur vollständig aus
Plug-ins.
So
lassen
sich
je
nach
Anwendungsfall
unterschiedliche
hierarchisch-geschichtete Systeme bilden, in denen Plug-ins einer höheren Schicht auf
Plug-ins einer tieferen Schichten zurückgreifen.
Ein Plug-in kann als Spezialisierung einer Komponente aufgefasst werden. Eine
Komponente ist ein Softwarebaustein, der über eine klar definierte Schnittstellen
Funktionalität bereitstellt. [Ba05] Von Komponenten wird auch gesprochen, wenn in
einem Komponentenmodell (Bsp. EJB) ein Mechanismus zur Verwaltung des
Lebenszyklus bereitgestellt wird. In einer Plug-in-Architektur wird der Lebenzyklus
durch eine Laufzeitumgebung (Runtime) verwaltet, während dies im Fall von
Komponentenmodellen häufig durch einen Container durchgeführt wird, der auch in
einem separaten Application Server betrieben werden kann. Komponenten in Bezug zu
einem Komponentenmodell stellen häufig eine für sich genommen gekapselte
Funktionalität bereit, während Plug-ins tendenziell eher im Zusammenspiel mit anderen
Plug-ins Funktionalität erbringen. Beispielsweise stellt die Eclipse-Workbench nicht nur
eine Erweiterung eines bestehenden Plug-ins dar, sondern wird selbst durch andere
Plug-ins erweitert.
Abb. 1: Verwendung von Extensions und Extension Points
In einer Plug-in-Architektur ist somit die Integration unterschiedlicher Plug-ins
tendenziell bedeutender als in einer Komponenten-Architektur. Diesem Umstand wird
Eclipse durch die explizite Offenlegung der Schnittstellen unter Verwendung von
Extensions und Extension Points gerecht. Der Mechanismus funktioniert wie folgt: Ein
3
Plug-in definiert einen Extension Point, der Anforderungen an eine Extension
beschreibt. Eine oder mehrere Extensions können einen bereitgestellten Extension Point
verwenden. (Vgl. Abb. 1) Dadurch ist es möglich, eine komplexe Applikationen aus
einer Menge von Plug-ins aufzubauen.
2.3 Lebenszykluskonzept auf Basis des OSGi-Frameworks
Ab
der
Version
3.0
setzt
die
Eclipse-RCP
eine
Implementierung
der
OSGi-Diensteplattform ein. Das auf Java basierende Framework verwaltet Dienste auf
Komponentenbasis. Das ursprüngliche Einsatzgebiet von OSGi waren verteilte
Anwendungen, die auf lokalen Netzen und eingebetteten Geräten zum Einsatz kommen
sollten. Die für die Realisierung von Diensten verwendeten Java-Klassen und
Ressourcen werden in so genannten Bundles zusammengefasst. OSGi-konforme Server
können Bundles laden, installieren und wieder entfernen. Dabei verwaltet der
OSGi-Server die Abhängigkeiten zwischen Bundles in einer dynamischen und
skalierbaren Ablaufumgebung.
Abb. 2: Lebenzyklus eines Bundles [Os05]
Bundles werden in einer JAR-Datei im OSGi-Server deponiert. Beschreibende
Informationen zu den Bundles werden in einer so genannten Manifest-Datei
gespeichert. Für den Start einer Anwendung wertet der OSGi-Server den
Bundle-Activator-header der manifest.mf aus, der den Namen der zu startenden Klasse
enthält. [OS05] Danach kann sich das Bundle in einem der in Abb. 2 beschriebenen
Zustände befinden.
In Eclipse erfüllt die Runtime (genauer die Plug-ins org.eclipse.osgi und
org.eclipse.core.runtime) die Aufgabe des OSGi-Servers. Plug-ins bilden dabei das
4
Äquivalent zu den Bundles von OSGi. Die interne Realisierung von Eclipse bildet
Plug-ins auf OSGi-konforme Bundles ab. Jedes Plug-in in Eclipse muss entsprechend
der OSGi-Spezifikation eine Instanz des Interfaces BundleActivator und eine
Manifest-Datei bereitstellen. In Eclipse erben alle zu registrierenden Plug-ins von der
abstrakten Klasse Plugin, die einen solchen BundleActivator implementiert und damit
die Methoden start( ) und stop( ) für die jeweilige Klasse bereitstellt. Letztere wird vor
einem Update ausgeführt, sofern sich das Plug-in in aktivem Zustand befindet. [Ec05a]
Plug-ins werden erst in den Speicher geladen, wenn ihre Funktionalität benötigt wird
(Lazy-Loading). Theoretisch ermöglicht das verzögerte Laden, Anwendungen mit einer
nahezu unbegrenzten Anzahl von Plug-ins zu erweitern, da eine installierte Erweiterung
zunächst so gut wie keine Ressourcen benötigt. Als problematisch erweist sich das
dynamische Entladen der Plug-ins in Eclipse 3.0. Der Programmierer muss selbst dafür
sorgen, dass die referenzierten Objekte freigegeben werden, so dass sie über den
Garbage Collector aus der VM entfernt werden können. [Li05] Dazu werden in Eclipse
so genannte Extension-Tracker verwendet, die abhängige Objekte im Nachgang einer
Deinstallation freigeben. Außerdem muss von dem erweiterten Plug-in (das Plug-in,
welches den Extension Point anbietet), die Referenz gelöscht werden. Da dieses jedoch
nicht wissen kann, wann ein Plug-in dynamisch installiert oder deinstalliert wird, muss
es über entsprechende Veränderungen benachrichtigt werden. Die verwaltende Einheit
(Extension Registry) bietet genau für diesen Fall an, entsprechende Listener zu
registrieren.
2.4 Grundlegende Plug-ins
Ein großer Anteil der Plug-ins dient der Bereitstellung der Benutzeroberfläche. Die
Plug-ins Help, Update und Team repräsentieren optionale Plug-ins, während
Workbench, SWT, JFace und Workspace praktisch in jeder Applikation zu finden sind,
die über eine GUI verfügt. Abb. 3 gibt einen Überblick über die wesentlichen Plug-ins
der Eclipse-RCP-Architektur.
5
Abb. 3: Eclipse-RCP – Architekturüberblick [Ob03]
Im Folgenden seien die wichtigsten Plug-ins kurz beschrieben.
Workbench
Die Workbench definiert die Benutzeroberfläche der Eclipse Anwendung und legt fest,
wie unterschiedliche Workbench-Komponenten angezeigt und verwendet werden. Die
Workbench verwendet sowohl Bestandteile von SWT als auch von JFace. Aus Sicht des
Nutzers besteht die Workbench aus Editoren und Views. Die Eclipse-RCP stellt
unterschiedliche Editoren zur Bearbeitung von Texten bereit, die von der abstrakten
Klasse EditorPart erben. Diese Klasse stellt neben grundlegenden Methoden zum
Zugriff auf Werkzeugleisten oder Menüs auch Methoden zum Sichern der Dateninhalte
bereit. Views bieten Informationen über ein spezifisches Objekt, an dem der Nutzer
gerade arbeitet. Beispiele für Views sind der Standard-Property-View oder der
Outline-View. Editoren und Views können mit dem Plug-in Eclipse Visual Editor 1.1
auf einfache Art und Weise erzeugt und bearbeitet werden.
Zusammenstellungen
von
Editoren
und
Views
werden
in
Perspektiven
zusammengefasst. Eine Perspektive verwaltet das Anzeigeverhalten einzelner
Komponenten und das Layout der Benutzeroberfläche. Über die Extension Points des
Plug-ins org.eclipse.ui.perspectives können unterschiedliche Komponenten einer
Perspektive hinzugefügt werden.
SWT
Das Standard Widget Toolkit (SWT) ist eine Bibliothek für die Erstellung grafischer
Oberflächen, die es ermöglicht, native Widgets des jeweiligen Betriebssystems zu
verwenden. Die Emulierung beschränkt sich auf wenige, nicht-standardisierte Widgets,
die nicht betriebssystemübergreifend vorhanden sind. [Ob03]
Daraus ergeben sich zwei grundlegende Vorteile: Die Applikation integriert sich sowohl
visuell wie auch funktional (Drag & Drop) in die gewohnte Betriebssystemumgebung
und eine aufwendige Emulierung von Widgets kann weitgehend vermieden werden. In
6
der Eclipse-RCP sind die für SWT relevanten Plug-ins in dem Paket org.eclipse.swt
zusammengefasst.
JFace
JFace ist ein UI-Toolkit, das standardisierte Hilfsklassen für unterschiedliche
Routineaufgaben der UI-Programmierung bereitstellt. Dabei ist sowohl die API als auch
die Implementierung betriebssystemunabhängig. Die bereitgestellten Funktionen lassen
sich in vier Kategorien einteilen [EH05]:
1. Viewers:
JFace
stellt
Viewer-Komponente
einige
des
Viewer
zur
Verfügung,
welche
Model-View-Controller-Entwurfsmusters
die
(MVC)
implementieren. Der Viewer erzeugt Ereignisse, die dem Controller zugesandt
werden, der Änderungen an den Modelldaten vornehmen kann. [Da05] Viewer sind
keine reinen Repräsentationsobjekte der GUI, sondern verwalten zusätzlich ihre
Dateninhalte wie z. B. Tabellen oder Trees. Die Verwendung des Entwurfsmusters
hat neben der sauberen Trennung der Verantwortlichkeiten vor allem den Vorteil,
dass verschiedene Viewer auf ein Modell angewendet werden können.
2. Actions: Der Mechanismus erlaubt die generische Verwendung von Methoden
durch unterschiedliche Widgets. Das Verhalten der Action wird durch den
Übergabeparameter bestimmt (parametrischer Polymorphismus).
3. Ressourcenverwaltung: JFace bietet unterstützende Klassen für die Verwaltung
von Bildern, Schriften und Farben. Verschiedene statische Methoden erlauben die
Entnahme und das Hinzufügen bestimmter Ressourcen zu einem Repository.
Beispielsweise lassen sich durch die Klasse FontRegistry aller Schriftarten einer
Applikation verwalten.
4. Dialoge und Wizards: JFace unterstützt die Erstellung komplexer Dialoge und
Wizards.
Die Klassen von JFace sind nicht unbedingt an Eclipse gebunden, können also auch in
anderen Umgebungen eingesetzt werden. Jedoch macht insbesondere die Workbench
umfangreichen Gebrauch von JFace.
Workspace
Der Workspace stellt eine API zur Verfügung, die es ermöglicht, auf Projekte, Ordner
und Dateien zuzugreifen, die im lokalen Dateisystem des Nutzers abgelegt sind. Diese
7
Kapitel 3: Implementierung am Beispiel
Basisfunktionalität wird um eine Zugriffshistorie und einen Marker-Mechanismus
ergänzt. Letzterer speichert Systemmeldungen wie Compilerfehler oder Suchergebnisse.
Der Marker-Mechanismus ist durch den Plug-in Entwickler erweiterbar. Darüber hinaus
stellt der Workspace unterschiedliche Change-Listener zur Verfügung, die, ausgelöst
durch Änderungen im Dateisystem, eine bestimmte Komponente benachrichtigen.
Aktualisierung, Hilfesystem und Versionsverwaltung,
Die zuvor beschriebenen Plug-ins dienen hauptsächlich der Bereitstellung von
Funktionalität mit Bezug zur Benutzeroberfläche. Darüber hinaus existieren Plug-ins,
die ein Hilfesystems (org.eclipse.help) einbinden und die bestehende Anwendung
aktualisieren bzw. erweitern (org.eclipse.update). Das Plug-in Update muss nicht
zwingend manuell durch den Update-Manager ausgeführt werden (vergleichbar zu der
Umsetzung in der IDE), sondern kann als Teil eines Batch-Prozesses automatisch
angestoßen werden. Für den gemeinsamen Zugriff auf eine zentrale Ressource eignen
sich das Team-Plug-in (org.eclipse.team), welches Zugriff auf einen CVS-Server
bereitstellt.
3 Implementierung am Beispiel
Zur Verdeutlichung der Funktionsweise des Plug-in-Mechanismus wird in diesem
Abschnitt ein einfaches Programm mit Hilfe der Eclipse-Runtime erstellt. Als
Ausgangspunkt dient die Klasse TraditionalViewer. Die Umsetzung erfolgt in zwei
Schritten:
1. Realisierung der bestehender Funktionalität als Plug-in mit Hilfe der
Eclipse-Runtime.
2. Erweiterung des Plug-ins durch die Definition eines eigenen Extension Points.
3.1 Umsetzung mit Hilfe der Runtime
Das herkömmliche Java-Programm TraditionalViewer wird über die main-Methode
gestartet und funktioniert unabhängig von anderen Klassen.
public class TraditionalViewer {
public static void main(String[] args) {
String m_text = "MyTextContent";
System.out.println(m_text);
}
8
Für eine Applikation auf Basis der Eclipse Runtime sind mehrere Klassen notwendig.
Abb. 4 gibt einen Überblick über den Aufbau eines Plug-ins.
Abb. 4: Aufbau eines Plug-ins
Damit die Eclipse-Runtime zur Ausführungszeit die verschiedenen Plug-ins erkennt,
wird die Relation zwischen Extension und Extension Points in der plugin.xml
beschrieben. Aus Gründen der Konformität zu der OSGi-Spezifikation wird parallel die
manifest.mf erstellt. Die Runtime wertet die beschriebenen Abhängigkeiten aus und
stellt eine entsprechende Registry bereit, in der die Abhängigkeiten zur Laufzeit
abgefragt werden können.
<plugin>
<extension
id="viewer"
name="Viewer"
point="org.eclipse.core.runtime.applications">
<application>
<run class="textViewer.Viewer"/>
</application>
</extension>
</plugin>
Die Viewer-Klasse (Umsetzung des TraditionalViewers) erweitert das Plug-in am
Extension Point (EP) org.eclipse.core.runtime.applications durch eine Applikation. Die
Spezifikation des EP legt fest, dass eine Application eine run-Methode und das Interface
IPlatformRunnable implementiert. Die Umsetzung erfolgt in der Viewer-Klasse. Der
Methodenaufruf run startet die Runtime und übergibt der Applikation die Argumente in
Form eines nicht näher spezifizierten Objects.
Die wenigen Änderungen reichen aus, um das Programm über die Eclipse-Runtime zu
starten.
9
import org.eclipse.core.runtime.IPlatformRunnable;
import org.eclipse.core.runtime.Plugin;
public class Viewer extends Plugin implements
IPlatformRunnable {
/* Start der Runtime. Spezifikation der Run-Methode
* entsprechend IPlatformRunnable.
*/
public Object run(Object args) throws Exception {
return EXIT_OK;
}
}
}
3.2 Erweiterung des Plug-ins
Möchte man nun das erstellte Plug-in selbst für potentielle Erweiterungen öffnen,
beispielsweise für einen Pretty Printer oder eine Rechtschreibprüfung, so muss darin
ein eigener EP definiert werden. Dazu wird zunächst die plugin.xml um einen
entsprechenden Eintrag ergänzt.
<extension-point id="viewerAdd" name="ViewerAdd">
Um „Viewer“ zu erweitern, wird ein Interface definiert, das den Text an entsprechende
Plug-ins weiterreicht.
public interface PluginViewerAdd {
String performChange(String s);
}
Die folgende Klasse implementiert das Interface und führt eine Trivialoperation aus.
public class PrettyPrinter implements PluginViewerAdd {
public String performChange(String s) {
System.out.println ("Pretty Printer arbeitet");
// Umwandeln in Großbuchstaben
return s.toUpperCase();
} }
Die Erweiterung wird ebenfalls in der plugin.xml beschrieben
<extension
id="prettyprinter"
name="PrettyPrinter"
point="textViewer.viewerAdd">
<filter class ="textViewer.PrettyPrinter"/>
</extension>
10
Auf die selbe Art und Weise können weitere Extensions an den definierten EP
angeschlossen werden. Im Folgenden wird ausgehend von der Viewer-Klasse auf
Dienste des Plug-ins Pretty Printer zugegriffen:
public class Viewer extends Plugin implements IPlatformRunnable{
// Referenz auf die Registry holen
IExtensionRegistry registry = Platform.getExtensionRegistry();
/* Verfügbare Plugins zur dem Extension Point "viewerAddID"
* holen und als IConfigurationElement-Array speichern.
* IConfigurationElement stellt eine Methode bereit um
* ausführbare Extensions zu erstellen
*/
IConfigurationElement[] plugins = registry
.getConfigurationElementsFor("textViewer.viewerAddID");
/* Der Text kann potentiell mehreren Plug-ins zur Bearbeitung
* übergeben werden (abhängig von der Anzahl der Extension
* zum EP) die jeweils eine bestimmte Operation
* (Rechschreibprüfung, Pretty Print...)ausführen.
*/
for (int j = 0; j < plugins.length; j++) {
// Eine ausführbare Extension wird erstellt.
PluginViewerAdd pp = (PluginViewerAdd)
plugins[j].createExecutableExtension("class")
// Die jeweilige Methode wird angewandt
m_text = pp.performChange(m_text);
}
// Konsolenausgabe des geänderten Textes
return EXIT_OK;
}
}
Die Klasse bedient sich zunächst der Plug-in-Registry um auf verfügbare Plug-ins
zuzugreifen. Plug-ins zum EP viewerAdd werden nacheinander auf den Text angewandt.
So kann auf einfache Art und Weise zusätzliche Funktionalität innerhalb des Plug-ins
Viewer erbracht werden, das selbst ein Plug-in zu einem EP darstellt.
Es wird deutlich, dass Plug-ins eine explizite und robuste Schnittstelle definieren, die
einfach zu erweitern ist. Dabei führt der OSGi-Server das gesamte Management im
Hintergrund durch, so dass sich die Arbeit auf die Implementierung der gewünschten
Funktionen beschränkt.
11
3.3 GUI-basierte Applikationen
Die Erstellung einer GUI-basierten Applikation erfolgt prinzipiell ähnlich. Der EP
org.eclipse.core.runtime.applications wird allerdings derart erweitert, dass in der
korrespondierenden Run-Methode eine Workbench erzeugt wird. Der Methodenaufruf
createAndRunWorkbench öffnet ein Fenster und läuft so lange in einer Schleife, bis das
letzte Fenster geschlossen wird. Mit der Terminierung werden die durch das Fenster
belegten Ressourcen freigegeben.
public class Application implements IPlatformRunnable {
Display dl = PlatformUI.createDisplay();
try {
// Workbench erzeugen und starten. Klasse WbA erbt
// von WorkbenchAdvisor und muss separat erstellt werden
int returnCode =
PlatformUI.createAndRunWorkbench(dl, new WbA());
if (returnCode == PlatformUI.RETURN_RESTART) {
return IPlatformRunnable.EXIT_RESTART;
}
return IPlatformRunnable.EXIT_OK;
} finally {
display.dispose();
}
}
}
Von zentraler Bedeutung ist die Klasse WbA
(ein abweichender Name ist
selbstverständlich möglich), die von der abstrakt definierten Klasse WorkbenchAdvisor
erbt und durch den Programmierer selbst zu erstellen ist. Das Verhalten der
Benutzeroberfläche zur Laufzeit kann gesteuert werden, indem bei der Erstellung der
Klasse WbA die Laufzeitmethoden [Vgl. Ec05a] der Klasse WorkbenchAdvisor
überschrieben werden. Beispielsweise kann durch den Methodenaufruf postShutdown
der Zustand der Workbench dauerhaft gespeichert werden. Innerhalb der Methode
initialize können der Workbench weitere Perspektiven hinzugefügt werden, die dem
Nutzer zur Laufzeit zur Verfügung stehen. Für die Steuerung der Workbench sind
außerdem die Klassen WorkbenchWindowAdvisor und ActionBarAdvisor von
besonderer Bedeutung. Für eine detaillierte Beschreibung sei auf die Literatur
verwiesen.
12
Kapitel 4: Rich-Clients auf Basis der Eclipse-RCP
4 Rich-Clients auf Basis der Eclipse-RCP
In den vorherigen Kapiteln wurden die grundlegenden Konzepte der Eclipse-RCP
beschrieben. Ziel dieses Kapitels ist eine integrierte Betrachtung der Komponenten in
einem existierenden Anwendungssystem. Als Beispiel soll die Groupware-Lösung IBM
Lotus Workplace (LW) dienen, die im Vergleich zu dem parallel durch IBM
vertriebenen Produkte Lotus Notes/Domino (LN/D) technology eine moderne, offene
Architektur aufweist, jedoch zur Zeit als funktional rückständig gegenüber LN/D gilt.
Die beiden Produkte werde vermutlich in den nächsten Jahren in einer einheitlichen
Version integriert.[Ga04]
Der LW setzt auf Clientseite die Eclipse-RCP als Integrationsplattform ein. Neben den
Open-Source-Plug-ins, basiert der LW auf einer Reihe von IBM Plug-ins, die
insbesondere Persistenz- und Kommunikationsdienste in Zusammenhang mit einem
WebSphere Application Server erbringen (vgl. Abb. 5).
WebSphere Application Server
IBM Workplace Client Technology
Update
Manager
Help
Workbench
JFace
Alerts
Logging
SWT
Platform Runtime
JRE
WMM
Model
Manager
Service
Locator
Portal
Integration
J2EE Client Container
(EJB Access)
IBM Cloudscape
(RDBMS)
Operating System
Selected Updated Eclipse Plug-ins
Selected New IBM Workplace Client Technology Plug-ins
Abb. 5:IBM Lotus Workplace Architektur [Ib04]
Der LW erfüllt die in Kapitel 2 beschriebenen Anforderungen an einen Rich-Client
durch die Verwendung einer zeitgemäßen, dem Nutzer vertrauten Benutzeroberfläche,
die auf Basis der Grafikbibliotheken SWT und JFace erstellt wurde. (Vgl. Abb. 6)
Desweiteren kann der LW sowohl im Online- wie auch im Offlinebetrieb verwendet
werden. Die Eigenschaft der Persistenz wird in LW durch einen lokalen, kompakten
EJB-Container realisiert, der im Offlinebetrieb Zugriff auf eine verschlüsselte,
13
Kapitel 4: Rich-Clients auf Basis der Eclipse-RCP
relationale Datenbank hat, in der die Nutzdaten abgelegt sind. Die Aktualität der Daten
wird
bei
erneuter
Synchronisation
mit
der
zentralen
Servereinheit
(WebSphere Application Server) sichergestellt. [Ib05a]
Die Anforderung bezüglich Wartung und Installation von Programmen durch einen
zentralen Server wird durch die Eclipse-RCP-Komponente Update zur Verfügung
gestellt, die installierte Versionen bestimmter Features bzw. Plug-ins auf die
Versionsnummer hin überprüft und diese gegebenenfalls ersetzen kann. Die
IBM Workplace Client Technology, die der LW zu Grunde liegt, verwendet den
WebSphere Application Server
für
die
Auslieferung
neuer
und
zusätzlicher
Komponenten.
Abb. 6: IBM Workplace Benutzeroberfläche
Das Beispiel des IBM Lotus Workplace verdeutlicht, dass sich die Eclipse-RCP als
Ausgangsbasis zur Erstellung komplexer Rich-Clients eignet. IBM profitiert hierbei von
der konsequenten Weiterentwicklung der Eclipse-RCP durch einen großen Nutzerkreis
in der Community. Im Gegenzug stellt IBM immer wieder umfangreiche
Softwarekomponenten unter der Open-Source-Lizenz zur Verfügung.[IB05b]
14
Kapitel 5: Bewertung der Eclipse-RCP
5 Bewertung der Eclipse-RCP
Das Variantenmanagements zielt darauf ab, den Aufwand der Softwareentwicklung zu
verringern und somit die Kosten der Bereitstellung unterschiedlicher Softwarevarianten
zu reduzieren. [Ti94] Bei der Herstellung von Software ist ein umfassender
Kostenbegriff heranzuziehen, der neben den einmaligen Erstellungskosten auch
Wartungs- und Erweiterungskosten miteinbezieht. Als weiteres Ziel, ist die Qualität der
erstellten Software zu garantieren, so dass der Nutzen der Software die Investition des
Kunden
rechtfertigt.
Aus
den
genannten
Forderungen
lassen
sich
vier
Bewertungskriterien ableiten, nach denen die Softwareerstellung mit der Eclipse-RCP
beurteilt werden kann.
1. Implementation: Ein Großteil des Erstellungs- und Integrationsprozesses wird durch
spezielle Wizards und Konfigurationsschaltflächen unterstützt, wodurch sich die
Verwendung des Plug-in-Mechanismus unkompliziert gestaltet. Mit zunehmender
Größe einer Applikation erweist sich eine Plug-in-Architektur als äußerst wirtschaftlich,
da der Programmierer auf standardisierte Plug-ins zurückgreifen kann, die durch einen
großen Nutzerkreis erstellt und getestet werden. Die Verwendung standardisierter
Plug-ins zwingt den Programmierer zwar zur Einhaltung externer Standards, jedoch
erscheint die Einschränkung der Flexibilität vor dem Hintergrund des genannten
Vorteils akzeptabel.
2. Maintenance: Durch die Modularisierung einer Applikation kann die Wartbarkeit
erhöht werden. Dieses Prinzip gilt sowohl auf Ebene einzelner Klassen wie auch auf
Ebene der Plug-ins. Im Idealfall können einzelne Plug-ins zur Laufzeit ausgetauscht
oder aktualisiert werden, ohne den Ablauf der Gesamtapplikation zu unterbrechen. In
der Praxis wird dies jedoch nicht immer erreicht. Beispielsweise kann der
Releasewechsel von Version 3.0 auf 3.1 der Eclipse-RCP zu Kompatibilitätsproblemen
bei bestehenden Plug-ins führen, die Anpassungen am Quellcode erfordern (Dies gilt
sogar für die kompakte Anwendung aus Kapitel 3.1 ff., die auf Basis der Version 3.0
geschrieben
wurde).
Ebenfalls
problematisch
erweist
sich
das
dynamische
Laden / Entladen von Plug-ins (vgl. Kapitel 2.3), das für eine Aktualisierung zur
Laufzeit notwendig ist. Trotz der genannten Schwachstellen kann eine auf Plug-ins
aufgebaute Applikation als wesentlich wartungsfreundlicher angesehen werden, als eine
monolithische Applikation, da die relevanten Schnittstellen transparent gestaltet sind.
15
Kapitel 6: Zusammenfassung und Ausblick
3. Usability: Anwendungen auf Basis der Eclipse-RCP erlauben ein natives
Look & Feel abhängig vom Betriebssystem des Anwenders. Damit wird die Akzeptanz
für die Anwendung durch den Nutzer erhöht und gleichzeitig der potenzielle
Nutzerkreis ausgeweitet.
4. Performance: Die Umsetzung des OSGi-Standards in der Version 3.1 der
Eclipse-RCP erlaubt das dynamische Laden und Entladen von Plug-ins zur Laufzeit, so
dass auch umfangreiche Anwendungen performant umgesetzt werden können. Weitere
Performanceverbesserungen sind für die Version 3.2 der Eclipse-RCP angekündigt.
Hinsichtlich der vier Kriterien kann die Eclipse-RCP überwiegend positiv bewertet
werden. Die beschriebenen Problembereiche des 2. Gliederungspunktes lassen sich
nicht immer eindeutig auf Charakteristika der Plattform zurückführen und können durch
Anpassungen am Quellcode umgangen werden.
6 Zusammenfassung und Ausblick
Die Untersuchung der Eclipse-RCP hat gezeigt, dass die realisierte Plug-in-Architektur
wirtschaftliche Softwareerstellung ermöglicht und bedeutende Vorteile gegenüber einer
monolithischen Implementation mit sich bringt. Große Anwendungen lassen sich
übersichtlich strukturieren und besser warten. Aus Nutzersicht sind insbesondere die
native Benutzeroberfläche und eine vergleichsweise gute Performance hervorzuheben.
Der Erfolg von Eclipse und den auf Eclipse aufbauenden Produkten kann als ein Beweis
angesehen werden, dass die Plug-in-architektur nicht nur eine hervorragende
theoretische Idee ist, sondern auch effizient und skalierbar umgesetzt werden kann.
Diese Eigenschaften machen sie interessant für vielfältige Arten von Anwendungen, die
entweder in bestimmten Bereichen erweiterbar sein oder insgesamt aus Plug-ins
aufgebaut werden sollen. Aus der Sicht des Variantenmanagements sind es exakt die
genannten Vorteile, die positiv auf die Ziele hinsichtlich Wiederverwendbarkeit und
Aufwandsreduzierung im Erstellungsprozess wirken.
Für
die
Zukunft
ist
anzunehmen,
dass
neben
den
bereits
bestehenden
IBM-Implementationen weitere Anwendungssysteme auf Basis der Eclipse-RCP
entstehen werden.
16
Kapitel 0: Literaturverzeichnis
Literaturverzeichnis
[Ba05]
Heide Balzert: Lehrbuch der Objektmodellierung, Spektrum Akademischer
Verlag, 2005.
[Br05]
Kai Brüssau: Eclipse – Die Plattform, Software & Support Verlag GmbH,
2005.
[Da05]
Berthold Daum: Rich-Client-Entwicklung mit Eclipse 3.1, D-Punkt Verlag,
2005.
[Ec05a]
Eclipse Foundation. Eclipse help system, http://help.eclipse.org, 2005.
Abrufdatum: 02.12.05.
[Ec05b]
Eclipse Foundation. The Eclipse Project DRAFT 3.2 Plan,
http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_2.html,
2005. Abrufdatum: 02.12.05.
[Ga04]
Gartner Research. IBM Workplace Will Eclipse Lotus Notes/Domino
Technology, ID Number: G00125012, 2004.
[Ib04]
IBM Corp.: IBM Workplace Client Technology (Rich-Client Edition)
Technical Overview, http://www.redbooks.ibm.com, 2004. Abrufdatum:
02.12.05.
[Ib05a]
IBM Corp.: IBM Workplace Client Technology architecture, http://www128.ibm.com/developerworks/lotus/library/wct-architecture, 2005.
Abrufdatum: 02.12.05.
[Ib05a]
IBM Corp.: IBM to Contribute Software Development Blueprints to Open
Source Community, Press release, Oktober 2005.
[Li05]
Martin Lippert, Bernd Kolb: Neustart?!? Warum? - Mit Eclipse 3
dynamische Plug-ins implementieren, Eclipse Magazin, Volume 3, 2005,
pp. 28-30.
[Ma03]
Klaus Marquardt, Markus Völter: Plug-Ins – applikationsspezifische
Komponenten,Java-Spektrum, Volume 2, 2003, pp. 20-25.
[Mc05]
Jeff McAffer, Jean-Michel Lemieux: Eclipse Rich-Client Platform:
Designing, Coding, and Packaging Java Applications, Addison Wesley,
2005.
[Ob03]
Object Technology International, Inc.: Eclipse Platform Technical
Overview, 2003.
[Os05]
OSGi Alliance: OSGi Service Platform Core Specification, Release 4, 2005.
[Ti94]
Walter Tichy: Configuration management, Wiley, 1994.
17

Ausarbeitung - Department of Information Systems

Transcription

Similar documents

Eclipse RCP - Entwicklung von Desktop-Anwendungen

Contents - The X Lab

DIVSI Studie – Wissenswertes über den Umgang mit Smartphones