10 Autonomie und Heterogenität

10.3 Die Rolle von Standards

Die gemeinsame Nutzung heterogener Rechnersysteme setzt zwingend den Einsatz von Standards voraus, um ein ausreichendes Maß an Interoperabilität zu erreichen. Unter Interoperabilität versteht man dabei allgemein die Kommunikations- und Kooperationsfähigkeit, so daß ein Programm eines Rechners, auf Programme oder Daten eines anderen Rechners zugreifen kann. Hierzu ist es erforderlich, daß die beteiligten Kommunikationspartner ein gemeinsames Protokoll verwenden, in dem die Formate und Reihenfolgen von Nachrichten sowie deren Bedeutung festgelegt sind. Eine weitere Zielsetzung von Standards ist die Definition einheitlicher Schnittstellen zur Unterstützung der Portabilität von Programmen (Übertragbarkeit auf unterschiedliche Hardware- bzw. Betriebssystem-Plattformen). Um eine weitestgehende Interoperabilität und Portabilität erreichen zu können, sollten die eingesetzten Protokolle und Schnittstellen von möglichst vielen Herstellern unterstützt werden. Systeme, welche solch allgemein akzeptierten und öffentlich zugänglichen Standards folgen, werden auch als "offene" Systeme bezeichnet [Se93][47].

Die Menge der Systemdienste zur Unterstützung von Interoperabilität und Portabilität in verteilten und heterogenen Umgebungen wird neuerdings oft als Middleware bezeichnet [Be93a]. Der Name resultiert daher, daß diese Dienste (Services) "in der Mitte" zwischen Anwendungen und Betriebssystem anzusiedeln sind (Abb. 10-2). Gegenüber Anwendungen bieten die Middleware-Services eine Reihe von Programmierschnittstellen oder APIs (Application Program Interfaces). Damit werden den Anwendungen mächtige Funktionen angeboten, die die darunterliegenden Plattformen (Hardware, Betriebssystem, Kommunikationsnetzwerk) vollständig verbergen und auch die Behandlung von Verteilung und Heterogenität vereinfachen. Zugleich wird bei Verwendung standardisierter APIs die Portabilität von Anwendungen unterstützt, d.h. ihre Lauffähigkeit auf unterschiedlichen Plattformen. Dies setzt voraus, daß die Middleware-Komponenten selbst auf verschiedenen Plattformen verfügbar sind und eine Interoperabilität zwischen ihnen unterstützt wird.

Abb. 10-2: Stellung von Middleware [Be93a]

Beispiele für Middleware sind u.a. DBVS, Präsentations-Services, Kommunikations-Services, Transaktions-Manager, Name-Service, Dateiverwaltung oder Authentisierungsdienst. Der Middleware zuzurechnen sind auch TP-Monitore, wobei diese meist mehrere Services bieten und auf eine bestimmte Anwendungsklasse, nämlich OLTP (Online Transaction Processing), zugeschnitten sind[48]. Ältere TP-Monitore realisierten sämtliche Funktionen selbst und nutzten ausschließlich plattformspezifische Funktionen des Betriebssystems (inklusive des Basiskommunikationssystems). Neuere Entwicklungen dagegen basieren selbst wiederum auf standardisierten Middleware-Services z.B. zur Kommunikation (Bsp. OSF DCE) oder Transaktionsverwaltung. Damit werden für diese TP-Monitore Portabilität sowie Realisierungsaufwand verbessert.

Die praktische Umsetzbarkeit des abstrakten Middleware-Konzepts wird derzeit v.a. dadurch beschränkt, daß zahlreiche Systemarchitekturen, Standards bzw. De-facto-Standards vorliegen, die oft nur teilweise miteinander verträglich sind bzw. gar miteinander konkurrieren. Die einzelnen Ansätze stammen von internationalen und nationalen Gremien und Vereinigungen (z.B. ISO, ANSI, DIN, IEEE, ECMA), Hersteller-Konsortien (X/Open, OSF, OMG etc.) sowie Firmen-Allianzen und Einzel-Herstellern. So haben viele größere Unternehmen eigene Middleware-Architekturen definiert, z.B. IBM mit SAA (Systems Application Architecture) und OE (Open Enterprise), DEC mit NAS (Network Application Support) oder Software AG mit ISA (Integrated Software Architecture), in die zum Teil bestehende Standards aufgenommen wurden und fehlende Teile durch eigene Komponenten und Schnittstellen-Definitionen ergänzt wurden.

Daß von Gremien wie der ISO verabschiedete Standards keineswegs immer herstellerspezifische Lösungen ablösen können, zeigt sich bezüglich der Kommunikationsarchitektur am Beispiel von OSI (Open Systems Interconnection). Dessen Verbreitung ist aufgrund der Marktdominanz von IBMs SNA sowie TCP/IP immer noch recht begrenzt. Die Folge davon ist u.a., daß in vielen Anwendungen weiterhin verschiedene Netzwerke und Kommunikationsprotokolle im Einsatz sind und zu ihrer Überbrückung Gateways eingesetzt werden müssen. Eine bessere Marktdurchdringung wurde von der ISO mit dem SQL-Standard erreicht, da sich dessen Definition eng an bestehenden Produkten orientierte. Dennoch weichen die meisten SQL-Implementierungen vom Standard ab, z.B. um zusätzliche Funktionen zu realisieren.

Große Bedeutung hinsichtlich der Standardisierung nimmt derzeit die Hersteller-Vereinigung X/Open ein, deren Ziel es ist, Industrie-Standards auf Basis allgemein akzeptierter Schnittstellen durchzusetzen. Die Definition einer einheitlichen Anwendungsumgebung (Common Application Environment, CAE) umfaßt APIs für einen Vielzahl von Diensten; die Festlegungen sind in einem "Portability Guide" zusammengestellt (derzeit X/Open Portability Guide 4, XPG4). Große Verbreitung erlangt haben auch die standardisierten Middleware-Dienste Motif (Benutzeroberfläche), DCE (Distributed Computing Environment) und DME (Distributed Management Environment) der OSF (Open Software Foundation) [Sc93]. So sind die DCE-Dienste wie Fernaufruf (Remote Procedure Call, RPC), Datendarstellungs-, Zeit- und Namensdienste u.a. bereits auf einer Vielzahl von Plattformen verfügbar und erleichtern damit Interoperabilität und Portabilität der nutzenden Software-Komponenten.

Wir können hier (Kap. 11) nur auf einige Standardisierungen eingehen, die im engeren Zusammenhang mit unserer Problemstellung stehen (X/Open DTP, MIA STDL, ISO RDA, ODBC, IBM DRDA). Einen guten Überblick über die sonstigen Standardisierungsaktivitäten bietet [Se93].

[47] "Offen" ist derzeit einer der am meisten gebrauchten und mißbrauchten Begriffe, für den es keine allgemein akzeptierte Definition gibt. Ähnliches gilt allerdings zum Teil auch für andere Schlagwörter, z.B. Interoperabilität oder Middleware.
[48] Solche spezialisierteren Middleware-Komponenten werden auch als Frameworks bezeichnet [Be93a].