Flexible Unterstützung von Dienstauswahl und -nutzung in verteilten Systemen

Michael Merz

Universität Hamburg, Fachbereich Informatik

Vogt-Kölln-Straße 30, 22527 HAMBURG

Hintergrund

Einführung und Verbreitung neuartiger Netzwerktechnologien gewährleisten nicht nur schnelle und zuverlässige Datenübertragung, sondern ermöglichen auch eine effiziente Nutzung von entfernten Diensten in offenen verteilten Umgebungen. Dadurch entsteht auch im Bereich der Kooperation verteilter Rechner ein offener Markt von Diensten. Hier stellen einenerseits Diensterbringer (Server) dedizierte Dienste über wohldefinierte Schnittstellen einer Vielzahl von externen Anwendungen zur Verfügung - andererseits haben Dienstnehmer (Clients) damit prinzipiell die Möglichkeit, aus einer Vielzahl verschiedenartiger Dienste eine Auswahl zu treffen und diese dann lokal zu nutzen.

Entsprechend wandelt sich auch die Koordination der (verteilten) Software-Produktion immer mehr von einer rein projektorientierten Auftragsvergabe an Subkontraktoren hin zur Nutzung eines globalen Marktes von bereits existierenden Diensten mit einer hinreichen großen Anzahl an Komponentenanbietern und -nachfragern. So bieten viele Software-Anbieter oft stark spezialisierte Software-Komponenten an, deren Einbindung in größere Anwendungen aufgrund gemeinsam vereinbarter Absprachen (z.B. bzgl. Benutzerschnittstellen, EDI-Standards, Datenbankschnittstellen, etc.) nur geringe Kosten verursacht. Dadurch wird auch der verteilte Software-Entwicklungsprozeß immer weniger zentral koordiniert sondern zunehmend zu einem Komponentenmarkt. Andererseits spiegelt sich hier ebenfalls die Anforderungsvielfalt von Entwicklungsprojekten in einer hohen Heterogenität der angebotenen Komponentenfunktionalität wider. Dieser potentiellen Vielfalt mit Hilfe von ('de jure'- bzw. 'de facto'-) Standardisierung von Schnittstellen zu begegnen, ist nur bis zu einem gewissen Grade möglich. Je weiter nämlich insbesondere innovative - also zunächst nicht standardisierte - Softwarekomponenten Teil der Anwendungssphäre sind, desto weniger einheitliche Vereinbarungen sind zwischen Schnittstellenangeboten möglich; aus Wettbewerbsgründen ist oft in diesem Bereich ist sogar eine gewisse Individualität von Schnittstellentypen (Syntax) und Funktionalität (Semantik) gefordert.

Ziele des Beitrages

Die oben geschilderten, marktmäßig nutzbaren Dienste können auf der einen Seite in eine Menge von bereits bekannten (klassifizierten oder standardisierten), auf der anderen Seite eine Menge von neuartigen, noch unbekannten (unklassifizierten) unterschieden werden. Der vorliegende Beitrag hat zum Ziel, das Potential aktuell diskutierter Infrastruktur-Architekturen insbesondere zur Unterstützung des Zugriffs auf neuartige, unklassifzierte Dienste in offenen verteilten Umgebungen (d.h. die dynamische Vermittlung semantisch heterogener Dienste zur Laufzeit) zu vergleichen. Unter diesem Gesichtspunkt sollen vor allem das "World-Wide-Web" (WWW), die Objektmodelle von "OMG CORBA", Microsoft's "OLE 2", des "ISO ODP-Traders" sowie schließlich die im Rahmen des Projektes COSM/TRADE entwickelte Architektur eines 'Common Open Service Markets' (COSM) verglichen werden.

Dienstvermittlung im 'Common Open Service Market' (COSM)

