Schwierigkeiten bei verteilter DV Die Anwender profitieren von objektorientierter Middleware

20.08.1993

*Francis Murphy und Raimo Rikkilae sind als Berater fuer Anwendungssysteme und Informationsarchitektur bei der Entitec Gesellschaft fuer Entity-Analysen und -Technologien GmbH in Hamburg taetig.

Fuer die DV-Abteilungen bedeuten die immer haeufigeren Technologieschuebe ein massives Problem. Das gilt auch fuer den jetzt allerorten anstehenden Einstieg in eine heterogene Systemwelt mit offenen und verteilten Anwendungen. Francis Murphy* und Raimo Rikkilae* zeigen auf, mit welchen Schwierigkeiten die Anwender rechnen muessen und wie vor allem objektorientierte Middelware-Techniken bei der Bewaeltigung der Aufgabe helfen koennen.

Viele Anwenderunternehmen erhoffen sich von heterogenen und verteilten Systemarchitekturen eine flexible DV-Infrastruktur, die sie in die Lage versetzt, die Benutzer rasch mit den jeweils aufgabengerechten Computerleistungen zu versorgen. Gedacht ist an systemtechnische Umgebungen, die permanent den aktuellen Anforderungen angepasst werden koennen und muessen.

Wie laesst sich angesichts dessen erreichen, dass auch die Anwendungsentwicklung und -wartung den sich rasant aendernden Anforderungen Rechnung tragen koennen? Das Problem ist klar: Die Konzepte und Komponenten fuer die Verwirklichung dezentraler Anwendungsmodelle sind derzeit sowohl in der Fachwelt als auch in den meisten Anwenderbetrieben noch Gegenstand heftiger Diskussionen. Niemand kann mitten in einer Phase schnellebiger Trends vorhersagen, welche Plattformen und Verteilungsarchitekturen in einigen Jahren das Rennen machen werden. An dieser Situation muss sich auch die IT-Strategie orientieren.

Hinzu kommt, dass heute viele Anwendungsprofile relativ kurzlebig sind. Oft veraendern sich schon nach wenigen Jahren das Datenvolumen, der Aufgabenumfang, die Standorte und andere Ausgangsfaktoren, von denen sich die Betriebe bei der Konzeption ihrer heterogenen und verteilten Systeme leiten liessen. Deshalb sollten die Anwendungssysteme so konzipiert werden, dass sie auf Dauer unabhaengig von den Eigenschaften bestimmter Plattformen und verteilter Architekturen eingesetzt werden koennen.

Die meisten Betriebe stuetzen sich heute noch auf Anwendungssysteme mit monolithischer Auslegung und eng miteinander verflochtenen Komponenten. Die einzelnen Systembestandteile lassen sich schon bei kleineren Eingriffen nicht getrennt behandeln, erst recht nicht beim Uebergang von zentralen Systemen zur Client- Server-Architektur, zum Workgroup-Computing oder anderen Dezentralisierungsformen mit schwer ueberschaubarer Komplexitaet.

Ein wesentlich groesseres Mass an Flexibilitaet gegenueber neuen Grundsystemen bei gleichzeitiger Stabilitaet der Programm- und Datenbestaende wird hingegen von der Objektorientierung erwartet.

Nach dem arbeitsteiligen Prinzip wirken hier bei der Ausfuehrung der Funktionen Objekte zusammen, die voneinander unabhaengig sind und miteinander korrespondieren. Softwareveraenderungen wirken sich nur innerhalb der betroffenen und nicht auf andere Objekte aus. Damit wird schon eine der wichtigsten Voraussetzungen fuer die Portabilitaet erfuellt.

Dieser Ansatz setzt allerdings ein praxisorientiertes Umsetzungsverfahren voraus, auf das sich die Entwickler bei der Neustrukturierung und kuenftigen Ausgestaltung der Anwendungssysteme stuetzen koennen. Eine geeignete Architektur sorgt unter anderem dafuer, dass sich die Portabilitaet bis zu den einzelnen Teilaspekten hin fortsetzt und nicht an Details scheitert. Sie unterscheidet zwischen Dimensionen des Objekts, die der Verteilungsneutralitaet gerecht werden, und Schichten eines Objekts, die die Plattformunabhaengigkeit gewaehrleisten (vgl. Abbildung).

