DE69632987T2

DE69632987T2 - Verfahren und Vorrichtung zum Mehrfachprotokollbetrieb in einem Benutzer-/Anbietersystem

Info

Publication number: DE69632987T2
Application number: DE69632987T
Authority: DE
Inventors: Graham Palo Alto Hamilton; Peter B. Palo Alto Kessler; Jeffery D. San Jose Nisewanger; Alan Mountain View Bishop; Eduardo Mountain View Pelegri-Llopart
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1995-10-06
Filing date: 1996-09-19
Publication date: 2005-01-05
Anticipated expiration: 2016-09-20
Also published as: DE69632987D1; AU6552196A; EP0767563A3; EP0767563B1; EP0767563A2; TW303558B; US5758186A; CN1159631A; KR970024763A; JPH09218860A

Description

Kurzbeschreibung der Erfindung
Diese Erfindung bezieht sich allgemein auf Client/Server-Computernetzwerke. Genauer bezieht sich diese Erfindung auf einen Server-Computer, der Methodenaufrufe von Objektanfragevermittlern, die verschiedene Kommunikationsprotokolle verwenden, generisch handhaben kann.
Hintergrund der Erfindung
In einem Client/Server-Computernetzwerk fordert der Benutzer eines Client-Computers die Ausführung eines Objekts an. Genauer fordert der Benutzer die Ausführung einer dem Objekt zugeordneten Methode an. Häufig ist das Objekt nicht lokal auf dem Client-Computer gespeichert. Somit muss ein Fernprozeduraufruf (RPC = Remote Procedure Call) an einen Server-Computer weitergeleitet werden, auf dem sich das Objekt befindet. Der RPC spezifiziert das Objekt und dessen zugehörige Methode. Der Server-Computer identifiziert die auszuführende Methode, führt diese Methode aus, und leitet die Ergebnisse und/oder die erzeugten Ausnahmen wieder zum Client-Computer zurück. Der verteilte Mechanismus zum Handhaben von Fernprozeduraufrufen wird häufig als Objektanfragevermittler (ORB = Object Request Broker) bezeichnet. Der Mechanismus ist in dem Sinne verteilt, dass die einem ORB zugewiesene Software sich sowohl auf dem Client-Computer als auch dem Server-Computer befindet.
Es gibt eine große Anzahl von "drahtgebundenen" Datenformaten, die ein Client-Computer verwenden kann, um einen Fernprozeduraufruf zu einem Server-Computer zu senden. Die gleichen drahtgebundenen Datenformate werden auch verwendet, um die Ergebnisse vom Server-Computer zum Client-Computer zurückzusenden. Allgemeiner ausgedrückt definieren diese drahtgebundenen Datenformate das Format aller Nachrichten, die Fernprozeduraufrufen zugeordnet sind.
Die drahtgebundenen Datenformate, hier allgemein als Protokolle bezeichnet, legen solche Faktoren fest, wie z. B., auf welche Art Argumente weitergeleitet werden und wie Datentypen gehandhabt werden. Verschiedene Lieferanten implementieren ORBs mit unterschiedlichen Protokollen. Vor kurzem wurde eine Industrienorm mit der Bezeichnung Universal-Networked-Objects-(UNO)-Protokoll von der Object Management Group veröffentlicht. Dieses Protokoll wird in erster Linie als ein Gateway-Protokoll für die Verbindung von Objektsystemen von unterschiedlichen Lieferanten betrachtet. Schließlich scheinen verschiedene Lieferanten kurzfristig ihre bestehenden Protokolle für eine höhere Leistungsfähigkeit innerhalb ihrer eigenen Objektsysteme weiter verwenden zu wollen, während UNO-Gateways mit geringer Leistungsfähigkeit auf ihren ORBs unterstützt werden. Diese RBC-bezogenen Nachrichten werden weiterhin unter Verwendung einer Vielfalt von Protokollen transportiert. Es wäre folglich sehr wünschenswert, einen Server-Computer zu schaffen, der eine beliebige Anzahl von Protokollen, die in RBC-bezogenen Nachrichten verwendet werden, leicht und schnell erkennt.
EP 0 690 235 A1 offenbart einen Dienstvermittler, der Dienstanfragen und bereitgestellte Dienstantworten von mehreren Clients bzw. Servern verwaltet, die sich auf unterschiedlichen Hardwareplattformen und Betriebssystemen befinden können und mit Computernetzwerken mit verschiedenen Netzwerkarchitekturen und zugehörigen Kommunikationsprotokollen verbunden sein können.
EP 0 456 249 A2 offenbart ein System, das Anwendungen integriert, die auf mehreren homogenen oder heterogenen Computern an einem Netz laufen.
Zusammenfassung der Erfindung
Die Erfindung schafft ein Verfahren zur Handhabung diverser Protokoll-Methodenaufrufe, wie in Anspruch 1 dargelegt ist, und einen computerlesbaren Speicher, wie in Anspruch 7 dargelegt ist.
Eine Ausführungsform der Erfindung ist ein verteiltes Client/Server-Computersystem mit einer großen Anzahl von Client-Computern, die mit einem Übertragungskanal verbunden sind. Die Client-Computer erzeugen Methodenaufrufe (auch als Fernprozeduraufrufe bezeichnet), die dem Übertragungskanal zugeführt werden. Jeder Methodenaufruf kann mit einem unterschiedlichen Kommunikationsprotokoll codiert sein. Ein Server-Computer verarbeitet jeden Methodenaufruf, den er über den Übertragungskanal empfangen hat, durch anfängliches Lokalisieren eines in einem protokollabhängigen Format spezifizierten Methodendeskriptors innerhalb des Methodenaufrufs. Der Methodendeskriptor wird anschließend mit einer Liste von protokollabhängigen Werten verglichen, die im Speicher des Server-Computers gespeichert sind. Beim Abgleich des Methodendeskriptors mit einem ausgewählten protokollabhängigen Wert in der Liste der protokollabhängigen Werte wird ein Indexwert zugewiesen. Der Indexwert wird zu einem protokollunabhängigen Abschnitt des Server-Computers weitergeleitet. Der protokollunabhängige Abschnitt des Servers führt anschließend das Verfahren aus, das dem Indexwert entspricht, um eine Antwort zu erzeugen. Die Antwort wird anschließend über den Übertragungskanal zum Client-Computer transportiert.
Eine weitere Ausführungsform der Erfindung enthält den Schritt des Empfangens eines von einem Client-Computer erzeugten Methodenaufrufs an einem Server-Computer. Anschließend wird eine in einem protokollabhängigen Format spezifizierte Methodenbeschreibung innerhalb des Methodenaufrufs lokalisiert. Anschließend wird beim Abgleich des Methodendeskriptors mit einem ausgewählten protokollabhängigen Wert in einer Liste protokollabhängiger Werte ein Indexwert zugewiesen. Anschließend wird der Indexwert an ein protokollunabhängiges Verarbeitungsmodul des Servers weitergeleitet. Der Server führt die Methode aus, die dem Indexwert entspricht, wobei die Ergebnisse dieser Methodenausführung anschließend über den Übertragungskanal zum Client-Computer transportiert werden.
Der protokollunabhängige Abschnitt des Servers bildet einen einzelnen Satz von objektspezifischern Code, der verwendet werden kann, um alle Methodenaufrufe zu verarbeiten, unabhängig von dem Protokoll, das vom Client-Computer verwendet wird, um den Methodenaufruf zum Server zu senden. Folglich sind für die Verarbeitung der unterschiedlichen Protokolle, die auf dem Übertragungskanal verwendet werden, keine unterschiedlichen Sätze von objektspezifischern Computercode erforderlich. Die vorliegende Erfindung erleichtert somit die Verarbeitung von Fernprozeduraufrufen von Methoden in Objekten in einer sprach- und lieferantenunabhängigen Weise. Als Ergebnis kann von unterschiedlichen Client-Umgebungen transparent auf Netzwerk-Server zugegriffen werden. Somit können z. B. Netzwerk-Server im Internet die Anfragen von Client-Computern verarbeiten, und Client-Computer können auf Netzwerk-Server in einer Weise zugreifen, die vorher nicht möglich war.
Kurzbeschreibung der Zeichnungen
Im Folgenden werden Beispiele der Erfindung in Verbindung mit den beigefügten Zeichnungen beschrieben, in welchen:
1 eine Client/Server-Computertopologie zeigt;
2 die Verarbeitung zeigt, die der Vorrichtung der 1 zugeordnet ist;
3 die Verarbeitungsschritte zeigt, die einer Ausführungsform der Protokollerkennungsmethodik der Erfindung zugeordnet sind;
4 ein Beispiel einer Datenstruktur zeigt, die bei der Ausführung der offenbarten Technik verwendet werden kann;
5 eine verallgemeinerte Darstellung einer Datenstruktur ist, die bei der Ausführung der offenbarten Technik verwendet werden kann.
Ähnliche Bezugszeichen beziehen sich über die mehreren Ansichten der Zeichnungen hinweg auf entsprechende Teile.
Genaue Beschreibung der Erfindung
1 zeigt eine Client/Server-Computervorrichtung 20, die die Technik enthält, die die vorliegende Erfindung verkörpert. Die Vorrichtung 20 enthält einen Satz von Client-Computern 22A–22N, die jeweils mit einem Übertragungskanal 23 verbunden sind. Der Übertragungskanal 23 bezieht sich allgemein auf eine beliebige drahtgebundene oder drahtlose Verbindung zwischen Computern. Die Client-Computer 22A–22N verwenden den Übertragungskanal 23, um mit einem Server-Computer 24 zu kommunizieren.
Jeder Client-Computer 22 weist eine Standard-Computerkonfiguration auf, die eine Zentraleinheit (CPU) 30 enthält, die mit einem Speicher 32 verbunden ist, der einen Satz von ausführbaren Programmen speichert. Die ausführbaren Programme in diesem beispielhaften System umfassen wenigstens ein Client-Anwendungsprogramm 34, Client-Stummelprogramme 38, Client-Unterkontraktprogramme 40 und ein Betriebssystem 42.
Das Client-Anwendungsprogramm 34 ist ein beliebiges Programm auf Anwendungsebene, wie z. B. ein Anwendungsprogramm, mit dem der Benutzer eines Client-Computers 22 interagiert. Die Client-Stummelprogramme 38 empfangen Prozeduraufrufe vom Anwendungsprogramm 34, die die Ausführung spezifizierter Methoden von spezifizierten Objekten anfordern. Der Zweck der Client-Stummelprogramme 38 ist, auf Objekte zuzugreifen, die in anderen Adressräumen, wie z. B. auf einem Server-Computer 24, implementiert sind.
Die Client-Unterkontraktprogramme 40 und die Server-Unterkontraktprogramme 58 steuern die Grundmechanismen des Objektaufrufs und der Argumentweiterleitung. Sie steuern, wie der Objektaufruf implementiert wird, wie Objektreferenzen zwischen Adressräumen übertragen werden, wie Objektreferenzen aufgelöst werden, und ähnliche Objektlaufzeitoperationen. Wenn z. B. ein Client ein Objekt eines gegebenen Unterkontraktes aufruft, implementiert der Unterkontrakt den Objektaufruf durch Senden der Anfrage zu dem Adressraum, in dem das zugehörige Objekt angeordnet ist, gewöhnlich dem Server-Computer 24.
Die Client-Unterkontraktprogramme 40 führen eine Sortierungsoperation durch, um einen Objektaufruf (d. h. einen Fernprozeduraufruf) zu einem weiteren Adressraum zu senden. Eine entsprechende Resortierungsoperation wird von einem Server-Unterkontraktprogramm 58 auf dem Server-Computer 24 durchgeführt. Die Client-Unterkontraktprogramme 40 führen ebenfalls Resortierungsoperationen durch, wenn sie eine Antwort (wie z. B. die von einem Methodenaufruf erzeugten Ergebnisse) von einem weiteren Computer, z. B. dem Server-Computer 24, empfangen. Ein Betriebssystem 42, wie z. B. das SOLARIS Betriebssystem von Sun Microsystems liegt den Operationen der Client-Anwendungsprogramme 34, der Client-Stummelprogramme 38 und der Client-Unterkontraktprogramme 40 zu Grunde.
Der Server 24 weist eine Konfiguration ähnlich derjenigen der Client-Computer 22 auf. Der Server 24 enthält eine CPU 50 und einen zugehörigen Speicher 52. Der Speicher 52 speichert Server-Anwendungsprogramme 54, Server-Stummelprogramme 56, Server-Unterkontraktprogramme 58 und ein Betriebssystem 60. Wie oben angegeben ist, behandeln die Server-Stummelprogramme 56 ankommende Methodenaufrufe für ein Objekt und rufen die spezifizierte Methode auf, um die Operation durchzuführen. Wie oben ferner angegeben ist, führen die Server-Unterkontraktprogramme 58 eine Datensortierung und andere Operationen durch, um den Transport der Verfahrensaufrufe und der resultierenden Rückkehrnachrichten zwischen dem Server 24 und dem Client-Computern 22 zu unterstützen.
Die Operationen der Vorrichtung der 1 werden mit Bezug auf 2 genauer eingeschätzt. 2 zeigt den Client-Computer 22A, den Übertragungskanal 23 und den Server 24 der 1. Wie oben angegeben ist, ruft eine Client-Anwendung 34 eine spezifizierte Methode eines Objekts in einem anderen Adressraum unter Verwendung eines Fernprozeduraufrufes auf. Der Fernprozeduraufruf wird von den Client-Stummelprogrammen 38 zum Client-Unterkontraktprogramm 40 weitergeleitet, welches den Fernprozeduraufruf für den Transport auf dem Übertragungskanal 23 verpackt. Das Server-Unterkontraktprogramm 58 des Servers 24 empfängt die Informationen und packt diese aus. Das Server-Unterkontraktprogramm 58 leitet anschließend die Informationen zu den Server-Stummelprogrammen 56 weiter. Die Server- Stummelprogramme 56 greifen auf die Server-Anwendungsprogramme 54 zu, die die vorher beschriebenen Objektmethoden sind. Genauer macht ein spezifiziertes Server-Stummelprogramm 56 einen Prozeduraufruf, um eine spezifizierte Methode des aufgerufenen Objekts auszuführen. Die Ausführung der Methode erzeugt einen Satz von Ergebnissen, hier als Antwort bezeichnet, der anschließend zum Server-Unterkontraktprogramm 58 zurückgeleitet wird, wobei der Kommunikationsweg umgekehrt ist, wie durch die Pfeile der 2 gezeigt ist.
Block 70 der 2 zeigt die Komponenten, die einem Objektanfragevermittler (ORB) der Erfindung zugeordnet sind. Wie oben angegeben ist, wird eine breite Vielfalt von Kommunikationsprotokollen in den ORBs verwendet. Die Verwendung verschiedener Protokolle auf verschiedenen ORBs führt zu Schwierigkeiten, wenn ein Server versucht, ankommende Objektanfragen zu erkennen.
Die allgemeine Architektur und die Verarbeitung, die den Ausführungsformen der Erfindung zugewiesen sind, wurden nun offenbart. Die Aufmerksamkeit wird jetzt auf eine genauere Betrachtung der Architektur und der Verarbeitung der Ausführungsformen und der Unterscheidungen zwischen den Elementen und entsprechenden Elementen des Standes der Technik und der Vorteile, die der offenbarten Technik zugeordnet werden, gerichtet.
Wie in 2 gezeigt ist, verwendet ein Client-Unterkontraktprogramm 40 einen protokollabhängigen Methodendeskriptor, um eine einem aufgerufenen Objekt zugeordnete Methode anzufordern. Genauer verwendet das Client-Unterkontraktprogramm 40 einen Sortierungspuffer, der einem ausgewählten drahtgebundenen Datenformat folgt. Um z. B. eine gegebene Methode "X" zu identifizieren, kann ein Protokoll einen Wert "XXX" verwenden, eine weitere kann einen Wert "@@@::123::" verwenden, und eine weitere kann einen Ganzzahlwert "123456" verwenden, wobei der Wert die Ausgabe einer Hash-Funktion für den Methodennamen ist. Das Client-Stummelprogramm 38 leitet an das Client-Unterkontraktprogramm 40 eine Liste protokollabhängiger Werte weiter, aus der das Client-Unterkontraktprogramm 40 den protokollabhängigen Methodendeskriptor berechnet.
Wenn somit ein Satz von Client-Computern 22A–22N mit einem Server 24 verbunden ist, muss der Server 24 jedes Protokoll verarbeiten. Separate Server-Unterkontraktprogramme 58 (nicht gezeigt) sind notwendig, um jedes dieser Protokolle zu bewältigen. Im Stand der Technik weist jedes Server-Unterkontraktprogramm 58 einen Satz entsprechender Server-Stummelprogramme 56 auf. Um somit ORBs mit mehreren Protokollen zu unterstützen, sollte ein Server 24 verschiedene Server-Stummelprogramme 56 für jedes Protokoll aufweisen, was zu einem großen Satz von Server-Stummelprogrammen 56 führt. Folglich kann leicht abgeschätzt werden, dass die Verwendung unterschiedlicher ORB-Protokolle zu unhandlichen Anforderungen an den Server 24 führt.
Wenn gemäß der vorliegenden Erfindung das Server-Unterkontraktprogramm 58 einen ankommenden Methodenaufruf empfängt, resortiert es den Methodendeskriptor in einer Weise, die für das Unterkontraktprotokoll spezifisch ist. Anschließend versucht es, den Methodendeskriptor mit jedem der Einträge in einer Liste protokollabhängiger Werte abzugleichen. Die protokollabhängigen Werte können Zeichenketten, numerische Werte, sowie andere Typen von Parameterwerten sein. Verschiedene Protokolle können verschiedene Abgleichfunktionen verwenden, um den Methodendeskriptor mit der Liste der protokollabhängigen Werte zu vergleichen. Die Abgleichfunktion kann mittels eines Kettenvergleichs, einer Hash-Funktion, oder einer anderen Technik bewerkstelligt werden, die durch das Server-Unterkontraktprogramm 58 spezifiziert wird. Wenn ein passender protokollabhängiger Wert identifiziert wird, kann das Server-Unterkontraktprogramm 58 anschließend diesem einen Indexwert zuweisen.
Wie in 2 gezeigt ist, wird der Indexwert zu den protokollunabhängigen Server-Stummelprogrammen 56 weitergeleitet, die die dem Indexwert entsprechende Methode aufrufen können. Auf diese Weise werden die Protokollabhängigkeiten der individuellen Objektreferenzen von den protokollunabhängigen Server-Stummelprogrammen 56 isoliert. Folglich können protokollunabhängige Server-Stummelprogramme 56 mit einem beliebigen Typ von Objektanfragevermittler 70 verwendet werden. Ferner kann ein einzelner Compiler verwendet werden, um die protokollunabhängigen Server-Stummelprogramme 56 zu erzeugen.
Im Gegensatz zum Stand der Technik schafft die vorliegende Erfindung somit einen Server 24, der eine Vielfalt von ORB-Protokollen erkennt. Außerdem führt er diese Funktion in einer hocheffektiven Weise durch, indem er einen einzelnen Satz von protokollunabhängigen Server-Stummelprogrammen 56 verwendet. Es ist zu beachten, dass zur Unterstützung dieser Technik die Sortierungs- und Resortierungsoperationen, die gewöhnlich von Stummelprogrammen des Standes der Technik verwendet werden, vom Client-Unterkontraktprogramm 40 und vom Server-Unterkontraktprogramm 58 der Erfindung ausgeführt werden. Diese Übertragung der Verarbeitung und die Verwendung eines Indexwertes, um protokollunabhängige Server-Stummelprogramme bereitzustellen, stellen die Verarbeitungsunterschiede zwischen dem Stand der Technik und der vorliegenden Erfindung dar. Die vorliegende Erfindung kann somit in bestehenden Architekturen und Prozessen erfolgreich implementiert werden, sobald diese Verarbeitungsunterschiede berücksichtigt werden.
3 zeigt eine genaue Darstellung der Verarbeitungsschritte, die in den vorangehenden Absätzen beschrieben worden sind. Der erste Verarbeitungsschritt der 3 besteht darin, dass das Server-Unterkontraktprogramm einen Methodendeskriptor in einen Methodenaufruf identifiziert (Block 80). Wie oben angegeben ist, erzeugt der Client-Computer einen Methodenaufruf, der schließlich in einem Sortierungspuffer als Satz von Informationen verpackt wird. Der Inhalt der Information ist bedingt durch das Client-Unterkontraktprogramm, das die Informationen sortiert hat. Das entsprechende Unterkontraktprogramm am Server resortiert die Informationen und erkennt innerhalb der Informationen den Methodendeskriptor.
Der nächste Verarbeitungsschritt ist für das Server-Unterkontraktprogramm, einen protokollabhängigen Wert auszuwählen, der zum Methodendeskriptor passt (Block 82). Diese Operation kann mit Bezug auf 4 dargestellt werden. 4 zeigt eine Deskriptorliste (Descriptor_List) protokollabhängiger Werte. Diese Liste enthält N Teilmengenlisten. Jede Teilmengenliste identifiziert einen Satz von protokollabhängigen Werten, die verwendet werden können, um eine einzelne Methode zu identifizieren. Jede Teilmengenliste besitzt j Einträge. In 4 sind diese Einträge als Descriptor_List_1_1 bis Descriptor_List_1_j gezeigt. In 4 ist Descriptor_List_1_! einem Schnittstellendefinitionssprachen-Kurznamen (IDL = Interface Definition Language) zugewiesen. IDL ist eine Industrienorm. Das heißt, ein Eintrag in der Liste ist der IDL-Kurzname (IDL Short Name) für die aufgerufene Methode. Der IDL-Kurzname ist ein ORB-Protokollname, der im Stand der Technik verwendet wird. Die gleiche Liste zeigt, dass Descriptor_List_1_2 einem IDL-Langnamen (IDL Long Name) zugewiesen ist. Das heißt, dieser Eintrag in der Liste ist der IDL-Langname für die aufgerufene Methode. Der IDL-Langname ist ein weiterer ORB-Protokollname, der im Stand der Technik verwendet wird. Der dritte Eintrag in der Teilmengenliste ist Descriptor_List_1_3, der eine Aufbewahrungsort-ID (Repository ID) aufweist. Die Aufbewahrungsort-ID ist ein Name, der in einem weiteren ORB-Protokoll im Stand der Technik verwendet wird. Beispiele dieser verschiedenen Protokolle umfassen folgende Anweisungen:
"get_weak_operator" (IDL-Kurzname),
"::comparator::weak_comparable::get_waek_comparator" (IDL-Langname), und
"IDL:/comparator/weak_comparable/get_weak_comparator: 1.0" (Aufbewahrungsort-ID),
die verwendet werden, um folgende Operation aufzurufen:
get_weak_comparator.
Wie in 4 gezeigt ist, können auch wechselnde Bezeichnungen in der Liste der protokollabhängigen Werte verwendet werden. Außerdem müssen nicht die im Beispiel gezeigten Bezeichnungen verwendet werden. In jedem Fall ist es unter Verwendung des Formats, das durch die IDL-Norm und andere Industrienormen und die Praxis etabliert ist, möglich, die Art vorherzusagen, in der die meisten Methodendeskriptoren durch irgendein vernünftiges Protokoll implementiert werden.
Der folgende Pseudo-Code wird als ein einfaches Beispiel verwendet, um zu zeigen, wie die Deskriptorliste durchsucht werden kann.
Die Zeilen (1) und (2) bewerkstelligen die Initialisierung. Die Zeile (3) ist der Eintritt in eine Verarbeitungsschleife. Die Zeile (4) bewerkstelligt die Initialisierung innerhalb der Verarbeitungsschleife. Die Zeile (5) testet auf eine Bedingung. Das heißt, der Code prüft, ob der resortierte "Methodendeskriptor" des Methodenaufrufs zum "j-ten" Eintrag der "i-ten" Teilmengenliste (Descriptor_List_i_j) der protokollabhängigen Liste passt. Der "j-te" Eintrag, z. B. der IDL-Kurzname, ist für das Server-Unterkontraktprogramm 58 dafür bekannt, derjenige zu sein, der für dieses Protokoll verglichen wird. Der "i-te" Wert ist ein inkrementierter Wert, der jeder Teilmengendeskriptorliste (Descriptor_List_1 bis Descriptor_List_N) erlaubt, geprüft zu werden. Der Ausdruck "Match_p" bezieht sich auf die Abgleichfunktion, die verwendet wird, um den Methodendeskriptor mit den Listeneintrag zu vergleichen. Zum Beispiel kann "Match_p" einen einfachen Kettenvergleich zwischen Werten spezifizieren, oder kann den Vergleich von Hash-Werten spezifizieren. Die Definition von "Match_p" wird vom Server-Unterkontraktprogramm 58 bereitgestellt.
Wenn die Bedingung erfüllt wird, wird eine Übereinstimmung gefunden, während ansonsten die nächste Teilmengenliste "i" genommen wird. Wenn eine Übereinstimmung gefunden worden ist, stellt die Zeile (8) einen Aufruf einer Operationstabelle der Server-Stummelprogramme (56) bereit. Es ist zu beachten, dass der Wert "i", wenn eine Übereinstimmung gefunden worden ist, der Wert ist, der zu den Server-Stummelprogrammen weitergeleitet wird. Dieser Wert entspricht einer Teilmenge der gesuchten Liste, wobei diese Teilmenge einer einzelnen Methode zugeordnet ist, die aufgerufen worden ist. Der Code in der Zeile (8) zeigt somit den nächsten Verarbeitungsschritt der 3, nämlich, dass das Server-Unterkontraktprogramm einen Indexwert an die Server-Stummelprogramme weiterleitet (Block 86).
Sobald die Server-Stummelprogramme den Indexwert empfangen, greifen sie auf eine Operationstabelle 100 zu, die in 4 gezeigt ist, um die durch den Indexwert spezifizierte Methode aufzurufen. Die Operationstabelle ist vorzugsweise als eine Falltabelle implementiert, die einen Satz von Verarbeitungsschritten aufweist, die jedem Fallwert "i" zugeordnet sind. Wenn der Wert "i" empfangen wird, wird die durch den Wert spezifizierte Methode ausgeführt (Block 88). 4 zeigt einen Beispielsatz von Verarbeitungsschritten, um dieses Ergebnis zu erreichen. Der erste Schritt besteht in der Ausführung der Methode i, wobei der zweite Schritt darin besteht, alle resultierenden Nachrichten (die Antwort) in den Sortierungspuffer zu laden. Der letzte Verarbeitungsschritt, der in 3 gezeigt ist, besteht darin, dass die Server-Stummelprogramme die durch die Ausführung der Methode erzeugte Antwort an die Server-Unterkontraktprogramme (Block 90) weiterleiten.
Die Ausführungsform wurde nun vollständig offenbart. 5 zeigt einen zusätzlichen Aspekt der Technik. Das heißt, 5 zeigt, dass die Ausführungsform Methodenaufrufe und deren zugehörige Ausnahmen unterstützt. 5 zeigt die Operationstabelle 100 der 4. Wie oben angegeben ist, ist die Operationstabelle in den Server-Stummelprogrammen 56 gespeichert. Die Figur zeigt, dass der Indexwert "i" die Operationstabelle mit einer bestimmten Teilmenge (Descriptorliste i bzw. Descriptor_List_i) der Liste verknüpft ist. Wie oben angegeben ist, ist die Deskriptorliste für das Server-Unterkontraktprogramm 58 verfügbar. Die Teilmengenliste enthält "j" Einträge, einschließlich eines IDL-Kurznamens, eines IDL-Langnamens, einer Aufbewahrungsortidentifikation, einer wechselnden Identifikation und dergleichen. Wie in 4 gezeigt ist, ruft der Server die Operation i von der Operationstabelle 100 auf und gibt eine Antwort an den Client zurück. Die Antwort kann einen Ausnahmedeskriptor enthalten. Unter Berufung auf das obige Beispiel "get_weak_comparatorOperationDescriptorInstance" kann z. B. der Ausnahmedeskriptor die Kette "_get_weak_comparatorExceptionDescriptorInstance" sein.
Das Client-Unterkontraktprogramm 40 weist den Operationsdeskriptor auf, der eine Ausnahmeliste enthält. Der Ausnahmedeskriptor in der Antwort wird von dem client-seitigen Unterkontraktprogramm 40 verwendet, um zu ermitteln, welche Ausnahme zurückgegeben wurde. Diese Abgleichoperation kann unter Verwendung der obenbeschriebenen Technik zum Abgleichen des Operationsdeskriptors durchgeführt werden.
Der Ausnahmedeskriptor zeigt auf eine Ausnahmeliste, die N Ausnahme-Teilmengenlisten aufweist. 5 zeigt die Ausnahmeliste x (Exception_List_x). Jede Teilmengenliste spezifiziert eine der Ausnahmen für den Methodenaufruf und dem IDL-Kurznamen, den IDL-Langnamen, eine Aufbewahrungsortidentifikation und eine wechselnde Identifikation für die Ausnahme. Es ist zu beachten, dass der j-te" Eintrag jeder Teilmengenliste der Liste der protokollabhängigen Werte einem bestimmten Protokoll entspricht, z. B. dem IDL-Kurznamenprotokoll.
Das Ausnahmedeskriptor-Konzept ist in 4 genauer gezeigt. Es ist zu beachten, dass der letzte Eintrag in der Teilmengendeskriptorliste "Descriptor_List_1" ein Ausnahmedeskriptor ist, der auf eine Ausnahmeliste zeigt. Die vom Server-Computer erzeugte und zum Client-Computer weitergeleitete Antwort enthält eine Angabe der Ausnahme, falls erforderlich. Die Ausnahme kann mit einer Ausnahme in der Ausnahmeliste abgeglichen sein.
Das Client-Unterkontraktprogramm 40 speichert eine Kopie der einem Ausnahmedeskriptor zugewiesenen Ausnahmeliste. Wenn somit der Ausnahmedeskriptor vom Server-Computer 24 empfangen wird, kann der Client-Computer 22 den Ausnahmedeskriptor verarbeiten.
Der Ausnahmedeskriptor wird verarbeitet durch Aufrufen eines Ausnahmecodes für jeden Eintrag in der Ausnahmeliste. In 5 ist zu beachten, dass Exception_List_x, ähnlich allen anderen Ausnahmeteilmengenlisten, eine Ausnahmeobjektidentifikation enthält, die auf ein Objekt in einem lokalen Objektaufbewahrungsort 104 zeigt. Die Ausnahmeobjektidentifikation kann ein Kettenname sein, der mit einem Objekt im lokalen Objektaufbewahrungsort 104 verknüpft ist. Jedes Objekt im lokalen Objektaufbewahrungsort 104 stellt codierte Befehle oder Informationen zur Verfügung, um den Client- Computer 22 zu erlauben, die Ausnahme zu behandeln. In dem Fall, in dem sich das Objekt nicht im lokalen Objektaufbewahrungsort 104 befindet, instanziiert das Betriebssystem 42 das Objekt in dem lokalen Objektaufbewahrungsort 104 durch Herunterladen des Codes von einem weiteren Computer im Netzwerk.