Im Projekt COSM steht die Unterstützung sogenannter unklassifizierter Dienste im Vordergrund, d.h. Dienste, die bezüglich ihrer Schnittstelle und Diensteigenschaften noch nicht durch ein normiertes Klassifikationsschema erfaßbar sind. Aus diesem Grunde ist hier der menschliche Benutzer interaktiv als urteilsfähige Instanz eng in den Dienstauswahl und -zugriffsprozeß eingebunden. Somit erfordern unklassifizierte Dienste auch spezifische Werkzeuge für den Benutzer zur Unterstützung der Dienstvermittlung und -interaktion. Diese Unterstützung besteht u.a. in einer generischen Repräsentation für Dienstbeschreibungen, welche um spezielle Beschreibungsaspekte erweitert werden können. Client-Anwendungen können diese Informationen nutzen, um dedizierte Informationen über entfernte Dienste zu erlangen und so den menschlichen Benutzer bei der Interaktion mit externen Diensten im verteilten Systemen unterstützen. Auf diese Weise wird die erforderliche Flexibilität beim Anbieten von Diensten oder bei deren Zugriff in dem Maße erhöht, wie es für einen offenen Dienstemarkt erforderlich ist. (Eine spätere Standardisierung von Dienstschnittstelle und -semantik ist hierbei nicht ausgeschlossen, sodaß dann COSM-Dienste auch z.B. mit Hilfe eines ODP-Traders - wie im Partnerprojektes TRADE realisiert - weitgehend automatisch vermittelt werden können.)

Architekturen zur Dienstvermittlung im Vergleich

Entwickler von Vermittlungsinfrastrukturen sind generell sowohl mit den Anforderungen klassifizierter als auch unklassifizierter Dienste in verteilten Umgebungen konfrontiert: Einerseits lassen standardisierte Komponenten (oder auch "Dienste") die konkrete Implementierung der Software in den Hintergrund treten, indem der Standard eine eindeutige Beschreibung von durch ihn spezifizierten Funktionalität zusichert; andererseits kann ein Vermittlungsdienst nicht standardisierte (unklassifizierte) Komponenten nur auf der Basis relativ hoher Abstraktion verwalten - z.B. als "Objekt". Um letztlich dennoch dem Benutzer in der Rolle des Software-Entwicklers oder des Anwenders Zugriff und Nutzung derartiger Objekte zu ermöglichen, ist eine Repräsentation der Schnittstellen- und Verhaltensspezifikation erst zur Laufzeit möglich und erforderlich. Bei der systemtechnischen Unterstützung des (statischen wie dynamischen) Zugriffs auf derartige Dienstschnittstellen in offenen Umgebungen ist damit ein Kontinuum verschiedener Spezialisierungsgrade von Client-Software denkbar (von ganz wenig bis hin zu sehr viel speziellem Wissen über den zugegriffenen Dienst), welches an den folgenden Beispielen näher erläutert werden sollen:

