DE69734175T2 - Transportunabhängige Anruf- und Dienstschnittstellen, die die Marshalling von integrierten Type-Codes sowie kompilierten Code erlauben - Google Patents

Transportunabhängige Anruf- und Dienstschnittstellen, die die Marshalling von integrierten Type-Codes sowie kompilierten Code erlauben Download PDF

Info

Publication number
DE69734175T2
DE69734175T2 DE69734175T DE69734175T DE69734175T2 DE 69734175 T2 DE69734175 T2 DE 69734175T2 DE 69734175 T DE69734175 T DE 69734175T DE 69734175 T DE69734175 T DE 69734175T DE 69734175 T2 DE69734175 T2 DE 69734175T2
Authority
DE
Germany
Prior art keywords
call
argument
descriptor
request
code
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE69734175T
Other languages
English (en)
Other versions
DE69734175D1 (de
Inventor
Swee Boon Mountain View Lim
Peter B. Palo Alto Kessler
David M. Palo Alto Brownell
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Publication of DE69734175D1 publication Critical patent/DE69734175D1/de
Application granted granted Critical
Publication of DE69734175T2 publication Critical patent/DE69734175T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • G06F9/548—Object oriented; Remote method invocation [RMI]

Description

  • HINTERGRUND DER ERFINDUNG
  • 1. Gebiet der Erfindung
  • Die vorliegende Erfindung bezieht sich auf die Gebiete von verteilten Berechnungssystemen, Client-Server-Berechnung und objektorientierter Programmierung. Genauer bezieht sich die Erfindung auf Datenstrukturen, Verfahren und Einrichtungen zum Erleichtern von Servantaufruf (Bedienaufruf).
  • 2. Beschreibung des Standes der Technik
  • Eine Berechnungsumgebung, in der Objekte, die sich auf unterschiedlichen Computern befinden, durch ein Netz verknüpft sind, wird typischerweise als eine Client-Server-Berechnungsumgebung bezeichnet. Einige der Computer agieren als Anbieter von Diensten oder Funktionalität für andere Computer. Andere der Computer agieren als Kunden von Diensten oder Funktionalitäten. Die Anbieter eines Dienstes oder einer Funktionalität sind als "Server" bekannt, und die Kunden des Dienstes oder der Funktionalität werden "Clients" genannt. Das Client-Server-Modell kann auch auf den Fall verallgemeinert werden, wo verschiedene Programme, die auf dem gleichen Computer laufen, miteinander durch irgendeinen geschützten Mechanismus kommunizieren und als Anbieter und Kunden von Diensten oder Funktionalität agieren.
  • Versuche, ein derartiges verteiltes System vorzusehen, wurden unter Verwendung objektorientierter Methodiken unternommen, die auf einem Client-Server-Modell basieren, worin Server-Objekte Schnittstellen für Client-Objekte vorsehen, die Anforderungen der Server-Objekte durchführen. Typischerweise sind in einem derartigen verteilten System die Server Objekte, die aus Daten und zugehörigen Methoden bestehen. Die Client-Objekte erhalten Zugang zu den Funktionalitäten der Server-Objekte durch Ausführen von Rufen in ihnen, wobei die Rufe durch das verteilte System vermittelt werden. Wenn das Server-Objekt einen Ruf empfängt, führt es die geeignete Methode aus und überträgt das Ergebnis zurück zu dem Client-Objekt. Das Client-Objekt und das Server-Objekt kommunizieren durch einen Objektanforderungsvermittler (ORB, Object Request Broker), der verwendet wird, die verschiedenen verteilten Objekte zu lokalisieren und Kommunikationen zwischen Objekten herzustellen. Verteilte Objekte können irgendwo in einem Netz existieren, wie z.B. in dem Adressraum des Client, in vielen Adressräumen auf der Client-Maschine und in vielen Maschinen quer durch das Netz.
  • Die Softwareindustrie hat auf den Bedarf nach Technologie verteilter Objekte durch Bildung der Object Management Group (OMG) geantwortet. Das Ziel der OMG besteht darin, die Objektmanagementarchitektur (OMA) zu definieren, die vier wesentliche Komponenten hat: den Objektanforderungsvermittler (ORB), Objekt-Dienste, gemeinsame Einrichtungen und Anwendungsobjekte. Der Objektanforderungsvermittler sieht grundlegende Objektkommunikationen und Managementdienste vor, wobei dadurch die Basis eines verteilten Objektsystems gebildet wird. Ein Standard für einen Objektanforderungsvermittler ist in der Spezifikation Common Object Request Broker Architecture (CORBA, gemeinsame Objektanforderungsvermittler-Architektur) von der OMG, Revision 2.0, datiert Juli 1995 enthalten.
  • In typischen Client-Server-Systemen kann Overhead von Leistungsverhalten teuer sein. D.h. die Geschwindigkeit und Qualität eines Prozesses innerhalb des Systems können durch ineffiziente Verwendungen von Anwendungscode und Methoden, die mit Übertragung von Information zwischen verteilten Objekten in Verbindung stehen, kompromittiert werden. Als ein Beispiel ist der Overhead von Leistungsverhalten, der mit wiederholtem Extrahieren von Information in Verbindung steht, aus Puffern oder Abschnitten von Code, jedes Mal, wenn diese Information durch das Client-Server-System angefordert wird, hoch. Ferner wird durch einen Fachmann erkannt, dass Client-Server-Systeme typischerweise getrennte Schnittstellen für kompilierten Aufruf und nicht-kompilierten Aufruf verwenden. Die Verwendung von getrennten Schnittstellen ist ineffizient. Folglich wären die Bereitstellungen von Methoden, Datenstrukturen und/oder Einrichtungen wünschenswert, die den Overhead vom Leistungsverhalten reduzieren, der mit Kommunizieren von Information zwischen verteilten Objekten in Verbindung steht. Ferner würde die Bereitstellung eines Mechanismus, der einen gemeinsam genutzten Basiscode zwischen kompiliertem Aufruf und nicht-kompiliertem Aufruf ermöglichen würde, das verbesserte Leisungsverhalten eines Client-Server-Systems vorsehen.
  • EP-A-0643349 beschreibt Methoden und Vorrichtung zum Aufrufen entfernt verteilter Objekte, was den Speicherraum reduziert, der durch clientseitige Stubs (Stümpfe) gefordert wird. Es werden unterschiedliche Stubs für jede verschiedene Schnittstelle vorgesehen, die durch die Anwendungen unterstützt wird. Es wird ein Verfahren zum Ausführen einer bestimmten Stub-Operation beschrieben, die durch einen Client in einem Computersystem aufgerufen wird, durch Zugreifen von einem ersten Bereich eines Computerspeichers auf einen ersten Abschnitt von Code, der erforderlich ist, um die Stub-Operation auszuführen. Dieser erste Abschnitt von Code wird als Code identifiziert, der für eine Vielzahl von unterschiedlichen Stub-Methoden gemeinsam ist. Auf einen zweiten Abschnitt vom Computerspeicher wird für einen zweiten Abschnitt von Code zugegriffen, der für die aufgerufene bestimmte Stub-Operation eindeutig ist. Dies gestattet eine Verringerung in dem erforderlichen Computerspeicher, da der Code, der für eine Vielzahl von Stub-Methoden gemeinsam ist, nur einmal gespeichert wird. Es wird ein zweites Verfahren zum Trennen von Code, der zum Ausführen einer Stub-Operation generiert wird, in einen ersten Abschnitt von Code, der für eine Vielzahl von Stub-Methoden gemeinsam ist, und einen zweiten Abschnitt von Code, der für jede Stub-Operation eindeutig ist, beschrieben. Der zweite Abschnitt von Code wird in einen Computerspeicher in einem komprimierten Format gespeichert. Es wird ein Stub-Generator verwendet, um eine Datenbank von komprimierten clientseitigen Stub-Beschreibungsdateien zu generieren, die im Computerspeicher gespeichert werden, und ein Stub-Interpreter, der weiß, wie diese clientseitigen Stub-Beschreibungsdateien zu lesen sind.
  • Um die vorangehenden und andere Ziele zu erreichen, und in Übereinstimmung mit dem Zweck der vorliegenden Erfindung, werden Datenstrukturen, Methoden und Einrichtungen zum Erleichtern von Servantaufruf in einem verteilten Client-Server-basierten objektorientierten Betriebssystem offenbart. In einem Aspekt sieht die Erfindung ein Verfahren zum Rufen eines entfernt angeordneten Objektes in einem verteilten Client-Server-basierten Berechnungssystem vor, wobei das Verfahren die Schritte umfasst: Empfangen einer Anforderung innerhalb eines Client-Prozesses; Auswählen eines Transports, der für die Anforderung geeignet ist, wobei der Transport verwendet wird, um die Anforderungen aufzustellen (marshal); Erstellen eines Aufstellungspuffers, der für den ausgewählten Transport geeignet ist, wobei der Aufstellungspuffer verwendet wird, um die Anforderungen zu kapseln; Aufstellen eines Argumentes unter Verwendung von Deskriptordatenstrukturen, unter Nutzung einer Aufstellungsmethode, wobei die Deskriptordatenstrukturen ein kompiliertes Flag inkludieren, das verwendet wird um anzuzeigen, ob die Aufstellungsmethode Typcode-interpretiert oder kompiliert ist; und Bestimmen, ob das kompilierte Flag gesetzt ist, wobei wenn bestimmt wird, dass das kompilierte Flag gesetzt ist, der Argumentaufstellungsschritt durch Aufrufen einer Aufstellungsmethode bewerkstelligt wird, die mit dem Argument in Verbindung steht, das mit der Anforderung in Verbindung steht; und wenn bestimmt wird, dass das kompilierte Flag nicht gesetzt ist, der Argumentaufstellungsschritt durch Aufrufen einer Typcode-Aufstellungsmethode bewerkstelligt wird, wobei das Argument zu der Typcode-Aufstellungsmethode weitergegeben wird.
  • In einem weiteren Aspekt sieht die Erfindung ein Computerprogrammprodukt vor, umfassend ein computerverwendbares Medium mit darin verkörpertem computerlesbaren Code zum Aufrufen einer Objektmethode, definiert in einem verteilten Server-Objekt innerhalb eines verteilten Objektberechnungssystems, das Computerprogrammprodukt umfassend computerlesbaren Programmcode zum Bewirken der folgenden Schritte innerhalb des Computersystems: Empfangen einer Anforderung innerhalb eines Client-Prozesses; Auswählen eines Transports, der für die Anforderung geeignet ist, wobei der Transport verwendet wird, die Anforderung aufzustellen; Erstellen eines Aufstellungspuffers, der für den ausgewählten Transport geeignet ist, wobei der Aufstellungspuffer verwendet wird, um die Anforderung zu kapseln; Aufstellen eines Argumentes unter Verwendung von Deskriptordatenstrukturen, unter Nutzung einer Aufstellungsmethode, die Deskriptordatenstrukturen inkludierend ein kompiliertes Flag, das verwendet wird um anzuzeigen, ob die Aufstellungsmethode Typcode-interpretiert oder kompiliert ist; und Bestimmen, ob das kompilierte Flag gesetzt ist, wobei wenn bestimmt wird, dass das kompilierte Flag gesetzt ist, der Argumentaufstellungsschritt durch Aufrufen einer Aufstel lungsmethode bewerkstelligt wird, die mit dem Argument in Verbindung steht, das mit der Anforderung in Verbindung steht; und wenn bestimmt wird, dass das kompilierte Flag nicht gesetzt ist, der Argumentaufstellungsschritt durch Aufrufen einer Typcode-Aufstellungsmethode bewerkstelligt wird, wobei das Argument zu der Typcode-Aufstellungsmethode weitergegeben wird.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die Erfindung, zusammen mit weiteren Vorteilen von ihr, kann am besten durch Bezug auf die folgende Beschreibung verstanden werden, aufgenommen in Verbindung mit den begleitenden Zeichnungen, in denen:
  • 1a ein symbolischer Überblick eines verteilten objektorientierten Systems ist;
  • 1b eine schematische Veranschaulichung ist, die darstellt, wie eine Anforderung durch einen Client durch die Architektur einer Clientseite und einer Serverseite eines verteilten objektorientierten Systems weitergeleitet werden kann, und der Schnittstelle zwischen der Clientseite und der Serverseite des verteilten objektorientierten Systems;
  • 2 eine schematische Darstellung einer Objektreferenz ist;
  • 3 eine schematische Darstellung eines Methodendeskriptors in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung ist;
  • 4 eine schematische Darstellung eines Aufrufdeskriptors in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung ist;
  • 5 eine schematische Darstellung eines Parameterdeskriptors in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung ist;
  • 6 eine schematische Darstellung eines Ausnahmedeskriptors (exception descriptor) in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung ist;
  • 7 eine Darstellung eines Rufes zu einer Aufrufmethode auf der Clientseite eines verteilten objektorientierten Systems in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung ist;
  • 8 ein Prozessflussdiagramm ist, das Schritte veranschaulicht, die mit einem Aufruf eines Objektes in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung involviert sind;
  • 9 ein Prozessflussdiagramm ist, das Schritte veranschaulicht, die mit einer Ausführung eines entfernten Stubs in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung involviert sind;
  • 10 ein Prozessflussdiagramm ist, das Schritte veranschaulicht, die mit einem entfernten Stub involviert sind, der die Aufrufmethode einer Client-Darstellung ruft, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung;
  • 11 ein Prozessflussdiagramm ist, das Schritte veranschaulicht, die mit Aufstellen von Argumenten involviert sind, unter Verwendung von Deskriptoren in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung;
  • 12A ein Prozessflussdiagramm ist, das Schritte veranschaulicht, die mit Abstellen (unmarshaling) von Argumenten unter Verwendung von Deskriptoren in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung involviert sind;
  • 12B ein Flussdiagramm ist, das Schritte veranschaulicht, die mit generischem Abstellen von Argumenten unter Verwendung von Deskriptoren in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung involviert sind;
  • 12C ein Prozessflussdiagramm ist, das Schritte veranschaulicht, die mit Rufen einer Benutzerausnahmeroutine in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung involviert sind;
  • 13A ein Prozessflussdiagramm ist, das Schritte veranschaulicht, die auf der Serverseite eines verteilten objektorientierten Systems auftreten, sobald eine Anforderung in einem bestimmten Empfangsendpunkt in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung empfangen wird;
  • 13B ein Prozessflussdiagramm ist, das Schritte veranschaulicht, die mit Ausführen einer typischen Abfertigungsroutine in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung involviert sind;
  • 14A eine schematische Darstellung eines Serveraufrufobjektes in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung ist;
  • 14B ein Prozessflussdiagramm ist, das Schritte veranschaulicht, die mit Aufbauen eines Serveraufrufobjektes in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung involviert sind;
  • 15 ein Prozessflussdiagramm ist, das Schritte veranschaulicht, die mit Aufrufen eines Skeletts, welches statisch ist, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung involviert sind;
  • 16 ein Prozessflussdiagramm ist, das Schritte veranschaulicht, die mit Aufrufen eines Skeletts in einer dynamischen Skelett-Schnittstelle in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung involviert sind;
  • 17 ein typisches Computersystem in Übereinstimmung mit der vorliegenden Erfindung veranschaulicht.
  • DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
  • Die vorliegende Erfindung richtet sich auf verteilte Objektsysteme und wird mit Bezug auf mehrere bevorzugte Ausführungsformen beschrieben, wie in den begleitenden Zeichnungen veranschaulicht. Die Erfindung kann innerhalb des Kontexts eines beliebigen geeigneten verteilten Objektsystems praktiziert werden, inkludierend jene, die unter CORBA oder einer beliebigen anderen geeigneten Spezifikation definiert sind. Zum Zweck der Veranschaulichung wird die vorliegende Erfindung jedoch hauptsächlich innerhalb des Kontexts eines Objektanforderungsvermittlers (ORB) beschrieben, implementiert unter der Corba-Spezifikation von der Object Management Group (OMG), Revision 2.0, datiert Juli 1995. 1a veranschaulicht schematisch die Gesamtarchitektur eines repräsentativen verteilten Objektsystems, das zum Implementieren der vorliegenden Erfindung geeignet ist. 1b veranschaulicht schematisch einige mögliche Flusspfade, denen eine Anforderung von einem Client zu einem Servantobjekt folgen kann, inner halb einer derartigen Struktur, die einen dreistufigen Abfertigungsmechanismus inkludiert. 2 zeigt eine Objektreferenz-Datenstruktur, die durch einen Client verwendet werden kann, um auf ein Servantobjekt zu verweisen.
  • Ein verteiltes Objektsystem 10 inkludiert typischerweise einen Objektanforderungsvermittler (ORB) 11, wie symbolisch in 1a veranschaulicht wird. ORB 11 sieht alle Standort- und Transportmechanismen und Einrichtungen vor, die notwendig sind, um einen Ruf von einem Client zu einem Servant (Zielobjekt) abzugeben und eine Antwort zu dem Client zurückzugeben, wie nachstehend mit Bezug auf 1b erörtert wird. Der Client und der Servant können sich in dem gleichen Prozess, in unterschiedlichen Prozessen auf der gleichen Maschine oder in vollständig unterschiedlichen Maschinen befinden. Für den Zweck dieser Erörterung kann Client 20 beliebiger Code sein, der eine Operation in einem verteilten Objekt aufruft, und kann somit die Form eines verteilten Objektes oder eines Prozesses annehmen oder nicht. Ein verteiltes Objekt kann eine breite Vielfalt von Darstellungen haben. Als ein Beispiel kann ein Objekt ein C++-Objekt sein, das durch einen Anwendungsentwickler bereitgestellt wurde. Alternativ kann eine Implementierung für ein Objekt innerhalb eines visuellen Anwendungsbuilders 15 entwickelt werden. Dieser visuelle Anwendungsbuilder erlaubt einem Entwickler, existierende Objekttypen aus einem Katalog visuell auszuwählen und die Dienste, die durch ein Objekt bereitgestellt werden, mit den Diensten, die durch ein anderes benötigt werden (Attribute, Argumente, Ergebnisse etc.) grafisch zu verbinden, um eine neue Implementierung für ein Objekt zu erstellen.
  • Es kann eine Objektentwicklungseinrichtung 16 verwendet werden, um die Erstellung und die Installation von verteilten Objekten zu vereinfachen. Sie wird verwendet, um Entwicklerobjekte in einem verteilten Objektcode "einzuhüllen" oder zu kapseln. Als solche kann Objektentwicklungseinrichtung 16 verwendet werden, um ein Entwicklerobjekt in eine ORB-Objektimplementierung 14 zu transformieren. In diesem Beispiel wird ORB-Objektimplementierung 14 als ein Server präsentiert, wie durch seinen Standort in dem Diagramm gezeigt. Ein Entwickler verwendet eine Schnittstellendefinitionssprache, um eine Schnittstelle für ein ORB-Objekt zu definieren, stellt eine Entwicklerobjektimplementierung bereit, die das Verhalten dieses Objektes implementiert, und verwendet dann die Objektentwicklungseinrichtung 16, um eine ORB-Objektimplementierung 14 zu erzeugen. Zur Laufzeit wird eine Instanz dieses ORB-Objektes (ein Servant-Objekt) erstellt, die diese ORB-Objektimplementierung 14 nutzen wird. Es sollte erkannt werden, dass die Objektentwicklungseinrichtung auch verwendet werden kann, um Objektes zu erstellen, die in irgendeinem Punkt die Rolle von Clients übernehmen.
  • Client 20 kommuniziert mit einem Servant über den Weg eines Stubs 21, einer Subkontraktschicht 36, möglicherweise eines Filters 40 und einer Transportschicht 38. Stub 21 inkludiert Surrogat (Ersatz) 22, eine Methodentabelle 24 und Stub-Funktionen 25. Client 20 kommuniziert anfangs mit Surrogat 22, das dem Client als das Serverobjekt erscheint. Alternativ kann Client 20 mit dem Serverobjekt durch eine dynamische Aufrufschnittstelle (DII, dynamic invocation interface) 26 anstatt von durch Surrogat 22, Methodentabelle 24 und Stub-Funktionen 25 direkt kommunizieren. Die dynamische Aufrufschnittstelle 26 wird verwendet, um Clients zu ermöglichen, dynamische Anforderungen aufzubauen. Eine Prozedur, durch die ein Client einen Ruf zu einem Servant unter Nutzung der obigen Schichten durchführen kann, wird nachstehend detaillierter mit Bezug auf 1b beschrieben.
  • Subkontraktschicht 36 sieht die Funktionalität vor, die durch ein Objekt gefordert wird, um Subkontrakte zu nutzen, um ver schiedene Dienste (oder Merkmale oder Objektmechanismen) zu implementieren, die durch einen bestimmten Subkontrakt benannt werden, wie detaillierter in der oben angeführten US-Patentanmeldung US-5787251 A, eingereicht am 7.11.1995, beschrieben wird. Ein Subkontrakt identifiziert eine Dienstgüte, die durch das verteilte Objektsystem bereitgestellt wird, was durch ein einzelnes Objekt genutzt werden kann. Z.B. kann ein Subkontrakt identifizieren, dass das Merkmal von Sicherheit für ein bestimmtes Objekt zu verwenden ist. Filter 40 kann, falls verwendet, eine Vielfalt von Aufgaben durchführen, wie etwa Komprimierung, Verschlüsselung, Verfolgung oder Debugging, die auf Kommunikationen zu und von einem Objekt anzuwenden sind.
  • Transportschicht 38 arbeitet, um Information zu und von einem Servant aufzustellen, abzustellen und physisch zu transportieren, der typischerweise nicht den gleichen Prozess wie ein Client gemeinsam nutzt.
  • Eine Standardimplementierungssuite 28 (oder Objektadapter) repräsentiert eine Menge von Subkontrakten, die mit ORB-Objekten 14 auf identischen Wegen interagieren, wie z.B. Objektschlüsselmanagement. Es sollte vermerkt werden, dass ein Subkontrakt zu vielen Implementierungssuiten gehören kann. Auch können Implementierungssuiten verschiedene Subkontrakte nutzen. Ein Skelett, das die Form von entweder einem statischen Skelett 32 oder einem dynamischen Skelett 30 annehmen kann, wird verwendet, um Anforderungen in ein Format zu transformieren, das durch ein Servant-Objekt 78 gefordert wird (wie nachstehend mit Bezug auf 1b detaillierter erläutert wird). Somit rufen Skelette 30 und 32 ein geeignetes Servant-Objekt 78. Das statische Skelett 32 wird verwendet, um schnittstellenspezifische Objektimplementierungen 14 zu rufen, während das dynamische Skelett 30 generisch verwendet wird, wenn schnittstellenspezifische Objekte nicht verfügbar sind.
  • Ein ORB-Dämon 46 ist verantwortlich sicherzustellen, dass Objektserver aktiv sind, wenn durch Clients aufgerufen. Eine Technik zum Starten von Objektservern wird in US-Patentanmeldung US-6349342 B offenbart. Das sichere Protokoll 42 ist ein sicheres Interoperabilitätsprotokoll, das das Internet-Inter-ORB-Protokoll sichert und hilft, Information durch Transportschicht 38 auf eine sichere Weise zu übertragen. Dies kann Integritätsschutz, Vertraulichkeit etc. bedeuten. Das Internet-Inter-ORB-Protokoll ist ein Protokoll, das typischerweise zwischen Prozessen auf unterschiedlichen Maschinen kommuniziert. In einigen Fällen kann das Internet-Inter-ORB-Protokoll jedoch zwischen Prozessen auf der gleichen Maschine kommunizieren. Der Sicherheitsserver 54 ist ein Sicherheitsadministrationsserver, der die Dienste sichert, die zwischen Prozessen auf unterschiedlichen Computern verwendet werden.
  • Typcode-/Beliebiges Modul 44 implementiert "Typcode" und "Beliebige" Objekte. Typcode beschreibt einen Schnittstellemodifikationssprachen- (IDL, Interface Definition Language) Datentyp, der erlaubt, Typbeschreibungen zwischen Clients und Servern zu übertragen. Eine Instanz eines IDL-Datentyps kann durch ein Beliebiges Objekt gekapselt sein. Ein Beliebiges Objekt verweist auf Typcode der gekapselten Daten, und eine generische Kodierung der Daten.
  • Ein Implementierungsrepository (Implementierungsdepot) 50 wird verwendet, um Information bezüglich Objektservern zu speichern. Spezifisch speichert Implementierungsrepository 50 die Information, die benötigt wird, um einen Serverprozess zu starten. Z.B. speichert Implementierungsrepository 50 Information, wie etwa den Standort des Serverprogramms, beliebige Argumente für das Programm und beliebige Umgebungsvariablen, die zu dem Programm weiterzugeben sind etc.
  • Die einfache Persistenz 56 verwendet einen Schnittstellendefinitionssprachen- (IDL) definierten Typ und die Ausgabe eines Durchlaufs dieses IDL-Typs durch den IDL-Compiler, zusammen mit einem Abschnitt von zusätzlichem Code, sodass ein IDL-definierten Typ von und zu einer Platte gelesen und geschrieben werden kann. Ein Namensgebungsdienst 52 wird verwendet, um ORB-Objekte zu benennen. Ein Client kann den Namensgebungsdienst-Namensserver 52 verwenden, um ein gewünschtes Objekt nach einem Namen zu finden. Namensserver 52 gibt eine Objektreferenz zurück, die wiederum verwendet werden kann, um Anforderungen zu diesem Objekt zu senden. Ein Schnittstellenrepository (Schnittstellendepot) 48 (IFR) weiß über alle Schnittstellen für alle Objekte innerhalb des verteilten Objektsystems.
  • Eine Anforderung, die durch einen Client unter Verwendung einer Methodentabellen- ("m-Tabelle") Abfertigung durchgeführt wird, wird eine Vielfalt der zuvor erwähnten Schichten der Architektur auf ihrem Weg zu dem Servant durchlaufen, wie schematisch in 1b veranschaulicht wird. Die Anforderung wird durch einen Client initiiert und kann eine beliebige geeignete Form annehmen. Die Form der Anforderung wird zu einem großen Ausmaß von dem Wesen der Programmierungssprache abhängen, die verwendet wird, um den Client zu erstellen. Als ein Beispiel kann die Anforderung, falls der Client in der C++-Sprache geschrieben ist, die Form eines C++-Methodenrufes 62 annehmen. Der Ruf wird zu einer bestimmten Objektreferenz durchgeführt, die die Form eines Surrogates annimmt. Das Surrogat inkludiert Methoden, die mit der Schnittstelle des Objektes übereinstimmen.
  • Wie durch einen Fachmann erkannt wird, kann die Objektreferenz, die in unterschiedlichen Stellen in einem verteilten Objektsystems verwendet wird, in der Erscheinung beträchtlich variieren. In der beschriebenen Ausführungsform ist die clientseitige Objektreferenz ein dualer Zeiger (hierin nachstehend als ein "fetter Zeiger" ("fat pointer") bezeichnet). Ein fetter Zeiger enthält zwei verschiedene Zeiger. Ein erster Zeiger, oder Standortindikator, zeigt zu einer Clientdarstellung ("Client rep"), die mit dem referenzierten Objekt in Verbindung steht. Ein zweiter Zeiger, oder Standortindikator, zeigt zu einer Methodentabelle der Methodentabellenabfertigung 24, die mit dem referenzierten Objekt in Verbindung steht. Es sollte erkannt werden, dass wie hierin verwendet, der Begriff "Zeiger" verwendet wird, um nicht nur Stellen in einem Computer oder Netzspeicher zu identifizieren, sondern auch um auf einen Standortindikator im allgemeinen zu verweisen. Eine Clientdarstellung ist ein Objekt, das Methoden hat, die einen Aufruf ebenso wie CORBA-definierte "pseudo" Objektverweisoperationen unterstützen. Diese Operationen inkludieren, sind aber nicht begrenzt auf, eine "Duplikat"-Methode, eine "Freigabe-" Methode, eine "schmale" Methode, eine Hash-Methode und eine Methode "ist äquivalent".
  • Nachdem der Client einen Ruf initiiert hat, wird der Ruf unter Verwendung eines Methodentabellen-Abfertigungsmechanismus 24 verarbeitet. Eine derartige Technik wird in US-Patentanmeldung US-6412019 B offenbart. Der Methodentabellen-Abfertigungsmechanismus verwendet eine Methodentabelle, die eine Liste von Zeigern auf Stub-Funktionen 25 enthält, von denen eine mit der aufzurufenden Methode in Verbindung steht. Stub-Funktionen 25 empfangen einen Funktions- oder Prozedurruf in der "nativen" Sprache des Clientprozesses, verwenden dann entweder eine Subkontraktschicht 36 oder einen nativen Ruf, um schließlich das entsprechende Servant-Objekt zu rufen. Die native Sprache kann eine beliebige geeignete Sprache sein, wie z.B. eine Sprache, wie etwa C++.
  • Methodentabellenabfertigung 24 bestimmt die geeignete eine der Stub-Funktionen 25, um den Methodenruf zu verarbeiten, und paart dann den Methodenruf mit der geeigneten Stub-Funktion. In dem Fall, dass der Client, der den Methodenruf durchführt, in dem gleichen Prozess wie das Servant-Objekt ist, wird eine lokale Stub-Funktion gerufen. Die lokale Stub-Funktion sendet den Methodenruf direkt zu Servant-Objekt 78. Falls das Servant-Objekt in einem anderen Prozess ist, d.h. einem entfernten Prozess, wird alternativ eine entfernte Stub-Funktion gerufen. Die entfernte Stub-Funktion ruft die Clientdarstellung auf, die den Aufruf zu Servant-Objekt 78 abliefert.
  • Subkontrakte, die durch Subkontraktschicht 36 implementiert sind, sind logische Module, die Steuerung der Basismechanismen von Objektaufruf und Argumentenweitergabe vorsehen, die in verteilten Objektsystemen wichtig sind. Ein Subkontrakt, der durch Subkontraktschicht 36 implementiert ist, bestimmt eine spezifische Dienstgüte für eine Verwendung durch ein Objekt. Ein Subkontrakt wird durch einen Subkontrakt-Identifikator eindeutig identifiziert, der typischerweise in einer Objektreferenz eingebettet ist. Eine Dienstgüte ist eine Menge von Diensteigenschaften. Unter möglichen Diensteigenschaften, die auswählbar sind, sind Qualitäten bezüglich Serveraktivierung, Sicherheit, Transaktionen, Filtrierbarkeit und sauberes Herunterfahren. Subkontrakte sind derart konfiguriert, dass gewisse Dienstgüten verfügbar sind. Mit vorbestimmten Dienstgüten wird der Overhead, der mit einer Verarbeitung einzelner Diensteigenschaften in Verbindung steht, reduziert. Realistisch werden nur "vernünftige" oder gemeinsam verwendete Kombinationen von Diensteigenschaften mit Subkontrakten unterstützt. Subkontrakte können jedoch erstellt werden, um die spezifischen Anforderungen eines gegebenen verteilten Objektsystems zu erfüllen.
  • Die Identifikation eines geeigneten Subkontrakts in Subkontraktschicht 36 kann man sich als die Identifikation einer gewünschten Funktion vorstellen, die für diesen Subkontrakt eindeutig ist. Z.B. ist eine Aufstellungsfunktion oder eine Abstellungsfunktion für jeden Subkontrakt definiert. Eine Subkontrakt-Abstellungsfunktion wird durch einen Stub verwendet, um eine Objektreferenz aufzustellen, sodass sie zu einem anderen Adressraum, oder Domäne, übertragen werden kann. Die Objektreferenz wird typischerweise durch einen Transportmechanismus in Transportschicht 38 verarbeitet.
  • Ein Transportmechanismus, wie etwa T1, T2 etc., der ein Teil der Transportschicht 38 ist, wird verwendet, um Information zu und von Servant-Objekten aufzustellen und physisch zu transportieren. Information, d.h. die Objektreferenz oder die Anforderung, wird in Protokolle konvertiert, die für eine gegebene Domäne geeignet sind. Als ein Beispiel können Protokolle inkludieren, sind aber nicht darauf begrenzt, Ethernet-Protokolle und allgemeine Inter-ORB-Protokolle (GIOPs). In einigen ungewöhnlichen Fällen können Protokolle sogar die Verwendung von elektronischer Post zur Folge haben, um Instruktionen zu übertragen, die auf einem Server zu implementieren sind. Nachdem Information aufgestellt ist, transportiert der Transportmechanismus dann Information durch eine beliebige Kombination von einem Betriebssystem, einem Einrichtungstreiber oder einem Netz, die alle ein Teil von Hardware 70 sind, die durch die Clientseite eines verteilten Objektsystems verwendet wird.
  • Während Transportmechanismen eine Konvertierung von Information in ein Protokoll erfordern, das für eine gegebene Domäne geeignet ist, erfordern einige Transportmechanismen nicht die Kodierung von Information für unterschiedliche Domänen. Ein Transportmechanismus, der eine Konvertierung von Information in ein Protokoll nicht erfordert, das für eine Domäne geeignet ist, mit Ausnahme der einen, aus der Information stammt, wird eine "Tür" ("door") genannt. Türen sind im wesentlichen Gateways zwischen zwei unterschiedlichen Prozessen in dem gleichen Host. Die Verwendung von Türen beseitigt die Notwendigkeit für eine Konvertierung von Information in eine kanonische Implementierung in Transportschicht 38, da es keine Notwendigkeit gibt, Information in ein Protokoll zu kodieren, das durch eine andere Maschine verwendet werden kann, wegen der Tatsache, dass Information auf dem gleichen Host bleibt und deshalb nicht eine Änderung der Domäne erfordert. Daher kann Information einfach "flach gemacht" ("flattened out") werden, oder in einen Strom aufgestellt werden, der nicht für eine Verwendung durch eine andere Maschine kodiert wird, und zwischen den zwei Prozessen in dem Host weitergegeben werden.
  • Sobald Information durch Hardware 70 transportiert wird, die durch die Clientseite verwendet wird, wird die Information dann zur Hardware 70 auf der Serverseite eines verteilten Objektsystems transportiert. Sobald Information durch Hardware 70 weitergeleitet wird, ruft die Serverseite eines verteilten Objektsystems einen Transportmechanismus, wie etwa T1, T2 etc., auf, um Information in einem Endpunkt zu empfangen, der ein Teil von Transportschicht 38 ist. In dem Fall, dass ein Endpunkt nicht durch Transportschicht 38 erstellt wird, sieht Transportschicht 38 die Funktionalität vor, die für den Endpunkt benötigt wird, um durch Subkontraktschicht 36 erstellt zu werden. Als ein Beispiel wird ein dedizierter Endpunkt typischerweise durch Subkontraktschicht 36 erstellt, während Clusterendpunkte, die typischerweise Netz und TCP/IP-Endpunkte inkludieren, typischerweise durch Transportschicht 38 erstellt werden. Ungeachtet dessen, ob Endpunkte durch Subkontraktschicht 36 oder Transportschicht 38 erstellt werden, "leben" Endpunkte in, d.h. sind ein Teil von, Transportschicht 38. Endpunkte sind im wesentlichen Ports, die Information von einer anderen Domäne empfangen. Nachdem ein Endpunkt in Transportschicht 38 Information empfängt, die von einer anderen Domäne transportiert wird, fertigt der Endpunkt dann die Information von Transportschicht 38 zu Subkontraktschicht 36 ab. Subkontraktschicht 36 fertigt dann die Information zu dem Skelett und dem Servant ab.
  • Subkontraktschicht 36 sieht die Funktionalität vor, mindestens einige der Information abzustellen, die empfangen wurde. D.h. Subkontraktschicht 36 stellt mindestens einen Teil der Anforderung ab. Dann wird die Anforderung zu einem Skelett 31 abgefertigt, das die Anforderung in ein implementierungsspezifisches Format transformiert, das durch Servant-Objekt 78 gefordert wird. Das Skelett kann entweder ein statisches Skelett oder ein dynamisches Skelett sein, wie oben beschrieben wird.
  • Im allgemeinen wird eine entfernte Anforderung durch die Clientseite und die Serverseite weitergeleitet, wie oben beschrieben wird. Der Methodenruf 62 wird empfangen, Methodentabellen-Abfertigungsschicht 24 wird verwendet, um einen geeigneten Subkontrakt vor der Auswahl eines Transportmechanismus in Transportschicht 38 zu identifizieren, der die Anforderung aufstellt und sie für einen Transport zu einer anderen Domäne vorbereitet. Durch Hardware 70 wird die aufgestellte Anforderung zu der Serverseite transportiert, wo sie in einem Endpunkt empfangen wird, der ein Teil von Transportschicht 38 ist. Ein geeigneter Endpunkt empfängt Information, die über eine Leitung transportiert wird, und die Information wird von Transportschicht 38 zu Subkontraktschicht 36 abgefertigt, die die Funktionalität vorsieht, mindestens teilweise die Information abzustellen, die sie empfangen hat. Die Subkontraktschicht fertigt dann die Anforderung zu Skelett 31 ab, das die Anforderung in ein spezifisches Format transformiert, das durch Servant-Objekt 78 gefordert wird. Dieser Pfad wird durch Pfeil 77 gezeigt, und ist der Pfad, der durch sowohl entfernte als auch lokale Anforderungen genommen werden kann.
  • Falls jedoch ein Client und ein Server in einem lokalen Prozess sind, d.h. sowohl der Client als auch der Server in dem gleichen Prozess sind, ist die Verwendung des Pfades, der durch Pfeil 77 gezeigt wird, wie oben beschrieben, unnötig komplex. Falls bekannt ist, dass der Client und der Server in dem gleichen Prozess sind, ist es möglich, den Aufrufpfad, oder Flusspfad einer Anforderung für einen Dienst zu verkürzen. Falls ein lokaler Prozess identifiziert werden kann, wenn eine Objektreferenz erstellt wird, können verkürzte Flusspfade, d.h. die Pfade, die durch Pfeile 75 und 76 dargestellt werden, genommen werden, um eine Anforderung von einem Client zu einem Server, die in dem gleichen Host sind, zu senden. Es ist wahrscheinlicher, dass der Pfad genommen wird, der durch Pfeil 76 dargestellt wird, da er Subkontraktschicht 36 verwendet, um einen geeigneten Subkontrakt zu identifizieren. In Situationen jedoch, in denen ein geeigneter Subkontrakt nicht explizit identifiziert werden muss, kann der Pfad genommen werden, der durch Pfeil 75 dargestellt wird.
  • Es wird nun 2 verwendet, um eine Ausführungsform einer Objektreferenz zu beschreiben. Wie einem Fachmann vertraut sein wird, können Objektreferenzen eine Vielfalt von Formen annehmen, abhängig von der Stelle innerhalb des Prozesses, in der sie in einer beliebigen gegebenen Zeit gehalten werden. Als Hintergrund wird jedoch eine repräsentative Objektreferenz für eine Verwendung in einem System, da eine Implementierungssuite mit geringem Overhead nutzt, in 2 veranschaulicht. In der darin gezeigten Implementierung inkludiert Objektreferenz 150 einen Hostidentifikator 152, eine Portbestimmung 154 und einen Objektschlüssel 156. Objektschlüssel 156 inkludiert einen Subkontraktidentifikator 158, einen Serveridentifikator 160, einen Implementierungsidentifikator 162 und einen Benutzerschlüssel 164. Hostidentifikator 152 bezeichnet einen bestimmten Computer in einem Netz, während Portbestimmung 154 den Port des ausgewählten Computers identifiziert, der für eine Kommunikation zu verwenden ist. Objektschlüssel 156 sieht ferner identifizierende Information vor, die verwendet wird, um ein gewünschtes Servant-Objekt in seiner Host-Maschine zu lokalisieren.
  • Serveridentifikator 160 benennt einen bestimmten Prozess oder Programm, worin sich das Servant-Objekt befindet, während Benutzerschlüssel 164 eine eindeutige Zahl oder Zeichenkette ist, die verwendet wird, um den Servant innerhalb des Prozesses zu lokalisieren, der durch Serveridentifikator 160 benannt wird. Subkontraktidentifikator 158 wird verwendet, um das Protokoll eines bestimmten Subkontraktes und seine zugehörigen Dienste bei einem Servant anzubringen, und Implementierungsidentifikator 62 benennt eine Implementierung einer Schnittstelle, die mit diesem Servant-Objekt zu verwenden ist.
  • Eine Verringerung des Umfangs von Anwendungscode, der durch ein verteiltes objektorientiertes System verwendet wird, d.h. eine verteilte Betriebsumgebung, ohne Kompromittierung des Leistungsverhaltens des Systems würde dazu dienen, die Gesamteffizienz des Systems zu erhöhen. Ein Weg, den Umfang von Anwendungscode zu reduzieren, der in einem verteilten objektorientierten System verwendet wird, ist, so viel Code wie möglich verbreitet zu machen (commonize). Mit anderen Worten würde eine Verwendung des gleichen Codes, um unterschiedliche Aufgaben durchzuführen, wann immer es möglich ist, ermöglichen, den Gesamtumfang von Anwendungscode zu reduzieren, während die Gesamteffizienz des Systems erhöht wird. Ferner implizieren weniger Codepfade, dass der Code sowohl leichter zu testen ist als auch weniger Potenzial für versteckte Fehler in weniger verbreiteten Merkmalen haben wird. Als ein Beispiel kann ein relativ großer Anteil eines weniger verbreiteten Merkmals, wie dynamischer Aufruf, getestet werden, wenn statischer Aufruf, was ein Merkmal ist, das mehr verbreitet ist, getestet wird. Der Rest des Merkmals des dynamischen Aufrufs, der eine oder zwei kleinere Routinen inkludieren kann, kann unabhängig getestet werden.
  • Ein Bereich, in dem gemeinsam verbreiteter Code implementiert werden kann, ist der Bereich zum Rufen einer Methode. Rufe zu Methoden in einem Client-Server-System haben typischerweise die Spezifikation einer Methode zur Folge, und Information, die erforderlich ist, um die Methode aufzurufen, inkludierend verschiedene Schnittstellenparameter, die durch die Methode verwendet werden, und Ausnahmen, die durch die Methode geworfen werden. Typischerweise richtet sich Code, der in Bezug auf jeden Parameter generiert wird, direkt zu jeder Methode, die den Parameter verwendet. Da viele Methoden die gleichen Parameter verwenden können, kann die Effizienz eines Systems verbessert werden, falls Code, der sich auf einen Parameter bezieht, in einem "Modul" oder einer Datenstruktur eingeschlossen ist. Auf dieses Modul von Code kann dann von mehr als einer Methode zugegriffen werden, wobei dadurch der Umfang von Code in einem System reduziert wird.
  • Ein anderer Bereich, in dem gemeinsam verbreiteter Code implementiert werden kann, ist der Bereich zum Aufstellen und Abstellen. Aufstellen eines Paketes von Information hat Vorbereitung der Information für einen Transfer über eine "Leitung" oder eine Netzkommunikationsleitung zur Folge. Abstellen eines Paketes von Information ist im wesentlichen der Prozess zum Umkehren der Aufstellungsprozedur, wobei dadurch ein Paket von Information erzeugt wird, das in einer Nicht-Netzumgebung von Bedeutung ist. Es gibt zwei allgemeine Typen zum Aufstellen und zwei allgemeine Typen zum Abstellen, nämlich kompiliertes Aufstellen oder Abstellen und nicht-kompiliertes, oder Typcode-interpretiertes, Aufstellen und Abstellen. Isolieren der Unterschiede zwischen kompilierten, oder durch Schnittstellendefinitionssprache (IDL) generierten, und nicht-kompilierten Aufstellungs- und Abstellungsroutinen würde ermöglichen, eine gemeinsame Codebasis für eine Verwendung mit den Abschnitten der Routinen zu erstellen, die sich nicht unterscheiden. D.h. es können eine generische Aufstellungsroutine und eine generische Abstellungsroutine erstellt werden. Die Verwendung von generischen Routinen macht das Testen vom Code einfacher, wobei dadurch das Potenzial für versteckte Fehler reduziert wird, die in weniger verbreiteten Merkmalen existieren können.
  • Im allgemeinen involviert, wie oben erwähnt, ein Ruf, um ein Objekt aufzurufen, Spezifizieren einer Methode, die aufzurufen ist, Spezifizieren von Parametern, die mit der aufzurufenden Methode in Verbindung stehen, und Spezifizieren beliebiger Ausnahmen, die mit der aufzurufenden Methode in Verbindung stehen. Es können Datenstrukturen genutzt werden, um Code gemeinsam zu verbreiten. Datenstrukturen können ferner genutzt werden, um Änderungen in Bezug auf einen Parameter zu ermöglichen, um z.B. ohne Beeinflussung des gesamten Aufrufs einer Methode durchgeführt zu werden, die den Parameter verwendet, an dem Änderungen gemacht werden. Mit anderen Worten ermöglicht die Verwendung von Datenstrukturen, dass Änderungen an einem Element durchgeführt werden, das mit einem Ruf in Verbindung steht, um ein Objekt aufzurufen, ohne z.B. beträchtliche Änderungen zu erfordern, die an Anwendungssoftware durchzuführen sind. Datenstrukturen, die verwendet werden können, um ein Objekt aufzurufen, inkludieren, sind aber nicht darauf begrenzt, eine Methodendeskriptor-Datenstruktur, eine Aufrufdeskriptor-Datenstruktur, eine Parameterdatenstruktur und eine Ausnahmedatenstruktur.
  • Bezug nehmend als Nächstes auf 3 wird eine schematische Darstellung eines Methodendeskriptors 79 gezeigt, der zur Verwendung mit der vorliegenden Erfindung geeignet ist. Methodendeskriptor 79 ist eine von vielen Deskriptordatenstrukturen, und wird verwendet, um eine bestimmte Methode zu beschreiben, die zu rufen oder aufzurufen ist. Typischerweise beschreibt Methodendeskriptor 79 eine entfernte Prozedurenmethode. Sowohl die Clientseite als auch die Serverseite eines verteilten objektorientierten Systems verwenden Methodendeskriptor-Datenstrukturen 79. In der gezeigten Ausführungsform inkludiert die Methodendeskriptor-Datenstruktur 79 einen Schlüssel 80, einen lokalen Namen 81 der Methode, die aufzurufen ist, und einen logischen Identifikator (ID) 82 für die Methode, die aufzurufen ist. Schlüssel 80 kann eine beliebige geeignete Form annehmen, z.B. den Hash-Wert oder den numerischen Wert, vom lokalen Namen 81, der eine Kette von Zeichen ist. Der Hash-Wert vom lokalen Namen 81 kann verwendet werden, um eine Methodennummer zu generieren, die während sie nicht eindeutig ist, verwendet werden kann, um eine zugehörige Methode zu identifizieren. Der lokale Name 81 der Methode, die aufzurufen ist, ist ein nicht-abgegrenzter Name, und dient dazu, den Client zu identifizieren, mit dem der Methodendeskriptor in Verbindung steht. Der logische ID 82 ist ein eindeutiger Name für die zugehörige Methode. D.h. der logische ID 82 dient als ein globaler Identifikator für die Methode.
  • Der Vorteil einer Bereitstellung von Schlüssel 80 zusätzlich zu dem lokalen Namen 81 der Methode und dem logischen ID 82 in dem Methodendeskriptor rührt aus der Tatsache, dass Schlüssel 80 einen numerischen Wert hat, wohingegen der lokale Name 81 der Methode und der logische ID 82 typischerweise Ketten von Zeichen sind. Numerische Werte können viel schneller verglichen, dekodiert und abgefertigt werden als Werte, die Ketten von Zeichen sind.
  • Während Methodendeskriptor 79 Information in Bezug auf eine Methode enthält, enthält er nicht Information, die den tatsächlichen Aufruf der Methode beschreibt. Entsprechend wird eine Aufrufdeskriptor bereitgestellt, um den tatsächlichen Aufruf der Methode zu beschreiben. Ein Aufrufdeskriptor ist eine Datenstruktur, die verwendet wird, um Information bereitzustellen, die den Aufruf einer Methode betrifft. Mit anderen Worten ist ein Aufrufdeskriptor eine Sammlung aller Information in Bezug auf eine gegebene entfernte Prozedurenmethode, die durch einen Methodendeskriptor beschrieben wird.
  • 4 ist eine schematische Darstellung eines Aufrufdeskriptors 84 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung. Aufrufdeskriptor 84 kann eine Kombination von booleschen Werten, ganzzahligen Werten, einem Kontext, Zeigern auf andere Datenstrukturen und Zeigern auf Funktionen inkludieren. Es sollte erkannt werden, dass Zeiger durch generische Identifikatoren ersetzt werden können, d.h. beliebige Mittel zum Identifizieren geeigneter Datenstrukturen oder Funktionen. Hierin wird der Begriff Zeiger und Identifikator austauschbar verwendet. Boolesche Werte, oder logische Flags, inkludieren ein "kompiliertes" Flag 84 und ein "Einweg"-Flag 85. Das kompilierte Flag 84 identifiziert, ob der Aufrufpfad statisch ist, d.h. kompiliert, oder dynamisch, d.h. Typcode-interpretiert. Ein dynamischer Aufrufpfad ist auch als ein nicht-kompilierter Aufrufpfad bekannt. Einweg-Flag 85 identifiziert, ob eine Antwort als Reaktion auf eine Anforderung ist. Ganzzahlige Werte inkludieren einen "In"-Deskriptorzähler 86 (IN_DESC_COUNT) und einen "Aus"-Deskriptorzähler 87 (OUT_DESC_COUNT). Die Zähler halten Werte, die die Zahl von "In"-Parametern bzw. die Zahl von "Aus"-Parametern darstellen, die mit einem bestimmten Aufruf in Verbindung stehen.
  • Aufrufdeskriptor 83, der in 4 dargestellt wird, inkludiert Zeiger zu anderen Datenstrukturen, nämlich einen Zeiger auf einen "In"-Deskriptor 88 (IN_DESC), einen Zeiger auf einen "Aus"-Deskriptor 89 (OUT_DESC) und einen Zeiger auf einen Ausnahmedeskriptor (EXCEPTION_DESC). IN_DESC 88 und OUT_DESC 89 sind Zeiger auf Parameterdeskriptoren, die nachstehend mit Bezug auf 5 detailliert erläutert werden. IN_DESC 88 und OUT_DESC 89 können jeder ein Zeiger zu einem Feld von Parameterdeskriptoren sein. EXCEPTION_DESC 90 ist ein Zeiger auf ein Feld von Zeigern zu Ausnahmedeskriptoren, und wird anschlieflend mit Bezug auf 6 beschrieben. IN_DESC_COUNT 86 (OUT_DESC_COUNT 87) und IN_DESC 88 (OUT_DESC 89) implementieren eine geordnete gezählte Sammlung von Parameterdeskriptoren und können unter Verwendung anderer geeigneter Datenstrukturen implementiert werden.
  • Der Aufrufdeskriptor, der in 4 gezeigt wird, inkludiert auch einen Kontext 91. Ein Kontext, wie z.B. Kontext 91, kann im allgemeinen ein Feld von zugehörigen Zeichenketten sein, die Information enthalten, die für die aufzurufende Methode relevant ist. Die Information, die in einem Kontext enthalten ist, kann Information sein, die für die Implementierung der aufzurufenden Methode nützlich ist. Ein Kontext ist konzeptionell eine Liste von Assoziationen. Jede Assoziation inkludiert typischerweise einen Schlüssel, der eine Zeichenkette ist, und einen Wert, der auch eine Zeichenkette ist, der mit dem Schlüssel in Verbindung steht.
  • Ein Zeiger zu einer Reinitialisierungsfunktion 92 (REINIT) ist als ein Teil vom Aufrufdeskriptor 83 inkludiert, der in 4 dargestellt wird. Die Reinitialisierungsfunktion setzt alle gespeicherten Zeiger frei, und dient dazu, zugehörige Puffer zu löschen, sobald Daten in den Puffern verarbeitet wurden. Als ein Beispiel löscht, falls die aufzurufende Methode eine Aufstellungsmethode ist, die eine Methode zum Vorbereiten von Information für einen Transfer über eine Netzkommunikationsleitung ist, die Reinitialisierungsfunktion einen zugehörigen Parameter in irgendeinem Punkt, nachdem die Information in dem Parameter aufgestellt wurde.
  • Bezug nehmend als Nächstes auf 5 wird eine schematische Darstellung eines Parameterdeskriptors 93 in Übereinstimmung mit einer Ausführungsform der Erfindung gezeigt. Parameterdeskriptor 93 ist eine Datenstruktur, die angeordnet ist, die Charakteristika zu beschreiben, die mit einem gegebenen Parameter in Verbindung stehen, und steht selbst mit einem Aufrufdeskriptor durch den In-Deskriptor (IN_DESC) und den AUS-Deskriptor (OUT_DESC) in Verbindung, wie mit Bezug auf 4 beschrieben. Parameterdeskriptor 93 kann eine Richtung 94 und einen Typcode 95 inkludieren, und kann zusätzlich eine beliebige Kombination von einem Größencode 96, einem Namen 97, einem Zeiger zu einer zugehörigen Aufstellungsfunktion 98 und einem Zeiger zu einer zugehörigen Abstellungsfunktion 99 inkludieren. Richtung 94 ist ein Indikator, der eine Verarbeitungsrichtung des gegebenen Parameters identifiziert. Richtung 94 kann auch als ein Modus bezeichnet werden. Die Verarbeitungsrichtungen sind, von dem Rahmen von Bezug eines Clients, eine "In"-Richtung, eine "Aus"-Richtung, eine "In-Aus"-Richtung und eine" Rückgabe"-Richtung. Die In-Richtung ist eine Anzeige, dass der gegebene Parameter ein Argument sein kann, das durch den Client zu dem Server vorgesehen wird, wohingegen die Aus-Richtung eine Anzeige ist, dass der gegebene Parameter ein Argument sein kann, das durch den Server zu dem Client vorgesehen wird. Es folgt, dass die In-Aus-Richtung eine Anzeige ist, dass der gegebene Parameter ein Argument sein kann, das in sowohl einer In-Richtung als auch einer Aus-Richtung übertragen wird. Die Rückgaberichtung ist eine Anzeige, dass der gegebene Parameter ein Argument in einer Rückgabe von einem Ruf sein kann. Mit anderen Worten ist die Rückgaberichtung ein Spezialfall der Aus-Richtung.
  • Wie oben beschrieben stehen Parameterdeskriptoren, wie z.B. Parameterdeskriptor 93, mit Aufrufdeskriptoren in Verbindung. Speziell wird auf Parameterdeskriptoren indirekt durch die Zeiger IN_DESC und OUT_DESC gezeigt, die in einem Aufrufdeskriptor inkludiert sind, wie oben mit Bezug auf 4 erwähnt. IN_DESC ist allgemein ein Zeiger auf ein Feld von Parameterdeskriptoren mit einer Verarbeitungsrichtung, die eine In-Richtung oder eine In-Aus-Richtung ist, während OUT_DESC allgemein ein Zeiger auf ein Feld von Parameterdeskriptoren mit einer Verarbeitungsrichtung ist, die entweder eine Aus-Richtung oder eine Rückgaberichtung sein kann.
  • Typcode 95 enthält Spezifikationen, die einen bestimmten Datentyp beschreiben, in diesem Fall den Datentyp eines Parameters, obwohl Typcode 95 Information bezüglich der Verarbeitungsrichtung des Parameters nicht inkludiert. Typcode 95 inkludiert Zeiger zu Aufstellungs- und Abstellungsfunktionen oder Methoden. Aufstellungsfunktionen wurden zuvor mit Bezug auf 4 beschrieben. Eine Abstellungsfunktion ist eine Funktion, die die Aufstellungsprozedur umkehrt, um eine Instanz des Datentyps zu erzeugen, die in der Domäne von Bedeutung ist, in der der Datentyp zu verwenden ist. Typcode 95 inkludiert auch Information betreffend die Größe des Datentyps, oder mit anderen Worten den Umfang von Speicher, den jede Instanz des Datentyps erfordert. Es sollte erkannt werden, dass der Hauptzweck von Typcode 95 ist, einen Datentyp, oder genauer die Struktur oder Bestandteile des Datentyps, zu beschreiben.
  • Da Typcode 95 Zeiger zu Aufstellungs- und Abstellungsfunktionen inkludiert, ist Information in Bezug auf den Namen und Bestandteile eines Datentyps, und die Größe, oder den Umfang, von Speicher, der durch eine Instanz des Datentyps erforderlich ist, nicht notwendig, um speziell Zeiger zu Aufstellungs- und Abstellungsfunktionen zu inkludieren, und einen Wert in Bezug auf die Größe des Datentyps als einen Teil des Parameterdeskriptors. Explizites Vorsehen von Information, die aus Typcode 95 in Parameter 93 extrahiert werden kann, ist jedoch dadurch von Vorteil, dass es die Leistungsverhaltensstrafe beseitigt, die mit Extrahieren der Information jedes Mal, wenn sie benötigt oder erwünscht ist, in Verbindung steht. Als ein Beispiel ist eine Berechnung der Größe eines Datentyps über Typcode 95 aufwändig, da sie rekursive Berechnung von Größen von Bestandteilstypen und Summierung der Ergebnisse involvieren kann. Daher kann, wie zuvor beschrieben, Parameterdeskriptor 93 explizit Information betreffend Größe 96 eines zugehörigen Parameters, und Name 97 des Parameters, ebenso wie Zeiger 98 und 99 zu den Aufstellungs- bzw. Abstellungsfunktionen des Parameters zusätzlich zu Richtung 94 und Typcode 95 des Parameters inkludieren.
  • Bezug nehmend als Nächstes auf 6 wird eine schematische Darstellung eines Ausnahmedeskriptors 102 in Übereinstimmung mit einer Ausführungsform der Erfindung gezeigt. Ausnahmedeskriptor 102 ist eine Datenstruktur, die angeordnet ist, die Charakteristika einer zugehörigen Ausnahme zu beschreiben. Wie der oben beschriebene Parameterdeskriptor steht Ausnahmedeskriptor 102 mit Aufrufdeskriptoren in Verbindung, und auf ihn wird durch den oben mit Bezug auf 4 erwähnten Zeiger EXCEPTION_DESC indirekt gezeigt. Ausnahmedeskriptor 102 kann Typcode 103 inkludieren, und kann auch explizit spezifizierte Information betreffend eine beliebige Kombination von einer Größe 104, einem Schlüssel 107, einem Repositoryidentifikator 108, einem Zeiger zu einer zugehörigen Aufstellungsfunktion 111, einem Zeiger zu einer zugehörigen Abstellungsfunktion 112 und einem Zeiger zu einer Wurffunktion 113 inkludieren. Während der oben beschriebene Parameterdeskriptor eine Richtung inkludiert, tut es Ausnahmedeskriptor 102 nicht, da die Verarbeitungsrichtung stets von dem Server zu dem Client ist. Mit anderen Worten wird eine Ausnahme stets von dem Server zu dem Client übertragen.
  • Wie oben mit Bezug auf 5 beschrieben, enthält Typcode 103 Spezifikationen, die einen bestimmten Datentyp beschreiben, inkludierend Zeiger zu Aufstellungs- und Abstellungsfunktionen, die mit dem Datentyp in Verbindung stehen. Bezug nehmend zurück auf 6 ist die Entität in diesem Fall eine Ausnahme. Zusätzlich zum Inkludieren von Zeigern auf die Aufstellungs- und Abstellungsfunktionen, die mit der Ausnahme in Verbindung stehen, inkludiert Typcode 103 Information in Bezug auf die Größe der Ausnahme, oder den Umfang von Speicher, der durch einen Prozess zugeordnet werden muss, der die Ausnahme empfängt. Typcode 103 inkludiert ferner einen Repositoryidentifikator (REPOSITORY_ID). Der Repositoryidentifikator dient ferner dazu, die Ausnahme eindeutig zu identifizieren. Der Repositoryidentifikator ist in etwa analog zu dem LOGICAL_ID des Methodendeskriptors, wie oben mit Bezug auf 3 beschrieben, und kann verwendet werden, eine Ausnahme innerhalb eines Ausnahmerepository eindeutig zu identifizieren, oder eine "Auflistung" aller Ausnahmen. Schließlich inkludiert Typcode 103 einen Zeiger zu einer Wurffunktion (THROW_FUNC), die das Wesen der Ausnahme spezifiziert, und wird verwendet, eine Anforderung in dem Fall einer Ausnahme umzuleiten. Es sollte erkannt werden, dass obwohl nur Information in Typcode 103 beschrieben wurde, die speziell für den Ausnahmedeskriptor relevant ist, Typcode 103 allgemein viel mehr Information als beschrieben enthalten kann.
  • Wie es der Fall mit dem Parameterdeskriptor war, der oben mit Bezug auf 5 beschrieben wird, kann Ausnahmedeskriptor 102, wie mit Bezug auf 6 beschrieben, explizit Informa tion inkludieren, die aus Typcode 103 extrahiert werden kann. Erneut kann diese Information, nämlich eine beliebige Kombination von Größe 104 der Ausnahme, Schlüssel 107, Repositoryidentifikator 108, Zeiger zu der zugehörigen Aufstellungsfunktion 111 und Zeiger zu der zugehörigen Abstellungsfunktion 112, explizit in Ausnahmedeskriptor 102 inkludiert sein, um die Leistungsverhaltensstrafe zu vermeiden, die jedes Mal, wenn die Information aus Typcode 103 extrahiert wird, berechnet wird.
  • Die vier Deskriptordatenstrukturen, die in 3 bis 6 beschrieben werden, stehen in gegenseitiger Beziehung. Parameter- und Ausnahme-Deskriptordatenstrukturen werden durch eine Compilerroutine in einem verteilten objektorientierten System beim Hochfahren generiert. D.h. die Parameter- und Ausnahme-Deskriptordatenstrukturen werden automatisch zur Kompilierungszeit angemeldet. Methoden- und Aufruf-Deskriptordatenstrukturen können andererseits entweder beim Hochfahren erstellt und automatisch zur Kompilierungszeit angemeldet werden, oder sie können zur Laufzeit erstellt werden. Ein Aufrufdeskriptor inkludiert Zeiger zu Feldern von Parameterdeskriptoren und Felder von Zeigern zu Ausnahmedeskriptoren. Die Beziehung zwischen einem Methodendeskriptor und den verbleibenden drei Datenstrukturen kann am besten mit Bezug auf 7 verstanden werden, die eine Darstellung eines Rufes zu einer Aufrufmethode in der clientseitigen Darstellung eines verteilten Objektes in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung ist. Der Ruf zu einer Aufrufmethode involviert Inkludieren als Argumente einen Zeiger zu einem Methodendeskriptor, einen Zeiger zu einem zugehörigen Aufrufdeskriptor, Zeiger zu Feldern von Parameteradressen oder Speicherstellen, einen CORBA-Kontext und eine CORBA-Ausnahme. Der Methodendeskriptor und der Aufrufdeskriptor stehen dadurch in gegenseitiger Beziehung, dass sie beide ein Teil des Rufes zu einer Aufrufmethode sind. Obwohl ein Methodendeskriptor und ein Aufrufdeskriptor in eine einzelne Deskriptordatenstruktur kombiniert werden können, bleiben sie wegen der Tatsache getrennt, dass obwohl sowohl die Clientseite als auch die Serverseite eines verteilten objektorientierten Systems den Methodendeskriptor verwenden, auf der Serverseite Information in dem Methodendeskriptor und Information in dem Aufrufdeskriptor von unterschiedlichen Stellen in dem Gesamtsystem kommt. Die Listen von Parameteradressen ändern sich mit jedem Ruf zu der Aufrufmethode, und dienen teilweise dazu, Speicherstellen vorzusehen, von denen "In"-Argumente zu erhalten sind und in denen "Aus"-Argumente zu speichern sind. Die Parameterspeicherstellenfelder werden durch Stubs und Skelette eingerichtet, die oben mit Bezug auf 1b beschrieben wurden. Der CORBA-Ausnahme-Speicher-Ausnahmedeskriptor sieht einen Zeiger zu einem Ausnahmerückgabezeiger vor. Dieser Zeiger zu einem Ausnahmerückgabezeiger zeigt an, wo der Zeiger zu einer Ausnahme zu speichern ist. Falls der Zeiger zu einem Ausnahmerückgabezeiger Null ist, wird eine Ausnahmerückgabe geworfen.
  • Bezug nehmend als Nächstes auf 8 wird eine Methode zum Aufrufen eines Objektes in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung beschrieben. D.h. es werden die Schritte in dem Diagramm gezeigt, die auftreten, sobald ein Ruf durchgeführt wird, um eine Methode aufzurufen. Anfangs wird ein Ruf oder eine Anforderung, dass die einen fetten Zeiger verwendet, durch einen Client empfangen. Obwohl der Ruf in einer beliebigen geeigneten Computersprache sein kann, ist der Ruf in der beschriebenen Ausführungsform ein C++-Ruf. Einen fetten Zeiger kann man sich als einen "großen" Zeiger, oder eine Zeigerstruktur, vorstellen, der/die mindestens zwei "normale" Zeiger enthält. Ein fetter Zeiger kann auch betrachtet werden, eine CORBA-Objektreferenz zu sein. In einem fetten Zeiger mit zwei "normalen" Zeigern enthält der fette Zeiger typischerweise acht Bytes, während die normalen Zeiger typischerweise je vier Bytes enthalten. Der fette Zeiger besteht aus einem Darstellungszeiger "rep" und einem Zeiger einer Methodentabelle, oder m-Tabelle, von denen jeder ein normaler Zeiger ist. Der Darstellungszeiger zeigt auf eine Clientdarstellung, oder Client-"rep", und kann betrachtet werden, ein Zeiger zu einer Subkontraktentität zu sein, die ein verteiltes Objekt in dem Client darstellt.
  • In Schritt 100 wird die gerufene Methode in der m-Tabelle lokalisiert, auf die durch den fetten Zeiger gezeigt wird. Falls die gerufene Methode eine lokale Methode ist, dann ist die m-Tabelle, auf die durch den fetten Zeiger gezeigt wird, eine lokale m-Tabelle. Falls die gerufene Methode eine entfernte Methode ist, ist dann ähnlich die m-Tabelle, auf die durch den fetten Zeiger gezeigt wird, eine entfernte m-Tabelle. In Schritt 105 wird ein Ruf zu der Funktion, auf die mit der Clientdarstellung gezeigt wird, identifiziert durch den fetten Zeiger und Argumenten zu dem C++-Ruf, durchgeführt. Nachdem die Funktion gerufen ist, verzweigt die Prozesssteuerung zu unterschiedlichen Funktionen abhängig davon, ob die Funktion, auf die gezeigt wird, in einem lokalen Prozess oder einem entfernten Prozess ist. Falls die Funktion, auf die gezeigt wird, in einem lokalen Prozess ist, fährt die Prozesssteuerung zu Schritt 110 fort, in dem ein lokaler Stub ausgeführt wird. Nachdem der lokale Stub in Schritt 110 ausgeführt wurde, kehrt der Prozess von dem Funktionsruf in Schritt 120 zurück. Falls die Funktion, auf die durch den fetten Zeiger gezeigt wird, in einem entfernten Prozess und nicht in einem lokalen Prozess ist, rückt die Prozesssteuerung zu Schritt 115 vor, nachdem die Funktion in Schritt 105 gerufen ist. In Schritt 115 wird ein entfernter Stub ausgeführt. Der Prozess zum Ausführen eines entfernten Stubs wird nachstehend detailliert erläutert. Nachdem der entfernte Stub in Schritt 115 ausgeführt wurde, fährt die Prozesssteuerung zu Schritt 120 fort, der die Rückgabe von dem Funktionsruf ist.
  • Bezug nehmend als Nächstes auf 9 wird eine Methode zum Ausführen eines entfernten Stubs in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung beschrieben. D.h. mit Bezug auf 8, Schritt 115, wird der Schritt zum Ausführen eines entfernten Stubs detailliert beschrieben. Der Start zum Aufruf von einem entfernten Stub mit einer Liste von Argumenten und einem Kontext, falls ein Kontext verwendet wird, beginnt in Schritt 190, der die Zuordnung einer Ablage, oder von Speicher, ist, für einige Rückgabe- und Aus-Parameter, oder Parameter mit einer Rückgabeverarbeitungsrichtung und Parameter mit einer Aus-Verarbeitungsrichtung. Hierin können die Begriffe "In-Parameter" und "Aus-Parameter" austauschbar mit den Ausdrücken "Parameter mit einer In-Verarbeitungseinrichtung" bzw. "Parameter mit einer Aus-Verarbeitungsrichtung" verwendet werden. Ähnlich werden auch die Begriffe "Rückgabeparameter" und "In-Aus-Parameter" austauschbar mit den Ausdrücken "Parameter mit einer Rückgabeverarbeitungsrichtung" bzw. "Parameter mit einer In-Aus-Richtung" verwendet. Im Speicherzuordnungsschritt 190 wird Speicher nicht für In-Aus-Parameter zugeordnet, da Speicher für Parameter mit einer In-Aus-Verarbeitungsrichtung im voraus zugeordnet wird. Von Speicherzuordnungsschritt 190 fährt die Prozesssteuerung zu Schritt 192 fort, wo In-Parameter eingerichtet werden. Jedes Mal, wenn eine Aufrufmethode gerufen wird, müssen die In-Parameter, die mit Argumenten in Verbindung stehen, die in dem Aufruf von dem entfernten Stub verwendet werden, eingerichtet werden. Einrichten von In-Parametern hat Erstellung eines Feldes von Zeigern zu Speicherstellen zur Folge, die In-Parameter enthalten, die als IN_PARAMs zu der Aufrufmethode von 7 weiterzugeben sind. Von dem Schritt zum Einrichten von In-Parametern fährt die Prozesssteuerung zu Schritt 194 fort, in dem Aus-Parameter, ebenso wie Rückga beparameter, eingerichtet werden. D.h. es wird ein Feld von Zeigern zu Speicherstellen, die Aus-Parameter empfangen werden, die als OUT_PARAMs zu der Aufrufmethode von 7 weitergegeben werden, erstellt.
  • Von Schritt 194, dem Schritt zum Einrichten von Aus-Parametern, bewegt sich die Prozesssteuerung zu Schritt 196, in dem ein Ruf zu der Aufrufmethode für die Clientdarstellung durchgeführt wird. Es sollte erkannt werden, dass die "Signatur", oder Basiselemente, oder eine Aufrufmethode zuvor mit Bezug auf 7 beschrieben wurden. Jede Clientdarstellung hat eine zugehörige Aufrufmethode. Die Schritte, die mit Rufen der Aufrufmethode für die Clientdarstellung involviert sind, werden nachstehend mit Bezug auf 10 erörtert. In Schritt 197 wird eine Bestimmung bezüglich dessen durchgeführt, ob der Ruf zu der Aufrufmethode in Schritt 196 zu einer Ausnahme geführt hat. Falls bestimmt wird, dass es eine Ausnahme gegeben hat, fährt die Prozesssteuerung zu Schritt 198 fort, wo der Speicher, der für die Speicherung von Rückgabe- und Aus-Parametern in Schritt 190 zugeordnet wurde, deallokiert wird. Die Prozesssteuerung gibt dann das Ergebnis des Rufes zu der Aufrufmethode zurück. Falls in Schritt 197 bestimmt wird, dass es keine Ausnahme gegeben hat, gibt die Prozesssteuerung einfach das Ergebnis des Rufes zu der Aufrufmethode zurück.
  • Bezug nehmend als Nächstes auf 10 wird die Aufrufmethode einer Clientdarstellung in Übereinstimmung mit einer Ausführungsform der Erfindung beschrieben. D.h. mit Bezug auf 9, Schritt 196, wird der Schritt zum Rufen einer Aufrufmethode für die Clientdarstellung detailliert beschrieben. Der Prozess beginnt in Schritt 201, wo der entfernte Stub die Aufrufmethode der Clientdarstellung unter Verwendung von Deskriptoren, nämlich den Methodendeskriptor, den Aufrufdeskriptor, die Parameterspeicherstellendeskriptoren und den Ausnahmespeicherstellendeskriptor, als Argumente ruft. Mit anderen Worten ruft der entfernte Stub einen geeigneten Subkontrakt unter Verwendung von Deskriptoren als Argumente auf. In Schritt 202 wird ein Transport ausgewählt. Falls ein Subkontrakt nur einen Transport unterstützt, wird dieser Transport ausgewählt. Falls der Subkontrakt viele Transporte hat, sieht eine Metrik, die mit den Transporten in Verbindung steht, Information vor, die den am meisten geeigneten Transport spezifiziert, der auszuwählen ist. Sobald ein Transport ausgewählt wurde, bewegt sich die Prozesssteuerung zu einem Schritt 204, in dem ein Endpunkt basierend auf einer Zielobjektreferenz identifiziert wird. Ein Endpunkt ist eine "Luke", oder Verbindung, die verwendet wird, um Aufrufe zu empfangen und Nachrichten zu senden. Eine CORBA-Objektreferenz kann einen Zeiger zu einem anderen Objekt enthalten, und wurde zuvor mit Bezug auf 2 beschrieben. Der Objektschlüssel in der Objektreferenz identifiziert, wie zuvor mit Bezug auf 2 beschrieben, das Zielobjekt, oder das Objekt, das das Ziel einer Anforderung ist. Die Identifikation eines Endpunktes kann entweder in der Transportschicht eines Clients oder in der Subkontraktschicht des Clients geschehen. Nachdem ein Endpunkt identifiziert ist, fährt die Prozesssteuerung zu Schritt 206 fort, wo ein Aufstellungspuffer erstellt wird, der für den in Schritt 202 gewählten Transport geeignet ist. Dies geschieht in der Transportschicht der Clientseite. Ein Aufstellungspuffer ist im wesentlichen ein Netzpuffer, der Information kapselt, die zu transportieren ist, und hat die Fähigkeit zum Kodieren atomarer Daten, die für einen Transport geeignet sind. Ein Aufstellungspuffer hat einen Identifikator oder ein. Tag, der/das das Kodierungsformat von Information spezifiziert, die von dem Aufstellungspuffer aufzustellen oder abzustellen ist. Ein Subkontrakt ist dank des Identifikators in der Lage, den Aufstellungspuffer zu identifizieren, der für den gewählten Transport geeignet ist.
  • Nachdem der Aufstellungspuffer, der für den ausgewählten Transport geeignet ist, erstellt ist, werden in Schritt 208 die Zielobjektreferenz und die Operation, oder Methodenbeschreibung, aufgestellt. In diesem Schritt werden nur die Abschnitte der Objektreferenz, die nicht anderweitig abgeleitet werden können, aufgestellt. In Schritt 209 wird, falls ein Kontext verwendet wird, der Kontext aufgestellt. Es wird nur die Information in dem Kontext ausgesucht, die für die Aufrufmethode interessant ist. Von dem Schritt zum Aufstellen des Kontexts bewegt sich die Prozesssteuerung zu Schritt 210, wo Argumente unter Verwendung von Deskriptoren aufgestellt werden. In dem Fall, dass die Objektreferenz als eines der Argumente weitergegeben wurde, kann sie unter Verwendung von Information aufgestellt werden, die durch die Argumentobjektreferenz vorgesehen wird. Der Prozess zum Aufstellen von Argumenten unter Verwendung von Deskriptoren wird nachstehend mit Bezug auf 11 beschrieben. Es sollte erkannt werden, dass Schritt 209, der Schritt zum Aufstellen des Kontexts, entweder vor Schritt 210 (wie gezeigt), dem Schritt zum Aufstellen von Argumenten unter Verwendung von Deskriptoren, oder nach Schritt 210 geschehen kann. In einigen Fällen, wenn kein Kontext verwendet wird, kann Schritt 209 überhaupt nicht auftreten, da es eindeutig nicht notwendig ist, einen Kontext aufzustellen, falls ein Kontext nicht verwendet wird.
  • Nachdem der Kontext, falls verwendet, und die Argumente aufgestellt sind, fährt die Prozesssteuerung zu Schritt 212 fort, wo der Inhalt des Aufstellungspuffers über den ausgewählten Transport zu dem identifizierten Endpunkt übertragen wird. Für die meisten ausgewählten Transporte hat dieser Schritt Senden des Inhalts in dem Aufstellungspuffer über eine Leitung zur Folge. Übertragungsschritt 212 kann als der Schritt zum Kommunizieren von dem Client zu dem Server interpretiert werden. Vom Übertragungsschritt 212 bewegt sich die Prozesssteuerung zu Schritt 214, wo der Client auf eine Ant wort von dem Server wartet. In einem Schritt 216 empfängt der Client eine Antwort von dem Server. Nachdem der Client eine Antwort von dem Server empfängt, fährt die Prozesssteuerung zu Schritt 218 fort, wo die Antwort, die von dem Server empfangen wird, in einen Aufstellungspuffer gekapselt wird. Falls die Antwort größer als die Anforderung ist, kann ein neuer Aufstellungspuffer erstellt werden, um die Antwort zu kapseln. Falls jedoch die Antwort nicht größer als die Anforderung ist, kann der Aufstellungspuffer, der in Schritt 206 erstellt wird, verwendet werden, um die Antwort in Schritt 218 zu kapseln. Es sollte erkannt werden, dass der Schritt zum Kapseln der Antwort in der Transportschicht geschieht.
  • Sobald die Antwort in einem Aufstellungspuffer gekapselt ist, fährt die Prozesssteuerung zu Schritt 220 fort, wo ein transportspezifischer Header aus der Antwort, die in dem Aufstellungspuffer gekapselt ist, abgestellt wird. Ein transportspezifischer Header enthält Information, die den in Schritt 202 ausgewählten Transport betrifft. Andere Header inkludieren Header, die Argumente und Header identifizieren, die Anforderungsidentifikatoren spezifizieren. Es kann ein Zeiger, der mit dem Aufstellungspuffer in Verbindung steht, verwendet werden, um den Beginn und das Ende eines Headers zu bestimmen. Dieser Zeiger bewegt sich von Byte zu Byte in dem Aufstellungspuffer. Nachdem der transportspezifische Header aus der Antwort abgestellt ist, fährt die Prozesssteuerung zu Schritt 222 fort, wo Argumente unter Verwendung von Deskriptoren von dem ursprünglichen Ruf abgestellt werden. Schritt 222 wird nachstehend mit Bezug auf 12A erörtert. Nachdem die Argumente unter Verwendung von Deskriptoren abgestellt sind, kehrt der Prozess zu dem entfernten Stub zurück.
  • Bezug nehmend als Nächstes auf 11 wird eine Methode zum Aufstellen von Argumenten unter Verwendung von Deskriptoren, d.h. Schritt 210 von 10, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung beschrieben. Der Argumentaufstellungsschritt 210 von 10 kann betrachtet werden, der Prozess zum generischen Aufstellen von Argumenten unter Verwendung von Deskriptoren zu sein, da dieser Prozess zum Aufrufen der geeigneten Aufstellungsroutine basierend darauf verantwortlich ist, ob der Aufrufpfad statisch, d.h. kompiliert, oder dynamisch ist. Bezug nehmend zurück auf 11 ist der erste Schritt, der mit generischem Aufstellen von Argumenten unter Verwendung von Deskriptoren involviert ist, Schritt 1100, in dem bestimmt wird, ob der Aufrufpfad statisch oder dynamisch ist. Speziell wird in dieser Ausführungsform in Schritt 1100 eine Bestimmung bezüglich dessen durchgeführt, ob das Kompilierungsflag des Aufrufdeskriptors auf wahr gesetzt ist. Falls bestimmt wird, dass das Kompilierungsflag auf wahr gesetzt ist, ist die Anzeige, dass der Aufrufpfad statisch ist, und die Prozesssteuerung fährt zu Schritt 1102 fort, wo ein Zähler i anfangs auf Null gesetzt wird, und wo bestimmt wird, ob der Wert des Zählers i größer oder gleich der Argumentzahl ist. Die Argumentzahl wird als ein Argument weitergegeben. Sie ist gewöhnlich entweder IN_DESC_COUNT oder OUT_DESC_COUNT, die zuvor mit Bezug auf den Aufrufdeskriptor von 4 beschrieben wurden. Die Argumentzahl repräsentiert die Gesamtzahl von Parametern, auf die durch den Parameterdeskriptor gezeigt wird, der als ein Argument hinein weitergegeben wird. Für jeden Parameter i, wird Schritt 1104, wo die Aufstellungsmethode, die für Parameter i geeignet ist, aufgerufen wird unter Weitergabe von Argumenten, die einen zugehörigen Aufstellungspuffer und die Adresse für Parameter i inkludieren, bereitgestellt durch den Parameterspeicherstellendeskriptor, wiederholt. Die Adresse für Parameter i wird durch die Zeiger zu Parameteradresslisten identifiziert, die Teile des Rufes sind, um eine Methode aufzurufen, wie oben mit Bezug auf 17 beschrieben. Da es eine Parameteradressliste für In-Parameter und eine Parameteradressliste für Aus-Parameter gibt, hängt die Liste, die zu dieser Methode weitergegeben wird, davon ab, ob "In"-Argumente in dem Client aufgestellt werden oder "Aus"-Argumente in dem Server aufgestellt werden. Die Prozesssteuerung bildet eine Schleife zwischen Schritt 1102, dem Schritt zum Bestimmen, ob alle Parameter verarbeitet wurden, und Schritt 1104, dem Schritt zum Aufrufen der Aufstellungsmethode, die für Parameter i geeignet ist, bis alle Parameter verarbeitet wurden. Sobald alle Parameter verarbeitet wurden, d.h. Zähler i gleich der Argumentzahl ist, fährt die Prozesssteuerung zu Schritt 1110 fort, wo bestimmt wird, ob eine Ausnahme durch beliebige der Rufe, um eine Aufstellungsmethode aufzurufen, geworfen wurde.
  • Falls die Bestimmung in Schritt 1100 durchgeführt wird, dass das Kompilierungsflag nicht auf wahr gesetzt ist, ist die Folgerung, dass der Aufrufpfad dynamisch ist. Nach der Bestimmung, dass der Aufrufpfad dynamisch ist, fährt die Prozesssteuerung zu Schritt 1106 fort, wo ein Zähler i anfangs auf Null gesetzt wird, und in dem bestimmt wird, ob der Wert von Zähler i größer oder gleich der Argumentzahl ist. Die Argumentzahl repräsentiert die Gesamtzahl von Parametern, auf die durch den Parameterdeskriptor gezeigt wird, der als ein Argument hinein weitergegeben wird. Die Argumentzahl ist gewöhnlich die IN_DESC_COUNT oder die OUT_DESC_COUNT eines Aufrufdeskriptors. Ein Schritt 1108, in dem die Typcode-Aufstellungsroutine unter Weitergabe von Argumenten inkludierend einen Typcode, der mit Parameter i in Verbindung steht, den zugehörigen Aufstellungspuffer und die Adresse für Parameter i, aufgerufen wird, wird für jeden Parameter i wiederholt. Im allgemeinen kann die Typcode-Aufstellungsroutine durch einen Typcode-Interpreter implementiert werden. Typcode kann in sowohl Parameterdeskriptoren als auch Ausnahmedeskriptoren gefunden werden, wohingegen die Adresse für Parameter i durch die Zeiger auf Parameteradresslisten identifiziert wird, die Teile des Rufes sind, um eine Methode aufzurufen, wie oben mit Bezug auf 7 beschrieben. Da es eine Parameteradressliste für In-Parameter und eine Parameteradressliste für Aus-Parameter gibt, hängt die Liste, die zu dieser Methode weitergegeben wird, davon ab, ob "In"-Argumente in dem Client aufgestellt werden oder "Aus"-Argumente in dem Server aufgestellt werden. Die Prozesssteuerung bildet eine Schleife zwischen Schritt 1106, dem Schritt zum Bestimmen, ob alle Argumente verarbeitet wurden, und Schritt 1108, dem Schritt zum Aufrufen der Typcode-Aufstellungsroutine, bis Zähler i die Argumentzahl überschreitet, wobei dadurch angezeigt wird, dass alle Parameter verarbeitet wurden. Wenn bestimmt wird, dass alle Parameter verarbeitet wurden, fährt die Prozesssteuerung zu Schritt 1110 fort, in dem bestimmt wird, ob eine Ausnahme durch beliebige der Rufe, um eine Aufstellungsmethode aufzurufen, geworfen wurde.
  • Falls in Schritt 1110 bestimmt wird, dem Schritt zum Bestimmen, ob eine Ausnahme durch beliebige der Rufe geworfen wurde, um eine Aufstellungsmethode aufzurufen, dass keine Ausnahmen geworfen wurden, ist der Prozess zum Aufstellen von Argumenten unter Verwendung von Deskriptoren, d.h. Schritt 210 von 10, fertig. Falls bestimmt wird, dass eine Ausnahme geworfen wurde, bewegt sich die Prozesssteuerung zu Schritt 1112, wo eine Bestimmung bezüglich dessen durchgeführt wird, ob der Ausnahmerückgabezeiger Null ist. D.h. Schritt 112 ist die Bestimmung davon, ob es geeignet ist, eine Aufstellungsausnahme zu werfen. Falls der Ausnahmerückgabezeiger, der in einer vorherigen Erörterung eines Rufes, um eine Methode aufzurufen, erwähnt wurde, Null ist, ist die Anzeige, dass eine spezifische Aufstellungsausnahme zu dem Rufer geworfen werden kann. Falls dies der Fall ist, bewegt sich die Prozesssteuerung von Schritt 1112, dem Schritt zum Bestimmen, der Ausnahmezeiger Null ist, zu Schritt 1114, wo eine spezifische Aufstellungsausnahme geworfen wird. Falls der Ausnahmerückgabezeiger nicht Null ist, fährt die Prozess steuerung zu Schritt 1116 fort, wo Speicher für eine Aufstellungsausnahme zugeordnet wird, und die Ausnahme wird initialisiert. Dann wird in Schritt 1118 die Adresse der Ablage, oder des Speichers, zugeordnet in Schritt 1116, dem Zeiger zugewiesen, auf den durch den Ausnahmerückgabezeiger gezeigt wird. Nachdem Schritt 1118 abgeschlossen ist, ist der Prozess zum Aufstellen von Argumenten unter Verwendung von Deskriptoren fertig.
  • Es sollte erkannt werden, dass eine generische Aufstellungsroutine durch sowohl die Clientseite als auch die Serverseite eines verteilten Objektsystems gemeinsam genutzt wird. Wenn von der Clientseite gerufen, werden IN_PARAM, IN_DESC und IN_DESC_COUNT als Argumente weitergegeben. Wenn von der Serverseite gerufen, werden ähnlich OUT_PARAM, OUT_DESC und OUT_DESC_COUNT als Argumente weitergegeben. Ferner sollte erkannt werden, dass viele generische Aufstellungsroutinen existieren können. Als ein Beispiel kann eine generische Aufstellungsroutine existieren, um Argumente in einer umgekehrten Reihenfolge aufzustellen. Die Unterschiede zwischen kompilierter und Typcode-interpretierter Aufstellung sind jedoch nur innerhalb der generischen Aufstellungsroutine bekannt.
  • Bezug nehmend als Nächstes auf 12A wird eine Methode zum Abstellen von Argumenten unter Verwendung von Deskriptoren in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung beschrieben. D.h. es wird Schritt 222 von 10 untersucht. Der Prozess zum Abstellen von Argumenten unter Verwendung von Deskriptoren beginnt in Schritt 1201, wo bestimmt wird, ob durch den Server eine Ausnahme verursacht wurde. Falls durch den Server eine Ausnahme nicht verursacht wurde, fährt die Prozesssteuerung zu Schritt 1202 fort, wo eine Reinitialisierungsfunktion gerufen wird, um zuvor verwendeten Speicher aufzufrischen. Nachdem die Reinitialisierungsfunktion gerufen ist, bewegt sich die Prozesssteuerung zu Schritt 1203, wo ein Ruf zu einer generischen Abstellungsroutine durchgeführt wird. Es sollte erkannt werden, dass die generische Abstellungsroutine durch sowohl die Clientseite als auch die Serverseite eines verteilten Objektsystems verwendet wird. Der Prozess zum Ausführen einer generischen Abstellungsroutine wird nachstehend mit Bezug auf 12B erörtert.
  • Falls bestimmt wird, dass in Schritt 1201 eine Ausnahme durch den Server verursacht wurde, werden der Ausnahmetyp, Identifikator (ID) und Schlüssel aus Information in dem Aufstellungspuffer in Schritt 1204 bestimmt. Der Ausnahmetyp, Identifikator und Schlüssel können durch eine beliebige Zahl von Verfahren bestimmt werden. Als ein Beispiel können, wie durch einen Fachmann erkannt wird, "Späh"-Methoden in dem Aufstellungspuffer verwendet werden. Nachdem Ausnahmetyp, Identifikator und Schlüssel bestimmt sind, wird in Schritt 1206 bestimmt, ob die Ausnahme, die durch den Server verursacht wird, eine vordefinierte Systemausnahme oder eine benutzerdefinierte Ausnahme ist. Falls die Ausnahme eine benutzerdefinierte Ausnahme ist, wird in Schritt 1260 ein Ruf zu einer Benutzerausnahmeroutine durchgeführt. Die Schritte, die mit der Ausführung einer benutzerdefinierten Ausnahmeroutine involviert sind, werden nachstehend mit Bezug auf 12C beschrieben.
  • Falls in Schritt 1206 die Ausnahme bestimmt wird, eine vordefinierte Systemausnahme zu sein, bewegt sich die Prozesssteuerung zu Schritt 1208, der die Bestimmung davon ist, ob der Ausnahmerückgabezeiger Null ist. Die Bestimmung davon, ob der Ausnahmerückgabezeiger Null ist, kann als eine Bestimmung davon betrachtet werden, ob es schließlich notwendig sein wird, Speicher für eine Ausnahme zuzuordnen, die abzustellen ist. Falls der Ausnahmerückgabezeiger Null ist, fährt die Prozesssteuerung zu Schritt 1210 fort, wo ein Systemausnahmedeskrip torrepository, welches eine Auflistung aller Systemausnahmen enthalten kann, nach einem übereinstimmenden Schlüssel durchsucht wird. Das Systemdeskriptorrepository ist eine systemweite EXCEPTION_DESC, d.h. eine Liste von Zeigern zu Ausnahmedeskriptoren, die jede Systemausnahme beschreiben. Nach einer Suche nach einem übereinstimmenden Schlüssel wird in Schritt 1212 eine Bestimmung bezüglich dessen durchgeführt, ob eine Schlüsselübereinstimmung für den Schlüssel gefunden wurde, der aus Information in dem Aufstellungspuffer bestimmt ist. Falls eine Schlüsselübereinstimmung nicht gefunden wurde, wird eine Ausnahme geworfen, die anzeigt, dass eine Systemausnahme nicht gefunden wurde, und der Prozess zum Abstellen von Argumenten unter Verwendung von Deskriptoren wird als abgeschlossen betrachtet. Falls eine Schlüsselübereinstimmung für den Schlüssel gefunden wurde, der aus Information in dem Aufstellungspuffer bestimmt ist, wird in Schritt 1214 der Ausnahmeidentifikator (ID) mit dem Identifikator (ID) verglichen, der mit dem passenden Schlüssel in Verbindung steht. Mit anderen Worten wird ein Vergleich zwischen dem ID entsprechend dem Schlüssel, der in dem Systemausnahmedeskriptorrepository gefunden wird, und dem Ausnahme-ID, der aus Information in dem Aufstellungspuffer in Schritt 1204 bestimmt wird, durchgeführt.
  • Nachdem der Ausnahme-ID mit dem ID verglichen ist, der mit dem passenden Schlüssel in Verbindung steht, bewegt sich die Prozesssteuerung zu Schritt 1216, wo bestimmt wird, ob der Vergleich des Ausnahme-ID mit dem ID, der mit dem passenden Schlüssel in Verbindung steht, positiv ist. D.h. es wird bestimmt, ob der Ausnahme-ID und der ID, der mit dem passenden Schlüssel in Verbindung steht, konsistent sind. Falls der Ausnahme-ID und der ID, der mit dem passenden Schlüssel in Verbindung steht, tatsächlich übereinstimmen, wird die Wurffunktion, die mit dem passenden Schlüssel in Verbindung steht, mit dem Zeiger zu dem Aufstellungspuffer, der in einem Schritt 1222 hinein weitergegeben wird, gerufen. In einer C++-Umgebung stellt die Wurffunktion die Daten ab, die mit der Ausnahme in Verbindung stehen, und wirft die Ausnahme. Wurffunktionen wurden oben mit Bezug auf 6 beschrieben. Sobald die Wurffunktion, die mit dem passenden Schlüssel in Verbindung steht, gerufen ist, ist der Prozess zum Abstellen von Argumenten unter Verwendung von Deskriptoren abgeschlossen. Falls in Schritt 1216 bestimmt wird, dass der Ausnahme-ID und der ID, der mit dem passenden Schlüssel in Verbindung steht, nicht übereinstimmen, wird in Schritt 1218 das Systemausnahmedeskriptorrepository nach einer anderen Schlüsselübereinstimmung durchsucht. Die Prozesssteuerung kehrt dann zu Schritt 1212 zurück und der Bestimmung, ob eine Schlüsselübereinstimmung gefunden ist.
  • Falls die Bestimmung zurück in Schritt 1208 durchgeführt wird, dass der Ausnahmerückgabezeiger nicht Null ist, wird in Schritt 1240 eine Suche nach einem übereinstimmenden Schlüssel in dem Systemausnahmedeskriptorrepository durchgeführt. Dann wird in Schritt 1242 eine Bestimmung bezüglich dessen durchgeführt, ob eine Schlüsselübereinstimmung gefunden wurde. Falls eine Schlüsselübereinstimmung nicht gefunden wurde, wird in Schritt 1250 Speicher zugeordnet um anzuzeigen, dass eine Systemausnahme nicht gefunden wurde. Daher wird eine zugeordnete Ausnahme erstellt. Die zugeordnete Ausnahme wird dann über den Ausnahmerückgabezeiger in Schritt 1252 zurückgegeben. D.h. es wird die Adresse vom Speicher, der der Ausnahme zugeordnet ist, zurückgegeben, und der Prozess zum Abstellen von Argumenten unter Verwendung von Deskriptoren ist abgeschlossen.
  • Falls in Schritt 1242 eine Schlüsselübereinstimmung gefunden wurde, bewegt sich die Prozesssteuerung zu Schritt 1244, in dem der Ausnahmeidentifikator (ID) mit dem Identifikator (ID) verglichen wird, der mit dem passenden Schlüssel in Verbin dung steht. Von Schritt 1244 bewegt sich die Prozesssteuerung zu Schritt 1246, wo bestimmt wird, ob der Vergleich des Ausnahme-ID mit dem ID, der mit dem passenden Schlüssel in Verbindung steht, zu einer Übereinstimmung führt. Falls der Ausnahme-ID und der ID, der mit dem passenden Schlüssel in Verbindung steht, nicht übereinstimmen, wird das Systemausnahmedeskriptorrepository nach einer anderen Schlüsselübereinstimmung in Schritt 1248 durchsucht. Sobald das Systemausnahmedeskriptorrepository nach einer anderen Schlüsselübereinstimmung durchsucht ist, kehrt die Prozesssteuerung zu Schritt 1242 zurück, wo bestimmt wird, ob eine andere Schlüsselübereinstimmung gefunden wurde. Falls der Ausnahme-ID und der ID, der mit dem passenden Schlüssel in Verbindung steht, tatsächlich übereinstimmen, wird in Schritt 1254 für die Ausnahme, die abzustellen ist, Speicher zugeordnet. Dann wird in Schritt 1255 bestimmt, ob der Zeiger zu der Abstellungsfunktion, die mit dem gefundenen Ausnahmedeskriptor in Verbindung steht, Null ist. Falls der Zeiger Null ist, ist die Folgerung, dass die Abstellungsfunktion, die aufzurufen ist, dynamisch oder Typcode-basiert ist. In Schritt 1258 wird die Typcode-basierte Abstellungsroutine gerufen, unter Weitergabe des zugehörigen Ausnahme-Typcodes, des zugehörigen Aufstellungspuffers und der Adresse des zugeordneten Speichers. Es sollte erkannt werden, dass der zugehörige Ausnahme-Typcode aus dem Ausnahmedeskriptorrepository gefunden werden kann. Nachdem die Abstellungsroutine in Schritt 1258 gerufen ist, fährt die Steuerung zu Schritt 1252 fort, wo die zugeordnete Ausnahme über den Ausnahmerückgabezeiger zurückgegeben wird, und der Prozess zum Abstellen von Argumenten unter Verwendung von Deskriptoren abgeschlossen ist. Falls der Zeiger zu der Abstellungsfunktion nicht Null ist, dann ist die Abstellungsfunktion, die zu rufen ist, statisch oder kompiliert. In Schritt 1256 wird ein Ruf zu der Abstellungsfunktion durchgeführt, die mit dem passenden Schlüssel in Verbindung steht, und der Zeiger zu dem zugehörigen Aufstellungspuffer wird als ein Argument weitergegeben. Nach dem Ruf zu der Abstellungsfunktion fährt die Prozesssteuerung zu Schritt 1252 fort, in dem eine zugeordnete Ausnahme über den Ausnahmerückgabezeiger zurückgegeben wird.
  • Bezug nehmend auf 12B wird eine Methode zum generischen Abstellen von Argumenten unter Verwendung von Deskriptoren, d.h. Schritt 1203 von 12A, in Übereinstimmung mit einer Ausführungsform der Erfindung beschrieben. Die Methode zum generischen Abstellen von Argumenten unter Verwendung von Deskriptoren trifft auch auf Schritt 1510 von 15 zu, was nachstehend erörtert wird. Der erste Schritt, der mit generischem Abstellen von Argumenten unter Verwendung von Deskriptoren involviert ist, ist Schritt 1130, wo eine Bestimmung bezüglich dessen durchgeführt wird, ob das Kompilierungsflag des Aufrufdeskriptors auf wahr gesetzt ist. Falls bestimmt wird, dass das Kompilierungsflag auf wahr gesetzt ist, ist die Anzeige, dass der Aufrufpfad statisch ist, und die Prozesssteuerung fährt zu Schritt 1132 fort, wo ein Zähler i anfangs auf Null gesetzt wird, und wo bestimmt wird, ob der Wert von Zähler i größer oder gleich der Argumentzahl ist. Die Argumentzahl zeigt die Zahl von Argumenten oder Parametern an, die abzustellen sind. Für jeden Parameter i wird Schritt 1134, in dem die Abstellungsmethode, identifiziert durch den Parameterdeskriptor, der hinein weitergegeben wird, geeignet für Parameter i unter Weitergabe von Argumenten aufgerufen wird, die einen zugehörigen Aufstellungspuffer und die Adresse für Parameter i inkludieren, wiederholt. Die Adresse für Parameter i wird durch die Zeiger zu Parameteradresslisten identifiziert, die Teile des Rufes sind, um eine Methode auf zurufen, wie oben mit Bezug auf 7 beschrieben wird. Es sollte erkannt werden, dass die Begriffe "Parameterspeicherstellendeskriptor" und "Parameteradressliste" austauschbar verwendet werden können. Die Prozesssteuerung bildet eine Schleife zwischen Schritt 1132, dem Schritt zum In krementieren von Zähler i und Bestimmen, ob Zähler i größer oder gleich der Argumentzahl ist, und Schritt 1134, dem Schritt zum Aufrufen der Abstellungsmethode für Parameter i, bis alle Parameter verarbeitet wurden. Sobald alle Parameter verarbeitet wurden, fährt die Prozesssteuerung zu Schritt 1140 fort, wo bestimmt wird, ob eine Ausnahme durch beliebige der Rufe, um eine Abstellungsmethode aufzurufen, geworfen wurde.
  • Falls die Bestimmung in Schritt 1130 durchgeführt wird, dass das Kompilierungsflag nicht auf wahr gesetzt ist, ist die Folgerung, dass der Aufrufpfad dynamisch, d.h. Typcode-interpretiert ist. Falls das Kompilierungsflag nicht auf wahr gesetzt ist, fährt die Prozesssteuerung zu Schritt 1136 fort, wo ein Zähler i inkrementiert wird und eine Bestimmung bezüglich dessen durchgeführt wird, ob Zähler i größer oder gleich der Argumentzahl ist. Mit anderen Worten inkrementiert Schritt 1136 einen Zähler i und bestimmt, ob es beliebige Parameter gibt, die zu verarbeiten bleiben. Für jeden Parameter i wird Schritt 1138, wo die Typcode-Abstellungsroutine unter Weitergabe von Argumenten inkludierend Typcode, der mit Parameter i in Verbindung steht, den zugehörigen Aufstellungspuffer und die Adresse für Parameter i aufgerufen wird, wiederholt, bis keine Parameter zu verarbeiten bleiben. Typcode kann in sowohl Parameterdeskriptoren als auch Ausnahmedeskriptoren gefunden werden, wohingegen die Adresse für Parameter i, der hinein weitergegeben wird, als Zeiger zu Parameteradresslisten verwendend identifiziert wird, wie zuvor beschrieben. Wenn bestimmt ist, dass alle Parameter verarbeitet wurden, fährt die Prozesssteuerung zu Schritt 1140 fort, wo bestimmt wird, ob eine Ausnahme geworfen wurde.
  • In Schritt 1140 wird bestimmt, ob eine Ausnahme durch beliebige der Rufe, um eine Abstellungsmethode aufzurufen, geworfen wurde. Falls keine Ausnahmen geworfen wurden, ist der Prozess zum Abstellen von Argumenten unter Verwendung von Deskriptoren abgeschlossen. Falls bestimmt wird, dass eine Ausnahme geworfen wurde, bewegt sich die Prozesssteuerung zu Schritt 1142, wo eine Bestimmung bezüglich dessen durchgeführt wird, ob der Ausnahmerückgabezeiger Null ist. Falls der Ausnahmerückgabezeiger Null ist, ist die Anzeige, dass eine spezifische Abstellungsausnahme geworfen sein kann. Falls dies der Fall ist, wird in Schritt 1144 eine spezifische Abstellungsausnahme geworfen. Falls in Schritt 1142 bestimmt wird, dass der Ausnahmerückgabezeiger nicht Null ist, fährt die Prozesssteuerung zu Schritt 1146 fort, in dem Speicher für eine Abstellungsausnahme zugeordnet wird. Dann wird in Schritt 1148 die Adresse der Ablage, oder des Speichers, zugeordnet in Schritt 1146, dem Zeiger zugewiesen, auf den durch den Ausnahmerückgabezeiger gezeigt wird. Nach Schritt 1148 ist der Prozess zum Abstellen von Argumenten unter Verwendung von Deskriptoren abgeschlossen.
  • Bezug nehmend als Nächstes auf 12C wird der Prozess einer Benutzerausnahmeroutine, d.h. Schritt 1260 von 12A, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung beschrieben. Der Prozess beginnt in Schritt 1268, der die Bestimmung davon ist, ob der Ausnahmerückgabezeiger Null ist. Falls der Ausnahmerückgabezeiger Null ist, fährt die Prozesssteuerung zu Schritt 1270 fort, in dem das Benutzerausnahmedeskriptorrepository nach einem übereinstimmenden Schlüssel durchsucht wird. Das Benutzerausnahmedeskriptorrepository ist eine Liste von Zeigern auf Ausnahmedeskriptoren, die Benutzerausnahmen beschreiben, die mit einer Methode in Verbindung stehen, und wird von einem zugehörigen Aufrufdeskriptor erhalten. In Schritt 1272 wird eine Bestimmung bezüglich dessen durchgeführt, ob eine Schlüsselübereinstimmung von der Suche des Benutzerausnahmerepository gefunden wurde. Falls eine Schlüsselübereinstimmung nicht gefunden wurde, wird eine Ausnahme geworfen, die anzeigt, dass eine Benutzer ausnahme in dem Benutzerausnahmerepository nicht gefunden wurde, und der Prozess zum Abstellen von Argumenten unter Verwendung von Deskriptoren ist abgeschlossen. Falls eine Schlüsselübereinstimmung gefunden wurde, wird in Schritt 1274 der Ausnahmeidentifikator (ID) mit dem Identifikator (ID), der mit dem passenden Schlüssel in Verbindung steht, verglichen. Nachdem ein Vergleich zwischen dem Ausnahme-ID und dem ID, der mit dem passenden Schlüssel in Verbindung steht, durchgeführt ist, bewegt sich die Prozesssteuerung zu Schritt 1276, wo bestimmt wird, ob der Vergleich des Ausnahme-ID mit dem ID, der mit dem passenden Schlüssel in Verbindung steht, zu einer Übereinstimmung führt. Falls der Ausnahme-ID und der ID, der mit dem passenden Schlüssel in Verbindung steht, eine Übereinstimmung sind, wird die Wurffunktion, die mit dem passenden Schlüssel in Verbindung steht, mit dem Zeiger zu dem Aufstellungspuffer, der weitergegeben wird, in Schritt 1282 gerufen. Wurffunktionen wurden oben mit Bezug auf 6 beschrieben. Sobald eine Wurffunktion gerufen wurde, ist der Prozess zum Abstellen von Argumenten unter Verwendung von Deskriptoren abgeschlossen. Falls in Schritt 1276 bestimmt wird, dass der Ausnahme-ID und der ID, der mit dem passenden Schlüssel in Verbindung steht, nicht übereinstimmen, wird in einem Schritt 1278 das Benutzerausnahmedeskriptorrepository nach einer anderen Schlüsselübereinstimmung durchsucht. Die Prozesssteuerung bildet dann eine Schleife zurück zu Schritt 1272, wo bestimmt wird, ob eine Schlüsselübereinstimmung gefunden ist.
  • Bezug nehmend zurück zu Schritt 1268, wo bestimmt wird, ob der Ausnahmerückgabezeiger Null ist, wird, falls die Bestimmung durchgeführt wird, dass der Ausnahmerückgabezeiger nicht Null ist, in Schritt 1284 eine Suche nach einem übereinstimmenden Schlüssel in dem Benutzerausnahmedeskriptorrepository durchgeführt. Dann wird in Schritt 1286 eine Bestimmung bezüglich dessen durchgeführt, ob eine Schlüsselübereinstimmung gefunden wurde. Falls eine Schlüsselübereinstimmung nicht gefunden wurde, wird in Schritt 1293 Speicher zugeordnet und initialisiert um anzuzeigen, dass eine Benutzerausnahme nicht gefunden wurde, und für eine Aufstellungsausnahme wird Speicher zugeordnet. In Schritt 1291 wird eine zugeordnete Ausnahme über den Ausnahmerückgabezeiger zurückgegeben, und der Prozess zum Abstellen von Argumenten unter Verwendung von Deskriptoren ist abgeschlossen.
  • Falls in Schritt 1286 eine Schlüsselübereinstimmung gefunden wurde, bewegt sich die Prozesssteuerung zu Schritt 1288, in dem der Ausnahme-ID mit dem ID, der mit dem passenden Schlüssel in Verbindung steht, verglichen wird. Von dem Vergleichsschritt 1288 bewegt sich die Prozesssteuerung zu Schritt 1290, wo bestimmt wird, ob der Vergleich des Ausnahme-ID mit dem ID, der mit dem passenden Schlüssel in Verbindung steht, zu einer Übereinstimmung führt. Falls der Ausnahme-ID und der ID, der mit dem passenden Schlüssel in Verbindung steht, nicht übereinstimmen, wird in Schritt 1292 das Benutzerausnahmedeskriptorrepository nach einer anderen Schlüsselübereinstimmung durchsucht. Nach einer Suche nach einer anderen Schlüsselübereinstimmung kehrt die Prozesssteuerung zu Schritt 1286 zurück, wo bestimmt wird, ob eine Schlüsselübereinstimmung gefunden wurde. Falls in Schritt 1290 bestimmt wird, dass der Ausnahme-ID und der ID, der mit dem passenden Schlüssel in Verbindung steht, in der Tat übereinstimmen, wird in Schritt 1294 Speicher für die Ausnahme, die abzustellen ist, zugeordnet. Dann wird in Schritt 1295 bestimmt, ob der Zeiger zu der Abstellungsfunktion, die mit dem gefundenen Ausnahmedeskriptor in Verbindung steht, Null ist. Falls der Zeiger Null ist, wird in Schritt 1298 die Typcode-basierte Abstellungsroutine gerufen, wobei der zugehörige Ausnahme-Typcode, der zugehörige Aufstellungspuffer und die Adresse des zugeordneten Speichers weitergegeben werden. Nachdem die Typcode-basierte Abstellungsroutine gerufen ist, fährt die Prozesssteuerung zu Schritt 1291 fort, wo die zugeordnete Ausnahme über den Ausnahmerückgabezeiger zurückgegeben wird, und der Prozess zum Abstellen von Argumenten unter Verwendung von Deskriptoren ist abgeschlossen. Falls die Bestimmung in Schritt 1295 ist, dass der Zeiger zu der Abstellungsfunktion nicht Null ist, fährt die Prozesssteuerung zu Schritt 1296 fort, wo ein Ruf zu der Abstellungsfunktion durchgeführt wird, die mit dem passenden Schlüssel in Verbindung steht, und der Zeiger zu dem zugehörigen Aufstellungspuffer wird als ein Argument weitergegeben. Nachdem die Abstellungsfunktion gerufen ist, gibt die Prozesssteuerung eine zugeordnete Ausnahme über den Ausnahmerückgabezeiger in Schritt 1291 zurück, und der Prozess zum Abstellen von Deskriptoren ist abgeschlossen.
  • Es sollte erkannt werden, dass es viele Variationen von Aufstellungs- und Abstellungsroutinen gibt. Diese Variationen hängen von dem verwendeten Transport oder Protokoll ab. Gewöhnlich gibt es weniger Aufstellungs- und Abstellungsroutinen als es Transporte gibt. Die oben beschriebenen generischen Aufstellungs- und Abstellungsroutinen sind für die meisten Standardprotokolle geeignet, in denen Argumente von links nach rechts und in einer tiefenorientierten Reihenfolge innerhalb jedes Argumentes aufgestellt werden. Andere generische Routinen können Argumente von rechts nach links und in einer breitenorientierten Reihenfolge innerhalb jedes Argumentes aufstellen oder abstellen. Kompilierte Aufstellungs- und Abstellungsroutinen nehmen typischerweise eine tiefenorientierte Reihenfolge an, wohingegen Typcode-interpretierte Aufstellungs- und Abstellungsroutinen typischerweise eine breitenorientierte Reihenfolge annehmen. In den meisten Fällen sind die Unterschiede zwischen kompilierten und Typcodeinterpretierten Aufstellungs- und Abstellungsroutinen in den generische Routinen verborgen, wobei dadurch ermöglicht wird, dass Transport- und Subkontrakt-Codepfade die gleichen unge achtet dessen bleiben, ob kompilierte oder Typcode-interpretierte Aufstellung oder Abstellung verwendet wird. Als solches kann in den meisten Fällen der Aufruf als transportunabhängig betrachtet werden.
  • In einigen Fällen können Transporte Protokolle haben, die unterschiedliche Aufstellungs- und Abstellungsreihenfolgen zwischen Argumenten und innerhalb von jedem Datentyp erfordern. Daher können Transporte spezifische Aufstellungs- und Abstellungsroutinen nutzen, die für jedes Protokoll geeignet sind, da Information über eine bestimmte Methode in dem Aufrufdeskriptor verfügbar ist, was oben in Bezug auf 4 beschrieben wurde, der mit der Methode in Verbindung steht. Als ein Beispiel kann eine Aufstellungsreihenfolge von rechts nach links durch eine indexdekrementierende Schleife bewerkstelligt werden, im Gegensatz zu einer indexinkementierenden Schleife, die für eine Aufstellungsreihenfolge von links nach rechts verwendet wird, wie mit Bezug auf 11 beschrieben. Falls ein Standard, kompilierte tiefenorientierte Argumenten-Aufstellungs- und Abstellungsreihenfolge für einen gegebenen Transport oder Protokoll nicht geeignet ist, dann können andere Aufstellungs- und Abstellungsreihenfolgen, wie z.B. eine breitenorientierte Reihenfolge, unter Verwendung eines Typcode-Interpreters mit Typcode bewerkstelligt werden, da Typcode die vollständige Beschreibung, d.h. Struktur, eines Datentyps enthält. Mit anderen Worten werden in diesem Fall kompilierte Aufstellungs- und Abstellungsroutinen nicht verwendet, da unterschiedliche Typcode-Aufstellungs- und Abstellungsinterpreter verwendet werden. Falls generische Aufstellungs- und Abstellungsroutinen für einen gegebenen Transport nicht geeignet sind, ist deshalb ausreichend Information in den Deskriptoren verfügbar, sodass eine beliebige Aufstellungs- oder Abstellungskonvention implementiert werden kann, und der gesamte Aufrufprozess kann als transportunabhängig betrachtet werden.
  • In dem Fall von dynamischem Aufruf wird die gleiche Clientdarstellungs-Aufrufmethode gerufen, wie sie in dem Fall von statischem Aufruf gerufen würde, mit der Ausnahme, dass das dynamische Aufrufsystem typischerweise den Methodendeskriptor, Aufrufdeskriptor und andere zugehörige Deskriptoren aus Information aufbaut, die entweder durch einen Benutzer oder ein verfügbares Schnittstellenrepository bereitgestellt wird. Für dynamischen Aufruf werden nur Pflichtfelder in zugehörigen Ausnahmedeskriptoren und Parameterdeskriptoren vorgesehen.
  • Die Serverseite eines verteilten objektorientierten Systems antwortet auf Anforderungen, die in empfangenden Endpunkten empfangen werden. Die Serverseite überwacht empfangende Endpunkte kontinuierlich um zu bestimmen, wann eine Anforderung empfangen wird. Methoden, die mit dem Serveraufruf in Verbindung stehen, inkludieren eine konventionelle Konstruktormethode und eine konventionelle Destrukturmethode, die verwendet werden können, um ein Serveraufrufobjekt zu initialisieren und zu zerstören. Ein Serveraufrufobjekt wird nachstehend mit Bezug auf 14A beschrieben. Andere Methoden, die mit der Serverseite in Verbindung stehen, inkludieren eine Abstellungsmethode, eine Aufstellungsmethode und eine Aufstellungsausnahmemethode. Jede Methode hat einen zugehörigen Aufrufdeskriptor. Die Aufstellungsmethode ruft die generische Aufstellungsmethode, wie oben mit Bezug auf 11 beschrieben. Ähnlich ruft die Abstellungsmethode die generische Abstellungsmethode, wie oben mit Bezug auf 12 beschrieben. Die Aufstellungsausnahme sucht Argumente aus, die durch die generische Aufstellung aufgestellt werden.
  • Bezug nehmend als Nächstes auf 13A werden Schritte, die auf der Serverseite eines verteilten objektorientierten Systems auftreten, sobald eine Anforderung in einem bestimmten empfangenden Endpunkt empfangen wird, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung beschrieben. Der Prozess beginnt in Schritt 250, wo ein Aufstellungspuffer, der für die Anforderung spezifisch ist, erstellt wird, um die empfangene Anforderung zu kapseln. Der Typ vom erstellten Aufstellungspuffer basiert auf dem Endpunkt, der ein dedizierter Endpunkt oder ein Cluster-Endpunkt sein kann, wie oben mit Bezug auf 1b beschrieben wird. In Schritt 252 wird eine Abfertigungsroutine basierend auf dem Endpunkttyp und der Zielobjektreferenz ausgewählt. Der zugehörige Subkontrakt und Transport sind typischerweise Faktoren in der Auswahl einer Abfertigungsroutine. Nachdem eine Abfertigungsroutine ausgewählt ist, bewegt sich die Prozesssteuerung zu Schritt 254, wo die ausgewählte Abfertigungsroutine gerufen wird. Der Aufstellungspuffer, der in Schritt 250 erstellt wird, wird weitergegeben, zusammen mit einem "Cookie", in den Ruf zu einer geeigneten Abfertigungsroutine. Ein Cookie ist ein Zeiger zu einem Datenelement. Wenn eine Abfertigungsroutine gerufen wird, gibt es typischerweise einen Abschluss, der als Teil des Rufes hinein weitergegeben wird. Ein Abschluss enthält einen Zeiger zu einer Abfertigungsroutine und einen Cookie. Der Prozess zum Rufen, oder Ausführen, einer typischen Abfertigungsroutine wird nachstehend mit Bezug auf 13B detailliert erläutert. Der Ruf zu einer Abfertigungsroutine führt zu einer Antwort, die in dem Aufstellungspuffer gekapselt ist. Schließlich wird in Schritt 256 die Antwort in dem empfangenden Endpunkt übertragen.
  • Bezug nehmend als Nächstes auf 13B wird eine Methode zum Ausführen einer typischen Abfertigungsroutine in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung beschrieben. In Schritt 1300 wird Header-Information von dem Aufstellungspuffer abgestellt, falls Header-Information vorhanden ist. Der ausgewählte Transport, der verwendet wird, um eine Anforderung von dem Client zu dem Server weiterzuleiten, kann manchmal Header von dem Aufstellungspuffer entfernen. In Schritt 1302 werden Zielobjektreferenzdaten abgestellt. D.h. es wird auf ein beliebiges Element, das das aufzurufende Objekt identifiziert, zugegriffen. Dann wird in Schritt 1304 der Name der aufzurufenden oder zu rufenden Operation abgestellt. Von Schritt 1304 fährt die Prozesssteuerung zu Schritt 1306 fort, wo ein Operationsschlüssel erhalten oder aus dem Aufstellungspuffer abgestellt wird, und es wird ein geeigneter Methodendeskriptor erstellt. Es sollte erkannt werden, dass die Reihenfolge, in der Zielobjektreferenzdaten, der Operationsname und ein Operationsschlüssel abgestellt werden, nicht kritisch ist, da die Reihenfolge der Schritte von dem bestimmten Protokoll abhängt, das verwendet wird.
  • In Schritt 1308 wird ein Serveraufrufobjekt aufgebaut, das für den Subkontrakt und Transport, die mit der Abfertigungsroutine in Verbindung stehen, geeignet ist. Die Information, die benötigt wird, um ein Serveraufrufobjekt aufzubauen, ist die Information, die in den Schritten zum Abstellen von Zielobjektreferenzdaten, des Operationsnamen und eines Operationsschüssels gesammelt wird. Der Subkontrakt bestimmt implizit die geeignete Art des Serveraufrufobjektes, das zu erstellen ist. D.h. ein gegebener Subkontrakt wird stets bei einer Auswahl der Art vom Serveraufrufobjekt, das für den gleichen Transportendpunkt auf gebaut wird, oder Objekt konsistent sein. Die Struktur eines Serveraufrufobjektes wird nachstehend mit Bezug auf 14A erörtert, und die Schritte, die mit einem Aufbau eines Serveraufrufobjektes in Verbindung stehen, werden nachstehend mit Bezug auf 14B erörtert.
  • Nachdem das Serveraufrufobjekt in Schritt 1308 erstellt ist, bewegt sich die Prozesssteuerung zu Schritt 1310, wo ein Abfertigungsabschluss basierend auf den abgestellten Zielobjektreferenzdaten identifiziert wird. Es gibt viele Verfah ren, die verwendet werden können, um einen Abfertigungsabschluss zu identifizieren, inkludierend die Verwendung einer Hash-Tabelle oder eines Rufes zu durch einen Benutzer bereitgestellten Routinen. Der Abfertigungsabschluss kann unter Verwendung des Objektschüssels der Zielobjektreferenz als ein Schlüssel "nachgeschaut", d.h. identifiziert werden. Es sollte erkannt werden, dass ein zugehöriger Subkontrakt und Transport gewöhnlich Faktoren bei der Auswahl einer Abfertigungsroutine sind. Der identifizierte Abfertigungsabschluss, oder Abfertigungsroutine, hat einen Zeiger zu einer Skelettabfertigungsfunktion und einen Cookie, der in diesem Fall ein Zeiger zu einem Servant ist.
  • In Schritt 1312 wird der identifizierte Abfertigungsabschluss, und deshalb das identifizierte Skelett, mit einem Zeiger zu dem Serveraufrufobjekt, das in Schritt 1310 aufgebaut wurde, und einem Cookie aufgerufen. Das identifizierte Skelett kann entweder ein statisches Skelett oder ein dynamisches Skelett sein. In Schritt 1314 wird eine Bestimmung bezüglich dessen durchgeführt, ob eine Ausnahme geworfen wurde, als der identifizierte Abfertigungsabschluss aufgerufen wurde. Falls bestimmt wird, dass eine Ausnahme geworfen wurde, fährt die Prozesssteuerung zu Schritt 1316 fort, wo die Aufstellungsausnahmemethode des Serveraufrufobjektes aufgerufen wird, mit der geworfenen oder zurückgegebenen Ausnahme, die als ein Argument hinein weitergegeben wird. Dann wird in Schritt 1318 das Serveraufrufobjekt zerstört, und der Prozess zum Ausführen einer typischen Abfertigungsroutine ist abgeschlossen. Der Schritt zum Zerstören des Serveraufrufobjektes involviert einen Ruf zu einem Mehrzweck-Rückrufabschluss. Dieser Abschluss erlaubt, dass dynamische Skelette zugeordneten Speicher nach Aufstellung freigeben. Falls in Schritt 1314 bestimmt wird, dass eine Ausnahme nicht geworfen wurde, fährt die Prozesssteuerung direkt zu Schritt 1318 fort, in dem das Serveraufrufobjekt zerstört wird. Nachdem das Serveraufrufobjekt zerstört ist, ist der Prozess zum Ausführen einer typischen Abfertigungsroutine abgeschlossen. Die Schritte, die bei einem Aufruf eines Abfertigungsabschlusses, d.h. einem Aufruf eines Skeletts, involviert sind, werden nachstehend mit Bezug auf 15 und 16 erörtert.
  • Bezug nehmend als Nächstes auf 14A wird die Struktur eines typischen Serveraufrufobjektes in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung beschrieben. Ein Serveraufrufobjekt 1408 ist eine Datenstruktur, die einen Zeiger zu einem Aufstellungspuffer 1410, einen Zeiger zu einem Methodendeskriptor 1412 und einen Zeiger zu einem Aufrufdeskriptor 1414 inkludieren kann. Serveraufrufobjekt 1408 wird in dem Aufruf einer Methode auf der Serverseite eines verteilten Objektsystems verwendet. Speziell enthält Serveraufrufobjekt 1408 Funktionalität, die durch den Server verwendet wird, um einen Methodenruf auszuführen. Es sollte erkannt werden, dass Methoden, die mit Serveraufrufobjekt 1408 in Verbindung stehen, mit anderen Methoden überschrieben werden können. In der beschriebenen Ausführungsform ist Serveraufrufobjekt 1408 ein C++-Objekt, oder Datenstruktur, das/die Aufstellungs-, Abstellungs- und Aufstellungs-Ausnahme-Methoden hat.
  • Serveraufrufobjekt 1408 kann optional Elemente außer einem Zeiger zu einem Aufstellungspuffer 1410, Zeiger zu einem Methodendeskriptor 1412 und Zeiger zu einem Aufrufdeskriptor 1414 inkludieren. Als ein Beispiel kann Serveraufrufobjekt 1408 auch einen Zeiger zu einem Kontext 1416, falls ein Kontext vorhanden ist, und einen Rückrufabschluss 1418 inkludieren, der einen Zeiger zu einer Rückruffunktion enthält, und einen Zeiger zu einem Datenelement, d.h. einem Cookie. Rückrufabschluss 1418 kann durch die dynamische Skelettschnittstelle (DSI, dynamic skeleton interface) verwendet werden, um in dem Prozess zum Zerstören und Deallokieren von Speicher zu helfen, der während eines Aufrufs eines dynamischen Skeletts zugeordnet wird, der nicht zerstört oder zurückgegeben würde, da der zugeordnete Speicher Ergebnisse oder Deskriptoren enthält, die entweder aufgestellt werden müssen oder zum Aufstellen von Ergebnissen benötigt werden. Es sollte erkannt werden, dass Serveraufrufobjekt 1408 zusätzliche Zeiger und Funktionen abhängig von den Anforderungen eines Systems inkludieren kann.
  • Bezug nehmend als Nächstes auf 14B wird ein Verfahren zum Aufbauen eines Serveraufrufobjektes in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung beschrieben. Mit anderen Worten ist 14B ein Überblick von Schritt 1308 von 13B. In Schritt 1402 wird das Serveraufrufobjekt durch Rufen der Konstruktormethode des Serveraufrufobjektes initialisiert. Konstruktormethoden werden gewöhnlich verwendet, um Datenstrukturen zu initialisieren, und sind einem Fachmann gut bekannt. Ein Subkontrakt verwendet eine Konstruktormethode, um ein Serveraufrufobjekt aufzubauen. Subkontrakte bestimmen den Typ vom Serveraufrufobjekt, das aufzubauen ist. Speziell bestimmen Subkontrakte beliebige optionale Elemente, wie z.B. einen optionalen Zeiger zu einem Kontext, wie mit Bezug auf 14A beschrieben, die als ein Teil eines Serveraufrufobjektes inkludiert sein können. Die Bestimmung ist jedoch innerhalb eines Subkontraktes implizit. Mit anderen Worten wird ein gegebener Subkontrakt stets die gleiche Art von Serveraufrufobjekt für den gleichen Transportendpunkt oder Objekt aufbauen.
  • Nachdem das Serveraufrufobjekt initialisiert ist, wird in Schritt 1404 der Zeiger zu dem geeigneten Aufstellungspuffer, oder dem Aufstellungspuffer, der mit dem Serveraufrufobjekt in Verbindung steht, eingefüllt. Dann wird in Schritt 1406 der Zeiger zu einem Methodendeskriptor, der mit dem Serveraufrufobjekt in Verbindung steht, eingefüllt. Es sollte er kannt werden, dass in einigen Ausführungsformen der Zeiger zu dem Methodendeskriptor eingefüllt werden kann, bevor der Zeiger zu dem Aufstellungspuffer eingefüllt wird. Obwohl das Serveraufrufobjekt einen Zeiger zu einem Aufrufdeskriptor inkludiert, wird dieser Zeiger durch das Skelett eingefüllt, nachdem das Serveraufrufobjekt aufgebaut ist. Nachdem der Zeiger zu einem Methodendeskriptor eingefüllt ist, ist der Prozess zum Aufbauen eines Serveraufrufobjektes abgeschlossen.
  • Bezug nehmend als Nächstes auf 15 wird der Schritt zum Aufrufen eines Abfertigungsabschlusses, oder Skeletts, d.h. Schritt 1312 von 13B, was ein statisches Skelett ist, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung beschrieben. Sobald ein Zeiger zu dem Serveraufrufobjekt und der Zeiger zu dem Servant in den Ruf weitergegeben sind, um das Skelett aufzurufen, wird der richtige Aufrufdeskriptor in Schritt 1502 unter Verwendung des Methodendeskriptors, auf den in dem Serveraufrufobjekt gezeigt wird, identifiziert. In Schritt 1502 geschieht eine Steuerungsumschaltung, eine Standardoperation in den meisten Programmiersprachen. Nachdem ein Aufrufdeskriptor unter Verwendung des Methodendeskriptors, der mit dem Serveraufrufobjekt in Verbindung steht, identifiziert ist, fährt die Prozesssteuerung zu Schritt 1504 fort, wo der Zeiger zu einem Aufrufdeskriptor eingefüllt wird. Der Zeiger zu einem Aufrufdeskriptor ist ein Teil des Serveraufrufobjektes, wie oben beschrieben wird. Nachdem der Zeiger zu dem Aufrufdeskriptor eingefüllt ist, wird Speicher für Argumente in Schritt 1506 zugeordnet. Das Skelett hat die Kapazität zu bestimmen, wie viel Speicher für eine Speicherung zuzuordnen ist. Eine In-Parameteradressliste oder Speicherstellenliste wird dann Schritt 1508 eingerichtet. Die In-Parameterliste besteht aus einer Liste von Zeigern zu Stellen, wo In-Argumente abzustellen sind.
  • Nachdem die In-Parameterliste eingerichtet ist, bewegt sich der Prozessfluss zu Schritt 1510, wo die Abstellungsmethode für das Serveraufrufobjekt mit der In-Parameterliste gerufen wird. Die gerufene Abstellungsmethode ist für das bestimmte Serveraufrufobjekt spezifisch, und ruft schließlich die generische Abstellungsroutine, die oben mit Bezug auf 12B beschrieben wird, oder eine äquivalente Routine, unter Weitergabe von IN_DESC, IN_DESC_COUNT und einer In-Parameterliste. In Schritt 1512 wird die Servantmethode, die durch den Methodendeskriptor identifiziert wird, gerufen. Falls eine Ausnahme durch den Ruf zu der Servantmethode geworfen wird, fährt der Prozessfluss zu Schritt 1520 fort, der Schritt 1316 von 13B ist, dem Aufruf der Aufstellungsausnahmemethode des Serveraufrufobjektes. Falls eine Ausnahme nicht geworfen wird, wird nach dem Ruf zu der Servantmethode eine Rückgabe von der Servantmethode in Schritt 1514 empfangen. Die Servantmethode kann auch als die "gerufene" Methode bekannt sein. In Schritt 1516 wird eine Aus-Parameterliste eingerichtet. Die Aus-Parameterliste besteht aus einer Liste von Zeigern zu Stellen, die Aus-Argumente enthalten. Nachdem die Aus-Parameterliste eingerichtet ist, wird ein Ruf in Schritt 1518 zu der Aufstellungsmethode des Serveraufrufobjektes mit der Aus-Parameterliste durchgeführt. Die Aufstellungsmethode ruft schließlich die generische Aufstellungsmethode, die oben mit Bezug auf 11 beschrieben wird, oder eine äquivalente, unter Weitergabe von OUT_DESC, OUT_DESC_COUNT und einer Aus-Parameterliste. Nachdem der Ruf zu der Aufstellungsmethode durchgeführt ist, ist der Prozess zum Aufrufen eines Skeletts fertig.
  • Bezug nehmend als Nächstes auf 16 wird eine Methode zum Aufrufen eines Abfertigungsabschlusses, oder eines Skeletts, d.h. Schritt 1312 von 13B, in einer dynamischen Skelettschnittstelle (DSI) in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung beschrieben. Anfangs werden der Zeiger zu dem Serveraufrufobjekt und der Zeiger zu der Servantadresse in den Ruf weitergegeben, um das DSI-Skelett aufzurufen. Dann wird in Schritt 1602 ein Aufrufdeskriptor für die Methode, die durch den Methodendeskriptor identifiziert wird, worauf durch das Serveraufrufobjekt gezeigt wird, aufgebaut oder erhalten. Die Information, die notwendig ist, um Deskriptoren aufzubauen, auch als Deskriptordatenstrukturen bekannt, ist in einem Schnittstellenrepository enthalten. Das Schnittstellenrepository, das auf eine Schnittstelle bezogene Information speichert, wird durchlaufen, um genug Information zu sammeln, um alle notwendigen Deskriptoren aufzubauen, inkludierend den Aufrufdeskriptor. Die Information wird dann durch das DSI-Teilsystem verwendet, um die Deskriptoren zu erstellen. Es sollte erkannt werden, dass Deskriptoren erstellt werden, wenn benötigt, d.h. wenn eine Methode über die DSI aufgerufen wird, unter Verwendung von Information in dem Schnittstellenrepository. Dynamische, oder Typcode-interpretierte, Aufstellung und Abstellung nutzen typischerweise nicht vorkompilierte Methoden- und Aufrufdeskriptoren.
  • Nachdem ein Aufrufdeskriptor aufgebaut oder erhalten ist, bewegt sich der Prozessfluss zu Schritt 1604, wo der Zeiger zu dem Aufrufdeskriptor, der innerhalb des Serveraufrufobjektes enthalten ist, eingefüllt wird. In Schritt 1606 wird dann Speicher unter Verwendung von Typcode für Argumente zugeordnet, vorgesehen durch Parameterdeskriptoren, auf die durch den Aufrufdeskriptor gezeigt wird. Es sollte erkannt werden, dass es nicht notwendig ist, den Größencode in dem Parameterdeskriptor explizit vorzusehen, da Information bezüglich des Umfangs von Speicher, der durch einen empfangenden Prozess zugeordnet werden muss, aus dem Typcode berechnet werden kann.
  • Nachdem Speicher zugeordnet ist, wird eine In-Parameterliste in Schritt 1608 eingerichtet. D.h. es wird eine Liste von Zeigern erstellt, die anzeigen, wo In-Argumente abzustellen sind. Dann wird in Schritt 1610 ein Ruf zu einer Abstellungsmethode durchgeführt, die mit dem Serveraufrufobjekt in Verbindung steht, mit Argumenten und der In-Parameterliste. Sobald die Abstellungsmethode mit der In-Parameterliste gerufen ist, wird in Schritt 1612 ein Ruf zu der Abfertigungsmethode des DSI-Servants durchgeführt. Die Prozesssteuerung fährt dann zu Schritt 1614 fort, wo die Rückgabe von der Servantmethode empfangen wird. Bei Empfang der Rückgabe von der Servantmethode wird in Schritt 1615 bestimmt, ob eine Ausnahme zurückgegeben wurde. Falls die Bestimmung ist, dass eine Ausnahme zurückgegeben wurde, wird die Aufstellungsausnahmemethode des Serveraufrufobjektes in Schritt 1620 mit den Argumenten gerufen, die in der Ausnahme zurückgegeben wurden. Sobald der Ruf zu der Aufstellungsausnahmemethode durchgeführt ist, ist der Prozess zum Aufrufen eines DSI-Skeletts fertig. Falls in Schritt 1615 bestimmt wird, dass eine Ausnahme nicht zurückgegeben wurde, bewegt sich der Prozessfluss zu Schritt 1616, wo eine Aus-Parameterliste, oder eine Liste von Zeigern zu den Stellen, in denen Aus-Argumente abzustellen sind, eingerichtet. Nachdem die Aus-Parameterliste eingerichtet ist, wird die Aufstellungsmethode des Serveraufrufobjektes in Schritt 1618 gerufen, mit der Aus-Parameterliste als ein Argument. Nachdem die Aufstellungsmethode gerufen ist, ist der Prozess zum Aufrufen eines DSI-Skeletts fertig.
  • Es sollte erkannt werden, dass Code in Bezug auf Subkontrakte und Transporte Unterschiede zwischen kompilierter und interpretierter Aufstellung und Abstellung nicht kennt. Ferner nutzen dynamische und statische Skelette die gleiche Schnittstelle, die hauptsächlich durch das Serveraufrufobjekt definiert ist. Die Aufstellungsmethode, die mit dem Serveraufrufobjekt in Verbindung steht, ruft schließlich eine generische Aufstellungsmethode oder eine äquivalente Methode. Ähnlich ruft die Abstellungsmethode, die mit dem Serveraufrufobjekt in Verbindung steht, schließlich eine generische Abstellungsmethode oder eine äquivalente Methode. Details, die sich auf Aufstellung und Abstellung von Argumenten beziehen, sind in den generischen Aufstellungs- und Abstellungsmethoden oder äquivalenten Methoden eingebettet, d.h. verborgen. Die Aufstellungs- und Abstellungsmethode eines Serveraufrufobjektes, wovon es viele Arten geben kann, hängt jedoch von dem verwendeten bestimmten Subkontrakt und Transport ab.
  • Die vorliegende Erfindung, wie sie oben beschrieben wird, setzt verschiedene Prozessschritte ein, die Daten involvieren, die in Computersystemen gespeichert sind. Diese Schritte sind jene, die physische Manipulation von physischen Quantitäten erfordern. Gewöhnlich, obwohl nicht notwendigerweise, nehmen diese Quantitäten die Form von elektrischen oder magnetischen Signalen an, die fähig sind, gespeichert, transferiert, kombiniert, verglichen oder anderweitig manipuliert zu werden. Es ist manchmal, prinzipiell aus Gründen üblicher Verwendung, zweckdienlich, auf diese Signale als Bits, Werte, Elemente, Variablen, Zeichen, Datenstrukturen oder dergleichen zu verweisen. Es sollte daran erinnert werden, dass jedoch alle diese und ähnliche Begriffe mit den geeigneten physischen Quantitäten zu verbinden sind und lediglich zweckdienliche Kennzeichen sind, die auf diese Quantitäten angewendet werden.
  • Ferner werden die durchgeführten Manipulationen häufig in einem Sinn bezeichnet, wie etwa Identifizieren, Laufen oder Vergleichen. In beliebigen der hierin beschriebenen Operationen, die einen Teil der vorliegenden Erfindung bilden, sind diese Operationen Maschinenoperationen: Nützliche Maschinen zum Durchführen der Operationen der vorliegenden Erfindung inkludieren Mehrzweckdigitalcomputer oder andere ähnliche Einrichtungen. In allen Fällen sollte der Unterschied zwischen dem Verfahren von Operationen beim Betreiben eines Computers und dem Verfahren der Berechnung selbst berücksichtigt werden. Die vorliegende Erfindung bezieht sich auf Verfahrensschritte zum Betreiben eines Computers bei Verarbeitung elektrischer oder anderer physischer Signale, um andere gewünschte physische Signale zu generieren.
  • Die vorliegende Erfindung bezieht sich auch auf eine Vorrichtung zum Durchführen dieser Operationen. Diese Vorrichtung kann speziell für die erforderlichen Zwecke konstruiert sein, oder sie kann ein Mehrzweckcomputer sein, der durch ein Computerprogramm, das in dem Computer gespeichert ist, selektiv aktiviert oder neu konfiguriert wird. Die Prozesse, die hierin präsentiert werden, beziehen sich nicht inhärent auf einen beliebigen bestimmten Computer oder eine andere Vorrichtung. Insbesondere können verschiedene Mehrzweckmaschinen mit Programmen verwendet werden, die in Übereinstimmung mit den Unterweisungen hierin geschrieben sind, oder es kann zweckdienlicher sein, eine spezialisiertere Vorrichtung zu konstruieren, um die erforderlichen Verfahrensschritte durchzuführen. Die erforderliche Struktur für eine Vielfalt dieser Maschinen wird aus der oben angegebenen Beschreibung erscheinen.
  • Außerdem bezieht sich die vorliegende Erfindung ferner auf computerlesbare Medien, die Programminstruktionen zum Durchführen verschiedener Computer-implementierter Operationen inkludieren. Die Medien und Programminstruktionen können jene sein, die speziell für die Zwecke der vorliegenden Erfindung ausgelegt und konstruiert sind, oder sie können von der Art sein, die einem Fachmann für Computersoftware gut bekannt und verfügbar sind. Beispiele von computerlesbaren Medien inkludieren, sind aber nicht darauf begrenzt, magnetische Medien, wie etwa Festplatten, Floppy-Disks und Magnetband; optische Medien, wie etwa CD-ROM-Disks; magneto-optische Medien, wie etwa optische Disks; und Hardwareeinrichtungen, die speziell konfiguriert sind, Programminstruktionen zu speichern und durchzuführen, wie etwa Nur-Lese-Speichereinrichtungen (ROM) und Speicher mit wahlfreiem Zugriff (RAM). Beispiele von Programminstruktionen inkludieren sowohl Maschinencode, wie etwa durch einen Compiler erzeugt, als auch Dateien, die Code höherer Ebene enthalten, der durch den Computer unter Verwendung eines Interpreters ausgeführt werden kann.
  • 17 veranschaulicht ein typisches Computersystem in Übereinstimmung mit der vorliegenden Erfindung. Das Computersystem 500 inkludiert eine beliebige Zahl von Prozessoren 502 (auch als zentrale Verarbeitungseinheiten oder CPUs bezeichnet), die mit Speichereinrichtungen gekoppelt sind, inkludierend primäre Speichereinrichtungen 504 (typischerweise einen Nur-Lese-Speicher, oder ROM) und primäre Speichereinrichtungen 506 (typischerweise einen Speicher mit wahlfreiem Zugriff, oder RAM). Wie in der Technik gut bekannt ist, agiert ROM 504, um Daten und Instruktionen unidirektional zu der CPU zu transferieren, und RAM 506 wird typischerweise verwendet, um Daten und Instruktionen auf eine bidirektionale Art und Weise zu transferieren. Beide primären Speichereinrichtungen 504, 506 können beliebige geeignete computerlesbare Medien wie oben beschrieben inkludieren. Es ist auch eine Massenspeichereinrichtung 508 bidirektional mit CPU 502 gekoppelt und sie zusätzliche Datenspeicherkapazität vor. Die Massenspeichereinrichtung 508 kann verwendet werden, um Programme, Daten und dergleichen zu speichern, und ist typischerweise ein sekundäres Speichermedium, wie etwa eine Festplatte, das langsamer als primäre Speichereinrichtungen 504, 506 ist. Massenspeichereinrichtung 508 kann die Form eines magnetischen oder Papierband-Lesegerätes oder einer beliebigen anderen gut bekannten Einrichtung annehmen. Es wird erkannt, dass die Information, die innerhalb der Massenspeichereinrichtung 508 gehalten wird, in geeigneten Fällen auf eine Standardweise als Teil von RAM 506 als virtueller Speicher inkorporiert werden kann. Eine spezielle Massenspeichereinrichtung, wie etwa eine CD-ROM 514, kann auch Daten unidirektional zu der CPU weitergeben.
  • CPU 502 ist auch mit einer oder mehr Eingabe-/Ausgabeeinrichtungen 510 gekoppelt, die Einrichtungen, wie etwa Videomonitore, Track-Balls, Mäuse, Tastaturen, Mikrofone, berührungsempfindliche Anzeigen, Umformerkartenlesegeräte, magnetische oder Papierband-Lesegeräte, Tabletts, Griffel, Erkennungseinrichtungen für Sprache oder Handschrift oder andere gut bekannte Eingabeeinrichtungen, wie etwa natürlich andere Computer, inkludieren können, aber nicht darauf begrenzt sind. Schließlich kann CPU 502 optional mit einem Computer- oder Telekommunikationsnetz unter Verwendung einer Netzverbindung, wie allgemein bei 512 gezeigt, gekoppelt werden. Mit einer derartigen Netzverbindung wird betrachtet, dass die CPU Information von dem Netz empfangen kann, oder Information zu dem Netz im Verlauf einer Durchführung der oben beschriebenen Verfahrensschritte ausgeben kann. Die oben beschriebenen Einrichtungen und Materialien werden einem Fachmann für Computerhardware und Softwaretechnik vertraut sein.
  • In den beschriebenen Ausführungsformen wurden spezifische Datenstrukturen für die Methodendskriptoren, Aufrufdeskriptoren, Parameterdeskriptoren und Ausnahmedeskriptoren beschrieben. Es wird offensichtlich sein, dass diese Datenstrukturen innerhalb des Bereichs der vorliegenden Erfindung breit variiert werden können. Ähnlich können auch Methoden zum Aufstellen und Abstellen von Argumenten innerhalb des Bereichs der vorliegenden Erfindung breit variiert werden. Als ein Beispiel können Schritte, die mit Methoden zum Aufstellen und Abstellen von Argumenten involviert sind, umgeordnet werden. Es können auch Schritte entfernt oder hinzugefügt werden.
  • Außerdem können in einigen Situationen Aufstellungs- und Abstellungsmethoden, die mit einem gewöhnlichen Objekt in Verbindung stehen, wie etwa einem Parameter, in eine einzelnen Methode kombiniert werden. Für Fälle, in denen die Aufstellungs- und Abstellungsmethoden identisch sind, könnte die Hinzufügung eines Argumentes in dem Funktionsruf verwendet werden um zu spezifizieren, ob Aufstellung oder Abstellung gewünscht wird. Für Fälle, in denen die Aufstellungs- und Abstellungsmethoden verschieden sind, könnte eine neue Funktion erstellt werden, um beide Methoden durchzuführen. Diese neue Funktion könnte ein Argument zu dem Funktionsruf inkludieren, das spezifizieren würde, ob die gewünschte Methode Aufstellung oder Abstellung war. Falls eine einzelne Funktion sowohl Aufstellung als auch Abstellung darstellt, kann in Typcode und Deskriptordatenstrukturen mit Zeigern zu Aufstellungs- und Abstellungsmethoden ein Zeiger verwendet werden, um auf die einzelne Funktion zu zeigen. Es kann ein boolescher Wert oder ein Flag in die Deskriptordatenstrukturen implementiert werden, was anzeigen würde, ob Aufstellung oder Abstellung durch die Deskriptordatenstruktur gewünscht wird. Deshalb sollten die beschriebenen Ausführungsformen als veranschaulichend und nicht einschränkend genommen werden, und die Erfindung sollte durch die folgenden Ansprüche und ihren vollständigen Bereich von Äquivalenten definiert werden.

Claims (19)

  1. Verfahren zum Rufen eines entfernt gelegenen Objektes in einem verteilten Client-/Server-basierten Berechnungssystem (10), das Verfahren die Schritte umfassend: Empfangen einer Anforderung innerhalb eines Clientprozesses (62); Auswählen eines Transports (202), der für die Anforderung geeignet ist, wobei der Transport verwendet wird, um die Anforderung aufzustellen; Erstellen eines Aufstellungspuffers (206), der für den gewählten Transport geeignet ist, wobei der Aufstellungspuffer verwendet wird, um die Anforderung zu kapseln; Aufstellen eines Argumentes (210) unter Verwendung von Deskriptordatenstrukturen, unter Nutzung einer Aufstellungsmethode, die Deskriptordatenstrukturen inkludierend ein kompiliertes Flag (84), das verwendet wird um anzuzeigen, ob die Aufstellungsmethode Typcode-interpretiert oder kompiliert ist; und Bestimmen, ob das kompilierte Flag gesetzt ist (1100), wobei wenn bestimmt ist, dass das kompilierte Flag gesetzt ist, der Argumentaufstellungsschritt durch Aufrufen einer Aufstellungsmethode bewerkstelligt wird, die mit dem Argu ment in Verbindung steht, das mit der Anforderung in Verbindung steht (1104), und wenn bestimmt ist, dass das kompilierte Flag nicht gesetzt ist, der Argumentaufstellungsschritt durch Aufrufen einer Typcode-Aufstellungsmethode bewerkstelligt wird, wobei das Argument zu der Typcode-Aufstellungsmethode weitergegeben wird (1108).
  2. Verfahren, wie in Anspruch 1, wobei: die Anforderung innerhalb des Clientprozesses mindestens ein Argument inkludiert, das in einer Stelle mit einer Adresse gespeichert ist; die Aufstellungsmethode geeignet zum Aufstellen des Argumentes in der Anforderung unter Verwendung der Deskriptordatenstrukturen ausgewählt wird, wobei die Deskriptordatenstrukturen eine Aufrufdeskriptor-Datenstruktur (83), die das kompilierte Flag (84) inkludiert, das verwendet wird um anzuzeigen, ob die Anforderung Typcode-interpretiert oder vorkompiliert ist, und eine Vielzahl von Datendeskriptoren inkludieren; wobei wenn das kompilierte Flag gesetzt ist, die Aufstellungsmethode durch einen Parameterdeskriptor identifiziert wird, der mit dem Argument in Verbindung steht (1104); und wobei wenn das kompilierte Flag nicht gesetzt ist, die Aufstellungsmethode unter Verwendung von Typcode-Interpretation identifiziert wird (1108).
  3. Verfahren, wie in Anspruch 2 vorgetragen, ferner die Schritte umfassend: Auswählen einer Abstellungsfunktion, geeignet zum Abstellen des Argumentes in der Anforderung unter Verwendung der Deskriptordatenstrukturen; und Bestimmen, ob das kompilierte Flag gesetzt ist (1130), wobei wenn bestimmt ist, dass das kompilierte Flag (84) gesetzt ist, der Argumentabstellungsschritt durch Aufrufen einer Abstellungsmethode bewerkstelligt wird, die durch den Parameterdeskriptor identifiziert wird, der mit dem Argument in Verbindung steht (1134); und wenn bestimmt ist, dass das kompilierte Flag nicht gesetzt ist, der Argumentabstellungsschritt durch Aufrufen einer Abstellungsmethode bewerkstelligt wird, die unter Verwendung von Typcode-Interpretation identifiziert wird (1138).
  4. Verfahren, wie in Ansprüchen 2 oder 3 vorgetragen, wobei: der Aufstellungsmethode, die durch den Parameterdeskriptor identifiziert wird, das Argument weitergegeben wird (1104); und der Aufstellungsmethode, die unter Verwendung von Typcode-Interpretation identifiziert wird, das Argument und ein zugehöriger Typcode weitergegeben wird (1108).
  5. Verfahren, wie in Anspruch 4 vorgetragen, wobei jedes Argument, das zu einer der Aufstellungsmethoden weitergegeben wird, die Form einer Adresse annimmt, die die Speicherstelle definiert, die das Argument speichert.
  6. Verfahren, wie in beliebigen von Ansprüchen 2 bis 5 vorgetragen, wobei: der Abstellungsmethode, die durch den Parameterdeskriptor identifiziert wird, das Argument weitergegeben wird (1134); und der Abstellungsmethode, die unter Verwendung von Typcode-Interpretation identifiziert wird, das Argument und ein zugehöriger Typcode weitergegeben wird (1138).
  7. Verfahren, wie in Anspruch 6 vorgetragen, wobei jedes Argument, das zu einer der Abstellungsmethoden weitergegeben wird, die Form einer Adresse annimmt, die die Speicherstelle definiert, die das Argument speichert.
  8. Verfahren, wie in einem von Ansprüchen 2 bis 7 vorgetragen, wobei wenn die Anforderung mehr als ein Argument hat, das damit in Verbindung steht: wenn bestimmt ist, dass das kompilierte Flag (84) gesetzt ist, der Argumentaufstellungsschritt durch sequenzielles Aufrufen von Aufstellungsmethoden bewerkstelligt wird, die mit jedem der Argumente in Verbindung stehen (1102); und wenn bestimmt ist, dass das kompilierte Flag nicht gesetzt ist, der Argumentaufstellungsschritt durch sequenzielles Aufrufen von Typcode-Aufstellungsroutinen bewerkstelligt wird, die mit jedem der Argumente in Verbindung stehen, unter Weitergabe der Argumente zu ihren zugehörigen Typcode-Aufstellungsroutinen (1106).
  9. Verfahren, wie in einem von Ansprüchen 2 bis 8 beschrieben, ferner die Schritte umfassend: Übertragen der Anforderung über den ausgewählten Transport zu einem identifizierten Endpunkt (212), wobei der Endpunkt mit einem Serverprozess in Verbindung steht; und Empfangen einer Antwort von dem Serverprozess (216).
  10. Aufrufdeskriptor-Datenstruktur (83) für eine Verwendung in einem Verfahren zum Rufen eines entfernt gelegenen Objektes, wie in beliebigen von Ansprüchen 1 bis 9 beansprucht, die Aufrufdeskriptor-Datenstruktur umfassend: ein Kompilierungsflag (84), angeordnet, einen Aufrufpfadtyp zu identifizieren, wobei ein erster Zustand des kompilierten Flags anzeigt, dass der Aufrufpfadtyp ein statisch kompilierter Aufruf ist, in dem Aufstellungs- und Abstellungsfunktionen, die erforderlich sind, um den Aufruf zu ermöglichen, vorkompiliert sind, und ein zweiter Zustand des kompilierte Flags anzeigt, dass der Aufrufpfadtyp dynamisch, Typcode-interpretierter Aufruf ist, in dem die Aufstellungs- und Abstellungsfunktionen, die erforderlich sind, um den Aufruf zu ermöglichen, nicht vorkompiliert sind.
  11. Aufrufdeskriptor-Datenstruktur, wie in Anspruch 10 vorgetragen, ferner umfassend: einen Zeiger zu einem Feld von Parameterdeskriptor-Datenstrukturen (88), die Charakteristika von Parametern beschreiben, die mit der Aufrufdeskriptor-Datenstruktur in Verbindung stehen; und einen Zeiger zu einem Feld von Zeigern zu Ausnahmedeskriptor-Datenstrukturen (90), die Charakteristika von Ausnahmen beschreiben, die mit der Aufrufdeskriptor-Datenstruktur in Verbindung stehen.
  12. Aufrufdeskriptor-Datenstruktur, wie in Anspruch 10 oder 11 vorgetragen, ferner umfassend einen Deskriptorzähler (86), der die Anzahl von Parametern anzeigt, die mit der Aufrufdeskriptor-Datenstruktur in Verbindung stehen.
  13. Aufrufdeskriptor-Datenstruktur, wie in einem von Ansprüchen 10–12 vorgetragen, ferner umfassend: einen Zeiger zu einer Reinitialisierungsfunktion (92), die dazu dient, Puffer zu löschen, die mit der Aufrufdeskriptor-Datenstruktur in Verbindung stehen; und einen Kontextdeskriptor (91), der Information enthält, die für eine Methode relevant ist, die mit der Aufrufdeskriptor-Datenstruktur in Verbindung steht.
  14. Computerprogrammprodukt, umfassend ein computerverwendbares Medium mit computerlesbarem Code, der darauf verkörpert ist, zum Aufrufen einer Objektmethode, die in einem verteilten Serverobjekt innerhalb eines Berechnungssystems verteilter Objekte (10) definiert ist, das Computerprogrammprodukt umfassend computerlesbaren Programmcode zum Bewirken der folgenden Schritte innerhalb des Computersystems: Empfangen einer Anforderung innerhalb eines Clientprozesses; Auswählen eines Transports (202) geeignet für die Anforderung, wobei der Transport verwendet wird, um die Anforderung aufzustellen; Erstellen eines Aufstellungspuffers (206) geeignet für den ausgewählten Transport, wobei der Aufstellungspuffer verwendet wird, um die Anforderung zu kapseln; Aufstellen eines Argumentes (210) unter Verwendung von Deskriptordatenstrukturen, unter Nutzung einer Aufstellungsmethode, die Deskriptordatenstrukturen inkludierend ein kompiliertes Flag (84), das verwendet wird um anzuzeigen, ob die Aufstellungsmethode Typcode-interpretiert oder kompiliert ist; und Bestimmen, ob das kompilierte Flag gesetzt ist (1100), wobei wenn bestimmt ist, dass das kompilierte Flag gesetzt ist, der Argumentaufstellungsschritt durch Aufrufen einer Aufstellungsmethode bewirkt wird, die mit dem Argument in Verbindung steht, das mit der Anforderung in Verbindung steht (1104); und wenn bestimmt ist, dass das kompilierte Flag nicht gesetzt ist, der Argumentaufstellungsschritt durch Aufrufen einer Typcode-Aufstellungsmethode bewerkstelligt wird, wobei das Argument zu der Typcode-Aufstellungsmethode weitergegeben wird (1108).
  15. Computerprogrammprodukt, umfassend computerlesbaren Code, wie in Anspruch 14 vorgetragen, wobei: die Anforderung innerhalb des Clientprozesses mindestens ein Argument inkludiert, das in einer Stelle mit einer Adresse gespeichert ist; die Aufstellungsmethode geeignet zum Aufstellen des Argumentes in der Anforderung unter Verwendung der Deskriptordatenstrukturen ausgewählt wird, wobei die Deskriptordatenstrukturen eine Aufrufdeskriptor-Datenstruktur (83), die das kompilierte Flag (84) inkludiert, das verwendet wird um anzuzeigen, ob die Anforderung Typcode-interpretiert oder vorkompiliert ist, und eine Vielzahl von Datendeskriptoren inkludieren; wobei wenn das kompilierte Flag gesetzt ist, die Aufstellungsmethode durch einen Parameterdeskriptor identifiziert wird, der mit dem Argument in Verbindung steht (1104); und wobei wenn das kompilierte Flag nicht gesetzt ist, die Aufstellungsmethode unter Verwendung von Typcode-Interpretation identifiziert wird (1108).
  16. Computerprogrammprodukt, umfassend computerlesbaren Programmcode, wie in Anspruch 15 vorgetragen, wobei: der Aufstellungsmethode, die durch den Parameterdeskriptor identifiziert wird, das Argument weitergegeben wird (1104); und der Aufstellungsmethode, die unter Verwendung von Typcode-Interpretation identifiziert wird, das Argument und ein zugehöriger Typcode weitergegeben wird (1108).
  17. Computerprogrammprodukt, umfassend computerlesbaren Programmcode, wie in Anspruch 16 vorgetragen, wobei jedes Argument, das zu einer der Aufstellungsmethoden weitergegeben wird, die Form einer Adresse annimmt, die die Speicherstelle definiert, die das Argument speichert.
  18. Computerprogrammprodukt, umfassend computerlesbaren Programmcode, wie in einem von Ansprüchen 15–17 vorgetragen, ferner die Schritte umfassend: Übertragen der Anforderung über den ausgewählten Transport zu einem identifizierten Endpunkt (212), wobei der Endpunkt mit einem Serverprozess in Verbindung steht; und Empfangen einer Antwort von dem Serverprozess (216).
  19. Computerprogrammprodukt, umfassend computerlesbaren Programmcode, wie in Anspruch 18 vorgetragen, wobei der Schritt zum Empfangen einer Antwort von dem Serverprozess ferner die Schritte zum Kapseln der Antwort in dem Aufstellungspuffer (218) unter Verwendung der Aufstellungsfunktion, die durch den Parameterdeskriptor identifiziert wird, umfasst.
DE69734175T 1996-06-26 1997-05-16 Transportunabhängige Anruf- und Dienstschnittstellen, die die Marshalling von integrierten Type-Codes sowie kompilierten Code erlauben Expired - Fee Related DE69734175T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US08/673,181 US6032199A (en) 1996-06-26 1996-06-26 Transport independent invocation and servant interfaces that permit both typecode interpreted and compiled marshaling
US673181 1996-06-26

Publications (2)

Publication Number Publication Date
DE69734175D1 DE69734175D1 (de) 2005-10-20
DE69734175T2 true DE69734175T2 (de) 2006-05-04

Family

ID=24701602

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69734175T Expired - Fee Related DE69734175T2 (de) 1996-06-26 1997-05-16 Transportunabhängige Anruf- und Dienstschnittstellen, die die Marshalling von integrierten Type-Codes sowie kompilierten Code erlauben

Country Status (4)

Country Link
US (3) US6032199A (de)
EP (1) EP0817027B1 (de)
JP (1) JPH1063506A (de)
DE (1) DE69734175T2 (de)

Families Citing this family (68)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5991535A (en) * 1996-07-03 1999-11-23 Sun Microsystems, Inc. Visual composition tool for constructing application programs using distributed objects on a distributed object network
US6496865B1 (en) * 1997-03-12 2002-12-17 Novell, Inc. System and method for providing interpreter applications access to server resources in a distributed network
JP3817823B2 (ja) * 1997-04-10 2006-09-06 ソニー株式会社 データ通信方法
US6405264B1 (en) * 1997-12-18 2002-06-11 Sun Microsystems, Inc. Marshaling and unmarshaling framework for supporting filters in a distributed object system
US6298391B1 (en) 1998-03-13 2001-10-02 Microsoft Corporation Remote procedure calling with marshaling and unmarshaling of arbitrary non-conformant pointer sizes
US8650320B1 (en) * 1998-03-23 2014-02-11 Software Ag Integration server supporting multiple receiving channels
US8346337B2 (en) 1998-04-30 2013-01-01 Abbott Diabetes Care Inc. Analyte monitoring device and methods of use
US8688188B2 (en) 1998-04-30 2014-04-01 Abbott Diabetes Care Inc. Analyte monitoring device and methods of use
US8974386B2 (en) 1998-04-30 2015-03-10 Abbott Diabetes Care Inc. Analyte monitoring device and methods of use
US8480580B2 (en) 1998-04-30 2013-07-09 Abbott Diabetes Care Inc. Analyte monitoring device and methods of use
US6949816B2 (en) 2003-04-21 2005-09-27 Motorola, Inc. Semiconductor component having first surface area for electrically coupling to a semiconductor chip and second surface area for electrically coupling to a substrate, and method of manufacturing same
US9066695B2 (en) 1998-04-30 2015-06-30 Abbott Diabetes Care Inc. Analyte monitoring device and methods of use
US8465425B2 (en) 1998-04-30 2013-06-18 Abbott Diabetes Care Inc. Analyte monitoring device and methods of use
US6175752B1 (en) 1998-04-30 2001-01-16 Therasense, Inc. Analyte monitoring device and methods of use
US6195685B1 (en) * 1998-05-22 2001-02-27 International Business Machines Corporation Flexible event sharing, batching, and state consistency mechanisms for interactive applications
US6222916B1 (en) * 1998-05-22 2001-04-24 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for introducing and modifying telecommunications services
US6353837B1 (en) * 1998-06-30 2002-03-05 Emc Corporation Method and apparatus providing mass storage access from systems using different meta-data formats
US20060241943A1 (en) * 2005-02-16 2006-10-26 Anuthep Benja-Athon Medical vocabulary templates in speech recognition
US6907609B1 (en) * 1999-02-01 2005-06-14 Iona Technologies Plc. Object request dispatch using matching of a segmented object key
US6711629B1 (en) * 1999-10-18 2004-03-23 Fisher-Rosemount Systems, Inc. Transparent support of remote I/O in a process control system
US6658660B1 (en) * 1999-12-31 2003-12-02 Nortel Networks Limited System and method of automatically modifying source code for marshaling, unmarshaling and marking modified data objects
FI20001617A (fi) * 2000-07-06 2002-01-07 Nokia Mobile Phones Ltd Tiedonsiirtomenetelmõ ja -jõrjestely
US7543304B2 (en) * 2000-12-14 2009-06-02 Borland Software Corporation Method for efficient location of corba objects based on an unmarshaled object key in a request
US6560471B1 (en) 2001-01-02 2003-05-06 Therasense, Inc. Analyte monitoring device and methods of use
US7041468B2 (en) 2001-04-02 2006-05-09 Therasense, Inc. Blood glucose tracking apparatus and methods
FI20011239A (fi) 2001-06-12 2002-12-13 Nokia Corp Tiedonsiirtomenetelmä ja -järjestely
US7032230B2 (en) * 2001-08-27 2006-04-18 International Business Machines Corporation Efficient virtual function calls for compiled/interpreted environments
US20030192038A1 (en) * 2002-04-09 2003-10-09 Thomas Hagmann Linking data objects to a project development system
US20040073598A1 (en) * 2002-09-06 2004-04-15 Eftia Oss Solutions Inc. System-to-system inter-operation interface
US8771183B2 (en) 2004-02-17 2014-07-08 Abbott Diabetes Care Inc. Method and system for providing data communication in continuous glucose monitoring and management system
US7811231B2 (en) 2002-12-31 2010-10-12 Abbott Diabetes Care Inc. Continuous glucose monitoring system and methods of use
US7587287B2 (en) 2003-04-04 2009-09-08 Abbott Diabetes Care Inc. Method and system for transferring analyte test data
US8066639B2 (en) * 2003-06-10 2011-11-29 Abbott Diabetes Care Inc. Glucose measuring device for use in personal area network
US8312473B2 (en) * 2004-04-26 2012-11-13 Sony Computer Entertainment Inc. Specifying parameters for selective return to an invoker
US7921216B2 (en) * 2005-02-01 2011-04-05 Microsoft Corporation System and method for building and using communication binding objects
US20060247504A1 (en) * 2005-04-29 2006-11-02 Honeywell International, Inc. Residential monitoring system for selected parameters
US8112240B2 (en) 2005-04-29 2012-02-07 Abbott Diabetes Care Inc. Method and apparatus for providing leak detection in data monitoring and management systems
US7881939B2 (en) * 2005-05-31 2011-02-01 Honeywell International Inc. Monitoring system with speech recognition
US7405653B2 (en) * 2005-06-13 2008-07-29 Honeywell International Inc. System for monitoring activities and location
US9060681B2 (en) * 2005-06-30 2015-06-23 Honeywell International Inc. Trend monitoring system with multiple access levels
US20070024439A1 (en) * 2005-07-26 2007-02-01 Tice Lee D Monitoring system for a residence
EP1922153A4 (de) * 2005-08-08 2008-09-24 Guardian Industries Durchsichtige artikel mit antireflexionsschicht und herstellungsverfahren dafür
US8121855B2 (en) * 2005-09-12 2012-02-21 Mymedicalrecords.Com, Inc. Method and system for providing online medical records
US8117045B2 (en) 2005-09-12 2012-02-14 Mymedicalrecords.Com, Inc. Method and system for providing online medical records
US7511623B2 (en) * 2005-09-14 2009-03-31 Honeywell International Inc. In-residence monitoring system incorporating voice output
US7766829B2 (en) 2005-11-04 2010-08-03 Abbott Diabetes Care Inc. Method and system for providing basal profile modification in analyte monitoring and management systems
US7620438B2 (en) 2006-03-31 2009-11-17 Abbott Diabetes Care Inc. Method and system for powering an electronic device
US8226891B2 (en) 2006-03-31 2012-07-24 Abbott Diabetes Care Inc. Analyte monitoring devices and methods therefor
WO2007143225A2 (en) 2006-06-07 2007-12-13 Abbott Diabetes Care, Inc. Analyte monitoring system and method
US8930203B2 (en) 2007-02-18 2015-01-06 Abbott Diabetes Care Inc. Multi-function analyte test device and methods therefor
US8732188B2 (en) 2007-02-18 2014-05-20 Abbott Diabetes Care Inc. Method and system for providing contextual based medication dosage determination
US8123686B2 (en) 2007-03-01 2012-02-28 Abbott Diabetes Care Inc. Method and apparatus for providing rolling data in communication systems
US20080249805A1 (en) * 2007-04-04 2008-10-09 Amit Kumar Singh Smart clinical data clipboard
US8456301B2 (en) 2007-05-08 2013-06-04 Abbott Diabetes Care Inc. Analyte monitoring system and methods
US8461985B2 (en) 2007-05-08 2013-06-11 Abbott Diabetes Care Inc. Analyte monitoring system and methods
US8665091B2 (en) 2007-05-08 2014-03-04 Abbott Diabetes Care Inc. Method and device for determining elapsed sensor life
US7928850B2 (en) 2007-05-08 2011-04-19 Abbott Diabetes Care Inc. Analyte monitoring system and methods
US8103456B2 (en) 2009-01-29 2012-01-24 Abbott Diabetes Care Inc. Method and device for early signal attenuation detection using blood glucose measurements
US9226701B2 (en) 2009-04-28 2016-01-05 Abbott Diabetes Care Inc. Error detection in critical repeating data in a wireless sensor system
US9184490B2 (en) 2009-05-29 2015-11-10 Abbott Diabetes Care Inc. Medical device antenna systems having external antenna configurations
WO2011026148A1 (en) 2009-08-31 2011-03-03 Abbott Diabetes Care Inc. Analyte monitoring system and methods for managing power and noise
US9314195B2 (en) 2009-08-31 2016-04-19 Abbott Diabetes Care Inc. Analyte signal processing device and methods
WO2011041469A1 (en) 2009-09-29 2011-04-07 Abbott Diabetes Care Inc. Method and apparatus for providing notification function in analyte monitoring systems
US20110314256A1 (en) * 2010-06-18 2011-12-22 Microsoft Corporation Data Parallel Programming Model
US8589867B2 (en) 2010-06-18 2013-11-19 Microsoft Corporation Compiler-generated invocation stubs for data parallel programming model
US9980669B2 (en) 2011-11-07 2018-05-29 Abbott Diabetes Care Inc. Analyte monitoring device and methods
US9968306B2 (en) 2012-09-17 2018-05-15 Abbott Diabetes Care Inc. Methods and apparatuses for providing adverse condition notification with enhanced wireless communication range in analyte monitoring systems
CN103093142B (zh) * 2012-12-26 2015-07-22 飞天诚信科技股份有限公司 一种Java卡对象访问的控制方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69327448T2 (de) * 1992-12-21 2004-03-04 Sun Microsystems, Inc., Mountain View Verfahren und Vorrichtung für Teilaufgaben in verteiltem Verarbeitungssystem
DE69426143T2 (de) * 1993-09-10 2001-06-13 Sun Microsystems Inc Kundenseitiger Stubinterpretor
US5737607A (en) * 1995-09-28 1998-04-07 Sun Microsystems, Inc. Method and apparatus for allowing generic stubs to marshal and unmarshal data in object reference specific data formats
US5758186A (en) * 1995-10-06 1998-05-26 Sun Microsystems, Inc. Method and apparatus for generically handling diverse protocol method calls in a client/server computer system
US5815708A (en) * 1995-10-06 1998-09-29 Sun Microsystems, Inc. Method and apparatus for dynamically loading method call exception code in response to a software method exception generated in a client/server computer system

Also Published As

Publication number Publication date
DE69734175D1 (de) 2005-10-20
US6032199A (en) 2000-02-29
US6389484B1 (en) 2002-05-14
EP0817027A2 (de) 1998-01-07
EP0817027B1 (de) 2005-09-14
EP0817027A3 (de) 1999-03-31
JPH1063506A (ja) 1998-03-06
US6167458A (en) 2000-12-26

Similar Documents

Publication Publication Date Title
DE69734175T2 (de) Transportunabhängige Anruf- und Dienstschnittstellen, die die Marshalling von integrierten Type-Codes sowie kompilierten Code erlauben
US6044409A (en) Framework for marshaling and unmarshaling argument object references
DE69327448T2 (de) Verfahren und Vorrichtung für Teilaufgaben in verteiltem Verarbeitungssystem
DE69936627T2 (de) In einer warteschlange angeordnete aufrufe von prozeduren für verteilte auf komponenten basierte anwendungen
DE60035745T2 (de) Verfahren zum bei Bedarf Laden und Ausführen einer Netzwerkanwendung
DE60125705T2 (de) Vorrichtung und Verfahren zur Implementierung eines HTTP Programmstacks auf einem Client
DE69630480T2 (de) Verfahren, Vorrichtung und Datenstrukturen zur Objektverwaltung
DE69936162T2 (de) Verfahren und Gerät für ein objektorientiertes Unterbrechungssystem
DE69730690T2 (de) Verfahren und apparat zum dynamischen austausch von objekt-nachrichten zwischen objekt-modellen
DE60126016T2 (de) Serverseitige Kontrollobjekte zur Verarbeitung von kundenseitigen Benutzerschnittstellenelementen
DE60207155T2 (de) Objektorientiertes Internetschnittstellensystem für eine industrielle Steuereinrichtung
DE60211254T2 (de) Fernereignis Behandlung in ein Paketnetzwerk
US6083277A (en) Filtering an object interface definition to determine services needed and provided
DE69635337T2 (de) Erweiterbares und austauschbares system von netzwerkkomponenten
DE69832354T2 (de) Netzwerkverwaltungsrahmenwerk
US5729739A (en) Persistent object mapping system and method with abstract schema mapper
US7127724B2 (en) Method and apparatus for providing protocol independent naming and life cycle services in an object-oriented system
EP0912014B1 (de) Verfahren, Vorrichtung, und Programmprodukt zum Zugriff auf einen Server-basierten Verwaltungsinformationsdienst
DE60031370T2 (de) Tokenbasierte verknüpfung
DE69733266T2 (de) Ausfallsicheres und ereignisgesteuertes transaktions-system und verfahren
DE69637436T2 (de) Objektorientiertes Kommunikationssystem mit Unterstützung für mehrere entfernte Maschinentypen
US20020038390A1 (en) Method and apparatus for fast, local corba object references
DE69727933T2 (de) Verfahren und gerät zum beschreiben einer definierten schnittstelle, einer operation und eines datentyps in einer schnittstellendefinitionssprache
Szymanski Embedded internet technology in process control devices
Radestock et al. Coordination in evolving systems

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee