Enterprise Eclipse RCP: Deployment

Kompatibilität

Nachdem ein Eclipse-RCP-Client einmal installiert wurde, gilt es, ihn aktuell zu halten. In der Regel ist das auch notwendig, da mit dem Client die Schnittstellenklassen für den Server bereitgestellt wurden. Sobald sich die Serverseite ändert, muss in den meisten Fällen auch der Client aktualisiert werden, da sich Datenstrukturen (und somit die Kommunikationsobjekte) oder Methoden verändern. Zugriffe auf den Server mit einem älteren Client müssen dabei unterbunden werden. Um das sicherzustellen, können in einem zustandsbehafteten Umfeld die laufenden Sessions serverseitig invalidiert werden, eine erneute Anmeldung mit einem „alten“ Client muss unterbunden werden.

In dem in dieser Artikelreihe beschriebenen Szenario ist der Server allerdings zustandslos implementiert. Der Client muss die Versionsinformationen demzufolge mit jedem Request, beispielsweise im HTTP Header, mitliefern. So kann serverseitig geprüft werden, ob der Request in Bezug auf die Version gültig ist, und es kann entsprechend reagiert werden. Auch hier ist eine erneute Anmeldung mit einer alten Version zu unterbinden. Der Nachteil dieser Lösungen ist, dass der Anwender eventuell keine Möglichkeit hat, im Vorwege auf die Aktualisierung zu reagieren, da die Benachrichtigung im Zuge eines fachlich motivierten Requests geschieht. Besser ist es, den Anwender frühzeitig auf das bevorstehende Deployment vorzubereiten. Dies kann mithilfe eines Polling-Mechanismus umgesetzt werden, der in regelmäßigen Abständen mit dem Server kommuniziert und den Benutzer über eine bestehende Aktualisierung informiert. Hier ist allerdings der erhöhte Kommunikationsaufwand zu berücksichtigen.

Eclipse-Update

Neben der Prüfung der Kompatibilität ist dann auch das eigentliche Aktualisieren des Clients interessant. Eclipse selbst bietet mit P2 ein komplettes Provisioning an. Dazu zählt zum einen eine UI-Komponente, mit der manuell neue Bundles von einer Updatesite installiert werden können. Daneben wird mit der P2 Director Application [5] eine Eclipse-Application-Klasse zur Verfügung gestellt, um den installierten Client zu aktualisieren. Beide Wege benötigen allerdings ein Zutun des Benutzers. Die UI-Komponente muss vom Benutzer aufgerufen werden, die Aktualisierung läuft also als Dialog. Für die Aktualisierung mithilfe der P2 Director Application muss der Client (oder eine andere entsprechend konfigurierte Eclipse-Distribution) mit der entsprechenden Application-Klasse gestartet werden.

Im Umfeld von Enterprise-Eclipse-RCP-Clients ist eine automatische Aktualisierung beim Start der Anwendung von Vorteil. Zum einen kann der Anwender die Aktualisierung nicht unterbinden, da sie grundsätzlich vor dem Start des Clients durchgeführt wird – vorausgesetzt natürlich, es liegen aktualisierte Versionen der Bundles vor. Der zweite Vorteil liegt darin, dass die Aktualisierung als Batch ohne Benutzereingaben vonstatten geht. Somit kann der Benutzer dem Client auch nicht durch Fehleingaben schaden oder ihn gar unbrauchbar machen. Auch hierfür stellt P2 die Werkzeuge zur Verfügung [6]. Sollte dann während der Verwendung ein Update bereit gestellt werden, kann der alte Client sich nach einem ungültigen Zugriff auf den Server neu starten, was dann automatisch zu einer Aktualisierung des Clients führt. Der Benutzer arbeitet somit immer mit dem aktuellen Client.

Enterprise-Eclipse-RCP-Epilog

Die fünf Teile der Reihe „Enterprise Eclipse RCP“ haben die Eckpunkte von Eclipse RCP im Bereich von verteilten Anwendungen beleuchtet und für einzelne Themengebiete exemplarisch Lösungsansätze aufgezeigt. Die Eclipse-Plattform bietet viele ausgereifte Techniken und zahlreiche verlässliche Tools, die eine gute Basis für Unternehmensanwendungen darstellen. Eclipse RCP ist keine Wunderwaffe und nicht uneingeschränkt für alle Einsatzbereiche von verteilten Anwendungen geeignet. Dennoch sollte eine Enterprise-Eclipse-RCP-Lösung bei entsprechenden Anforderungen im Rahmen des Architekturdesigns geprüft und bewertet werden. In vielen Fällen ist sie objektiv gesehen die bessere Alternative.

Stefan Reichert, Diplom-Wirtschaftsinformatiker (FH), arbeitet als Softwarearchitekt in Hamburg. Er beschäftigt sich seit mehreren Jahren mit verteilten Java-Enterprise-Anwendungen, serviceorientierten Architekturen, Eclipse und Eclipse RCP. Darüber hinaus ist er Autor mehrerer Fachartikel und regelmäßig Referent auf Konferenzen. Im August 2009 erschien sein Buch „Eclipse RCP im Unternehmenseinsatz“. Kontakt: stefan[at]wickedshell.net.
Kommentare

Schreibe einen Kommentar

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