-
1. Gebiet
der Erfindung
-
Die
folgende Erfindung betrifft ein Verfahren und eine Vorrichtung zum
Beschreiben einer Schnittstelle, einer Operation und eines Datentyps,
die mittels einer Schnittstellen-Definitionssprache
definiert sind. Insbesondere werden Datentypen beschrieben, die
eine Folge von ASCII-Zeichen verwenden.
-
2. Hintergrund
-
Das
Rechnen mit verteilten Objekten kombiniert die Konzepte des verteilten
Rechnens und des objektorientierten Rechnens. Das verteilte Rechnen
umfaßt
zwei oder mehr Softwareteile, die sich Information 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-Modell.
Beim Client/Server-Modell werden hauptsächlich zwei Typen von Software verwendet:
Client-Software, mit der die Information oder der Dienst angefordert
wird, und Server-Software,
mit der die Information oder der Dienst bereitgestellt oder implementiert
werden.
-
Objektorientiertes
Rechnen basiert auf dem Objektmodell, bei dem Codeteile, die „Objekte" genannt werden – und gegenüber echten
Objekten in der realen Welt häufig
abstrahiert sind – Daten
enthalten, und mit denen Prozesse (auch „Operationen" genannt) durchgeführt werden.
Ein Objekt wird durch seine Schnittstelle (oder „Klasse" in der Terminologie von C++) definiert.
Die Schnittstelle definiert die Merkmale und das Verhalten einer
Objektart, einschließlich
der Operationen, die bezüglich
dieser Objekte mit dieser Schnittstelle durchgeführt werden können, sowie
die Parameter dieser Operation. Eine bestimmte Instanz eines Objekts
ist innerhalb eines Systems mit verteilten Objekten durch einen
eindeutigen Bezeichner gekennzeichnet, der Objektreferenz genannt
wird.
-
In
einem System mit verteilten Objekten sendet ein Client eine Anfrage
(oder „Aufruf" oder „Objektaufruf") an eine Serveranwendung,
die eine Angabe der bezüglich
eines bestimmten Objekts durchzuführenden Operation, die Parameter
für diese
Operation, die Objektreferenz für
dieses Objekt und einen Mechanismus zur Rückgabe von Fehlerinformationen
(oder „Ausnahmeinformation)
hinsichtlich des Erfolgs oder Fehlschlagens einer Anfrage enthält. Die
Serveranwendung empfängt
die Anfrage und verarbeitet die Anfrage über eine Server-„Implementierung". Die Implementierung
kommt der Anfrage des Client nach einer Operation bezüglich eines
bestimmten Objekts nach. Die Implementierung umfaßt eine
oder mehr Methoden, die Teile von Code in der Serveranwendung sind,
welche momentan die von der Implementierung angeforderte Arbeit
durchführen. Wenn
die Implementierung erfolgreich durchgeführt wurde, gibt die Serveranwendung
eine Antwort an den Client zurück,
falls notwendig. Die Serveranwendung kann auch Ausnahmeinformation
zurückgeben.
-
Um
Systeme mit verteilen Objekte zu standardisieren, wurde von der
Object Management Group („OMG"), ein Konsortium
von Computersoftwarefirmen, die Common Object Request Broker Architecture („CORBA") vorgeschlagen.
Unter dem CORBA-Standard schafft ein Object Request Broker („ORB") einen Kommunikationsnetzknoten
(communication hub) für
alle Objekte in dem System, der die Nachfrage an den Server weitergibt
und die Antwort an den Client zurückgibt. Kommerzielle ORBs sind
aus dem Stand der Technik bekannt, wobei ein üblicher Typ das System Object
Model („SOM") von IBM ist. Auf
der Clientseite wickelt der ORB Anfragen bezüglich des Aufrufs einer Methode
und der damit verknüpften
Auswahl von Servern und Methoden ab. Wenn eine Anwendung eine Anfrage
nach einer Methode an den ORB sendet, die auf das Objekt anzuwenden
ist, validiert der ORB die in der Anfrage enthaltenen Argumente
gegenüber
der Schnittstelle dieses Objekts, fertigt die Anfrage an den Server
aus und startet diesen, falls notwendig. Auf der Serverseite verwendet
der ORB die in der Anfrage enthaltene Information, um die beste
Implementierung zur Erfüllung
der Anfrage zu ermitteln. Diese Information umfaßt die Operation, die der Client
anfordert, den Objekttyp auf den die Operation angewandt wird, sowie
jegliche zusätzliche
Informationen, die für
die Anfrage gespeichert sind. Zudem validiert der serverseitige
ORB jede Nachfrage und ihre Argumente. Der ORB ist zudem für das Übertragen
der Antwort zurück
an den Client verantwortlich.
-
Sowohl
die Clientanwendung als auch die Serveranwendung müssen Informationen
bezüglich
der zur Verfügung
stehenden Schnittstellen haben, einschließlich der Objekte und Operationen,
die auf diesen Objekten angewendet werden können. Um das gemeinsame Nutzen
der Schnittstellendefinitionen zu vereinfachen, schlägt OMG die
Schnittstellendefinitionssprache (Interface Definition Language, „IDL") vor. IDL ist eine
Definitionssprache (keine Programmiersprache), die zum Beschreiben
der Schnittstelle eines Objekts verwendet wird; d. h. die Merkmale
und das Verhalten einer Objektart, einschließlich der Operationen, die
auf diesen Objekten ablaufen können.
-
Die
IDL-Schnittstellen definieren einen Satz von Operationen, die ein
Client bezogen auf ein Objekt aufrufen kann. Eine Schnittstelle
kann eine oder mehrere Ausnahmen deklarierern, die anzeigen, daß eine IDL-Operation
nicht erfolgreich durchgeführt
wurde. Operationen können
Parameter empfangen und einen Rückgabewert
zurückgeben.
Jeder Parameter einer Operation kann eine „Richtung" haben, die anzeigt, ob der Wert von
dem Client an dem Server („in"), von dem Server
an den Client („out"), oder in beide
Richtungen („inout") weitergegeben wird.
Der Parameter weist ferner einen Datentyp auf, der seine zulässigen Werte
vorgibt. Operationen können
optional auch ein „Einweg"-Atribut aufweisen,
das spezifiziert, welche Inhalte des Aufrufs von dem Kommunikationsdienst
für Aufrufe
einer bestimmten Operation bereitgestellt werden müssen. Wenn ein
Client eine Operation mit dem Einweg-Attribut aufruft, sind die
Inhalte des Aufrufs „best-möglich" („best-effort"), was beinhaltet,
daß die
Operation mindestens einmal von einem Server implementiert wird.
Wenn ein Versuch der Implementierung der Operation fehlschlägt, versucht
der Server nicht nochmals, die Operation zu implementieren. Eine
Operation mit dem Einweg-Attribut muß einen leeren (void) Rückgabetyp
spezifizieren und darf keine Ausgabeparameter enthalten.
-
Datentypen
werden verwendet, um die zulässigen
Werte für
IDL-Operationsparameter, -Ausnahmen und
-Rückgabewerte
zu beschreiben. Die IDL unterstützt
zwei Kategorien von Datentypen: Basistypen und Mischtypen. Basistypen
umfassen short integers (kurze ganze Zahlen), long integers (lange
ganze Zahlen), long long integers, unsigned long integers (lange
ganze Zahlen ohne Vorzeichen), unsigned short integers (kurze ganze
Zahlen ohne Vorzeichen), Fließkomma,
double (Doppel), character (Zeichen), boolean (Bool'sche Typen) und Byte.
Mischtypen umfassen Aufzählung
(enum), Zeichenkette (string), Struktur (struct), Feld (array),
Variante (union), Folge (sequence) und einen "jegliche" (any) Typ. Der Strukturtyp gleicht
einer C-Struktur; sie erlaubt es den Erstellern der Schnittstelle,
komplexe Datentypen zu erzeugen, die eine oder mehrere Typdefinitionen
verwenden. Mit dem Folge-Typ können
Ersteller der Schnittstelle ein Feld von Objekten mit variabler
Größe übergeben.
Der Typ „jegliche" kann jeden möglichen
Datentyp – Basistyp
oder Mischtyp – darstellen.
-
Die
IDL ist für
eine Verwendung in Systemen mit verteilten Objekten bestimmt, in
denen die Common Object Request Broker Architecture ("CORBA"), Revision 2.0 der
OMG imple mentiert ist. In einem typischen System, das den CORBA-Standard
implementiert, werden Schnittstellendefinitionen in eine IDL-definierte Quelldatei
geschrieben (die auch als "Übersetzungseinheit" bezeichnet wird).
Die Quelldatei wird von einem IDL-Compiler kompiliert, der programmiersprachenspezifische
Dateien erzeugt, einschließlich
Client-Stub-Dateien, Server-Stub-Dateien und Headerdateien. Client-Stub-Dateien
sind sprachspezifische Abbildungen von IDL-Operationsdefitionen
eines Objekttyp auf prozedurbezogene Routinen, jeweils eine pro
Operation. Wenn die Stub-Routinen von einem sprachspezifischen Compiler
kompiliert und in eine Client-Anwendung verlinkt werden, können die
Stub-Routinen von der Client-Anwendung aufgerufen werden, um eine
Anfrage auszulösen.
In gleicher Weise sind die Server-Stub-Dateien sprachenspezifische
Abbildungen von IDL-Operationsdefinitionen eines (von einer Schnittstelle
definierten) Objekttyps auf prozedurbezogene Routinen. Wenn diese kompiliert
und in eine Serveranwendung gelinkt ist, kann sie diese Routinen
aufrufen, wenn eine entsprechende Anforderung empfangen wird. Headerdateien
können
kompiliert und in Client- und Serveranwendungen gelinkt werden,
und sie werden verwendet, um allgemeine Datentypen zu definieren.
-
Ein
Nachteil bei der Verwendung von Operationen, die exakt nach IDL
definiert sind, innerhalb einer Anwendung, ist die Unmöglichkeit,
diese Operationen in generischen Funktionen zu verwenden. Generische Funktionen
können über heterogene
Plattformen hinweg verwendet werden und daher die Wiederverwendung von
Codes über
diese verschiedenen Plattformen begünstigen. Im Stand der Technik
muß jedoch
jede Applikation eine bestimmte Client-Stub-Funktion aufrufen, um auf eine
Operation zuzugreifen, die in einer bestimmten Schnittstelle enthalten
ist. Da zusätzliche
Operationen zu der Schnittstelle hinzugefügt sind, müssen neue Stub-Funktionen erzeugt
werden. Daher können
Anwendungen mit der Zeit immer komplexer werden.
-
Ein
weiterer Nachteil bei Operationen, die exakt nach IDL definiert
sind, ist die Unmöglichkeit,
die Schnittstellen zu vergleichen, um Kompatibilität zu ermitteln.
In bestimmten Fällen
kann ein Server einen angeforderten Dienst nicht bereitstellen,
da der Server diese Schnittstelle und ihre zugehörigen Operationen nicht bereit
hält. Der
Server könnte
jedoch eine kompatible Schnittstelle aufweisen, die eine ähnliche
Operation vorsieht. Zur Zeit ist kein Verfahren verfügbar, um
die Kompatibilität
von Schnittstellen und/oder Operationen zu ermitteln.
-
Dementsprechend
gibt es einen Bedarf an der Verwendung von IDL-definierten Schnittstellen,
Operationen und Parametern für
generische Funktionen.
-
Ferner
besteht Bedarf an einer Vereinfachung des Vergleichs von IDL-definierten
Schnittstellen, Operationen und Datentypen.
-
ABRISS DER
ERFINDUNG
-
Die
vorliegende Erfindung betrifft ein Verfahren und ein System und
ein Computerprogrammprodukt, das den Bedarf hinsichtlich der Verwendung
von IDL-definierten Schnittstellen, Operationen und Datentypen bei
generischen Funktionen befriedigt. Ferner erfüllt das Verfahren der vorliegenden
Erfindung das Bedürfnis zur
Vereinfachung des Vergleichs von IDL-definierten Schnittstellen,
Operationen und Parametern. Das Verfahren umfaßt den Schritt des Erzeugens
eines neuen ASCII-Zeichenkettenbezeichners, der die Schnittstelle, die
Operation oder den Parameter bezeichnet. Insbesondere werden Zeichen
verwendet, um den Basistyp jedes Parameters zu bezeichnen, während eine
Kombination von Zeichen und Zahlen verwendet wird, um Parameter
des Mischtyps und die Merkmale solcher Parameter des Mischtyps zu
bezeichnen. Für
Operationen werden Zeichen und Zahlen verwendet, um die Anzahl und
Typen von Parametern, die Anzahl der Ausnahmen und die Anzahl der
in der Operation enthaltenen Kontexte zu kennzeichnen. Schnittstellen
werden mittels einer Zahl beschrieben, welche die Anzahl der in
der Schnittstelle enthaltenen Operationen kennzeichnet.
-
Generische
Funktionen können
erzeugt werden, um Objektaufrufe über heterogene Systeme zu transportieren,
indem die ursprüngliche
IDL-Beschreibung in eine ASCII-Zeichenkette konvertiert wird. Insbesondere
können
Codegeneratoren einfache Zeichenketten ausgeben, um eine Schnittstelle
vollständig
zu beschreiben, anstatt einer komplexen Verbindung von Datenstrukturen.
Ferner können
individuelle Operationen und Datentypen einfach beschrieben werden,
indem das Verfahren gemäß der vorliegenden
Erfindung verwendet wird.
-
Anhand
der folgenden detaillierten Beschreibung der bevorzugten Ausführung kann
der Fachmann das Verfahren zum Beschreiben von Datentypen, Operationen
und Schnittstellen sowie die Realisierung zusätzlicher Vorteile und deren
Ziele besser verstehen. Zunächst
werden kurz die beigefügten
Zeichnungen beschrieben, auf die Bezug genommen werden wird.
-
KURZBESCHREIBUNG
DER ZEICHNUNGEN
-
1 ist ein Diagramm eines
Client/Server-Systems, welches das Verfahren gemäß der vorliegenden Erfindung
verwendet.
-
2a und 2b sind Darstellungen von alternativen
Konfigurationen für
Kapseln der gemeinsamen Ausführungsumgebung
(Common Execution Environment Capsules).
-
3 ist eine Darstellung einer
Kapsel der gemeinsamen Ausführungsumgebung
und deren zentralen Komponenten.
-
4 ist ein Diagramm der Kompilierung
von IDL-Quelldateien.
-
5 ist ein Ablaufdiagramm,
das die Erzeugung eines CIN-Bezeichners für Basistypen und für Mischdatentypen
darstellt.
-
6 ist ein Flußdiagramm,
das die Erzeugung eines CIN-Bezeichners für eine Operation darstellt.
-
7 ist ein Flußdiagramm,
das die Erzeugung eines CIN-Bezeichners für eine Schnittstelle darstellt.
-
DETAILLIERTE
BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNG
-
Im
folgenden wird im Detail auf die bevorzugten Ausführungen
der Erfindung Bezug genommen, von denen Beispiele in den beigefügten Figuren
dargestellt sind. Nach Möglichkeit
werden in den gesamten Zeichnungen zur Bezeichnung von gleichen
oder ähnlichen
Teilen die gleichen Bezugszeichen verwendet.
-
I. Systemüberblick
-
Wie
in der 1 dargestellt,
ist das Verfahren nach der vorliegenden Erfindung dafür vorgesehen,
in einer Umgebung für
verteiltes (Client/Server) Rechnen 10 verwendet zu werden.
Die Client- und Serversysteme sind durch Netzverbindungen 12 verbunden,
beispielsweise Internetverbindungen oder Verbindungen eines Nahbereichnetzes
(LAN). Ein Servercomputer 11 kommuniziert über einen
Bus oder einen Eingangs-/Ausgangskanal 20 mit einem zugehörigen Plattenspeicher-Untersystem 13.
Das Serversystem 11 umfaßt eine CPU 15 und
einen Speicher 17, um aktuelle Zustandsinformation bezüglich der
Programmausführung
zu speichern. Ein Teil des Speichers 17 ist dafür vorgesehen,
die Zustände
und Variablen zu speichern, die mit jeder Funktion des Programms
verknüpft
sind, das momentan auf dem Clientcomputer abläuft. Der Clientcomputer 21 umfaßt in gleicher
Weise eine CPU 27 und einen zugehörigen Speicher 23,
sowie eine Eingabevorrichtung 29, beispielsweise eine Tastatur 29 oder
eine Maus 31, sowie eine Anzeigevorrichtung 33,
beispielsweise ein Videoanzeige-Endgerät (Video
Display Terminal, „VDT"). Die CPU des Client
kommuniziert über
einen Bus oder über
einen Ein-/Ausgabekanal 40 mit dem Plattenspeicher-Untersystem 33 und über einen
Ein-/Ausgabekanal 41 mit der Tastatur 29, dem
VDT 33 und der Maus 31. Beide Computer können verschiedene
Medientypen lesen, einschließlich
Disketten und CD-ROMs.
-
Der
Speicher 27 des Client umfaßt eine Clientanwendung 77 und
Client-Stubs 79, die in diesem geladen sind. In gleicher
Weise umfaßt
der Speicher 17 des Servers eine Serveranwendung 87 und
Server-Stubs 89. Ferner umfassen sowohl der Speicher des
Clients als auch der Speicher des Servers eine Ausführungsumgebung
(„CEE") 75, 85 (wie
im weiteren erörtert).
-
Das
in der 1 dargestellte
Client/Servermodell steht lediglich beispielhaft für ein typisches
Client/Serversystem. In bezug auf die vorliegende Erfindung ist
der „Client" eine Anwendung,
die anfordert, daß Operationen
bezüglich
eines Objekts durchgeführt
werden, während
der „Server" eine Anwendung ist,
welche die Operation bezüglich
des Objekts implementiert. Tatsächlich
können
sowohl die Client- als auch die Serveranwendung auf dem gleichen
Computer und innerhalb einer gemeinsamen Kapsel vorgesehen sein,
wie unten beschrieben. Am häufigsten
liegen jedoch die Client- und die Serveranwendung auf unterschiedliche
Computern vor, die verschiedene Betriebssysteme verwenden. Das Verfahren
der vorliegenden Erfindung wird anhand von zwei Kapseln diskutiert,
die auf getrennten Maschinen laufen.
-
II. Umgebung für verteiltes
Rechnen
-
Das
Verfahren und die Vorrichtung der vorliegenden Erfindung können in
jeder Umgebung für
verteiltes Rechnen verwendet werden. In einer bevorzugten Ausführung wird
die gemeinsame Ausführungsumgebung
(Common Execution Environment, „CEE") 75, 85 verwendet, die eine Komponente
der Tandem Message Switching Facility Architecture (Message Switching
Facility, „MSF") ist. Die CEE aktiviert
und deaktiviert Objekte und wird verwendet, um Nachrichten zwischen
Client- und Serveranwendungen weiter zu geben, welche in CEE- Kapseln geladen sind.
Die CEE kann in dem Speicher einer einzelnen Maschine gespeichert
sein. Häufiger
sind die CEE und die Client- und Serveranwendungen auf verschiedenen
Maschinen geladen, die über ein
Netz verteilt sind, wie in 1 dargestellt
ist. Die CEE 75 der Clientseite ist in dem Clientspeicher 23 gespeichert.
Die CEE 85 der Serverseite ist in einem Serverspeicher 17 gespeichert.
-
Die
CEE verwendet eine „Kapsel"-Infrastruktur. Eine
Kapsel verkapselt Speicherraum und einen oder mehrere Ausführungsströme („execution
streams"). Eine
Kapsel kann auf verschiedenen Systemen unterschiedlich implementiert
sein, abhängig
von dem Betriebssystem, das von dem System verwendet wird. Beispielsweise
kann eine Kapsel auf bestimmten Systemen als Prozeß implementiert
sein. Auf anderen Systemen kann die Kapsel als Thread implementiert
sein. Ferner können
Client- und Serveranwendungen innerhalb verschiedener Kapseln konfiguriert
sein, die auf verschiedenen Maschinen vorgesehen sind, wie in 1 dargestellt. Alternativ
können
verschiedene Kapseln konfiguriert sein, wie es die 2 darstellt. Die 2a zeigt eine Clientanwendung 77,
die in einer einzelnen Kapsel 81 geladen ist, und eine
Serveranwendung 87 kann in einer getrennten Kapsel 85 geladen
sein. Beide Kapseln sind jedoch auf der gleichen Maschinen 21 gespeichert.
Sowohl die Client- als auch die Serveranwendung kann auch innerhalb
einer einzelnen Kapsel 81 auf der gleichen Maschine 21 geladen
sein, wie in der 2b dargestellt
ist. Wie oben bemerkt, wird das Verfahren der vorliegenden Erfindung
mit Bezug auf einen Fall beschrieben, der mehrere Kapseln und mehrere
Maschinen umfaßt.
Dementsprechend umfassen die Clientmaschine 12 und die
Servermaschine 11 eine CEE 75 auf der Clientseite
und eine CEE 85 auf der Serverseite, die in deren jeweiligen
Speichern geladen sind.
-
Die 3 zeigt eine CEE-Verkapselung 70,
die beispielsweise in einem Clientcomputerspeicher 27 (nicht
gezeigt) enthalten ist, der die CEE 75 und bestimmte Komponenten
der Zentral-CEE und Implementierungen von Objekten, die in Implementierungsbibliotheken 71 enthalten
sind, umfaßt.
Die Implementierungsbibliotheken 71 umfassen die Clientanwendung 79 (oder
die Serveranwendung im Falle der Serverkapsel) und Client-Stubs 77 (oder
Server-Stubs), die
von der IDL-Spezifikation der Schnittstelle des Objekts erzeugt
wurden, wie im weiteren beschrieben ist. Die Implementierungsbibliotheken 71 und
die CEE 75 wirken zusammen durch Abwärtsaufrufe (Down-Calling) von
dynamisch zugreifbaren Routinen, die von der CEE bereitgestellt werden,
sowie durch Aufwärtsaufrufe
(Up-Calling) von Routinen, die in der Implementierungsbibliothek
enthalten sind. Die CEE 75 kann auch Objektaufrufe 82 von
anderen Kapseln innerhalb der gleichen Maschine sowie Anfragen 84 von
anderen CEEs empfangen. Die CEE 75 der Clientseite und
die CEE 85 der Serverseite können durch jedes bekannte Netzprotokoll
miteinander kommunizieren.
-
Objekte,
die in einer CEE-Kapsel implementiert sind, können konfiguriert oder dynamisch
sein. Die Implementierungsdetails von konfigurierten Objekten können in
einem Depot (repository) (beispielsweise das MSF Warehouse 85)
oder in Initialisierungsskripten gespeichert sein. Bei einer Anfrage
nach einer bestimmten Objektreferenz, startet die CEE 75 die
entsprechende Kapsel basierend auf diesen Konfigurationsdaten. Die Kapsel
verwendet die Konfigurationsdaten, um zu ermitteln, welche Implementierungsbibliothek
zu laden ist und welche Objektinitialisierungsroutine aufzurufen
ist. Die Objektinitialisierungsroutine erzeugt dann das Objekt.
Dynamische Objekte werden in der gleichen Kapsel dynamisch erzeugt
und zerstört.
Dynamische Objekte weisen keine Information auf, die im Depot gespeichert
ist oder von Skriptkonfigurationen stammt.
-
III. Kompilieren und Verlinken
von IDL-Quelldateien
-
Die 4 zeigt, wie IDL-Quelldateien
kompiliert und in Client- und Serveranwendungen verlinkt werden,
die das erfindungsgemäße Verfahren
und die erfindungsgemäße Vorrichtung
verwenden. Zuerst wird eine IDL-Quelldatei 101 vorbereitet,
die IDL-Schnittstellendefinitionen
enthält.
Ein IDL-Compiler 103 kompiliert die Quelldatei 101.
Der IDL-Compiler 103 parst den Code 101 und erzeugt
eine Zwischendatei 105, um die kompilierte Quelldatei zu
speichern. Ein Codegenerator 112 parst daraufhin die PIF-Datei.
Der Codegenerator 112 erzeugt Dateien in der Sprache der
Client- und Serveranwendungen. Wenn die Client- und Serveranwendungen
in verschiedenen Sprachen ausgeführt
sind, werden verschiedene Codegeneratoren 112 verwendet.
Vorzugsweise werden der Codegenerator 112 und der IDL-Compiler 103 in
einer einzigen Anwendung kombiniert, um sprachspezifischen Code
zu erzeugen. Der Codegenerator 112 erzeugt eine Client-Stubdatei 77,
die Client-Stubfunktionen
enthält,
sowie eine Server-Stubdatei 87, die Definitionen für Objektimplementierungen
enthält.
Die Client-Stubfunktionen umfassen synchrone und asynchrone Aufrufe
der CEE 75. Die Client-Stubdatei 77 und die Server-Stubdatei 87 werden
durch programmiersprachenspezifische Compiler 122, 124 kompiliert, um
einen kompilierten Client-Stubobjektcode
und einen kompilierten Server-Stubobjektcode zu erzeugen. In gleicher
Weise wird eine Clientanwendung 79 und eine Serveranwendung 89 von
programmiersprachenspe zifischen Compilern kompiliert, um kompilierten
Clientanwendungs-Objektcode und kompilierien Serveranwendungs-Objektcode
zu erzeugen. Die Clientanwendung 79 und die Serveranwendung 89 umfaßt zudem eine
Headerdatei 119, die von dem Codegenerator 112 erzeugt
wird. Die Headerdatei 119 enthält allgemeine Definitionen
und Deklarationen. Schließlich
verlinkt der Compiler 121 den Clientanwendungs-Objektcode
und den Client-Stubobjektcode, um eine Implementierungsbibliothek 71 zu
erzeugen. In gleicher Weise verlinkt ein zweiter Compiler den Serveranwendung-Objektcode
und den Server-Stubobjektcode, um eine weitere Implementierungsbibliothek 81 zu
erzeugen.
-
Der
Codegenerator 112 erzeugt eine kompakte IDL-Notation (Compact
IDL Notation, „CIN") und legt diese
in der Headerdatei 119 ab. Insbesondere untersucht der
Codegenerator alle kompilierten Schnittstellen, Operationen und
Operationsparameter und definiert einen Bezeichner (üblicherweise
der Name der Schnittstelle) und eine Zeichenfolge, durch die der
Bezeichner in der Headerdatei substituiert wird (beispielsweise
indem das Makro #define in C++ verwendet wird). Da der Codegenerator 112 eine
Quelldatei linienweise parst, speichert der Codegenerator die Zeichenfolge
in dem Speicher des Computers, der den Codegenerator enthält. Wenn
die gesamte Quelldatei geparst wurde, erzeugt der Codegenerator
einen ASCII-Bezeichner
in der Headerdatei, die von den Client- und Serveranwendungen einbezogen
(included) wird. Die Zeichenfolge in dem ASCII-Bezeichner wird basierend
auf vorbestimmte Definitionen erzeugt, die den Codegeneratoren bekannt
sind, wie im weiteren behandelt wird.
-
Eine
IDL-Quelldatei enthält
eine oder mehrere Schnittstellendefinitionen und Datentypdefinitionen
(„typedefs"). Der Körper der
Schnittstelle enthält
verschiedene Deklarationen. Deklarationen von Konstanten werden
verwendet, um Konstanten zu spezifizieren, die von der Schnittstelle
exportiert werden. Typdeklarationen spezifizieren Typdefinitionen,
die von der Schnittstelle exportiert werden. Ausnahmedeklarationen
spezifizieren die Ausnahmestrukturen, die von der Schnittstelle
exportiert werden. Attributdeklarationen spezifizieren die zugehörigen Attribute,
die von der Schnittstelle exportiert werden. Deklarationen von Operationen
spezifizieren die Operationen, die von der Schnittstelle exportiert
werden, sowie das Format jeder Operation, einschließlich des
Namens, des Rückgabedatentyps,
der Parametertypen und der Ausnahmen. In einer bevorzugten Ausführung wird
das Verfahren der vorliegenden Erfindung verwendet, um Schnittstellendefinitionen,
Definitionen von Operationen und Definitionen von individuellen
Datentypen zu beschreiben, die in einer Quelldatei enthalten sind.
Das Verfahren der vorliegenden Erfindung kann jedoch verwendet werden,
um Definitionen von Konstanten, Ausnahmedefinitionen und Moduldefinitionen
(eine Definition einer Schnittstellensammlung) zu beschreiben.
-
IV. Erzeugen von kompakter
IDL-Notation
-
Die 5 ist ein Flußdiagramm,
das die Erzeugung eines CIN-Bezeichners ausgehend von einem IDL-Datentyp,
-Operation und -Schnittstelle darstellt, die in einer IDL-Quelldatei
enthalten sind. Es ist ersichtlich, daß die Schritte der 5–7 durch
eine CPU eines Datenverarbeitungssystems implementiert werden, die
Computerbefehle ausführt,
welche in einem Speicher gespeichert sind. Im Schritt 101 beginnt
der Codegenerator 112 mit der ersten Zeile der IDL-Quelldatei
und ermittelt die Datenstruktur, die Schnittstellen oder die Operation,
die in der Quelldatei beschrieben sind. Wenn die beschriebene Datenstruktur
eine Schnittstelle ist, folgt der Codegenerator 112 den
in 7 gezeigten Richtungen.
Wenn die beschriebene Datenstruktur eine Operation innerhalb einer
Schnittstelle ist, folgt der Generator den in 6 dargestellten Richtungen. Wenn die
Datenstruktur ein Datentyp ist (oder ein Parameter einer Operation,
wie unten behandelt), erzeugt der Generator ein einzelnes Zeichen
basierend auf einer Definitionstabelle. Es sollte beachtet werden,
daß andere
Zeichen verwendet werden können,
als die, welche in den hier dargestellten Listen enthalten sind.
Jeder Listeneintrag enthält
nur ein bevorzugtes ASCII-Zeichen. Die Liste A zeigt eine bevorzugte
Definitionstabelle, welche die Zeichenfolge umfaßt, die verwendet werden, um
verschiedene IDL-Basistypen
zu bezeichnen.
-
-
-
Wie
in der Liste A dargestellt, werden einfache Zeichenketten verwendet,
um in einem CIN-Bezeichner Basistypen
darzustellen.
-
Wenn
der Datentyp eine Mischtyp ist, beispielsweise ein Feld oder eine
Struktur (struct Type), wird eine Folge verschiedener Schritte durchgeführt. In
Schritt 111 wird ein Zeichen erzeugt, das den Beginn des zusammengesetzten
Typs angibt. Die Liste B zeigt eine Beispieltabelle, welche die
Zeichenketten umfaßt,
die verwendet werden, um den Beginn verschiedener Misch-IDL-Typen
zu bezeichnen.
-
-
Die
einzelne Darstellung jedes Variantentyps wird abhängig dem
Typ unterschiedlich gehandhabt.
-
Die
IDL definiert multidimensionale Felder mit fester Größe für jeden
Basistyp. Die Feldgröße steht zum
Zeitpunkt des Kompilierens fest. In der CIN werden Felder wie folgt
dargestellt:
-
a anz_dimensionsgroesse_1.[groesse_2,
... groesse_n]basistyp
-
Die
Erzeugung von Zeichen für
das Feld ist in den Schritten 113, 115 und 117 dargestellt.
In dieser Felddarstellung stellt das Zeichen a den Beginn des Feldes
dar (wie in der Liste B ge zeigt). Das Zeichen anz_dimensionsgroesse
ist eine Zahl, die die Anzahl der Dimensionen im Feld angibt. Die
Zeichen groesse_1, groesse_2, groesse_n geben jeweils die Größe des Feldes
in der ersten, zweiten und n-ten Dimension des Feldes an. Für jedes
Element in dem Feld ist basistyp der Bezeichner für jedes
Element. Die Darstellung der verschiedenen Basistypen wird von der
Tabelle der ursprünglichen
Basistypen abgeleitet, die in der Liste A dargestellt sind.
-
Die
IDL definiert benutzerdefinierte Strukturtypen. Jede Struktur setzt
sich aus einem oder mehreren Feldern mit Basis- oder Mischdatentypen
zusammen. Strukturen werden in der CIN wie folgt dargestellt:
-
b anz_felder feld_1.[feld_2,
... feld_n]
-
Die
Erzeugung von Zeichen, um eine Struktur zu beschreiben, ist in den
Schritten 119 und 121 beschrieben. Wie in der
Liste B dargestellt, gibt das Zeichen b den Beginn einer Struktur
an. Die Zahlen anz_felder gibt die Anzahl der Felder in der Struktur
an. Die Felder in der Struktur sind durch die Bezeichner feld_1,
feld_2, feld_n beschrieben. Jedes Feld ist ein Basistyp oder ein
Mischtyp. Basistypfelder in der Struktur werden wie in der Liste
A dargestellt beschrieben. Mischtypen werden beschrieben, wie hier
dargestellt (das heißt
Felder werden mit dem Startzeichen a zusammen mit der Anzahl der
Dimensionen und der Größe jeder Dimension
dargestellt, usw.).
-
Die
IDL definiert Folgen von Datentypen. Eine Folge ist ein eindimensionales
Feld mit zwei Eigenschaften: eine maximale Größe (die zum Zeitpunkt des Kompilierens
feststeht) und eine Länge
(die während der
Laufzeit ermittelt wird). Folgen werden wie folgt dargestellt:
-
e anz_ereignisse
basistyp
-
Die
Erzeugung von Zeichen für
eine Folge ist in den Schritten 123 und 125 dargestellt.
In dieser Darstellung gibt c den Anfang der Folge an, wie in der
Liste B gezeigt. Das Zeichen anz_ereignisse spezifiziert, wie viele
Ereignisse (Elemente) des Datentyps von der Folge umfaßt sind.
Auf die Anzahl von Ereignissen bzw. Elementen folgt der aktuelle
Bezeichner, basistyp, für
jedes Auftreten (Ereignis) des Datentyps in dem Element. Wenn der
Datentyp ein Basistyp ist, wird der entsprechende Bezeichner von
der Liste A verwendet. Wenn die Folge aus Mischtypen besteht, werden
Bezeichner erzeugt, wie hier beschrieben. Eine Folge von Folgen
ist möglich.
-
Die
IDL definiert den Zeichenkettentyp als jede mögliche 8 Bit-Größe außer Null.
Eine Zeichenkette gleicht einer Folge von Zeichen. Zeichenketten
werden in der CIN wie folgt dargestellt:
-
d größe
-
Der
Beginn der Zeichenkette wird durch das d-Zeichen dargestellt. Die
Größe der Zeichenkette
wird durch das Zeichen größe dargestellt,
das in Schritt 127 erzeugt wird.
-
In
der IDL sind Varianten eine Kreuzung zwischen der „Union" der C-Programmiersprache
und der C-„Switch"-Anweisung. In anderen
Worten umfaßt
der Syntax der Variante eine „switch"-Anweisung zusammen
mit einer „Fall"-Markierung, welche
die Verzweigung der Variante angibt. IDL-Varianten müssen unterschieden
werden; d. h. der Header der Variante muß ein typspezifisches Markierungsfeld
spezifizieren, das festlegt, welches Variantenelement für die aktuelle
Instanz eines Aufrufs zu verwenden ist. Varianten (unions) und Variantenverzweigungen
(union branches) werden in der CIN wie folgt dargestellt:
-
e anz_Felder f markierung_1
feld_1 [f markierung_2 feld_2 ... markierung_n feld_n]
-
Die
Erzeugung von Zeichen, um Varianten und Variantenverzweigungen darzustellen,
ist in den Schritten 129, 131, 133 und 135 dargestellt.
In dieser Darstellung gibt e den Beginn des Verbunds an und f gibt
den Beginn einer Variantenverzweigung innerhalb der Variante an.
Die Anzahl von Feldern in der Variante ist durch das Zeichen anz_felder
spezifiziert. Der Fallmarkierungswert für jedes Feld ist durch das
Zeichen markierung_1 angegeben. Wenn das Feld das voreingestellte
Feld (default) ist, wird die Markierung vernachlässigt. Darauf folgt der Bezeichner
für jedes
Feld, feld_1. Die Variantenfelder können entweder vom Basistyp oder
vom Mischtyp sein. Dementsprechend kann der Feldbezeichner für einen
Basistypen basierend auf der Liste A erzeugt werden. Mischtypen
werden wie hier beschrieben erzeugt.
-
Wie
es anhand der Bezeichner für
Basis- und Mischtypen ersichtlich ist, umfaßt der CIN-Bezeichner nicht die Kennzeichen, die
in der Original-IDL-Quelldatei enthalten sind, und es wird ein generischer
Bezeichner erzeugt. Daher können
auch die komplexesten Datenstruktu ren einfach im Zeichenkettenformat
dargestellt werden. Im folgenden ist eine Beispielstruktur dargestellt,
wie sie ursprünglich
in IDL beschrieben ist:
-
-
Bei
der Verwendung des Verfahrens gemäß der vorliegenden Erfindung,
würde die
oben beschriebene Datenstruktur in CIN wie folgt dargestellt werden:
„c100+e2+f0+b2+FFf1+b2+KK"
-
In
einer bevorzugten Ausführung
folgt auf positive Zahlen ein Pluszeichen („+"). Negative Zahlen werden durch ein
Negativzeichen („–") abgeschlossen.
Während
negative Zahlen nicht oft auftreten, können sie jedoch für bestimmte
Datentypen erforderlich sein, beispielsweise Variantenfallmarkierungen
(union case labels) (d. h. der Falldiskriminator kann eine negative
Zahl sein). Der oben dargestellte CIN-Bezeichner erklärt sich
wie folgt: ein Datenstruktur bestehend aus einer Folge (c) mit maximal
100 Elementen (100+), jedes Element besteht aus einer Variante (e)
mit zwei Feldern (2+). Wenn der Diskriminator Null ist (FALSE) (f0+),
dann ist eine Variante eine Struktur (b), die zwei Felder enthält (2).
Das erste Feld ist ein signed long (F). Das zweite Feld ist ein
signed long (F). Wenn der Diskriminator 1 ist (TRUE), dann
(f1+) ist die zweite Variante eine Struktur (b), die zwei Felder
(2+) enthält.
Das erste Feld ist ein unsigned long (K). Das zweite Feld ist ein
unsigned long (K).
-
Wenn
in der CIN eine Operation zu beschreiben ist, fährt das Verfahren mit Schritt 151 fort. 6 ist ein Flußdiagramm,
das die Schritte darstellt, welche beim Erzeugen eines Bezeichners
für eine
Operation durchgeführt
werden. Ein Bezeichner für
eine Operation wird in der CIN wie folgt generiert:
operation_synopsis
operation_id
operation_attribut
anz_params
param_1,
param_2 ... param_n;
anz_ausnahmen
ausnahme_1, ausnahme_2
... ausnahme_n
anz_kontexts
kontext_1, kontext_2 ... kontext_n
-
In
dem Schritt 151 erzeugt der Codegenerator eine eindeutige
ganze Zahl (integer), operation_synopsis, die von der Zeichenkette
abgeleitet wird, die den Rest des Bezeichners der Operation darstellt.
Die ganze Zahl (integer) wird abgeleitet, indem beispielsweise ein
zyklischer Redundanztest (CR2) aus den restlichen Zeichen des CIN-Bezeichners
abgeleitet wird. Als nächstes
erzeugt der Codegenerator 112 eine eindeutige Zeichenkette,
operation_id, die von dem ursprünglichen
IDL-Namen der Operation abgeleitet ist. Daraufhin erzeugt der Codegenerator
in Schritt 155, operation_attribut, ein Zeichen, das die
Attribute (keines oder „Einweg") der Operation angibt.
Wenn die Operation beispielsweise kein Einwegattribut hat, wird
das Zeichen A erzeugt. Wenn jedoch das Attribut der Operation „Einweg" ist, erzeugt der
Codegenerator das Zeichen B. Das Zeichen anz_arams ist ein Ganzzahlwert
(Integer), der angibt, wie viele Parameter in der Operation enthalten
sind. Wenn die Operation einen nichtleeren Rückgabetyp hat, dann ist das
Ergebnis der erste Parameter. Der Bezeichner param_1 umfaßt ein Zeichen,
das die Richtung des Parameters (in, out, inout oder Funktionsergebnis)
angibt, gefolgt von einem aktuellen Parameterdatentyp. Der Codegenerator 112 erzeugt beispielsweise
die Buchstaben A, B, C und D für
die jeweiligen Richtungen in, out, inout und Funktionsergebnis.
Für spezielle
Parameter geht das Verfahren zum Schritt 107 in der 5 zurück. Wenn der Datentyp jedes Parameters
bezeichnet ist, wird die Anzahl der Ausnahmen durch den Integerwert
anz_ausnahmen angegeben. Der Strukturbezeichner für jede Ausnahme
wird dann beschrieben, indem zu Schritt 119 zurückgegangen wird,
der Strukturen beschreibt. Der Integerwert anz_kontexte gibt die
Anzahl der Kontextnamen an, die von der Operation vorgesehen sind.
Die Namen werden dann als Zeichenketten, kontext_1, kontext_2, kontext_n erzeugt.
-
Im
folgenden sind zwei Beispieloperationen dargestellt, die ursprünglich in
IDL beschrieben sind:
-
-
Bei
der Verwendung des erfindungsgemäßen Verfahrens
würde sich
die oben beschriebene Add-Operation wie folgt in CIN darstellen:
126861413+3+ADDA3+DFAFAF0+0+
-
Der
CIN-Bezeichner für
die Operation setzt sich wie folgt zusammen. Die Anfangszahl (126861413) wird
von dem Rest der CIN abgeleitet, indem mit der Zeichenkette „3+ADDA3–DFAFAF0+0+" ein zyklischer Redundanztest
durchgeführt
wird. Die Identifikation (ID) der Operation enthält drei Zeichen (3+). Diese
drei Zeichen sind die Zeichenkette „ADD" – die
Kennzeichnung der Operation. Alle IDL-Kennzeichner müssen eindeutig
und fallunabhängig
sein. Daher wird die ID der Operation groß geschrieben. Die Operation
umfaßt
nicht das Einwegattribut (A). Die Operation umfaßt drei „Parameter" (3+). Da die Funktion ein Ergebnis
zurückgibt, ist
der erste „Parameter" in diesem Fall ein
Funktionsergebnis (D). Das Funktionsergebnis ist ein signed long (F).
Der nächste
Parameter (in diesem Fall der erste Parameter) ist ein In-Parameter
(A). Der Parameter ist von dem Typ signed long (F). Der dritte Parameter
ist ein In-Parameter (A) von dem Typ signed long (F). Es gibt keine
Ausnahmen (0+) und keine Kontexte (0+).
-
Dementsprechend
wäre der
CIN-Bezeichner für
die Subtract-Operation:
453399302–9+SUBTRACTA3+DFAF0+0+
-
In
gleicher Weise beschrieben werden Schnittstellen, indem das erfindungsgemäße Verfahren
verwendet wird. Die 7 zeigt
die Erzeugung eines Schnittstellenbezeichners. Schnittstellen sind
wie folgt definiert:
anz Operationen
operation_spez_1
operation_spez_2
operation_spez_n
-
Die
ganze Zahl, anz-operationen, gibt an, wie viele Operationen in der
Schnittstelle enthalten sind. Jede Operation wird dann gemäß des oben
beschriebenen Verfahrens zum Erzeugen eines Operationsbezeichners
anhand operation_spez_1, operation_spez_2, operation_spez_n beschrieben.
Der Codegenerator 112 geht daher zu Schritt 151 in 6 über, um jede Operation zu beschreiben.
-
Unter
Verwendung des erfindungsgemäßen Verfahrens
würde sich
die oben beschriebene Math-Schnittstelle in der CIN wie folgt darstellen:
2+126861413+3+ADDA3+DFAFAF0+0+453399302–9+SUBTRACTA3+DFAF0+0+
-
Die
Schnittstelle umfaßt
zwei Operationen (2+). Die Operationsbezeichner für die Add-
und Subtract-Operationen folgen auf das Zeichen, das die Anzahl
der Operationen angibt.
-
Wie
oben bemerkt, sind die CIN-Bezeicher in einer Headerdatei enthalten,
die sowohl mit der Client- als auch mit der Serveranwendung verlinkt
wird. Daher können
sowohl der Client als auch der Server den Bezeichner verwenden,
da er für
beide paßt.
Die CIN kann in vielfacher Hinsicht verwendet werden. Beispielsweise
kann ein CIN-Bezeichner eines Datentyps bei dem Erzeugen von generischen
Funktionen hilfreich sein, um strukturierte Datentypen zu packen
und zu entpacken.
-
CIN-Bezeichner
können
auch verwendet werden, um Schnittstellen schnell zu vergleichen.
Beispielsweise kann eine Serveranwendung eine Headerdatei haben,
die zwei Schnittstellen enthält,
welche in CIN beschrieben sind. Der Server kann dann die ASCII-Zeichenkettenbezeichner
vergleichen, indem bekannte Funktionen zum Vergleich von Zeichenketten
verwendet werden. Wenn der Server ermittelt, daß die CIN-Bezeichner gleich
(oder ähnlich)
sind, kann der Server die Operationen beider Schnittstellen implementieren,
indem gemeinsame Methoden der Serveranwendung verwendet werden.
Daher kann die CIN verwendet werden, um die Zeit zu sparen, die
zum Codieren verschiedener Methoden für verschiedene (aber gleiche)
Schnittstellen verwendet wird.