DE69616934T2

DE69616934T2 - Verfahren und Vorrichtung zum dynamischen Laden des Ausnahmekodes eines Methodeanrufs

Info

Publication number: DE69616934T2
Application number: DE69616934T
Authority: DE
Inventors: Graham Hamilton; Peter B. Kessler; Jeffrey D. Nisewanger
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1995-10-06
Filing date: 1996-09-11
Publication date: 2002-04-04
Anticipated expiration: 2016-09-12
Also published as: DE69616934D1; JPH09218794A; KR970024764A; AU6445696A; EP0767428A1; EP0767428B1; TW367456B; US5815708A

Description

Kurze Beschreibung der Erfindung

Diese Erfindung betrifft allgemein Client/Server-Computernetzwerke. Insbesondere betrifft diese Erfindung eine Technik zum Laden von Ausnahmekode eines Methodenaufrufs in einen Client-Computer, nur dann, wenn er bei Laufzeit benötigt wird.

Hintergrund der Erfindung

In einem Client/Server-Computernetzwerk fordert der Benutzer eines Client- Computers die Ausführung eines Objektes an. Insbesondere fordert der Benutzer die Ausführung einer dem Objekt zugeordneten Methode an. Häufig wird das Objekt nicht lokal auf dem Client-Computer gespeichert. Daher muss ein Fernprozeduraufruf (Remote Procedure Call, RPC) an einen Server-Computer durchgeführt werden, auf dem das Objekt vorgehalten wird. In den meisten Fällen führt der Server-Computer die angeforderte Methode aus, um ein Resultat zu erzeugen. Das Resultat wird dann an den Client-Computer übergeben. Wenn jedoch der Server-Computer die angeforderte Methode nicht oder nur einen Teil der angeforderten Methode ausführen kann, sagt man, dass ein Ausnahme existiert. In diesem Fall benachrichtigt der Server-Computer den Client-Computer von der Ausnahme. Es obliegt dann dem Client-Computer, die Art der Ausnahme zu interpretieren und korrigierende Maßnahmen zu ergreifen.
In vielen verteilten Computersystemen, die Fernprozeduraufrufe unterstützen, z. B. Computersysteme, die das SOLARISTM-Betriebssystem in Verbindung mit der JAVATM-virtuellen Maschinenumgebung, beide von Sun Microsystems®, Inc., Mountain View, Kalifornien (SOLARISTM, JAVATM und Sun Microsystems® sind Marken oder registrierte Marken von Sun Microsystems, Inc. in den Vereinigten Staaten und anderen Ländern) benutzen, instanziiert der Client-Computer den gesamten der Methode zugeordneten Ausnahmekode, wenn ein Client-Computer die Ausführung einer Methode in einem Objekt anfordert (manchmal Aufrufen einer Objektmethode genannt). Der Ausnahmekode kann lokal auf dem Client- Computer gespeichert werden, aber in vielen Fällen muss der Ausnahmekode von einem entfernten Computer abgerufen werden. Konsequenterweise muss in dem meisten Fällen der Client-Computer durch das Aufrufen eines Objektes einen Ausnahmekode von einem entfernten Computer abrufen. Starten von Kommunikation mit dem entfernten Computer und Austauschen von Information mit ihm ist eine relativ Zeit konsumierende Operation.
Da in den meisten Fällen die aufgerufene Methode erfolgreich ausgeführt wird, wird der Methoden-Ausnahmekode von dem Client-Computer nicht benutzt. Daher verbraucht der Client-Computer wertvolle Zeit zum Laden von Ausnahmekode, der nicht nötig ist. In Anbetracht dieser Situation wäre es sehr wünschenswert, eine Technik zum Laden von Methoden- Ausnahmekode nur in dem Fall, dass er bei Laufzeit benötigt wird, zur Verfügung zu stellen.
IBM Technical Disclosure Bulletin, Vol. 35, Nr. 1A, Juni 1992, Seiten 23-24, offenbart eine Technik, die es erlaubt, Ausführungskontrolle an ein Benutzerprogramm zu übertragen, falls eine Fehlerausnahme in dem Benutzerprogramm oder einer von ihm aufgerufenen Routine auftritt. Dies wird durch ein Benutzerprogramm erreicht, das die Adresse des Beginns von Fehlerbehandlungsanweisungen bei einem festen Offset in seinem Speicherbereich registriert. In einer Fehlersituation wird eine Verzweigung an die entsprechende Adresse durch den Benutzerkode durchgeführt, wobei, falls nötig, der Stapel von Speicherbereichen zusammengebrochen wird.

Zusammenfassung der Erfindung

