MODELLGETRIEBENE ARCHITEKTUR IN EINEM J2EE ... - OXSEED

Empfehlungen

Info

objekte modellgetriebene architektur Abb. 1: Die Architekturschichten des neuen Bausparsystems im Überblick (die Abk. WFMS steht für „Workflow- Management-System”) die Planungen einbezogen und verfolgt. Hierzu gehörte neben dem Aufbau der schichtenartigen Softwarearchitektur (siehe Abb. 1) das Herausarbeiten eines Designstils mit einem UML-Modell, das weitgehend von technischen Aspekten und Implementierungsdetails abstrahiert und die Grundlage einer translativen Codegenerierung bilden sollte. Als Werkzeuge für diesen Ansatz wurden „ArcStyler” (Interactive Objects Software GmbH) und „Rational Rose” (Rational Software Corporation) ausgewählt (vgl. [IOS02]). Die Interactive Objects Software GmbH hat nach unseren Vorgaben in wenigen Wochen eine Technologie-Projektion erstellt, die von uns ausgebaut wurde und selbständig weiterentwickelt wird. Sie enthält die Generierungsschablonen (Templates) der zu generierenden Artefakte, in die Aufrufe von Jython- Methoden 1 ) eingebettet sind, über die auf die Modellinformationen zugegriffen wird. Für die Erstellung dieser Schablonen bietet der ArcStyler eine integrierte Entwicklungsumgebung mit Debugging- Möglichkeiten an. Die Schablonen definieren geschützte Bereiche, in denen sich der Anwendungsentwickler ausschließlich bewegen und Fachlogik einfügen darf, da nur diese Bereiche in nachfolgenden Generierungsläufen erhalten bleiben. Hierzu muss dem Generator immer der aktuelle Quellenstand zur Verfügung gestellt werden. Die Generierung kann für einzelne Modellklassen, für Pakete von Modell-Klassen oder für das ganze Modell aus dem CASE-Werkzeug heraus aufgerufen werden. Um die zur Generierung notwendigen Parameter einstellen zu können, wurden in Rational Rose neben den 1 )Jython ist eine Java-Implementierung der Skriptsprache Python (siehe: http://www.jython.org). speziellen Eigenschaftsleisten des ArcStylers auch eigene eingefügt, deren Properties die Generierungsvorlagen verwenden. Daneben wird die Generierung auch durch den Einsatz von Stereotypen gesteuert. Während die Kernteile des Designmodells (Klassen, Methoden, Assoziationen etc.) relativ technologieunabhängig sind, werden die technologiespezifischen Einstellungen innerhalb der leicht austauschbaren Eigenschaftsleisten gepflegt, und die Generierungsschablonen enthalten die Projektion auf die technische Umgebung. Damit kann unser Stil als konform zum Standard der „Model Driven Architecture” der OMG angesehen werden (vgl. [Koc02]). Der Ansatz der modellbasierten Generierung konzentriert sich auf diejenigen Komponenten und Anwendungsteile, bei denen fachliche Breite zu erwarten ist und deren Menge mit der Zahl der Anwendungsfälle stetig anwächst. Unsere Darstellung trägt dem Rechnung und setzt deshalb bewusst den Schwerpunkt auf den stilbildenden modellgetriebenen Ansatz. Methodenaufruf: 615 010 AFH002 Methodenantwort: Testfiliale B 615 Test-Name 10 Eschborn 6236 Stuttgarterstr. 1 Listing 1: Beispiel des zur Server-Großrechner- Kommunikation eingesetzten, auf XML basierenden Protokolls. Es wird die Methode „getStandort” des COBOL-Moduls „BL-User” aufgerufen.
objekte XML-Schnittstelle Die Architektur des neuen Bausparsystems ist geprägt von der Schnittstelle zwischen Server und Großrechner. Zur Kommunikation wird „MQSeries” von IBM als Message Queue eingesetzt, über das Remote Procedure Calls in XML-Form verschickt werden. Dabei wird sowohl ein asynchrones Kommunikationsmodell für schreibende Zugriffe als auch ein synchrones für lesende Zugriffe eingesetzt. Das auf XML basierende Protokoll (vgl. Listing 1) ist eine Eigenentwicklung, die vor der Etablierung des Simple Object Access Protocol (SOAP) in der Version 1.1 bereits abgeschlossen war und auf die speziellen Anforderungen der Schnittstelle abgestimmt ist. Es ermöglicht den Aufruf mehrerer Methoden innerhalb einer Nachricht, womit das Setzen der CICS- Transaktionsklammern von der Serverseite aus ermöglicht wird. Wichtiger Bestandteil des Protokolls ist ein eigenes Typensystem mit Transformationsregeln zur Überführung in Java-Klassen und COBOL-Datentypen. Die Datenstrukturen, die als Parameter und Rückgabewerte über die Schnittstelle transportierbar sind, werden als UML-Klassen modelliert (siehe Abb. 2). Diese Schnittstellenklassen werden dem Generator mit dem Stereotyp «dtd» kenntlich gemacht. Sie werden unter der Programmiersprache Java auf Value Objects (vgl. [Sun02]) und unter COBOL auf Copy-Strecken abgebildet. Zur Steuerung der Transformation zwischen diesen Instanzformen und XML werden in Java je eine XML-Transfer- Klasse zuzüglich SAX-Handler (Simple API for XML) und Test-Klasse und in COBOL jeweils ein Modul generiert, welches das Navigieren über den Element- Baum ermöglicht. Zur Erzeugung dieser XML-Module wurde das Produkt „XML4cobol” der Maas High Tech Software GmbH (vgl. [Maa02]) vollständig in den Generierungsprozess des ArcStylers integriert. Alle aufgezählten modellgetriebene architektur Abb. 2: Beispielhaftes Klassendiagramm mit assoziierten Schnittstellenklassen. Die Umsetzung in XML ist in der Methodenantwort von Listing 1 enthalten. Artefakte sind komplett generierbar und bedürfen keiner Nachbearbeitung (siehe Tabelle 1). Frontend-Layer Als Thin Client fungiert stets ein Browser auf dem Rechner des Benutzers, der über HTTP-Anfragen die Frontend-Schicht der Anwendung anspricht. Diese liegt in mehreren Ausprägungen als Web-Applikation vor, die das bewährte Entwurfsmuster Model View Controller für Web-Architekturen (vgl. [Sun02]) implementieren. Dabei setzen wir das freie Framework Struts (vgl. [Apa02]) ein, das neben diversen Tag-Bibliotheken und Hilfsklassen die Möglichkeit bietet, Model und View lose zu koppeln, indem der Kontrollfluss des Controller-Servlets über eine XML-Datei konfiguriert werden kann. Die View- Elemente werden durch Java Server Pages (JSPs) umgesetzt. Das Model wird von sogenannten Action-Klassen umhüllt, die nach dem Command-Entwurfsmuster vom Controller-Servlet aufgerufen werden. Einer Action-Klasse können Form- Klassen zugeordnet sein, die mit HTML- Formularen korrespondieren und innerhalb der auszuführenden Aktion ausgewertet oder gefüllt werden können. Die Action-Klassen leiten die Anfragen über RMI (Remote Methode Invocation) an die EJB-Schicht (Business-Layer) weiter. Action- und Form-Klassen werden modelliert und generiert, wobei die Rahmen der modellierten Methoden gegebenenfalls noch ausprogrammiert werden. Wenn Daten über mehrere Kontrollflüsse hinweg vorzuhalten sind, werden sie im Kontext der Sitzung („HttpSession”) gespeichert. Eingaben in Formulare werden noch innerhalb der Frontend-Schicht geprüft. Business-Layer: Server Die Aufgaben der serverseitigen Business- Schicht sind das Ansprechen der Datenzugriffsschicht, der Aufruf von Großrechner-Diensten, die Steuerung langer Transaktionen über ein Workflow-Mana- gement-System (WFMS) und Prüfungen, zu denen der serverseitige Datenbestand heranzuziehen ist. Diese Funktionalität wird gemäß dem Session-Facade-Entwurfsmuster (vgl. [Sun02]) durch zustandslose Session-Beans gekapselt. Die Session-Beans werden über je eine Klasse im Modell gepflegt, in der nur die Geschäftsmethoden zu modellieren sind. Daraus wird die Bean-Klasse mit ihren Interfaces generiert, einschließlich Deployment-Deskriptoren, die über eigene Eigenschaftsleisten konfiguriert werden, und Test-Klassen. Die Entwicklungsarbeit konzentriert sich auf das Ausprogrammieren der Geschäfts- und ihrer Testmethoden. Da die Bestandsdaten weiterhin auf dem Großrechner-System gehalten werden, sind die Datenbestände unter Oracle auf der Serverseite überschaubar. Es handelt sich um Wiedervorlagedaten der Beratungsanwendung mit Informationen zu durchgeführten Beratungen oder auch um Benutzerdaten. Die Zugriffsschicht auf diese Daten teilt sich in eine logische und eine physische Schicht auf, die weiter unten beschrieben werden. Diesen wird eine JDBC-Verbindung (Java Database Connectivity) aus der Session- Bean heraus übergeben, über die der EJB- Container die Transaktionen steuert. Zugriffe auf das Großrechner-System werden an Stub-Klassen delegiert, die die Serialisierung der Anfragen in XML, deren Weiterleiten an die Message Queue über eine Kommunikationsschicht und – bei synchronen Zugriffen – die Deserialisierung der Antwort steuern. Diese Stub- Klassen werden für jede Business-Schicht- Komponente der Host-Seite (siehe nächsten Abschnitt) vollständig aus dem Designmodell generiert. Einige aufwändige Arbeitsabläufe im Bausparsystem erfordern lange Transaktionen, die über ein Workflow-System gesteuert werden. Kundenbetreuer müssen definierte Aktivitäten sukzessive abschließen, bevor ein komplexer Prozess nach mehreren Minuten beendet werden kann. Die im Kontext einer Aktivität bearbeiteten Formulardaten werden innerhalb des Workflow-Systems persistent gespeichert und erst mit dem Abschluss der Aktivität in Änderungsfunktionen umgesetzt, die als XML-Nachricht an das Großrechnersystem gesendet und innerhalb einer Transaktion abgearbeitet werden. Die Antwort erfolgt asynchron und triggert bei Erfolg den Abschluss der Aktivität. Dabei wird ein optimistisches Sperrkonzept verfolgt. Die Value Objects tragen den Zeitstempel ihres Lesens mit sich,
Seite 1: objekte modellgetriebene architektu
Seite 5 und 6: objekte modellgetriebene architektu

MODELLGETRIEBENE ARCHITEKTUR IN EINEM J2EE ... - OXSEED

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?