Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Objekte in verteilter Umgebung

Client-Server-Anwendungen erfordern angepaßte Methoden

06.11.1992

Um die Vorteile von Client-Server-Anwendungen auszuschöpfen, sind die klassischen Methoden der Software-Entwicklung wenig geeignet. Die Mechanismen der objektorientierten Modellierung führen hingegen zu einem Modell der Anwendung, das sich nahtlos in eine Client-Server-Architektutr einfügen läßt.

Mit dem Begriff der Client-Server-Anwendungen verbindet sich die Hoffnung auf preisgünstige und schnell realisierbare DV-Lösungen. Die Verlagerung einer Applikation auf eine Reihe von kleinen, leistungsfähigen Rechnern setzt jedoch eine sinnvolle Zerlegung in selbständige, miteinander kooperierende Bausteine voraus.

Mehrere vernetzte PCs oder Unix-Rechner einzusetzen bedeutet noch lange nicht, eine Client-Server-Architektur zu haben. Denn dabei handelt es sich um eine Software-, nicht nur eine Hardware-Architektur! Nur wenn eine Anwendung in mehrere zusammenwirkende Bausteine aufgeteilt ist, besteht überhaupt die Möglichkeit, seine Komponenten auf mehreren Rechnern ablaufen zu lassen.

Sinnvollerweise sollten die Anwendungsbaustein so verteilt sein, daß sie die Stärke des jeweiligen Rechners ausnutzen können. Die Dialogkomponente gehört folglich auf einen PC oder eine Workstation, die Datenhaltung auf einen größeren Unix-Rechner oder Mainframe und rechenintensive Prozesse auf einen Number Cruncher.

Eine sauber modularisierte Applikation kann jederzeit auch unverteilt auf einem Rechner ablaufen, eine monolithische aber läßt sich nachträglich nicht mehr verteilen. Deshalb ist es sinnvoll, jede neue Anwendung - unabhängig von der zunächst vorgesehenen Rechnerumgebung - auf der Grundlage einer Client-Server-Architektur zu strukturieren.

Was eine Client-Server-Architektur ausmacht, ist vor alle die Zusammenfassung von mehrfach benötigten Funktionen und Daten in einem Server und die Inanspruchnahme der vom Server bereitgestellten Dienstleistung durch Clients. Dazu bedarf es eines definierten Application Programming lnterface, kurz API.

Ursprünglich diente dieses Konstruktionsprinzip nur dazu, in lokalen Netzwerken einen transparenten Zugriff auf Ressourcen zu gewähren. Rudimentäre Betriebssystem-Funktionen wie das Dateisystem oder Druckfunktionen wurden dabei auf speziellen Servern (File-Server, Print-Server) zentralisiert und allen Client-Workstations zur Verfügung gestellt. Eine Erweiterung des Prinzips bedeutet die Zusammenfassung von höherwertigen Server-Funktionen, zum Beispiel von Datenbank- oder Kommunikationsfunktionen (Server-Datenbanken, Comunication-Server).

Die konsequente Fortsetzung der Grundidee führte zu einer Client-Server-Architektur, in der sich nicht nur einfache Dienste wie Dateisysteme, Datenbanken oder Kommunikationsfunktionen netzweit zugänglich machen, sondern auch Application-Server konstruieren lassen. Die unter diesem Begriff subsumierten Anwendungen definieren ihrerseits ein API, über das sie anderen Programmen spezielle Funktionen zugänglich machen (siehe Abbildung 1).

Die damit angestrebte Software-Architektur zielt vor allem auf Wiederverwendbarkeit ab. So stellt beispielsweise eine auf dieser Basis erstellte Buchhaltungsanwendung Funktionen zur Verfügung, damit andere Programme ihre Daten an die Buchhaltung übergeben können, aber auch, damit sich die Buchhaltungsdaten von anderen Anwendungen lesen und als Statistiken aufbereiten beziehungsweise damit sich buchhaltungsspezifische Funktionen in den Fremdapplikationen nutzen lassen.

