10 Autonomie und Heterogenität
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.
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].