Die Erfindung stellt ein Verfahren, wie in Anspruch 1 ausgeführt, zur Verfügung. Die Erfindung stellt ebenso einen computerlesbaren Speicher, wie in Anspruch 7 ausgeführt, zur Verfügung.
Eine Ausführung der Erfindung beinhaltet den Schritt, bei einem Server- Computer einen Methodenaufruf, der von einem Client-Computer erzeugt worden ist, zu empfangen. Der Server-Computer versucht dann, den Methodenaufruf auszuführen und erzeugt darauf folgend eine Ausnahme. Die Ausnahme wird an den Client-Computer übergeben. Der Client- Computer passt die Ausnahme an Ausnahmen in einer Ausnahmeliste, die auf dem Client-Computer gespeichert wird, an, um einen Ausnahme- Objektbezeichner zu erhalten. Der Ausnahme-Objektbezeichner wird benutzt, um einen Ausnahmekode in den Client-Computer zu laden. Der Ausnahmekode wird dann ausgeführt, um die Ausnahme zu behandeln. Daher wird der Ausnahmekode zu der Zeit des Erzeugens des Methodenaufrufs nicht geladen. Stattdessen wird er nur dann geladen, wenn er bei Laufzeit benötigt wird.
Die Vorrichtung gemäß der Erfindung kann einen Client-Computer, der einen Methodenaufruf erzeugt, enthalten. Ein Server-Computer empfängt den Methodenaufruf von einem Übertragungskanal, der zwischen dem Client- Computer und Server-Computer angeschlossen ist. Der Server-Computer versucht, den Methodenaufruf auszuführen, und erzeugt danach eine Ausnahme. Die Ausnahme wird über den Übertragungskanal an den Client- Computer übergeben. Der Client-Computer passt die Ausnahme an einen Satz gespeicherter Ausnahmen an. Die angepasste Ausnahme ist einem Ausnahme-Objektbezeichner zugeordnet. Der Ausnahme-Objektbezeichner wird benutzt, um den Ausnahmekode zu laden. Der Client-Computer führt dann den Ausnahmekode aus und antwortet dadurch auf die Ausnahme, die von dem Methodenaufruf erzeugt worden ist.
Die Client-Computer arbeiten viel schneller, weil sie weniger Information laden, wenn eine Methode aufgerufen wird. Genaugenommen laden sie nur den Kode für den Methodenaufruf. Für das relativ ungewöhnliche Ereignis eines nicht erfolgreichen Methodenaufrufs wird der der Methode zugeordnete Methoden-Ausnahmekode schnell geladen.

Kurze Beschreibung der Zeichnungen

Beispiele der Erfindung werden im Folgenden beschrieben unter Bezugnahme zu den begleitenden Zeichnungen, in denen:
Fig. 1 eine Client/Server-Computertopologie zeigt.
Fig. 2 die der Vorrichtung von Fig. 1 zugeordnete Bearbeitung zeigt.
Fig. 3 die Bearbeitungsschritte zeigt, die der Protokoll- Erkennungsmethodologie einer Ausführung der Erfindung zugeordnet sind.
Fig. 4 ein Beispiel einer Datenstruktur zeigt, die zum Praktizieren der offenbarten Technologie benutzt werden kann.
Fig. 5 eine verallgemeinerte Repräsentation einer Datenstruktur ist, die beim Praktizieren der offenbarten Technologie benutzt werden kann.
Fig. 6 Bearbeitungsschritte illustriert, die dem dynamischen Laden von Ausnahmekode gemäß einer Ausführung der vorliegenden Erfindung zugeordnet sind.
Gleiche Bezugszeichen beziehen sich auf die entsprechenden Teile über verschiedene Ansichten der Zeichnungen hinweg.

Detaillierte Beschreibung der Erfindung

