Teil 5: Deployment

Enterprise Eclipse RCP: Deployment

Stefan Reichert

Der vorangegangene vierte Teil der Serie „Enterprise Eclipse RCP“ stellte dar, wie eine EERCP-Anwendung automatisiert gebaut und getestet werden kann. Der fünfte und letzte Teil soll nun auf das Thema „Deployment“ eingehen. Wie kann also ein getesteter Eclipse-RCP-Client initial zum Benutzer gelangen und dort bei Bedarf auch aktualisiert werden?

Zugegeben, das Deployment des Clients auf den Zielrechnern ist auf den ersten Blick eines der komplizierten Themen, wenn man sich mit Eclipse-RCP-Anwendungen beschäftigt. Anders als bei Webanwendungen, die einen Webbrowser verwenden, ist bei Eclipse-RCP-Anwendungen die Laufzeitumgebung auf dem Zielrechner nicht vorhanden. Der Eclipse-RCP-Client muss anfänglich zur Verfügung gestellt werden, d. h. auf jedem Zielrechner muss ein neues Stück Software installiert werden. Zusätzlich besteht die Herausforderung, den installierten Client aktuell zu halten, um die Kompatibilität mit dem laufenden Server zu gewährleisten.

Schaut man sich die typische Zielgruppe einer Enterprise-Eclipse-RCP-Anwendung an, dann relativiert sich jedoch der Aufwand bzw. die Komplexität. In der Regel setzt sich der Benutzerkreis aus firmeneigenen Mitarbeitern zusammen. Somit ist die Menge an Zielrechnern vergleichsweise stabil. Des Weiteren befinden sich diese meist im firmeneigenen Netz, sodass in der Regel auch die notwendige Bandbreite vorhanden ist, um den Client initial zu übertragen. Häufig existieren sogar bereits Softwareverteilungsmechanismen für die firmeneigenen Rechner, die auch für den Eclipse-RCP-Client genutzt werden können. Nichtsdestotrotz ist das Deployment und die Aktualisierung eines Eclipse-RCP-Clients eine Herausforderung, und ich möchte in diesem letzten Teil ein paar Lösungsansätze aufzeigen.

Umgebung eines Clients

Bevor ich auf die unterschiedlichen Möglichkeiten eingehe, mit denen ein Eclipse-RCP-Client zur Verfügung gestellt werden kann, sollen ein paar Worte zur Zielumgebung des Clients vorangestellt werden. Diese zu kennen, ist für das Deployment sehr wichtig. Als Beispiel eignet sich die Java-Laufzeitumgebung recht gut. Bundles definieren in der Regel im Manifest die Java-Version, die zur Ausführung notwendig ist. Dazu dient Bundle-RequiredExecutionEnvironment: J2SE-1.5 in der Datei MANIFEST.MF, die für ein Bundle mindestens Java 5 als Voraussetzung definiert. Die OSGi-Laufzeitumgebung sorgt dafür, dass das Bundle nur dann geladen bzw. gestartet wird, wenn diese Java-Version auch verwendet wird. Ansonsten wird das Bundle ignoriert. Um nun zu vermeiden, dass der Client aufgrund einer falschen oder gar fehlenden Java-Installation nicht startet, sollte die benötigte Java-VM einfach mit ausgeliefert werden. Das vergrößert zwar den Footprint des Clients, allerdings sorgt ein ausgelieferter, nicht lauffähiger Client nicht gerade für Akzeptanz unter den Benutzern. Zudem ist das Ausliefern einer eigenen Java-VM relativ einfach. Ein Eclipse-RCP-Client schaut zunächst im Installationsverzeichnis nach einem Ordner JRE und einer darin enthaltenen eigenen Java-VM, um zu starten. Erst wenn er nicht fündig wird, verwendet er die Standard-Java-VM des Rechners.

Die Frage nach der verwendeten Java-VM führt zu einem weiteren typischen Merkmal eines potenziellen Zielrechners. In der Regel sind die Anwender für das System als gewöhnliche Benutzer registriert. Es fehlt also im Normalfall das Recht, Programme auf dem Rechner zu installieren, also die Registrierung bzw. Systemdateien zu verändern. Dieser Punkt ist für den Eclipse-RCP-Client und der ggf. mit ausgelieferten Java-VM nicht relevant, da sie lediglich kopiert werden müssen. Sollten im Zuge des Deployments jedoch noch weitere Programme mit ausgeliefert werden, sollte dieser Umstand berücksichtigt werden.

Neben den Benutzerrechten ist auch die Anzahl der Benutzer auf dem Zielrechner für einen Eclipse-RCP-Client von Bedeutung. In Unternehmen ist damit zu rechnen, dass sich unter Umständen mehrere Mitarbeiter einen Rechner teilen. Somit ist es notwendig, sämtliche temporär gespeicherten Daten für jeden einzelnen Benutzer separat abzulegen. Dabei ist es wichtig, dass das Ziel zum einen benutzerspezifisch ist, und dass der Benutzer dort auch Schreibrechte hat. Ein Eclipse-RCP-Client nutzt für das Speichern von solchen Daten üblicherweise den Workspace. Jedes Bundle erhält dort im Unterverzeichnis .metadata einen eigenen Ordner, die so genannte Statelocation, um Dateien ablegen zu können. Der Ort des Workspace liegt per Default im Installationsverzeichnis eines Eclipse-RCP-Clients. Mit der Standardeinstellung würden also alle Benutzer – vorausgesetzt sie besitzen Schreibrechte im Installationsverzeichnis – im selben Workspace arbeiten. Die Anwendung müsste intern dafür sorgen, dass Daten beispielsweise im IPreferenceStore benutzerspezifisch abgelegt werden. Eleganter ist es, die Anwendung davon zu befreien und den gesamten Workspace benutzerspezifisch abzulegen. Der beste Ort ist das Benutzerverzeichnis des Betriebssystems. Mit dem Programmargument -data kann das Verzeichnis des Client-Workspace angegeben werden. Setzt man dessen Wert auf @user.home/<Name der Anwendung>, dann arbeitet jeder Benutzer in seinem eigenen Workspace.

Softwareverteilungssysteme

Die Auslagerung der benutzerspezifischen Einstellungen erlaubt es, den Client nun über beliebige Softwareverteilungssysteme bereit zu stellen. Vereinfacht wird dieser Prozess durch die Tatsache, dass keine Installation vorgenommen werden muss. Das System kann den Client sehr einfach aktualisieren. Zum anderen bleiben die Einstellungen der Benutzer trotz Aktualisierung erhalten, da sie sich nicht im Hauptverzeichnis der Anwendung, sondern im von der Aktualisierung nicht betroffenen Benutzerverzeichnis befinden.

Geschrieben von
Stefan Reichert
Kommentare

Schreibe einen Kommentar

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