Claims

Verfahren zur Handhabung von Methodenaufrufenmit diversen Protokollen in einem Client/Server-Computersystem (20), wobei das Verfahren die Schritte umfasst: Empfangen eines Methodenaufrufes, der von einem Client-Computer (22A ... 22N) erzeugt wird, an einem Server-Computer (24), dadurch gekennzeichnet, dass das Verfahren ferner die Schritte umfasst: Lokalisieren (80) eines Methodendeskriptors, der in einem protokollabhängigen Format spezifiziert ist, innerhalb des Methodenaufrufs; Wiedergewinnen (82) eines Indexwertes, der dem Methodendeskriptor zugewiesen ist; Weiterleiten (86) des Indexwertes zu einem protokollunabhängigen Verarbeitungsmodul des Server-Computers; Ausführen (88) einer Methode, die dem Indexwert entspricht, im Server-Computer, um eine Antwort zu erzeugen; und Übertragen (90) der Antwort vom protokollunabhängigen Verarbeitungsmodul zum Client-Computer.
Verfahren nach Anspruch 1, bei dem der Empfangsschritt den Schritt des Weiterleitens des Methodenaufrufes von einem Anwendungsprogramm (34) des Client-Computers (22A ... 22N) zu einem Client-Stummelprogramm (38) des Client-Computers, zu einem Unterkontraktprogramm (40) des Client-Computers, zu einem Übertragungskanal (23), der den Client-Computer und den Server-Computer (24) verbindet, und zu einem Unterkontraktprogramm (58) des Server-Computers, das die Liste der protokollabhängigen Werte speichert, umfasst.
Verfahren nach Anspruch 1, bei dem der Lokalisierungsschritt (80) den Schritt des Resortierens eines Sortierungspuffers, der den Methodenaufruf enthält, umfasst.
Verfahren nach Anspruch 1, bei dem der Wiedergewinnungsschritt (82) den Schritt der Verwendung einer Liste protokollabhängiger Werte umfasst, die Anweisungen enthalten, die aus der Gruppe ausgewählt sind, welche einen Schnittstellendefinitionssprache-(IDL)-Kurznamen, einen IDL-Langnamen und eine IDL-Aufbewahrungsortidentifikation enthält.
Verfahren nach Anspruch 1, bei dem der Weiterleitungsschritt (85) den Schritt des Weiterleitens des Indexwertes zu dem protokollunabhängigen Verarbeitungsmodul des Server-Computers enthält, das als ein Server-Stummelprogramm (56) implementiert ist, das auf dem Server-Computer läuft.
Verfahren nach Anspruch 1, bei dem der Übertragungsschritt den Schritt des Übertragens der Antwort vom Server-Stummelprogramm (56), das auf dem Server-Computer läuft, zu einem Unterkontraktprogramm (58), das auf dem Server-Computer läuft, zu einem Übertragungskanal (23), der den Server-Computer und den Client-Computer verbindet, zu einem Unterkontraktprogramm (40), das auf dem Client-Computer läuft, und zu einem Client-Stummelprogramm (38), das auf dem Client-Computer läuft, enthält.
Computerlesbarer Speicher, der verwendet werden kann, um ein Client/Server-Computersystem (20) anzuweisen, in einer spezifizierten Weise zu arbeiten, umfassend: Methodenaufrufinformationen, die im Speicher gespeichert sind, wobei die Methodenaufrufinformationen enthalten: (1) eine Liste protokollabhängiger Werte, und (2) einen Satz von Methodenausführungsbefehlsmodulen, wobei wenigstens ein Methodenausführungsbefehlsmodul einen Satz von Operationen spezifiziert, die bei der Ausführung eines angeforderten Methodenaufrufs auszuführen sind; und ausführbare Befehle, die im Speicher gespeichert sind, dadurch gekennzeichnet, dass die ausführbaren Befehle enthalten: (3) Befehle zum Lokalisieren (80) eines Methodendeskriptors, der in einem protokollabhängigen Format spezifiziert ist, innerhalb eines Methodenaufrufs, der von einem Client-Computer (22A ... 2N) des Client/Server-Computersystems stammt, (4) Befehle zum Zuweisen (82) eines Indexwertes bei Übereinstimmung des Methodendeskriptors mit einem ausgewählten protokollabhängigen Wert in der Liste der protokollabhängigen Werte, (5) Befehle zum Weiterleiten (86) des Indexwertes zu einem serverseitigen Stummel (56), der auf einem Server-Computer (24) der Client/Server-Computerarchitektur läuft, (6) Befehle zum Ausführen (88) eines ausgewählten Methodenausführungsbefehlsmoduls des Satzes der Methodenausführungsbefehlsmodule auf der Grundlage des Indexwertes auf dem Server-Computer, um eine Antwort zu erzeugen, und (7) Befehle zum Übertragen (90) der Antwort zum Client-Computer.
Computerlesbarer Speicher nach Anspruch 7, bei dem die Liste der protokollabhängigen Werte, die im Speicher gespeichert sind, Anweisungen enthält, die aus der Gruppe ausgewählt sind, die einen Schnittstellendefinitionssprache-(IDL)-Kurznamen, einen IDL-Langnamen, sowie eine IDL-Aufbewahrungsortidentifikation umfasst.
Computerlesbarer Speicher nach Anspruch 7, bei dem die Antwort eine Ausnahmebedingung für den Methodenaufruf enthält.