DE69615978T2

DE69615978T2 - Verfahren und Vorrichtung zum Verpackung und Entpackung von Daten in objectreferenzspezifischen Datenformaten anhand generischen Stubs

Info

Publication number: DE69615978T2
Application number: DE69615978T
Authority: DE
Inventors: Graham Hamilton; Peter B. Kessler; Swee Boon Lim; Jeffrey D. Nisewanger; Sanjay R. Radia
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1995-09-28
Filing date: 1996-07-25
Publication date: 2002-04-11
Anticipated expiration: 2016-07-26
Also published as: US5737607A; JPH09231076A; DE69615978D1; EP0766172A1; EP0766172B1

Description

Die vorliegende Erfindung betrifft die Bereiche verteilte Rechnersysteme, Client-Server-Rechner und objektorientierte Programmierung.
Die vorliegende Erfindung betrifft insbesondere ein Verfahren und eine Vorrichtung zum Bereitstellen von Programmmechanismen, mit denen generische Stubs Daten in Objektreferenz-spezifischen Datenformaten marshalieren und zurückmarshalieren.
Ein Hauptproblem in modernen objektorientierten verteilten Verarbeitungssystemen besteht darin, es Objektanwendungen zu erlauben, mit einem neuen Object Request Broker ("ORB") zu kommunizieren, der sein eigenes individuelles Datenformat hat, mit nur geringfügigen Modifikationen an den unterstützenden Codemechanismen. Ebenso sollten Client-Anwendungen und -Stubs in der Lage sein, nahtlos mit verschiedenen ORBs in einem System zu kommunizieren, das mit einer Vielzahl von ORBs kommunizieren kann, wobei jeder der ORBs sein eigenes individuelles Datenformat hat.
So ist beispielsweise die Object Management Group (OMG) eine Industriestandard-Organisation, die Multivendor-Normen für verteilte objektorientierte Programmierung schafft. Einer der Ecksteine der OMG-Arbeit war die Definition einer gemeinsamen Interface Definition Language, IDL genannt, die heute weitverbreitet standardmäßig für die Definition von Schnittstellen zu Netzwerkobjektene unabhängig von den jeweiligen verwendeten Netzwerkprotokollen oder der jeweiligen; von den Clients und Servers verwendeten Programmiersprache eingesetzt wird.
Die IDL-Sprache ist objektorientiert und unterstützt mehrfache Vererbung. Sie weist einen reichhaltigen Satz an eingebauten primitiven Typen (wie z. B. Task- Intervalle, boolesche Verknüpfungen usw.) auf und definiert auch einen Satz strukturierter Typen wie z. B. Structs, Vereinigungen und Sequenzen.
Die Object Management Group standardisierte die IDL- Schnittstellendefinitionssprache als einheitliche Art und Weise der Definition von Schnittstellen zu Netzwerkobjekten. Die OMG ließ jedoch zunächst das On-the-Wire- Protokoll und die Datenformate undefiniert. In Folge dessen implementierten unterschiedliche Vendoren ORBs mit verschiedenen Protokollen und Datenformaten.
Die OMG hat sich kürzlich auf ein gemeinsames ORB- Interoperabilitätsprotokoll geeinigt, das Universal Networked Objects (UNO) Protokoll. Dies wird jedoch vornehmlich als Gateway-Protokoll für die Verbindung von Objektsystemen von verschiedenen Vendoren angesehen. Es scheint, dass verschiedene Vendoren wenigstens kurzfristig ihre existierenden Protokolle zur Erhöhung der Leistungen innerhalb ihrer eigenen Objektsysteme wahrscheinlich weiter verwenden und UNO-Gateways niedrigerer Leistung zu anderen ORBs unterstützen. Somit besteht derzeit der Bedarf, es Objektanwendungen zu erlauben, auf transparente Weise mit diesen ORBs mit verschiedenen Protokollen und Datenformaten zu kommunizieren.
Eine weitergehende Beschreibung der objektorientierten Design- und Programmierungstechniken befindet sich in "Object-oriented Software Construction" von Bertrand Meyer, Prentice-Hall 1988. Weitere Informationen über OMG, CORBA, ORBs und IDL siehe "Common Object Request Broker: Architecture and Specification", Revision 2.0, Juli 1955.
Momentan sind Internet-Browser im Hinblick auf ihre Fähigkeit, mit Netzwerk-Servern zu interagieren, sehr begrenzt. Ein Browser wie beispielsweise Mosaic lädt gewöhnlich ein HTML-Dokument herunter und wartet dann passiv, bis ein menschlicher Benutzer entweder ein anderes Dokument wählt oder Informationen im HTML-Format eingibt, die dann zurück zum Server geleitet werden.
Zwei neue Entwicklungen sehen vielversprechend aus, um das Internet zu einer dynamischeren Umgebung zu machen. Die erste ist die Unterstützung für Skriptsprachen in Internet-Browsern (wie z. B. die nachfolgend beschriebene JAVA- Sprache von Sun Microsystems, Inc. (SUN), so dass ein Browser interaktive Skripte herunterladen und ausführen kann. Damit sind dann Browser nicht mehr nur passive Betrachter, sondern sie werden zu dynamischen Agenten, die mit dem Internet für einen Benutzer interagieren und sich rasch ändernde Informationen anzeigen können. Die zweite Entwicklung ist die weit verbreitete Übernahme der verteilten Objektschnittstellen auf der Basis der IDL-Schnittstellendefinitionssprache der Object Management Group. Dies ergibt eine Standardmöglichkeit für Netzwerk-Server, um Dienste wie "Netzwerkobjekte" in einer sprach- und vendorunabhängigen Weise zu exportieren. So wird es weitaus leichter, Netzwerkdienste zu erstellen, auf die transparent von verschiedenen Client-Umgebungen aus zugegriffen werden kann.
Die EP-0604010 offenbart eine Vorrichtung und ein Verfahren, umfassend ein Logikmodul mit der Bezeichnung Subcontract, das die Aufgabe hat, die Basismechanismen von Objektaufruf und Argumentweiterleitung zu steuern, die in verteilten Systemen am Wichtigsten sind, und zwar auf eine Weise, die es Objektimplementoren erleichtert, einen existierenden Subcontract auszuwählen und zu verwenden, und die es den Anwendungsprogrammierern erlaubt, keine Kenntnis über die spezifischen Subcontracts zu haben, die für bestimmte Objekte verwendet werden.
Dazu gehört ein neuer Objekttyp, als "Spring-Objekt" bezeichnet, der eine Methodentabelle, einen Subcontract-Mechanismus und eine Datenstruktur beinhaltet, die den lokalen Privatzustand des Subcontracts repräsentiert.
Jeder Subcontract enthält einen clientseitigen Teil und einen zugehörigen serverseitigen Teil. Jeder Objekttyp hat einen assoziierten Subcontract. Der clientseitige Teil eines Subcontracts hat die Fähigkeit, ein neues Spring-Objekt zu erzeugen, ein Spring-Objekt zu löschen, Informationen über sein assoziiertes Objekt in einen Kommunikationspuffer zu marshalieren, Daten in einem Kommunikationspuffer, der ein assoziiertes Objekt repräsentiert, zurückzumarshalieren, einen Kommunikationspuffer zu seinem assoziierten serverseitigen Subcontract zu senden, was entweder das Senden eines Objekts von einem Ort zum anderen oder das Senden einer Kopie eines Objekts von einem Ort zum anderen beinhaltet. Der serverseitige Teil des Subcontract-Mechanismus beinhaltet die Fähigkeit, ein Spring-Objekt zu schaffen, Unterstützung für die Verarbeitung eingehender Rufe und zugehöriger Kommunikationspuffer sowie Unterstützung für die Revokation eines Objekts bereitzustellen.
Hierzu gehören auch Methoden für die Verwendung von Subcontracts zum Verarbeiten von Objektaufrufen, einschließlich des Weiterleitens von Argumenten, wobei diese Argumente an sich Objekte sein können, in einem verteilten Computersystem, wobei sich die Client-Anwendungen auf anderen Computern als die Objektimplementationen befinden können.
Die EP-0643349 offenbart eine Vorrichtung und ein Verfahren, umfassend Logikmodule, die als clientseitige Stubgeneratoren bezeichnet werden, eine Datenbank für komprimierten clientseitigen Stub-Ausführungscode und einen clientseitigen Stub-Interpreter, die die Aufgabe haben, den von clientseitigen Stubs benötigten Speicherraum zu minimieren und gleichzeitig das Design von Stubs zu behalten, um die Steuerung der Basismechanismen von Objektaufruf und Argumentweiterleitung bereitzustellen, die in verteilten Systemen am Wichtigsten sind, so dass Anwendungsprogrammierer die spezifischen Stubs nicht zu kennen brauchen, die für bestimmte Objekte verwendet werden.
Der zum Reduzieren dieses Speicherraums verwendete Mechanismus umfasst einen Stub-Generator ("CONTOCC" genannt) zum Erzeugen einer Datenbank aus komprimierten clientseitigen Stub-Beschreibungsdateien, die im Computerspeicher gespeichert sind, und einen Stub-Interpreter, der weiß, wie diese clientseitigen Stub- Beschreibungsdateien zu lesen sind. CONTOCC liest Dateien in der Schnittstellendefinitionssprache ("IDL") und erzeugt entsprechende C++ Dateien. CONTOCC hat die Fähigkeit, die IDL-Daten zu lesen und entweder unkomprimierte C++ Stub-Dateien oder die speziellen komprimierten clientseitigen Stub-Interpreter- Dateien zu erzeugen, die nur diejenigen Daten enthalten, die für das in der Bytekodierten Form beteiligte jeweilige Stub-Verfahren individuell sind.
Das Stub-Interpreter-Logikmodul empfängt ein Zielobjekt, Argumente in Bezug auf das jeweilige aufgerufene Stub-Verfahren sowie einen Zeiger auf die komprimierten Byte-Code-Repräsentationen des Stub-Codes in der Datenbank von komprimierten clientseitigen Stub-Beschreibungsdateien, die im Computerspeicher gespeichert sind, und fährt mit der Ausführung von Objektaufruf, Marshalieren oder Zurückmarshalieren von Rückgabemeldungen nach Bedarf fort.

Java

Java ist eine stark typisierte objektorientierte Sprache mit einer C-ähnlichen Syntax. Der Java-Compiler und die Laufzeit-Code-Mechanismen gewährleisten Typensicherheit, so dass es keine Wild-Pointers oder anderen Referenzen gibt, die das Typensystem der Sprache verletzen. So gibt es beispielsweise kein "Void*" (Leerstellen), und alle Casts werden in Laufzeit validiert.
Die Java-Sprache wird typischerweise in maschinenunabhängige Byte-Codes kompiliert, danach interpretiert eine virtuelle Java-Maschine diese Byte-Codes, um das Java-Programm auszuführen. Java kann in Netzwerk-HTML-Browser integriert werden, so dass im Rahmen des Betrachtens eines Dokumentes ein Satz von Java- Byte-Codes heruntergeladen und dann auf der Client-Maschine ausgeführt werden kann. Da Java vollständig typensicher ist, kann der Client-Browser sicher sein, dass das Java-Programm sicher ausgeführt werden kann, ohne dass Sicherheit oder Integrität des Clients gefährdet werden. Java ist ausführlicher in "The Java Language Specification", Release 1.0 Alpha3, von Sun Microsystems, Inc. vom 11. Mai 1995 beschrieben.
Skriptsprachensysteme wie Java erzeugen Java-Programme, die portabel entwickelt sind und in einer Reihe verschiedener Umgebungen eingesetzt werden können. Es ist daher wünschenswert, dass Java-Programme verschiedene ORBs verwenden können, ohne dass das Java-Programm auf irgendeine Weise geändert werden müßte. Da die erzeugten Stubs Teil des Java-Programms sind, ist es notwendig, dass die Stubs ORB-unabhängig sind, so dass das Java-Programm und seine assoziierten Stubs in beliebigen aus einer Vielzahl von ORBs verwendet werden können.
Die vorliegende Offenbarung beschreibt eine Lösung für das Grundproblem durch Erzeugen einer generischen Schnittstelle zwischen den Stubs und ORB- spezifischen Datenmechanismen. Diese ORB-spezifischen Datenmechanismen beinhalten ein oder mehrere MarshalBuffer-Objekte, die Methoden zum Marshalieren und Zurückmarshalieren von einem oder mehreren bestimmten ORB-bezogenen On- the-Wire-Datenformaten haben, sowie ein Verfahren und eine Vorrichtung zum Verwenden einer Objektreferenz (Objref), um das jeweilige MarshalBuffer-Objekt für die Verwendung für diesen bestimmten Objektaufruf anzuzeigen.
Die vorliegende Erfindung stellt eine elegante und einfache Möglichkeit bereit, um Mechanismen für den Aufruf von Objekten durch Client-Anwendungen sowie für Argumentweiterleitungen zwischen Client-Anwendungen und Objektimplementationen bereitzustellen, ohne dass die Client-Anwendung oder das Betriebssystem die Einzelheiten der Arbeitsweise dieser Mechanismen kennt. Darüber hinaus arbeiten diese Mechanismen in einer verteilten Computer-Umgebung mit ähnlicher Leichtigkeit und Effizienz, wobei Client-Anwendungen ein Computer- Knoten und Objektimplementationen aufeinander sein können.
In einem Aspekt der Erfindung wird ein Computersystem mit einem Prozessor, einem Speicher, einem Anzeigegerät, einem Ein-Ausgabegerät und einem Betriebssystem (OS) zum Verarbeiten von Aufrufen von Programmcodemechanismen bereitgestellt, die an einen aus einer Vielzahl von ortsfernen Objekt Request Brokern (ORBs) gerichtet sind, dadurch gekennzeichnet, dass das Computersystem ferner folgendes umfasst:
eine ORB-unabhängige Schicht von Codemechanismen einschließlich Programmanwendungen und zugehörigen Stubs; und
eine ORB-abhängige Schicht von Codemechanismen, die mit der ORB- unabhängigen Schicht gekoppelt ist, wobei die ORB-abhängige Schicht folgendes umfasst:
Programmcodemechanismen, die ORB-spezifisch und so konfiguriert sind, dass sie einen Marshal-Codemechanismus zum Marshalieren (Einsortieren) von Daten in einem von dem ORB benötigten Format zu erzeugen, und
Programmcodemechanismen, die so konfiguriert sind, dass sie einen spezifischen Netzwerkprotokollcode verwenden, so dass ein Programmanwendungscode-Mechanismus von der ORB-unabhängigen Schicht einen Aufruf an einen ortsfernen Implementationsprogrammcode-Mechanismus einleiten kann, und die ORB-spezifischen Programmcodemechanismen in der ORB-abhängigen Schicht einen geeigneten Marshal-Codemechanismus ermitteln, um Daten in einem vom ORB benötigten Format zu marschalieren;
so dass ein Computersystem entsteht, das mit einer Vielzahl von ORBs kommunizieren kann, wobei jeder ORB ein spezielles Datenformat verlangt. In einem weiteren Aspekt der Erfindung wird ein Verfahren zum Betreiben eines Computersystems mit einem Prozessor, einem Speicher, einem Display, einem Ein-Ausgabemechanismus, einem Betriebssystem und wenigstens einem Client- Anwenderprogramm, einem oder mehreren Stub-Programmen in Bezug auf die Client-Anwendung bereitgestellt, wobei das mit dem Computer durchgeführte Verfahren durch die folgenden Schritte gekennzeichnet ist:
Einleiten eines Aufrufs an einen Programmimplementationscode- Mechanismus, wobei der Aufruf durch eine Client-Anwendung erfolgt, wobei der Aufruf eine Referenz auf den Programmimplementationscode-Mechanismus beinhaltet;
Verwenden eines Stubprogrammcode-Mechanismus, der sich auf die Client- Anwendung zum Empfangen des Aufrufs bezieht, wobei der Stubprogrammcode- Mechanismus das Format nicht kennt, das zum Marshalieren von Daten benötigt wird, die von der Client-Anwendung in Verbindung mit der Aufrufeinleitung bereitgestellt werden;
Aufrufen eines ersten spezifischen Programmcodemechanismus durch den Stubprogrammcode-Mechanismus, Anfordern des ersten spezifischen Programmcodemechanismus zur Bereitstellung eines MarshalBuffer- Codemechanismus, der weiß, wie von der Client-Anwendung bereitgestellte Daten in Verbindung mit dem Aufruf formatiert werden;
Marshalieren der von der Client-Anwendung bereitgestellten Daten in Verbindung mit dem Aufruf, wobei die Marshalierung vom Stubprogrammcode- Mechanismus mit Hilfe des MarshalBuffer-Codemechanismus erfolgt; und Senden des Aufrufs zu einem Server, der den Programmimplementationscode- Mechanismus enthält, der das Ziel des Rufs ist.
In einem weiteren Aspekt der Erfindung wird ein Computerprogrammprodukt bereitgestellt, umfassend: ein in einem Computersystem benutzbares Speichermedium, in dem rechnerlesbarer Code eingebettet ist, mit dem veranlasst werden kann, dass ein Computersystem Programmcodemechanismus-Aufrufe verarbeitet, die an einen aus einer Vielzahl von ortsfernen Object Request Brokern (ORBs) gerichtet sind, wobei das Computerprogrammprodukt gekennzeichnet ist durch:
einen ersten rechnerlesbaren Programmcodemechanismus, der so konfiguriert ist, dass er eine ORB-unabhängige Schicht von Codemechanismen umfasst, einschließlich Client-Anwendungen und zugehörigen Stubprogrammcode- Mechanismen; und
einen zweiten rechnerlesbaren Programmcodemechanismus, der so konfiguriert ist, dass er eine ORB-abhängige Schicht von Codemechanismen umfasst, die mit der ORB-unabhängigen Schicht gekoppelt sind, wobei die ORB-abhängige Schicht Programmcodemechanismen umfasst, die ORB-spezifisch und so konfiguriert sind, dass sie einen Marshal-Codemechanismus zum Marshalieren von Daten in einem vom ORB benötigten Format erzeugt, und Programmcodemechanismen, die so konfiguriert sind, dass sie einen spezifischen Netzwerkprotokollcode benutzen, so dass ein Programmanwendungscode-Mechanismus von der ORB-unabhängigen Schicht einen Ruf auf einem ortsfernen Implementationsprogrammcodemechanismus einleiten kann, und die ORB-spezifischen Programmcodemechanismen in der ORB- abhängigen Schicht einen geeigneten Marshal-Codemechanismus zum Marshalieren von Daten in einem vom ORB benötigten Format bestimmen, so dass ein Computersystem bereitgestellt wird, das in der Lage ist, mit einer Vielzahl von ORBs zu kommunizieren, wobei jeder ORB Daten in einem bestimmten Format verlangt.
Die vorliegende Erfindung wird nachfolgend beispielhaft unter Bezugnahme auf die Begleitzeichnungen näher beschrieben. Dabei zeigt:
Fig. 1 die Konfiguration eines typischen Computerhardwaresystems, das mit und im Rahmen der vorliegenden Erfindung eingesetzt wird;
Fig. 2 die Beziehung von Client- und Server-Anwendungen des Standes der Technik zu Stubs und Netzsoftware;
Fig. 3 ein System, das Java ORB-Klassen illustriert;
Fig. 4 die Beziehung zwischen Stub-Objekten, ORB-spezifischen Code/Subcontract-Mechanismen sowie Server-Anwendungsobjekten in einem einzelnen ORB-System;
Fig. 5 Fern-Objektaufruf mit ORB-spezifischen Code/Subcontracts, ORB- spezifischen MarshallBuffer-Mechanismen in einem Multi-ORB-System;
Fig. 6 einen beispielhaften MarshallBuffer-Codemechanismus;
Fig. 7 einen spezifischeren Fernobjektaufruf mit ORB-spezifischen Code/Subcontracts, ORB-spezifischen MarshallBuffer-Mechanismen in einem Multi- ORB-System.

NOTATIONEN UND NOMENKLATUR

Die nachfolgenden ausführlichen Beschreibungen können im Sinne von Programmprozeduren dargestellt werden, die auf einem Computer oder einem Netzwerk von Computern ausgeführt werden. Diese Prozedurbeschreibungen und - darstellungen sind das Mittel, mit dem die Fachperson die Substanz ihrer Arbeit anderen Fachpersonen auf effektivste Weise übermittelt.
Eine Prozedur wird hier und allgemein als eine in sich einheitliche Sequenz von Schritten angesehen, die zu einem gewünschten Ergebnis führen. Diese Schritte sind diejenigen, die physikalische Manipulationen physikalischer Quantitäten erfordern. Diese Quantitäten haben gewöhnlich, aber nicht unbedingt, die Form von elektrischen oder magnetischen Signalen, die gespeichert, übertragen, kombiniert, verglichen und auf andere Weise manipuliert werden können. Es ist zuweilen praktisch, hauptsächlich aus Gründen des allgemeinen Gebrauchs, diese Signale als Bits, Werte, Elemente, Symbole, Zeichen, Terme, Zahlen oder dergleichen zu bezeichnen. Es ist jedoch zu bemerken, dass alle diese und ähnliche Terme mit den entsprechenden physikalischen Quantitäten assoziiert werden müssen und lediglich praktische Bezeichnungen für diese Quantitäten sind.
Ferner werden die durchgeführten Manipulationen häufig mit Begriffen bezeichnet, wie z. B. Addieren oder Vergleichen, die allgemein mit mentalen Vorgängen assoziiert werden, die von einem menschlichen Operator ausgeführt werden. Es ist keine solche Fähigkeit eines menschlichen Operators in den hier beschriebenen Vorgängen, die Teil der vorliegenden Erfindung darstellen, notwendig oder in den meisten Fällen auch nur wünschenswert; die Vorgänge sind Maschinenvorgänge. Nützliche Maschinen für die Durchführung der Vorgänge der vorliegenden Erfindung beinhalten universelle digitale Computer oder ähnliche Geräte.
Die vorliegende Erfindung bezieht sich auch auf eine Vorrichtung zum Ausführen dieser Vorgänge. Diese Vorrichtung kann speziell für die gewünschten Zwecke konstruiert werden oder sie kann einen Universalcomputer umfassen, der selektiv von einem im Computer gespeicherten Computerprogramm aktiviert oder umkonfiguriert wird. Die hierin dargestellten Prozeduren beziehen sich nicht automatisch auf einen bestimmten Computer oder eine andere bestimmte Vorrichtung. Verschiedene Universalmaschinen können mit Programmen verwendet werden, die gemäß den hierin gegebenen Lehren geschrieben wurden, oder es kann sich als praktischer erweisen, spezialisiertere Vorrichtungen zu konstruieren, die die gewünschten Verfahrensschritte ausführen. Die benötigte Struktur für eine Auswahl dieser Maschinen geht aus der nachfolgenden Beschreibung hervor.
Die nachfolgende Offenbarung beschreibt Lösungen für die Probleme, denen Designer von objektorientierten Systemen bei dem Versuch begegnen, Schemata für Objektaufrufe und Argumentweiterleitungen in verteilten Systemen zu implementieren, wobei die Argumente Objekte sein können, auf Arten und Weisen, die das objektorientierte Basissystem nicht an Methoden binden, die sich später schwer ändern lassen. Darüber hinaus beschreibt die offenbarte Erfindung einen "MarshalBuffer-Mechanismus", der Vorgänge (im objektorientierten Programmierjargon als "Methoden" bezeichnet) zum Marshalieren von Daten für einen spezifischen ORB enthält; ein "Multi-ORB-Marshalierungssystem", das es einer Client-Anwendung und dem zugehörigen Stub erlaubt, einen Vorgang an einem Zielobjekt aufzurufen, ohne zu wissen oder berücksichtigen zu müssen, welchen ORB dieses Zielobjekt benutzt oder welches Datenformat der ORB für die Argumente des aufgerufenen Vorgangs erfordert; und ein "Computersystem für Multi-ORB- Kommunikationen", umfassend eine ORB-unabhängige Schicht, die Client- Anwendungen und Stubs enthält; eine ORB-abhängige, OS-unabhängige Schicht, die ORB-abhängige Code/Subcontract-Codemechanismen sowie ORB-spezifische MarshalBuffers für eine Vielzahl von ORBs enthält; und eine Betriebssystem-(OS) Schicht. Der in der vorliegenden Erfindung zur Anwendung kommende "ORB- abhängige Codemechanismus" ist analog zu dem "Subcontract Mechanismus", der mit jedem Objekt assoziiert und in der EP-A-0604010 beschrieben ist.
In der nachfolgenden Beschreibung werden zu Erläuterungszwecken spezifische Daten und Konfigurationen dargelegt, um ein tiefgreifendes Verständnis der vorliegenden Erfindung zu vermitteln. Die hierin beschriebene bevorzugte Ausgestaltung wird im Rahmen des objektorientierten Betriebssystems SPRING- DISTRIBUTION implementiert, das von Sun Microsystems®, Inc. entwickelt wurde (Sun Microsystems ist ein eingetragenes Markenzeichen der Sun Microsystems, Inc.). Für die Fachperson ist es jedoch offensichtlich, dass die vorliegende Erfindung auch ohne die spezifischen Einzelheiten ausgeführt und in verschiedenen Computersystemen und verschiedenen Konfigurationen sowie in Marken und Modellen von eng gekoppelten Prozessoren oder in verschiedenen Konfigurationen von lose gekoppelten Multi-Prozessor-Systemen implementiert werden kann. Das objektorientierte Betriebssystem Spring-Distribution ist in "A Spring Collection" beschrieben, einer Sammlung von Artikeln über das verteilte objektorientierte Betriebssystem von Spring, veröffentlicht im September 1994 von Sun Microsystems, Inc.

Betriebsumgebung

Die Umgebung, in der die vorliegende Erfindung zur Anwendung kommt, umfasst das allgemeine verteilte Computersystem, bei dem universelle Computer, Workstations oder Personal Computer über Kommunikationsverbindungen verschiedener Typen in einer Client-Server-Anordnung verbunden sind, in der Programme und Daten, viele in der Form von Objekten, von verschiedenen Teilen des Systems für die Ausführung und den Zugriff durch andere Elemente des Systems verfügbar gemacht werden. Einige der Elemente eines universellen Workstation- Computers sind in Fig. 1 dargestellt, in der ein Prozessor 1 mit einem Ein-Ausgabeteil ("E/A") 2, einer Zentraleinheit ("CPU") 3 und einem Speicherteil 4 gezeigt ist. Der E/A-Teil 2 ist mit einer Tastatur S. einem Display 6, einer Plattenspeichereinheit 9 und einem CD-ROM Laufwerk 7 verbunden. Das CD-ROM Gerät 7 kann ein CD- ROM Medium 8 lesen, das typischerweise Programmcode-Mechanismen 10 und Daten enthält.

Stubs

Techniken zum Bereitstellen eines Furniers auf Sprachebene für Fernbetrieb (z. B. "Fernprozeduraufrufe") werden seit vielen Jahren verwendet. Sie haben gewöhnlich die Form, dass eine Fernschnittstelle in einer Sprache definiert ist. Dann wird ein Paar Stubs von dieser Schnittstelle erzeugt. Der Client-Stub läuft auf einer Maschine und stellt eine Schnittstelle auf Sprachebene dar, die von der Fernschnittstelle abgeleitet wird. Der Server-Stub läuft auf einer anderen Maschine und ruft eine Schnittstelle auf Sprachebene auf, die von der Fernschnittstelle abgeleitet ist. Gemäß Fig. 2 ruft zur Ausführung eines Fernbetriebs eine Client- Anwendung 12 auf einer Maschine 11 den Client-Stub 14 auf, der die Argumente in Bezug auf den Aufruf in (einen) Netzwerkpuffer marshaliert und sie zum Server-Stub 22 auf der Fernmaschine 18 sendet, die die Argumente von dem/den Netzwerkpuffer(n) zurückmarshaliert und die Server-Anwendung 24 aufruft. Ebenso werden, wenn die Server-Anwendung 24 eine Antwort zurücksendet, die Ergebnisse vom Server-Stub 22 hinaufmarshaliert und zum Client-Stub 14 zurückgegeben, der die Ergebnisse zurückmarshaliert und sie zur Client-Anwendung 12 zurückgibt. Die gesamte Mechanik von Argument- und Ergebnisübertragung sowie von Fernobjektaufruf wird in den Stubs ausgeführt. Sowohl Client-Anwendung als auch Server-Anwendung arbeiten nur im Sinne von konventionellen Schnittstellen auf Sprachebene.
Wenn die Argumente oder Ergebnisse einfach Werte wie z. B. ganze Zahlen oder Strings sind, dann sind die Vorgänge von Marshalieren und Zurückmarshalieren recht einfach. Die Stubs setzen normalerweise einfach den buchstäblichen Wert des Arguments in den Netzwerkpuffer. In Sprachen, die abstrakte Datentypen oder Objekte unterstützen, wird das Marshalieren jedoch weitaus komplexer. Eine Lösung besteht darin, dass Stubs die internen Datenstrukturen des Objekts marshalieren und diese Daten dann in ein neues Objekt zurückmarshalieren. Dies hat mehrere ernsthafte Mängel. Zunächst stellt dies eine Verletzung des "Abstraktions"-Prinzips der objektorientierten Programmierung dar, da Stubs das Innenleben von Objekten nicht zu kennen brauchen. Zweitens ist es notwendig, dass Server- und Client- Implementationen des Objektes dasselbe interne Layout für ihre Datenstrukturen verwenden. Drittens kann dies das Marshalieren von großen Mengen unnötiger Daten beinhalten, weil nicht unbedingt der gesamte interne Zustand des Objekts zu der anderen Maschine übertragen zu werden braucht. Eine alternative Lösung ist die, dass beim Marshalieren eines Objektes nichts von seinem internen Zustand übertragen wird. Stattdessen wird eine Identifikationsmarke für das Objekt erzeugt, und diese Marke wird übertragen. So werden beispielsweise im Eden-System Objekten Namen zugeordnet, und wenn ein Objekt marshaliert wird, dann wird nur dieser Name anstatt der eigentlichen Darstellung marshaliert. Demzufolge müssen Fernmaschinen, wenn sie an diesem Objekt arbeiten wollen, den Namen benutzen, um den ursprünglichen Ort des Objekts zu ermitteln, und ihre Aufrufe zu diesem Ort senden. Dieser Mechanismus ist für schwerwiegende Objekte wie z. B. Dateien oder Datenbanken geeignet, ist aber häufig für leichte Abstraktionen wie z. B. ein Objekt ungeeignet, das ein kartesisches Koordinatenpaar repräsentiert, wo es weitaus besser gewesen wäre, den echten Zustand des Objektes zu marshalieren. Schließlich bieten einige objektorientierte Programmiersysteme das Mittel für eine Objektimplementation, um zu steuern, wie seine Argumente marshaliert und zurückmarshaliert werden. So können beispielsweise im Argus-System Objektimplementoren Funktionen bereitstellen, um zwischen ihrer internen Darstellung und einer spezifischen, konkreten externen Darstellung abzubilden. Die Argus-Stubs rufen die entsprechenden Abbildungsfunktionen beim Marshalieren und Zurückmarshalieren von Objekten auf, so dass die externe Darstellung anstatt einer bestimmten internen Darstellung gesendet wird. Diese verschiedenen Lösungen legen entweder eine einzelne standardmäßige Marshalierungsstrategie für alle Objekte auf oder sie erfordern es, dass individuelle Objektimplementoren die Verantwortung für die Einzelheiten der Marshalierung übernehmen. Ein weiterentwickelter Objektmarshalierungsprozess wird in der oben erwähnten EP-A-0604010 beschrieben, die "Subcontracts" beschreibt.

Zusammenfassung des derzeitigen Problems

Spezifisches Problem für derzeitige objektorientierte Systeme

Das spezifische Problem besteht hier darin, dass verschiedene ORBs unterschiedliche On-the-Wire-Datenformate haben. So könnte beispielsweise ein ORB Bytes in Little-Endian-Reihenfolge, ein anderer in Big-Endian-Reihenfolge usw. marshalieren. Verschiedene ORBs haben unterschiedliche On-the-Wire-Formate für Arrays, Strings, Vereinigungen usw.
Es ist somit wünschenswert, ORB-unabhängige Stubs zu haben, die ihre Daten auf verschiedene Weise marshalieren können, wenn sie mit verschiedenen Objekten kommunizieren. So könnte man beispielsweise ein DEC-Datenformat beim Kommunizieren mit einem DEC-Objekt und ein Sun-Datenformat bei der Kommunikation mit einem Sun-Objekt verwenden. Und es wäre wünschenswert, dass ein einzelner Stub-Satz gleichzeitig mit verschiedenen ORBs verwendet werden kann.

Vorgeschlagene Lösung für das Problem

Die Lösung lautet:
(1) Definieren einer generischen Schnittstelle für die Marshalierung. Diese generische Schnittstelle ergibt Verfahren zum Marshalieren und Zurückmarshalieren von ganzen Zahlen (Ints), Kurzzeichen (Shorts), Bytes, Zeichen und Strings. Es gibt jedoch keinen Hinweis darauf, wie diese Verfahren implementiert werden.
(2) Verschiedene ORBs implementieren ihre generische MarshalBuffer- Schnittstelle selbst. Diese ORB-spezifischen Marshalklassen unterstützen nicht nur die generischen Marshalierungs- und Zurückmarshalierungsmethoden, sondern sie stellen auch zusätzliche Methoden zum Marshalieren von ORB-spezifischen Daten bereit. So stellt beispielsweise die MarshalBuffer-ORB-Implementation von Spring Methoden zum Marshalieren und Zurückmarshalieren von Spring-Türen bereit.
(3) Jede Objektreferenz (Objref) enthält einen Zeiger auf einen Satz von ORB- Laufzeitmaschinen, der zu dem ORB gehört, der das Objekt implementiert. In der bevorzugten Implementation ist dies ein Zeiger auf den clientseitigen ORB- abhängigen Code-Mechanismus/Subcontract für das Objekt.
(4) Die in (3) beschriebenen ORB-Laufzeitmaschinen unterstützen ein Verfahren für den Erhalt eines MarshalBuffer-Objekts. Die Laufzeitmaschinen geben ein MarshalBuffer-Objekt zurück, das die korrekte Marshalierung und Zurückmarshalierung für diesen ORB implementiert.
(5) Die generischen Stubs arbeiten vollkommen im Sinne der generischen MarshalBuffer-Schnittstelle.
(6) Zu Beginn jedes Rufs rufen die generischen Stubs die ORB-spezifischen Laufzeit-Codemechanismen in Verbindung mit der Objektreferenz, um ein geeignetes MarshalBuffer-Objekt zu erhalten. Die Stubs verwenden dann die generischen Marshalierungs- und Zurückmarshalierungsschnittstellen, um Daten zu und von diesem MarshalBuffer-Objekt zu marshalieren und zurückzumarshalieren. Da die Implementationen dieser Marshalierungs- und Zurückmarshalierungsmethoden ORB- spezifisch sind, bedeutet dies, dass die Daten auf eine ORB-spezifische Weise marshaliert und zurückmarshaliert werden.
In der derzeit bevorzugten Ausgestaltung beinhaltet der generische MarshalBuffer zusätzliche Fähigkeiten für die Handhabung von Unterschieden in mehreren bekannten ORBs. Z. B.:
(a) über die Methoden zum Marshalieren und Zurückmarshalieren von einfachen Datentypen hinaus, stellt der generische MarshalBuffer eine Möglichkeit zum Marshalieren von Array-Deskriptoren bereit. Dieses Verfahren nimmt die Grenzen der Array und marshaliert einen Array-Deskriptor auf eine ORB-spezifische Weise. So marshaliert beispielsweise der DOE ORB Code die Länge der Array. Aber der ORB-Code von Spring marshaliert die Untergrenze und die Obergrenze; und (b) stellt auf ähnliche Weise Mechanismen zum Zurückmarshalieren eines Array- Deskriptors bereit.

UMSETZUNG UND ANWENDUNG DER ERFINDUNG

Eine portable ORB-Implementation

Eines der Ziele der bevorzugten Ausgestaltung der vorliegenden Erfindung ist es, dass die Java ORB Implementation direkt mit einer Vielzahl verschiedener On-the- Wire-Protokollen und Datenformaten arbeiten kann. Insbesondere muss ein einzelnes Java-Programm in der Lage sein, gleichzeitig Objektreferenzen zu verwenden, die sich auf Objekte in verschiedenen ORBs beziehen. Das Internet ist eine äußerst heterogene Umgebung, und es ist wünschenswert, dass sie Java IDL Clients nicht auf die Arbeit mit nur jeweils einem einzigen Server beschränkt.
Insbesondere muss die Java-ORB-Implementation der bevorzugten Ausgestaltung in der Lage sein, direkt mit der Distributed Objekt Environment (DOE) von Sun und dem verteilten Betriebssystem von Spring zu kommunizieren. Es ist auch wünschenswert, den Java-ORB-Kern so auszulegen, dass er mit UNO-Gateways oder mit Objektsystemen auf DCE-Basis kommunizieren könnte.

Portabilitätsfaktoren

Portabilität ist ein Faktor auf mehreren verschiedenen Ebenen.
Auf der untersten Ebene wird die Socket-Klasse von Java verwendet, um Maschinen- und OS-unabhängigen Zugang zur IP-Protokollfamilie zu erhalten.
In der nächsthöheren Ebene verwenden verschiedene ORBs unterschiedliche Low-Level-Netztransportprotokolle. So arbeiten beispielsweise die DOE-Systeme von Sun mit ONC RPC, das Spring-System verwendet ein optimiertes sequenziertes Paketprotokoll, UNO arbeitet mit TCP/IP, einige andere Vendoren mit DCE RPC usw. Dies mag vielleicht wie ein recht bedeutender Unterschied auszusehen, es ist aber tatsächlich vergleichsweise leicht, verschiedene Low-Level-Transportprotokolle einzustecken.
Leider haben auch die verschiedenen Transportprotokolle unterschiedliche Datenformate für einfache Datentypen. So müssen beispielsweise ganzzahlige Werte in einer Big-Endian Byte-Reihenfolge für einen ONC ORB und in einer Little-Endian Byte-Reihenfolge für einen DCE ORB übertragen werden. Dies beeinflusst die Art und Weise, in der Argumente von den Marshal-Puffern marshaliert und zurückmarshaliert werden können.
In der nächsthöheren Ebene können zwei ORBs selbst dann, wenn sie sich auf ein Standardformat für einfache Datentypen einigen, möglicherweise uneinig darüber sein, wie die IDL-strukturierten Datentypen gehandhabt werden. So benutzen beispielsweise sowohl der Spring ORB als auch der DOE ORB das ONC XDR Format für einfache Datentypen; wenn sie aber einen Array-Deskriptor senden, dann sendet der DOE ORB einfach eine ganze Zahl, die die Länge vorgibt, während der Spring-ORB zwei ganze Zahlen sendet, von denen die eine die Untergrenze und die andere die Obergrenze der Array vorgibt. Dies bedeutet, dass, wenn Stubs gewünscht werden, die zwischen verschiedenen ORBs verwendet werden können, die Stubs nicht direkt Gegenstände wie Array-Deskriptoren marshalieren können, sondern stattdessen einen ORB-spezifischen Code rufen müssen.
Schließlich wird es wahrscheinlich verschiedene Formate für die verschiedenen Arten von IDL-bezogenen Meta-Daten wie z. B. Objektreferenzen, Methodenkennungen, Ausnahmenkennungen und Typenkennungen geben. So verwendet beispielsweise Spring ganze Zahlen als Methodenkennungen. Andere ORBs senden entweder einen einfachen Methodennamen eines vollqualifizierten Schnittstellennamens plus einer Methodennamenkombination.

Die Portabilitätsstrategie

In der bevorzugten Ausgestaltung bestand die allgemeine Strategie darin, Stabs zu erzeugen, die ORB-unabhängig sind, und die ORB-Abhängigkeiten innerhalb der individuellen Objektreferenzen zu verbergen. Dies hat den großen Vorteil, dass ein einziger Java-Stubs-Compiler verwendet werden kann, der Stubs erzeugen kann, die mit jedem beliebigen ORB verwendet werden können. Dies bedeutet jedoch, dass Schnittstellen zwischen den Stubs und der Objektreferenz benötigt werden, die es den Stubs erlauben, Argumente zu marshalieren und Fernvorgänge auf eine ORB-unabhängige Weise aufzurufen.
Erfahrungen mit der Verwendung des Subcontract-Mechanismus im Spring- System wurden bei der Entwicklung der Trennung zwischen den Stubs und der ORB- spezifischen Schicht genutzt. Spring lässt es zu, dass verschiedene Objektreferenzen verschiedene Formate und verschiedene Aufrufmechanismen haben, damit Dinge wie Replikation und Daten-Caching unterstützt werden können. Dies erfolgt durch Assoziieren eines Software-Moduls mit der Bezeichnung Subcontract mit jeder Objektreferenz. Wenn die Spring-Stubs eine Objektreferenz marshalieren oder aufrufen wollen, dann rufen sie den Subcontract in Verbindung mit der Objektreferenz auf, so dass die Marshalierung oder der Objektaufruf auf eine Weise erfolgt, die für diesen Subcontract geeignet ist.
In der JAVA ORB Implementation der bevorzugten Ausgestaltung wurde eine zusätzliche abstrakte Schnittstelle hinzugefügt, so dass ein einzelner Stub-Satz mit mehreren ORBs kommunizieren könnte. Eine abstrakte MarshalBuffer-Schnittstelle kam hinzu, und die Erzeugung von MarshalBuffers wurde von den Stubs zu den Subcontracts verlegt, so dass verschiedene ORBs unterschiedliche MarshalBuffer- Subklassen bereitstellen könnten, die Daten im richtigen Format für diesen ORB marshalieren und zurückmarshalieren. Fig. 3 zeigt eine Darstellung der Java-ORB- Klassen. In Fig. 3 verwendet eine Java-Anwendung 70 einen Satz von Stubs 68, um mit einem Satz von Fernobjekten (nicht dargestellt) zu kommunizieren. Diese Stubs und Anwendungen umfassen eine "ORB-unabhängige" Schicht 69, die allgemein mit der "OS-unabhängigen/ORB-abhängigen" Schicht 61 Verbindung hat. Eine beispielhafte "OS-unabhängige/ORB-abhängige" Schicht 61 umfasst beispielsweise zwei verschiedene Spring-Subcontract-Mechanismen 66, 64, die denselben MarshalBuffer 60 und denselben Spring-Netzprotokoll-Codemechanismus 56 verwenden, um mit dem Fernobjekt (nicht dargestellt) zu kommunizieren. Es wird ein ORB-abhängiger Codemechanismus 62 für die Verwendung durch den DOE ORB von Sun dargestellt, der einen DOE MarshalBuffer 58 benutzt, der wiederum den DOE-Netzprotokoll-Codemechanismus 54 verwendet. In diesem Beispiel verwenden sowohl der Spring-Netzprotokoll-Codemechanismus 56 als auch der DOE- Netzprotokoll-Codemechanismus 54 den Java-Netz-"Socket"-Codemechanismus 52. (Die Java-"Socket"-Klasse bietet Zugang zu TCP/IP und UDP Funktionalität auf eine Weise, die etwa den Socket-Schnittstellen ähnlich ist, die in den Berkeley UNIX Distributionen bereitgestellt wird.) Dieser Java-Netz- "Socket"-Codemechanismus 52 verwendet Betriebssystem-(OS) Dienste 51 von dem jeweiligen OS, auf dem er läuft.

Die MarshalBuffer-Schnittstelle

In der bevorzugten Ausgestaltung wurde die Schnittstelle zwischen den Stubs und der MarshalBuffer-Schnittstelle so definiert, dass die Stubs nicht nur einfache primitive Typen wie Zeichen und Länge marshalieren, sondern auch die Kontrolle darüber erhalten, wie strukturierte IDL-Datentypen marshaliert werden. Dies bedeutet die Bereitstellung generischer MarshalBuffer-Methoden zum Marshalieren und Zurückmarshalieren von Array-Headern und Vereinigungsdiskriminatoren.

Zusammensetzen des Puzzles

Im Kontext der vorliegenden Erfindung können verschiedene Anwendungen Objekte aufrufen oder Daten zu Objekten senden, die Implementationen haben, die mit verschiedenen ORBs assoziiert sind, aber in diesem Fall mit ORB-unabhängigen Code/ Subcontract-Mechanismen, um den Ziel-ORB zu bestimmen, um einen MarshalBuffer zu finden, der weiß, wie die Daten für die Zielimplementation zu marshalieren sind, und um mit der Maschine zu kommunizieren, die die Zielimplementation enthält. Gemäß Fig. 5 gibt die Client-Anwendung 112 wieder den Aufruf an Stub 112 aus. In diesem Fall sendet jedoch der Stub 112 den Aufruf an einen ORB-spezifischen Code/Subcontract-Mechanismus 212, der in der bevorzugten Ausgestaltung von einer Anzeige in objref bestimmt wird. (Eine alternative Ausgestaltung würde einen ORB-ID-Mechanismus zum Identifizieren des ORB- spezifischen Codemechanismus beinhalten, der von einem spezifischen Objektaufruf benötigt wird, wobei dieser ORB-ID-Mechanismus vorgegeben werden könnte, wenn die Objektimplementation erzeugt wird, und bei jedem nachfolgenden Aufruf dieses Objektes verwendet werden könnte. Die Fachperson wird erkennen, dass es viele verschiedenen Möglichkeiten gibt, den von einer Objektreferenz benötigten ORB- spezifischen Code zu identifizieren.) Dieser ORB-spezifische Code/Subcontract- Mechanismus 212 bestimmt, welches Format vom Ziel-ORB benötigt wird, und stellt ein MarshalBuffer-Objekt 210 bereit, das in der Lage ist, die richtige Marshalierung durchzuführen und den Client-Stub 114 darüber zu informieren, welches MarshalBuffer-Objekt 210 verwendet werden soll. Der Client-Stub 114 marshaliert mit diesem MarshalBuffer-Objekt 210 die Daten und sendet sie wie zuvor zum Netzsoftware-Codemechanismus/Gerät 116. Auf der Serverseite 118 weiß der ORB- spezifische Codemechanismus 214 des Ziels, wie er die Daten zurückmarshalieren muss, und leitet sie zum Zurückmarshalierungspuffer 216 weiter, der bei einer Java- Übertragung eine virtuelle Maschine sein kann, um die Byte-Code-Daten für die Ausführung durch die Server-Maschine zu interpretieren.
In der bevorzugten Ausgestaltung stellen wir für jede IDL-Objektreferenz des Typs FOO eine Java-Stub-Klasse FOO bereit, die aus einem Satz von Stub-Methoden und einem Zeiger auf ein Subcontract-Objekt besteht, das Informationen enthält, die das Serverobjekt identifizieren. Jedes Objekt der Stub-Klasse zeigt auf ein anderes Subcontract-Objekt, und diese Subcontract-Objekte können verschiedene Implementationen haben, so dass sie mit verschiedenen ORBs kommunizieren können. Wenn die Stub-Methoden einen Objektaufruf vornehmen möchten, dann fordern sie den Subcontract auf, ihnen ein geeignetes MarshalBuffer-Objekt zu geben, und benutzen dann diesen MarshalBuffer, um die Objekte zu marshalieren und die Ergebnisse zurückzumarshalieren. Ein beispielhafter MarshalBuffer ist in Fig. 6 dargestellt. Die in Fig. 6 gezeigte MarshalBuffer-Schnittstelle repräsentiert eine klare Trennung zwischen der Funktionalität des ORB-abhängigen Codes beim Marshalieren und Zurückmarshalieren von Daten. Die Stubs verstehen den jeweiligen Satz von Argumenten oder Ergebnissen, die für einen bestimmten IDL-Ruf benötigt werden. Die Stubs rufen dann den ORB-abhängigen Codemechanismus, der die MarshalBuffer-Schnittstelle implementiert, um jedes Datenelement, das in den Argumenten oder Ergebnissen enthalten ist, zu marshalieren (oder zurückzumarshalieren). Der ORB-abhängige Codemechanismus weiß nichts über die IDL-Schnittstelle, sondern marshaliert einfach die einzelnen Datenelemente im richtigen Format für diesen Ziel-ORB. Die wichtigsten Konzepte in der bevorzugten Ausgestaltung sind: (1) die MarshalBuffer-Schnittstelle wie die in Fig. 6 gezeigt ist eine Schnittstelle, für die verschiedene ORBs ihre eigene Implementation bereitstellen können, und (2) der ORB-abhängige Code stellt das MarshalBuffer-Objekt zu den Stubs bereit.
So könnte beispielsweise, bezugnehmend auf Fig. 7, eine Objektreferenz vom IDL-Typ FOO 404, die auf einen Spring-Server (nicht illustriert) zeigt, einen Singleton-Subcontract 408 von Spring benutzen. Wenn die Stubs für FOO 406 einen Aufruf an eine der FOO-Methoden vornehmen, dann fordern sie zunächst den Subcontract 408 auf, ihnen einen MarshalBuffer zu geben. Der Singleton-Subcontract 408 gibt einen Spring MarshalBuffer 410 zurück, der den On-the-Wire-Datenformaten von Spring entspricht. Die Stubs 406 marshalieren dann die Methodenargumente zum MarshalBuffer 410. Wenn die Stubs 406 alle Argumente marshaliert haben, dann rufen sie den Subcontract 408 und fordern ihn auf, tatsächlich den Methodenaufruf zum Server zu senden. Der Singleton-Subcontract 408 verwendet die Spring- Netzprotokoll-Handler 412, um die Anforderung an den Spring-Server zu senden und die Ergebnisse zu holen. Die Stubs 406 können dann die Ergebnisse vom MarshalBuffer 410 zurückmarshalieren und sie zur Client-Anwendung 402 zurückgeben.
In der bevorzugten Ausgestaltung wird ein Stub-Compiler contojava verwendet, der komplette Java-Client-Stubs für IDL-Schnittstellen erzeugt.
Darüber hinaus wird eine funktionsfähige Java ORB Implementation verwendet, die mit DOE- und Spring-Servern kommunizieren kann. Der Code für die Kommunikation mit Spring beinhaltet zwei Subcontracts (Caching und Singleton) sowie eine Java-Implementation des Proxy-Proxy-Protokolls von Spring. Der Code für die Kommunikation mit DOE beinhaltet einen einzelnen Subcontract (für den Basic Object Adapter (BOA)) und Code zum Suchen und Aktivieren von DOE BOA Objekten. Der gesamte ORB-Code ist in Java geschrieben und ist zwischen verschiedenen Java-Umgebungen portabel. Man ist der Ansicht, dass dieser ORB- Kern leicht mit Subcontracts erweitert werden kann, die mit UNO oder ORBs kommunizieren könnten, die von anderen Vendoren implementiert werden.

Claims

1. Computersystem mit einem Prozessor (3), einem Speicher (4), einem Anzeigegerät (6), einem Ein-Ausgabegerät (2) und einem Betriebssystem (OS) zum Verarbeiten von Aufrufen von Programmcodemechanismen (10), die an einen aus einer Vielzahl von ortsfernen Object Request Brokern (ORBs) gerichtet sind, dadurch gekennzeichnet, dass das Computersystem ferner folgendes umfasst:

eine ORB-unabhängige Schicht von Codemechanismen (69) einschließlich Programmanwendungen und zugehörigen Stubs; und

eine ORB-abhängige Schicht von Codemechanismen (61), die mit der ORB- unabhängigen Schicht gekoppelt ist, wobei die ORB-abhängige Schicht folgendes umfasst:

Programmcodemechanismen, die ORB-spezifisch (212) und so konfiguriert sind, dass sie einen Marshal-Codemechanismus (210) zum Marshalieren (Einsortieren) von Daten in einem von dem ORB benötigten Format zu erzeugen, und

Programmcodemechanismen, die so konfiguriert sind, dass sie einen spezifischen Netzwerkprotokollcode (116) verwenden, so dass ein Programmanwendungscode-Mechanismus von der ORB-unabhängigen Schicht einen Aufruf an einen ortsfernen Implementationsprogrammcode-Mechanismus einleiten kann, und die ORB-spezifischen Programmcodemechanismen in der ORB-abhängigen Schicht (61) einen geeigneten Marshal-Codemechanismus ermitteln, um Daten in einem vom ORB benötigten Format zu marschalieren;

so dass ein Computersystem entsteht, das mit einer Vielzahl von ORBs kommunizieren kann, wobei jeder ORB ein spezielles Datenformat verlangt.

2. Computersystem nach Anspruch 1, bei dem die ORB-unabhängige Schicht von Codemechanismen (69) mit Programmanwendungen und zugehörigen Stubs Objektanwendungen und zugehörige Stubs umfassen.

3. Computersystem nach Anspruch 1 oder 2, bei dem der Marshal- Codemechanismus (210) zum Marshalieren von Daten in einem vom ORB benötigten Format, der sich in der ORB-abhängigen Schicht (61) befindet, ein MarshalBuffer- Objekt ist, das so konfiguriert ist, dass es Vorgänge zum Marshalieren von Daten in einem ORB-spezifischen Format ausführt.

4. Computersystem nach Anspruch 1, 2 oder 3, bei dem der Programmcode- Mechanismus, der so konfiguriert ist, dass er einen spezifischen Netzwerkprotokollcode (116) verwendet, mit einem Servercomputer (118) kommuniziert, der folgendes umfasst:

einen Empfangsprogrammcode-Mechanismus (120), der ORB-abhängigen Code umfasst, der so konfiguriert ist, dass er einen Objektaufruf von einem ortsfernen

Computersystem (110) empfängt; und

eine ORB-unabhängige Serveranwendung, so dass der Empfangsprogrammcode-Mechanismus in die ORB-unabhängige Serveranwendung (214) hineinruft und einen MarshalBuffer einbringt, so dass die Serveranwendung Argumente zurückmarshalieren (aussortieren) und Ergebnisse marshalieren kann, ohne wissen zu müssen, von welchem ORB ein Anruf stammte.

5. Computersystem nach Anspruch 1, 2, 3 oder 4, bei dem die ORB-abhängige Schicht (61) auch von der Betriebssystem-Schicht (OS) unabhängig ist.

6. Verfahren zum Betreiben eines Computersystems mit einem Prozessor (3), einem Speicher (4), einem Display (6), einem Ein-Ausgabemechanismus (2), einem Betriebssystem und wenigstens einem Client-Anwenderprogramm (112), einem oder mehreren Stub-Programmen (114) in Bezug auf die Client-Anwendung, wobei das mit dem Computer durchgeführte Verfahren durch die folgenden Schritte gekennzeichnet ist:

Einleiten eines Aufrufs an einen Programmimplementationscode- Mechanismus, wobei der Aufruf durch eine Client-Anwendung erfolgt, wobei der Aufruf eine Referenz auf den Programmimplementationscode-Mechanismus beinhaltet;

Verwenden eines Stubprogrammcode-Mechanismus, der sich auf die Client- Anwendung zum Empfangen des Aufrufs bezieht, wobei der Stubprogrammcode- Mechanismus das Format nicht kennt, das zum Marshalieren von Daten benötigt wird, die von der Client-Anwendung in Verbindung mit der Aufrufeinleitung bereitgestellt werden;

Aufrufen eines ersten spezifischen Programmcodemechanismus (212) durch den Stubprogrammcode-Mechanismus, Anfordern des ersten spezifischen Programmcodemechanismus (212) zur Bereitstellung eines MarshalBuffer- Codemechanismus (210), der weiß, wie von der Client-Anwendung bereitgestellte Daten in Verbindung mit dem Aufruf formatiert werden;

Marshalieren der von der Client-Anwendung bereitgestellten Daten in Verbindung mit dem Aufruf, wobei die Marshalierung vom Stubprogrammcode- Mechanismus mit Hilfe des MarshalBuffer-Codemechanismus erfolgt; und

Senden des Aufrufs zu einem Server (118), der den Programmimplementationscode-Mechanismus enthält, der das Ziel des Rufs ist.

7. Verfahren nach Anspruch 6, umfassend den zusätzlichen Schritt des Zurückmarshalierens (216) von Ergebnissen vom MarshalBuffer, wobei die Ergebnisse vom Programmimplementationscode-Mechanismus geliefert werden, der mit dem Aufruf gerufen wurde.

8. Verfahren nach Anspruch 6 oder 7, bei dem der erste spezifische Programmcode-Mechanismus (212), der vom Stubprogrammcode-Mechanismus gerufen wurde, ein für einen Object Request Broker (ORB) spezifischer Codemechanismus ist.

9. Verfahren nach Anspruch 6, 7 oder 8, bei dem der Stubprogrammcode- Mechanismus, der den ORB-spezifischen Codemechanismus (212) ruft, den ORB nicht kennt, der den Ruf verarbeitet.

10. Verfahren nach Anspruch 6, 7, 8 oder 9, bei dem der Objekt Request Broker (ORB) ein ORB ist, der mit einem Common Object Request Broker (CORBA) gemäß der Object Management Group (OMG) kompatibel ist.

11. Verfahren nach Anspruch 6, 7, 8, 9 oder 10, umfassend die folgenden zusätzlichen Schritte:

Empfangen eines Objektaufrufs von einem ortsfernen Computersystem (110) auf einem serverseitigen ORB-abhängigen Codemechanismus (120); und

Ausgeben eines Rufs in eine ORB-unabhängige Serveranwendung (214), wobei der Ruf durch den serverseitigen ORB-abhängigen Codemechanismus erfolgt, der einen MarshalBuffer einbringt, der es zulässt, dass die Serveranwendung Argumente zurückmarshaliert und Ergebnisse marshaliert, ohne wissen zu müssen, von welchem ORB ein Ruf stammt.

12. Computerprogrammprodukt, umfassend ein in einem Computersystem benutzbares Speichermedium (9), in dem rechnerlesbarer Code eingebettet ist, mit dem veranlasst werden kann, dass ein Computersystem Programmcodemechanismus- Aufrufe verarbeitet, die an einen aus einer Vielzahl von ortsfernen Object Request Brokern (ORBs) gerichtet sind, wobei das Computerprogrammprodukt gekennzeichnet ist durch:

einen ersten rechnerlesbaren Programmcodemechanismus, der so konfiguriert ist, dass er eine ORB-unabhängige Schicht (69) von Codemechanismen umfasst, einschließlich Client-Anwendungen (112) und zugehörigen Stubprogrammcode- Mechanismen (114); und

einen zweiten rechnerlesbaren Programmcodemechanismus, der so konfiguriert ist, dass er eine ORB-abhängige Schicht (61) von Codemechanismen umfasst, die mit der ORB-unabhängigen Schicht (69) gekoppelt sind, wobei die ORB- abhängige Schicht Programmcodemechanismen umfasst, die ORB-spezifisch und so konfiguriert sind, dass sie einen Marshal-Codemechanismus (210) zum Marshalieren von Daten in einem vom ORB benötigten Format erzeugt, und Programmcodemechanismen (116), die so konfiguriert sind, dass sie einen spezifischen Netzwerkprotokollcode benutzen, so dass ein Programmanwendungscode-Mechanismus von der ORB-unabhängigen Schicht einen Ruf auf einem ortsfernen Implementationsprogrammcodemechanismus (120) einleiten kann, und die ORB-spezifischen Programmcodemechanismen in der ORB-abhängigen Schicht einen geeigneten Marshal-Codemechanismus zum Marshalieren von Daten in einem vom ORB benötigten Format bestimmen, so dass ein Computersystem bereitgestellt wird, das in der Lage ist, mit einer Vielzahl von ORBs zu kommunizieren, wobei jeder ORB Daten in einem bestimmten Format verlangt.

13. Computerprodukt nach Anspruch 12, bei dem die ORB-unabhängige Schicht (69) von Codemechanismen mit Programmanwendungen (112) und zugehörigen Stubs (114) Objektanwendungen und zugehörige Stubs umfassen.

14. Computerprogrammprodukt nach Anspruch 12 oder 13, bei dem der Marshal- Codemechanismus zum Marshalieren von Daten in einem vom ORB benötigten Format, der sich in der ORB-abhängigen Schicht (61) befindet, ein MarshalBuffer Object (210) ist, das so konfiguriert ist, dass es Vorgänge zum Marshalieren von Daten in einem ORB-spezifischen Format ausführt.

15. Computerprogrammprodukt nach Anspruch 12, 13 oder 14, bei dem der Programmcodemechanismus, der so konfiguriert ist, dass er einen spezifischen Netzwerkprotokollcode (116) benutzt, der sich in der ORB-abhängigen Schicht (61) befindet, so konfiguriert ist, dass er einen Netzwerkprotokollcode-Mechanismus benutzt, der ausgewählt ist aus einer Gruppe bestehend aus Spring- Netzwerkprotokollcode und DOE-Netzwerkprotokollcode.

16. Computerprogrammprodukt nach Anspruch 12, 13, 14 oder 15, bei dem der Marshal-Codemechanismus zum Marshalieren von Daten in einem vom ORB benötigten Format, die sich in der ORB-abhängigen Schicht (61) befinden, ebenfalls konfiguriert ist, um an ihn zurückgegebene Ergebnisse zurückzumarshalieren.