Fig. 1 zeigt eine Client/Server-Computervorrichtung 20, die die Technologie der vorliegenden Erfindung integriert. Die Vorrichtung 20 beinhaltet einen Satz Client-Computer 22A-22N, die mit einem Übertragungskanal 23 verbunden sind. Der Übertragungskanal 23 bezieht sich gattungsgemäß auf irgendeine Draht- oder drahtlose Verbindung zwischen den Computern. Die Client-Computer 22A-22N benutzen den Übertragungskanal 23, um mit einem Server-Computer 24 oder anderen Server-Computern, die durch den Server-Computer 24N bezeichnet werden, zu kommunizieren.
Jeder Client-Computer 22 hat eine Standard-Computerkonfiguration, die eine zentrale Prozessoreinheit (CPU) 30 beinhaltet, die mit einem Speicher 32, der einen Satz ausführbarer Programme speichert, verbunden ist. Die ausführbaren Programme in diesem Beispielsystem beinhalten mindestens ein Client-Anwendungsprogramm 34, Client-Stubs 38, Client-Subcontracts 40, und ein Betriebssystem 42.
Das Client-Anwendungsprogramm 34 ist irgendein Programm auf Anwendungsniveau, wie beispielsweise ein Anwendungsprogramm, mit dem ein Benutzer eines Client-Computers 22 interagiert. Die Client-Stubs 38 empfangen Prozeduraufrufe durch das Anwendungsprogramm 34, das die Ausführung von spezifizierten Methoden spezifizierter Objekte anfordert. Der Zweck der Client-Stubs 38 ist es, auf Objekte, die an anderen Adressplätzen, wie beispielsweise bei dem Server-Computer 24, implementiert sind, zuzugreifen.
Die Client-Subcontract-Programme 40 und Server-Subcontract-Programme 58 kontrollieren die grundsätzlichen Mechanismen des Objektaufrufs und Argument-Übergebens. Sie kontrollieren, wie das Aufrufen von Objekten implementiert ist, wie Objektreferenzen zwischen Adressplätzen übertragen werden, wie Objektreferenzen freigegeben werden und ähnliche Objektlaufzeit-Operationen. Wenn z. B. ein Client ein Objekt eines gegebenen Subcontracts aufruft, implementiert der Subcontract den Objektaufruf durch Übertragen der Anforderung an den Adressplatz, wo das zugeordnete Objekt lokalisiert ist, gemeinhin den Server-Computer 24.
Die Client-Subcontract-Programme 40 führen eine Zusammenstellungs- (Marshal-)Operation durch, um einen Objektaufruf (d. h. einen Fernprozeduraufruf) an einen anderen Adressplatz zu übertragen. eine entsprechende Auseinanderziehungs-(Unmarshalling-)Operation wird durch einen Server-Subcontract 58 auf dem Server-Computer 24 durchgeführt. Die Client-Subcontract-Programme 40 führen ebenso Auseinanderziehungs- Operationen durch, wenn sie eine Antwort (wie die von einem Methodenaufruf erzeugten Resultate) von einem anderen Computer empfangen, z. B. dem Server-Computer 24. Ein Betriebssystem 42, wie das Sun Microsystems SOLARIS-Betriebssystem, unterliegt den Operationen der Client-Anwendungsprogramme 34, der Client-Stubs 38, und der Client- Subcontracts 40.
Der Server 24 hat eine Konfiguration analog zu der der Client-Computer 22. Der Server 24 enthält eine CPU 50 und einen zugeordneten Speicher 52. Der Speicher 52 speichert Server-Anwendungsprogramme 54, Server-Stubs 56, Server-Subcontract-Programme 58 und ein Betriebssystem 60. Wie oben angedeutet, behandeln die Server-Stubs 56 eingehende Methodenaufrufe auf ein Objekt und rufen die spezifizierte Methode zum Durchführen der Operation auf. Wie ebenso oben angezeigt, führen die Server-Subcontracts 58 Daten-Zusammentellung und andere Operationen durch, um den Transport von Methodenaufrufen und den resultierenden Rückmeldungen zwischen dem Server 24 und den Client-Computern 22 zu unterstützen.
Die Operationen der Vorrichtung von Fig. 1 werden ausführlicher erläutert mit Bezug zu Fig. 2. Fig. 2 zeigt den Client-Computer 22A, den Übertragungskanal 23 und den Server 24 von Fig. 1. Wie oben angedeutet, ruft eine Client-Anwendung 34 durch Benutzung eines Fernprozeduraufrufs eine spezifizierte Methode eines Objektes an einem anderen Adressraum auf. Der Fernprozeduraufruf wird durch die Client-Stubs 38 an den Client- Subcontract 40 übergeben, der den Fernprozeduraufruf zum Transport auf den Übertragungskanal 23 verpackt. Der Server-Subcontract 58 des Servers 24 empfängt die Information und packt sie aus. Der Server-Subcontract 58 überträgt dann die Information an die Server-Stubs 56. Die Server-Stubs 56 greifen auf die Server-Anwendungsprogramme 54 zu, die die zuvor beschriebenen Objektmethoden sind. Insbesondere macht ein spezifizierter Server-Stub 56 einen Prozeduraufruf, um eine spezifizierte Methode des aufgerufenen Objekts auszuführen. Die Ausführung der Methode produziert einen Satz Resultate, hierin Antwort genannt, der dann zu dem Server- Subcontract 58 zurückgegeben wird, und der Kommunikationspfad wird umgedreht, wie durch die Pfeile von Fig. 2 angedeutet wird.
Block 70 von Fig. 2 zeigt die Komponenten, die einem Objektanforderungs- Broker (ORB) der Erfindung zugeordnet sind. Wie oben angedeutet, werden eine große Vielzahl von Kommunikationsprotokollen für ORBs benutzt. Die Benutzung von verschiedenen Protokollen für verschiedene ORBs führt zu Schwierigkeiten, wenn ein Server versucht, eingehende Objektanforderungen zu erkennen.
Die generelle Architektur und Bearbeitung, die der Ausführung zugeordnet ist, ist nun offenbart worden. Die Aufmerksamkeit wird nun auf eine detailliertere Betrachtung der Architektur der Ausführung, der Bearbeitung der Ausführung, der Unterscheidung zwischen diesen Elementen und entsprechenden Elementen gemäß dem Stand der Technik, und der Vorteile, die der offenbarten Technologie zugeordnet sind, gelenkt.
Wie in Fig. 2 gezeigt wird, benutzt ein Client-Subcontract 40 einen protokollabhängigen Methodenbeschreiber, um eine Methode, die einem aufgerufenen Objekt zugeordnet ist, anzufordern. Insbesondere benutzt der Client-Subcontract 40 einen Zusammenstellungs-Puffer, der einem gewählten On-the-Wire-Datenformat gehorcht. Um zum Beispiel eine gegebene Methode "X" zu identifizieren, könnte ein Protokoll einen Wert von "XXX" benutzen, ein anderes könnte einen Wert von "@@@::123::XXX" benutzen, und ein anderes könnte einen ganzzahligen Wert "123456" benutzen, wobei der Wert die Ausgabe einer Verschlüsselungs-(Hash-) Funktion auf den Methodennamen ist. Der Client-Stub 38 übergibt an den Client-Subcontract 40 eine Liste von protokollabhängigen Werten, aus denen der Client-Subcontract 40 den protokollabhängigen Methodenbeschreiber errechnet.
Daher muss ein Server 24, wenn ein Satz von Client-Computern 22A-22N mit dem Server 24 verbunden ist, jedes Protokoll bearbeiten.
Unterschiedliche Server-Subcontracts 58 (nicht gezeigt) sind notwendig, um jedes dieser Protokolle zu beherbergen. Gemäß dem Stand der Technik hat jeder Server-Subcontract 58 einen Satz von entsprechenden Server-Stubs 56. Daher sollte ein Server 24, um ORBs mit einer Mehrzahl von Protokollen zu unterstützen, verschiedene Server-Stubs 56 für jedes Protokoll haben, was zu einem großen Satz Server-Stubs 56 führt. Folglich kann leicht eingesehen werden, dass die Benutzung von verschiedenen ORB- Protokollen zu unhandlichen Erfordernissen für den Server 24 führen kann.
Wenn der Server-Subcontract 58 einen eingehenden Methodenaufruf empfängt, zieht er er gemäß der vorliegenden Erfindung den Methodenbeschreiber in einer Weise auseinander, die für das Protokoll des Subcontracts spezifisch ist. Er versucht dann, den Methodenbeschreiber an jeden der Einträge in einer Liste von protokollabhängigen Werten anzupassen. Protokollabhängige Werte können Zeichen-Sequenzen, nummerische Werte, ebenso wie andere Arten von Parameterwerten sein. Verschiedene Protokolle können verschiedene Anpassungsfunktionen benutzen, um den Methodenbeschreiber mit der Liste protokollabhängiger Werte zu vergleichen. Die Anpassungsfunktion kann ein String-Vergleich, eine Verschlüsselungs-Funktion oder andere Technik, die durch den Server- Subcontract 58 spezifiziert wird, sein. Wenn ein passender protokollabhängiger Wert identifiziert wird, kann der Server-Subcontract 58 ihm einen Indexwert zuordnen.
Wie in Fig. 2 gezeigt, wird der Indexwert an protokollunabhängige Server- Stubs 56 übergeben, die den der Methode entsprechenden Indexwert aufrufen. Auf diese Weise werden die Protokollabhängigkeiten der individuellen Objektreferenzen von den protokollunabhängigen Server-Stubs 56 isoliert. Folglich können protokollunabhängige Server-Stubs 56 mit jeder Art von Objektanforderungs-Broker 70 benutzt werden. Weiterhin kann ein einziger Compiler benutzt werden, um die protokollunabhängigen Server- Stubs 56 zu erzeugen.
Daher stellt die vorliegende Ausführung im Gegensatz zum Stand der Technik einen Server 24 zur Verfügung, der eine Vielzahl von ORB- Protokollen erkennt. Weiterhin führt er diese Funktion in einer hocheffektiven Weise durch Benutzen eines einzigen Satzes protokollunabhängiger Server- Stubs 56 durch. Man beachte, dass, um diese Technik zu unterstützen, die Zusammenstellungs- und Auseinanderziehungs-Operationen, die allgemein durch Stubs gemäß dem Stand der Technik angewandt werden, durch den Client-Subcontract 40 und den Server-Subcontract 58 der Erfindung durchgeführt werden. Diese Übertragung des Bearbeitens und die Benutzung eines Indexwertes, um protokollunabhängige Server-Stubs zur Verfügung zu stellen, stellen Unterschiede zwischen dem Stand der Technik und einer Ausführung der vorliegenden Erfindung dar. Daher kann diese Ausführung der vorliegenden Erfindung erfolgreich in existierende Architekturen und Prozesse implementiert werden, sobald diesen Bearbeitungsunterschieden Rechnung getragen wird.
Fig. 3 zeigt eine ausführliche Illustration der in den vorangehenden Abschnitten beschriebenen Bearbeitungsschritte. Der erste Bearbeitungsschritt in Fig. 3 ist, dass der Server-Subcontract einen Methodenbeschreiber in einem Methodenaufruf (Block 80) identifiziert. Wie oben angedeutet, produziert der Client-Computer einen Methodenaufruf, der letztendlich in einen Zusammentstellungs-Puffer als ein Satz von Informationen verpackt wird. Der Inhalt der Information ist von dem Client- Subcontract abhängig, der die Information zusammengestellt hat. Der entsprechende Subcontract auf dem Server zieht die Information auseinander und erkennt innerhalb der Information den Methodenbeschreiber.
Der nächste Bearbeitungsschritt ist, dass der Server-Subcontract einen protokollabhängigen Wert auswählt, der mit dem Methodenbeschreiber (Block 82) zusammenpasst. Diese Operation kann mit Bezug zu Fig. 4 illustriert werden. Fig. 4 zeigt eine Beschreiber_Liste protokollabhängiger Werte. Diese Liste enthält N Unterlisten. Jede Unterliste identifiziert einen Satz protokollabhängiger Werte, die benutzt werden können, um eine einzelne Methode zu identifizieren. Jede Unterliste hat j Einträge. In Fig. 4 sind diese Einträge als Beschreiber_Liste_1_1 bis Beschreiber_Liste_1_j gezeigt. Die Beschreiber_Liste_1_1 in Fig. 4 ist einer Interface-Definition- Language (IDL)-Kurzbezeichnung zugeordnet. IDL ist ein in der Technik benutzter Standard. Das bedeutet, dass ein Eintrag in der Liste der IDL- Kurzname für die aufgerufene Methode ist. Der IDL-Kurzname ist ein ORB- Protokollname, der in der Technik benutzt wird. Die gleiche Liste zeigt, dass Beschreiber_Liste_1_2 einem IDL-Langnamen zugeordnet ist. Das bedeutet, dass dieser Eintrag in der Liste der IDL-Langname für die aufgerufene Methode ist. Der IDL-Langname ist ein anderer ORB-Protokollname, der in der Technik benutzt wird. Der dritte Eintrag in der Unterliste ist Beschreiber_Liste_1_3, der eine Lager-ID hat. Die Lager-ID ist ein Name, der in einem anderen ORB-Protokoll in der Technik benutzt wird. Beispiele dieser verschiedenen Protokolle beinhalten die folgenden Aussagen:
die benutzt werden, um die Operation:
nehme_schwachen_Komparator
aufzurufen.
Wie in Fig. 4 angedeutet, können auch alternative Bezeichnungen in der Liste protokollabhängiger Werte verwendet werden. Weiterhin brauchen die hier als Beispiel gezeigten Bezeichnungen nicht verwendet werden. Jedenfalls ist es durch Benutzen des durch den IDL-Standard oder anderer Industriestandards und Praktiken eingeführten Formates möglich, die Weise vorherzusagen, in der die meisten Methodenbeschreiber durch ein vernünftiges Protokoll realisiert werden.
Der folgende Pseudokode wird als einfaches Beispiel benutzt, um zu zeigen, wie die Beschreiberliste durchsucht werden kann.
Die Zeilen (1) und (2) sorgen für Initialisierung. Zeile (3) ist der Eingang in eine Bearbeitungsschleife. Zeile (4) sorgt für Initialisierung innerhalb der Bearbeitungsschleife. Zeile (5) testet eine Bedingung. Der Kode testet nämlich, ob der auseinandergezogene "Methoden_Beschreiber" des Methodenaufrufs mit dem "j-ten" Eintrag der "i-ten" Unterliste (Beschreiber_Liste_i_j) der protokollabhängigen Liste zusammenpasst. Der "j-te" Eintrag, zum Beispiel der IDL-Kurzname, ist von dem Server- Subcontract 58 her als derjenige bekannt, mit dem für dieses Protokoll verglichen werden muss. Der "i-te" Wert ist ein inkrementierter Wert, der es erlaubt, jede Beschreiberliste eines Untersatzes (Beschreiber_Liste_1 bis Beschreiber_Liste_N) zu testen. Der Ausdruck "Anpassen_p" bezieht sich auf die Anpassungsfunktion, die benutzt wird, um den Methoden_Beschreiber mit dem Listeneintrag zu vergleichen. Zum Beispiel könnte "Anpassen_p" einen einfachen String-Vergleich zwischen Werten spezifizieren oder es könnte den Vergleich von Verschlüsselungs-Werten spezifizieren. Die Definition von "Anpassen_p" wird durch den Server- Subcontract 58 zur Verfügung gestellt.
Wenn die Bedingung zutrifft, wird eine Übereinstimmung gefunden, andernfalls wird auf das nächste "i" in der Unterliste zugegriffen. Wenn eine Übereinstimmung gefunden wird, sorgt Zeile (8) für einen Aufruf an eine Operationstabelle der Server-Stubs (56). Man beachte, dass der Wert "i" der Wert ist, der, wenn ein Treffer gefunden wird, an die Server-Stubs übergeben wird. Dieser Wert entspricht einem Untersatz der durchsuchten Liste, und dieser Untersatz ist einer einzigen Methode zugeordnet, die aufgerufen worden ist. Daher veranschaulicht der Kode in Zeile (8) den nächsten Bearbeitungsschritt von Fig. 3, nämlich dass der Server- Subcontract einen Indexwert an die Server-Stubs (Block 86) übergibt.
Sobald die Server-Stubs den Indexwert empfangen, stützen sie sich auf eine Operationstabelle 100, die in Fig. 4 gezeigt ist, um die durch den Indexwert spezifizierte Methode aufzurufen. Die Operationstabelle wird bevorzugt als Falltabelle implementiert, die einen Satz von jedem Fallwert "i" zugeordneten Bearbeitungsschritten aufweist. Wenn der Wert "i" empfangen wird, wird die durch den Wert spezifizierte Methode ausgeführt (Block 88). Fig. 4 zeigt einen einfachen Satz von Bearbeitungsschritten, um dieses Ergebnis zu erreichen. Der erste Schritt ist, die Methode i auszuführen, und der zweite Schritt ist, alle resultierenden Nachrichten (die Antworten) in den Zusammenstell-Puffer zu laden. Der letzte, in Fig. 3 gezeigte Bearbeitungsschritt dient dazu, dass die Server-Stubs die von der Ausführung der Methode erzeugten Antworten an die Server-Subcontracts (Block 90) übergeben.
Fig. 5 zeigt, dass die Ausführung die Methodenaufrufen zugeordneten Ausnahmen unterstützt. In den oben diskutierten Systemen gemäß dem Stand der Technik wird der einer Methode zugeordnete Ausnahmekode geladen, bevor die Methode aufgerufen wird. Wenn zum Beispiel eine Methode in einem System gemäß dem Stand der Technik aufgerufen wird, lädt der Client-Computer 22A den Kode für alle dem Methodenaufruf zugeordneten Ausnahmen, bevor er einen RPC zum Ausführen der Methode erzeugt.
Insbesondere gibt es für jede mögliche Ausnahmebedingung eine entsprechende Objektklasse. Wenn die Objektklasse einer Ausnahme instanziiert wird, wird eine Objektinstanz, die eine Methode (d. h. ein ausführbares Programm) zum Antworten auf oder andernfalls Bearbeiten der entsprechenden Ausnahme enthält, erzeugt. Daher müssen in Systemen gemäß dem Stand der Technik, wenn ein Client-Anwendungsprogramm einen RPC initialisiert, um eine Objektmethode aufzurufen, im Falle, dass der RPC sich auf eine lange Liste von Ausnahmeobjektklassen bezieht, alle diese Ausnahmeobjektklassen in dem Adressraum des Client- Anwendungsprogramms 34 instanziiert werden, bevor der Client-Subcontract 40 überhaupt den Methodenaufruf an den Server-Computer 24 übertragen kann.
Während die Ausnahmeinformation für einige dieser Ausnahmen (d. h. Instanzen einiger der Ausnahmeobjektklassen) auf dem Client-Computer 22 zur Verfügung stehen können, werden in den meisten Fällen wenigstens einiger dieser Ausnahmeobjektklassen auf dem Client-Computer 22 nicht vorgehalten. Für diese Ausnahmen, die keine entsprechenden Ausnahmeprozeduren (d. h. Ausnahmekode) auf dem Client-Computer 22 haben, muss der Client-Computer 22 Ausnahmeprozeduren von entfernten Computern, wie dem in Fig. 1 gezeigten Server 24N, abrufen. Weiterhin wird typischerweise eine separate Kommunikationssitzung benötigt, um jede Ausnahmeprozedur (d. h. Ausnahmekode) zu erhalten. Konsequenterweise kann der Prozess des Sammelns von Ausnahmekode relativ zeitaufwändig sein. Dieser Bearbeitungsnachteil ist deswegen besonders unglücklich, weil in den meisten Fällen der Ausnahmekode auf dem Client-Computer 22 nicht benötigt wird.
In der vorliegenden Ausführung bezieht sich ein Methodenaufruf nicht auf jede dem Methodenaufruf zugeordnete Ausnahme. Konsequenterweise werden verschiedene Ausnahmen anfänglich nicht geladen. Sie werden nur geladen, wenn eine Ausnahme geliefert wird. Daher wird mit der vorliegenden Ausführung anfänglich nur der Methodenaufruf bearbeitet, was zu schnellerer Leistungsfähigkeit führt. Die verbesserte Leistungsfähigkeit steht nur in dem relativ seltenen Ereignis, dass eine Ausnahme bearbeitet wird, nicht zur Verfügung.
Wie in Fig. 5 gezeigt, hat jede identifizierte Methode, zum Beispiel die Beschreiber_Liste_i zugeordnete Methode, einen verbundenen Ausnahmebeschreiber. Der Ausnahmebeschreiber ist ein Zeiger. Legt man z. B. das "nehme_schwachen_Komparator"-Beispiel von oben zu Grunde ist der Ausnahmebeschreiber zum Beispiel
_nehme_schwachen_KomparatorAusnahmeBeschreiberInstanz.
Der Ausnahmebeschreiber zeigt auf eine Ausnahmeliste, die M Ausnahme- Unterlisten enthält. Fig. 5 zeigt Ausnahme_Liste_x. Jede Unterliste spezifiziert eine der Ausnahmen für den Methodenaufruf, beinhaltend den IDL-Kurznamen, IDL-Langnamen, eine Lageridentifikation und jede alternative Identifizierung für die Ausnahme. Jede Ausnahmeliste enthält auch einen Ausnahmeobjekt-Identifizierer, der zum Lokalisieren von Ausnahmekode bei Laufzeit benutzt wird.
Das in dieser Ausführung der Erfindung benutzte Ausnahmebeschreiber- Konzept ist in Fig. 4 gezeigt. Man beachte, dass der letzte Eintrag in der Unterbeschreiberliste "Beschreiber_Liste_1" ein Ausnahmebeschreiber ist, der auf eine Ausnahmeliste zeigt. Die Antwort, die von dem Server- Computer beim Ausführen einer Methode erzeugt wird, kann jeden der Einträge innerhalb der Ausnahmeliste, z. B. die Ausnahme Liste_1, Ausnahme_Liste_3 oder Ausnahme_Liste_M zugeordneten Ausnahmen, enthalten. Ein spezifizierter Server-Subcontract 58 benutzt sein zugeordnetes Protokoll, um die Ausnahmen zu übertragen. Der Client- Computer 22 empfängt dann die Ausnahmen von dem Server-Computer 24.
Gemäß der vorliegenden Ausführung speichert der Client-Subcontract 40 eine Kopie der mit einem Ausnahmebeschreiber zugeordneten Ausnahmeliste. Daher kann der Client-Computer 22, wenn die Ausnahmen von dem Server-Computer 24 empfangen worden sind, diese an Ausnahmen in der Ausnahmeliste anpassen, wobei die zuvor veröffentlichte Technik bezüglich der Identifizierung von Methoden benutzt wird.
Die Ausnahme wird dann durch Zugrundelegen eines Ausnahmeobjekt- Identifizierers bearbeitet, der zum Abrufendes der Ausnahme zugeordneten Ausnahmekodes benutzt wird. Man beachte in Fig. 5, dass Ausnahme_Liste_x, wie alle anderen Ausnahmeunterlisten, einen Ausnahmeobjekt-Identifizierer (Ausnahmeobjekt ID) enthält, der ein String- Name ist, der die Objektklasse zur Behandlung der Ausnahme spezifiziert. Der Kode für die Objektklasse kann in einem lokalen Objektlager 104 sein. Falls das Objekt nicht in dem lokalen Objektlager 104 vorgehalten wird, instanziiert das Betriebssystem 42 das Objekt in das lokale Objektlager 104 durch Herunterladen von Kode von einem anderen Computer in dem Netzwerk, zum Beispiel Server 24N in Fig. 1. Daher bezieht sich das entfernte Objektlager 106 von Fig. 5 allgemein auf jeden Computer, der aufgerufen wird, einen Kode für ein Objekt zur Verfügung zu stellen. Der Kode wird dann in das lokale Objektlager 104 geleitet. Der Prozess des Kodeeinholens von dem lokalen Objektlager 104 und dem entfernten Objektlager 106 ist Ansätzen gemäß dem Stand der Technik ähnlich, aber bei der vorliegenden Erfindung wird die Operation ausgeführt, nachdem eine Ausnahme zurückgegeben worden ist, anstatt dann, wenn die Methodenbeschreiber konstruiert werden.
Die vorangehende Offenbarung einer Ausführung der Erfindung wird mit Bezug zu Fig. 6 zusammengefasst. Der erste dem Prozess von Fig. 6 zugeordnete Schritt ist, einen Methodenaufruf auf einem Client-Computer 22 (Block 110) zu erzeugen. Wie oben angedeutet, instanziiert der Methodenaufruf der Ausführung nicht eine Objektklasse einer Ausnahme. Daher wird der Methodenaufruf ohne Instanziierung von Ausnahmeobjekten behandelt.
Der nächste Bearbeitungsschritt ist, den Methodenaufruf auf dem Server- Computer 24 (Block 112) zu bearbeiten. Wie oben angedeutet, führt der Versuch, den Methodenaufruf zu bearbeiten, dazu, dass der Server- Computer 24 eine Ausnahme identifiziert. Die Ausnahme wird dann an den Client-Computer 22 (Block 114) übergeben.
Wenn der Client-Computer 22 die Ausnahme empfängt, versucht er, sie an die Ausnahmen in der auf ihm gespeicherten Ausnahmeliste (Block 116) anzupassen. Jeder Untersatz der Ausnahmeliste (z. B. Ausnahme_Liste_M) ist einer einzigen Ausnahme zugeordnet, und jeder Untersatz hat einen entsprechenden Ausnahmeobjekt-Identifizierer (Ausnahme_Objekt_ID, wie in Fig. 4 gezeigt). Der Ausnahmeobjekt-Identifizierer wird zum Laden von Ausnahmekode in den Client-Computer (Block 118) benutzt. Schließlich bearbeitet der Client-Computer den Ausnahmekode, um auf die von dem Methodenaufruf (Block 120) erzeugte Ausnahme zu antworten.
Das Vorangegangene im Auge behaltend, sind die Vorteile der vorliegenden Ausführung offensichtlich. Gemäß der Ausführung funktionieren Client- Computer 22 viel schneller, weil sie weniger Information laden, wenn eine Methode aufgerufen wird. Insbesondere laden sie nur den Kode, der zur Bearbeitung des Methodenaufrufs benötigt wird. In dem relativ ungewöhnlichen Fall, dass der Methodenaufruf nicht erfolgreich ist, wird der mit der Methode verbundene Ausnahmekode schnell geladen.

