Ein XML-basierter Designansatz für J2EE-Applikationen im EAI-Umfeld

XML-basiertes EJB-Design

Dr. Claus Ziegler

J2EE-Applikationen aus dem EAI-Umfeld (Enterprise Application Integration) verwenden zunehmend EJB-Container, die sowohl mit ihren Clients als auch mit ihren integrierten Altsystemen ausschließlich über XML-basierte Schnittstellen kommunizieren. Dieser Artikel stellt einen Designansatz für EJBs vor, der in diesem Systemumfeld eine ernstzunehmende Alternative zu den gängigen klassisch-objektorientierten Ansätzen darstellt.

Systemumfeld und Schnittstellendesign

Bei der Anbindung von Altsystemen an einen J2EE-Server haben XML-basierte Schnittstellen mittlerweile eine herausragende Bedeutung erlangt. Als Transportmedium wird häufig eine Message-orientierte Middleware gewählt, die über Java Message Services (JMS) angesprochen werden kann. Mit dieser eigentlich asynchronen Technik lassen sich auch synchrone Schnittstellen realisieren, indem der Absender einer Auftragsnachricht auf das Eintreffen einer zugehörigen Antwortnachricht wartet. Gerade IBM setzt mit der MQ Series Produktfamilie stark auf diese Karte, insbesondere im Bereich der Integration von OS/390 und AS/400-Hostsystemen.

Auch Client-Anwendungen kommunizieren mehr und mehr über XML mit J2EE-Servern. Protokolle wie das auf XML basierende SOAP haben sich im Web Service-Umfeld längst durchgesetzt. Techniken wie das Apache SOAP API versuchen dabei objektorientierte Schnittstellen nachzupictureen. Mittlerweile werden jedoch auch XML-basierte Ansätze diskutiert, die anstatt serialisierbarer Datenhaltungsobjekte (value objects) direkt XML-Datenströme über Schnittstellen-Methoden von Enterprise Beans austauschen. Die wesentlichen Vorteile dieses Ansatzes wurden erst kürzlich in einem Artikel von Jason Cai in der JavaWorld [1] herausgearbeitet:

  • Client und Applikationsserver sind vollständig entkoppelt. Das Hinzufügen oder Entfernen einzelner fachlicher Attribute ändert die Schnittstelle aus technischer Sicht nicht. Hierdurch wird eine unabhängige parallele Entwicklung von Client und Applikationsserver ermöglicht.
  • XML-Datenströme sind selbstdokumentierend. Die textuelle Natur von XML-Tags und ihre Verwendung in einem hierarchischen Datenschema reduzieren die Gefahr von Fehlinterpretationen während des Entwicklungsprozesses.
  • Dem Client können als Ergebnis eines einzelnen Aufrufs gleichzeitig Daten und multiple Plausibilitätsverletzungen übermittelt werden.
  • Über XML-basierte Schnittstellen können leicht zusätzliche technische Informationen wie Zeitstempel oder Journalisierungs- und Protokolldaten transportiert werden.
  • SOAP als Kommunikationsprotokoll zwischen Client und Applikationsserver kann unterstützt werden, ohne anwendungsspezifische SOAP-Serializer schreiben zu müssen.

Ein Nachteil einer XML-basierten Schnittstelle gegenüber einer objektorientierten Schnittstelle sind fehlende Compiler-Prüfungen auf Vollständigkeit und Datentyp der erwarteten Eingabeparameter.

Gerade Applikationen aus dem EAI-Umfeld beinhalten immer häufiger EJB-Container, die sowohl mit ihren Clients als auch mit den integrierten Backend- und Legacy-Systemen ausschließlich über XML-basierte Schnittstellen kommunizieren. Im Falle eines Browser-basierten Web-Clients betrachten wir dabei Browser und Web Container (JSPs + Servlets) als logischen Client des EJB-Containers (Abb. 1). Die mit XML beschrifteten Pfeile in der Abpictureung sind dabei als Aufrufe zu verstehen, die sowohl als Eingangsparameter wie auch als Rückgabewerte XML-Dokumente transportieren.

Abb. 1: Beispielhafte Systemarchitektur einer EAI-Applikation

