DE69331440T2

DE69331440T2 - Verfahren und system zur durchführung von fernprozeduranrufen in einem verteilten rechnersystem.

Info

Publication number: DE69331440T2
Application number: DE69331440T
Authority: DE
Inventors: J. Davidson; Michael T. Kelley
Original assignee: Tandem Computers Inc
Current assignee: Tandem Computers Inc
Priority date: 1992-08-28
Filing date: 1993-08-26
Publication date: 2002-08-22
Anticipated expiration: 2013-08-27
Also published as: DE69331440D1; JPH08504975A; EP0657047A4; EP0657047A1; WO1994006083A1; US5307490A; EP0657047B1

Description

Hintergrund der Erfindung

1. Gebiet der Erfindung

Die vorliegende Erfindung bezieht sich auf verteilte Computersysteme und bezieht sich insbesondere auf die Verwendung von Fernprozeduraufrufmechanismen in verteilten Computersystemen.

2. Beschreibung des Stands der Technik

In einem verteilten Computersystem kann der Wirkungsgrad durch Aufteilen von Resourcen (z. B. eines Dateisystems) unter zahlreichen Rechnern in dem System verbessert werden. Außerdem können in solch einem System mehrere Rechner zusammenwirkend verwendet werden, um eine gemeinsame Aufgabe durchzuführen. Eine Anzahl von Kommunikationsparadigmen sind entwickelt worden, um ein Netzwerk von Rechnern zu strukturieren, um diesen Rechnern zu erlauben, zusammenwirkend zu arbeiten oder Resourcen zu teilen bzw. gemeinsam zu benutzen. Unter diesen Paradigmen befindet sich das "Client-Server"-Modell. Bei dem Client-Server-Modell sind ein oder mehrere Rechner (die "Server") damit betraut, Dienste bereitzustellen, welche andere Rechner (die "Clients") in dem verteilten Rechnersystem anfordern können, entweder durch Weiterreichen von Nachrichten an die Server oder durch Anstoßen von Fernprozeduraufrufen. In dem Client-Server-Paradigma leitet der Client eine Dienstanforderung ein, und der Server reagiert auf eine solche Dienstanforderung.
Ein Fernprozeduraufruf ist ein Mechanismus, durch welchen ein Programm, welches in einem Prozeßraum eines Computers bzw. Rechners abläuft, bewirkt, daß eine Prozedur in einem Prozeßraum eines anderen Rechners ("entfernter Rechner") ausgeführt wird. Bei einer Implementierung des Client-Server-Paradigmas bewirkt ein Client-Prozeß einen Fernprozeduraufruf, um den angeforderten Dienst in einem Server-Prozeß zu aktivieren. Eine günstige Implementierung des Server-Prozesses ist ein Daemon-Prozeß. Ein Daemon-Prozeß ist ein Rechnerprozeß, welcher Nachrichten von anderen Prozessen empfängt und welcher, einmal begonnen, in dem Rechner resident ist, bis eine "kill"-Nachricht von einem anderen Prozeß empfangen wird, ein Zeitgeber ausläuft, oder wenn alle erwarteten Nachrichten empfangen sind. Solch ein Daemon- Prozeß wird oft verwendet, um eine gemeinsam benutzte Ressource zu verwalten. Zum Beispiel empfängt ein Daemon- Prozeß für eine Druckerwarteschlange Nachrichten von Prozessen, welche die Verwendung von einem oder mehreren mit der Druckerwarteschlange in Verbindung stehenden Druckern erfordern. Um eine Druckoperation herbeizuführen, sendet ein Anforderungsprozeß eine Druckanforderung an den Daemon-Prozeß, welcher, sofern geeignet, die erforderlichen Druckprozesse vorbereiten und planen würde, um die Druckanforderungen zu erfüllen. Der Daemon-Prozeß sorgt für Effizienz, nachdem Aufgaben, welche druckerspezifische Informationen erfordern, dem Daemon-Prozeß zugewiesen und den anfordernden Prozessen abgenommen werden. Man sagt, daß der Daemon-Prozeß "schlafend" ist, während er auf eine Nachricht von einem anfordernden Prozeß wartet, und "wach" ist, wenn er seine zugewiesene Aufgabe ausführt.
Moderne Computerprogramme sind so konzipiert, daß sie die Vorteile von Modularisierung und Datenabstraktion ausnutzen. Modularisierung gestattet, daß ein komplexes System bei definierten funktionalen Schnittstellen in untereinander zusammenhängende Subsysteme unterteilt ist. Die Implementierungskomplexitäten aller Subsysteme sind daher von anderen Subsystemen abgeschirmt ("bezüglich dieser transparent") und können daher in hohem Maße unabhängig von anderen Subsystemen entwickelt und modifiziert werden.
Datenabstraktion vereinfacht die Aufgabe der Programmierung durch die Verwendung von Datenstrukturen hohen Niveaus, welche eine logische oder konzeptionelle Darstellung der Objekte sind, welche die Daten darstellen. Somit erlaubt Datenabstraktion dem Programmierer, Daten eher auf einem konzeptionellen bzw. begrifflichen Niveau zu verwalten, als Daten als eine Sammlung primitiver Datentypen zu verwalten.
Idealerweise sollte eine geeignete Modularisierung einem Anwendungsprogrammierer erlauben, Dienste des Betriebssystems anzustoßen, z. B. den Status eines Druckauftrags ohne Kenntnis der Feinheiten in Bezug darauf, wie der Dienst beschafft wird oder wo der Dienstanbieter lokalisiert ist, anzufordern. Außerdem sollte eine Unterstützung von Datenstrukturen hohen Niveaus bereitgestellt sein, um einem Anwendungsprogramm zu erlauben, eine Schnittstelle zu einem anderen Programm zu bilden, ohne die Datenstrukturen hohen Niveaus des Anwendungsprogramms in Primitive niedrigeren Niveaus zu zerlegen.
Im Gegensatz zu den Zielen von Datenabstraktion und Modularisierung sind, auch wenn verteilte Rechnersysteme in großem Umfang verwendet worden sind, Fernprozeduraufrufe in sprachunabhängigen Rahmenwerken implementiert. Infolgedessen können nur Datenstrukturen vergleichsweise niedrigen Niveaus zwischen den in dem Fernprozeduraufruf involvierten Computerprozessen weitergereicht werden, was vom Anwendungsprogrammmierer verlangt, ein verteiltes Objekt speziell zu behandeln. Solche Erfordernisse bringen eine Modularisierung zu Fall.
Ferner ist, da ein geeigneter Mechanismus zum Kommunizieren von Datenstrukturen hohen Niveaus nicht verfügbar ist, die Datenstruktur eines Anwendungsprogramms oft in dem Anwendungsprogrammcode explizit zerlegt, um die zum Kommunizieren von Daten über Maschinengrenzen hinweg notwendigen Datenstrukturen niedrigen Niveaus zu erzeugen. Die Übertragbarkeit und Zuverlässigkeit solcher Anwendungsprogramme werden beeinträchtigt.
Daher ist ein Mechanismus eines hohen Abstraktionsgrad erwünscht, um Anwendungsprogramme davor zu bewahren, daß sie sich für Fernprozeduraufrufe vorbereiten müssen. Zum Beispiel sollten Fernprozeduraufrufe für den Anwendungsprogrammierer transparent gemacht werden. Das heißt, der Mechanismus sollte gestatten, daß ein Anwendungsprogramm ohne Kenntnis oder Erfordernis, daß bestimmte Datenstrukturen des Anwendungsprogramms auf durch eine entfernte Maschine gesteuerte Ressourcen implementiert werden oder von ihnen abhängig sein müssen, geschrieben wird.
Weitere Informationen bezüglich des Stands der Technik können in EP-A-474339 gefunden werden, welche sich auf Verfahren und Vorrichtung zum Bereitstellen einer Client-Schnittstelle für einen objektorientierten Aufruf einer Anwendung bezieht. In Übereinstimmung mit der Lehre dieser EP-Veröffentlichung umfaßt in einem Datenverarbeitungsnetzwerk, welches:
- eine Mehrzahl von Datenverarbeitungsplattformen zum Ausführen von Anwendungen, und
- eine Klassendatenbank mit Abschnitten, welche für alle der Datenverarbeitungsplattformen zugreifbar ist, aufweist, wobei die Klassendatenbank:
1) eine Mehrzahl von Methodeneinträgen, von denen jeder eine Referenz auf einen Mechanismus zum Aufrufen einer Entsprechenden der auf einer Server-Datenverarbeitungsplattform auszuführenden Anwendung enthält, und
2) eine Mehrzahl von Klasseneinträgen, von denen jeder Informationen enthält, welche eine entsprechende Gruppe der Methodeneinträge identifizieren und eine unterschiedliche, eindeutig identifizierbare Klasse identifizieren, wobei jede der Klassen durch einen unterschiedlichen Satz von Instanzen referenziert wird, wobei Instanzen Datenfelder sind, welche durch die Anwendungen manipuliert werden können oder auf welche von diesen zugegriffen werden kann, und alle die Instanzen in jedem Satz gemeinsam benutzte Eigenschaften aufweisen,
enthält, ein Prozeß eines Aufrufens einer Anwendung, welche auf der Server-Datenverarbeitungsplattform auszuführen ist, von einer Client-Anwendung, welche auf einer Client-Datenverarbeitungsplattform abläuft, die durch die Client-Datenverarbeitungsplattform ausgeführten Schritte:
1) Empfangen einer Nachricht von der Client-Anwendung für die Durchführung einer eine erste Instanz involvierenden Datenverarbeitungsoperation;
2) Zugreifen auf die Klassendatenbank unter Verwendung der durch die erste Instanz referenzierten Klasse und der empfangenen Nachricht, um einen ersten Methodeneintrag und einen entsprechenden Mechanismus zum Aufrufen einer Server-Anwendung auszuwählen; und 3) Auswählen der Server-Datenverarbeitungsplattform, um die Server-Anwendung auszuführen, aus den Datenverarbeitungsplattformen.

Zusammenfassung der Erfindung