• In dem einen Extremfall verfügt der Benutzer lediglich über ganz vages Wissen bezüglich des erbrachten Dienstes (wie z.B. beim WWW), welches informell über online-Texte vermittelt wird. (Z.B. ein Browser für Hypertexte ist völlig unspezifisch bezüglich des durch ihn lesbaren Dokumentes - standardisiert ist lediglich die graphische Repräsentation von Hypertexten.) Nachteile liegen bei dieser Alternative vor allem in der mangelhaften (syntaktischen) Typsicherheit sowie in der irrtümlichen Nutzung des (semantisch) "falschen" Dienstes. Darüber hinaus kann ein Dienst (versehentlich oder absichtlich) eine beliebig unscharfe Selbstbeschreibung liefern.
• CORBA bietet hierbei zumindest die Möglichkeit, eine Definition der Dienstschnittstelle zur Laufzeit als Eintrag im Schnittstellen-Repository zur Verfügung zu stellen. Unter Verwendung der dynamischen Aufrufschnittstelle DII ist somit eine nutzende Komponente befähigt, typsichere entfernte Prozeduraufrufe durchzuführen. Nach wie vor bleibt jedoch eine Interpretation der Dienst-Semantik dem Benutzer überlassen, welcher als Software-Entwickler spezifischen Anwendungskode programmiert oder als Anwender über ein geeignetes interaktives Tool kommuniziert. Somit ist ein CORBA-Client zumndest zum Teil auf den genutzen Dienst spezialisiert.
• Einen weiteren Schritt in Richtung einer stärkeren Spezialisierung des Klienten stellt die Entwicklung des ODP-Traders dar. Hierbei wird der Kombination aus Dienstschnittstelle und -semantik ein dedizierter Diensttyp zu einem Konfigurationszeitpunkt verliehen (Klassifikation). Alle Server, welche dem gleichen Diensttyp angehören, sind somit ununterscheidbar, so daß für den Client Transparenz bezüglich des tatsächlich genutzen Diensterbringers besteht. Der Zwang zur vorherigen Konfiguration schränkt jedoch das Potential an Servern eines Diensttyps auf solche ein, welche an ihren konformen Schnittstellen exakt das gleiche Verhalten zeigen. Bei Servern unterschiedlicher Hersteller geht somit der Diensttypvergabe ein u.U. langfristiger Standardisierungsprozeß voraus, der sich kontraproduktiv bzgl. des Angebots solcher innovativen Dienste verhält. Dienstnutzer sind hierbei spezifisch bzgl. des nachgefragten Diensttyps.
• Den Gegenpol zum Dienst-unspezifischen WWW-Browser stellt in diesem Kontinuum die Herausgabe ausführbaren (Stub-)Kodes an den Nutzer dar (wie in üblichen RPC-Implementierungen vorzufinden): Dienstspezifischer Programmkode ist hierbei seitens des Clients erforderlich, um Operationen der Server-Anwendung sinnvoll nutzen zu können. Für ad-hoc-Benutzer ist hingegen Programmkode als Dienstbeschreibung ungeeignet, darüber hinaus ist eventuell der Transfer von Programmkode an den Dienstnutzer nicht gewünscht. {SONDZEICHEN 183 \f "Symbol" \s 10 \h} Das Projekt COSM schließlich unternimmt den Versuch, einen Bereich in diesem Kontinuum einzunehmen, in dem auf erweiterbare Weise der Schnittstellentyp und ein möglichst großer Teil der Semantik eines Dienstes spezifiziert werden kann. Hierbei sollte einerseits ein Diensterbringer nicht zuviel des durch seine Komponente gekapselten Know-hows als Kode herausgeben müssen, andererseits sollte jedoch Konformität zwischen Dienstbeschreibung und Dienstnutzung zugesichert werden können - z.B. durch Typsicherheit beim Prozeduraufruf und Software-gestützte Einhaltung einer Protokollspezifikation für die Dienstschnittstelle. Zusätzlich ist es Gruppen von Diensterbringern möglich, eine weitergehende Spezifikationen ihrer Dienstbeschreibung einzuführen, ohne daß hierauf nicht sensibilisierte Klienten von der Nutzung des Dienstes abgehalten werden ("Abwärtskompatibilität"), gleichzeitig jedoch sensibilisierte Nutzer auch solche Dienste verwenden können, welche diese Informationen nicht bereitstellen ("Aufwärtskompatibilität"). Dabei stellt der Subtyppolymorphismus das typtheoretische Analogon zur Abwärtskompatibilität dar: Er läßt bezüglich der angebotenen Dienstschnittstelle eine beliebige Verfeinerung des Schnittstellentyps zu, solange sich dieser in einem Subtypverhältnis zur nachgefragten Schnittstelle befindet. In bezug auf Schnittstellenbeschreibungen bedeutet dies eine eine individuelle Erweiterbarkeit der Dienstschnittstelle durch den Server. Auch auf derartige Konformitätsaspekte soll im Vortrag noch näher eingegangen werden.