Gesellschaft für Informatik e.V.

Lecture Notes in Informatics


Software Engineering 2008, Fachtagung des GI-Fachbereichs Softwaretechnik, 18. - 22.02.2008 in Muenchen P-121, 80-84 (2008).

Gesellschaft fuer Informatik, Bonn
2008


Editors

Korbinian Herrmann (ed.), Bernd Bruegge (ed.)


Copyright © Gesellschaft fuer Informatik, Bonn

Contents

Muster zur Migration betrieblicher Informationssysteme

Wilhelm Hasselbring , Achim Buedenbender , Stefan Grasmann , Stefan Krieghoff and Joachim Marz

Abstract


Wir berichten über unsere Erfahrungen aus drei unterschiedlichen Migrationsprojekten, um daraus verallgemeinerte Muster abzuleiten. Es gibt verschiedene Möglichkeiten ein Altsystem in eine neue Architektur zu migrieren. Altsysteme stellen wichtige Investitionen dar, die nicht einfach außer Betrieb genommen werden können. Der Betrieb muss während des Übergangs weitergehen. Ein Unternehmen kann nicht - nur zur Einführung einer neuen Software-Architektur - mehrere Monate oder auch Jahre lang seinen Betrieb einstellen. Die Entwicklung eines neuen Systems erfordert einen signifikanten Zeitraum bis zur Stabilisierung des neuen Systems durch den praktischen Einsatz. Während dieses Gesamtzeitraums muss das Altsystem i.d.R. ebenfalls weitergepflegt werden, wodurch zeitgleich Kosten sowohl für das Altals auch das Neusystem entstehen. Folglich sind sanfte Migrationspfade und die Integration von Altund Neusystemen essenziell für die Praxis der Integration von Informationssystemen [BS95, Ha00]. Entwurfsmuster bieten bewährte Lösungsstrukturen für immer wiederkehrende Probleme. Für den objektorientierten Entwurf und auch die Strukturierung auf Softwarearchitekturebene existieren bereits viele Kataloge (siehe z.B. http://www.architekturmuster.de/). Während die Bedeutung von modularen, mehrschichtigen Architekturen für Unternehmensinformationssysteme allgemein akzeptiert ist und deren Vorteile ausführlich publiziert wurden, ist die systematische Migration von Altsystemen (so genannte Legacy-Systeme) hin zu neuen Architekturen nur in einem wesentlich geringeren Maße erforscht. Insbesondere gibt es nur wenig publizierte Muster für diesen Problembereich. 80 Legacy - Schnittstelle Legacy - Client DB - Schnittstelle (a) Legacy - Legacy - Dublo Schnittstelle Server Datenbank Geschäftslogik Service - Schnittstelle Service Neuer Neuer Client Applikations - server Legacy - Schnittstelle Legacy - Client Legacy - DB - Schnittstelle Server (b) Legacy - Dublo Schnittstelle Datenbank Old Geschäftslogik Neuer Database Applikations - Neuer Client server Legacy - Schnittstelle Legacy - Legacy - Legacy - Client Server Datenbank (c) Dublo Schnittstelle DB - Schnittstelle New Geschäftslogik Neuer Neue Database Applikations - Neuer Client Datenbank server Abbildung 1: Die Varianten des Dublo-Musters. Im Folgenden berichten wir über unsere Erfahrungen aus drei unterschiedlichen Migrationsprojekten, um daraus verallgemeinerte Muster abzuleiten: KDO: Die Migration kommunaler Informationssysteme von Informix 4GL hin zur Java Enterprise Edition. Die KDO stellt Standardsoftware für kommunale Verwaltungen her, insbesondere auch als Application Service Providing. IBS: Die Migration von Produktionsmanagementsystemen, die mit dem Gupta Teamdeveloper (mit C++ und Visual Basic) entwickelt wurden, hin zu .NET. Die IBS AG stellt Standardsoftware für die Industrieproduktion her. Cewe Color: Die Migration eines Auspreisungssystems von COBOL hin zu einer regelbasierten Java-Anwendung mit JBoss Rules und Oracle-Datenbank. CeWe Color ist in Europa Marktführer für die Fotoentwicklung, wobei die Auspreisungssoftware die Preisetiketten für die Fototaschen erstellt. In diesen Projekten traten und treten immer wiederkehrende Probleme auf, insbesondere im Bereich der Datenbankintegration [Co05]. Aus den Erfahrungen des KDO-Projektes, welches bereits seit 2002 läuft, wurde schon zuvor das Dublo-Muster [Ha04] abgeleitet. Das Dublo-Muster (DUal Business LOgic) basiert auf der teilweisen Duplikation der Ge- schäftslogik zwischen Altund Neusystem. Inzwischen können wir auf einen - insbesondere durch die Betrachtung mehrerer industrieller Projektkontexte - erheblich erweiterten Erfahrungsschatz zurückgreifen. Unsere Erfahrungen werden in diesem Papier durch die Beschreibung der Vorund Nachteile unterschiedlicher Varianten des Dublo-Musters verallgemeinert, so dass sie für ähn- 81 liche Aufgaben der Migration von Architekturen wiederverwendet werden können. Wir konnten drei Varianten des Dublo-Musters identifizieren: Dublo Service Die Dublo-Service-Lösungsstruktur ist in Abbildung $1(a)$ dargestellt. Die Grundidee besteht in der Entwicklung der Geschäftslogik in der neuen Geschäftslogikschicht, der Erstellung eines Legacy-Adapters für den Zugriff der neuen Ge- schäftslogik auf die existierende Legacy-Geschäftslogik und der Benutzung dieses Adapters für den Datenzugriff. Folglich wird auf die Datenbank nur indirekt durch den vorhandenen Legacy-Code zugegriffen. Der vorhandene Code dient als dienstbasierte Zugriffsebene für die Datenbank. Auf Funktionalität, die in der neuen Geschäftslogikschicht entwickelt wird, erfolgt der Zugriff durch eine ebenfalls neue Präsentationsschicht. Dies stellt die Variante des Dublo-Musters dar, wie es in [Ha08, Kr08] als Migrationsstrategie hin zu neuen Architekturen beschrieben wird. Da die Entwicklung der neuen Präsentationsund Geschäftslogik von der Funktion des alten Systems getrennt wird, ist eine sanfte Migration möglich. Bei dem Dublo- Muster können alte Geschäftslogik und vorhandene Nutzungsschnittstellen so lange wiederverwendet werden, wie sie Funktionalität bereitstellen, die in dem neuen Anwendungskontext sinnvoll ist. Die alte Logik kann Schritt für Schritt durch eine neue Geschäftslogikschicht ersetzt werden. Dublo Database Old Die Dublo-Database-Old-Lösungstruktur ist in Abbildung $1(b)$ dargestellt. Die Grundidee besteht darin, dass im Gegensatz zum Dublo-Service-Muster direkt auf die Legacy-Datenbank zugegriffen wird. Diese Strategie erhält die alte Datenbank und ersetzt die alte Kombination aus Prä- sentations-, Geschäftsund Datenzugriffsebene durch getrennte Präsentationsund Geschäftslogikebenen mit dem Vorteil, dass diese Strategie sofort eine Drei-Schichten-Architektur mit den gut getrennten Aspekten Präsentation, Geschäftslogik und Datenzugriff liefert. Falls das Altsystem ein DBMS verwendet, das den direkten Zugriff erlaubt, bleibt die Möglichkeit des Direktzugriffs auf die Datenbank ohne Verwendung von Legacy-Code, wie es diese Variante vorsieht. Dublo Database New Die Dublo-Database-New-Lösungstruktur ist in Abbildung $1(c)$ dargestellt. Die Grundidee besteht darin, parallel zum Altsystem eine ganz neue Infrastruktur aufzubauen. Die Anwendung des Dublo-Serviceund des Dublo-Database-Old-Musters ist sinnvoll, wenn ein inkrementeller Austausch alter Geschäftslogikund Client-Software durch neue Geschäftslogik in der Mittelschicht angestrebt wird. Da keine zusätzliche Datenbank eingeführt wird, entstehen keine Konsistenzoder Abgleichsprobleme zwischen neuer und alter Datenbank. Mit dem Dublo-Service-Muster ist es für die neuen Clients transparent ob Geschäftslogik bereits in der neuen Mittelschicht oder noch im alten Legacy-Code implemetiert ist. Bei der KDO hatten wir uns ursprünglich für die Dublo-Service-Variante entschieden. Der erste Ansatz sah Dublo-Database-Old-Variante vor. Die gewachsenen Datenbankstrukturen in den vorhandenen Altsystemen offenbaren aber nicht die für eine korrekte Benutzung 82 Einsatzkriterien Erfolgsfaktoren Pro: Das Datenbankschema beschreibt die Möglichkeiten zur Generierung von Web Semantik der Daten nicht ausreichend Services für Dienste des Altsystems Dublo Pro: Ein Parallelbetrieb von Altund Die Geschäftslogik ist (relativ) stabil Neusystem ist erforderlich Service Eine serviceorientierte Architektur ist Teil Contra: Aus Performance-Gründen soll direkt des Leitbilds der IT-Strategie auf die Datenbank zugegriffen werden Pro: Geschäftslogik und Datenbank sind gut Das Datenbankschema beschreibt die getrennt Semantik der Daten ausreichend Dublo Pro: Ein Parallelbetrieb von Altund Das DBMS wird vom Hersteller Database Neusystem ist erforderlich weitergepflegt oder kann (relativ) einfach Old Contra: Das Datenbankschema beschreibt ersetzt werden die Semantik der Daten nicht ausreichend Pro: Das Datenbankschema beschreibt die Die neue Technologie ist bekannt oder Semantik der Daten nicht ausreichend wird umfassend geschult Dublo Pro: Das DBMS wird vom Hersteller nicht Kein Parallelbetrieb mit alter Datenbank Database weitergepflegt nötig New Contra: Ein Parallelbetrieb von Altund Neusystem ist erforderlich Tabelle 1: Kriterien für die Varianten des Dublo-Musters. erforderliche Semantik der gespeicherten Datenbankobjekte, welche in den Informix 4GL Funktionen codiert wurde. Inzwischen wurden einige Komponenten auch entsprechend der Dublo-Database-New-Variante migriert. Es ist also nicht notwendig, sich in einem Kontext auf eine Variante zu beschränken. Für die jeweiligen Komponenten müssen die entsprechenden Kriterien erfüllt sein (siehe Tabelle 1). Bei IBS sieht die Situation anders aus. Durch die eingesetzte Implementierungstechnologie (Zugriff auf Oracle und SQLServer aus C++ und Visual Basic Programmen heraus) sind die Datenbankstrukturen nicht direkt mit den oberen Schichten verknüpft, wie es bei 4GL-Systemen der Fall ist [WW90]. Somit kann hier das Dublo-Database-Old-Muster umgesetzt werden. Bei CeWe Color besteht der Ansatz darin, die alte COBOL-basierte Datenhaltung komplett abzulösen, somit das Dublo-Database-New-Muster umzusetzen. Dieser Ansatz hat zumeist den Nachteil, Konsistenzmechanismen zu benötigen, die die Daten zwischen alter und neuer Datenbank replizieren [Ha97]. Im Falle der zu migrierenden Auspreisungssoftware, die in den Fotolaboren zum Einsatz kommt, werden Altund Neu-Systeme jedoch nicht parallel betrieben. Somit kommt dieser Nachteil hier nicht zum Tragen. Tabelle 1 fasst die Einsatzkriterien und Erfolgsfaktoren für die Varianten des Dublo-Musters zusammen. Generell gilt für alle Varianten des Dublo-Musters - verglichen mit einem abrupten Übergang der gesamten Geschäftslogik (Big Bang) - dass es in der Übergangszeit zu redundantem Code und Zusatzaufwand kommt. Da neue Systemanforderungen erheblichen Einfluss auf den Entwurf der Geschäftslogik haben können, kann es passieren, dass alter Legacy- Code nicht wiederverwendet werden kann und in der neuen Geschäftslogikschicht sofort 83 reimplementiert werden muss. Dieser letzte Aspekt ist aus vielen Legacy-Integrationspro- jekten bekannt. Infolgedessen reduziert dies die Anwendbarkeit des Dublo-Musters auf Bereiche, in denen sich die Geschäftsprozesse während der Übergangszeit nicht zu häufig ändern.


Full Text: PDF

Gesellschaft fuer Informatik, Bonn
ISBN 978-3-88579-215-4


Last changed 04.10.2013 18:16:12