In Übereinstimmung mit der Erfindung werden die zuvor erwähnten Aufgaben durch die Struktur des unabhängigen Anspruchs 1 wie auch das entsprechende Verfahren des unabhängigen Anspruchs 2 erreicht. Bevorzugte Ausführungsformen der Erfindung sind in den abhängigen Ansprüchen definiert.
In Übereinstimmung mit der vorliegenden Erfindung wird eine Fernprozeduraufrufstruktur und ein -verfahren, welche Datenstrukturen hohen Niveaus unterstützen, durch die Verwendung einer gemeinsamen Datenstruktur oder Klasse ("Basis"-Klasse) bereitgestellt. Durch Verwenden der gemeinsamen Datenstruktur, um ein verteiltes oder gemeinsam benutztes Objekt abzuleiten, kann ein Vorprozessor aufgebaut sein, um automatisch sowohl Client- als auch Server-Stub-Routinen für einen Fernprozeduraufruf zu erzeugen. Ein Anwendungsprogramm, welches die Server-Routinen aufruft, kann an die Server-Routine Daten hohen Niveaus in der gleichen Weise übergeben, wie sie die gleichen Datenstrukturen an eine lokale Routine übergibt.
In einer Ausführungsform der vorliegenden Erfindung wird der Server als ein Daemon-Prozeß zur Systeminitialisierungszeit erzeugt. Der Server erzeugt ein Fernprozeduraufruf-Serverobjekt ("RpcServer"), welches ein oder mehrere Fernprozeduraufruf-Clientobjekte ("RpcClients") unterbringt. Ein in dem Client erzeugter RpcClient schafft einen Kommunikationskanal zwischen dem RpcServer auf dem Server und dem Client. Außerdem wird ein RpcClient auch auf dem Server erzeugt, um eine asynchrone Kommunikation zwischen dem Server und dem Client bereitzustellen.
Wenn ein RpcClient in dem Client erzeugt wird, wird ein "Manifest" an den RpcServer gesendet, welcher durch Senden seines eigenen Manifests an den RpcClient antwortet. Ein Manifest enthält Klassen-Metainformationen jeder Klasse in dem entsprechenden Server oder Client. Solche Klassen-Metainformationen enthalten für jede Klasse: (i) einen "Typencode", welcher die Klasse identifiziert, (ii) den Klassennamen, (iii) die Anzahl von Basisklassen, (iv) die Namen aller Basisklassen, sofern vorhanden, von welchen die Klasse abgeleitet ist. Außerdem sieht das Manifest für jedes geteilte Objekt auch vor: (i) den Typencode des gemeinsam benutzten Objekts, und (ii) einen Index in eine Liste gemeinsam benutzter Objekte in der Umgebung des Manifestsenders, wobei eine solche Liste für jedes gemeinsam benutzte Objekt einen Zeiger zu dem gemeinsam benutzten Objekt enthält.
Ein verteiltes oder gemeinam benutztes Objekt ist durch die Kombination eines in dem Server implementierten Stammobjekts ("Master") und eines oder mehrerer in dem Client implementierten abhängigen Objekts ("Slave") implementiert. Sowohl der Master als auch der Slave sind von der gleichen gemeinsamen Basisklasse abgeleitet. Um eine Übereinstimmung zwischen dem Master und jedem seiner Slaves aufrechtzuerhalten, wird, nachdem sich der Master und seine Slaves in unterschiedlichen Speicherräumen befinden, der Master mit einem Schlüssel, um einen Fernprozeduraufruf zu gestatten, ausgestattet, um einen Zeiger zu dem Slave in dem Speicherraum des Slaves zu erhalten, und jeder Slave ist mit einem Schlüssel zu dem Master in dem Speicherraum des Masters ausgestattet. Somit kann ein Fernprozeduraufruf daraufhin, daß das entfernte Objekt nur einen Schlüssel zu dem entfernten Objekt weiterreicht, arbeiten.
Die vorliegende Erfindung bewahrt die Semantik lokaler Prozeduraufrufe durch das Erfordernis, daß der Slave auf den Rücksprung des Fernprozeduraufrufs wartet. Die Semantik lokaler Prozeduraufrufe wird auch durch einen Fehlerbehandlungsmechanismus bewahrt, welcher (i) Ausnahmen in dem Speicherraum des Servers fängt, (ii) die Ausnahme an den Client zurückreicht, wobei (iii) der Client wiederum die Ausnahme zur Behandlung an das geeignete Programmniveau zurückreicht. In dem Anwendungsprogramm erscheint die entfernte Ausnahme nicht anders als eine Ausnahme, welche durch eine lokal ausgeführte Prozedur erzeugt wird.
In einer Ausführungsform werden RpcClients auch in dem Server erzeugt, um dem Server zu gestatten, mit Slaves eines Masterobjekts zu kommunizieren. In dieser Ausführungsform werden Nachrichtendaemonen zum Aussenden von Nachrichten an die Slaves durch den Server erzeugt. Jeder Slave liefert dem Master einen Schlüssel, welcher zur Übersetzung in einen Zeiger zu dem Slave durch den RpcClient des Servers dem Client präsentiert werden kann. Dieser Zeiger zu dem Slave kann verwendet werden, um eine Methode für den Slave aufzurufen, um die Nachricht von dem Nachrichtendaemon zu empfangen.
Ferner erzeugt in Übereinstimmung mit der vorliegenden Erfindung ein automatisches Programm sowohl Client- als auch Server-Stub-Routinen zum Aufrufen einer Methode in einem verteilten Objekt.
Weil die vorliegende Erfindung eine Unterstützung für verteilte Objekte in dem Kontext einer Datenstruktur vergleichsweise hohen Niveaus wie etwa einer C++-Klasse vorsieht und die Semantik lokaler Aufrufe bewahrt, können verteilte Objekt in einer für den Anwendungsprogrammierer transparenten Weise implementiert werden, wodurch Robustheit und Wartbarkeit der verteilten Objekte verbessert werden. Die vorliegende Anwendung vereinfacht Anwendungsprogramme, welche verwendet werden, um ein verteiltes Computersystem zu steuern.
Die vorliegende Erfindung wird unter Berücksichtigung der nachstehenden genauen Beschreibung und der begleitenden Zeichnungen besser verstanden werden.

Kurze Beschreibung der Zeichnungen

Fig. 1 zeigt die Deklarationen der Klassen SharedThang, SharedThangId und RemoteId in einer Ausführungsform der vorliegenden Erfindung.
Fig. 2 ist ein Blockdiagramm, welches die Prozeßräume eines Server-Prozesses und eines Client-Prozesses in einer Ausführungsform der vorliegenden Erfindung zeigt.
Fig. 3a ist ein Blockdiagramm, welches die beim Erzeugen eines Vererbungsbaums involvierten Schritte unter Verwendung eines Makros GIFTS_DECLARE und eines Programms GenType zeigt.
Fig. 3b ist ein Protokoll einer Skriptdatei chomp.cpp, welches die _magic_ -Symbole, welche ein Programm GenType verwendet, um einen Vererbungsbaum bereitzustellen, extrahiert, in Übereinstimmung mit der vorliegenden Erfindung.
Fig. 4a ist ein Blockdiagramm, welches ein Programm, welches einen Daemon-Prozeß Sectd implementiert, veranschaulicht.
Fig. 4b ist ein Protokoll eines Programmsegments Sectd.C, welches in einem Server-Prozeß Sectd der vorliegenden Ausführungsform ausgeführt wird.
Fig. 4c ist ein Protokoll einer Routine SectdProg_1, welche durch einen RPC-Mechanismus 204 aufgerufen wird, um eine Prozedur in Sectd aufzurufen.
Fig. 5 ist ein Blockdiagramm, welches die Erzeugung eines Objekts der Klasse RpcServer veranschaulicht, welches verwendet wird, um eine Kommunikation zwischen dem Prozeß Sectd der vorliegenden Ausführungsform und seinen Clients bereitzustellen.
Fig. 6a und Fig. 6b sind jeweils ein Blockdiagramm des Programmcodes, welcher ein Objekt der Klasse SectClientController implementiert, und ein Protokoll des Programmcodes.
Fig. 7a und 7b sind jeweils die Blockdiagramme der Stub-Routinen SectController::startTester und rStartTester, welche durch das Skript oz für die Master- und Slave-Objekte erzeugt werden, welches die verteilte Klasse SectController in SectClientController und Sectd implementiert.
Fig. 8 ist der Quellcode in der Datei SectController.C für die tatsächliche Implementierung der Klasse SectController in Sectd.
Fig. 9a und 9b sind jeweils die Stub-Routinen-Programmsegmente SectController::startTester und rstartTester, welche durch das Script oz über die Klasse StartTester erzeugt werden, wie in den Blockdiagrammen von Fig. 7a und 7b veranschaulicht.
Fig. 10 ist ein Blockdiagramm, welches eine Skript- Datei oz zum Erzeugen von Stub-Routinen für Client- und Server-Prozesse in Übereinstimmung mit der vorliegenden Erfindung veranschaulicht.
Fig. 11 ist ein Beispiel einer Spezifierungsdatei zur Eingabe in das Skript oz von Fig. 10.

Genaue Beschreibung der bevorzugten Ausführungsformen

