Carsten Bovelet (Wuppertal)
"Datenhaltungskonzepte in der kommerziellen Anwendungsentwicklung"
1 Einleitung
Der Einsatz unterschiedlicher Datenbanksysteme ist heute in nahezu jedem
Unternehmen mit eigener Anwendungsentwicklung Realität. Die kommerzielle
Anwendungsentwicklung ist in diesem Zusammenhang besonders betroffen, da gerade
Banken und Versicherungen frühzeitig auf die Datenverarbeitung gesetzt haben
und deshalb nahezu alle im Laufe der Zeit entstandenen Technologien in den
verschiedenen Unternehmen zu finden sind. Problematisch ist dabei, das die
jeweils "neueste Technologie" nicht durchgängig für alle Anwendungen genutzt
wurde und deshalb noch heute veraltete Anwendungen, die auf der Basis von
Assembler realisiert worden sind, neben auf neuesten objektorientierten
Techniken basierenden Anwendungen existieren. Diese Aussage gilt sowohl für
Programmiersprachen als auch für Benutzungsschnittstelle, Steuerung und
Datenbanken.
Hier soll zunächst kurz der generelle Rahmen vorgestellt werden, der es unserem
Unternehmen in Zukunft erlauben soll, der zuvor aufgezeigten Problemstellung in
angemessener Weise zu begegnen. Zu diesem Zweck wird das Projekt
Software-Architektur vorgestellt.
Anschliesend wird auf die Datenhaltung als eine wichtige Komponente dieser
Architektur detailliert eingegangen.
2 Architekturkonzept auf Unternehmensebene
2.1 Zielsetzungen
Das Software-Architekturkonzept stellt in Zukunft eine wesentliche Basis für
die Softwareentwicklung da. Mit Hilfe einer solchen Architektur sollen alle
vorhandenen und zukünftigen Plattformen eines Unternehmens in ein einheitliches
Konzept integriert werden, das es ermöglicht,
* Anwendungen weitestgehend unabhängig von spezifischer Hard- und Software zu
entwickeln,
* die Wiederverwendbarkeit und den Kauf von Anwendungen bzw. Anwendungsteilen zu
fördern,
* Anwendungen verteil- und skalierbar zu machen,
* die Auswirkungen von Wartungs- und Änderungdiensten eng begrenzt zu halten
und
* die Produktivität von Anwendern und Entwicklern zu erhöhen.
Mit diesen Qualitätsmerkmalen sind die wesentlichen Zielsetzungen, die sich mit
dem Begriff Software-Architektur in der kommerziellen Anwendungsentwicklung
verbinden, charakterisiert. Mit diesen allgemeinen Zielsetzungen verbinden sich
einige grundlegende Prinzipien, die für die Konzeption einer solchen Umgebung
von Bedeutung sind:
* Die Berücksichtigung von Standards.
* Eine strikte horizontale und vertikale Schichtenbildung
* Die Möglichkeit zum Einsatz einer Workflow-Tools
*
Die Unterstützung einer einfachen und für den Entwickler transparenten
Anwendungsentwicklung in einer heterogenen Systemlandschaft unter Einbeziehung
von Grosrechnern.
* Die einfache Nutzung von selbst entwickelten oder fertig gekauften Bausteinen
in der Entwicklung.
Diese Prinzipien müssen in der zukünftigen Anwendungsentwicklung
Berücksichtigung finden. Die Software-Architektur dient dabei als eine
Grundlage zum Erreichen dieser Zielsetzung.
2.2 Rahmenbedingungen
Folgende Hardware-Plattformen befinden sich derzeit im produktiven Einsatz oder
sind zukünftig dafür vorgesehen:
* Bull DPS 9000 Grosrechner mit Betriebssystem GCOS 8.
* Bull Escala mit Betriebssystem AIX 4.1.
* PCs mit Betriebssystem WfW 3.11.
Alle Plattformen müssen bei der Erarbeitung berücksichtigt werden.
Alternativen für den Grosrechner werden derzeit nicht geprüft, er soll
mittelfristig die Aufgaben eines "grosen Datenservers" übernehmen.
Folgende Software-Produkte befinden sich derzeit im Einsatz bzw. sollen
zukünftig eingesetzt werden:
* Codasysl-Datenbank IDS II mit Bull-spezifischem TP-Monitor für den
Grosrechner.
* Informix für die Unix-Plattformen.
* Cobol-74-Compiler für den Grosrechner, Cobol-85 in Planung.
* Innovator 5.0 als CASE-Tool (strukturierte Methoden)
* C++ oder Cobol für Unix wird geprüft.
* Oberflächen und Kommunikationstool Sold+ für den Grosrechner, Microfocus
Dialog System auf PC-Plattform wird geprüft.
2.3 Lösungsansätze
Die Umsetzung der in Punkt 2.1 dokumentierten Ziele stellt viele Anwender trotz
aller Bemühungen in Richtung öffene Systeme" vor grose Probleme, da am Markt
kein ausgereifter und von vielen Unternehmen unterstützter Standard zur Lösung
dieser Problemstellungen zu erkennen ist.
Aufgrund dieser Situation bestand die Notwendigkeit, ein eigenes Konzept unter
Berücksichtigung der zuvor skizzierten Vorgaben zu entwickeln. Dieses Konzept
basiert auf folgenden Grundlagen:
* Objektorientierung als Grundkonzept der Architektur (Wiederverwendbarkeit,
horizontale und vertikale Strukturierung, Zukaufbarkeit von Anwendungen).
* CORBA als Technologie-unabhängiger Standard für die Infrastruktur.
* Klassische Werkzeuge zur Realisierung der Entkopplungsschichten (3GL).
Diese Grundlagen erfordern eine Architektur, die unterschiedliche Schnitte bei
der Abbildung der Software auf die technische Infrastruktur zulast. Folgende
Schnitte sollten unterstützt werden:
* Distributed Database: Fur Objekte, die sowohl Daten unter IDS II als auch
Daten unter Informix nutzen.
* Remote Database:Fur Objekte, deren Verarbeitung und Datenhaltung auf
unterschiedlichen Plattformen implementiert sind
* Distributed Computing:Fur Objekte mit Anwendungsteilen auf unterschiedlichen
Plattformen.
* Remote Presentation:Fur Objekte, deren Benutzungsschnittstelle von der
Verarbeitung getrennt ist.
Fur die Datenhaltung innerhalb einer Architektur sind die beiden ersten Punkte
interessant. Diese Punkte in Kapitel 3 näher betrachtet werden.
3 Die Datenhaltung im Architekturkontext
3.1 Anforderungen an die Datenhaltung
Die Datenhaltung innerhalb der zuvor skizzierten Rahmenbedingungen mus folgenden
Kriterien genügen:
* Klassische Transaktionsabsicherung (ACID).
* Unterstützung verteilter Transaktionen (für Objekte mit verteilter
Datenhaltung).
* Unterstützung langlaufender Transaktionen zur kontrollierten Absicherung von
Geschäftsprozessen.
* Unterstützung einer einfach handhabbaren und transparenten
Entkopplungsschicht.
* Hohe Performance.
* Unterstützung für Management-Informationssysteme.
* Investitionssicherheit der Lösung / zukünftige Kostenreduktion.
Diese Ziele sollen durch eine Mischung aus objektorientierten und klassischen
Prinzipien der Softwareentwicklung erreicht: Datenzugriffsobjekte ermöglichen
eine offene und transparente Schnittstelle, die sich durch entsprechendes
Mapping gut in die geplante Entwicklungsumgebung einpasst. Die eigentliche
Realisierung der Zugriffsschicht erfolgt auf traditionelle Art und Weise und
nutzt somit alle Vorteile der jeweiligen Plattform.
Nur für eine verteilte Datenhaltung müssen hier zusätzliche Funktionalitäten
für verteilte Transaktionen genutzt werden. 3.2 Alternative Konzepte zur
Umsetzung
Ein durchgängiges und einsatzfähiges Konzept zur Umsetzung einer
objektorientierten Datenzugriffsschicht einschl. einer Unterstützung
unterschiedlicher Technologien ist derzeit nicht verfügbar. Aus diesem Grund
wurden verschiedene Lösungsansätze untersucht, die zumindest teilweise den
Anforderungen des Unternehmens entsprechen. Diese Lösungsansätze werden im
folgenden vorgestellt
3.2.1 OMG / Corba
Innerhalb einer objektorientierter Unternehmensarchitektur ist es grundsätzlich
sinnvoll, sich zunächst an Standards in diesem Bereich zu orientieren. Für die
Umsetzung bieten die bisher vorliegenden Corba-Spezifikationen zwar
Hilfestellung an (OTS, Persistenz etc.), liefern aber keine direkten Lösungen
bzgl. der zuvor geschilderten Problematik. Aus diesem Grund wurde im Rahmen der
Architektur ein Konzept zur Umsetzung entwickelt, das unter Nutzung der
Möglichkeiten von Corba eine den zuvor skizzierten Anforderungen genügende
Datenhaltungskomponente ermöglichen soll.
Diese Konzeption stützt sich auf zwei wesentliche Elemente:
1. Die Schnittstellen werden auf der Basis der IDL definiert und orientieren
sich grundsätzlich an der Theorie der abstrakten Datentypen, die um
Selektionsmechanismen ergänzt werden.
2. Die Schnittstelle wird plattformspezifisch auf der Basis des Mappings auf die
jeweilige 3GL generiert.
3. Die Realisierung innerhalb der Datenzugriffsschicht erfolgt einschlieslich
der Transaktionsmechanismen auf klassische Art und Weise. Die im Vergleich zur
heutigen Technologie notwendigen zusätzlichen Funktionalitäten zur
Transaktionsabsicherung sollen entweder durch Nutzung von Corba-Services oder
durch den Einsatz entsprechender Transaktionsmonitore.
Auf dieser Basis wird eine einheitliche Schnittstelle geschaffen, die auf
allgemein akzeptierten Standards aufbaut und den Anforderungen des Unternehmens
vom Grundsatz her genügt. Probleme hinsichtlich der Umsetzung werden
hauptsächlich in Bezug auf Performance und die eng damit verbundene komplexen
Implementierung der Datenzugriffe innerhalb der Entkopplungsschicht erwartet.
3.2.2 VAA-Datenmanager
Der VAA-Datenmanager ist eine Element der Versicherungs-Anwendungsarchitektur
(VAA). Diese Architektur ist eine Branchenlösung der deutschen
Versicherungswirtschaft , die als ein Element auch sogenannte
Entkopplungsschichten enthält. Der Datenmanager soll den Datenzugriff innerhalb
von VAA-Anwendungen von technischen Spezifika trennen und kann grundsätzlich
als eine Möglichkeit zur Realisierung der Datenhaltungskomponente gesehen
werden.
Die Anforderungen an die Datenhaltung sind prinzipiell durch den Datenmanager
abgedeckt, Probleme ergeben sich hauptsächlich durch den Stand der Entwicklung
- es existieren derzeit nur grobe textuelle Beschreibungen der einzelnen
Entkopplungsschichten - sowie die sich abzeichnende Favorisierung bestimmter
Plattformen innerhalb einer proprietären Lösung. Zur Performance läst sich
unter diesen Aspekten ebenfalls keine Aussage machen.
3.2.3 Eigenentwicklung
Als weitere Möglichkeit wird die Eigenentwicklung einer Zugriffsschicht in
Sinne einer örganisatorischen Lösung" in Betracht gezogen. Hier sollen
zusätzlich notwendige Funktionalitäten auf der Basis der vorhandenen Mittel
durch den Entwickler selbst implementiert werden.
Diese auf den ersten Blick einfache und kostengünstige Lösung entpricht
allerdings in wesentlichen Punkten nicht den oben genannten Anforderungen, da
hier weder eine einheitliche und transparente Entkopplungsschicht entsteht noch
ausreichende Sicherungsmechanismen im Transaktionsbereich existieren. Die
Performance einer solchen Lösung würde stark von der Person des Entwicklers
abhängen.
3.3 Bewertung der Alternativen
Unter den zuvor diskutierten Ansätzen kommt realistisch gesehen nur die
Corba/OMG-Variante in Frage. Andere Ansätze sind entweder nicht einsatzfähig
wie VAA oder weisen andere schwerwiegende Mängel auf, die einen Einsatz in der
Praxis unmöglich machen. Die Tabelle zeigt das Ergebnis unserer Betrachtung im
Überblick, wobei der Punkt MIS/Data Warehouse bewust ausgespart bleibt, da hier
mangels Alternativen proprietäre Lösungen auf Informix-Basis favorisiert
werden.
CORBA VAA Eigenentwicklung
Klassische Transaktionsabsicherung ++ ++ ++
Verteilte Transaktionen + + - -
Langlaufende Transaktionen + + - -
Transparenz + ? -
Handhabbarkeit - ? -
Performance ? ? ?
Investitionen (Implementierung) + ? ++
Kosten (Betrieb) + + - -
4 Zusammenfassung und Ausblick
Grundsätzlich bleibt festzustellen, das es aus heutiger Sicht starke Analogien
zwischen der Software-Architektur und dem Datenhaltungskonzept innerhalb dieser
Architektur gibt: Ein praktisch einsetzbares Gesamtkonzept ist derzeit nicht
verfügbar. Mit Hilfe der vorhandenen Standards und Technologien ist es jedoch
möglich, zu einer praktikablen Lösung zu kommen, ohne wichtige Anforderungen
zu vernachlässigen.
Die in diesem Zusammenhang notwendigen Konzepte sind bereits erarbeitet, in
zukünftigen Projektstufen müssen die noch offenen Punkte geklärt werden.