Claims

1. Verfahren zur Behandlung von Methodenaufrufen in einem Client/Server-Computersystem, wobei das Verfahren die Schritte umfasst:

Anpassen einer von einem Server-Computer (24) erzeugten Ausnahme an Ausnahmen in einer Ausnahmeliste, die auf dem Client- Computer (22) gespeichert ist, um einen Ausnahme-Objektbezeichner zu erhalten;

Laden von Ausnahmekode in den Client-Computer entsprechend dem Ausnahme-Objektbezeichner; und

Ausführen des Ausnahmekodes auf dem Client-Computer, um auf die Ausnahme des Methodenaufrufs zu antworten.

2. Verfahren nach Anspruch 1, das ferner die folgenden Schritte umfasst, die vor dem Anpassungsschritt ausgeführt werden:

Empfangen eines von einem Client-Computer erzeugten Methodenaufrufs auf einem Server-Computer;

Versuchen, den Methodenaufruf auf dem Server-Computer auszuführen;

Erzeugen einer Ausnahme zu dem Methodenaufruf in Antwort auf den Versuchsschritt; und

Übergeben der Ausnahme an den Client-Computer, um den Anpassungsschritt auszuführen.

3. Verfahren nach Anspruch 2, wobei der Übergabeschritt den Schritt enthält, eine Ausnahme in einem protokollabhängigen Format zu übergeben.