Sowohl die System- als auch die Anwendungsobjekte weisen die gleiche einfache Grundstruktur auf. Deshalb koennen sie, um ein Gebilde beziehungsweise ein System aufzubauen, anhand weniger Regeln aneinander gebunden werden. Die zusaetzliche Zerlegung in Dimensionen zielt darauf ab, ein Objekt so zu gestalten, dass die verteilungsspezifischen Merkmale auseinandergehalten werden. Die dafuer notwendigen und miteinander verknuepften Komponenten sind

- Praesentation (Bildschirmmaske, Schnittstelle zu fremden Systemen und andere Aussenwelt-Bedingungen),

- Datenstruktur (konzeptionell: Entity-Modell, logisch: Datenbankdesign),

- Funktionalitaet (betriebswirtschaftliche Fachlogik),

- Steuerung (Koordination der oben genannten Komponenten des Objekts, die zur Ausfuehrung eines Geschaeftsvorfalls dienen) sowie

- Kommunikation (Zusammenwirken mit anderen Objekten in der Ausfuehrung eines Auftrags).

Mit der Zerlegung eines Objekts in seine Dimensionen wird die Voraussetzung fuer die Verteilung von Einzelobjekten und Objektklassen in einer dezentralen Verarbeitungsumgebung geschaffen. Je nach Bedarf und ohne viel Aufwand koennen die Komponenten eines Objekts von einem Verteilungsmodell zum anderen portiert werden. Durch eine derartige Gestaltung werden die Objekte von der Organisation der Rechnerinfrastruktur sozusagen abgekoppelt.

Der Object Request Broker

uebermittelt Nachrichten

Dabei faellt der Komponente Kommunikation die Schluesselrolle der Weitergabe von Nachrichten an andere Objekte zu, die an der Ausfuehrung einer Funktion beteiligt sind. Diese Aufgabe uebernimmt der von der Object Management Group stammende Postverteiler mit der Bezeichung Common Object Request Broker Architecture (Corba). Er wird von jeder Komponente im Netz (auch von Objekten) sowohl innerhalb der eigenen Plattform als auch in Verbindung mit anderen Plattformen benoetigt.

Corba koordiniert das Auffinden der Objekte mit Hilfe von Eintragungen in ein Tabellensystem, das unabhaengig von den Objekten gepflegt werden kann. Neben dieser Technik traegt zur Portabilitaet der gesamten Anwendung aber auch die Faehigkeit der Nachrichten zur Selbstbeschreibung bei. Sie vermeidet feststehende und umfangreiche Nachrichtenstrukturen und sorgt damit zugleich fuer eine sehr flexible Nachrichtensteuerung und -interpretation, denn Aenderungen in der Nachrichtenstruktur haben nur lokale Auswirkungen.

Darueber hinaus traegt die Schichtstruktur zur Portabilitaet der Anwendungen bei. Die konzeptionelle Schicht definiert den Rahmen, das "Was", und den Umfang eines Objekts und laesst erkennen, wie die "Aussenwelt" es versteht. Die logische Schicht, das "Wie", bildet das Objekt in seiner Zielplattform ab (Datenbank, TP-Monitor, Programmiersprache). Die physische Schicht, das "Womit", repraesentiert das Objekt mit den Betriebsmitteln.

Insbesondere die Trennung zwischen konzeptioneller und logischer Schicht ermoeglicht es, die plattformspezifischen Merkmale von letzterer fernzuhalten. Weil hier lediglich die geschaeftsrelevanten Gegebenheiten erfasst werden, laesst sich das konzeptionelle Modell in Verbindung mit verschiedenartigen Zielkonfigurationen verwirklichen. Die leichte Portierbarkeit haengt allerdings auch von einer aktuellen und fehlerfreien Versionsfuehrung und der Standortbestimmung mit der Komponente Kommunikation ab.

Das Prinzip der Trennung zwischen konzeptioneller und logischer Schicht einer Anwendung wird heute auch bei integrierten CASE- Werkzeugen wie IEF und ADW angewandt. Das geschieht hier mit dem Ziel, durch die Unterscheidung zwischen der Geschaeftslogik und den technischen Eigenschaften einer Anwendung eine hochgradige Portabilitaet zu erreichen.

Allerdings liefern diese Tools mit dem jeweiligen Vorgehensmodell keine Infrastruktur fuer die Kommunikation und erzeugen deshalb keine so flexiblen Anwendungen wie in der Objektorientierung.

In der logischen Schicht werden die einzelnen Komponenten der Objekte mit herkoemmlichen Datenbanken und Programmiersprachen in die jeweilige Systemsoftware umgesetzt.

Objektorientierte Sprachen sind keine Voraussetzung fuer

