Hauptargumente der Gegner von Java-basierten Clients sind die "langsame Verarbeitungsgeschwindigkeit" (ein Relikt aus alten Applet-Zeiten) sowie das aufwändige Deployment-Verfahren (neben der Applikation muss auch noch ein JRE deployt werden). Aus diesen Gründen wurden in den vergangenen Jahren viele Anwendungen, die eigentlich besser als Rich Client umgesetzt worden wären, als Webapplikation umgesetzt. Dass diese Argumente nicht (mehr) stichhaltig sind, wissen Eclipse-Benutzer schon seit langem: Eclipse-basierte Anwendungen haben ein natives Look&Feel und werden nahezu genauso schnell ausgeführt wie native Anwendungen. Auch das Deployment ist dank Update-Manager mittlerweile unternehmenstauglich. Doch wie kann die Kopplung eines RCP Frontends an einen Backend-Service erfolgen und was gilt es sonst noch zu beachten?
Was ist eigentlich Enterprise Eclipse RCP?
Große Softwarelösungen im Unternehmensbereich werden aus unterschiedlichsten Gründen häufig mehrschichtig entworfen, denn reine Client/Serverarchitekturen, die einen Großteil der Applikationslogik in den Client verlagern, bringen etliche Nachteile mit sich. Da wäre zum Beispiel das Thema Sicherheit – ein Unternehmen gibt ungern das eigene Know-how in Form der Anwendung heraus. Ein weiterer Aspekt ist die Anforderung, den Business-Tier gegebenenfalls von mehreren Präsentationsschichten, z.B. einem Web-Frontend und einem Mobile Device, nutzbar zu machen oder als Service zur Verfügung zu stellen. Enterprise Eclipse RCP (EERCP) bezeichnet eben solche mehrschichtigen Anwendungen, die als Frontend Eclipse RCP verwenden. Es gibt also eine strikte Trennung des Presentation-Tiers und des Business-Tiers.Im Gegensatz zu "traditionellen" Java EE-Applikationen mit einem Web-Frontend sind Java EE-Applikationen mit einer Rich-Client-Applikation als Frontend nicht so weit verbreitet, und es herrscht bezüglich ihrer Architektur noch kein genereller Konsens. Wir stellen hier daher die gebräuchlichsten Architekturvarianten vor und diskutieren ihre jeweiligen Vor- und Nachteile.
Variante 1: Client/Serverarchitektur
Bei dieser Architekturvariante befinden sich sowohl die Präsentationsschicht als auch die Geschäftslogik auf dem Client (Abb. 1). Der Zugriff auf die Datenbank erfolgt direkt aus dem Client heraus. Strukturell ähnelt dieser Aufbau dem einer einfachen Java EE-Webapplikation. Auch hier befinden sich ja GUI (z.B. JSPs) und Businesslogik gemeinsam im Webcontainer, der Browser besorgt nur noch das Rendering (im Fall von Ajax-Applikationen gilt dies im Großen und Ganzen weiterhin, da sich auch hier die Geschäftslogik im Server abspielt).
Die räumliche Nähe von GUI und Geschäftslogik ist ein wesentlicher Vorteil dieser Architekturvariante. So ist es zum Beispiel möglich, das Lazy-Loading-Feature von Hibernate zu verwenden, um so das Nachladen fehlender Daten zu realisieren.
Allerdings hat die Verlagerung des Datenbankzugriffscodes auf den Client einige Konsequenzen. Zunächst erhöht sich die Anzahl der gleichzeitigen Verbindungen, die die Datenbank verwalten muss, da nun jeder Client eine eigene Verbindung zur Datenbank aufbaut. Connection Pooling ist in diesem Falle nicht möglich. Darüber hinaus muss dafür Sorge getragen werden, dass die Datenbankverbindung zwischen Client und Datenbank sicher ist und nicht abgehört werden kann. Dies ist insbesondere dann wichtig, wenn sich die Clients außerhalb des Unternehmensnetzwerks befinden und über das Internet auf die Datenbank zugreifen sollen. Kaum ein Datenbankadministrator wird den ungeschützten Zugriff aus dem Internet auf seine Datenbank zulassen. Hinzu kommt, dass das JDBC-Protokoll auf der Firewall freigeschaltet werden müsste. Alternativ dazu unterstützen einige JDBC-Treiber das Tunneling des JDBC Protokolls über HTTP, was aber nur instabil funktioniert.
Eine Spielart dieser Variante enthält mehr oder weniger große Teile der Geschäftslogik in der Datenbank (in Form von Stored Procedures), was aber an den prinzipiellen Eigenschaften nichts ändert.
Variante 2: 3-Tier-Architektur
Bei dieser Architekturvariante befindet sich die Geschäftslogik in einem eigenen Tier (Abb. 2). Der Client enthält nur die Präsentationslogik und gegebenenfalls einige einfache Routinen zur Eingabevalidierung. Der Zugriff auf die Datenbank wird vollständig vom Middle-Tier aus durchgeführt, üblicherweise wird hier das DAO-Pattern eingesetzt. Die Geschäftslogik ist gekapselt und kann über definierte Services angesprochen werden. Die dazu verwendeten Zugriffsprotokolle können den Anforderungen entsprechend gewählt werden.Die Vorteile liegen auf der Hand: Der Zugriff auf die Datenbank ist gekapselt. Üblicherweise steht der Datenbankserver in einer separaten Netzwerkzone, auf die nur der Application-Server zugreifen kann. Dies bedeutet einen weitaus höheren Schutz für die Datenbank. Der Zugriff auf die Geschäftslogik erfolgt über Services. Je nach Anforderungen können entsprechende Endpoints bzw. Stubs geschaffen werden, z.B. für RMI, SOAP, REST oder HTTP. Auf diese Weise ist es auch möglich, die Businesslogik für unterschiedliche Clients (z.B. Eclipse RCP Frontend, Mobile Devices oder auch eine HTML-basierte Webapplikation) zugänglich zu machen.
Nachteilig an dieser Variante ist allerdings, dass die Nutzung des Lazy-Loading-Features des O/R-Mappers einigen Einschränkungen unterliegt. Da User Interface und Businesslogik in getrennten Adressräumen ausgeführt werden, kann der Clientcode das dynamische Nachladen von Datenbankinhalten nicht ausnutzen. Die Folge sind LazyInitializationExceptions. Diese lassen sich auf zwei Wegen umgehen: Entweder man lädt die gegebenenfalls erst später benötigten Daten bereits auf dem Server, indem man entweder das Lazy Loading ganz abschaltet oder die entsprechenden Assoziationen und Collections vorinitialisiert (im Fall von Hibernate mit Hibernate.initialize()). Die Alternative dazu ist die Verwendung des Data Transfer Object (DTO) Patterns: Man bildet pro Use Case (bzw. pro UI-Dialog) passende DTOs und füllt diese mit den Daten, die man mittels Hibernate aus der Datenbank geladen hat. Im Endeffekt initialisiert man auch hier die Entities. Da die DTOs jedoch nicht vom Persistence-Manager gemanaged werden, kann clientseitig niemals eine LazyIniatializationException auftreten.
Variante 3: N-Tier-Architektur
Die Verlagerung der Geschäftslogik vom Client auf den Server spielt ihre Stärken besonders dann aus, wenn neben der Datenbank auch auf andere Systeme zugegriffen werden muss oder andere Systeme auf das eigene System zugreifen sollen (Abb. 3, 4). Das eigene Backend agiert in diesem Fall als Fassade und kapselt den Zugriff auf die Fremdsysteme. Müssen mehrere Systeme miteinander interagieren, wirkt das eigene Backend als Mediator, harmonisiert die Datenmodelle und routet die Nachrichten.Bei besonders rechenintensiven Anwendungen können aufwändige Verarbeitungsschritte auf separate Systeme ausgelagert und somit die Anwendung skaliert werden.
Bei all diesen Vorteilen darf nicht vergessen werden, dass die Kommunikation in verteilten Systemen der üblichen Netzwerklatenz unterliegt. Um diese Effekte zu mildern, ist der feingranulare entfernte Zugriff auf Entities zu unterbinden. Grobgranulare Servicezugriffe und die Nutzung von DTOs sind das Mittel der Wahl.