In dieser detaillierten Beschreibung wird, obwohl die vorliegende Erfindung in beliebigen verteilten Computersystemen unter Verwendung einer beliebigen Programmiersprache implementiert werden kann, eine Ausführungsform der vorliegenden Erfindung unter Verwendung der Programmiersprache "C++" beschrieben. Der Leser sei auf An Annotated C++ Reference Manual von Ellis und Stroustrup, erschienen bei Addison and Wesley, (1990), bezüglich einer Erläuterung der Programmiersprache C++ verwiesen. In dieser Ausführungsform wird auch ein wohlbekanntes Textverarbeitungsprogramm "awk", welches in dem Betriebssystem UNIX läuft, verwendet, um Programmsegmente zu erzeugen. Die Verwendung von awk und anderer ähnlicher Textverarbeitungsprogramme ist für den Fachmann wohlbekannt. Eine Beschreibung von awk kann in Sektion 1 von SunOS Reference Manual, Ausgabe 4.1, (1990), erhältlich bei Sun Microsystems, Mountain View, CA, gefunden werden.
In der nachfolgenden Beschreibung und den begleitenden Zeichnungen sind Namen unter der Programmiersprache C++, welche in den Namen überladener Funktionen und Operatoren beteiligt sind, austauschbar mit ihren äquivalenten signaturkodierten Namen der Programmiersprache C ("verstümmelte Namen") in Übereinstimmung mit den sogenannten "Namensverstümmelungsregeln" verwendet. Der Fachmann wird die Übereinstimmung zwischen verstümmelten und unverstümmelten Namen verstehen, so daß eine detaillierte Beschreibung einer Namensverstümmelung weggelassen wird. Eine Erläuterung der Namensverstümmelungsregeln kann auch in An Annotated C++ Reference Manual gefunden werden.
Die vorliegende Erfindung ist auf alle verteilte Rechnersysteme, welche Fernprozeduraufrufe unterstützen, anwendbar. Ein Beispiel eines solchen Systems ist ein Rechnernetzwerk unter NFS (Network File System), welches von Sun Microsystems, Mountain View, CA, erhältlich ist. Eine Anwendung der vorliegenden Erfindung kann in dem Produkt Gifts von Tandem Computers, Inc. aus Cupertino, CA, gefunden werden. Unter Gifts werden Anwendungsprogramme verwendet, um Hardwarekomponenten entfernter Maschinen zu steuern, zu diagnostizieren und zu konfigurieren. In einer fehlertoleranten Umgebung gestattet die vorliegende Erfindung, daß das Produkt Gifts Hardware steuert, wobei Komponenten vom Dienst hinzugefügt und entfernt werden und Hardware ohne physikalischen Zugriff und Dienstunterbrechung rekonfiguriert wird.
In der nachfolgenden Beschreibung ist ein "Objekt" eine Datenstruktur, welche typischerweise "Attribute" und "Methoden" aufweist. Ein Attribut kann eine Datenstruktur sein, welche mit dem Objekt verbunden ist. Ein Beispiel einer solchen Datenstruktur ist ein Feld von Werten (z. B. Ganzzahlen) oder eine Zustandsvariable, welche beim Darstellen von Zustandsinformationen des Objekts nützlich ist. Eine Methode weist eine oder mehrere Anweisungen auf, welche beim Bewirken mit dem Objekt verbundener, sinnvoller Vorgänge nützlich sind. Eine Methode wird, wenn sie in einer prozeduralen Programmiersprache implementiert ist, typischerweise durch entweder einen Operator oder eine Prozedur dargestellt.
Zusätzlich gehört jedes Objekt zu einer oder mehreren Klassen. Alle Objekte innerhalb einer Klasse sind darin gleich, daß jedes Objekt den gleichen Satz von Attributen und Methoden besitzt. Jede Klasse von Objekten kann verwendet werden, um andere Klassen von Objekten zu definieren. Eine abgeleitete Klasse erbt von einer "Eltern"- Klasse die Attribute und Methoden der Elternklasse und enthält zusätzlich Attribute und Methoden, welche für die abgeleitete Klasse definiert oder bezüglich der Elternklasse modifiziert sind. In dieser Hierarchie wird eine Klasse, von welcher eine oder mehrere andere Klassen abgeleitet sind, eine "Basis"-Klasse genannt.
Eine Ausführungsform der vorliegenden Erfindung sieht eine Basisklasse SharedThang vor, von welcher alle verteilten Objekte abzuleiten sind. Die Klassendefinition von SharedThang und ihre Implementierung werden in den Dateien SharedThang.C und SharedThang.h gefunden. Die Klasse SharedThang besitzt Attribute (i) stid, welches ein Zeiger zu einem Objekt der Klasse SharedThangId ist, und (ii) commonType, welches ein Zeiger zu einem Objekt der Klasse ClassInfo ist. Das Attribut stid zeigt zu einem SharedThangld-Objekt ("SharedThangld"), welches auf eine Liste aller gemeinsam benutzter Objekte ("shared object list") in dem aktuellen Prozeßraum zugreift. Für jedes gemeinsam benutzte Objekt pflegt, falls das gemeinsam benutzte Objekt ein Master ist, sein SharedThangId eine Liste der Slaves des gemeinsam benutzten Objekts ("Slaves"). Ersatzweise hält SharedThangId die Identität des Masters des gemeinsam benutzten Objekts ("Master"), wenn das gemeinsam benutzte Objekt ein Slave ist.
Ein ClassInfo-Objekt besitzt die Attribute (i) type, welches ein die Klasse ("Objektklasse") identifizierender "Typencode" ist, (ii) name, welches eine die Objektklasse identifizierende Zeichenkette ist, (iii) nbases, welches die Anzahl der Basisklassen ist, soweit vorhanden, von welcher die Objektklasse abstammt, (iv) bases, welches ein Feld von Zeigern ist, von denen jeder zu einem Objekt der Klasse ClassInfo zeigt, wobei jedes solche Objekt einer der Basisklassen der Objektklasse entspricht, und (v) xdr, welches ein Zeiger zu einer Routine ist, welche zum Kodieren und Dekodieren eines Objekts der Objektklasse zu und von einem neutralen, zur Übertragung zwischen Computern durch einen Datenpuffer der Klasse XdrBuffer geeigneten Datenformat vorgesehen ist.
Zusätzlich enthält die Klasse ClassInfo die Methoden (i) CastDown, welche verwendet werden kann, um einen Zeiger eines Objekts mit einem Zeiger zu einem anderen in einer Wurzelklasse enthaltenen Objekt auszutauschen, (ii) typeofoder get, welche eine der Objektklasse eines Objekts entsprechende ClassInfo-Struktur zurückgibt, (iii) nameof, welche den Namen der Objektklasse des Objekts zurückgibt, und (iv) traverse, welche jeden Knoten in einem Vererbungsbaum besucht (siehe unten). Die Klassendefinition von ClassInfo und ihre Implementierung werden in ClassInfo.h und ClassInfo.C gefunden. In der vorliegenden Ausführungsform wird ein Objekt der Klasse ClassInfo für (i) jeden unterstützten Datentyp (z. B. Ganzzahlen, Gleitkommazahlen etc.), (ii) jede deklarierte Klasse und (iii) den mit jeder deklarierten Klasse verbundenen Zeigertyp erzeugt.
In SharedThangId werden die slaves und master jeweils durch ein Objekt der Klasse RemoteId darstellt. Jedes RemoteId identifiziert den Gegenpart (oder "Zwilling") eines gemeinsam benutzten Objekts in der entfernten Umgebung. Zum Beispiel weist ein Zwilling eines gemeinsam benutzten Objekts in dem Server (d. h. ein Master) eine Liste slaves von RemoteId-Objekten auf, wobei jedes RemoteId-Objekt einem der Slaves des Masters entspricht. Umgekehrt weist ein Zwilling eines gemeinsam benutzten Objekts in einem Client (d. h. ein Slave) ein RemoteId-Objekt master auf, welches dem Master des Slaves entspricht. Jedes RemoteId-Objekt weist einen Zeiger zu einem Objekt der Klasse RpcClient und einen Index in eine Liste gemeinsam benutzter Objekte einer SharedThangId auf. Nachdem die SharedThangId's des Servers und des Clients typischerweise unterschiedliche Listen gemeinsam benutzter Objekte aufweisen, weist dasselbe gemeinsam benutzte Objekt unterschiedliche Indizes in der Liste gemeinsam benutzter Objekte des Clients und des Servers auf. Der RpcClient identifiziert einen Kommunikationskanal zwischen einem Master und einem Slave und wird nachstehend genauer erläutert.
Fig. 1 stellt die Deklarationen der Klassen SharedThang, SharedThangId und RemoteId bereit. Die Klasse SharedThang liefert die Methoden: (i) id(), welche das Attribut stid zurückgibt, (ii) masterid(), welche die RemoteId des Masters eines SharedThang zurückgibt, und (iii) getCommonType(), welche commonType zurückgibt, was ein Objekt der Klasse ClassInfo ist. Die Klasse SharedThangId liefert die Methoden addClient und addMaster zum Hinzufügen jeweils einer Master-Liste slaves einer einem Slave entsprechenden RemoteId und zum Hinzufügen einer dem Master entsprechenden RemoteId in dem Slave.
In der vorliegenden Ausführungsform wird ein Fernprozeduraufruf durch Ausführen einer RPC-Funktion execute durchgeführt, welche an den RPC-Mechanismus eine "Nachricht" und eine Prozedurnummer übergibt. Die Prozedurnummer identifiziert die Verbindung zwischen den kommunizierenden Programmen, und die Nachricht ist in einem Puffer ("message") der Klasse XdrBuffer enthalten. Die Definition und Implementierung von XdrBuffer sind in den Dateien XdrBuffer.h und XdrBuffer.C enthalten. Um ein von der Klasse Thang (von welcher sich SharedThang ableitet) abgeleitetes Objekt in eine Nachricht zu kodieren oder von einer Nachricht zu dekodieren, wird eine Methode xdr in dem ClassInfo-Objekt der Klasse des Objekts durch den Klassenimplementierer bereitgestellt.
In einer Nachricht der vorliegenden Ausführungsform besitzt ein kodiertes Objekt die Felder: (i) byte_count, welches die Größe in Bytes des kodierten Objekts ist, und (ii) eine Liste von subrecords. Jeder subrecord besitzt die Felder: (i) type_tag, welches der Typencode eines enthaltenen Objekts ist, (ii) byte_count, welches die Größe in Bytes des subrecords ist, (iii) primitives, welches eine Liste primitiver Datenstrukturen ist, und (iv) eine Liste von subrecords.
Fig. 2 veranschaulicht die Prozeßräume einer Servermaschine und einer Clientmaschine in einer Ausführungsform der vorliegenden Erfindung. In der Servermaschine 200 ist ein RPC-Mechanismus 204 ein herkömmliches Anwendungsprogramm, welches für andere Anwendungsprogramme eine Fernprozeduraufrufschnittstelle bereitstellt, um auf die zwischenmaschinellen Kommunikationsdienste niedrigen Niveaus im Kernel 250 der Servermaschine 200 zuzugreifen. In analoger Weise stellt ein Rpc-Mechanismus 203 eine herkömmliche Anwendungsprogrammschnittstelle für andere Anwendungsprogramme bereit, um auf die zwischenmaschinellen Kommunikationsdienste des Kernels 251 zuzugreifen. Typischerweise sind die Kopfdateien des Rpc-Mechanismus, wie die Rpc-Mechanismen, 203 oder 204, mit einem Anwendungsprogramm kompiliert, um eine herkömmliche Programmschnittstelle bereitzustellen. Kernel 250 und 251 steuern die zugrundeliegende physikalische Verbindung, z. B. ein Netzwerk oder Busprotokoll zwischen den miteinander verbundenen Rechnern. In der vorliegenden Ausführungsform können die miteinander verbundenen Rechner von sehr unterschiedlicher Architektur sein.
Für jedes in der vorliegenden Ausführungsform implementierte verteilte Objekt wird ein "Master" des verteilten Objekts in einem Serverprozeß erzeugt, repräsentiert durch Server 206, um den tatsächlichen lokalen Prozeduraufruf anzustoßen. Um auf eine Methode in den Masterobjekt zuzugreifen, ist es erforderlich, den Schlüssel, welcher ein Index in die Liste gemeinsam benutzter Objekte des Servers 206 (d. h. die Liste aller SharedThang's im Server 206) gegen einen Zeiger zu dem Masterobjekt im Speicherraum des Servers 206 auszutauschen. Nachdem ein Zeiger in der Liste gemeinsam benutzter Objekte ein Zeiger zu einem in dem Master enthaltenen Objekt (Klasse SharedThang) ist, muß, falls es notwendig ist, eine Memberfunktion eines anderen in dem Master enthaltenen Objekts (etwa Klasse foo, welche von Klasse SharedThang abgeleitet ist) zu aktivieren, der Zeiger zu SharedThang von der Liste gemeinsam benutzter Objekte gegen einen Zeiger zu dem enthaltenen foo-Objekt ausgetauscht werden. Dieser Prozeß, welcher "Downcasting" genannt wird, wird durch die Memberfunktion CastDown der Klasse ClassInfo durchgeführt. Um CastDown zu implementieren, ist es erforderlich, die Klassenableitungsgeschichte der Klassen aller gemeinsam benutzter Objekte zu kennen. In der vorliegenden Ausführungsform wird die Ableitungsgeschichte bereitgestellt durch Verwenden (i) eines Makros GIFTS_DECLARE, um die Deklarationen jeder Klasse gemeinsam benutzter Objekte zu modifizieren, (ii) um aus dem durch den Vorprozessor cpp erzeugten Code eine Liste gemeinsam benutzter Objektklassen zu extrahieren, und (iii) Bereitstellen einer solchen Liste an ein selbständiges Programm GenType, um einen Code in der Sprache C zu generieren, welcher kompiliert werden kann, um einen Laufzeit-Vererbungsbaum auszubilden. Dieser Prozeß wird durch das Blockdiagramm von Fig. 3a veranschaulicht.
Wie in Fig. 3a gezeigt, wird bei Schritt 301 ein Makro GIFTS_DECLARE bereitgestellt, um in die Deklaration jeder von der Klasse Thang abgeleiteten Klasse ("Objektklasse") die Deklarationen einzufügen: (i) einer Memberfunktion _typeof(), (ii) einer Anzahl von Symbolen, wobei jedes Symbol die Kettung der Zeichenkette "_magic_" und den Namen einer Basisklasse, von welcher sich die Objektklasse ableitet, bereitstellt, und (iii) einer Zeichenkette _nameof, welcher der Name der Objektklasse zugewiesen ist. Als ein Ergebnis des Makros GIFTS_DECLARE wird die Kompilierung dieser zusätzlichen Deklarationen in der Symboltabelle jeder Klasse eine Anzahl von Symbolen enthalten, welchen die Zeichenkette "_magic_" vorangestellt ist. Diese Symbole werden in der vorliegenden Erfindung verwendet, um die Ableitungsmöglichkeiten jeder von der Klasse Thang abgeleiteten Klasse zu kodieren. Das Makro GIFTS_DECLARE ist in macros.h aufgelistet.
In Schritt 302 extrahiert eine "Skript"-Datei chomp.cpp unter Verwendung eines Textverarbeitungsdienstprogramms egrep aus den Symboltabellen kompilierter Objektdateien die eingefügten Symbole, welchen die Zeichenkette "_magic_" vorangestellt ist. Diese Symbole werden dann dem selbständigen Programm GenType zugeführt (Schritt 303 zugeführt), welches in UNIX von einem Befehlszeileninterpreter oder einer "Shell" aus läuft. Diese Symbole gestatten GenType, einen Vererbungsbaum bezüglich aller von Thang abgeleiteten Klassen von Objekten aufzubauen. Chomp.cpp ist in Fig. 3b aufgelistet. Der Vererbungsbaum enthält (1) ein Feld list, welches ein Feld ist, welches die ClassInfo-Strukturen entsprechend allen Klassen, Zeigern zu Klassen und unterstützten primitiven Datentypen enthält; und (ii) für jede Klasse ("Objektklasse") gemeinsam benutzter Objekte ein Feld von Zeigern zu ClassInfo, wobei jedes Element des Feldes zu einer Basisklasse zeigt, von welcher die Objektklasse abgeleitet ist.
GenType gibt den in Schritt 303 in C-Code aufgebauten Vererbungsbaum aus, welcher kompiliert wird, um den Vererbungsbaum als eine statische Datenstruktur sowohl im Server- als auch Client-Adreßraum zu erzeugen. Zusätzlich generiert GenType auch den Code, um die _ tpyeof()-Memberfunktion für jede Klasse zu implementieren. Die _typeof()-Funktion greift auf die list-Datenstruktur zu, um den Typencode eines Objekts wiederzugewinnen. Der Quellcode für GenType ist als GenType.C bereitgestellt.
Wie zuvor diskutiert, ist, unter der Voraussetzung eines Zeigers zu einem Thang-Objekt, welches in einem größeren Objekt enthalten ist, der Zweck der ClassInfo- Memberfunktion CastDown, einen Zeiger zu entweder einem anderen in dem größeren Objekt enthaltenen Objekt oder dem größeren Objekt selbst wiederzugewinnen. Die für das Downcasten vorgesehene Klasse wird CastDown mit ihrem Namen bereitgestellt. Um einen Zeiger zu dem größeren Objekt zu erhalten, wird eine Funktion root aufgerufen, um den Zeiger "root" des größeren Objekts zurückzugeben. Falls das Downcasten sich auf ein in dem größeren Objekt enthaltenes Objekt bezieht, durchquert CastDown den Vererbungsbaum von der ClassInfo von "root", zurückgegeben von der ClassInfo-Memberfunktion get, in einem Versuch, die vorgesehene Klasse zu erreichen. Falls eine zu dem Namen der vorgesehenen Klasse passende Klasse erreicht ist, berechnet CastDown einen Zeiger zu dem größeren Objekt unter Verwendung des Offsets zwischen der Destruktorfunktion und dem this-Zeiger in jedem in dem Ableitungsweg eingreifenden Objekt. (In der Programmiersprache C++ ist jedes Objekt mit einem Zeiger this ausgestattet, welcher zu dem Objekt selbst zeigt.) Falls der berechnete Zeiger zu dem größeren Objekt zu dem von root zurückgegebenen Zeiger paßt, ist das Downcasten erfolgreich, und der Zeiger zu dem in der angestrebten Klasse enthaltenen Objekt wird zurückgegeben. Anderenfalls wird der Vererbungsbaum weiter durchquert nach einem anderen Vererbungsweg, welcher die vorgesehene Klasse erreicht. Diese Prozedur ist erforderlich, da die Sprache C++ mehrfache Vererbungswege erlaubt.
Server 206 ist normalerweise als ein Daemon implementiert. Fig. 4a ist ein Blockdiagramm des Programms, welches eine Daemon Sectd (System Exercise and Confidence Test Daemon) implementiert. Daemon Sectd beherbergt ein Master-Objekt SectController. Sectd und SectController sind jeweils durch die Programmsegmente Sectd.C und SectController.C implementiert, welche in Fig. 4b und 8 aufgelistet sind. Wie in Fig. 4a gezeigt, wird Sectd als ein Anwendungsprogram (d. h. Server 206) unter Verwendung der Benutzerschnittstelle Gifts gestartet (Schritt 401). Sectd erzeugt dann den Master für das verteilte Objekt SectController (Schritt 402) durch Aufrufen der "Server"-seitigen Konstruktorroutine. Wie in dem Programmsegment Sectcontroller.C von Fig. 8 gezeigt, ist eine Methode startTester die einzige in Sectd implementierte Methode der Klasse SectController. Im allgemeinen sind Methoden eines gemeinsam benutzten Objekts nur auf der Serverseite implementiert.
Die Konstruktorroutine (Serverseite) für SectController gibt einen Zeiger für das erzeugte SectController-Objekt zurück (Schritt 403). Um mit seinen Clients zu kommunizieren, erzeugt Sectd ein Kommunikationsserverobjekt RpcServer (Schritt 404). RpcServer wird verwendet, um Kommunikation zwischen RPC-Mechanismus 204 und Sectd zu filtern. Fig. 5 ist ein Blockdiagramm, welches eine Implementierung eines RpcServers veranschaulicht. RpcServer ist durch zwei Programmsegmente RpcServer.h und RpcServer.C implementiert. Nach Erzeugen des RpcServers geht Sectd schlafen, wobei es auf Dienstanforderungen von Client-Objekten wie etwa Client 207 der Client-Maschine 251 wartet. Der Fernprozeduraufrufmechanismus 204 ruft eine Routine SectdProg_1 (aufgelistet in Fig. 4c) auf, welche eine Routine in Sectd in Übereinstimmung mit einem von einem Client-Objekt empfangenen Handle aufruft.
Wie in Fig. 5 gezeigt, erzeugt Sect einen RpcServer durch Aufrufen der Konstruktorroutine eines RpcServer bei Schritt 501. Diese Konstruktorroutine (i) ruft eine Systemroutine svc_register auf, um einen Transportniveaudienst zum Kommunizieren zwischen RPC-Mechanismus 204 und Sectd zu erzeugen (Schritt 502), und (ii) registriert den RpcServer in dem Registerdienst des Netzwerks (Schritt 503). Der Registerdienst des Netzwerks stellt einen Nachschlagedienst in dem Netzwerk zum Lokalisieren von Programmen bereit. Das Register des Netzwerks empfängt einen Wirtsmaschinennamen, den Programmnamen und eine Version und gibt einen Handle an das angeforderte Programm zurück. Ein Eintrag in dem Netzwerkregisterdienst erlaubt einem entfernten Programm, in einem Fernprozeduraufruf unter Verwendung der Programmnummer auf den RpcServer zuzugreifen.
Für jede Methode des verteilten Objekts ist eine Stub-Routine in Sectd und jedem seiner Clients, wie etwa Client 207, vorgesehen. Somit sind, wie in Fig. 2 gezeigt, um einen Fernprozeduraufruf für die Methode StartTester von SectController vorzubereiten, "Stub"-Routinen 202 und 201 vorgesehen, um jeweils in Prozeßräumen von Sectd und Client 207 ausgeführt zu werden. Stub-Routinen 201 und 202 führen typischerweise das durch, was "Marshalling" und "Unmarshalling"-Operationen genannt wird. Marshalling bildet maschinenabhängige Datenstrukturen aus den formalen Parametern des Methodenaufrufs (z. B. Zeiger zu einem Feld) einer Maschine in eine "neutrale" Datenstruktur um, welche an die potentiell unterschiedliche Umgebung einer anderen Maschine übergeben werden kann. Unmarshalling bildet das neutrale, zwischen den Umgebungen ausgetauschte Format in maschinenabhängige Datenstrukturen ab. Wenn zum Beispiel ein Anwendungsprogramm 208 eine Client-Stub-Routine 201 mit einer Liste von Argumenten in maschinenabhängigen Datenstrukturen aufruft, führt die Client-Stub-Routine 201 das Marshalling durch und sendet die gemarshallten Argumente, üblicherweise in der Form einer zwischenprozessualen Nachricht, an RPC-Mechanismus 203. Der RPC-Mechanismus 203 und dessen Gegenstück, RPC-Mechanismus 204, fordert vom Kernel 251 Systemdienste (z. B. Anschlüsse und Protokolle) zum Kommunizieren über Maschinengrenzen hinweg an. Die durch RPC-Mechanismus 203 gesendeten gemarshallten Argumente werden durch RPC-Mechanismus 204 empfangen, welcher wiederum die gemarshallten Argumente an Sectd übergibt. Sectd, welcher ein Daemon-Prozeß ist, ruft eine Stub-Routine 202 auf, um die empfangenen Argumente zu unmarshallen. Die Stub-Routine 202 übergibt dann die ge-unmarshallten Argumente an die lokale Prozedur 205 (z. B. "startTester 14SectControllerFRUiRC5Twine") (Der Name dieses Programms ist ein Beispiel eines verstümmelten Namens. Der erste Teil des Namens, welcher vor dem "_" steht, ist der Name der C++-Memberfunktion, und der zweite Teil des Namens, welcher auf "_" folgt, ist der Signaturanteil. Der Signaturanteil kodiert die Parameterliste zu dieser Memberfunktion. Verstümmelte Namen erlauben eine Implementierung eines "Überladens" in der Programmiersprache C++ ohne Modifizieren der Sprache C. Ein C++- Programm wird, nachdem ein Vorprozessor cpp aus dem C++-Programm einen Quellcode in der Programmiersprache C generiert, typischerweise durch einen C-Compiler kompiliert), welche den
tatsächlich angeforderten Dienst der Methode StartTester implementiert. Ergebnisse, sofern vorhanden, werden von der lokalen Prozedur 205 an die Stub-Routine 202 zurückgegeben, welche die Ergebnisse zur Rückgabe an Client 207 marshallt. Rückgabe von Ergebnissen von Sectd an Client 207 folgt in umgekehrter Reihenfolge im wesentlichen dem Weg der gemarshallten Argumente. Stub-Routine 201 unmarshallt das Ergebnis, welches dann an Anwendungsprogramm 208 zurückgegeben wird. Es gibt keine Grenze bezüglich der Anzahl von Clients, wie etwa Client 207, welche Sectd bedienen kann.
Das Programmsegment für SectClientController, welches in SectClientController.c von Fig. 6b aufgelistet und in dem Blockdiagramm von Fig. 6a abstrahiert ist, ist ein Beispiel eines Teils eines Client-Prozesses, wie etwa Client 207, welches einen Fernprozeduraufruf bewerkstelligt.
Vor dem Herstellen irgendwelcher Fernprozeduraufrufe erzeugt SectClientController ein Objekt der Klasse RpcClient, um einen Kommunikationskanal zwischen ihm selbst und Sectd auszubilden (Schritt 601). Die Klasse RpcClient ist auch von der Klasse sharedThang abgeleitet. Eine Implementierung des RpcClient-Objekts und diesbezüglicher Funktionen werden in den Dateien RpcClient.h, RpcClient.c, RpcUtil.h, RpcUtil.h, Wrapper.h und Wrapper.c gefunden.
Wie in Fig. 6a gezeigt, stellt, wenn SectClientController ein RpcClient-Objekt erzeugt, eine Konstruktorroutine von RpcClient (SectClientControllerseitig) eine Anforderung an Systemdienste, um eine vorübergehende Programmnummer anzufordern, welche mit der Versionsnummer präsentiert wird, um einen Transportniveaudienst einzuleiten (Schritt 602). Dieser Transportniveaudienst wird als ein Server in SectClientController zum Empfangen von Nachrichten von dem RpcClient-Objekt von Sectd verwendet, was nachstehend diskutiert wird. (RpcClients von Sectd stellen einen Weg zum Kommunizieren von Statusinformationen von Master-Objekten in Sectd an die Clients von Sectd bereit, wodurch ein Rückrufmechanismus ausgebildet wird.) Somit agiert in Bezug auf von Sectd empfangenen Nachrichten SectClientController als ein Server. Dieser Transportniveaudienst wird mit dem Netzwerkregisterdienst registriert, um zuzulassen, daß Nachrichten von Sectd SectClientController erreichen (Schritt 603). Die Konstruktorroutine von RpcClient stellt dann einen Fernprozeduraufruf (Schritt 604) zu einer entfernten Routine rct_9RpcClientFPCcUlUlR8ManifestUlPC9RpcHandlePC7timeint erval ("rct") in Sectd (durch SectdProg_1, gezeigt in Fig. 4c) her. Der Fernprozeduraufruf an rct sendet an Sectd (i) die vorübergehende Programmnummer und Versionsnummer des Transportniveaudienstes, (ii) den Wirtsmaschinennamen von SectClientController, (iii) ein "Manifest" (siehe unten) von SectClientController (nachstehend erläutert) und (iv) den Index des RpcClient-Objekts in der geteilten Objektliste von SectClientController. Umgekehrt ruft ein Fernprozeduraufruf an rct, welcher in dem Programmsegment in Wrapper.C implementiert ist, in Schritt 605 die Konstruktorroutine (serverseitig) für RpcClient auf, um (i) das empfangene Manifest zu übersetzen, und (ii) weist zum Zwecke eines rückwärtigen Aufrufs als Master des RpcClient von Sectd dem Index in der Liste von Objekten von Sectd den RpcClient von SectClientController zu. Sectd erzeugt auch einen Nachrichten-Daemon ozmsgd (Schritt 606). Der Fernprozeduraufruf an rct gibt ein Manifest, welches die Information zu allen in Sectd implementierten Klassen einschließt, zurück. Der Nachrichten- Daemon ozmsgd ist als eine Einrichtung gedacht, um die Slaves eines Masters in Sectd "zurückzurufen", um die Slaves von entweder (i) einem asynchronen Zustandswechsel in dem Master, (ii) der Erzeugung eines neuen gemeinsam benutzten Objekts in Sectd, oder (iii) der Zerstörung eines gemeinsam benutzten Objekts in Sectd zu unterrichten.
In dem herkömmlichen Server-Client-Modell fordert ein Client durch Senden einer Nachricht an einen Server einen Dienst von dem Server an. Der Server bestätigt dann oder gibt, nachdem der angeforderte Dienst durchgeführt ist, ein Ergebnis zurück. In diesem herkömmlichen Modell leitet der Server keine Kommunikation mit dem Client ein. In der vorliegenden Ausführungsform jedoch ist es, da ein Master eines verteilten Objekts einen oder mehrere Clients bedient, manchmal notwendig, daß der Master des verteilten Objekts eine Zustandsänderung des Master-Objekts asynchron kommuniziert. Zu diesem Zweck ruft, in diesem Fall als Client agierend, der Daemon ozmsgd SectClientController und alle ähnlichen Clients von Sectd auf, um den Zustandswechsel des Master-Objekts und die Erzeugung oder Zerstörung eines gemeinsam benutzten Objekts, wie zuvor diskutiert, zu kommunizieren.
In der vorliegenden Ausführungsform enthält ein Manifest für jede bekannte Klasse Klassen-"Metainformation". Damit Slave- und Master-Objekte richtig angepaßt werden können, enthält eine solche Metainformation für jede Klasse (i) einen Typencode, welcher die Klasse identifiziert, (ii) den Namen der Klasse, (iii) die Anzahl von Basisklassen, sofern vorhanden, von welchen die Klasse abgeleitet ist, und (iv) die Namen solcher Basisklassen. Zusätzlich enthält ein Manifest für jedes gemeinsam benutzte Objekt in dem das Manifest liefernden Prozeß einen Typencode und den Index des gemeinsam benutzten Objekts in die Liste gemeinsam benutzter Objekte des sendenden Prozesses. Das Manifest wird aus der Struktur list aufgebaut, einem Teil des Vererbungsbaums, welcher durch zuvor beschriebenes GenType erzeugt wird. Die Definition und Implementierung des Klassenmanifests sind in den Dateien manifest.c und manifest.h bereitgestellt.
In der vorliegenden Ausführungsform stellt ein Systemdesigner für den Anwendungsprogrammierer alle zu verwendenden Systemobjekte bereit. Obwohl diese Systemobjekte verteilt oder lokal sein können, ist die Implementierung vor dem Anwendungsprogrammierer verborgen. Wenn die SectClientController-Klasse zuerst instanziiert wird, lokalisiert die Konstruktorroutine des SectClientController den Master-SectController von einer Liste gemeinsam benutzter Objekte des Masters, welche von dem von dem SectController empfangenen Manifest erzeugt wird (Schritt 607). Wie durch dieses Beispiel veranschaulicht, erfordert eine Verbindung zwischen einem Master und dem Slave nicht, daß Master- und Slave-Objekt von der gleichen Klasse sind. In dieser Ausführungsform wird Kompatibilität erreicht, nachdem SectClientController eine von SectController abgeleitete Klasse ist. Somit kann der gleiche SectController in Sectd verwendet werden, um eine Zahl von Vorrichtungen, welche zu von der SectController- Klasse abgeleiteten Klassen gehören, zu steuern. Um die Verbindung zu vervollständigen, fordert SectClientController ein "Join" mit dem Master-Objekt SectController in Sectd durch Herstellen eines Aufrufs an eine Funktion JoinWithMaster an (Schritt 608), wobei an JoinWithMaster übergeben wird: (i) ein Zeiger zu SectClientController, (ii) ein Handle Join_With_Slave_1, welcher eine Anweisung an JoinWithMaster darstellt, eine Routine JoinWithSlave aufzurufen, (iii) ein Zeiger zu dem RpcClient von SectClientcontroller, (iv) der Name der Basisklasse "SectController" und (v) ein Index master in die Liste gemeinsam benutzter Objekte von Sectd, wobei master einem SectController-Objekt in Sectd entspricht. Sowohl JoinWithMaster als auch JoinWithSlave sind in den Programmsegmenten der Daten RpcUtil.h und RpcUtil.c aufgelistet.
JoinWithMaster erhält das ClassInfo-Objekt, welches einer Klasse SectController entspricht. Das ClassInfo-Objekt wird durch Anwenden der typeof-Methode auf den Namen "SectController" zurückgegeben. Der Index master und der RpcClient werden dann durch die Memberfunktion addMaster von SharedThangId mit dem SectClientController-Objekt verbunden. Danach ruft ein Fernprozeduraufruf (Schritt 609), welcher den Handle Join_With_Slave_1 verwendet, durch SectdProgl die Funktion rjoinWithSlave_FP11SharedThangP9RpcClientUi ("rjoin") in Sectd auf, um einen Index von SectClientController in eine Liste gemeinsam benutzter Objekte von SectClientController an Sectd zu liefern.
Der Fernprozeduraufruf an rjoin übergibt an Sectd (i) den Index master, welcher SectController in der Liste von SharedThang's von Sectd identifiziert, und (ii) die Indizes von RpcClient und SectClientController in die Liste gemeinsam benutzter Objekte von SectClientcontroller. Um mit dem entsprechenden RpcClient in Sectd zusammenzupassen, wird der Index von RpcClient gegen einen Zeiger zu dem entsprechenden in RpcClient enthaltenen Objekt der Klasse SharedThang ausgetauscht. Dieser SharedThang-Zeiger wird wiederum zu einem Zeiger zu dem durch vorgenannten Sectd erzeugten RpcClient-Objekt downgecastet. rjoin ruft dann die lokale Routine JoinWithSlave, um den SectController von Sectd mit der RemoteId zu verknüpfen, welche ausgebildet ist durch (i) den übergebenen Index von SectClientController und (ii) das entsprechende RpcClient-Objekt von Sectd. Dieses RemoteId-Objekt ist in die slaves-Liste von SectController unter Verwendung der addClient-Memberfunktion von SharedThangId eingegeben.
Um sicherzustellen, daß die Implementierung für den Anwendungsprogrammierer transparent ist, sieht die vorliegende Erfindung einen Mechanismus vor, welcher für einen Fernprozeduraufruf eine "lokale Prozeduraufrufsemantik" bewahrt. Bei einer lokalen Prozeduraufrufsemantik wartet der Client-Prozeß auf den Prozeduraufruf, um in der gleichen Weise wie eine Prozedur in dem Speicherraum des Client-Prozesses zurückzuspringen. Des weiteren wird aufgrund der Schwierigkeit, in einem herkömmlichen Fernprozeduraufruf sprachenunabhängige Fehlerbehandlungsmechanismen zu implementieren, ein in der entfernten Umgebung auftretender Fehler oft nicht an die lokale Umgebung zurückgegeben. Statt dessen gibt die aufrufende Prozedur nach einer gewissen Zeit eine Zeitablaufnachricht zurück, wenn die erwarteten Ergebnisse nicht empfangen werden. Jedoch kann eine lokale Prozeduraufrufsemantik nur bewahrt werden, wenn der Fehlerbehandlungsmechanismus für Fernprozeduraufrufe ebenfalls ununterscheidbar von dem Fehlerbehandlungsmechanismus für lokale Prozeduraufrufe gemacht wird.
In einer herkömmlichen Implementierung von Fernprozeduraufrufen führt der Client eine sequentielle Ausführung in seinem Prozeßraum fort, bis eine explizite "Warte"-Anweisung ausgeführt wird. Eine solche Implementierung ist unerwünscht, da das Anwendungsprogramm sowohl über eine Kenntnis einer entfernten Implementierung als auch eine Synchronisierung mit einem entfernten Ereignis verfügen muß.
Fernprozeduraufrufe können durch Anstoßen einer Stub- Routine, wie etwa Stub-Routine 201, in der mit Bezug auf Fig. 2 beschriebenen Art und Weise in SectClientController bewirkt werden. In dieser Ausführungsform werden Stub-Routinen 201 und 202 unter Verwendung eines durch eine "Skript"-Datei (das "oz"-Skript) implementierten Stub-Routinen-Generators gleichzeitig generiert. Eine Skript-Datei ist ein Programm, welches durch einen UNIX-Befehlszeileninterpreter (im UNIX-Jargon eine "Shell" genannt) ausführbar ist.
Fig. 7a und 7b sind jeweils die Blockdiagramme der Stub-Routinen SectController::startTester und rstartTester_14SectControllerFRUiRC5Twine ("rstartTester"), welche durch das oz-Skript für die Master- und Slave-Objekte erzeugt werden, welches die verteilte Klasse SectController in SectClientController und Sectd implementiert. Fig. 8 ist der Quellcode in Datei SectController.C für die tatsächliche Implementierung der Klasse SectController in Sectd, welche zusätzlich zu Konstruktor- und Destruktorfunktionen eine Memberfunktion SectController::StartTester aufweist. Nachdem sich StartTester in Sectd befinden soll, geschieht der Zugriff von SectClientController auf StartTester durch die durch das oz-Skript generierte Stub-Routine. Das oz-Skript generiert jeweils zwei Stub-Routinen für SectController in Dateien svc_SectController.C und clnt_SectController.C zur Kompilierung mit Sectd und SectClientController. Zum Zwecke des Kompilierens von SectClientController enthält sectClientController.C die Datei clnt_SectController.C. Für den Zweck eines Kompilierens des Servers 206 enthält SectController.C svc Controller.C. Nachdem die Memberfunktion StartTester tatsächlich nur in Sectd implementiert ist, ist der Rumpf der Memberfunktion SectController::StartTester nur für eine Kompilierung in Sectd enthalten. Der durch das oz-Skript in Sectd generierten Stub-Routine ist das Zeichen "r" vorangestellt, um es von dem tatsächlichen SectController::StartTester- Code zu unterscheiden. Damit wird, wie in Fig. 8 gezeigt, die alternative Compiler-Direktive "#if defined(Server)" verwendet, wo eine Implikation in der Sectd zugehörigen Version von SectController.C (d. h. svc- SectController) erwünscht ist, und die alternative Compiler-Direktive "#if defined(oz)" wird verwendet, wo eine Implikation in der SectClientController zugehörigen SectController.C (d. h. SectController::StartTester-Stub) erwünscht ist. Als ein Kompilierungsergebnis wird eine Objektdatei SectController.o für jede Version von SectController.C zum Verknüpfen mit seinem jeweiligen Client oder Server erhalten. Anwendungsprogramme, welche die Client-Version von SectController.o verküpfen, müssen nicht wissen, daß SectController ein verteiltes Objekt ist.
Wie in Fig. 7a gezeigt, erhält SectController::startTester den Index masterid (d. h. den Index in die Sectd zugehörige Liste gemeinsam benutzter Objekte) von SectController (Schritt 701). Die vorzeichenlose lange Ganzzahl handle, welche die aufzurufende Memberfunktion (d. h. rstartTester) kodiert, wird dann durch die Memberfunktion rwhich von RpcClient wiedergefunden, wobei der Name der Memberfunktion auf handle abgebildet wird. Die Argumente an die Memberfunktion parm1 und parm2, die Adresse masterid des Masters und das RpcClient-Objekt rid.id werden dann in einer Pufferstruktur der Klasse XdrBuffer bereitgestellt, welche durch die RPC-Mechanismen 203 und 204 unterstützt wird (Schritt 703). Der Puffer und die Zahl handle der entfernten Funktion werden durch den RPC-Mechanismus an Sectd übergeben (Schritt 704). Fig. 9a ist der Quellcode der beispielhaften Stub-Routine von Fig. 7a, welche durch das oz- Skript für SectClientController generiert wird.
Fig. 7b ist ein Blockdiagrammbeispiel der Stub-Routine rStartTester, welche durch das oz-Skript für Sectd eines Objekts der Klasse SectController erzeugt wird. Wie in Fig. 7b gezeigt, wird der Index des dem Master zugehörigen RpcClient-Objekts in die Liste gemeinsam benutzter Objekte von Sectd aus der von SectClientController empfangenen Nachricht extrahiert (Schritt 750). Dieser Index des RpcClient-Objekts wird dann verwendet, um einen Zeiger in dem Speicherraum von Sectd zu dem in RpcClient enthaltenen SharedThang-Objekt wiederzufinden, wobei die SharedThang::get(id)-Memberfunktion verwendet wird (Schritt 751). Der Zeiger wird dann downgecastet, um ein Zeiger zu einem Objekt der Klasse RpcClient zu werden (Schritt 752). Die verbleibenden Parameter von XdrBuffer werden dann verwendet, um den Index id eines SectControllers in der Liste der gemeinsam benutzten Objekte von Sectd und Parameter parm1 und parm2 von startTester zu erhalten (Schritt 753). Der Index id wird verwendet, um einen Zeiger, welcher dem in SectController enthaltenen SharedThang-Objekt entspricht, wiederzufinden. Dieser Zeiger wird dann in einen Zeiger zu einem Objekt der Klasse SectController downgecastet (Schritt 754). rstartTester ruft dann die tatsächliche lokale Prozedur StartTester als eine Memberfunktion der Klasse SectController auf (Schritt 755). Falls in dem lokalen Prozeduraufruf kein Fehler aufgetreten ist, wird der Rückgabewert in Variable parm1 und der Fehlercode LPC- _Success zurückgegeben (Schritt 756). Anderenfalls werden Ausnahmen durch eine von zwei catch-Anweisungen aufgefangen, und der Fehlercode wird zurückgegeben. Auf diese Weise wird eine Ausnahme an die Stub-Routine in SectClientController zurückübergeben. Somit bewahrt die vorliegende Erfindung die lokale Aufrufsemantik in einem Fernprozeduraufruf. Fig. 9b ist der Quellcode der beispielhaften Stub-Routine rstartTester von Fig. 7b, welche durch das oz-Skript für Sectd generiert wird.
Fig. 10 ist ein Blockdiagramm, welches die Betriebsweise des oz-Skripts veranschaulicht. Der Fachmann wird verstehen, daß viele Variationen verwendet werden können, um die Stub-Routinen bereitzustellen. Solche Variationen schließen die Verwendung eines durch andere als eine Shell verwendbaren Programms oder die Verwendung von anderen Textverarbeitungsdienstprogrammen als awk ein, sind aber nicht darauf beschränkt. Das oz-Skript der vorliegenden Ausführungsform empfängt als Eingang eine Spezifikationsdatei und akzeptiert wählbare Befehlszeilenargumente. Diese Befehlszeilenargumente spezifizieren, (i) ob Namen in der Spezifikationsdatei "unverstümmelt" sein müssen (Option -raw); (ii) ob eine Client-Stub-Routinen- Datei zu erzeugen ist (Option -c); (iii) ob eine Server- Stub-Routinen-Datei zu erzeugen ist (Option -s); (iv) ob die Kompiliererdirektiven für eine alternative Implikation der Server- oder Client-Stub-Routinen-Dateien an den Rumpf der das verteilte Objekt implementierenden.C-Datei angehängt werden sollen (Option -m); und (v) ob Handles zu den entfernten Funktionen, z. B. rstartTester, zur Implikation zu dem Programm, z. B. SectProg_1, welches durch den RPC-Mechanismus auf der Serverseite aufgerufen wird, generiert werden sollten (Option -h).
Fig. 11 ist der Inhalt der durch das oz-Skript verwendeten Spezifikationsdatei, um die in Fig. 7a und 7b veranschaulichten Stub-Routinen für SectController zu generieren. Um die Generierung der zuvor diskutierten Stub- Routinen zu veranschaulichen, reicht eine Betrachtung der ersten Zeile in der Spezifikationsdatei aus.
Wie in Fig. 10 gezeigt, analysiert das oz-Skript die Befehlszeile und extrahiert aus der Befehlszeile Argumente zum Festlegen der inneren Zustände des oz-Skripts (Schritt 1001). Je nachdem, ob die Option -raw gesetzt ist, werden Namensverstümmelungsoperationen an der Spezifikationsdatei durchgeführt (Schritt 1002). Das Verstümmeln übersetzt den Namen einer C++-Funktion in einen eindeutigen Namen, welcher eine Kodierung der Parameterliste der Funktion enthält. Die Ergebnisse der Namensverstümmelung der Spezifikationsdatei werden in einer neuen Datei input (die "Input"-Datei) gespeichert. In dieser Ausführungsform wurde ein anderes Shell-Skript "mangle" verwendet, um die Namensverstümmelung durchzuführen. Jedoch sind andere Shell-Skripte, welche im wesentlichen mit den in der obigen Referenz dargelegten Namensverstümmelungsregeln übereinstimmen, gleichermaßen anwendbar. Falls die Option -raw nicht gesetzt ist, wird die Spezifikationsdatei in die Input-Datei direkt kopiert (Schritt 1003), wobei der Namensverstümmelungsschritt umgangen wird. Zusätzlich werden, wenn die Option -m gesetzt ist, alternative Compiler-Direktiven der Quellcodedatei der verteilten Klasse hinzugefügt (Schritt 1004). Die Input-Datei wird dann geparst, um aus den unverstümmelten Namen eine Liste der in der Input-Datei dargestellten Basisklassen zu extrahieren (Schritt 1005). Zum Beispiel werden in der von der Spezifikationsdatei von Fig. 11 abgeleiteten Input-Datei zwei Basisklassen "SectTester" und "SectController" aus der Input-Datei extrahiert. Die extrahierte Liste von Basisklassen wird in eine "Basislisten"-Datei eingebracht.
In den nächsten Schritten 1006 und 1007 werden awk- Befehlsdateien svc.awk und clnt.awk vorbereitet. Die Befehlsdatei svc.awk (i) stellt die erforderlichen Kopfdateischnittstellen mit der Fernprozeduraufrufeinrichtung und Deklaration anderer Datenstrukturen, wie etwa SharedThangld, bereit, (ii) prüft eine Input-Temporärdatei auf einen Memberfunktionsaufruf, (iii) stellt in dem Server-Objekt Unmarshalling-Anweisungen zum Übergeben von Parametern des Input-Typs zu tatsächlichen Implementierungen des verteilten Objekts bereit und (iv) stellt Marshalling-Anweisungen zum Zurückgeben von Werten von Parametern anderer Input/Output-Typen bereit. Die Befehlsdatei svc.awk stellt auch eine Anweisung in dem Output-Serverobjekt zum Downcasten eines SharedThang-Objekts zu der in der Input-Temporärdatei spezifizierten Basisklasse bereit.
Die Befehlsdatei clnt.awk stellt auch Schnittstellen mit der Fernprozeduraufrufeinrichtung und eine Deklaration von Datenstrukturen bereit. Zusätzlich marshallt clnt.awk Parameter vom Input-Typ, um einen Fernprozeduraufruf unter Verwendung der Input-Parameter zu erzeugen und Unmarshalling-Anweisungen zur Ausgabe oder bidirektionale Parameter, deren Werte von dem Fernprozeduraufruf zurückgegeben werden, bereitzustellen.
In Schritt 1008 wird die Basislisten-Datei verwendet, um für jede Basisklasse Memberfunktionsaufrufe von der Input-Datei zu extrahieren, um in eine Output-Temporärdatei plaziert zu werden. Diese Temporärdatei wird dann in Schritt 1009 durch beide Befehlsdateien clnt.awk und svc.awk verwendet, um die Output-Stub-Routinen-Dateien svc_< base> .C und clnt_< base> .C zu generieren (wobei < base> der Name der Basisklasse, z. B. vorgenannter SectController, ist).
In Schritt 1010 werden die Memberfunktionen der Klasse SectController in Handles kodiert, um in eine Datei SectdProg.c eingeführt zu werden. SectdProg.c enthält eine Sectd-Funktion SectProg_1, welche über eine Schaltanweisung Funktionen in Sectd in Übereinstimmung mit dem an den RPC-Mechanismus gelieferten Handle aufruft.
Die vorstehende Beschreibung veranschaulicht besondere Ausführungsformen der vorliegenden Erfindung, beschränkt die vorliegende Erfindung aber nicht. Zahlreiche Modifikationen und Variationen sind innerhalb des Umfangs der vorliegenden Erfindung möglich. Zum Beispiel ist, obwohl die vorstehend bereitgestellte, detaillierte Beschreibung eine Implementierung in der Programmiersprache C++ als ein Beispiel verwendet, die vorliegende Erfindung auf jede objektorientierte Programmiersprache anwendbar. Die vorliegende Erfindung wird durch die nachfolgenden Ansprüche dargelegt.

Claims

1. Struktur zum gemeinsamen Benutzen von Datenobjekten in Anwendungsprogrammen (208, 205) eines verteilten Rechnersystems, wobei das verteilte Rechnersystem erste (207, 203, 251) und zweite (206, 204, 250) Rechner aufweist, wobei die Struktur aufweist:

eine erste Anwendungsebenenschnittstelle (201) in dem ersten Rechner (207, 203, 251) zu einem ersten Fernprozeduraufrufmechanismus (203);

eine zweite Anwendungsebenenschnittstelle (202) in dem zweiten Rechner (206, 204, 250) zu einem zweiten Fernprozeduraufrufmechanismus (204);

Mittel (250, 251) in dem ersten (207, 203, 251) und zweiten (206, 204, 250) Rechner zum Koppeln des ersten (203) und zweiten (204) Fernprozeduraufrufmechanismus, zum Befördern von Daten zwischen dem ersten (207, 203, 251) und zweiten (206, 204, 250) Rechner;

erste, mit der ersten Anwendungsebenenschnittstelle (201) gekoppelte Mittel zum Bereitstellen einer Datenstruktur, welche eine Basisklasse (SharedThang) gemeinsam benutzter Objekte darstellt, wobei jedes gemeinsam benutzte Objekt durch Prozesse (206, 207) in dem ersten (207, 203, 251) und zweiten (206, 204, 205) Rechner abrufbar ist;

zweite, mit der zweiten Anwendungsebenenschnittstelle (202) gekoppelte Mittel zum Bereitstellen der Datenstruktur, welche die Basisklasse (SharedThang) gemeinsam benutzter Objekte darstellt; erste, mit der ersten Anwendungsebenenschnittstelle (201) gekoppelte Mittel zum Bereitstellen von Datenstrukturen, welche eine Mehrzahl von Klassen gemeinsam benutzter Objekte darstellen, von denen jede in Übereinstimmung mit einer Hierarchie von Klassen von der Basisklasse (SharedThang) abgeleitet ist, wobei jedes gemeinsam benutzte Objekt in jeder der Mehrzahl von Klassen gemeinsam benutzter Objekte durch Prozesse (206, 207) in dem ersten (207, 203, 251) und zweiten (206, 204, 250) Rechner abrufbar ist;

zweite, mit der zweiten Anwendungsebenenschnittstelle (202) gekoppelte Mittel zum Bereitstellen der Datenstrukturen, welche die Mehrzahl von Klassen gemeinsam benutzter Objekte darstellen;

erste Mittel in dem ersten Rechner (207, 203, 251) zum Aufbauen (Schritt 303) eines Vererbungsbaums, dessen Wurzel sich in einer die Basisklasse (SharedThang) darstellenden Datenstruktur befindet, wobei der Vererbungsbaum Datenstrukturen aufweist, welche Beziehungen zwischen den Klassen gemeinsam benutzter Objekte und der Basisklasse (SharedThang) in Übereinstimmung mit der Hierarchie von Klassen darstellt;

zweite Mittel in dem zweiten Rechner (206, 204, 250) zum Aufbauen (Schritt 303) des Vererbungsbaums in dem zweiten Rechner (206, 204, 250);

erste Mittel (201) in dem ersten Rechner (207, 203, 251) zum Durchqueren des Vererbungsbaums, um eine Datenstruktur, welche eine Beziehung zwischen einem ersten Objekt und einem zweiten Objekt darstellt, in dem ersten Rechner (207, 203, 251) auf zubauen, wobei das erste Objekt in einem maschinenunabhängigen Format durch einen Prozess (206) in dem zweiten Rechner (206, 204, 250) durch den ersten und zweiten Fernprozeduraufrufmechanismus (203, 204) angegeben wird; und

zweite Mittel (202) in dem zweiten Rechner (206, 204, 250) zum Durchqueren des Vererbungsbaums, um eine Datenstruktur, welche eine Beziehung zwischen einem ersten Objekt und einem zweiten Objekt darstellt, in dem zweiten Rechner (206, 204, 250) auf zubauen, wobei das erste Objekt in einem maschinenunabhängigen Format durch einen Prozess (207) in dem ersten Rechner (207, 203, 251) durch den ersten und zweiten Fernprozeduraufrufmechanismus (203, 204) angegeben wird.

2. Verfahren zum gemeinsamen Benutzen von Datenobjekten in Anwendungsprogrammen (208, 205) eines verteilten Rechnersystems, wobei das verteilte Rechnersystem erste (207, 203, 251) und zweite (206, 204, 250) Rechner aufweist, wobei das Verfahren die Schritte aufweist:

Bereitstellen einer ersten Anwendungsebenenschnittstelle (201) in dem ersten Rechner (207, 203, 251) zu einem ersten Fernprozeduraufrufmechanismus (203) in dem ersten Rechner (207, 203, 251);

Bereitstellen einer zweiten Anwendungsebenenschnittstelle (202) in dem zweiten Rechner (206, 204, 250) zu einem zweiten Fernprozeduraufrufmechanismus (204) in dem zweiten Rechner (206, 204, 250);

Koppeln der ersten (203) und zweiten (204) Fernprozeduraufrufmechanismen in dem ersten (207, 203, 251) und zweiten (206, 204, 250) Rechner, um Daten zwischen dem ersten (207, 203, 251) und zweiten (206, 207, 250) Rechner zu befördern; Bereitstellen einer Datenstruktur sowohl in dem ersten (207, 203, 251) als auch dem zweiten (206, 204, 250) Rechner zum Darstellen einer Basisklasse (SharedThang) gemeinsam benutzter Objekte in dem ersten (207, 203, 251) und zweiten (206, 204, 250) Rechner und Bereitstellen von Datenstrukturen sowohl in dem ersten (207, 203, 251) als auch in dem zweiten (206, 204, 250) Rechner zum Darstellen einer Mehrzahl von Klassen gemeinsam benutzter Objekte, von denen jede in Übereinstimmung mit einer Hierarchie von Klassen von der Basisklasse (SharedThang) abgeleitet wird, wobei jedes gemeinsam benutzte Objekt in jeder der Mehrzahl von Klassen gemeinsam benutzter Objekte durch Prozesse (206, 207) in dem ersten (207, 203, 251) und zweiten (206, 204, 250) Rechner abrufbar ist; und

Aufbauen eines Vererbungsbaums, dessen Wurzel sich in einer die Basisklasse (SharedThang) darstellenden Datenstruktur befindet, in sowohl dem ersten (207, 203, 251) als auch dem zweiten (206, 204, 250) Rechner, wobei der Vererbungsbaum Datenstrukturen aufweist, welche in Übereinstimmung mit einer Hierarchie Beziehungen zwischen der Mehrzahl von Klassen gemeinsam benutzter Objekte und der Basisklasse (SharedThang) darstellen; und

Durchqueren des Vererbungsbaums in sowohl dem ersten (207, 203, 251) als auch dem zweiten (206, 204, 250) Rechner, um eine Datenstruktur aufzubauen, welche ein Verhältnis zwischen einem ersten Objekt und einem zweiten Objekt darstellt, immer wenn das erste Objekt in einem maschinenunabhängigen Format durch einen Prozess (206, 207) in einem von dem ersten (207, 203, 251) und dem zweiten (206, 204, 250) Rechner angegeben wird und dem anderen von dem ersten (207, 203, 251) und dem zweiten (206, 204, 250) Rechner über die Fernprozeduraufrufmechanismen (203, 204) in dem ersten (207, 203, 251) und dem zweiten (206, 204, 250) Rechner zur Verfügung gestellt wird.

3. Struktur nach Anspruch 1, wobei jedes der gemeinsam benutzten Objekte ein Serverobjekt (206) in einem ausgewählten von dem ersten (207, 203, 251) und dem zweiten (206, 204, 250) Rechner und ein Clientobjekt (207) in dem anderen von dem ersten (207, 203, 251) und dem zweiten (206, 204, 250) Rechner aufweist, wobei das Server- (206) und das Clientobjekt (207) über die erste (201) und zweite (202) Anwendungsebenenschnittstelle kommunizieren.

4. Struktur nach Anspruch 3, wobei das Clientobjekt (207) zu entweder (a) der Serverobjektklasse gemeinsam benutzter Objekte oder (b) einer Klasse gemeinsam benutzter Objekte, welche von der Serverobjektklasse gemeinsam benutzter Objekte abgeleitet ist, gehört.

5. Struktur nach Anspruch 3, wobei das Serverobjekt (206) mit einer Mehrzahl von Methoden ausgestattet ist, welche auf dem ausgewählten Rechner auszuführen sind, und das Clientobjekt (207) auf jede der Methoden über einen Fernprozeduraufruf über die erste (201) und zweite (202) Anwendungsebenenschnittstelle zugreift (Schritt 704).

6. Struktur nach Anspruch 5, die weiter Mittel (201, 202) zum Berechnen eines Zeigers zu entweder (a) einem Elternobjekt, welches ein gemeinsam benutztes Objekt enthält, oder (b) einem in dem Elternobjekt enthaltenen Objekt auf der Grundlage des Vererbungsbaums und unter Verwendung eines Zeigers zu dem gemeinsam benutzen Objekt aufweist.

7. Struktur nach Anspruch 6, wobei das Serverobjekt (206) eine Liste gemeinsam benutzter Objekte pflegt und wobei das Clientobjekt (207) eine Methode in einem der gemeinsam benutzten Objekte in der Liste unter Verwendung eines Index in die Liste angibt, wobei das Serverobjekt (206) dann den Index nimmt, um einen Zeiger zu der Methode unter Verwendung der Mittel (201, 202) zum Berechnen eines Zeigers zu erhalten.

8. Struktur nach Anspruch 5, wobei das Serverobjekt (206) ein Ausführungsergebnis einer beliebigen der Methoden an das Clientobjekt (207) über die erste (201) und zweite (202) Anwendungsebenenschnittstelle zurückgibt (Schritt 755) und das Clientobjekt (207) in einem Ruhezustand wartet (Schritt 705), bis das Ergebnis empfangen wird.

9. Struktur nach Anspruch 5, wobei das Serverobjekt (206) eine beliebige Fehlermeldung, welche während der Ausführung einer beliebigen der Methoden erzeugt wird, über die erste (201) und zweite (202) Anwendungsebenenschnittstelle an das Clientobjekt (207) zurückgibt (Schritt 756).

10. Struktur nach Anspruch 3, wobei das Clientobjekt (207) ein Serverkommunikationsobjekt (clientseitiger RPC-Client) und eine Nachricht erzeugt, welche das Serverobjekt (206) über eine Erzeugung des Serverkommunikationsobjekts (clientseitiger RPC-Client) benachrichtigt, und wobei als Antwort auf die Nachricht das Serverobjekt (206) ein Clientkommunikationsobjekt (serverseitiger RPC-Client) zum Senden von Nachrichten zu dem Clientobjekt (207) erzeugt.

11. Struktur nach Anspruch 4, wobei das Serverobjekt (206) an das Clientobjekt (207) ein Servermanifest schickt, welches die Serverobjektklasse und Klassen, von welchen die Serverobjektklasse abgeleitet ist, auflistet, und wobei das Clientobjekt (207) an das Serverobjekt (206) ein Clientmanifest schickt (Schritt 604), welches die Clientobjektklasse und Klassen, von welchen die Clientobjektklasse abgeleitet ist, auflistet.

12. Verfahren nach Anspruch 2, welches weiter den Schritt eines Implementierens jedes der gemeinsam benutzten Objekte als ein Serverobjekt (206) in einem ausgewählten aus dem ersten (207, 203, 251) und dem zweiten (206, 204, 250) Rechner und ein Clientobjekt (207) in dem anderen von dem ersten (207, 203, 251) und dem zweiten (206, 204, 250) Rechner aufweist, wobei das Server- (206) und das Clientobjekt (207) über die erste (201) und zweite (202) Anwendungsebenenschnittstelle kommunizieren.

13. Verfahren nach Anspruch 12, welches weiter den Schritt eines Bereitstellens des Clientobjekts (207) in entweder (a) der Serverobjektklasse gemeinsam benutzter Objekte oder (b) einer Klasse gemeinsam benutzter Objekte, welche von der Serverobjektklasse gemeinsam benutzter Objekte abgeleitet wird, aufweist.

14. Verfahren nach Anspruch 13, welches weiter die Schritte aufweist:

Ausstatten des Serverobjekts (206) mit einer Mehrzahl von Methoden, welche auf dem ausgewählten Rechner ausgeführt werden sollen; und Zugreifen (Schritt 704) auf jede der Methoden von dem Clientobjekt (207) über einen Fernprozeduraufruf über die erste (201) und zweite (202) Anwendungsebenenschnittstelle.

15. Verfahren nach Anspruch 14, welches weiter den Schritt eines Berechnens eines Zeigers zu entweder (a) einem Elternobjekt, welches ein gemeinsam benutztes Objekt enthält oder (b) einem in dem Elternobjekt enthaltenen Objekt in sowohl dem ersten (207, 203, 251) als auch dem zweiten (206, 204, 250) Rechner auf der Grundlage des Vererbungsbaums und unter Verwendung eines Zeigers zu dem gemeinsam benutzten Objekt aufweist.

16. Verfahre n nach Anspruch 15, welches weiter die Schritte aufweist:

Pflegen einer Liste gemeinsam benutzter Objekte in dem Serverobjekt (206);

Angeben eines Index in die Liste, wenn auf eine beliebige Methode in einem der gemeinsam benutzten Objekte in der Liste zugegriffen wird; und Nehmen des Index, um einen Zeiger zu der Methode unter Verwendung des Schritts zum Berechnen eines Zeigers zu erhalten.

17. Verfahren nach Anspruch 14, welches weiter die Schritte aufweist:

Zurückgeben (Schritt 756) eines Ausführungsergebnisses einer beliebigen der Methoden von dem Serverobjekt (206) an das Clientobjekt (207) über die erste (201) und zweite (202) Anwendungsebenenschnittstelle, und Warten (Schritt 705) in einem Ruhezustand des Clientobjekts (207), bis das Ergebnis empfangen wird.

18. Verfahren nach Anspruch 14, welches weiter den Schritt (756) eines Zurückgebens einer beliebigen Fehlermeldung, welche während einer Ausführung einer beliebigen der Methoden erzeugt wird, über die erste (201) und zweite (202) Anwendungsebenenschnittstelle an das Clientobjekt (207) aufweist.

19. Verfahren nach Anspruch 12, welches weiter die Schritte aufweist:

Erzeugen (Schritt 601) eines Serverkommunikationsobjekts (clientseitiger RPC-Client) und einer Nachricht, welche das Serverobjekt (206) über die Erzeugung des Serverkommunikationsobjekts (clientseitiger RPC-Client) unterrichtet, in dem Clientobjekt (207); und

Erzeugen (Schritt 606) eines Clientkommunikationsobjekts (serverseitiger RPC-Client) in dem Serverobjekt (206) zum Senden von Nachrichten an das Clientobjekt (207) als Antwort auf die Nachricht.

20. Verfahren nach Anspruch 13, welches weiter die Schritte aufweist:

Senden eines Servermanifests, welches die Serverobjektklassen und Klassen, von welchen die Serverobjektklasse abgeleitet ist, auflistet, an das Clientobjekt (207); und

Senden eines Clientmanifests, welches die Clientobjektklasse und Klassen, von welchen die Clientobjektklasse abgeleitet ist, auflistet, an das Serverobjekt (206).