4. Verfahren nach Anspruch 2, wobei der Anpassungsschritt den Schritt enthält, eine Ausnahmeliste mit einer Mehrzahl von Unterlisten zu benützen, wobei jede Unterliste einer spezifizierten Ausnahme entspricht und einen Satz von verschiedenen protokollabhängigen Aussagen entsprechenden Einträgen enthält, die zur Charakterisierung der spezifizierten Ausnahme benutzt werden.

5. Verfahren nach Anspruch 2, wobei der Ladeschritt den Schritt enthält, den Ausnahmekode von einem anderen Computer als dem Client- Computer zu laden, wenn der Ausnahmekode auf dem Client-Computer nicht vorgehalten wird.

6. Verfahren nach Anspruch 2, das ferner die Schritte umfasst:

Lokalisieren eines in einem protokollabhängigen Format spezifizierten Methodenbeschreibers innerhalb des Methodenaufrufs;

Zuweisen eines Indexwertes auf das Anpassen des

Methodenbescheibers an eine ausgewählte protokollabhängige Aussage in einer Liste protokollabhängiger Aussagen; und

Übergeben des Indexwertes an ein protokollunabhängiges Ausführungsmodul des Server-Computers, wobei der Computer-Server basierend auf dem Indexwert eine Antwort an den Client-Computer zurückgibt.

