Die Dienstrepräsentation

Aufgaben der Dienstrepräsentation

Komponenten der Dienstrepräsentation

In eine DR sind Daten zur Schnittstellenbeschreibung sowie deren Typdefinition eingebettet. Diese Typinformation ist für generische Komponenten innerhalb der verteilten COSM-Architektur erforderlich, um Daten der Schnittstellenbeschreibung typgerech interpretieren zu können. Ein Beispiel für eine derartig generische Anwendung ist das DR-Repository, welches a-priori über keine Information bzgl. der Semantik der in die DR eingebetteten Beschreibungskomponenten verfügt. Im Gegensatz zum Repository ist der generische Client bezüglich der DR eine spezifische Anwendung, da hier die notwendige Information zur Interpretation von DR gegeben ist. Im folgenden sollen daher zunächst die Schemaebene der DR erläutert und anschließend ein Beispiel für einen Druckdienst gegeben werden.
Alle in der Dienstrepräsentation eingebetteten Elemente werden im folgenden Komponenten genannt. Je nach Ebene werden Typkomponenten von Instanzkopmponenten unterschieden.
Beispiel: Die Typkomponente "Parameter" legt die Struktur aller Instanzkomponenten fest, welche dem Typ "Parameter" angehören. Die Instanzkomponente <"Document", COSM_MODE_IN, > spezifiziert einen bestimmten Parameterwert, auf den über die Atrributkomponente zugegriffen wird.

Das COSM-Schema von Dienstrepräsentationen

In der aktuellen Version des generischen Client werden Informationen über folgende Aspekte einer Dienstschnittstelle benötigt (cosmtyps.h):
  • Signatur der Dienstschnittstelle
    • Der Komponententyp Operation enthält den Namen der beim Server aufzurufenden Operation, ein Flag für den Aufrufmodus (synchron/asynchron), einem Timeout-Wert (in Sekunden), einen Verweis auf das Resultat-Attribut sowie einen Verweis auf die Parameterliste. Parameter werden als Menge von Handles verwaltet. Zu beachten ist, daß der verwendete Operationsname mit dem Namen der entsprechenden Callback-Funktion beim Server übereinstimmt. Mehrere Operations-Komponenten können die gleichen Parameter-Komponenten in ihrer Parameter-Menge umfassen.
    • Parameterkomponenten setzen sich zusammen aus dem Parameternamen, ihrem Aufrufmodus sowie einem Verweis auf die Attributkomponente, welche den Parameterdatenwert referenziert. Bei Parametern ist darauf zu achten, daß die in der DR gewählten Namen mit jenen übereinstimmen, die beim DII zum Entnehmen von Werten aud der DII-Parameterliste verwendet werden.
      • Parameterwerte sind "C"-Datenwerte und -strukturen im Hauptspeicher des generischen Client. Um den Zugriff auf diese Datenwerte erfolgt eine Indirektion über Attributkomponenten, so daß je verwendetem Datenwert eine Attributkomponente erforderlich ist, welche seinen Typ und den Offset innerhalb der Datenstruktur, in der er sich befindet, festlegt.
      • Parametertypen entsprechen dem Datentyp, der in der referenzierten Attributkomponente verwendet wird.
Beispiel: Für eine Telefonbuchverwaltung sei der anwendungsspezifische Datentyp "Address" als Record mit den Elementen erforderlich. Die Referenz auf diese Instanzkomponente sei hAddress. Entsprechend werden drei Attributkomponenten definiert:
AttrN = {name="Name", hInst={hAddress}, hType={hStringType}, offs=0}
AttrA = {name="Age", hInst={hAddress}, hType={hIntType}, offs=30}
AttrC = {name="City", hInst={hAddress}, hType={hStringType}, offs=34}
  • Die GUI-Spezifikation umfaßt die Elemente Dialogbox, Editor und Buttons. Einzelne, typspezifische Ausprägungen von Editoren und Buttons werden durch das Element widgetType im Typ Ctrl festgelegt. Mögliche Ausprägungen dieses Elements sind in cosmall.h zu finden.
  • Die Dienstbeschreibung charakterisiert den Dienst durch eine global eindeutige Identifikation - den URL - sowie ein individuelles Logo. Hier findet Ihr eine nette Übersichtsgrafik zur den Komponenten der COSM-Architektur und eine schematische Darstellung der Dienstrepräsentation.

    Die Programmierschnittstelle "CCB" zum Definieren von Dienstrepräsentationen

    CCB-API

    Das Dynamic Invocation Interface (DII)

    Im Gegensatz zum Sun-RPC bzw. DCE-RPC, bei denen Typinformation über die Server-Schnittstelle zum Zeitpunkt der Kompilation als generierter C-Kode einfließt und es somit einem Client nicht mehr möglich ist, zur Laufzeit Typinformation aus dem generierten Kode abzuleiten, erlaubt das von der OMG spezifizierte DII, Typinformation zusammen mit den Parameterwerten des RPC zur Laufzeit zu übertragen. Als first-class-Objekte sind Typinformationen somit zur Laufzeit inspizierbar, eine Bindungen kann somit nicht zum Übersetzungszeitpunkt erfolgen, sondern erst später, beim Zugriff auf einen Dienst.
  • Grundsätzlich erlaubt das DII dem Anwendungsprogrammierer somit, dynamisch eine beliebige Parameterliste für einzelne entfernte Prozeduraufrufe zu erstellen sowie beliebige Resultatwerte nach der erfolgreichen Ausführung des RPCs entgegen zu nehmen.
    Client-seitig setzt bei der COSM-Architektur der generische Client auf die Client-Schnittstelle des DII auf. Der Entwickler von COSM-Anwendungen ist somit nur mit der Server-seitigen Schnittstelle involviert:

    Die Server-Programmierschnittstelle des Dynamic Invocation Interface (DII)

    C++-Klassen im DII

    DII-Klassenbaum

    Ein exemplarischer COSM-Server: "$COSMDIR/doc/cosmsvc.C"