Java Enterprise Architekturen Willkommen in der Realität

Transkript

1 Java Enterprise Architekturen Willkommen in der Realität Ralf Degner Dr. Frank Griffel Techniker Krankenkasse Häufig werden Mehrschichtarchitekturen an physikalischen Grenzen (zwischen Rechnersystemen) ausgerichtet. Daher werden die Schichten an ihren Grenzen mit Mitteln der Remote- Kommunikation ausgestattet. Solche Kommunikationen sorgen für einen hohen Overhead und schränken damit die Granularität der Interaktionen zwischen den Schichten ein. Entscheidender sind die logischen Schichten. So sollten Kunden der Geschäftslogik dieser sehr nahe sein (in der selben VM leben) um sie uneingeschränkt nutzen zu können. In TKeasy (Systemarchitektur der Techniker Krankenkasse) verlaufen die Grenzen der logischen Schichten alle im Application-Server. Jede Art eines Klienten hat immer einen Teil, der in der VM des Application-Servers läuft (z.b. bei HTML die JSP-Engine). Remote-Kommunikationen werden innerhalb einer logischen Schicht realisiert und orientieren sich an konkreten Bedürfnissen. Für die Geschäftsobjekte wird eine Laufzeitumgebung benötigt, die Dinge wie Transaktionshandling, Security und Zustandüberwachung übernimmt. Um objektorientierte Techniken uneingeschränkt nutzen zu können, ist die zentrale Anforderung an eine solche Umgebung "Transparenz". Als Nutzer von Geschäftsobjekten (ob als Client oder als andere Geschäftskomponente) müssen diese wie normale Java-Objekte erscheinen und keine "besonderen" Dinge notwendig sein, um sie zu nutzen. Nur so kann ein Nutzer ein Objekt als "Black-Box" betrachten. Auch kleine Einschränkungen, wie z.b. das Exception-Handling von CORBA, haben starke negative Auswirkungen. Die Laufzeitumgebung von TKeasy ist an die Architektur der Java Data Objects (JDO) angelehnt, in der seit vielen Jahren der POJO-Ansatz verfolgt wird. Als grundlegende Elemente zur transparenten Nutzung von Geschäftsobjekten haben sich zudem langlaufende geschachtelte Transaktionen auf diesen herausgestellt. Entscheidend für den Erfolg einer objektorientierten Enterprise-Architektur ist die Performance des Persistenzdienstes. Dies scheint oft der Forderung nach Transparenz von Geschäftsobjekten für Entwickler und Nutzer zu widersprechen. Um beide Ziele zu erreichen, wird in TKeasy eine besondere Kommunikation mit der Datenbank eingesetzt. Der Persistenzdienst schickt dem Großrechner als Datenbanksystem nicht einzelne Datenbankzugriffe, sondern ein Skript mit einer Vielzahl von Anforderungen und Regeln, welche abhängigen Daten im selben Aufruf zusätzlich gelesen werden sollen. Für die Realisierung von fachlichen Basissystemen (z.b. Vorgangssystem) sind zudem allgemeine (generische) Referenzen notwendig, die auf jedes Geschäftsobjekt verweisen können (unabhängig von den zugehörigen Datenbanken). SWING ist für die Anwendungsentwicklung im großem Stil durchaus ein tragfähiges GUI-Framework. Allerdings ist die direkte Nutzung von SWING sehr ineffizient. Hier sollten abstraktere Frameworks eingeführt werden, auf denen die Anwendungsentwicklung aufbaut. Dies gilt insbesondere auch für Layout-Manager. Ein "Big-Bang" für die Einführung einer OO-Enterprise-Architektur erscheint aufgrund des Reifegrades der Technologien und Produkte auch heute noch sehr riskant. Um eine kontinuierliche Migration für den Anwender möglichst komfortabel zu gestalten, wurde in TKeasy ein abstrakter Begriff einer Anwendung eingeführt, der für verschiedenste Programme konkretisiert wurde. So ergibt sich beim Aufruf einer Anwendung für den Nutzer kein Unterschied zwischen alten und neuen Anwendungen oder Fremdsoftware. Neben der Hauptarchitektur des Unternehmens gibt es in der Regel viele weitere Systeme, die an diese angebunden werden müssen. Hierzu hat sich ein serviceorientierter Ansatz bewährt. Aufgrund der Überschreitung von Systemgrenzen sind feingranulare Kommunikationen oder transaktionale Kopplungen nicht sinnvoll. Als Austauschformat kommt XML/SOAP mit WSDL-Schnittstellen zum Einsatz.

2

3

4

5

6

7

8

9

10

11

12