Die DV-Welt der 90er Jahre wird beherrscht von Schlag worten: Graphical User Interface, Multimedia, Objektorientierung und Downsizing. Dieser Beitrag widmet sich dem Stichwort Downsizing. Darunter ist allerdings nicht die vollständige Ablösung der Mainframes zu verstehen. Downsizing heißt: verteilte Verarbeitung auf angepaßten Kapazitäten oder für jede Anwendung die richtige Leistung.
Verteilte Verarbeitung heißt aber auch koordiniertes Zusammenarbeiten der verteilten Programme: Distributed Computing in heterogenen Netzen. Damit ergibt sich der mögliche Migrationspfad von der zentralen Lösung zum angepaßten Rechnerverbund.
Ein sicherer DV-Betrieb bei hoher Verfügbarkeit wurde bisher häufig mit einer möglichst homogenen, meist proprietären Umgebung realisiert. Die Folge: Immense Kosten und Aufwand, um durch eine Umstellung ganzer, homogener Teile Technologieschübe nachvollziehen zu können.
Diesen Aufwand muß man jedoch vor dem Hintergrund der sehr kurzen Innovationszyklen betrachten: Der Lebenszyklus bei Hardwareprodukten liegt heute im Durchschnitt bei einem bis anderthalb Jahren. Will man als Anwender den Fortschritt auch in der Preis-Leistung-Relation nutzen, so muß man lernen, verteilte Verarbeitung in heterogenen Netzen zu beherrschen.
DCE der OSF als De-facto-Standard
Verteilte Verarbeitung in heterogenen Netzen impliziert eine Reihe von Vorteilen. Sie bietet den passenden Weg zum Downsizing und damit die Migration von der zentralen Lösung zum angepaßten Rechnerverbund. Sicher wird durch den Einsatz angepaßter Kapazitäten und den Einsatz neuer Technologien jetzt und in Zukunft eine dramatische Kostenreduktion möglich sein.
Andererseits ist es notwendig, die mit der verteilten Verarbeitung verbundenen Risiken zu beherrschen. Daten in einem Netzwerk behalten nicht automatisch ihre Konsistenz. Ein Netzwerk ist immer als Gesamtheit ein Multiuser-System. Anders als auf einem einzelnen PC müssen die Zugriffe auf Daten und Serverleistungen synchronisiert werden. Die Gewährleistung von Transaktionssicherheit gestaltet sich in einer verteilten Umgebung komplexer als auf einem Mainframe. Sicherheitsaspekte sind zu berücksichtigen.
Die Antwort der OSF und damit eines wesentlichen Teils der Hersteller und Softwarehäuser ist Distributed Computing Environment (DCE). Das Ziel der OSF mit DCE ist die Bereitstellung von Protokollen, Services und Tools für die verteilte Verarbeitung in heterogenen Netzen. Heute sind zum Beispiel homogene Unix-Netze mit vertretbarem Aufwand beherrschbar. ISO/OSI hat das Ziel, Standards zu definieren, die homogene Inseln dann miteinander verbinden. Doch ein Standardisierungsprozeß ist naturgemäß langsam, der Anspruch der universellen Gültigkeit hemmt.
Die OSF geht einen anderen Weg: Sie stellt Technologie als De-facto-Standard bereit. Die große Unterstützung durch die Mitglieder und durch Dritte fördert deren Etablierung. OSF/Motif ist hier ein Paradebeispiel. In den 70er und 80er Jahren - und teilweise noch heute - wurde Software monolithisch realisiert.
Die Anwendungssoftware besteht aus einem riesigen, innen komplex verwobenen und damit nicht mehr teilbaren Block. Die Herauslösung der Datenbankfunktionalität sowie die Abtrennung der Softwarekomponenten für das User Interface (durch Maskengeneratoren, Laufzeitkomponenten oder Monitore bedingt) sorgte für die einzigen Lichtblicke. Sucht man jedoch in vorhandenen Anwendungen nach Sollbruchstellen für die Verteilung in einem Netz, so scheitert man meist an der monolithischen Struktur der eigentlichen Applikationssoftware. Um in Zukunft die Möglichkeit für die verteilte Verarbeitung zu schaffen, sind schon heute in der Software-Architektur Sollbruchstellen vorzusehen. Abbildung 1 zeigt das Prinzip einer solchen Architektur: Verteilung einer Anwendung auf Applikationskerne (Application objects), Abtrennung von User Interface und Präsentation von der Applikation. Diese oder ähnliche Architekturen sind die Voraussetzung für die Migration zu verteilter Verarbeitung in heterogenen, offenen Netzen. OSF/DCE bietet die Basis für Distributed Computing, die Voraussetzungen für die Migration zu verteilter Verarbeitung in heterogenen, offenen Netzen. OSF/DCE bietet die Basis für Distributed Computing, die Voraussetzungen müssen in der Anwendungssoftware selbst geschaffen werden.
Client-Server-Konzept als Software-Architektur
Grundelement des DCE ist der Remote Procedure Call, also der Aufruf von Programmteilen über Rechnergrenzen hinweg. Dieses Prinzip läßt sich leicht veranschaulichen. Bei der klassischen DV ruft ein Hauptprogramm ein Unterprogramm auf, übergibt dem Unterprogramm mit dem Aufruf einige Parameter und wartet auf die Ausführung des Unterprogramms.
Das Unterprogramm signalisiert seine Ausführung durch die Rückgabe eines Returncodes und der Ergebnisse. Der Remote Procedure Call folgt exakt dem gleichen Prinzip. Dabei nennt man das Hauptprogramm Client, das Unterprogramm Server. Auch hier also wartet der Client auf die "Rückmeldung" des Servers.
Dieses Prinzip ist damit völlig unabhängig davon, auf welchem Rechner der Client und auf welchem anderen Rechner der Server abläuft Fälschlicherweise wird jedoch häufig bei dem Schlagwort Client-Server-Architektur angenommen, daß immer das Arbeitsplatz-System (der PC) der Client sei und ein größerer Rechner im Hintergrund der Server. Client-Server-Architektur hat im Sinne von DCE nichts mit Hardwarekonfiguration zu tun. Beispielsweise läuft im X-Window-System immer der X-Server auf dem Arbeitsplatz-System und der Client, die Applikation, auf dem meist größeren Rechner im Hintergrund. Was hat nun der Entwickler, wenn er Client-Server-Architekturen mit DCE realisiert, zu tun? Vereinfacht gesehen, spezifiziert er die Schnittstelle seines Remote Procedure Call in einer Interface Definition Language (IDL), den Rest erledigt DCE. DCE generiert auf der Interface Definition zwei Stubs, einen für den Client, einen für den Server RPC Runtime Services und Transport Services sorgen für die Verbindung zwischen Client und Server.
Das "Kernstück" von DCE, der Remote Procedure Call, wird unterstützt von einer Reihe von Services. Alle Services sind als verteilte Services realisiert, sie residieren also nicht auf einem "Master" im Netz, der bei einem Ausfall zum Flaschenhals würde.
Der Directory Service verwaltet den Global Namespace und die Cell Directories. Der Directory Service für den Global Name Space ist nach dem ISO/ OSI-Standard X.500 implementiert. Der Directory Service hält aktuelle Informationen zum Beispiel darüber bereit, welche Serverleistung auf welchem Rechner im Netz verfügbar ist. Der Client ist damit nicht auf die Serverleistung eines bestimmten Rechners fixiert, sondern ruft die Serverleistung dort ab, wo sie im Netz verfügbar Ist.
Der Time Service erledigt die Synchronisation der verschiedenen Uhren im Netz. Er sorgt für exakte Zeit im Netz und ermöglicht den Anschluß externer Zeitgeber wie zum Beispiel DCF77.
Cache Manager steigert die Performance
Über den Security Service können die Benutzer im Netz verwaltet werden. Er ermöglicht einen in mehreren Stufen abgesicherten Remote Procedure Call bis hin zur Verschlüsselung. Der Security Service in DCE basiert auf Kerberos V5 vom MIT und Passwdetc von HP. Die Verschlüsselung erfolgt nach dem Data Encryption Standard.
Zum Umfang von DCE gehört auch ein Distributed File System, welches die Verteilung von Filesystemen auf mehrere Server ermöglicht. Dabei sind die Netzwerkschichten für die Applikationen unsichtbar. Der Zugriff auf eine Datei erfolgt transparent und unabhängig vom Speicherort. Dieser Service unterstützt auch diskless Workstations.
Die Performance wird durch einen Cache Manager im Client optimiert. Das Distributed File System ist kompatibel zum NFS Server. Es basiert auf Technologien von Transarc.
Ursprünglich war ein PC Integration Service in DCE vorgesehen, der lediglich Dienste für den Dateizugriff und das Drucken vorsah und die Protokolle NFS und SMB (LAN Manager) unterstützte. Inzwischen wurde jedoch von Gradient Technologies eine DCE-Implementierung für DOS für Anfang 1992 angekündigt. Damit sind PCs vollwertig in eine Client-Server-Architektur mit DCE integrierbar.
Die Technologie der Threads ermöglicht Parallelität innerhalb der Serverprozesse, das heißt, ein Server kann mehrere Clients gleichzeitig bedienen. Threads sind nicht konzeptioneller Bestandteil von DCE. Mit DCE wird jedoch eine Threads Implementierung mitgeliefert für den Fall, daß Threads nicht schon in der verwendeten Betriebssystem-Version, etwa in OSF/1, implementiert sind. Threads in DCE gehorchen dem Posix-Standard 1003.4A, Draft 4.
Die Ankündigung von DCE erfolgte im Mai 1990. Ende dieses Jahres liefert die OSF die Version 1.0 von DCE. Bisher existieren Snapshots dieser Version, die an die Mitglieder der OSF ausgegeben werden. Die Freigabe der Version 1.0 bedeutet die Verfügbarkeit von DCE auf OSF/1 und auf dem AIX der RS/6000 sowie die Verfügbarkeit des Quellcodes für die Portierungen durch die Hersteller auf ihre eigenen Plattformen. Man rechnet mit DCE Produkten für weitere Plattformen zirka Mitte 1992.
Viele Hersteller haben DCE-Implementierungen auch auf ihren proprietären Plattformen (IBM, Digital, SNI, HP, Bull, Stratur, NCR, Hitachi, Microsoft, SCO, Banyan und andere). Damit wird DCE zum Migrations-Tool von zentralen, proprietären Lösungen zu verteilen, offenen Lösungen in Client-Server-Architektur.
DCE ist heute noch nicht verfügbar
DCE ist eine Basistechnologie für die verteilte Verarbeitung in heterogenen Netzwerken. Dabei wurde sehr schnell deutlich, daß für die Praxis vor allem das Netzwerk-Management in heterogenen Netzwerken noch fehlt. Darauf hat die OSF mit der Ankündigung der Distributes Management Environment (DME) reagiert. DME liefert dem Betreiber eines heterogenen Netzwerks die notwendigen Applikationen bis hin zur Softwareverteilung im Netz.
DCE ist heute noch nicht für den Anwender verfügbar. Das ist Jedoch kein Grund für den Anwender zu warten. Erfahrungen mit Remote-Procedure-Call-Mechanismen gibt es ausreichend, zum Beispiel auf der Basis des RPC von Sun. Und diese Erfahrungen machen Mut zur Client-Server-Architektur. DCE jedoch verspricht Client-Server-Architekturen in heterogene Netze. Damit öffnet sich der Migrationspfad aus der heutigen, häufig proprietär gebundenen Welt in die offene Welt der verteilten Verarbeitung ohne das Mammutprojekt einer Totalumstellung.
Schon heute sollte jede Neuimplementierung von Anwendungen ausreichend viele Sollbruchstellen für eine spätere Verteilung der Applikation vorsehen .
Eine Anwendung, die in diesem Sinne nicht sauber auf eine Verteilung vorbereitet ist, läßt sich in Zukunft auch nicht verteilen. Der Anwender hat heute also die Aufgabe, noch nicht sofort DCE zu implementieren sondern Software-Architekturen zu planen und zu implementieren, die später nach der Integration von DCE verteilbar sind.