-
Hintergrund der Erfindung
-
1. Gebiet der Erfindung
-
Die
vorliegende Erfindung betrifft ein Verfahren und eine Vorrichtung
zum Transportieren von Datenstrukturen, die in der Schnittstellendefinitionssprache
(Interface Definition Language) der Object Management Group beschrieben
sind, zwischen unterschiedlichen Plattformen. Insbesondere werden
bei der vorliegenden Erfindung Funktionen zur Beseitigung der Anordnung
von Datenstrukturen und zum Speichern der Datenstrukturen in einem
vorbestimmten Format zum Transport zu einer Datei oder zwischen
unterschiedlichen Plattformen verwendet.
-
2. Hintergrund
-
Beim
Rechnen mit verteilten Objekten werden die Konzepte des verteilten
Rechnens und des objektorientierten Rechnens kombiniert. Das verteilte
Rechnen umfaßt
zwei oder mehr Softwareteile, die sich Informationen miteinander
teilen. Diese beiden Softwareteile können auf demselben Computer
oder auf verschiedenen Computern, die an ein gemeinsames Netz angeschlossen
sind, laufen. Der größte Teil
des verteilten Rechnens basiert auf einem Client/Server-Modus. Beim
Client/Server-Modell werden hauptsächlich zwei Typen von Software
verwendet: Client-Software, mit der die Informationen oder Dienste
angefordert werden und Server-Software, mit der die Informationen
oder die Dienste bereitgestellt werden.
-
Das
objektorientierte Rechnen basiert auf dem Objektmodell, bei dem
Codeteile, die „Objekte" genannt werden – die gegenüber echten
Objekten in der realen Welt häufig
abstrahiert sind -, Daten beinhalten (die in der objektorientierten
Sprache „Attribute" genannt werden)
und Dienste mit Hilfe von Methoden bereitstellen (die auch als „Operationen" oder „Elementfunktionen" bekannt sind). Die
in einem Objekt enthaltenen Daten und Methoden können entweder „öffentlich" oder „privat" sein. Öffentliche
Daten können
durch jedes andere Objekt verändert
werden. Die meisten Daten sind jedoch privat und nur für Methoden,
die zum Ob jekt gehören,
zugänglich.
Typischerweise arbeiten die Methoden mit privaten im Objekt enthaltenen
Daten.
-
Eine
Sammlung ähnlicher
Objekte bildet eine Schnittstelle (oder „Klasse" in der C++-Sprache). Eine Schnittstelle bestimmt
die Methoden und Datentypen, die in allen Objekten der Schnittstelle
enthalten sind. Es werden dann Objekte basierend auf dieser Schnittstelle
generiert („instanziiert"). Jedes Objekt enthält für dieses
Objekt spezifische Daten. Jedes spezifische Objekt ist in einem
System mit verteilten Objekten durch ein eindeutiges Identifizierungsmerkmal,
das Objektreferenz genannt wird, identifiziert.
-
In
einem System mit verteilten Objekten sendet ein Client eine Anforderung
(oder „Objektaufruf"), die einen Hinweis
auf die Operation enthält,
die der Server ausführen
soll, die Objektreferenz und einen Mechanismus ab, um „Fehlerinformationen" (unerwartete Ereignisse)
bezüglich
des Erfolgs oder Fehlschlagens einer Anforderung zurückzugeben.
Der Server empfängt
die Anforderung und führt
die Anforderung falls möglich
aus und gibt die entsprechenden Fehlerinformationen zurück. Ein
Objektanforderungsvermittler (Object Request Broker) („ORB") stellt einen Kommunikationsnetzknoten
für alle
Objekte im System bereit, der die Anforderung zum Server weitergibt
und die Antwort zum Client zurückgebt.
-
Clientseitig
erledigt der ORB Anforderungen von Aufrufen von Methoden und die
dazu in Bezug stehende Auswahl von Servern und Methoden. Wenn eine
Anwendung eine Anforderung einer Methode zum ORB absendet, die auf
ein Objekt ausgeführt
werden soll, validiert der ORB die in der Anforderung enthaltenen Argumente
gegenüber
der Schnittstelle und sendet die Anforderung zum Server, der diese
startet, falls dies notwendig ist. Serverseitig empfängt der
ORB derartige Anforderungen, zerlegt die Argumente, bildet den Kontextstatus
in der erforderlichen Form, ruft den Methodenabwickler auf, ordnet
die Ausgabeargumente und gibt die Ergebnisse zum Client zurück, wodurch
der Objektaufruf abgeschlossen wird.
-
Sowohl
der Client als auch der Server müssen über Informationen über verfügbare Objekte
und Methoden, die ausgeführt
werden können,
verfügen.
Durch das Versteckthalten privater Daten („Einkapselung" in der objektorientierten
Sprache), muß der
Client nicht wissen, wie die Anforderung vom Server ausgeführt wird. Jedoch
müssen
sowohl der Client als auch der Server Zugang zu gemeinsamen Schnittstellendefinitionen
haben, um eine Kommunikation zwischen diesen zu ermöglichen.
Momentan ist die Standardsprache für das Rechnen mit verteilten
Objekten die Schnittstellendefinitionssprache der Object Management
Group.
-
Entwickler
für Systeme
mit verteilten Objekten definieren die verfügbaren Schnittstellen des Systems in
der IDL. Eine Schnittstelle umfaßt eine oder mehrere Operationen,
die auf Objekte dieser Schnittstelle ausgeführt werden können. Jede
Operation kann einen oder mehrere Parameter erhalten, wobei jeder
Parameter einen bestimmten Datentyp der IDL umfaßt.
-
Die
IDL umfaßt
mehrere Datentypen. Ganze Zahlen werden durch die Integerwertdatentypen
long und short, vorzeichenbehaftete (signed) und vorzeichenlose
(unsigned) Integerwertdatentypen dargestellt. Gleitkomma-Typen der
OMG IDL sind float und double. Der float-Typ gibt IEEE Gleitkommazahlen
mit einfacher Genauigkeit wieder, während der double-Typ IEEE Gleitkommazahlen
mit doppelter Genauigkeit wiedergibt. In der OMG IDL ist ein char-Datentyp definiert,
der Größen von
8 Bit umfaßt.
Der boolean-Datentyp wird verwendet, um Wahr/Falsch-Werte wiederzugeben.
Der „jeglicher"-Typ erlaubt die
Spezifizierung von Werten, die jeden OMG IDL Typ ausdrücken können. Komplexe
Typen, wie beispielsweise structures (Strukturen), unions (Varianten)
und templates (Schablonen) werden ebenso dargestellt.
-
Die
IDL ist für
eine Verwendung in Systemen mit verteilten Objekten, in welchen
die Common Object Request Broker Architecture („CORBA") der OMG implementiert ist, bestimmt.
In einem typischen CORBA-System sind Schnittstellendefinitionen
in einer in der IDL definierten Quelldatei geschrieben (die auch
als eine „Übersetzungseinheit" bezeichnet wird).
Die Quelldatei wird durch einen IDL-Compiler kompiliert, der die Quelldatei
auf eine bestimmte Programmiersprache abbildet. Der IDL-Compiler
erzeugt programmiersprachenspezifische Dateien, einschließlich von
Client-Stub-Dateien, Kopfdateien und Server-Skeleton-Dateien. Die
Client-Stub-Dateien werden dann kompiliert und mit Clientanwendungen
verknüpft
und werden zur Ausführung
von Anforderungen verwendet. Kopfdateien werden mit Client- und
Serveranwendungen verknüpft und
werden verwendet, um Datentypen zu definieren. Server-Skeleton-Dateien
werden mit Serveranwendungen verknüpft und werden dazu verwendet,
Clientoperationen auf Objekte (Anforderungen) für Methoden in einer Serverimplementierung
abzubilden.
-
Bei
der Durchführung
von Objektaufrufen werden Datenstrukturen von einem Computersystem
zu einem anderen transportiert (vom Client zum Server und vom Server
zum Client).
-
Derartige
Objektaufrufe können
zwischen identischen Systemen erfolgen, es ist jedoch wahrscheinlich,
daß sie
zwischen unterschiedlichen Plattformen, bei welchen verschiedene
Betriebssysteme, Programmiersprachen und Compiler verwendet werden,
erfolgen. Sobald die IDL-Quelldateien kompiliert und auf eine bestimmte
Programmiersprache abgebildet sind, ordnet jeder unabhängige Compileranbieter
die Datenstrukturen in einer speziellen Weise im Stapel 1 an. Dementsprechend
können
sowohl die Client- als auch die Serversysteme die Datenstrukturen
unterschiedlich anordnen. Darüber
hinaus können
sowohl die Clientsysteme als auch die Serversysteme Parameter in
einer Struktur unterschiedlich ausrichten. Falls die Client- und
Serveranwendung die jeweils andere Anordnungsmethode nicht verstehen,
wird die transportierte Datenstruktur entstellt und es treten Fehler
auf.
-
Zusätzlich kann
die vom Client und vom Server verwendete Hardware unterschiedlich
sein. Beispielsweise kann ein Computer eine CPU umfassen, die eine
so genannte „BIGendian" Integerwertdarstellung
erfordert, bei der das höchstwertige
Byte zuerst aufgelistet wird. Der andere Computer kann eine CPU
umfassen, die eine „LITTLEendian" Darstellung erfordert,
bei der das niedrigstwertige Byte zuerst aufgelistet ist. Zwischen diesen
beiden Maschinen können
Datenstrukturen nicht wirkungsvoll ohne die reziproke Kenntnis des
jeweiligen Systems weitergegeben werden.
-
Darüber hinaus
geht ein primäres
Ziel des objektorientierten Rechnens – die Verkapselung – verloren, falls
die Clients und Server detaillierte Kenntnisse voneinander haben
müssen.
Sowohl die Client- als auch die Serveranwendungen müssen detaillierte
Anordnungsfunktionen aufstellen, um die Kompatibilität während der Objektaufrufe
sicherzustellen. Diese zusätzliche
Codierungsarbeit macht das Rechnen mit verteilten Objekten wirkungslos.
-
Dementsprechend
besteht ein Bedarf für
ein Verfahren zum Konvertieren von in IDL definierten Datenstrukturen
in ein Plattform-unabhängiges
Format, so daß konvertierte
Datentypen wirksam zwischen unterschiedlichen Systemen transportiert
werden können.
-
Zusätzlich besteht
ein Bedarf für
ein Verfahren, mit dem der Umfang des Codes und die Bearbeitungszeit,
die für
die Client- und Serveranwendungen notwendig sind, um die Objektaufrufe
zu implementieren, reduziert werden.
-
Abriß der Erfindung
-
Die
vorliegende Erfindung ist auf Verfahren gerichtet, mit welchem in
IDL definierte Datenstrukturen in ein Plattform-unabhängiges Format
umgewandelt werden können,
so daß die
konvertierten Datenstrukturen über
ein Netz transportiert werden können.
Das Erfordernis der Reduzierung des Umfangs des Codes und der Abarbeitungszeit,
die für
die Client- und Serveranwendungen notwendig sind, wird ebenfalls
erfüllt.
Die Verfahren sind in den beigefügten
Ansprüchen
definiert.
-
Die
Verfahren werden durch die Client- und Serversysteme mit Aufrufen
zu Implementierungsbibliotheken ausgeführt. Die Implementierungsbibliotheken
(Implementation Libraries) umfassen allgemeine Funktionen, die sich
in einer Laufzeitbibliothek befinden. Durch Aufrufen allgemeiner
Funktionen können
die Client- und Serveranwendungen Objektaufrufe einfach, ohne spezielle
Kenntnis voneinander und ohne, daß zusätzlicher Code erforderlich
ist, ausführen.
-
Ein
umfassenderes Verständnis
der Verfahren sowie eine Realisierung zusätzlicher Vorteile und Eigenschaften
derselben eröffnet
sich dem Fachmann durch eine Betrachtung der folgenden detaillierten
Beschreibung der bevorzugten Ausführungsform. Es wird auf die
beigefügten
Zeichnungen Bezug genommen, die zunächst kurz beschrieben werden.
-
Kurzbeschreibung
der Zeichnungen
-
1 ist ein Diagramm einer
verteilten Rechenumgebung, bei der das Verfahren bzw. die Vorrichtung der
vorliegenden Erfindung verwendet wird.
-
2 ist ein Diagramm der Infrastruktur
der gemeinsamen Ausführungsumgebung.
-
3 ist ein Diagramm, das
die Kompilierung und Verknüpfung
bei einer herkömmlichen
IDL-Quelldatei zeigt.
-
4 ist ein Diagramm, das
die Kompilierung und Verküpfung
einer IDL-Quelldatei,
bei der das Verfahren der vorliegenden Erfindung verwendet wird,
zeigt.
-
5(a) und 5(b) zeigen eine in IDL definierte Datenstruktur,
eine generierte CIN-Beschreibung
und ein generiertes Array von op_tag-Strukturen.
-
6 ist ein Flußdiagramm,
das eine erste bevorzugte Ausführungsform
der Clientseite des Verfahrens der vorliegenden Erfindung beschreibt.
-
7 ist ein Flußdiagramm,
das eine erste Ausführungsform
der Serverseite des Verfahrens der vorliegenden Erfindung beschreibt.
-
8 ist ein Flußdiagramm,
das die Generierung eines CIN-Deskriptors für Basis- und Verbunddatentypen
zeigt.
-
9 ist ein Flußdiagramm,
das die Generierung eines CIN-Deskriptors für eine Operation zeigt.
-
10 ist ein Flußdiagramm,
das die Generierung eines CIN-Deskriptors für eine Schnittstelle zeigt.
-
11 ist ein Diagramm, das
eine PIF-Datenstruktur zeigt.
-
12 ist ein Diagramm, das
eine Datenstruktur eines Eintrags zeigt.
-
13 ist ein Diagramm, das
eine Datenstruktur einer Operation zeigt.
-
14 ist ein Diagramm, das
eine Datenstruktur einer Union zeigt.
-
Detaillierte
Beschreibung der bevorzugten Ausführungsform
-
I. Überblick über die Hardware
-
Im
Folgenden wird in Einzelheiten auf die bevorzugten Ausführungsformen
der Erfindung Bezug genommen, wobei Beispiele derselben in den begleitenden
Zeichnungen dargestellt sind. Immer wenn es möglich ist, werden dieselben
Bezugszeichen in allen Zeichnungen zur Bezugnahme auf dieselben
oder ähnliche Teile
verwendet.
-
Wie
in 1 veranschaulicht
ist, hat das Verfahren der vorliegenden Erfindung einen Aufbau zur
Verwendung in einer verteilten (Client/Server) Rechenumgebung 10.
Die Client- und Serversysteme sind durch Netzverbindungen 12,
wie beispielsweise Internetverbindungen oder Verbindungen eines
Lokalbereichsnetzwerkes (local area network) verbunden. Der Serverrechner 11 kommuniziert über einen
Bus des I/O-Kanals 20 mit einem zugeordneten Speicheruntersystem 13.
Das Serversystem 11 umfaßt eine CPU 15 und
einen Speicher 17 zum Speichern aktueller Statusinformationen
bezüglich
der Programmabarbeitung. Ein Teil des Speichers 17 ist
zur Speicherung der jeder Funktion des Programms, das momentan auf
dem Clientrechner abgearbeitet wird, zugeordneten Zustände und
Variablen bestimmt. Ähnlich
umfaßt
der Clientrechner 21 eine CPU 27 und einen zugeordneten
Speicher 23, eine Eingabe vorrichtung, wie beispielsweise
eine Tastatur 29 oder eine Maus 31 und eine Anzeigevorrichtung 42,
wie beispielsweise einen Videobildanzeigeterminal („VDT"). Die Client-CPU
kommuniziert über
einen Bus oder I/O-Kanal 40 mit einem Plattenspeicheruntersystem 33 und über einen
I/O-Kanal 41 mit der Tastatur 29, dem VDT 42 und
der Maus 31. Beide Rechner sind dazu geeignet, verschiedene
Medientypen einschließlich
von Floppydisks und CD-ROMS zu lesen.
-
Das
in 1 gezeigte Client-Server-Modell
ist lediglich eine Darstellung eines typischen Client-Server-Systems.
Im Kontext der vorliegenden Erfindung ist der „Client" eine Anwendung, welche Dienste anfordert,
während
der „Server" eine Anwendung ist,
die den angeforderten Dienst implementiert. Tatsächlich können sich sowohl die Client-
als auch die Serveranwendung in demselben Rechner und einer gemeinsamen Verkapselung
befinden, wie nachfolgend erläutert
wird. Die Client- und die Serveranwendung können sich ebenso in getrennten
Rechnern befinden, in welchen unterschiedliche Betriebssysteme verwendet
werden.
-
II. Verteilte Rechenumgebung
-
Das
Verfahren und die Vorrichtung der vorliegenden Erfindung können in
irgendeiner verteilten Rechenumgebung verwendet werden. Bei einer
bevorzugten Ausführungsform
wird die gemeinsame Ausführungsumgebung
(Common Execution Environment) („CEE"), welche eine Komponente der Tandem
Message Switching Facility („MSF") Architektur darstellt,
verwendet. Die CEE aktiviert und deaktiviert Objekte und wird dafür verwendet,
Nachrichten zwischen Client- und Serveranwendungen zu übergeben,
die in CEE-Verkapselungen geladen sind. Die CEE kann im Speicher
einer einzelnen Maschine gespeichert sein. Die CEE und die Client- und
Serveranwendungen können
jedoch auch in mehrere Maschinen, die über ein Netz verteilt sind,
wie in 1 gezeigt ist,
geladen sein. Die clientseitige CEE 75 ist im Clientspeicher 23 gespeichert.
Die serverseitige CEE 80 ist im Serverspeicher 17 gespeichert.
-
Die
CEE verwendet eine „Verkapselungs"-Infrastruktur. In
einer Verkapselung sind Speicherraum und ein Abarbeitungsdatenstrom
verkapselt. Eine Verkapselung kann in verschiedenen Systemen abhängig vom Betriebssystem
unterschiedlich implementiert sein. Beispielsweise kann bei bestimmten
Systemen eine Verkapselung als ein Prozeß implementiert sein. Bei anderen
Systemen kann die Verkapselung als ein Teilprozeß bzw. Thread implementiert
sein. Darüber
hinaus können
Client- und Serveranwendungen in verschiedenen Verkapselungen konfiguriert
sein, die sich in verschiedenen Maschinen befinden, wie in 1 gezeigt ist. Alternativ
können
die verschiedenen Verkapselungen so konfiguriert sein, wie in 2 gezeigt ist. 2a zeigt eine Clientanwendung 77,
die in eine einzelne Verkapselung 48 geladen ist. Eine
Serveranwendung 87 kann in eine getrennte Verkapselung 50 geladen
sein. Beide Verkapselungen sind jedoch in derselben Maschine 44 gespeichert.
Sowohl die Client- als auch die Serveranwendungen können auch
in eine einzige Verkapselung 49 in derselben Maschine 46 geladen
sein, wie in 2b gezeigt
ist. Wie oben erläutert,
wird das Verfahren der vorliegenden Erfindung für den Fall mehrerer Verkapselungen
und mehrerer Maschinen beschrieben. Demgemäß umfassen der Client 12 und
die Servermaschine 11 eine clientseitige CEE 75 und
eine serverseitige CEE 80, die in ihren jeweiligen Speicher
geladen sind.
-
3 zeigt eine CEE-Verkapselung 70,
die beispielsweise in einem Speicher 27 (nicht gezeigt)
eines Clientrechners enthalten ist, der die CEE 75 und
bestimmte Kern-CEE-Komponenten
und Implementierungen von Objekten beinhaltet, die in den Implementierungsbibliotheken 71 enthalten
sind. Die Implementierungsbibliotheken 71 umfassen die
Clientanwendung 77 (oder die Serveranwendung im Fall der
Serververkapselung) und Client-Stubs 79 (oder
Server-Stubs), die aus der IDL-Spezifizierung der Schnittstelle
des Objekts generiert sind, wie nachfolgend beschrieben wird. Die
Implementierungsbibliotheken 71 und die CEE 75 wechselwirken durch
Aufrufen von dynamisch zugänglichen
Routinen in Abwärtsrichtung,
die durch die CEE geliefert werden und durch Aufrufen von Routinen,
die in der Implementierungsbibliothek enthalten sind, in Aufwärtsrichtung. Die
CEE 75 kann auch Objektaufrufe 82 von anderen
Verkapselungen in derselben Maschine und Anforderungen 84 von
anderen CEEs empfangen. Die clientseitige CEE 75 und die
serverseitige CEE 80 können
unter Verwendung irgendeines bekannten Netzprotokolls miteinander
kommunizieren. Die CEEs der Clients und Server umfassen zahlreiche
Routinenbibliotheken, die von den Client- und Serveranwendungen in Abwärtsrichtung
aufgerufen werden können.
Die Presentation Conversion Utilities („PCU") 91 ist eine Routinenbibliothek,
die beim Verfahren der vorliegenden Erfindung verwendet wird.
-
Objekte,
die in einer CEE-Verkapselung implementiert sind, können konfiguriert
werden oder dynamisch sein. Die Einzelheiten der Implementierung
konfigurierter Objekte sind an einem Verwahrungsort (wie beispielsweise
dem MSF Warehouse 85) oder in Initialisierungsskripten
gespeichert. Unter der Annahme einer Anforderung einer speziellen
Objektreferenz, startet die CEE 75 die entsprechende Verkapselung
basierend auf diesen Konfigurationsdaten. Die Verkapselung verwendet
die Konfigurationsdaten, um zu bestimmen, welche Implementierungsbibliothek
geladen werden muß und
welche Objektinitialisierungsroutine aufgerufen werden muß. Die Objektinitialisierungsroutine
erzeugt dann das Objekt. Dynamische Objekte werden in derselben
Verkapselung dynamisch erzeugt und zerstört. Dynamische Objekte haben
keine an einem Verwahrungsort gespeicherte oder als Skript verfasste
Konfigurationsinformationen.
-
In
den folgenden Absätzen
wird eine Betrachtung auf der Systemebene davon gegeben, wie die
Implementierungsbibliotheken mit der CEE 75 wechselwirken.
Die CEE 75 implementiert Anforderungen zur Aktivierung
und Deaktivierung von Objekten in einer Verkapselung. Zusätzlich erleichtert
die CEE Objektaufrufe 82 zwischen Verkapselungen sowie
Anforderungen von anderen CEEs 84, wie oben erläutert ist.
Anforderungen zur Objektaktivierung treten auf, wenn ein Objektaufruf
von einer Client- oder Serveranwendung erfüllt werden muß. Um ein
Objekt zu aktivieren, lädt
die CEE 75 die entsprechende Implementierungsbibliothek
(falls sie nicht schon bereits geladen ist), welche die Methoden
des Objekts enthält,
und ruft dann eine konfigurierte Objektinitialisierungsroutine auf.
Die Initialisierungsroutine bestimmt, welche Schnittstelle die Implementierungsbibliotheken
unterstützen
und registriert die Einsprungspunkte der Methoden des Objekts, die
von der CEE zu einem späteren
Zeitpunkt aufgerufen werden sollen.
-
Wenn
die Client- und Serversysteme starten, lassen sowohl die clientseitigen
als auch serverseitigen CEEs ihre eigene Initialisierung ablaufen.
Diese Initialisierung teilt den CEEs der Clients und Server mit,
wo die verschiedenen Implementierungsbibliotheken angeordnet werden
sollen. Sobald sie durch die CEE angeordnet sind, werden die Initialisierungsroutinen
in den Client- und Serveranwendungen aufgerufen. Die in den Client-
und Serveranwendungen enthaltenen Initialisierungsroutinen müssen zuerst
alle für
die Anwendung erforderlichen spezifischen Initialisierungen ausführen. Als
nächstes
rufen sowohl die Client- als auch Serverinitialisierungsroutinen
eine Stubfunktion auf, die wiederum in Abwärtsrichtung eine CEE-Funktion aufruft
(die in der dynamischen Bibliothek enthalten ist, wie oben erläutert wurde),
die CEE_INTERFACE_CREATE genannt wird, um die Schnittstelle des
Objekts festzulegen. Eine Schnittstelle kann für jedes Objekt festgelegt werden. Die
Schnittstellenbeschreibung wird normalerweise aus einer IDL-Beschreibung
der Schnittstelle, wie nachfolgend erläutert wird, erzeugt. CEE_INTERFACE_CREATE
erzeugt eine Schnittstelle und gibt eine „Schnittstellenkennung" (interface handle)
zur neu generierten Schnittstelle zurück. Die Kennung ist ein eindeutiges
Identifizierungsmerkmal, das die Schnittstelle spezifiziert. Die
Serveranwendungsinitialisierungsroutine verwendet dann die Schnittstellenkennung,
um in Abwärtsrichtung
CEE_IMPLEMENTATION_CREATE aufzurufen. CEE_IMPLEMENTATION_CREATE
erzeugt eine Implementierungsbeschreibung, die von einem oder mehreren
Objekten verwendet werden kann. CEE_IMPLEMENTATION_CREATE gibt eine „Implementierungskennung" zurück, die
ein eindeutiges Identifizierungsmerkmal ist, das die Implementierung
für jede
Operation in der Schnittstelle festlegt. Schließlich verwendet die Serveranwendungsinitialisierungsroutine
die Implementierungskennung, um eine Stub-Funktion aufzurufen, die
in Abwärtsrichtung
CEE_SET_METHOD aufruft. CEE_SET_METHOD bestimmt die tatsächliche
Adresse bestimmter Methodenroutinen der Implementierung, die in
der Serveranwendung enthalten sind. Die CEE verfügt dann über ausreichende Informationen,
um Objektaufrufe in der Clientanwendung mit bestimmten Methoden
in der Serveranwendung zu verbinden.
-
III. Kompilieren und Verknüpfen von
IDL-Quelldateien
-
4 zeigt, wie IDL-Quelldateien
kompiliert und mit Client- und Serveranwendungen verknüpft werden,
bei welchen das Verfahren und die Vorrichtung der vorliegenden Erfindung
verwendet werden. Zuerst wird eine IDL-Quelldatei 101 vorbereitet,
die IDL-Schnittstellendefinitionen
enthält.
Ein IDL-Compiler kompiliert die Quelldatei 101. Der IDL-Compiler 103 analysiert
den Code 101 syntaktisch, um eine Pickled-IDL-Datei-(„PIF")-Zwischendatei 105 zur Speicherung
der ursprünglichen
Quelldatei zu produzieren. Ein Codegenerator 101 analysiert
dann die PIF-Datei syntaktisch. Die Erzeugung einer PIF-Datei wird
nachfolgend im Abschnitt VI. beschrieben. Vorzugsweise werden der
IDL-Compiler und der Codegenerator miteinander kombiniert, um einen
Code zu erzeugen. Der Codegenerator 111 erzeugt Dateien
in der Sprache der Client- und Serveranwendungen. Falls die Client-
und Serveranwendungen in unterschiedlichen Sprachen vorliegen, werden verschiedene
Codegeneratoren verwendet. Alternativ können der Codegenerator 111 und
der IDL-Compiler 103 in einer einzigen Anwendung kombiniert
sein, um einen sprachspezifischen Code zu erzeugen. Der Codegenerator 111 erzeugt
eine Client-Stub-Datei 79, die Client-Stub-Funktionen enthält und eine
Server-Stub-Datei 89, die Definitionen für Objektimplementierungen
enthält.
Die Client-Stub-Datei 79 und die Server-Stub-Datei 89 werden
mit für
die Programmiersprache spezifischen Compilern 121, 123 kompiliert,
um einen kompilierten Client-Stub-Objektcode und ein kompilierten
Server-Stub-Objektcode zu erzeugen. Ähnlich werden eine Clientan wendung 77 und
eine Serveranwendung 87 mit für die Programmiersprache spezifischen Compilern
kompiliert, um einen kompilierten Client-Anwendungsobjektcode und
einen kompilierten Server-Anwendungsobjektcode zu erzeugen. Die
Clientanwendung 77 und die Serveranwendung 87 umfassen
auch eine Kopfdatei 119, die durch den Codegenerator 111 erzeugt
wird. Die Kopfdatei 119 enthält allgemeine Definitionen
und Erläuterungen.
Schließlich
verknüpft
ein Sprachcompiler 121 den Client-Anwendungsobjektcode und
den Client-Stub-Objektcode,
um eine Implementierungsdatei 71 zu erzeugen. In ähnlicher
Weise verknüpft
ein zweiter Sprachcompiler 123 den Server-Anwendungsobjektcode
und den Server-Stub-Objektcode, um
eine weitere Implementierungsdatei 81 zu erzeugen.
-
Zusätzlich umfassen
die Kopfdatei 119, die Client-Stub-Datei 79 und
die Server-Stub-Datei 89 eine kompakte Version jeder in
IDL definierten Datenstruktur, die als Compact IDL Notation („CIN") bezeichnet wird. Die
CIN ist eine ASCII-Darstellung (oder eine auf anderen Zeichen basierende
Darstellung) einer IDL-Datenstruktur, in der eine spezielle Notation
verwendet wird. Der CIN-Deskriptor ist in der Kopfdatei 119 enthalten, die
sowohl in der Clientanwendung 77 als auch in der Serveranwendung 87 enthalten
ist. Der Deskriptor ist ebenfalls in den Client- und Server-Stub-Dateien
enthalten. Da sowohl die Client- als auch Serveranwendungen 77, 87 auf
die CIN zugreifen können,
kann die allgemeine Funktionalität,
die durch die PCU-Bibliothek 91 gewährleistet wird, von verschiedenen
Kommunikationsteilnehmern verwendet werden. Die Erzeugung der CIN
durch den Codegenerator wird nachfolgend im Abschnitt V. beschrieben.
-
IV. Der Transport von
Datenstrukturen
-
Im
folgenden wird das Verfahren der vorliegenden Erfindung beschrieben.
Das Verfahren und die Vorrichtung gemäß der vorliegenden Erfindung
sind durch Verwenden einer Gruppe allgemeiner Funktionen oder Routinen 130,
die den Client- und Serveranwendungen mit Laufzeit zur Verfügung stehen,
implementiert. Diese Routinen sollen in Verbindung mit ursprünglich in
IDL dargestellten Datenstrukturen verwendet werden. Die hauptsächlichen
Routinen sind PCU_PREPARE, PCU_PACK und PCU_UNPACK.
-
Eine
IDL-Quelldatei kann zahlreiche Typdefinitionen für verschiedene Datenstrukturen
enthalten. Wenn die Quelldatei kompiliert und in die Client- und
Serveranwendungen verknüpft
wird, werden die Datenstrukturen von den Client- und Serveranwendungen
verwendet, um Objektaufrufe auszuführen. Eine Clientanwendung
kann erfordern, daß eine
Operation auf ein Objekt unter Verwendung von Daten, die in einer
bestimmten Datenstruktur enthalten sind, ausgeführt wird. Die in dieser Datenstruktur
enthaltenen Daten werden während
des Objektaufrufs zur Serveranwendung transportiert. Die Serveranwendung
muß die
Daten in der Datenstruktur richtig ausrichten, um die Operation
auf das Objekt tatsächlich
auszuführen.
-
Das
Verfahren der vorliegenden Erfindung vereinfacht den Transport von
in IDL definierten Datenstrükturen
zwischen verschiedenen bzw. heterogenen Systemen. 5a zeigt eine beispielhafte Datenstruktur 501,
die in IDL geschrieben ist. Die Struktur MyStruct, die in IDL geschrieben
ist, umfaßt
drei Komponenten: eine char-Datentypkomponente, eine long-Datentypkomponente
und eine boolean-Datentypkomponente. Diese Typdefinition ist, beispielsweise
zusammen mit Schnittstellendefinitionen, in einer IDL-Quelldatei 101 enthalten.
-
Ein
Codegenerator analysiert die IDL-Quelldatei syntaktisch und produziert
eine Kopfdatei, die eine CIN-Beschreibung 502 enthält. Der
CIN-Deskriptor enthält
eine Reihe von ASCII-Zeichen,
mit welchen die Struktur ohne eine Verwendung von Identifikationsmerkmalen
(wie beispielsweise dem Namen der Struktur) prägnant beschrieben ist. Bei
diesem Beispiel identifizieren die Zeichen b3 die Datenstruktur
als einen IDL-struct-Typ, der drei Elemente enthält. Das C kennzeichnet einen
IDL-char-Typ. Das F identifiziert einen IDL-long-Typ und B identifiziert
einen boolean-Datentyp.
-
PCU_PREPARE
konvertiert die CIN-Beschreibung eines Datentyps in eine „aufbereitete
CIN"-Form, die für eine Verwendung
mit Laufzeit zweckmäßiger ist
als die CIN-Beschreibung.
Vor einer Verwendung der Routinen PCU_PACK und PCU_UNPACK, muß die CIN-Beschreibung
jeder Datenstruktur, die in der Kopfdatei 119 enthalten
ist, die vom Codegenerator 111 erzeugt wurde, „aufbereitet" werden. PCU_PREPARE
wird einmal sowohl vom Client als auch vom Server aufgerufen. Da
der Aufruf relativ aufwendig ist, spart ein einziger Aufruf von
PCU_PREPARE während
der Initialisierung wertvolle Systemressourcen. Der Aufruf wird
vorzugsweise während
einer Initialisierungsroutine der Client- und Serveranwendung ausgeführt. PCU_PREPARE
ist in C definiert als:
-
-
-
In
dieser Funktion ist cinbuf ein Zeiger auf den Puffer, der die CIN-Beschreibung
der Datenstruktur enthält.
Der Parameter cinlen gibt die Größe der CIN
an. PCU_PREPARE gibt eine „aufbereitete
CIN" zurück, die an
der Adresse gespeichert wird, auf die durch prepbuf gezeigt wird.
Um eine maximale Länge
von prepbuf festzulegen, kann prepbufmaxlen auf einen bestimmten
Wert eingestellt werden. Die Funktion gibt prepbuf_len ebenfalls
zurück,
wodurch die Größe der aufbereiteten
CIN, die in prepbuf enthalten ist, bestimmt ist. Ein Wert von NULL
kann als dieser Parameter übergeben
werden, falls dieser Wert nicht erforderlich ist. Die tatsächliche
Zahl von Bytes, die von cinbuf gelesen wurden, werden im Parameter
*cin_used zurückgegeben.
Es kann auch NULL für
diesen Parameter verwendet werden, falls der Wert von *cin_used
nicht erforderlich ist.
-
PCU_PREPARE
wird verwendet, um eine aufbereitete CIN zu erzeugen, wobei es sich
um eine Tabelle von op_tag-Datenstrukturen handelt, welche den Datentyp,
den Offset, die Größe und die
Anordnung der mit der CIN beschriebenen Datenstruktur beschreibt.
PCU_PREPARE erzeugt diese op_tag-Strukturen, indem anfangs eine
ctx-Datenstruktur generiert wird, die verwendet wird, um Kontext
zu jeder internen Funktion in PCU_PREPARE weiterzugeben und davon
zu erhalten. Die Verwendung einer ctx-Struktur wird gegenüber einer
Weitergabe individueller Parameter zu den verschiedenen internen
Funktionen bevorzugt. Die ctx-Struktur ist in C wie folgt definiert:
-
-
-
Die
Felder der ctx-Struktur sind wie folgt: Der op-Zeiger zeigt auf
die momentane Operation in der aufbereiteten CIN. Dieser Zeiger
wird jedesmal inkrementiert, wenn PCU_PREPARE ein CIN-Element analysiert (wie
nachfolgend beschrieben wird). Der Zeiger op_end zeigt auf die letzte
mögliche
Operation in der aufbereiteten CIN plus eins. Der Zeiger cinptr
zeigt auf das nächste
Byte, das aus dem gesamten aufbereiteten CIN-String gelesen werden
soll. Der Zeiger cinend zeigt auf das letzte Byte plus eins des
aufbereiteten CIN-Strings. Die offset-, align-, und size-Felder
dieser ctx-Struktur sind Ausgabeparameter von process_cin_item (wie
nachfolgend erläutert
wird), die den Offset, die erforderliche Koordination und Größe des bearbeiteten
Feldes in der in CIN beschriebenen Datenstruktur festlegen. Ein
Laufzählwert
der Anzahl unbegrenzter Sequenzen und Strings, die im bearbeiteten
CIN-String vorgefunden
werden, ist in nr_unbounded enthalten. Ein Laufzählwert der Felder, in welchen
der IDL-Datentyp „jeglicher" verwendet wird,
ist im Feld nr_anys enthalten. Das Feld prev_branch zeigt auf eine
Union-Verzweigungsoperation, die zuvor bearbeitet wurde. Eine Liste
dieses Feldes wird verwendet, um eine Liste von Verzweigungsoperationen
aufzubauen, deren Kopf in der Haupt-Union-operation enthalten ist.
Auf die Union-Operation wird durch main_union gezeigt.
-
Sobald
die ctx-Struktur erzeugt ist, ruft PCU_PREPARE für jedes Zeichen im CIN-String PROCESS_CIN_ITEM,
TAKE_LONG für
jeden vorzeichenbehafteten (signed) long Integerwert im CIN-String und
TAKE_ULONG für
jeden vorzeichenlosen (unsigned) long Integerwert im CIN-String
auf. PROCESS_CIN_ITEM bearbeitet ein einzelnes Element im CIN-String. Die ctx-Struktur
wird zu PROCESS_CIN_ITEM weitergegeben. PROCESS_CIN_ITEM kann auf
viele Arten implementiert sein. Vorzugsweise verwendet die Funktion
eine „switch"-Anweisung aus der
C Sprache, die einen „case" für jedes mögliche Zeichen
in einem CIN-String enthält.
Zusätzlich
kann eine case-Anweisung verwendet werden, um sich selbst rekursiv
aufzurufen, um komplexe Strukturen, wie eine Folge von struct-Typen oder eine Union
aus Unionen zu behandeln.
-
TAKE_LONG
und TAKE_ULONG werden in Verbindung mit speziellen Datentypen verwendet,
auf die Zahlzeichen (die Anzahl der Arraydimensionen, etc.) folgen.
TAKE_LONG entnimmt einen vorzeichenbehafteten long Integerwert aus
dem CIN-Puffer und gibt den Wert an PCU_PREPARE zurück. TAKE_ULONG
entnimmt einen vorzeichenlosen long Integerwert aus dem CIN-Puffer
und gibt den Wert an PCU_PREPARE zurück. Diese Werte werden von
PCU_PREPARE verwendet, um die Tabelle der op_tag-Datenstrukturen
zu generieren.
-
PROCESS_CIN_ITEM
modifiziert die ctx-Datenstruktur bei jedem Aufruf. Zuerst inkrementiert PROCESS_CIN_ITEM
den Zeiger op, um sicherzustellen, daß die anderen Felder der Struktur
dem richtigen CIN-Element entsprechen. Zusätzlich werden die size-, align-
und offset-Felder der ctx-Struktur geändert. Die Anordnung jedes
Datentyps wird basierend auf den folgenden Koordinationsregeln bestimmt.
Basisdatentypen werden gemäß ihrer
Größe angeordnet.
Somit umfaßt
ein short-Datentyp eine Zwei-Byte-Anordnung, ein long-Datentyp eine
Vier-Byte-Anordnung, etc. Struct-Typen und Union-Typen haben dieselbe
Anordnung wie das enthaltene Feld mit der höchsten Anordnungsbedingung.
Trotzdem haben Struct- und Union-Typen vorzugsweise eine Anordnungsbedingung
von zumindest zwei Bytes. Schließlich werden Struct- und Union-Typen
vorzugsweise auf ein Vielfaches ihrer Anordnungsbedingung aufgefüllt.
-
Wenn
jeder Aufruf von PROCESS_CIN_ITEM erwidert ist, erzeugt PCU_PREPARE
basierend auf der modifizierten ctx-Struktur eine Datenstruktur
op_tag. Ein Feld dieser op_tag-Strukturen
wird dann im Puffer für aufbereitete
CINs prepbuf nach einem Aufruf von PCU_PREPARE gespeichert. Die
Struktur op_tag ist eine lineare Struktur, die einfach durch andere
Funktionen verarbeitet werden kann. Die Struktur op_tag ist wie
folgt definiert:
-
-
-
Der
Parameter type bezeichnet den IDL-Datentyp der Datenstruktur. Die
Typdefinition type_def ist eine Aufzählung aller möglichen
Datentypen. Der Parameter offset ist der Offset der Komponentendatenstruktur
gegenüber
dem Beginn der enthaltenden Struktur oder Union, falls die Datenstruktur
ein Teil einer Struktur oder Union ist. Die vom Datentyp geforderte
Anordnung (1, 2, 4 oder 8 Byte) wird durch den Parameter align bestimmt.
Der Parameter size gibt die Größe der Datenstruktur
in Bytes einschließlich
einer Rundung an. Der Parameter nr_elements wird für verschiedene
Zwecke verwendet. Für
ein Array gibt der Parameter die Gesamtzahl der Elemente für alle Dimensionen
an. Für
Sequenzen gibt der Parameter die maximale Zahl der Auftritte an.
Für Strings
bestimmt der Parameter die maximale Größe ausschließlich des
Null-Abschlusses. Für Strukturen
gibt er die Anzahl primärer
Felder in der Struktur an. Für
Unionen gibt er die Anzahl von Feldern in der Union an. Die Parameter
branch_label und is_default_branch werden nur für Verzweigungen von Unionen verwendet.
Der Parameter branch_label enthält
den case-Labelwert, der in der IDL-Spezifizierung der Union festgelegt
wurde, während
der Parameter is_default_branch wahr (true) ist, falls der Eintrag
die voreingestellte Verzweigung der Union beschreibt. Der is_simple-Parameter
ist ein boolean-Wert, der wahr ist, wenn die Datenstruktur ein IDL-Basisdatentyp
ist, und falsch (false) ist, falls die Datenstruktur ein Verbundtyp
ist. Der *next_branch-Parameter wird für Unionen und Verzweigungen
von Unionen verwendet und zeigt auf die Adresse des nächsten Verzweigungseintrags,
der zur Union gehört.
Im Fall eines Eintrags bei einer Union zeigt der Parameter auf die
erste Verzweigung. Für
die letzte Verzweigung enthält
der Parameter den Wert NULL. Der Parameter *union_end zeigt auf
die Adresse des nächsten
Eintrags, der auf den Abschluss der letzten Verzweigung folgt. Der
Parameter *sequence_end, der nur für Sequenzen verwendet wird,
zeigt auf die Adresse des nächsten
Eintrags, der auf den aufgereihten Typ folgt. Der Parameter *default_branch
zeigt auf die Adresse des voreingestellten Verzweigungseintrags.
Er wird verwendet, falls keine der Verzweigungen in der Verzweigungsliste
mit dem Union-Diskriminator zusammenpasst. Falls keine Voreinstellung
vorliegt, ist der Wert von default_branch NULL. Der Parameter reserve_XXX
lässt es
zu, daß Felder
zur op_tag-Struktur hinzugefügt
werden, ohne daß Fehler
in bestehenden Programmen hervorgerufen werden, bei welchen fälschlicherweise
die Größe der aufbereiteten
CIN angenommen wird.
-
5b zeigt das erzeugte Array
von op_tag-Strukturen für
den CIN-String 502. Die erste Struktur 520 spezifiziert
den Typ, den Offset, die Größe, die
Anordnung und Anzahl von Elementen der MyStruct-Struktur. Die nächsten drei
op_tag-Strukturen 530, 540, 550 enthalten
den Typ, den Offset, die Größe und die
Anordnung für
jedes Feld in der MyStruct-Struktur.
Dieses Feld von Strukturen wird in einem Puffer prepbuf gespeichert,
der von PCU_PACK und PCU_UPACK verwendet wird, um strukturierte
Daten über
eine Datei oder zu einem Netz zu senden.
-
Sobald
die Datenstruktur „aufbereitet" ist und das Feld
der op_tag-Strukturen in prepbuf gespeichert ist, können verschiedene
Nachrichten, die in dieser Datenstruktur gespeichert sind, in einen
Puffer gepackt werden, und unter Verwendung von PCU_PACK transportiert
werden. PCU_PACK wird dazu verwendet, einen strukturierten Datentyp
während
des Transports zu einer Datei oder durch das Netz in einen Ausgangspuffer zu
kopieren. PCU_PACK unterstützt
alle IDL-Konstrukte einschließlich
von Unionen, unbegrenzten Sequenzen/Strings und „jeglichen" Typen.
-
PCU_PACK
speichert die Komponenten eines strukturierten Datentyps in einem
Ausgabepuffer basierend auf einem festgelegten Format. PCU_PACK
ist in C definiert wie folgt:
-
-
Die
ersten drei Parameter legen fest, wie die Daten in den Ausgabepuffer
gepackt werden sollen. Diese Parameter können von rufenden Teilnehmern
definierte Funktionen sein, um die Konvertierung so durchzuführen, wie
sie von einem rufenden Teilnehmer vorgesehen ist. Der erste Parameter
dst_integer_fint legt das Format fest, das für short, long und long-Datentypen
im Ausgabepuffer verwendet werden soll. Beispiele möglicher
Werte für
dieses Format sind PCU_INTEGER_BIGENDIAN, womit eine Integerwert-Darstellung
festgelegt wird, bei der die Bytewertigkeit mit der zunehmenden
Adresse abnimmt, oder PCU_INTEGER_LITTLEENDIAN, womit eine Integerwert-Darstellung
festgelegt ist, bei der die Bytewertigkeit mit zunehmender Adresse
zunimmt. Der Parameter dst_real_fint_legt das Format fest, das für float-
und double-Datentypen im Ausgangspuffer verwendet werden soll. Beispiele
für diesen
Parameter sind PCU_REAL_IEEE, womit eine Gleitkommazahl-Darstellung bestimmt
ist, bei der das Standart-IEEE-Format verwendet wird, oder ein anbieterspezifischer
Wert, wie beispielsweise PCU_REAL_TI6, womit eine Gleitkommazahl-Darstellung unter
Verwendung des Tandem-T16-Formates festgelegt ist. Der dritte Parameter dst_char_fmt
legt das Format fest, das für
char- und string-Typen im Ausgabepuffer verwendet werden soll. Ein
möglicher
Wert für
diesen Parameter ist eine Zeichendarstellung unter Verwendung des
ISO Latin-1-Formats, einer Übergruppe
von ASCII. Ein anderer möglicher
Wert ist EBCDIC, wodurch eine Kompatibilität mit IBM-Hosts ermöglicht wird.
-
Der
Parameter *prepbuf ist, wie oben erläutert, ein Zeiger auf die Adresse,
die die aufbereitete CIN-Beschreibung, die von PCU_PREPARE zurückgegeben
wird, enthält.
Der Parameter *inbuf ist ein Zeiger auf die Adresse der strukturierten
Daten, die im Ausgangspuffer gespeichert werden sollen. Der Parameter
*outbuf ist ein Zeiger auf die Adresse des Ausgangpuffers, der die
tatsächlichen
gepackten Daten aufnimmt. Die maximale Anzahl von Bytes, die von
outbuf aufgenommen werden kann, ist im Parameter outbuf_max_len
enthalten. Die Anzahl von Bytes, die tatsächlich in outbuf geschrieben
ist, wird durch den Parameter outbuf_len wiedergegeben. Ein Wert
von NULL kann als dieser Parameter übergeben werden, falls die
Anzahl der Bytes nicht benötigt
wird. Falls PCU_SHORTOUTBUF von der Funktion zurückgegeben wird, erhält der Parameter outbuf_len
die erforderliche outbuf-Größe.
-
Entsprechend
kann PCU_PACK von der Client-Anwendung zweimal aufgerufen werden,
um dem Ausgabepuffer dynamisch Speicher zuzuweisen. Nach dem ersten
Aufruf, wird outbuf_max_len auf Null gesetzt. PCU_PACK gibt dann
PCU_SHORTBUF zurück
und outbuf_len enthält
die erforderliche Größe des Ausgabepuffers.
Der korrekte Speicherumfang kann dem Ausgabepuffer dann vor einem
zweiten Aufruf von PCU_PACK zugewiesen werden.
-
PCU_PACK
erzeugt am Anfang eine ctx-Struktur. Diese ctx-Struktur hat eine ähnliche
Funktion, wie der strukturierte Kontext, der von PROCESS_CIN_ITEM
verwendet wird. Die Struktur lässt
zu, daß Kontext
in großem
Umfang von PCU_PACK und den Routinen tieferer Ebene, die durch PCU_PACK_ENGINE
aufgerufen werden, geteilt wird. Diese ctx-Struktur wird von den
darunter liegenden Funktionen von PCU_PACK verwendet und ist wie
folgt definiert:
-
-
Das
angeforderte Bestimmungsortformat, das im Aufruf an PCU_PACK festgelegt
ist, wird zur ctx-Struktur weitergegeben. Diese drei Felder werden
in dem Fall benötigt,
daß PCU_PACK
rekursiv aufgerufen werden muß,
um einen „jeglicher"-Typ der IDL zu bearbeiten.
Der Zeiger outptr zeigt auf das nächste Byte, das in den Ausgabepuffer
geschrieben werden soll. Selbst in dem Fall, daß der Ausgabepuffer voll ist,
wird der Zeiger weiter aktualisiert. Dies ermöglicht, daß im Fall eines Überlaufs
die korrekte Größe an den
rufenden Teilnehmer zurückgegeben
werden kann. Der rufende Teilnehmer kann dann die Größe des Ausgabepuffers anpassen.
Der Zeiger outbuf end zeigt auf das letzte Byte plus eins im Ausgabepuffer.
-
PCU_PACK
ruft eine interne Funktion PCU_PACK_ENGINE auf. PCU_PACK_ENGINE
nimmt Zeiger auf Funktionen niederer Ebenen auf, die das eigentliche
Packen von Daten in den Ausgabepuffer durchführen. PCU_PACK nimmt auch einen
Zeiger auf prepbuf, einen Zeiger auf die Daten, die gepackt werden
sollen (enthalten in inbuf) und einen Zeiger auf die ctx-Struktur,
die von PCU_PACK erzeugt wird, auf. PCU_PACK_ENGINE geht Element
für Element
durch den Puffer prepbuf hindurch und ruft die entsprechende Funktion
einer niedri geren Ebene für
das Element basierend auf dem Typ des Elements (wie durch den in
der Struktur op_tag enthaltenen Typ spezifiziert wurde) und basierend
auf dem Parameter dst_XXX_fmt zu PCU_PACK auf. PCU_PACK_ENGINE liefert
die Adresse zum Eingangspuffer, der die strukturierten Daten enthält, den
Datentyp (über
ein CIN-Zeichen), die Adresse der ctx-Struktur und die Größe der Daten
im Eingangspuffer, die in den Ausgangspuffer gepackt werden sollen
(wie durch das Feld size der Struktur op_tag festgelegt ist).
-
PCU_PACK_ENGINE
ruft die entsprechende Funktion einer niedrigeren Ebene basierend
auf dem in der Datenstruktur op_tag enthaltenen Datentyp und der
Konversion, die im Aufruf zu PCU_PACK festgelegt ist, auf. Die Funktionen
niedrigerer Ebenen sind bekannt. Es handelt sich um Funktionen niedrigerer
Ebenen, die Daten entweder transparent packen oder eine festgelegte
Umwandlung ausführen
(z. B. BIGendian zu LITTLEendian). Jede von einem rufenden Teilnehmer
gelieferte Funktion nimmt Daten aus dem Eingangspuffer und platziert
sie in einem Ausgangspuffer. Die Anzahl der Bytes, die aus dem Eingangspuffer
genommen werden, ist durch den Größenparameter, der der Funktion
von PCU_PACK_ENGINE übergeben
wird, festgelegt. Sobald die Daten im Ausgabepuffer abgelegt wurden,
modifiziert die Funktion einer niedrigeren Ebene den Parameter outptr
der Struktur ctx, so daß er
auf das Byte zeigt, das auf das letzte in den Ausgabepuffer geschriebene
Byte folgt.
-
PCU_PACK_ENGINE
verwendet die verschiedenen Funktionen niedrigerer Ebenen, um Daten
im Ausgabepuffer wie folgt zu speichern. Die strukturierten Datentypen
im Eingangspuffer werden (Byte-ausgerichtet) im Ausgangspuffer in
derselben Reihenfolge, wie sie ursprünglich in IDL definiert wurden,
verdichtet gespeichert. Die Inhalte jeglicher Auffüllfelder,
die vom Codegenerator eingefügt
wurden, um eine korrekte Anordnung zu erhalten, werden gestrichen.
In gleicher Weise platzieren die Funktionen auch keine Voreinstellungswerte
in diesen Feldern.
-
Basistypdatenstrukturen
werden im Ausgabepuffer in der durch die Parameter dst_XXX_fmt festgelegten
Darstellung auf den Aufruf an PCU_PACK gespeichert. Typischerweise
werden diese Parameter ohne irgendeine Umwandlung in das systemspezifische
Format des Packers gesetzt. Somit führt die Serveranwendung (der
Entpacker) die tatsächliche
Umwandlung aus. Die bei der vorliegenden Erfindung verwendeten Routinen
erlauben es jedoch auch, daß der
Packer die Umwandlung der Datenstrukturen ausführt.
-
Die
Darstellung von shorts, vorzeichenlosen shorts, longs, vorzeichenlosen
longs, long longs und vorzeichenlosen long longs werden im Parameter
dst_real_fmt von PCU_PACK festgelegt. Dieser Parameter legt das
Format zur Darstellung von Gleitkommazahlen fest. Die Anordnungen
von floats und doubles werden durch den Parameter dst_real_fmt festgelegt.
Dieser Parameter entspricht dem Format zur Darstellung von Integerwerten.
Die Darstellung von chars ist durch den Parameter dst_char_fmt festgelegt.
Der Parameter dst_char_fmt legt ein Format zur Darstellung von Zeichen
fest. Boolean und octets werden nicht neu angeordnet. Der „jeglicher"-Typ wird als ein
vorzeichenloser long, der die Länge
der CIN-Beschreibung festlegt (deren Anordnung auf dem dst_integer_fmt-Parameter
basiert), als ein CIN-String, der den Typ beschreibt (ein nicht umgewandelter
ASCII-String), und als die Daten selbst gespeichert (die basierend
auf diesen Umwandlungsregeln gespeichert sind).
-
Verbundtypen,
wie beispielsweise Arrays und Unionen werden ebenfalls neu angeordnet.
Arrays werden ohne Auffüllungen
(paddings) zwischen den Elementen gespeichert. Sequenzen werden
als vorzeichenlose long Integerwerte gespeichert, die die Anzahl
von Auftritten angeben, gefolgt von dieser Anzahl von Auftritten.
Alle Auffüllungen
zwischen Auftritten werden entfernt. Das Format der long Integerwerte
hängt vom
Parameter dst_integer_fmt ab, wie oben erläutert wurde. Ein String wird
als ein vorzeichenloser long gespeichert, der die Länge des
Strings angibt, gefolgt von dieser speziellen Anzahl von Zeichen,
die als Chars gespeichert sind. Das Format der Chars ist durch den
Parameter dst_char_fmt bestimmt. Strukturen werden Feld für Feld ohne
Auffüllungen
gespeichert. Unions werden als ein Long gespeichert, worauf die
aktive Verzweigung der Union folgt.
-
Empfangsseitig
muß die
Serveranwendung den unstrukturierten Datentyp und seine Anhänge aus dem
Puffer, der unter Verwendung von PCU_PACK gepackt wurde, extrahieren.
PCU_UNPACK ordnet dann diese unstrukturierten Daten in einer Datenstruktur
basierend auf der aufbereiteten CIN für die Datenstruktur an. PCU_UNPACK
ist wie folgt definiert:
-
-
-
Die
ersten drei Parameter entsprechen den ersten drei Parametern von
PCU_UNPACK. Diese Parameter bestimmen das Format der Datentypen,
die im Eingangspuffer gespeichert sind. Diese Parameter sind vorzugsweise
identisch zu ihren PCU_PACK-Gegenstücken. Der Parameter *prepbuf
ist ein Zeiger auf die Adresse, welche die aufbereitete CIN-Beschreibung
enthält,
die von PCU_PREPARE zurückgegeben
wurde. *inbuf zeigt auf die Adresse des Eingangspuffers. Die Länge von
inbuf ist durch infub_len festgelegt. *outbuf zeigt auf die Adresse
des Ausgangspuffers. Die maximale Anzahl von Bytes, die von outbuf
untergebracht werden kann, ist durch outbuf_max_len festgelegt.
Der Parameter *outbuf_len erhält
die Anzahl von Bytes, die tatsächlich
in outbuf geschrieben wurde. Die aus dem Eingangspuffer gelesene
Bytezahl ist durch *inbuf_used festgelegt. Falls die Anzahl geschriebener
Bytes oder die Zahl gelesener Bytes nicht benötigt wird, kann NULL als der
Wert für
diese Parameter übergeben
werden.
-
PCU_UNPACK
erzeugt eine ctx-Struktur, die verwendet wird, um Kontext zu den
internen Funktionen von PCU_PACK weiterzugeben. Diese ctx-Struktur
wird von den PCU_UNPACK zugrunde liegenden Funktionen verwendet
und ist wie folgt definiert:
-
-
Die
ersten drei Parameter sind die an PCU_UNPACK übergebenen Formate. Diese Parameter
werden von den internen Funktionen benötigt, falls PCU_PACK rekursiv
aufgerufen wird, um einen „jeglicher"-Typ in IDL zu bearbeiten.
Der Zeiger inptr zeigt auf das nächste
Byte, das aus dem Eingangspuffer gelesen werden soll. Der Zeiger
inbuf end zeigt auf das letzte Byte plus eins im Eingangspuffer.
-
Nachdem
die Kontextstruktur generiert wurde, ruft PCU_UNPACK PCU_UNPACK_ENGINE
auf, welche die Funktionalität
von PCU_UNPACK liefert. PCU_UNPACK_ENGINE nimmt Zeiger auf von rufenden
Teilnehmern gelieferte Funktionen auf, um Daten aus dem Eingangspuffer
zu extrahieren (aus dem Ausgangspuffer, geliefert von PCU_PACK)
und um sie in einen Ausgangspuffer zu stellen. Der aufbereitete
CIN-Puffer wird ebenso als ein Parameter bereitgestellt. PCU_UNPACK_ENGINE
geht Element für
Element durch die aufbereitete CIN und speichert die Daten in einer
Datenstruktur, die durch die offset- und size-Felder der op_tag-Strukturen
bestimmt ist.
-
Für jedes
Element im aufbereiteten CIN-Puffer ruft PCU_UNPACK_ENGINE die entsprechende
nutzerspezifizierte Funktion auf tieferer Ebene auf, um das Entpacken
und Umwandeln durchzuführen. PCU_PACK_ENGINE übergibt
den Datentyp und die Größe der Daten,
die aus dem Eingangspuffer gelesen werden sollen, zusammen mit der
Adresse des Ausgangspuffers, um die Daten zu schreiben. PCU_UNPACK_ENGINE übergibt
die ctx-Datenstruktur
auch an jede Funktion. Jede durch einen rufenden Teilnehmer spezifizierte
Funktion extrahiert dann die Daten aus dem Eingangspuffer und platziert
die Daten in einer Datenstruktur. Die Anzahl der Bytes, die vom
Eingangspuffer in den Ausgangspuffer geschrieben werden soll, wird
durch den Größenparameter
bestimmt. Für
Verbund-Typen liefert PCU_UNPACK_ENGINE zusätzliche Parameter zu den durch
rufende Teilnehmer bereitgestellten Funktionen. Falls die Datenstruktur
ein Array ist, wird die Zahl der Elemente im Array geliefert. Falls
die Datenstruktur eine Sequenz ist, liefert PCU_UNPACK_ENGINE die
maximale Zahl der Elemente in der Sequenz zusammen mit der tatsächlichen Zahl
der Elemente. Falls die Datenstruktur ein String ist, werden die
maximale Größe und die
tatsächliche
Größe des Strings
an die durch rufende Teilnehmer gelieferten Funktionen übergeben.
Falls der Verbund-Typ ein Struct-Datentyp ist, wird die Anzahl der
Elemente der Struktur geliefert.
-
Nun
wird mit Bezugnahme auf 6 und 7 das Verfahren der vorliegenden
Erfindung beschrieben. 6 ist
ein Flußdiagramm
der Clientseite des Verfahrens der vorliegenden Erfindung. Vor der
Durchführung des
Verfahrens der vorliegenden Erfindung werden, wie oben erläutert wurde,
kompakte Beschreibungen der Datenstrukturen durch den Codegenerator 111 generiert
und in die Client- und Server-Stubs eingebunden. Diese Beschreibung
kann unter Verwendung des Verfahrens, das in der Anmeldung mit der
Nr. XXX beschrieben ist, generiert werden. Die Client- und Server-Stubs
werden kompiliert und mit den Client- und Serveranwendungen verknüpft. Sobald
die Client-Stubs in einem ersten Schritt 601 mit der Clientanwendung
verknüpft worden
sind, erzeugt die Clientanwendung eine aufbereitete CIN-Beschreibung durch
Aufrufen der Funktion PCU_PREPARE. PCU_PREPARE nimmt die CIN-Beschreibung
der Datenstruktur und wandelt im Schritt 603 die CIN in
ein Array von op_tag-Datenstrukturen durch Aufrufen von PROCESS_CIN_ITEM
für jedes
Element der CIN-Beschreibung um. Jede Struktur enthält Informationen
betreffend den Typ, den Offset, die Anordnung und die Größe der in
der CIN beschriebenen Datenstruktur. Eine Tabelle dieser Strukturen
wird dann in einem Speicherpuffer, der prepbuf genannt wird, im
Schritt 605 gespeichert.
-
Im
Schritt 607 ruft die Clientanwendung PCU_PACK auf, welche
die Datenstruktur durch Kopieren der Daten in einen Ausgangspuffer
basierend auf der Größe, die
durch das Größefeld jedes
op_tag bestimmt ist, packt. PCU_PACK entfernt alle Anordnungsauffüllungsfelder
aus der Datenstruktur und platziert die Datenstruktur im Schritt 609 in
einem Ausgangspuffer. Sobald die Datenstruktur in den Ausgangspuffer
gepackt wurde, werden die Daten im Schritt 611 transportiert.
Die Datenstruktur kann über
einen Draht zu einer Serveranwendung oder zu einer Datei, wie beispielsweise
einer Datei auf einer Platte transportiert werden. Falls eine andere
Anforderung, welche dieselbe Datenstruktur betrifft, ausgeführt wird,
wird diese Anforderung gepackt und die Clientanwendung wiederholt
die Schritte 605–611 für die neue
Anforderung. Die CIN-Beschreibung der Datenstruktur muß nicht
erneut „aufbereitet" werden.
-
7 zeigt die Serverseite
des Verfahrens der vorliegenden Erfindung. Die Serveranwendung ruft
im Schritt 701 PCU_PREPARE auf, um eine aufbereitete Beschreibung
der CIN zu erhalten. Der „Aufbereitungs"-Schritt ist ähnlich zum
oben beschriebenen Schritt 601. Der Server ruft dann im
Schritt 703 PCU_UNPACK auf, um einen strukturierten Datentyp
und alle Anhänge
desselben aus dem Puffer zu extrahieren, der unter Verwendung von
PCU_PACK gepackt wurde. Im Schritt 705 wird die Struktur
basierend auf den an die Funktion übergebenen Parametern entpackt
(dieselben Parameter, die an die PCU_PACK-Funktion übergeben
wurden). Während
die Datenstruktur extrahiert wird, wird die Struktur im Schritt 707 aus
dem im Eingangspuffer festgelegten Format des Servers in der systemspezifischen
Anordnung des Servers neu angeordnet. Falls eine weitere Anforderung
am Server ankommt, kann der Server PCU_UNPACK aufrufen, um die Anforderung
zu entpacken, ohne die Datenstruktur aufzubereiten.
-
V. Die kompakte IDL-Notation
-
8 ist ein Flußdiagramm,
das die Generierung eines CIN-Deskriptors aus einem IDL-Datentyp, der Operation
und der Schnittstelle, die in einer IDL-Quelldatei enthalten sind,
darstellt. Es ist verständlich,
daß die Schritte
der 8–10 mit einer CPU eines Datenverarbeitungssystems
implementiert werden können,
mit dem in einem Speicher gespeicherte Computerbefehle abgearbeitet
werden. Im Schritt 801 beginnt ein Codegenerator mit der
ersten Zeile einer IDL-Quelldatei und bestimmt die Datenstruktur,
die Schnittstellen oder die Operation, die in der Quelldatei beschrieben
sind. Falls die beschriebene Datenstruktur eine Schnittstelle ist,
folgt der Codegenerator den in 10 gezeigten
Anweisungen. Falls die geschriebene Datenstruktur eine Operation
in einer Schnittstelle ist, folgt der Generator den Anweisungen
in 9. Falls die Datenstruktur
ein Datentyp (oder ein Parameter für eine Operation, wie im Nachfolgenden
erläutert
ist) ist, erzeugt der Generator ein einzelnes Zeichen basierend
auf einer Definitionstabelle. Man beachte, daß andere Zeichen als die, die
in den hier umfassten Diagrammen gezeigt sind, verwendet werden
können.
Jedes Diagramm enthält
nur ein bevorzugtes ASCII-Zeichen. Das Diagramm A zeigt eine bevorzugte
Definitionstabelle, die die Zeichenstrings umfaßt, die verwendet werden, um
die verschiedenen IDL-Basistypen zu bezeichnen.
-
-
-
Wie
im Diagramm A gezeigt ist, werden einfache Zeichenstrings verwendet,
um Basistypen in einem CIN-Deskriptor darzustellen.
-
Falls
der Datentyp ein zusammengesetzter Typ bzw. Verbundtyp ist, wie
beispielsweise ein Array oder eine Struktur (Struct-Typ) folgt eine
Reihe unterschiedlicher Schritte. Im Schritt 811 wird ein
Zeichen generiert, das den Beginn des zusammengesetzten Typs anzeigt.
Das Diagramm B zeigt eine Mustertabelle, die die Zeichenstrings
beinhaltet, die verwendet werden, um den Beginn verschiedener zusammengesetzter
IDL-Typen zu bezeichnen.
-
-
Die
spezielle Darstellung jedes zusammengesetzten Typs wird entsprechend
dem Typ unterschiedlich behandelt.
-
In
der IDL sind mehrdimensionale Arrays mit fester Größe für jeden
Basistyp definiert. Die Arraygröße ist zur
Kompilierungszeit festgelegt. Arrays werden in CIN wie folgt dargestellt:
a
nr_dimensions size_1. [size_2, ... size_n] base type
-
Die
Erzeugung von Zeichen für
das Array ist in den Schritten 813, 815, und 817 gezeigt.
In dieser Arraydarstellung stellt das Zeichen a den Beginn des Arrays
dar (wie im Diagramm B gezeigt ist). Das Zeichen nr_dimensions ist
ein Zeichen, das die Anzahl der Dimensionen im Array angibt. Die
Zeichen size_1, size_2, size n geben die Größe des Arrays in der ersten, zweiten
bzw. n-ten Dimension des Arrays an. Base-type ist der Deskriptor
für jedes
Element des Arrays. Die Darstellung der verschiedenen Basistypen
ist aus der ursprünglichen
Basistyptabelle, die im Diagramm A gezeigt ist, abgeleitet.
-
In
der IDL sind benutzerdefinierte Struct-Typen definiert. Jedes Struct
wird aus einem oder mehreren Feldern von Basis- oder Verbund-Datentypen
gebildet. Structs sind in der CIN wie folgt dargestellt:
b
nr_fields field_1 [field_2 ... field_n]
-
Die
Erzeugung von Zeichen, um ein Struct zu beschreiben, ist in den
Schritten 819 und 821 gezeigt. Wie im Diagramm
B gezeigt wird, gibt das Zeichen b den Beginn des Structs an. Das
Zahlzeichen nr_fields gibt die Anzahl der Felder im Struct an. Die
Felder im Struct werden durch die Deskriptoren field_1, field_2, field
n beschrieben. Jedes Feld ist ein Basistyp oder Verbundtyp. Basistypfelder
des Structs werden, wie im Diagramm A gezeigt ist, beschrieben.
Zusammengesetzte bzw. Verbundtypen werden, wie hier gezeigt ist,
beschrieben (d. h. Arrays werden mit dem Startzeichen a zusammen
mit der Anzahl der Dimensionen und der Größe jeder Dimension, etc. beschrieben).
-
In
der IDL sind Sequenzen von Datentypen definiert. Eine Sequenz ist
ein eindimensionales Array mit zwei Merkmalen: einer maximalen Größe (die
zur Kompilierungszeit festgelegt ist) und einer Länge (die
während
der Laufzeit bestimmt wird). Sequenzen sind dargestellt als:
c
nr_occurrences base_type
-
Die
Erzeugung von Zeichen für
eine Sequenz ist in den Schritten 823 und 825 gezeigt.
Bei dieser Darstellung stellt c den Beginn der Sequenz, wie im Diagramm
B gezeigt ist, dar. Das Zeichen nr_occurrences legt fest, wie viele
Auftritte des Datentyps in der Sequenz beinhaltet sind. Auf die
Anzahl der Auftritte folgt dann der tatsächliche Deskriptor Base type
für jedes
Auftreten des Datentyps in der Sequenz. Falls der Datentyp ein Basistyp
ist, wird der entsprechende Deskriptor aus dem Diagramm A verwendet.
Falls die Sequenz aus zusammengesetzten Typen besteht, werden die
Deskriptoren, wie hierin beschrieben ist, generiert. Eine Sequenz
aus Sequenzen ist möglich.
-
Der
in der IDL definierte Stringtyp kann aus allen möglichen Größen mit 8 Bit mit Ausnahme
von Null bestehen. Ein String ist einer Folge von Chars ähnlich.
Strings sind in CIN dargestellt als:
d size
-
Der
Beginn des Strings wird durch das d-Zeichen gekennzeichnet. Die
Größe des Strings
ist durch das size-Zeichen, das im Schritt 827 erzeugt
wird, wiedergegeben.
-
In
der IDL sind Unionen eine Mischung zwischen der „Union" der Programmiersprache C und der „Switch"-Anweisung aus C.
Mit anderen Worten umfaßt
die Syntax der Union eine „Switch"-Anweisung zusammen
mit einem „Case"-Label, das die Verzweigungen
der Union angibt. IDL-Unionen müssen
diskriminiert werden; d. h. der Kopf der Union muß ein typisiertes
Kennzeichnungsfeld festlegen, das bestimmt, welches Element der
Union im momentanen Fall eines Aufrufs verwendet werden soll. Unionen
und Verzweigungen von Unionen sind in CIN wie folgt dargestellt:
e
nr_fields f label_l field_l [f label_2 field_2 ... label_n field_n]
-
Die
Erzeugung von Zeichen, um Unionen und Verzweigungen von Unionen
darzustellen, ist in den Schritten 829, 831, 833 und 835 gezeigt.
In dieser Darstellung gibt e den Beginn einer Union an und f den
Beginn einer Verzweigung einer Union in der Union. Die Anzahl der
Felder in der Union ist durch das Zeichen nr_fields festgelegt.
Der case-Labelwert für
jedes Feld ist durch das Zeichen label_l bezeichnet. Falls das Feld eine
Voreinstellung ist, wird das Label weggelassen. Darauf folgt der
Deskriptor für
jedes Feld field_l. Die Felder der Union können entweder ein Basistyp
oder ein Verbundtyp sein. Entsprechend kann der Felddeskriptor für einen
Basistyp basierend auf dem Diagramm A generiert werden. Verbundtypen
werden, wie hierin beschrieben ist, generiert.
-
Wie
anhand der Deskriptoren für
Basistypen und Verbundtypen zu erkennen ist, umfaßt die CIN-Beschreibung
nicht die Identifizierungsmerkmale, die in der ursprünglichen
IDL-Quelldatei enthalten
sind, und es wird ein allgemeiner Deskriptor generiert. Somit können selbst
die kompliziertesten Datenstrukturen einfach im Stringformat dargestellt
werden. Im folgenden wird eine beispielhafte Struktur, die ursprünglich in
IDL dargestellt war, gezeigt:
-
-
Bei
Verwendung des Verfahrens der vorliegenden Erfindung würde die
oben beschriebene Datenstruktur in CIN dargestellt werden als: "c100
+ e2 + f0 + b2 + FFf1 + b2 + KK"
-
Bei
einer bevorzugten Ausführungsform
folgt auf positive Zahlzeichen ein Pluszeichen („+"). Negative Zahlen enden durch ein negatives
Vorzeichen („–"). Während negative
Zahlen nicht häufig
auftreten, kann ihre Verwendung für bestimmte Datentypen, wie
beispielsweise case-Labels
für Unionen
erforderlich sein (d. h. der case-Diskriminator kann eine negative
Zahl sein). Der CIN-Deskriptor, der oben gezeigt wurde, wird wie
folgt erläutert:
Eine Datenstruktur besteht aus einer Sequenz (c) mit einem Maximum
von 100 Elementen (100+), wobei jedes Element aus einer Union (e)
mit zwei Feldern (2+) besteht. Falls der Diskriminator Null ist
(FALSE) (f0+), dann ist eine Union ein Struct (b), das zwei Felder
(2) enthält.
Das erste Feld ist ein vorzeichenbehaftetes Long (F). Das zweite
Feld ist ein vorzeichenbehaftetes Long (F). Falls der Diskriminator
1 (TRUE) ist (f1+), ist die zweite Union ein Struct (b), das zwei
Felder (2+) enthält.
Das erste Feld ist ein vorzeichenloses Long (K). Das zweite Feld
ist ein vorzeichenloses Long (K).
-
Falls
eine Operation in CIN beschrieben werden soll, wird das Verfahren
im Schritt 951 fortgesetzt. 9 ist
ein Flußdiagramm,
das beim Erzeugen eines Diskriptors für eine Operation die folgenden
Schritte umfaßt.
Ein Deskriptor für
eine Operation wird in CIN wie folgt generiert:
-
-
Im
Schritt 951 generiert der Codegenerator einen eindeutigen
Integerwert operation_synopsis, der vom String abgeleitet wird,
der den Rest des Deskriptors der Operation bildet. Der Integerwert
wird durch beispielsweise Durchführen
einer zyklischen Redundanzprüfung
der verbleibenden Zeichen im CIN-Deskriptor abgeleitet. Als nächstes generiert
der Codegenerator einen eindeutigen String operation_id, der aus
dem ursprünglichen
IDL-Namen der Operation abgeleitet wird. Als nächstes generiert im Schritt 955 der
Codegenerator operation_attribute, d. h. ein Zeichen, das die Attribute
(keines oder „one-way") der Operation kennzeichnet.
Beispielsweise wird das Zeichen A generiert, falls die Operation
kein one-way-Attribut
umfaßt.
Falls jedoch das Attribut der Operation one-way ist, generiert der
Codegenerator das Zeichen B. Das Zeichen nr_params ist ein Integerwert,
der anzeigt, wie viele Parameter von der Operation umfaßt sind.
Falls die Operation einen nicht ungültigen Rückgabetyp (non-void return
type) umfaßt,
ist der erste Parameter das Ergebnis. Der param_1 umfaßt ein Zeichen,
das die Richtung des Parameters angibt (in, out, inout, oder Funktionsergebnis), worauf
der tatsächliche
Parameterdatentyp folgt. Der Codegenerator erzeugt beispielsweise
die Zeichen A, B, C und D für
die Richtungen in, out, inout bzw. Funktionsergebnis. Für die speziellen
Parameter springt das Verfahren zum Schritt 807 in 8 zurück. Wenn der Datentyp für jeden
Parameter dargestellt wurde, wird die Anzahl der Ausnahmen durch
den Integerwert nr_exceptions festgelegt. Die Strukturbeschreibung
für jede Ausnahme
wird dann durch Zurückspringen
zum Schritt 819, in dem Strukturen dargestellt werden,
dargestellt. Der Integerwert nr_context gibt die Anzahl von Kontextnamen,
die in der Operation verwendet werden, wieder. Die Namen werden
dann in Strings context_1, context_2, context_n generiert.
-
Im
Folgenden sind zwei Musteroperation dargestellt, die ursprünglich in
IDL geschrieben sind:
-
-
Unter
Verwendung des Verfahrens der vorliegenden Erfindung würde die
oben beschriebene Add-Operation in CIN wiedergegeben werden als: 126861413 + 3 + ADDA3 + DFAFAFO + 0 +
-
Der
CIN-Deskriptor für
den Vorgang stellt sich wie folgt dar. Das Zahlzeichen am Anfang
(126861413) ist aus dem Rest der CIN durch Ausführen einer zyklischen Redundanzprüfung beim
String „ 3
+ ADDA3 + DFAFAFO + 0 +" abgeleitet.
Die ID der Operation enthält
drei Zeichen (3+). Diese drei Zeichen sind der String „ADD" – die ID der Operation. Alle
IDL-Identifizierungsmerkmale
müssen
eindeutig und vom Case unabhängig sein.
Daher werden die IDs der Operation groß geschrieben. Die Operation
umfaßt
das one-way-Attribut (A) nicht. Die Operation umfaßt drei „Parameter" (3+). Da die Funktion
ein Ergebnis zurückgibt,
ist der erste „Parameter" eigentlich ein Funktionsergebnis
(D). Das Funktionsergebnis ist ein vorzeichenbehafteter Long (F). Der
nächste
Parameter (in Wirklichkeit der erste Parameter) ist ein in-Parameter
(A). Der Parameter ist ein typisierter vorzeichenbehafteter Long
(F). Der dritte Parameter ist ein in-Parameter (A) eines typisierten
vorzeichenbehafteten Long (F). Es gibt keine Ausnahmen (0+) und
keine Kontexte (0+).
-
Ähnlich wäre der CIN-Deskriptor
für die
Subtract-Operation: 453399302-9 + SUBTRACTA3
+ DFAF0 + 0 +
-
Schnittstellen
werden ähnlich
unter Verwendung des Verfahrens der vorliegenden Erfindung beschrieben. 10 zeigt die Generierung
von Schnittstellendeskriptoren. Schnittstellen sind wie folgt definiert:
-
-
Der
Integerwert nr_operations zeigt an, wie viele Operationen in der
Schnittstelle enthalten sind. Jede Operation wird dann gemäß dem oben
beschriebenen Verfahren zum Generieren eines Deskriptors für eine Operation
mit operation_spec_1, operation_spec_2, operation_spec_n beschrieben.
Der Codegenerator 112 springt daher zum Schritt 951 in 9, um die jeweilige Operation
darzustellen.
-
Unter
Verwendung des Verfahrens der vorliegenden Erfindung wäre die oben
beschriebene Math-Schnittstelle in CIN dargestellt als: 2 + 126861413 + 3 + ADDA3 + DFAFAFO + 0 + 453399302 – 9 + SUBTRACTA3
+ DFAF0 + 0 +
-
Die
Schnittstelle umfaßt
zwei Operationen (2+). Die Deskriptoren der Operationen für die ADD-
und SUBTRACT-Operationen folgen auf das Zeichen, das die Zahl der
Operationen angibt.
-
Wie
oben erläutert,
sind die CIN-Deskriptoren in einer Kopfdatei enthalten, die sowohl
mit der Client- als auch der Serveranwendung verknüpft ist.
Somit kann sowohl der Client als auch der Server den Deskriptor verwenden,
da ihn beide sehen. Die CIN kann auf viele Arten verwendet werden.
Beispielsweise kann eine CIN-Beschreibung eines Datentyps beim Erzeugen
allgemeiner Funktionen zum Packen und Entpacken strukturierter Datentypen
nützlich
sein.
-
CIN-Beschreibungen
können
auch dazu verwendet werden, Schnittstellen schnell miteinander zu
vergleichen. Beispielsweise kann eine Serveranwendung eine Kopfdatei
umfassen, die zwei Schnittstellen enthält, die in CIN geschrieben
sind. Der Server kann dann die ASCII-String-Beschreibungen unter Verwendung bekannter
String-Vergleichsfunktionen vergleichen. Falls der Server feststellt,
daß die
CIN-Beschreibungen identisch sind (oder ähnlich), kann der Server die
Operationen beider Schnittstellen unter Verwendung allgemeiner Methoden
in der Serveranwendung implementieren. Somit kann die CIN dazu verwendet
werden, Zeit beim Kodieren mehrerer Methoden für unterschiedliche (jedoch ähnliche)
Schnittstellen zu sparen.
-
VI. Generieren einer Datenstruktur
im Pickled-IDL-Format
-
Die
Datenstruktur im Pickled-IDL-Format („PIF") ist so aufgebaut, daß sie in
Verbindung mit IDL-Compilern und Codegeneratoren, die in den Clientspeicher 23 und
Serverspeicher 17 geladen sind, verwendet werden kann.
Die Datenstruktur basiert auf einer IDL-Quelldatei, die im Speicher 23 oder
im Speicher 17 gespeichert ist. Die Quelldatei kann auch
in einem computerlesbaren Medium, wie beispielsweise einer Platte
enthalten sein. Die Datenstruktur der vorliegenden Struktur enthält einen
Syntaxanalysebaum, der die IDL-Quelldatei darstellt. Die Datenstruktur
kann im Speicher 23 oder im Speicher 17 oder auf
einem computerlesbaren Medium, wie beispielsweise einer Platte gespeichert
sein. Die Datenstruktur, die die Quelldatei wiedergibt, wird als Pickled-IDL-Format
(„PIF") bezeichnet. Auf
die PIF-Datei kann während
der Laufzeit durch Client und Server zugegriffen werden, die die
Schnittstellen, die in der Quelldatei definiert sind, verwenden.
Der Syntaxanalysebaum, der in der PIF-Datei enthalten ist, ist ein
Array, bei dem Arrayindices anstelle von Zeigern verwendet werden.
Die Verwendung von Arrayindices ermöglicht, daß der resultierende Syntaxanalysebaum
sprachunabhängig
ist. Das erste Element des Arrays wird nicht verwendet. Das zweite
Element des Arrays (Index 1) ist die Wurzel des Syntaxanalysebaums,
die die Funktion eines Eintrittspunktes zum Rest des Syntaxanalysebaums
hat.
-
Die
Datenstruktur tu 1101 ist in 11 gezeigt
und in IDL wie folgt definert:
-
-
Die
Datenstruktur 1101 enthält
eine Sequenz (ein Array mit variabler Größe) von Syntaxanalysebaumknoten 1105,
entry_def jedes Typs (nachfolgend definiert), und eine Folge von
Quelldateizeilen 1107. Die Sequenz von Quelldateizeilen 1107 ist
eine Folge von Strings, die die wirklichen Quellcodezeilen aus der IDL-Quelldatei
enthalten.
-
Jeder
Syntaxanalysebaumknoten (oder „Eintrag") 1105 besteht
aus einem festen Teil, der den Namen des Knoten enthält und seine
Eigenschaften enthält,
sowie aus einem variablen Teil, der vom Typ des Knoten abhängt. Der
Syntaxanalysebaumknoten ist in 12 gezeigt
und in IDL wie folgt definiert:
-
-
-
Der
feste Teil des Syntaxanalysebaumknotens umfaßt entry_index
1205,
ein vorzeichenloses Long, das der Index für diesen speziellen Eintrag
im Syntaxanalysebaum ist. Der unqualifizierte Name des Eintrags ist
im Feld name
1207 enthalten. Der Name der ursprünglichen
IDL-Quelldatei ist im Feld file_name
1211 enthalten. Das
Feld line_nr
1213 enthält
die Zeilennummer in der IDL-Quelldatei, die für die Generierung dieses Syntaxanalysebaumknotens
verantwortlich ist. Der boolean in_main_file
1215 gibt
an, ob der Eintrag in der IDL-Quelldatei,
die in der Befehlszeile bestimmt ist, eingetragen wurde oder nicht,
oder ob der Eintrag Teil einer „umfassenden" Datei ist. Folgend
auf diese Felder umfaßt
der Syntaxanalysebaumknoten einen variablen Teil – eine Union
1217 mit
einem Diskriminator entry_type_def. Der Union-Diskriminator entry_type_def
legt den Typ des Knotens fest und welche Variante in entry_def aktiv
ist. Entry_type_def ist eine Aufzählung, die wie folgt definiert
ist:
-
Entry_type_def
umfaßt
eine Liste der verschiedenen Typen von Syntaxanalysebaumeinträgen. Jeder Syntaxanalysebaumeintrag
stellt eine konstante ganze Zahl dar, die in der Switch-Anweisung verwendet
wird, die in entry_def enthalten ist. Für jeden Eintrag umfaßt die Union
u_tag einen unterschiedlichen Strukturtyp. Der erste Wert der Aufzählung entry_unused
entspricht dem Wert Null und wird zur Bestimmung des Typs der Union
nicht verwendet.
-
Falls
der Syntaxanalysebaumeintrag ein Modul ist (festgelegt durch entry_module),
ist der variable Teil des Syntaxanalysebaumeintrags eine Datenstruktur,
die eine Folge von Moduldefinitionen umfaßt. Jede Moduldefinition ist
ein vorzeichenloses Long, das im Syntaxanalysebaumarray als Index
funktioniert.
-
Falls
der Syntaxanalysebaumeintag eine Schnittstelle ist, die durch den
Wert entry_interface festgelegt ist, ist der variable Teil des Syntaxanalysebaums
eine Datenstruktur, die eine Folge lokaler Definitionen und eine
Folge von Basisschnittstellen umfaßt, von welchen diese Schnittstelle
erbt. Falls der Syntaxanalysebaumeintrag eine vorwärts gerichtete
Deklaration einer Schnittstelle ist (entry_interface_fwd), ist die
Union ein vorzeichenloses Long, das den Index der kompletten Definition
enthält.
-
Konstanten
(entry_const) sind in einem Syntaxanalysebaumknoten als eine Struktur
dargestellt, die den Wert der Konstante enthält. Eine Union und eine Switch-/Case-Anweisung
werden vorzugsweise verwendet, um zwischen den verschiedenen Basistypkonstanten
zu unterscheiden (Boolean-Konstante, Char-Konstante, Double-Konstane,
etc.), die in der Quelldatei beinhaltet sein können.
-
Ausnahmen
(entry_except) sind in einem Syntaxanalysebaumknoten als eine Struktur
dargestellt, die eine Sequenz von Feldern enthält. Ein Attribut (entry_attr)
ist als eine Datenstruktur dargestellt, die einen Boolean-Wert,
der anzeigt, ob das Attribut ein Nur-Lese ist, und ein vorzeichenloses
Long enthält,
das den Datentyp angibt.
-
Falls
der Syntaxanalysebaumeintrag eine Operation (op_def) ist, ist der
variable Teil 1217 der Datenstruktur des Eintrags 1105 eine
Datenstruktur, wie in 13 gezeigt
ist. Die Datenstruktur 1217 enthält ein Boolean 1305,
das angibt, ob die Operation ein one-way-Attribut umfaßt, ein
vorzeichenloses Long 1307, das den Rückgabetyp anzeigt, eine Folge
von Argumenten 1309 für
die Operation, eine Folge von Ausnahmen 1311 für die Operation
und eine Folge von Strings 1313, die den jeweiligen in
der Operation enthaltenen Kontext bestimmen. Falls der Syntaxanalysebaumeintrag
ein Argument für
eine bestimmte Operation ist (entry_argument), ist der variable
Teil des Syntaxanalysebaumeintrags eine Struktur, die vorzeichenlose
Longs enthält,
die den Datentyp und die Richtung des Arguments kennzeichnen.
-
Falls
der Syntaxanalysebaumeintrag eine Union ist (entry_union), ist sie
im Syntaxanalysebaumeintrag, wie in 14 gezeigt
ist, dargestellt. Die Datenstruktur 1217 enthält ein vorzeichenloses
Long, das den Diskriminator 1403 festlegt und ein vorzeichenloses
Long, das den Typ 1405 festlegt. Der Typ ist vorzugsweise unter
Verwendung einer Auflistung von Basistypen festgelegt. Die Struktur 1217 umfaßt des weiteren
eine Folge von Feldern 1407 der Union. Falls der Syntaxanalysebaumeintrag
eine Verzweigung einer Union (entry_branch) ist, ist der variable
Teil des Syntaxanalysebaumeintrags eine Struktur, die eine vorzeichenloses Long,
das den Basistyp der Verzweigung anzeigt, einen Boolean, der anzeigt,
ob die Verzweigung einen Case-Label umfaßt, oder nicht, und den Wert
des Diskriminators enthält.
Da der Wert einen bestimmten Datentyp umfaßt, wird vorzugsweise eine
Auflistung der verschiedenen Basistypen verwendet, um den Wert in
der Struktur festzulegen, die verwendet wird, um die Verzweigung
der Union darzustellen.
-
Für Datenstrukturen
(entry_struct) umfaßt
der variable Teil des Syntaxanalysebaumeintrags eine Struktur, die
eine Folge der Felder der festgelegten Struktur enthält. Aufgelistete
Werte (entry_enum) werden durch eine Struktur wiedergegeben, die
eine Folge aufgelisteter Werte enthält. Auflistungen eines aufgelisteten Typs
(entry_enum_val) werden im Syntaxanalysebaumeintrag durch eine Struktur
dargestellt, die ein vorzeichenloses Long enthält, das den numerischen Wert
der Auflistung enthält.
-
Falls
der Syntaxanalysebaumeintrag ein String (entry_string) ist, ist
der variable Teil des Syntaxanalysebaumeintrags eine Struktur, die
die maximale Größe des Strings
enthält.
Eine maximale Größe von Null
impliziert einen unbegrenzten String. Ein Array (entry_array) ist
im Syntaxanalysebaumeintrag durch eine Struktur dargestellt, die
ein vorzeichenloses Long umfaßt,
das den Basistyp des Arrays enthält,
und eine Folge von Longs, die die Abmessungen des Arrays enthalten.
Eine Sequenz (entry_sequence) ist im Syntaxanalysebaumeintrag durch
eine Struktur dargestellt, die vorzeichenlose Longs enthält, welche
den Basistyp der Sequenz und die maximale Größe der Sequenz enthalten.
-
Für Typdefinitionen
(entry_typedef) umfaßt
der Syntaxanalysebaumeintrag eine Struktur, die einen vorzeichenlosen
Longwert enthält,
der den Basistyp der Typdefinition anzeigt. Vordefinierte Typen (entry_pre_defined)
werden durch eine Struktur dargestellt, die den Datentyp enthält. Um den
Typ zu bestimmen, wird vorzugsweise eine Auflistung der verschiedenen
Basistypen verwendet.
-
Sobald
die IDL-Quelldatei unter Verwendung der tu-Datenstruktur dargestellt
ist, kann die Datenstruktur unter Verwendung irgendeiner bekannten
Methode zu einer Datei oder Datenbank transportiert werden.
-
Nachdem
eine bevorzugte Ausführungsform
eines Verfahrens und einer Vorrichtung zum Umwandeln von in IDL
definierten Datenstrukturen in ein für den Transport geeignetes
Format und von diesem beschrieben wurde, ist für Fachleute erkennbar, daß bestimmte
Vorteile des Systems erreicht wurden. Es sollte verständlich sein,
daß verschiedene
Modifizierungen, Anpassungen und alternative Ausführungsformen
daran innerhalb des Umfangs der vorliegenden Erfindung vorgenommen
werden können.
Die Erfindung ist durch die folgenden Ansprüche definiert.