7. Computer-lesbarer Speicher, der dazu benutzt werden kann, auf ein Client/Server-System so einzuwirken, dass es in einer spezifizierten Weise funktioniert, der umfasst:

Methoden-Ausnahmeinformation, die in dem Speicher gespeichert ist, wobei die Methoden-Ausnahmeinformation eine Ausnahmeliste enthält, die einen Satz von Ausnahmen spezifiziert; und ausführbare Anweisungen, die in dem Speicher gespeichert sind, wobei die ausführbaren Anweisungen enthalten:

Anweisungen zum Erzeugen einer Ausnahme auf einem Server- Computer (24) eines Client/Server-Systems in Antwort auf einen Methodenaufruf von einem Client-Computer des Client/Server-Systems;

Anweisungen zum Übergeben der Ausnahme von dem Server- Computer zu dem Client-Computer (22);

Anweisungen zum Anpassen der Ausnahme an Ausnahmen in der Ausnahmeliste auf dem Client-Computer, um einen Ausnahme- Objektbezeichner zu bilden;

Anweisungen zum Laden von Ausnahmekode in den Client- Computer entsprechend dem Ausnahme-Objektbezeichner; und

Anweisungen zum Ausführen des Ausnahmekodes auf dem Client-Computer, um auf die Ausnahme des Methodenaufrufs zu antworten.