die Implementierung von objektorientierten Anwendungen. Bei der Umsetzung der Datenstruktur kann die erreichbare Portabilitaet weitgehend von den ausgewaehlten Datenbanksystemen abhaengen. Sie wird etwa bei DB2 und Oracle mit eigenen Eigenschaften zum Betrieb mit unterschiedlichen Plattformen und Datenverteilungs-Mechanismen unterstuetzt. Mit Hilfe der Datendimension kann jedoch durch ein Denormalisierungs- Verfahren ein performance- und sicherheitsgerechteres Datenbankdesign erstellt werden, so dass das Entity-Modell intakt bleibt.

In einem relativ stabilen Zustand bleibt auf Dauer auch die Fachlogik, denn sie bezieht sich in erster Linie auf das konzeptionelle Datenmodell. Davon unberuehrt bietet sich die Moeglichkeit an, zur Steigerung der Portabilitaet fuer die Umsetzung

der Fachlogik eine Programmiersprache einzusetzen, die sich fuer mehrere Plattformen eignet.

Mit Weiterentwicklungen ist auch beim Mechanismus fuer die Behandlung des Nachrichtenaustausches innerhalb der Anwendungen zu rechnen. Gegenwaertig muessen die Anwendungsentwickler Corba fuer die plattforminterne und -uebergreifende Kommunikation noch selbst erstellen.

Anwendungen fuer mehrere Zielumgebungen lassen sich auch mit integrierten CASE-Werkzeugen generieren, die damit nicht allein einen guenstigen Einfluss auf die Produktivitaet nehmen, sondern auch zur besseren Portabilitaet beitragen. Gegenwaertig sind diese Tools weitgehend auf die Hardware und Software unter monolithischen

Systemarchitekturen ausgerichtet, und es gibt erst wenige Erweiterungen fuer den Betrieb von Client-Server-Anwendungen.

Die Vorteile eines herkoemmlichen CASE-Werkzeugs koennen erst dann voll genutzt werden, wenn alle Anwendungen mit dem Tool erstellt worden sind. Fuer die meisten Betriebe ist jedoch eine Umstellung der Altanwendungen nur langfristig durchfuehrbar. Gefragt ist also eine Vorgehensweise, die eine schrittweise Ueberfuehrung der Anwendungen mit gleichzeitiger Ausnutzung der Vorteile von CASE und Objektorientierung fuer heterogene und verteilte Umgebungen ermoeglicht.

In einer Entwicklungsumgebung, die die Generierung von heterogenen und verteilten Anwendungen unterstuetzt, laesst sich auch das Ziel der Portabilitaet leichter erreichen. Eine wichtige Rolle faellt in einer solchen Umgebung der Verwaltung der Anwendungen zu. Ihre Qualitaet traegt massgeblich dazu bei, die Portabilitaet auf Dauer zu gewaehrleisten. In der Objektorientierung werden fuer die Verwaltung andersartige Instrumente als bei herkoemmlichen Entwicklungsmethoden benoetigt.

Steht das Objekt im Mittelpunkt, sind insbesondere Kataloge und Tabellen erforderlich, die Auskunft ueber die Objektarchitektur, die Versionen und Standorte der Anwendungen geben. Hinzu kommt die Erarbeitung und Einfuehrung von Datenintegritaetsregeln und Kommunikationsstandards.

Die meisten Anwendungsbetriebe messen der Frage nach der Entwicklungstechnik allerdings zunaechst sekundaere Bedeutung bei. Sie wollen in der Regel kurz- oder mittelfristig portable Loesungen zum Einsatz bringen koennen und geben wegen dieser Prioritaet mit wachsender Tendenz dem objektorientierten Ansatz den Vorzug. Die Verwendung von CASE-Werkzeugen kann zwar den Codierungsaufwand verringern, doch mit herkoemmlichen Paradigmen sind sie fuer objektorientierte Anwendungen nur eingeschraenkt einsetzbar. Dementsprechend scheint zur Zeit die Kombination zwischen Werkzeug und personell gestuetzter Anwendungsentwicklung der gangbare Weg zu sein.

Portabilitaet von Anwendungen stellt sich nicht von selbst ein. Sie muss sorgfaeltig geplant und realisiert werden. Wer die Investitionen in die Anwendungssoftware schuetzen will, sollte sich auf Vorgehensweisen besinnen, die von Anfang an auf Flexibilitaet und Stabilitaet der Programme abzielen.

Die Objektstruktur gewaehrleistet die Portabilitaet aller Teilbereiche.