Die alte und die neue Architektur: Auf der linken Seite ist die alte OS/2-Fat- Client-Architektur zu sehen, auf der rechten Seite die neue verteilte Thin-Client-Architektur. Quelle: Suva
Suva beschloss im Jahr 1998, ihre Kernanwendungen zu modernisieren, um die Anforderungen einer dynamischen und in wachsendem Maße vernetzten Organisation mit einem breiten Spektrum von externen Partnern besser erfüllen zu können. Die alte Architektur bestand aus 2 000 OS/2-Arbeitsplätzen, lokalisiert am Stammsitz und in 20 über die ganze Schweiz verteilten Agenturen, die mit den zentralen DB2-Datenbanken auf S/390-Großrechnern verbunden waren. Bei den Anwendungen handelte es sich um Fat Clients in Cobol mit einer GUI-Struktur, die auf „Dialog System“ von Micro Focus beruhte.
Die alte Architektur stellte, weil weder offen noch flexibel, ein großes Hindernis für das Erreichen strategischer Geschäftsziele dar. Tief greifende Veränderungen waren erforderlich. Nach gründlicher Analyse entschied man sich für eine Thin-Client-Architektur, die einfach zu verwalten war und jedem von überall her den Zugriff ermöglichte.
Von Fat Clients zu verteilten Thin Clients
In der neuen Architektur wird eine Java-GUI mit Thin Clients verwendet. Die migrierte Cobol-Geschäftslogik in der mittleren Schicht nutzt BEA Web Logic Enterprise auf AIX-Servern. BEA Tuxedo-Middleware verbindet Clients und Applikations-Server miteinander. Die bestehende Cobol-Datenschicht läuft ebenfalls auf AIX und stellt die Verbindung zu den zentralen DB2-Datenbanken her.
In Anbetracht der enormen Investitionen in die alte Geschäfts- und Datenschicht war die Rentabilität ein besonders kritischer Punkt. Diese Schichten waren in Cobol implementiert worden, entsprachen jedoch noch immer den geschäftlichen Anforderungen. Gebraucht wurde eine Methode, um den Cobol-Code auf intelligente Weise zu „wrappen“, damit er von der objektorientierten Java-GUI benutzt werden konnte - wobei auch die verteilten Systeme und Middleware-Komponenten der neuen Architektur zu berücksichtigen waren.
Zur Generierung des Codes für die Integration der Cobol-Legacy-Server in die neue verteilte Architektur wurden Tools von Delta Software Technology gewählt. Quelle: Suva
Um die bestehende Cobol-Geschäftslogik- und Datenzugriffsschicht zu übernehmen und diese in der neuen Architektur direkt als Services wieder zu verwenden, wurde die „Score Integration Suite“ von Delta Software Technology gewählt. Diese Suite implementiert offene Standards und setzt die Konzepte der „Model Driven Architecture“ der OMG um. Ein integrierter Workflow stellt drei Schlüsselprozesse zur Verfügung: Discovery, Composition und Production. Diese werden jeweils von Tools unterstützt, die nahtlos auf einem XML-basierten Composition Repository zusammenarbeiten. Diese Tools erzeugen plattformunabhängige Modelle (PIMs), die dann erweitert und zu plattformspezifischen Modellen (PSM) transformiert werden, um aus diesen den Quellcode zu generieren.
Die Komponenten der Geschäftsschicht wurden mittels automatischer Analyse der Cobol-Copybooks definiert. Composition Tools wurden benutzt, um für die GUI-Clients fein granulare Schnittstellen und Methoden zu entwerfen. In späteren Phasen des Projekts erfolgten Verbesserungen.
Der Code für die Kommunikation der Java- GUI-Clients mit der Cobol-Geschäftsschicht wurde automatisch generiert, ebenso der Code für Tuxedo und für die Infrastrukturmerkmale wie Interface-Versionierung, Datenkonvertierung und Parameterzuordnung. Die alte „stateful“ Geschäftsschicht wurde in „stateless“ Server für Web Logic übertragen, was Flexibilität bei der Lastverteilung und Ausfallsicherung für die Server gestattete.
Die Bereitstellung für zusätzliche Plattformen einschließlich J2EE/EJB, .NET und Web Services erfordert lediglich die Wahl eines geeigneten Plattform-Adapters. Der gesamte Code wird automatisch generiert. Zusätzliche Arbeiten an der Spezifikation oder am Design sind grundsätzlich nicht erforderlich.
Um die Cobol-Geschäftsfunktionen herum wurden Komponenten-Frames generiert zur Bereitstellung der Operationen und Interfaces. Anstelle der Server mit einem „breiten” Interface, das häufig mehrere 100 K umfasste, offerieren sie mehrere Interfaces und Operationen, die genau nur die Daten zur Verfügung stellen, die tatsächlich gebraucht werden. Fein granulare Interfaces erleichterten die Nutzung der Business Services und ermöglichen eine einfache Integration der Geschäftsfunktionen in neue Technologien wie Web Services und Portale. Die künftige Wartung wird vereinfacht, da generierte Server mehrere Versionen der einzelnen Komponenten-Interfaces unterstützen können.
Da beide Seiten des Interface bekannt waren, wurde der gesamte Code automatisch generiert, ohne dass Änderungen an der bestehenden Geschäftsschicht erforderlich waren. Diese nicht-invasive Herangehensweise bedeutete, dass keinerlei Notwendigkeit bestand, die Geschäftslogik- oder Datenzugriffsschicht zu modifizieren, was zu einer beträchtlichen Einsparung an Zeit und Aufwand führte. Notwendig waren lediglich technisch bedingte Änderungen, die automatisch durchgeführt wurden.
Generative Programmierung entspricht den Erfordernissen des Projekts
Für die erneute Schulung der Mitarbeiter waren keine Kosten budgetiert. Die Java-GUI musste daher 100prozentig kompatibel sein. Dafür wurde ein maßgeschneidertes, mit den standardmäßigen Client-seitigen Proxies integriertes Java-GUI-Framework geschaffen.
Bei der Definition der Generierungsmuster für die Abbildung der Proxy-Interfaces auf das Java GUI-Framework kam eine frühe Version des „Pattern-By-Example”-Tools von Delta zum Einsatz. Mit Hilfe der Frame-basierten Generatortechnologie „Angie“ von Delta wurden die maßgeschneiderten Code-Generierungsmuster in den standardmäßigen Proxy-Generierungsprozess integriert.
Pattern By Example und Angie wurden auch verwendet, um Java-Testtreiber als schnelle, einfache und Script-fähige Methode zur Überprüfung der einzelnen Server zu generieren. Als Hilfestellung für das Debugging und Austesten wurde zudem ein ausgefeiltes Trace-System generiert.
Die Legacy-Anwendung in Zahlen Quelle: Suva
Erfolgreiche Testläufe im September 2002 mit 200 Benutzern führten zur vollständigen Umstellung für alle 2 000 Benutzer im Oktober 2002. Innerhalb der ersten Tage verzeichnete das System pro Stunde im Durchschnitt zwei Millionen Zugriffe auf die DB2-Datenbanken - ein Transaktionsvolumen, das die neue Architektur problemlos bewältigte.
In der heutigen wirtschaftlichen Lage ist es notwendig, aus bestehenden Systemen das Bestmögliche herauszuholen. Dieses Projekt lieferte einen sehr guten Ertrag. Unter enger Zusammenarbeit mit der Saxos Informatik AG, dem Vertriebspartner von Delta in der Schweiz, wurden ungefähr fünf Millionen Zeilen des bestehenden Cobol-Codes im neuen System unmittelbar wiederverwendet. Der Cobol-Kerncode blieb völlig unverändert. Auf nicht-invasive Weise wurde die Funktionalität zur Unterstützung einer Service-basierten Integration hinzugefügt, was die zukünftigen Kosten für Support und Wartung minimiert und die Flexibilität für die Abdeckung zukünftiger Anforderungen massiv erhöht.
Durch den Einsatz generativer Programmiertechniken und -werkzeuge wurde es möglich, dieses gewaltige und komplexe Projekt pünktlich und im Rahmen des Budgets zum Abschluss zu bringen. Entscheidend dabei war, dass Score Integration Suite die Produktivität bei den Integrationsarbeiten vervielfacht hat.
Eine wichtige Lehre aus diesem Projekt ist die Erkenntnis, dass Integration ein Prozess ist und kein einmaliges Ereignis. Die Arbeit am nächsten Satz von Client-Typen sowie an der Integration neuer Partner und Lieferkanäle hat deshalb bereits begonnen.