8. Computer-lesbarer Speicher nach Anspruch 7, wobei die Anweisungen zum Übergeben der Ausnahme von dem Server-Computer zu dem Client Computer Anweisungen zum Übergeben der Ausnahme in einem protokollabhängigen Format enthalten.

9. Computer-lesbarer Speicher nach Anspruch 7, wobei die Anweisungen zum Anpassen der Ausnahme an Ausnahmen in der Ausnahmeliste Anweisungen enthalten, eine Ausnahmeliste mit einer Mehrzahl von Unterlisten zu benutzen, wobei jede der Unterlisten einer spezifizierten Ausnahme entspricht und einen Satz von verschiedenen protokollabhängigen Aussagen entsprechenden Einträgen enthält, die zur Charakterisierung der spezifizierten Ausnahme benutzt werden.

10. Computer-lesbarer Speicher von Anspruch 7, wobei die Anweisungen zum Laden von Ausnahmekode in den Client-Computer entsprechend dem Ausnahme-Objektbezeichner Anweisungen zum Laden des Ausnahmekodes von einem anderen Computer als dem Client-Computer enthalten, wenn der Ausnahmekode auf dem Client Computer nicht vorgehalten wird.

11. Computer-lesbarer Speicher nach Anspruch 7, der ferner umfasst:

Anweisungen zum Lokalisieren eines in einem protokollabhängigen Format spezifizierten Methodenbeschreibers innerhalb des Methodenaufrufs;

Anweisungen zum Zuweisen eines Indexwertes aud das Anpassen des Methodenbescheibers an eine ausgewählte protokollabhängige Aussage in einer Liste protokollabhängiger Aussagen; und

Anweisungen zum Übergeben des Indexwertes an ein protokollunabhängiges Ausführungsmodul des Server-Computers, wobei der Computer-Server basierend auf dem Indexwert eine Antwort an den Client-Computer zurückgibt.