MODELLGETRIEBENE ARCHITEKTUR IN EINEM J2EE ... - OXSEED

objekte
modellgetriebene architektur
von joachim purgahn, gerhard renner,
jochen reckziegel und jürgen f. krusch
MODELLGETRIEBENE
ARCHITEKTUR IN EINEM
J2EE- UND COBOL-
GROSSRECHNER-UMFELD
Die Deutsche Bank Bauspar AG modernisiert ihr Bausparsystem durch die Integration
eines COBOL-Großrechner-Systems in web-basierte Applikationen. Hierzu wurde ein
eigener Architekturstil entwickelt, der sich an der „Model Driven Architecture” orientiert
und der die heterogenen Plattformen durch die Codegenerierung aus einem gemeinsamen
UML-Modell verbindet. Der Artikel vermittelt einen Überblick der Architektur
und der eingesetzten Techniken.
Das Kernsystem der Deutsche Bank Bauspar
AG läuft auf einem IBM-Großrechner
und basiert auf CICS (Customer Information
Control System), COBOL und
DB2. Es entstand in den 80er Jahren und
wurde seitdem stetig weiterentwickelt.
Dabei lag der Schwerpunkt auf der
Implementierung neuer fachlicher Funktionen;
die technische Basis blieb im
Wesentlichen unberührt.
Mit unserer IT-Strategie wurde vor zwei
Jahren der Grundstein für die evolutionäre
Weiterentwicklung des Systems und den
dafür notwendigen sukzessiven Aufbau
der methodischen und organisatorischen
Grundlagen der Softwareentwicklung
gelegt. Unter evolutionärer Weiterentwicklung
wird dabei eine zukunftsorientierte,
schrittweise Überarbeitung des
Kernsystems verstanden mit dem Ziel, ein
Höchstmaß an Prozessunterstützung für
die internen Arbeitsabläufe zu bieten
sowie die Offenheit für das Internet sicher
zu stellen. Dabei haben unsere Kunden,
Vertriebspartner und Mitarbeiter immer
anspruchsvollere Bedürfnisse, denen wir
mit umfangreichen Serviceleistungen gerecht
werden wollen:
■ Der Kunde möchte seinen Vertrag über
das Internet einsehen, Formulare herunterladen
und sich zu Vertragsoptimierungen
beraten lassen.
■ Die Vertriebspartner wünschen sich darüber
hinaus weitreichendere Berechnungs-
und Bestandsinformationen,
die auch ohne Internetanschluss im
mobilen Vertrieb zugänglich sein müssen.
■ Im Backoffice möchten unsere
Mitarbeiter nahtlos die Prozesse weiterführen,
ohne Daten redundant eingeben
zu müssen.
Hierfür basiert unsere Anwendung für
sämtliche Zielgruppen auf nahezu identischen
Quellcode und dem gleichen
Datenbestand. Durch diese enge Verzahnung
der Zielgruppen und der einheitlichen
technischen Lösung wird eine
Reduzierung des Entwicklungsaufwands
heute, aber auch zukünftig in der Wartung
angestrebt. Allein unsere Vertriebspartner
und Mitarbeiter stellen mehrere zehntausend
Anwender dar.
Das Umfeld der bestehenden Großrechner-Kernanwendung
bedingt weitreichend
die gewählte Softwarearchitektur.
Das bauspar-spezifische Wissen liegt im
Erfahrungsschatz der COBOL-Entwickler,
die seit mehr als einem Jahrzehnt die
Anwendung pflegen. Daher haben wir uns
entschlossen, wesentliche Bausparfunktionen
wieder in COBOL abzubilden und
diese als Services über eine XML-
Schnittstelle in ein web-basiertes J2EE-
Umfeld zu integrieren. Die sukzessive
Überführung auf die neue Softwarearchitektur
impliziert eine enge Verbundenheit
zum bestehenden Datenbankschema,
da jede strukturelle Änderung in
den Daten eine Anpassung der bestehenden
Kernanwendung und damit hohe
Aufwände bedeutet. Im neuen Bausparsystem
verbleibt die Kernlogik auf dem
Großrechner, die Präsentationslogik und
die Steuerung langer Transaktionen werden
innerhalb einer mehrschichtigen J2EE-
Architektur mit „BEA WebLogic Server”
(BEA Systems) unter dem Betriebssystem
„Sun Solaris” (Sun Microsystems) verfügbar
gemacht. Die verschiedenen Anwendergruppen
– Kundenbetreuer, Vertriebspartner
und Internet-Kunden – werden
über eigene Web-Applikationen bedient.
Ausgehend von der darunter liegenden
EJB-Schicht wird die Anwendung einheitlich
gehalten.
die autoren
Dr. Joachim Purgahn ist
Softwareentwickler bei der Deutsche
Bank Bauspar AG und im
beschriebenen Projekt verantwortlich
für das Framework und die
Generierungsaspekte.
Gerhard Renner ist Softwareentwickler
bei der Deutsche Bank Bauspar AG und
im Projekt verantwortlich für das
Framework auf dem Großrechner.
Jochen Reckziegel ist Leiter der
Softwareentwicklung bei der Deutsche
Bank Bauspar AG und technischer
Projektleiter.
Jürgen F. Krusch ist Leiter der
Organisation bei der Deutsche Bank
Bauspar AG und Gesamtprojektleiter.
Der Architekturstil des
neuen Bausparsystems
Von Projektbeginn an wurde die Entwicklung
eines eigenen Architekturstils in

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,

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.

