JAXenter

Besonderheiten von EERCP

Da im Unternehmensumfeld die 3+-Tier-Variante sehr verbreitet ist, werden wir uns in diesem Artikel auf diese Variante und ihre besonderen Aspekte konzentrieren. Wir möchten dabei nicht auf Eclipse RCP Basics eingehen, sondern die speziellen Herausforderungen einer 3-Schichten-Architektur im Zusammenhang mit Rich Clients herausstellen und im Projektalltag bewährte Lösungen beschreiben.

Die Trennung der Anwendung in einzelne Schichten eröffnet, wie beschrieben, sehr viele Möglichkeiten. Dennoch existieren auch einige Herausforderungen, die es zu bewältigen gilt. Der wesentliche Punkt, der EERCP-Anwendungen auszeichnet, ist die Verteilung, also die Verbindung des Clients mit dem Backend auf dem Server über ein Netzwerk. Die Verteilung bringt weitere Anforderungen an die Architektur mit sich. Diese Anforderungen sind:

• Remoting: die Art und Weise des Zugriffs auf das Backend
• Caching: das Vorhalten von Daten auf dem Client zur Reduzierung des Datenverkehrs
• Security: Authentifikation und Autorisation für einzelne Funktionen des Backend
• Fehlerbehandlung: Behandlung von serverseitigen und clientseitigen Fehlern
• Deployment: Bereitstellung und Aktualisierung der fertigen Software

Remoting

Je nach Architekturvariante spielt Remoting eine mehr oder weniger große Rolle. Entscheidet man sich für eine Client/Serverarchitektur, wird die gesamte Remote-Kommunikation vom JDBC-Treiber durchgeführt. Möchte man jedoch eine 3+-Tier-Architektur implementieren, muss man sich intensiver mit dem Thema Remoting auseinandersetzen. Das Umfeld der Anwendung spielt dann eine wichtige Rolle und beeinflusst die Wahl des geeigneten Remoting-Protokolls entscheidend. Müssen die Clients von außerhalb des Unternehmensnetzwerks auf die Applikation zugreifen können, sollte die Kommunikation möglichst Firewall-transparent sein. Gibt es existierende Systeme, auf die zugegriffen werden soll? In diesem Fall muss man entweder das von diesen Systemen unterstützte Kommunikationsprotokoll (also z.B. CORBA-IIOP, SOAP) verwenden oder dieses System mithilfe einer Fassade kapseln (Abb. 3, 4).

Manche Anwendungen erfordern es, dass der Server Benachrichtigungen an das Frontend senden kann. Man muss sich in diesem Fall zwischen Polling und Publish/Subscribe entscheiden, was wiederum eine starke Auswirkung auf das genutzte Kommunikationsprotokoll hat.

Die Kommunikation mit dem Backend soll für das Frontend natürlich völlig transparent sein. Dies will bei der Wahl der Kommunikationstechnologie ebenfalls bedacht sein. Die gute Nachricht ist, dass dies tatsächlich möglich ist. Allerdings darf man hier nicht aus den Augen verlieren, dass die Kommunikation über ein Netzwerk deutlich langsamer ist als ein lokaler Methodenaufruf. Dies hat einen starken Einfluss auf das Design der Service-APIs: Es gilt, kleinteilige Aufrufe wie das sequenzielle Lesen von Attributen zu vermeiden und stattdessen lieber grobgranulare Aufrufe zu tätigen. Das DTO (Data Transfer Object) Pattern kommt hier zu neuen Ehren.

Anhand dieser Anforderungen ist die Wahl zwischen CORBA-IIOP, RMI, SOAP, HTTPInvoker, Hessian etc. zu treffen. Dieses Thema werden wir in einem späteren Artikel vertiefen.

Caching

Ein weiterer Aspekt beim Einsatz von RCP-Oberflächen als Frontend für Java EE-Applikationen ist clientseitiges Caching. RCP-Oberflächen qualifizieren sich unter anderem als Frontend, da sie einen extrem guten Bedienkomfort ermöglichen. Datenstrukturen, die über die Oberfläche zum einen sichtbar und zum anderen bearbeitbar gemacht werden, sind in vielen Fällen komplex und umfangreich. Somit tendieren auch die einzelnen Oberflächenteile dazu, komplex und umfangreich auszufallen. Bedienkomfort bedeutet hier, dem Anwender möglichst früh eine Rückmeldung über seine Eingabe zu geben. So werden Fehleingaben vermieden, und die Bedienung der Maske beschleunigt sich erheblich. Ein weiteres Mittel, den Bedienkomfort zu erhöhen und die Validität der Eingabe sicherzustellen, ist die Feldvervollständigung (Content Assist). Dem Benutzer werden die Werte für ein Feld vorgeschlagen, die zu einer gültigen Eingabe führen.

