MODELLGETRIEBENE ARCHITEKTUR IN EINEM J2EE ... - OXSEED

Empfehlungen

Info

objekte modellgetriebene architektur Abb. 3: Die Modell-Klasse „BL-User”, die auf ein COBOL-Modul abgebildet wird und eine Änderung der Bestandsdaten wird nur zugelassen, wenn dieser Zeitstempel jünger ist als derjenige der letzten Datensatzänderung. Beim Workflow- Management-System greifen wir auf eine Eigenentwicklung zurück, die sich in unserem automatisierten Dokumenten-Management-System bewährt hat. Business-Layer: Host Die Programme dieser Business-Schicht bieten der Serverseite ihre Dienste mit XMLfähigen Methodenaufrufen an und steuern die für deren Abarbeitung erforderlichen Abläufe einschließlich dem Aufbau der XML-Rückantworten. Dabei werden vorrangig Methoden der logischen Schicht aufgerufen, aber auch Methoden der Business- Schicht können herangezogen werden und – falls erforderlich – werden Methoden innerhalb des gleichen Moduls benutzt. Methoden der Module der Business- Schicht und auch der logischen Schicht werden grundsätzlich über einen eigens entwickelten Name-Service angesprochen, der die Namen der Methoden in Aufrufe von COBOL-Programmen umsetzen kann. Der Name-Service wird beim CICS- Start oder auf Anforderung durch einen Rundruf an alle COBOL-Module, welche die von ihnen angebotenen Methoden mitteilen, initialisiert. Die Methoden selbst sind innerhalb der Module als eigenständige Unterprogramme (sogenannte Nested Programs) implementiert. Dieses Verfahren ermöglicht den geschachtelten Aufruf von Methoden innerhalb eines Moduls. Außerdem löst es das Problem des reflektiven Aufrufs, wenn die Methoden über die XML-Schnittstelle anhand ihres Namens aufrufbar sein müssen. Die Nutzdaten werden bei diesen Methodenaufrufen über Zeiger auf XML- Bäume weitergeleitet, die mit XML- Modulen verwaltet werden können. Die XML-Module dienen hierbei als dynamische Datencontainer und können mit Copy-Strecken oder Character-Feldern mit XML-Inhalt gefüllt werden. Für die COBOL-Module wurde ein Mechanismus zur Ausnahmebehandlung implementiert. Bei einem Fehlerfall sorgt die klammernde Methode der Business-Schicht dafür, dass die Ausnahme mit ihrem Aufruf-Stack in die XML-Rückantwort gestellt wird. Da die Module prozedural arbeiten, werden sie als Klassen ohne Attribute modelliert (siehe Abb. 3). Ihre Methoden werden auf Nested Programs abgebildet und ein Überschreiben ist nicht erlaubt. Als Übergabeparameter und Rückgabewerte sind primitive Datenklassen und Schnittstellenklassen möglich. Die Modellklassen werden über den Stereotyp «host» als COBOL-Module kenntlich gemacht. Zur Pflege der auf acht Stellen begrenzten Modulnamen setzen wir eine vierstellige Kennung auf der Ebene eines Modell- Pakets ein und fügen dieser eine vierstellige Nummer hinzu, die wir auf übersichtliche Weise für alle Module einer Schicht im Modell pflegen. Für jede Methode wird eine Copy-Strecke generiert, über die mit dem Name-Service kommuniziert wird. In Architektureinheit Anteil generierter Codezeilen XML-Schnittstelle 100 % Frontend-Layer 40 % Business-Layer Server 60 % Business-Layer Host 70 % Logical-Layer Server 70 % Logical-Layer Host 60 % Physical-Layer Server 90 % Physical-Layer Host 90 % Tabelle 1: Die relativen Anteile generierter Zeilen einschließlich Kommentaren für die anwendungsfallabhängigen Codeteile der einzelnen Architekturschichten und der Artefakte der Schnittstellenklassen. Für die Frontend-Schicht wurden nur die Java- Klassen, nicht aber die JSP-Seiten berücksichtigt. ihren achtstelligen Namen geht eine eindeutige Kennung des Modulnamens und ihr dreistelliger Stereotyp ein. Auf Methodenebene werden die aufgerufenen Fremdmethoden im Modell gepflegt, die der Generator über Abhängigkeitsbeziehungen auflösen kann. Auf diese Weise gelingt es, umfangreiche Teile der Module zu generieren, denn der zum Bestücken von Methoden-Schnittstellen unter COBOL sehr hohe Aufwand ist vollständig aus dem Modell ableitbar (siehe Tabelle 1). Die Fachlogik wird innerhalb der Nested Programs ausprogrammiert. Logical-Layer Die logische Datenzugriffsschicht ist als Adapter der physischen Zugriffsschicht implementiert und erlaubt es, mit Value Objects unter Java oder mit XML-Copy- Strecken unter COBOL auf die Datenbank zuzugreifen. Da auf Serverseite das Datenmodell das Klassenmodell der Value Objects nahezu abbildet, beschränkt sich deren Aufgabe im Wesentlichen auf das Aufsammeln assoziierter Instanzen. Hostseitig bildet die logische Schicht das gewachsene Datenmodell des Kernsystems auf die neuen Datenstrukturen ab und entkoppelt die darüber liegende Business- Schicht von zukünftigen Überarbeitungen des Datenbankschemas. Serverseitig wird die logische Schicht durch Java-Klassen, host-seitig durch COBOL-Module realisiert, die jeweils aus Modell-Klassen, in denen die Schnittstellen definiert werden, generierbar sind. Lediglich die Logik der Methoden ist zu programmieren. Die obigen Ausführungen zur Generierung von COBOL-Modulen der Business-Schicht treffen in gleicher Weise auf diejenigen der logischen Schicht zu. Der Generator verwendet sogar dieselbe Generierungsschablonen. Physical-Layer: Server Die physische Datenzugriffsschicht realisiert die Zugriffe auf die Datenbank, wobei auf der Serverseite über JDBC auf Oracle zugegriffen wird. Das Datenmodell ist serverseitig nahezu isomorph zum Modell der Value Objects. Die Standardzugriffe auf die Datenbanktabellen werden mit Data Access Objects (vgl. [Sun02]) zur Verfügung gestellt, die mit Value Objects korrespondieren. Sie werden daher nicht eigens modelliert, sondern sind durch zusätzliche Modellparameter aus den Schnittstellenklassen ableitbar. So wird im Modell definiert, ob eine Schnittstellen
objekte modellgetriebene architektur Abb. 4: Modellierung des COBOL-Moduls „UDPLA120” der physischen Schicht über die Klasse „PL-Bausparer”. Die firmenspezifischen Eigenschaftsleisten unserer Technologie-Projektion sind rot markiert. klasse überhaupt persistent ist, welche Attribute Primärschlüsselbestandteile sind, ob assoziierte Klassen in einer Tabelle zusammengezogen werden und ob die Datenbanktypen von einer vordefinierten Typenabbildung abweichen sollen. Die Data Access Objects und die zugehörigen DDL-Skripte (Data Definition Language) werden vollständig aus dem Modell generiert. Komplexere Anfragen werden in eigenen Klassen gekapselt, die von Hand programmiert werden. Physical Layer: Host Die physische Schicht der Host-Seite steuert die Zugriffe auf die operativen Bestandsdaten des Kernsystems unter DB2. Sie besteht aus COBOL-Modulen, die jeweils einer Tabelle zugeordnet sind. Diese Module stellen die Zugriffsmethoden auf die Tabellen bereit, deren sich die logische Schicht bedienen kann; der Datenaustausch erfolgt dabei über Copy- Strecken. Modellierung und programmatische Umsetzung unterscheiden sich von den bisher besprochenen Modularten. Zusätzlich zu den Modul-Klassen wird je eine Excel-Datei angelegt, in der feldbezogene Transformationsregeln und Zusatzinformationen gepflegt werden, die in die Generierung der Datenzugriffe eingehen. Aus Gründen der Übersichtlichkeit ziehen wir diese Technik der Pflege der Feldinformationen über Klassenattribute vor. Der Generator erkennt einen Satz von Standard-Zugriffsmethoden anhand ihres Namens („read”, „readNext”, „insert”, „update” und „delete”; siehe Abb. 4) und generiert sie mit den Informationen der zugeordneten Excel-Datei vollständig. Für andere Methoden werden die Rahmen erzeugt, in die spezielle Datenzugriffe individuell einzufügen sind. Je Modul wird eine Copy-Strecke generiert, die allein als Übergabe- und Rückgabeparameter der Methoden erlaubt ist. Sie repräsentiert eine Tabellenzeile, wobei die Transformationen in das Typensystem der XML-Schnittstelle berücksichtigt sind. Die Architektur des Beratungsclients Die Beratungsanwendung wird nicht nur zentral als Web-Anwendung bereitgestellt, sondern auch als Client-Anwendung, die ohne Kontakt zum Server lauffähig sein kann (siehe Abb. 5). Dieser Beratungsclient wird mit „Jakarta Tomcat” (Apache Software Foundation; siehe http://jakarta.apache.org/tomcat) als Web-Container auf den Zielrechnern ausgerollt und setzt die freie Java-Datenbank „HSQL” (vgl. [hsq02]) ein. Im Online-Modus greift sie auf die Geschäftslogik der Server-Anwendung zu. Dazu werden das XML-Protokoll der Server-Großrechner-Schnittstelle und HTTP als Transport-Protokoll eingesetzt. Die aufgerufene Geschäftslogik wird damit als Web-Service verfügbar. Serverseitig nimmt ein Servlet den HTTP-Post-Aufruf an und leitet dessen Inhalt an eine Session- Bean weiter, die ihn interpretiert und in einen Methodenaufruf umsetzt. Das Frontend der Web-Anwendung wird im Client vollständig wiederverwendet; die Unterschiede liegen allein in der Business-Schicht. Hierzu wird auf deren Komponenten über eine abstrakte Fabrik (vgl. [Gam95]) zugegriffen, die je nach Anwendungsmodus drei Arten von Klassen erzeugt, die alle das Business- Interface der korrespondierenden Session- Bean implementieren: ■ eine Proxy-Klasse, welche die Aufrufe über RMI an die Session Bean weiterleitet (im Fall der Server-Anwendung), ■ eine Java-Klasse, die die Geschäftslogik direkt anstößt (im Offline- Modus der Client-Anwendung) und ■ eine Proxy-Klasse, die die Aufrufe an eine Stub-Klasse weiterleitet, die diese in XML-Form umsetzt und über HTTP als Transport-Protokoll an die Serveranwendung weiterleitet (im Fall des Online-Modus der Client-Anwendung). Jede dieser Klassen kann vollständig aus der Modell-Klasse der Business-Layer- Komponente generiert werden – mit Ausnahme der Java-Klassen, die lokal verfügbare Geschäftslogik aufrufen, da hier nur die Methodenrahmen aus dem Modell ableitbar sind. Ob eine Geschäftsmethode entfernt über XML aufrufbar sein soll, wird im Modell eingestellt. Die Zugriffe auf die lokale Datenbank werden wie in der Server-Anwendung über eine logische Schicht gesteuert, die einer physischen vorgeschaltet ist. Dabei wird ein möglichst hoher Grad an Wiederverwendung der Quellen der Serveranwendung angstrebt. Schreibende Zugriffe auf Bestandsdaten sind in der Client-Anwendung nur im Zuge eines Herunterladens vom Server zulässig. Die Wiedervorlagedaten eines Benutzers werden mit dem Legitimieren an der Server-Anwendung repliziert, wobei die Client-Anwendung die Datenhoheit trägt.
Seite 1 und 2: objekte modellgetriebene architektu
Seite 3: objekte XML-Schnittstelle Die Archi

MODELLGETRIEBENE ARCHITEKTUR IN EINEM J2EE ... - OXSEED

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?