Die fachliche Logik einer solchen EAI-Applikation läuft überwiegend in den angeschlossenen Altsystemen ab. Daher besteht oftmals die Aufgabe des Applikationsservers nur darin, fachlich zusammengehörige Daten aus unterschiedlichen Systemen anzufordern und seinen Clients zur Ansicht bzw. für einfache Änderungen zur Verfügung zu stellen. Zu diesen einfachen Änderungen zählt beispielsweise das Anlegen, Ändern und Löschen von Datensätzen mitsamt der zugehörigen Plausibilitätsprüfungen. Komplexere Logik wird an die Altsysteme delegiert.

Design der Enterprise Beans

An objektorientierten Prinzipien ausgerichtete Designansätze wandeln üblicherweise die von den Altsystemen angeforderten XML-Daten in eine objektorientierte Datenrepräsentation um. Gemäß dem EJB-Paradigma wird jedoch im Gegensatz zur klassischen objektorientierten Lehre die Fach- und Anwendungslogik mit Ausnahme einfacher Zugriffsmethoden nicht in den Datenhaltungsobjekten (z.B. Entity Beans) realisiert, sondern in Session Beans (und zugehörigen Hilfsklassen). Die Session Beans übernehmen dabei jeweils die Verantwortung für einen klar abgegrenzten Teil der Daten und pictureen eine Fassade für alle zugehörigen Datenzugriffe. Auf diese Weise wird eine Gliederung des Systems in größere austauschbare und potentiell wiederverwendbare Komponenten erreicht. Das zugehörige Entwurfsmuster ist unter dem Namen Session Facade Pattern bekannt.

Das Wandeln der über die Schnittstellen ausgetauschten XML-Daten in Objektnetze und umgekehrt ist allerdings ein relativ aufwändiges Unterfangen, das ohne den Einsatz speziell hierfür konzipierter Werkzeuge wie JAXB (Java Architecture for XML Binding) kaum bewältigt werden kann. Falls im Applikationsserver keine wirklich komplexe Geschäftslogik implementiert werden muss, stellt sich die Frage, ob dieser klassisch-objektorientierte Ansatz und der damit verbundene Aufwand überhaupt gerechtfertigt sind. Fach- und Anwendungslogik, die ohnehin in Session Beans außerhalb der Datenhaltungsobjekte realisiert wird, können ebenso gut auf einer anders gearteten Datenrepräsentation operieren, ohne dass hierdurch die Prinzipien des Komponentendesigns wie das oben erwähnte Session Facade Pattern, tangiert würden.

Natürlich sind nur solche Datenrepräsentationen geeignet, die eine sinnvolle fachliche Strukturierung der Daten und ein bequemes Navigieren durch diese fachlichen Strukturen erlauben. Aus diesem Grund wäre etwa eine Repräsentation der Anwendungsdaten im Applikationsserver als Document Object Model (DOM) sicher keine gute Idee. In einem Punkt ist DOM jedoch einem fachlichen Objektnetz überlegen: Die Umwandlung der Anwendungsdaten in XML-Dokumente und umgekehrt ist ein einzeiliger Methodenaufruf und somit extrem einfach, da diese Umwandlung von einem generischen Algorithmus ausgeführt wird. Unter generisch verstehen wir in diesem Zusammenhang die Unabhängigkeit von fachlichen Spezifika der Anwendung.

Dieser Artikel stellt einen Lösungsansatz vor, der eine Datenrepräsentation im Hauptspeicher verwendet, die wie DOM durch einen generischen Algorithmus in XML-Dokumente umgewandelt werden kann und umgekehrt. Voraussetzung hierfür ist lediglich, dass die XML-Dokumente einigen einfachen Konventionen genügen. Im Gegensatz zu DOM sind jedoch die oben genannten Kriterien fachliche Strukturierbarkeit und einfache Navigation für diese Datenrepräsentation völlig zufriedenstellend erfüllt, so dass bei der Realisierung von Fach- und Anwendungslogik eine objektorientierte Datenrepräsentation nicht wirklich vermisst wird.

Abb. 2: Repräsentation von Objekten als HashMap