Betrachten wir nun die beiden Anforderungen "clientseitige Validierung" und "Feldvervollständigung". Es wird deutlich, dass in beiden Fällen größere Mengen an Daten clientseitig zur Verfügung stehen müssen. Es liegt also nahe, die benötigten Daten wiederzuverwenden, um ein ständiges Laden vom Server und damit teuren (im Sinne der Performance) Traffic zu vermeiden. Allerdings existieren situativ Beschränkungen seitens des auf dem Client zur Verfügung stehenden Hauptspeichers. Wird der Client auf einer Virtualisierungsplattform wie z.B. Citrix ausgeführt, unterliegt der Client üblicherweise recht starken Randbedingungen bezüglich des zugeordneten virtuellen Hauptspeichers. Dies kann durchaus zu Problemen führen.

Eine Lösung dieser Anforderungen liegt in der Abstraktion des Datenzugriffs auf der Clientseite. Der Zugriff auf die Daten des Servers erfolgt über eine zusätzliche Schicht, die ähnlich wie DAOs arbeitet. Hier kann dann transparent ein Caching eingehängt werden, das flexibel auf die spezifischen Anforderungen reagieren kann.

Security

Security ist ein wichtiges Feature nahezu jeder Anwendung im Unternehmensumfeld. Die Daten eines Unternehmens haben einen großen Wert und müssen vor Missbrauch geschützt werden. Der Zugang zu den Daten ist also üblicherweise durch Authentifizierung (ist der Benutzer tatsächlich der, für den er sich ausgibt) und Autorisierung (darf der Benutzer die Daten sehen bzw. bearbeiten) geschützt. Eclipse selbst ist zunächst hauptsächlich als Plattform für Entwicklungstools entstanden und verfügt daher nicht über ein ausgeprägtes Sicherheitskonzept. Um Enterprise-Eclipse-RCP-Anwendungen abzusichern, muss also eine geeignete Authentifizierungs- und Autorisationskomponente integriert werden. Ein kurzer Überblick über die hier möglichen Ansätze:

• Capabilities: Einzelne Oberflächenelemente werden je nach Nutzerrolle ein- oder ausgeblendet. Dieser Ansatz ist für eine Unternehmensanwendung nicht sicher genug, da er leicht umgangen werden kann (Kimberly Horne: Addressing UI Scalability in Eclipse, EclipseCon 2005 Talk).
• Load-Time-Modifikation der plugin.xml mit Equinox Transforms. Je nach Nutzerrolle werden einzelne Oberflächenelemente ein- und ausgeblendet. Da diese Transformation nur beim Start der Anwendung durchgeführt wird, ist auch diese Lösung nicht flexibel genug (Heiko Seeberger, Martin Lippert: Getting Hooked on Equinox, wiki.eclipse).
• Spring Security kann verwendet werden, um nicht nur funktionsorientierte (d.h. der Benutzer darf bestimmte Aktionen nicht ausführen), sondern auch datenorientierte (d.h. der Benutzer darf auf bestimmten Daten keine Aktionen ausführen) Sicherheit zu implementieren (Spring Security, Spring Security Reference).
• Equinox Security bietet schließlich Lösungen für die Bereiche User-Credential-Management (d.h. sichere Ablage von Benutzerpasswörtern inklusive Password-Recovery), User Authentication (d.h. Benutzeranmeldung mittels Dialog oder betriebssystemgestütztes Single Sign-on) sowie Codeautorisation (d.h. welcher Code darf ausgeführt werden, Einschleusen von bösartigem Code verhindern).

Alle oben genannten Ansätze lösen jedoch nur Teilaspekte der Sicherheitsanforderungen für Enterprise Eclipse-RCP-Projekte und müssen je nach Anforderung sinnvoll miteinander verbunden werden.

Fehlerbehandlung