Wird jede neue Anwendung nach diesem Muster erarbeitet und das Re-Design bestehender Software in diesem Sinn vorangetrieben, so entsteht - sukzessive - ein Baukasten aus Anwendungsteilen, die für die Erstellung neuer Systeme genutzt werden können. Die Devise heißt dann: "Montieren statt programmieren".

Wie aber läßt sich diese höhere Qualität der Software konkret erreichen? Die klassische Antwort auf eine solche Frage lautet: durch Software-Engineering. Allerdings stellt die Entwicklung verteilter Anwendungen nach dem Client-Server- Modell im Vergleich zur herkömmlichen Applikationentwicklung zusätzliche Anforderungen an die Methodenunterstützung. Die Grundidee der Client-Server- Architektur - Auslagerung von mehrfach benötigen Daten und

Funktionen mit definierter Schnittstelle zwecks Wiederverwendbarkeit - verlangt nämlich nach erweiterten, angepaßten Methoden.

Die klassischen Methoden wie Structured Analysis oder Entity-Relationship-Modellierung betrachten Daten und Funktionen weitgehend getrennt voneinander. Eine Zusammenfassung von fachlich verwandten Informationsobjekten mit Funktionen bleibt damit dem Zufall oder der Erfahrung des Analytikers überlassen. Weil eine Methodik zur Ableitung der in einem Server zu bündelnden Daten und Funktionen fehlt, wird eines der entscheidenden Ziele der Client-Server-Architektur, die Wiederverwendbarkeit, nicht erreicht.

Um den vom Downsizing erwarteten Nutzen zu realisieren, ist eine Methodik notwendig, die durch gemeinsame Betrachtung von Daten und Funktionen zur Bildung von abstrakten Datentypen führt (siehe Abbildung 2). Ein abstrakter Datentyp kapselt fachlich zusammenhängende Daten und Funktionen; der Zugriff auf die Datenstruktur ist also nur über definierte Schnittstellen-Funktionen möglich. Damit entsteht de facto ein Mini-Server mit einem eigenen API. Zur Realisierung einer Anwendung nach dem Client-Server-Modell werden die abstrakten Datentypen zu größeren Servern zusammengefaßt oder aber direkt als eigenständige Server implementiert.

Dieses Konzept deckt sich mit den Prinzipien der Objektorientierung. Die Einhaltung dieser Grundsätze führt ohne den üblichen Methodenbruch von den frühen Projektphasen zur Spezifikation von Objekten, die alle Eigenschaften der skizzierten abstrakten Datentypen besitzen und als Bausteine für den Client- oder den Server-Teil, einer Anwendung fungieren.

Für die Umsetzung ist aber nicht zwingenderweise eine objektorientierte Programmiersprache oder eine OO- Datenbank notwendig, sondern sie kann auch mit herkömmlichen Sprachen und DB-Systemen erfolgen. Eine geringfügige Modifikation des bestehenden Methodenkonzepts reicht. Als Gegenleistung erhält der Anwender die Möglichkeit, später zu einer bis in die Realisierung durchgängig objektorientierten Vorgehensweise zu migrieren. Mit der Datenmodell-Objekt Methode (DMO) existiert beispielsweise ein objektorientiertes Analyse- und Designverfahren, dessen Ausrichtung an den Ergebnistypen der herkömmlichen Methoden den Übergang von monolithischen Anwendungen zu Client-Server-Lösungen unterstützen soll. Nach dieser Methode wird zunächst - mit Hilfe der Entity-Relationship-Modellierung - ein normalisiertes Datenmodell gewonnen.

Anschließend lassen sich Objekte bilden, indem die lnformationen des Datenmodells um zugehörige Funktionen angereichert werden. Dazu zählen zum einen grundlegende Funktionen wie Erzeugen, Lesen, Ändern und Löschen, die nötig sind, um den statischen Informationsobjekten Leben einzuhauchen. Weitere Objektfunktionen lassen sich ermitteln, indem der Lebenszyklus von Informationsobjekten betrachtet wird.

Jede Instanz eines Informationsobjektes kann im Laufe ihres Lebenszyklus in mehreren Zuständen existieren, eine Rechnung zum Beispiel als verschickt, offen, angemahnt oder bezahlt. Das statische lnformationsobjekt aus dem Datenmodell kennt hier lediglich ein - ebenfalls statisches - Zustandsattribut.