In einem objektorientierten Datenmodell wäre obiges Beispiel durch eine 1-1 Beziehung zweier Objekte vom Typ Person und Adresse modelliert.

Listen von gleichartigen Elementen werden in den XML-Dokumenten in ein übergeordnetes Tag geklammert, das mit dem Suffix _LISTE endet. Derartige Listen sind jedoch nur als untergeordnete Elemente anderer Elemente erlaubt, d.h. dürfen nicht direkt im Wurzelelement des XML-Dokuments liegen. Beispiel:

Abb. 3: Repräsentation von Listen

In einem objektorientierten Datenmodell hätten wir hier eine 1-n Beziehung zwischen Objekten vom Typ Person und Termin.

Die Implementierung des generischen Umsetzungsalgorithmus ist sehr einfach, wenn als Zwischenformat eine DOM-Repräsentation der XML-Dokumente verwendet wird. In diesem Falle können nachdem ein XML-Dokument geparst und als DOM-Struktur aufgebaut wurde, die DOM-Knoten rekursiv durchsucht werden. Für jeden Element-Knoten, dessen Tag-Name mit _LISTE endet, wird eine ArrayList angelegt, für alle anderen Element-Knoten eine HashMap. Text-Knoten werden direkt in die HashMap ihrer Eltern-Knoten als Schlüssel-Wert-Paar eingefügt. In der umgekehrten Richtung erfolgt eine rekursive Iteration über die Basis-HashMap der zu konvertierenden Hauptspeicher-Repräsentation. In dieser Rekursion wird durch Aufrufe von Document.createElement() und Document.createTextNode() ein der HashMap entsprechendes DOM-Dokument aufbaut. Dieses DOM-Dokument wird anschließend mit Hilfe der Klasse org.apache.xml.serialize.XMLSerializer serialisiert.

Die fachliche Datenmodellierung der Anwendung kann auf Basis eines klassischen objektorientierten Analysemodells erfolgen. In diesem Falle wird das Analysemodell durch analoge Überlegungen wie bei der Ableitung eines ER-Modells in ein XML-basiertes Datenmodell überführt, das gemäß obigem Schema strukturiert ist. Wichtig hierbei ist, dass die Gruppierung der Attribute nach rein fachlichen Gesichtspunkten vorgenommen wird, unabhängig von der Herkunft der Attribute aus unterschiedlichen Altsystemen. Das so entstehende XML-Datenmodell ist ein wichtiger Bestandteil des Designmodells, denn das Design-Klassenmodell enthält als Datenhaltungsklassen ja nur die Klassen HashMap und ArrayList (Abb. 4). Das hier abgepictureete Klassendiagramm dokumentiert nicht die wirkliche Implementierung der Klassen HashMap und ArrayList in den Standard Java Bibliotheken, sondern modelliert die Art der Verwendung dieser Klassen zum Aufbau der Datenrepräsentation im Applikationsserver.

Abb. 4: Klassenmodell für die Datenhaltung

Falls bereits bestehende XML-Schnittstellen von Altsystemen angesprochen werden sollen, die nicht dem modellierten XML-Schema entsprechen, so sollte ein zusätzlich zwischengeschalteter Algorithmus eine entsprechende Konvertierung durchführen. Hierfür existiert mit XSLT ein Standardmechanismus, der in den meisten Fällen ausreichend sein sollte. Die übrigen Teile der Anwendung bleiben von dieser Konvertierung unberührt.

Ganz analog kann auch eine Transformation der Daten in ein anderes XML-Schema für die Versorgung der Client-Schnittstelle sinnvoll sein. Ein Anwendungsbeispiel hierfür ist die Anreicherung der XML-Datenströme um präsentationsspezifische Informationen wie Editierbarkeit und Art der Anzeige von Attributen. Bei einem Browser-Client wäre dies zwar eher die Aufgabe eines XML/XSL basierten Web Publishing Frameworks, doch konsequent weitergedacht können die selben Ideen auch für die Realisierung von Java Clients mit generischer Präsentationslogik angewendet werden. Abpictureung 5 zeigt, wie sich etwaige zusätzliche Schematransformationen in unsere bisherigen Designüberlegungen einordnen.