Charakteristisch für EERCP-Anwendungen ist, wie wir festgestellt haben, die Verteilung einzelner Schichten auf die Client- bzw. Serverseite. An der Bearbeitung einer Anfrage sind allerdings sämtliche Schichten beteiligt. Selbstverständlich kann die Bearbeitung an sämtlichen Stellen entweder gewollt, durch beispielsweise fehlende oder falsche Daten, oder ungewollt, durch andere Rahmenbedingungen wie Stale Data, unterbrochen werden. In jedem Fall erwartet der Anwender eine für ihn verständliche Darstellung des aufgetretenen Fehlers und im Idealfall eine Handlungsanweisung für dessen Behebung.

Aus Sicht der Architektur gilt es, bei der Fehlerbehandlung das Remoting zwischen Client und Server zu beachten. Fehler, die auf der Serverseite auftreten, müssen in einer dem Client verständlichen Weise zurückgeliefert werden. Der Client sollte diese lediglich darstellen müssen und nicht gezwungen sein, den Fehler mühsam aufzulösen. Es ist wünschenswert, die Fehlerbehandlung möglichst nach einem einheitlichen Schema an einer einzigen Stelle zu halten.

Serverseitig ist die ideale Stelle zur Fehlerbehandlung der Service, der vom Client verwendet wird. Zum einen können hier alle serverseitig auftretenden Fehler der Anfrage zentral abgefangen werden, zum anderen stehen weitere Informationen zur Verfügung, die möglicherweise zur Darstellung des Fehlers benötigt werden. Auch ist denkbar, die Fehlermeldung mit zusätzlichen Daten wie Handlungsanweisungen oder Fehlercodes anzureichern.

Auf der Clientseite ist es ein wenig komplizierter, da die Fehlerbehandlung sich hier in die Aspekte "Darstellung" und "Behandlung des Fehlers" teilt. Für die Darstellung empfiehlt es sich, analog zur Serverseite einen zentralen Punkt zu definieren, um eine einheitliche Anzeige zu gewährleisten. Dies kann mit einem Interceptor bzw. einem Aspekt geschehen. Dieser kann im Fehlerfall die Informationen einheitlich darstellen. Die Behandlung des Fehlers muss selbstverständlich individuell von der aufrufenden Stelle erledigt werden.

Deployment

IT-Abteilungen möchten die Kosten für das Rollout und den Betrieb von Anwendungen möglichst gering halten. Dies ist einer der maßgeblichen Gründe für die starke Verbreitung von Webapplikationen im Unternehmensumfeld.

Eclipse bietet bereits seit langem mit dem Update-Manager einen Mechanismus, der die Aktualisierung von Eclipse-RCP-Anwendungen ermöglicht. Seit Eclipse 3.4 steht mit P2 eine aktualisierte Generation des Update-Managers zu Verfügung, die technologisch einen großen Fortschritt bedeutet. Neue Features sind z.B. ein Standalone-Installationsprogramm, ausfallsicherer Download mit der Möglichkeit, abgebrochene Downloads wieder aufzunehmen, sowie die Verwendung des nächstgelegenen Update-Servers (insbesondere bei weltweiten Unternehmensnetzwerken von großer Bedeutung).

Ausblick

Die Implementierung von Enterprise-Eclipse-RCP-Anwendungen ist komplex und erfordert das Nachdenken über eine Vielzahl von Aspekten. Aufgrund der Tatsache, dass es sich hier um eine noch relativ junge Technologie handelt, liegt noch keine Erfahrung auf breiter Basis vor, wie dies bei Java EE-Webapplikationen der Fall ist. Mit dieser Artikelserie soll dazu beigetragen werden, diesen Umstand zu ändern. Feedback zur Serie ist herzlich willkommen.

Peter Friese arbeitet als Softwarearchitekt für die itemis AG in Kiel (www.itemis.de, www.peterfriese.de). Er ist Committer für die Open-Source-Projekte openArchitectureWare und Eclipse Modeling. Peter ist Autor verschiedener Artikel zu den Themenkomplexen Eclipse, Spring und modellgetriebene Softwareentwicklung und hält zu diesen Themen regelmäßig Vorträge auf Softwarekonferenzen.

Stefan Reichert arbeitet als Softwarearchitekt und Berater bei Lufthansa Systems in Hamburg. Er beschäftigt sich seit mehreren Jahren mit serviceorientierten Enterprise-Anwendungen, Eclipse und Eclipse RCP. Stefan ist Autor mehrerer Artikel zum Thema Architektur und Eclipse RCP und Committer mehrerer Open-Source-Projekte.