Soll aus dem Informationsobjekt ein abstrakter Datentyp im Sinne der Client-Server-ldee werden, so sind Objektfunktionen erforderlich, die das Zustandsattribut aktualisieren und den Zustandsübergang herbeiführen, indem sie Objektfunktionen anderer Objekte benutzen.

Vereinfacht dargestellt, würde die Objektfunktion "Rechnung verschicken" zunächst mittels der Objektfunktion "Kunde lesen" des Objekts "Kunde" die Adresse des Geschäftspartners mit den Rechnungsdaten zusammenführen, dann den Postversand veranlassen und anschließend das Zustandsattribut der Rechnung auf "verschickt" setzen.

Abstraktion von heterogenen Architekturen

Dieses einfache Beispiel zeigt bereits, daß durch die Betrachtung von Geschäftsvorfällen nicht nur weitere Objektfunktionen gefunden und zugeordnet, sondern auch die erforderlichen Nachrichtenverbindungen zwischen den Objekten erkannt werden. Eine Anwendung muß eine definierte Menge von Ereignissen bearbeiten und die daran gekoppelten Reaktionen erzeugen.

Dazu wiederum ein Beispiel: Das Ereignis "Kunde unterschreibt Vertrag" führt dazu, daß die Objektfunktionen "Rechnung erzeugen", "Rechnung verschicken" und "Kunde lesen" die Reaktion "Anzahlung fakturieren" hervorrufen. Die Ermittlung von Nachrichtenverbindungen, die notwendig sind, um vorgegebene Abläufe zu generieren, führt zu weiteren Objektfunktionen, da eine von einem Objekt erhaltene Nachricht durch eine entsprechende Objektfunktion bearbeitet werden muß.

Auf diese Weise entstehen sukzessive die sogenannten Datenmodell-Objekte: Die Datenstruktur wird nach außen abgekapselt, die Objektfunktionen lassen sich mit Nachrichten anstoßen (siehe Abbildung 3).

In einer späteren Designphase sind diese Objekte dann um Präsentationsobjekte zu ergänzen, die die Inhalte von Datenmodell-Objekten auf diversen Medien wie Bildschirm oder Drucker darstellen. Die interaktive Benutzerschnittstelle läßt sich beispielsweise durch sogenannte Dialogobjekte realisieren. Sowohl auf der Datenmodell- wie auch auf der Präsentationsobjekte-Ebene kommen Steuerungsobjekte hinzu, die im ersten Fall fachliche Zusammenhänge repräsentieren - zum Beispiel Views auf das Datenmodell - und im zweiten Fall vordefinierte Abläufe zusammenfassen.

Das Ergebnis der objektorientierten Modellierung ist ein Baukasten von Objekten, aus denen sich Anwendungen für eine Client-Server-Architektur montieren lassen. Alle Objekte besitzen eine durch ihre Funktionen definierte Schnittstelle und kommunizieren untereinander über Nachrichten.

Der fachliche Kern der Anwendung, repräsentiert durch die Datenmodell-Objekte, ist von der zugrunde liegenden Hardware-Architektur unabhängig zu verwenden, indem beispielsweise die Realisierung von Nachrichtenverbindungen in Serviceobjekte verlagert und so die Basis für die Verteilung der Anwendungsbausteine auf unterschiedliche Rechner geschaffen wird (siehe Abbildung 4).

Um Client-Server-Anwendungen in heterogenen Netzen installieren zu können und dabei den transparenten netzweiten Zugriff auf alle Application Server zu gewährleisten, muß ein Weg zur Abstraktion von heterogenen Hardware-, DBMS- und Netzwerkarchitekturen gefunden werden. Dies geschieht durch neutrale Kommunikationsaufrufe wie den Remote-Procedure Call (RCP) und durch DBMS-unabhängige SQL-Befehle. Die grundlegenden Mechanismen der objektorientierten Modellierung - Klassenbildung, Vererbung und Kommunikation über Nachrichten - fördern diesen Abstraktionsprozeß.