Bemerkungen zum
Entwicklungsprozess
Das Bausparsystem wird innerhalb eines
Rational Unified Process (vgl. [Kru98])
iterativ entwickelt. Einer Analysephase
schließt sich innerhalb der Iterationen eine
Designphase an, die von der Implementierung
nicht scharf abzutrennen ist. Das
Klassenmodell der Anwendungsfälle wird
entworfen und sukzessive mit den
Konfigurationsparametern für die Codegenerierung
versehen. Parallel dazu werden
die ersten Komponenten generiert und
getestet. Für den Anwendungsentwickler
bedeutet das Arbeiten in dieser Umgebung
neben dem Implementieren auch stets
Bearbeiten des Modells und Generieren
der betroffenen Artefakte.
Das UML-Modell und die Generierungsschablonen
werden mit den Java-
Quellen unter dem Concurrent Versions
System (CVS) versioniert. Die COBOL-
Quellen werden auf dem Großrechner in
einem eigenen Verwaltungssystem gepflegt
und bearbeitet. Modellierung, Generierung
und Java-Entwicklung werden auf
Arbeitsplatzrechnern unter Windows NT
durchgeführt. Der Generator arbeitet
dabei immer auf dem aktuellen Stand der
Java-Quellen, wodurch die Übernahme
der geschützten Bereiche in neue Generate
sichergestellt ist. Um die COBOL-Quellen
automatisiert erzeugen zu können, wurde
ein FTP-Client in den Generator integriert,
der für jedes Generat die aktuelle Quelle
aus der Großrechnerumgebung transferiert
und im Falle einer Aktualisierung die
geänderte Quelle wieder zurücküberträgt.
Während die Konsistenz und die
Lauffähigkeit des Quellcodes nächtlich
durch automatisiertes Übersetzen und
objekte
modellgetriebene architektur
Abb. 5: Übersicht der verschiedenen Versionen und Modi der Beratungsanwendung
und deren Datenhaltung
Packen der Java-Quellen und durch
Protokollieren der Entwicklertests überprüft
werden, setzen wir in der Konsistenz
von Modell, Generierungsschablonen und
Quellen auf die Disziplin des Entwicklerteams
und führen Generierungen des gesamten
Modells nur vor definierten
Release-Ständen durch.
Fazit
Die beschriebene Architektur des neuen
Bausparsystems wurde anhand eines
Prototyps, der einem Last- und Performanztest
unterzogen wurde, erfolgreich
erprobt. Seit Mitte 2001 hat der modellgetriebene
Ansatz seine hohe Effizienz innerhalb
der ersten Iterationsphasen unter
Beweis gestellt; die ersten Anwendungsteile
gehen in diesem Jahr in Produktion.
Durch die Konzentration auf die
Umsetzung der Fachlogik ereichen wir
eine hohe Produktivität, die zusätzliche
Aufwände zur Administration des relativ
komplexen Entwicklungsprozesses um ein
Vielfaches überwiegt. Als besonders hilfreich
hat sich die Verbindung unserer
heterogenen Systemlandschaft über die
Codegenerierung aus einem gemeinsamen
Modell herausgestellt, wodurch nicht nur
COBOL- und Java-Entwicklung stets konsistent
gehalten werden, sondern auch das
wichtige einheitliche Verständnis der
Architektur bei den verschiedenen Entwicklergruppen
herbeigeführt und dadurch
die Zusammenarbeit entscheidend
verbessert wurde. Indem wir die Pflege der
Generierungsschablonen in den Entwicklungsprozess
einbeziehen, beugen wir der
möglichen Gefahr vor, Design und
Implementierung zu stark an ihnen auszurichten
und daran zu binden.
Durch das weitgehende Freihalten des
Kernmodells von technischen Details, die
in den Generierungsschablonen gepflegt
und in speziellen Eigenschaftsleisten konfiguriert
werden, erreichen wir die
Offenheit, auf die in steter Weiterentwicklung
begriffene Technologie-Landschaft
flexibel eingehen zu können. Diese Offenheit
kommt insbesondere an den
Schnittstellen zwischen den Plattformen
und zu Datenbanken zum Tragen, da hier
die programmatische Umsetzung umfassend
generiert wird. So sind Änderungen
am Transport-Protokoll – z. B. eine Umstellung
auf SOAP – durchaus möglich, da
nur wenige Frameworkklassen und Generierungsschablonen
umzustellen wären
und der ständig anwachsende, abhängige
Quellcode vollständig generiert wird.
Mit unserem Architekturstil und seiner
Orientierung an der Model Driven Architecture
haben wir eine wichtige
Weichenstellung für die Weiterentwicklung
unserer unternehmenskritischen DV-
Systeme gelegt und glauben, ein interessantes
Beispiel der Integration eines
COBOL-Großrechner-Systems in webbasierte
Anwendungen zu bieten. ■
Literatur & Links
[Apa02] Apache Software Foundation,
Struts: Open source framework for building
Web applications (siehe: http://jakarta.
apache.org/struts)
[Gam95] E. Gamma, R. Helm, R. Johnson,
J. Vlissides, Design Patterns, Addison-
Wesley 1995
[hsq02] The hsqldb Development Group,
HSQL database engine (siehe http://hsqldb.
sourceforge.net)
[IOS02] Interactive Objects Software
GmbH, ArcStyler: Architectural IDE for
Model Driven Architecture (siehe: http://
www.io-software.com)
[Koc02] T. Koch, „Model Driven
Architecture”: eine Einführung, in:
OBJEKTspektrum 2/2002
[Kru98] P. Kruchten, The Rational Unified
Process, John Wiley & Sons 1998
[Maa02] Maas High Tech Software GmbH,
XML4cobol: Werkzeug zur Generierung
von COBOL-Modulen, die XML auf
COBOL-Strukturen abbilden (siehe: http://
xml4cobol.com)
[Sun02] Sun Microsystems, Sun Java
Center J2EE Patterns (siehe http://developer.
java.sun.com/developer/technicalArticles/
J2EE/patterns)