Abb. 5: Versorgung der XML-Schnittstellen

Die Realisierung von spezifischer Fach- und Anwendungslogik in Session Beans kann im Falle einfacher bis mäßig komplexer Operationen sehr elegant auf der oben beschriebenen Datenrepräsentation ausgeführt werden. Das Schreiben von einfachen Zugriffsmethoden in den Datenhaltungsklassen entfällt, da die Klassen HashMap und ArrayList entsprechende Methoden bereits zur Verfügung stellen.

Der Zugriff auf einzelne Attribute und das Navigieren durch ein Objektnetz geschieht völlig analog zu einer objektorientierten Datenrepräsentation – jeder Objektinstanz entspricht genau eine HashMap-Instanz, Datenzugriff und Navigation über Instanzverbindungen unterscheiden sich lediglich in der Syntax: Anstelle von Aufrufen von set- und get-Methoden( ) der Datenhaltungsobjekte stehen Aufrufe von get( ) und put( )-Methoden der HashMaps mit Schlüsselnamen als Parameter.

Deutlich einfacher zu implementieren ist jegliche generische Logik, wie etwa die Konvertierung der Daten in ein XML-Dokument. Gerade die Arbeitsersparnis durch letzteres Beispiel ist in dem beschriebenen Systemumfeld beträchtlich, da sämtliche Schnittstellen des Applikationsservers auf diese Weise versorgt werden müssen. Im Falle einer objektorientierten Datenrepräsentation würde die Realisierung derartiger generischer Funktionen die extensive Nutzung des Reflection-Mechanismus von Java erfordern. Dieser Mechanismus ist jedoch wesentlich komplexer, relativ fehleranfällig und wenig performant. Besser geeignet ist dann schon ein zwar nicht generischer, aber auf Source-Code-Generierung basierender Ansatz wie das eingangs erwähnte JAXB.

Einfache Änderungen des Datenmodells, wie etwa das Hinzufügen eines Attributs, erfordern nicht notwendigerweise eine Änderung der Enterprise Beans und somit auch nicht notwendigerweise das Deployment eines neuen Versionsstandes. Falls keine fachliche Semantik mit dem neuen Attribut verbunden ist, wird dieses vom Applikationsserver transparent an den Client durchgereicht. Besitzt dieser Client wie oben angedeutet eine generische Präsentationslogik, so kann auch die Verteilung eines neuen Client-Standes vermieden werden. Durch diese Entkopplung von den Altsystemen wird der Wartungsaufwand für die Gesamtlösung drastisch verringert.

Ein häufig zitiertes Standardargument für eine objektorientierte Datenrepräsentation ist die strenge Typsicherheit. Für diese Typsicherheit kann jedoch durch Verwendung eines Data Dictionary-Konzeptes leicht ein vollwertiger Ersatz geschaffen werden. In diesem Data Dictionary werden XML-Templates für das verwendete XML-Datenmodell hinterlegt. Durch einfache generische Algorithmen können nun die im XML-Format oder in der HashMap-Repräsentation vorliegenden Daten gegen die im Data Dictionary hinterlegten Informationen geprüft werden, z.B. auf korrekte Datentypen, Vollständigkeit der Attribute, usw. Der naheliegende Kritikpunkt, dass hierdurch Typprüfungen des Compilers in die Laufzeitumgebung verlagert werden, ist nur sehr bedingt stichhaltig, denn auch bei einer objektorientierten Datenrepräsentation führen falsche Datentypen in den über die Schnittstellen eingehenden XML-Dokumenten zwangsläufig zu Laufzeitfehlern.

Das vermutlich wichtigste Argument gegen die vorgestellte Lösung ist das Fehlen von geeigneten Werkzeugen und erprobten Vorgehensmodellen. Doch dieses Argument trifft auf viele neue Ansätze zu und es bleibt zu hoffen, dass auf Dauer nicht die verfügbaren Werkzeuge und Methoden die angewandten Lösungsstrategien bestimmen, sondern umgekehrt.

Geschrieben von
Dr. Claus Ziegler
Kommentare

Schreibe einen Kommentar

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