DE69630480T2

DE69630480T2 - Verfahren, Vorrichtung und Datenstrukturen zur Objektverwaltung

Info

Publication number: DE69630480T2
Application number: DE69630480T
Authority: DE
Inventors: David M. Brownell; Pavani Diwanji
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1995-03-22
Filing date: 1996-03-11
Publication date: 2004-08-19
Anticipated expiration: 2016-03-12
Also published as: US6009266A; JPH0926890A; DE69630480D1; CA2172220A1; EP0737916A1; EP0737916B1

Description

HINTERGRUND DER ERFINDUNG
Die vorliegende Erfindung betrifft die Gebiete verteilter Computersysteme, Client-server-computering und Objekt-orientierte Programmierung. Spezifischer lehrt die vorliegende Erfindung Verfahren, Vorrichtungen und Datenstrukturen zum Verwalten transienter und dauerhafter Objekte.
Objekt-orientierte Programmiermethodologien haben in den letzten Jahren in Reaktion auf eine steigende Tendenz einer Software Aufmerksamkeit gefunden, die unter Verwendung herkömmlicher Programmierverfahren entwickelt wird, die spät und über einem Budget auszuliefern ist. Dies rührt von der Tatsache her, dass herkömmliche Programmiertechniken, die Prozedurmodelle und einen "linearen" Code hervorheben, dazu neigen, unter vielen Umständen schwierig zum Auslegen und zum Warten zu sein. Allgemein sind große Programme, die unter Verwendung herkömmlicher Verfahren erstellt sind, "brüchig". Das heißt, sogar kleine Änderungen können zahlreiche Elemente des Programmiercodes beeinflussen. Somit können kleine Änderungen, die an der Software in Reaktion auf Benutzerbedürfnisse ausgeführt werden, ein größeres Redesign und ein Neuschreiben des gesamten Programms erfordern.
Objekt-orientierte Programmierstrategien neigen dazu, diese Probleme zu vermeiden, weil Objektmethodologien auf ein Manipulieren von Daten anstelle von Prozeduren konzentriert sind; wobei so mit dem Programmierer mit einem intuitiveren Zugang zu einem Modulieren von echten Problemen versehen. Zusätzlich kapseln Objekte bezogene Daten und Prozeduren, um so diese Information von dem Rest des Programms zu verstecken, indem ein Zugriff auf die Daten und auf die Prozeduren nur über die Schnittstelle des Objekts zugelassen wird. Somit sind Änderungen an den Daten oder den Prozeduren des Objekts relativ isoliert von dem Rest des Programms. Dies stellt einen Code bereit, der einfacher aufrechtzuerhalten ist verglichen mit dem Code, der unter Verwendung herkömmlicher Verfahren geschrieben ist, da Änderungen an einem Code des Objekts den Code in anderen Objekten nicht beeinflussen. Zusätzlich lässt es die inhärente modulare Natur der Objekte zu, dass einzelne Objekte und Schnittstellen in unterschiedlichen Programmen wiederverwendet werden. Somit können Programmierer Bibliotheken von "probierten und wahren" Objekten und Schnittstellen entwickelt werden, die immer wieder in unterschiedlichen Anwendungen verwendet werden können. Dies erhöht eine Softwarezuverlässigkeit, während eine Entwicklungszeit verringert wird, da ein zuverlässiger Programmiercode wiederholt verwendet werden kann.
Ein aktueller Fortschritt auf den Gebiet Objekt-orientierter Methodologien ist die Implementierung verteilter Objektbetriebsumgebungen über Computer, die über ein Computernetz verbunden sind, gewesen. Wie hierin verwendet, bezieht sich der Ausdruck "verteiltes Objekt" oder "Objekt" auf ein gekapseltes Pakets eines Codes und Daten, die durch Operationen über eine Schnittstelle manipuliert werden können. Somit werden verteilte Objekte von Durchschnittsfachleuten einer Objekt-orientierten Programmierung (OOP) gesehen werden, dass sie die grundlegenden Eigenschaften einschließen, die herkömmliche Programmierobjekte definieren. Jedoch unterscheiden sich verteilte Objekte von herkömmlichen Programmierobjekten dadurch, dass sie zwei wichtige Merkmale einschließen. Erstens sind verteilte Objekte multilingual. Das heißt, dass die Schnittstellen verteilter Objekte unter Verwendung einer Schnittstellen-Definitionssprache (IDL) definiert sind, die auf eine Vielzahl unterschiedlicher Programmiersprachen abgebildet werden kann. Eine derartige Schnittstellen-Definitionssprache ist die IDL der Object Management Group.
Zweitens sind verteilte Objekte orts-unabhängig, d. h. verteilte Objekte können irgendwo in einem Netz lokalisiert sein. Dies steht in krassem Gegensatz zu herkömmlichen Programmierobjekten, die typischerweise nur in einem einzigen Adressraum vorhanden sind, der mit ihren Clients geteilt wird.
Verteilte Objekte können Objektclients oder Objektserver sein, in Abhängigkeit davon, ob sie Anforderungen an andere Objekte senden oder auf Anforderungen von Clients antworten. In einer verteilten Objektumgebung werden Anforderungen und Antworten über einen Object Request Broker (ORB) ausgeführt, der die Orte und den Status der Objekte kennt. Eine Architektur, die zum Implementieren eines derartigen ORB geeignet ist, wird von der Common Object Request Broker Architecture (CORBA)-Spezifikation bereitgestellt. Die CORBA-Spezifikationen wurde von der Object Management Group (OMG) entwickelt, um die verteilte Computerumgebungswelt hinsichtlich von Objekten in einer verteilten Client-Server-Umgebung zu definieren, wo Serverobjekte in der Lage sind, für Clients, die den Dienst anfordern, bereitzustellen. In der folgenden Diskussion werden die Ausdrücke "Obejkt" und "verteiltes Objekt" austauschbar verwendet werden.
Im Gebiet verteilter Objektumgebungen sind potentiell zwei vorherrschende Arten von Objekten vorhanden, das transiente Objekt und das dauerhafte Objekt. Transiente Objekte weisen typischerweise eine kurze Lebensdauer auf und sind an einen einzelnen Host-Prozess gebunden. Das heißt, wenn ein Host-Prozess endet, enden auch sämtliche transiente Objekte, die unter dem Prozess laufen. Somit besteht keine Kontinuität einer Identität eines transienten Objekts von einem Prozess zu einem anderen. Da transiente Objekte an einen einzelnen Prozess gebunden sind, können sie inhärent ihren Ort nicht ändern. Somit könnten transiente Objekte in "immobile" Objekte umbenannt werden, da sie ihre Adressen nie ändern.
Im Gegensatz dazu sind dauerhafte Objekte nicht an einen einzelnen Prozess gebunden, und ihr Ort kann sich mit der Zeit ändern. Somit können dauerhafte Objekte als "mobile" Objekte bezeichnet werden, da sich ihre Adressen ändern können. Mit einem dauerhaften Objekt besteht eine Kontinuität einer Identität von einem Prozess zu einem anderen. Jedoch kann ein dauerhaftes Objekt in nur einen Prozess gleichzeitig existieren.
Wenn die transiente oder dauerhafte Natur eines Objekts diskutiert wird, ist das, was typischerweise betrachtet wird, die transiente oder dauerhafte Natur des Objektzustands. Wie Durchschnittsfachleuten vertraut sein wird, kann eine Computereinheit wie etwa ein Prozess oder ein Objekt zwei Komponenten aufweisen: einen ausführbaren Code und einen Zustand. Ein ausführbarer Code besteht im wesentlichen aus den Instruktionen, mit welchen die Einheit arbeit. Somit ist ein Zustand der verbleibende Abschnitt wie etwa Daten, die nicht ein Code sind. Die Motivation in der unterschiedlichen Arten eines Zustands, d. h. eines transienten und dauerhaften ist ziemlich einfach. Ein dauerhafter Zustand erfordert zusätzliche Systemressourcen, wie etwa Massenspeichervorrichtungen und entsprechende Verwaltungsressourcen, um eine Dauerhaftigkeit sicherzustellen, die gewünscht sein kann oder nicht. Beispielsweise ist eine Information, die in einer Datenbank gespeichert ist, typischerweise für eine langandauernde Speicherung bestimmt, und somit ist eine Dauerhaftigkeit erforderlich. In Situationen wie dieser sind es die zusätzliche Systemressourcen wert, die erforderlich sind, um diese Daten zu halten.
Jedoch ist eine Vielzahl von Szenarien vorhanden, wo eine Dauerhaftigkeit nicht erforderlich ist, und somit die zusätzlichen Systemressourcen, die für den dauerhaften Zustand erforderlich sind, effektiv verschwendet sind. Jedwede Situation, wo der Zustand nur für eine kurze Periode notwendig ist, und/oder wenn er später auf einfache Weise wieder erstellt werden kann, ist ein Kandidat für einen transienten Zustand. Ein vertrautes Beispiel ist das von Icons, wie etwa Formatierungs- und Editierknöpfe in vielen Fenster-basierten Textverarbeitungsprogrammen. Wenn Knöpfe wie etwa diese implementiert werden, wird (grob gesagt) ein Code vorhanden sein, der sie betriebsfähig macht, und ein Zustand, der ihnen ihr Erscheinungsbild vorgibt. Dieser Zustand wird die Bitmap des Icons einschließen. Wenn das Textverarbeitungsfenster geschlossen ist, verschwindet das Icon und es besteht kein Bedarf, die Bitmap der unterschiedlichen Icons aufrechtzuerhalten. Unter Verwendung eines transienten Zustands kann das System ein Aufrechterhalten dieser Bitmaps vergessen, bis sie wieder benötigt werden, wobei sie zu dieser Zeit wieder erstellt werden können.
Bekannte Lösungen, die sich mit einem transienten und/oder dauerhaften Zustand befassen, gehen fehl, einen Rahmen bereitzustellen, der die Integration transienter und dauerhafter Objekte innerhalb einer verteilten Objektbetriebsumgebung wirksam ermöglicht. Beispielsweise hat eine Datenbanktechnologie, die eine Objekt-orientierte Datenbanktechnologie einschließt, allgemein nur ein Aufrechterhalten eines dauerhaften Zustands behandelt. Als ein weiteres Beispiel sind Personalcomputersysteme so ausgelegt, dass sämtliche Ressourcendienste zur gleichen Zeit starten, indem ein dauerhafter Zustand verwendet wird. Die altbekannte Distributed Computing Environment (DCE), (verteilte Computerumgebung) implementiert nur dauerhafte verteilte Objekte unter Verwendung eines 128-Bit-Identifizierers, um jedes einzelne Objekt zu verwalten. Allgemein behandelt eine bekannte Technologie hauptsächlich dauerhafte Objekte, und wenn sie transiente Objekte behandelt, neigt sie dazu, nur auf transiente Objekte zu fokussieren. Was benötigt wird, ist ein Rahmen zum wirksamen Integrieren transienter und dauerhafter Objekte in einer verteilten Objektbetriebsumgebung. Dies wird Datenstrukturen erfordern, die Unterschiede zwischen den beiden zulassen, dennoch einen integrierten Rahmen bereitstellen. Außerdem werden wirksame Verfahren zum Verwalten dieser dauerhaften und transienten Objekte erforderlich sein.
ZUSAMMENFASSUNG DER ERFINDUNG
Um die vorangehenden und andere Aufgaben zu lösen, und in Übereinstimmung mit dem Zweck der vorliegenden Erfindung, wie sie in den angehängten Ansprüchen definiert ist, werden Verfahren, Vorrichtungen und Datenstrukturen zum Verwalten transienter und dauerhafter Objekte beschrieben. In einem Aspekt der Erfindung schließt eine Datenstruktur, die zur Verwendung als eine Objektreferenz für ein transientes Objekt vorgesehen ist, einen Satz von Endpunktadressen, eine Inkarnationsnummer und einen Objektschlüssel ein. Der Satz von Endpunktadressen ist angeordnet, einem Server-Hostcomputer zu entsprechen, auf welchem das transiente Objekt liegt. Die Inkarnationsnummer ist angeordnet, einem Server-Hostprozess zu entsprechen, der auf dem Hostcomputer abläuft. Das transiente Serverobjekt kann nur in diesem Server-Hostprozess laufen. Der Objektschlüssel ist ein Identifizierer, der dem transienten Serverobjekt entspricht. Diese drei Elemente, der Satz von Endpunktadressen, die Inkarnationsnummer und der Objektschlüssel dienen dazu, das transiente Serverobjekt eindeutig zu identifizieren und zu lokalisieren. Zusätzlich werden verschiedene Ausführungsformen und eine Vielzahl von Verfahren zum Benutzen eines oder mehrerer dieser Elemente, um eine wirksame Wechselwirkung zwischen einem Client, der Dienste anfordert und dem transienten Serverobjekt zu ermöglichen, auch beschrieben.
In manchen Anwendungen kann die Länge dieser Datenelemente variabel sein, wohingegen die Länge in anderen Anwendungen fest sein kann. In dem festen Fall ist eine Länge in dem Bereich von ungefähr 1–128 Byte bevorzugt. In einer bestimmten Ausführungsform schließt eine Adresse von dem Satz von Endpunktadressen einer 4-Byte lange Server-Hostnetzadresse und eine 2-Byte lange Server-Prozessnetz-Anschlussnummer ein. In einer weiteren spezifischen Ausführungsform ist die Inkarnationsnummer im wesentlichen ein Datumsstempel. Das heißt, eine monoton ansteigende Nummer, die die Erstellungszeit des Serverprozesses anzeigt. In anderen Ausführungsformen ist die Inkarnationsnummer eine vordefinierte Nummer, die für den Serverprozess eine vordefinierte Bedeutung aufweist.
In einer spezifischen Ausführungsform ist der Objektschlüssel eine Identifikationsnummer, die innerhalb des Serverprozesses, der das transiente Serverobjekt beinhaltet, eindeutig ist. In noch einer weiteren Ausführungsform wird der Objektschlüssel verwendet, um eine Objektreferenz zu transportieren, die gemäß dem Protokoll einer unterschiedlichen verteilten Objektbetriebsumgebung formatiert ist.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung schließt die Datenstruktur der Objektreferenz einen internen Namen ein, der anzeigt, dass die Objektsorte transient ist.
In einem weiteren Aspekt der Erfindung wird ein transientes Objekt, das der oben erwähnten Objektreferenz entspricht, betrachtet. Das transiente Objekt weist einen Zustand auf, auch dieser Zustand ist ein strikt transienter Zustand. In weiteren Ausführungsformen ist das transiente Objekt an den Serverprozess gebunden, und weist deswegen eine Identität innerhalb und nur innerhalb des Serverprozesses auf.
In einem Vorrichtungsaspekt der Erfindung schließt eine verteilte Objektbetriebsumgebung eine Vielzahl von Computersystemen, ein Computernetz, das die Computersysteme verbindet, und zumindest ein Objekt zur Verwendung als eine Objektreferenz für ein transientes Serverobjekt ein. In einer weiteren Vorrichtungs-Ausführungsform schließt die verteilte Objektbetriebsumgebung auch ein zweites Objekt zur Verwendung als eine Objektreferenz für ein dauerhaftes Serverobjekt ein. Das zweite Objekt weist eine Datenstruktur auf, die einen Host-Computernamen, eine Lokatoridentifikation, einen Objektschlüssel und einen Unterobjekt-Identifizierer einschließt. Die Datenstruktur des zweiten Objekts kann wahlweise einen Lokalisierungshinweis und ein Sortenfeld einschließen, das anzeigt, dass die Objektsorte dauerhaft ist.
In der Datenstruktur des zweiten Objekts wird der Host-Computername einem Host-Computer entsprechen, der einen Serverobjekt-Lokatordienst darauflaufend aufweist. Die Lokator-Identifikation wird einem Prozess entsprechen, innerhalb welchen ein Serverobjekt-Lokatorobjekt existiert. Das Lokatorobjekt ist eine Komponente eines Lokatordienstes, wobei das Lokatorobjekt zugezogen wird, um eine Ortsinformation für das zweite Objekt einzurichten. Die Ortsinformation wird datenähnlich der Datenstruktur des ersten Objekts wie etwa einen Satz von Endpunktadressen und eine Inkarnationsnummer einschließen.
In getrennten Aspekten der Erfindung werden verschiedene Verfahren zum Verwalten transienter und dauerhafter Objekte während des Aufrufs eines verteilten Serverobjekts, das auf einen Serverprozess läuft, der auf einem Server-Hostcomputer liegt, geschrieben. In einem Aspekt weist der Client eine Objektreferenz auf ein Serverobjekt auf und der Client-Aufruf schließt die Schritte eines Erlangens einer Adressierungsinformation für das verteilte Serverobjekt eines Auswählens einer Adresse für das verteilte Serverobjekt und eines Sendens einer Anforderung an das verteilte Serverobjekt ein. In einer weiteren Ausführungsform schließt dieses Verfahren den Schritt eines Empfangens einer Antwort von dem verteilten Serverobjekt ein.
In einem weiteren Verfahrensaspekt schließt der Schritt eines Erlangens eines Adressierungsinformation den Unterschritt eines Bestimmens der Sorte des verteilten Serverobjekts, ein, wobei die Sorten transient, dauerhaft, Null und ungültig einschließen können in Abhängigkeit von der Sorte des verteilten Serverobjekts unterschiedliche Verfahren durchgeführt werden. Wenn die Sorte Null oder ungültig ist, wird eine Fehlermeldung zurückgegeben. Wenn die Sorte transient ist, dann wird eine Adressierungsinformation direkt von der Objektreferenz zurückgegeben. Wenn die Sorte dauerhaft ist, dann schließt der Schritt eines Erlangens einer Adressierungsinformation weiter Schritte wie etwa ein Bestimmen, ob die Adressierungsinformation in dem Cache-Speicher auf dem Client-Hostcomputer gespeichert ist und eines Zurückgebens der Adressierungsinformation direkt von dem Cache-Speicher ein. Wenn die Adressierungsinformation nicht im Cache-Speicher gespeichert ist, dann wird die Adressierungsinformation aus innerhalb der verteilten Objektbetriebsumgebung, die in dem Cache-Speicher gespeichert ist, erhalten und dann direkt von dem Cache-Speicher zurückgegeben.
In einem weiteren Verfahrensaspekt schließt der Schritt eines Auswählens einer Adresse ein Bestimmen ein, ob der Client und der Server in dem gleichen Prozess sind, und wenn dem so ist, werden eine lokale Adresse und ein lokaler Transportmodus ausgewählt. In einem weiteren Verfahrensaspekt werden, wenn der Client und der Server in unterschiedlichen Prozessen sind, ein geteiltes Speicheradressieren und ein geteilter Speichertransport gewählt, wenn der Server-Hostcomputer der gleiche wie der Client-Hostcomputer ist. Jedoch wird, wenn ein geteiltes Speicheradressieren nicht verfügbar ist, oder wenn der Server-Hostcomputer nicht der gleiche wie der Client-Hostcomputer ist, dann ein Fern-Adressieren und ein Fern-Transport gewählt.
In einem getrennten Verfahrensaspekt ist ein Verfahren zum Aufrechterhalten einer verteilten Objektadressierungsinformation in einem Cache-Speicher auf einem Hostcomputer in einer verteilten Objektbetriebsumgebung offenbart. Dieses Verfahren beginnt, wenn eine Objektreferenz, die einem verteilten Objekt entspricht, empfangen wird. Dann wird, wenn die Objektreferenz eine Adressierungsinformation für das verteilte Objekt einschließt, diese Adressierungsfunktion in dem Cache-Speicher eingeschrieben. In manchen Ausführungsformen wird die Objektreferenz als Teil eines Zielobjektaufrufs empfangen, während sie in anderen Ausführungsformen im Ansprechen auf ein Zielobjektaufruf empfangen wird. Jedenfalls kann der Schritt eines Empfangens ein Vereinzeln der Objektreferenz vor einem Bestimmen, ob irgendeine Adressierungsinformation verfügbar ist, einschließen.
In einem Verfahrensaspekt, der sich auf die Diskussion der vorangehenden Absätze bezieht, weisen eine Vielzahl von Hostcomputern, die Teil einer verteilten Objektbetriebsumgebung sind, jeweils ihren eigenen Cache-Speicher auf. Jeder dieser Computer führt das Verfahren des voranstehenden Absatzes durch, um die Adressierungsinformation, die in ihrem Cache-Speicher verfügbar ist, zu erhöhen. Überdies bewahrt, wenn irgendeiner der Hostcomputer eine neue Adressierungsinformation lokalisiert, der die Vorteile der vorliegenden Erfindung, indem er sie in eine Objektreferenz vereinzelt und sie zu den anderen Hostcomputern verteilt, die Teil der verteilten Objektbetriebsumgebung sind.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die Erfindung, zusammen mit weiteren Aufgaben und Vorteilen davon, am besten unter Bezugnahme auf die folgende Beschreibung, die in Verbindung mit den zugehörigen Zeichnungen zu nehmen ist, verstanden werden.
In den Zeichnungen zeigen:
1 eine bildhafte Veranschaulichung verschiedener Computer, die in einem Computernetz untereinander verbunden sind;
2 diagrammartig Hauptkomponenten eines Computers in 1;
3a eine bildhafte Veranschaulichung eines Host-zu-Host-Client-Servermodells, das die Beziehung zwischen einem Client, der auf einem Hostcomputer läuft und einem Serverobjekt, das auf einem unterschiedlichen Server-Hostcomputer läuft, in einer verteilten Objektbetriebsumgebung zeigt;
3b eine bildhafte Veranschaulichung eines Prozess-zu-Prozess-Client-Servermodells, das die Beziehung zwischen einem Client und einem Server, die in unterschiedlichen Prozessen auf einem Client/Server-Hostcomputer laufen, zeigt;
3c eine bildhafte Veranschaulichung eines Client-Servermodells, das die Beziehung zwischen einem Client und einem Server, die in einem einzigen Client/Serverprozess laufen, zeigt;
4a eine bildhafte Veranschaulichung eines dauerhaften Objekts, die einen Ablauf durch drei unterschiedliche Objektzustände zeigt, wobei jeder Zustand einen transienten Zustand und einen dauerhaften Zustand gemäß einem ersten Aspekt der vorliegenden Erfindung zeigt;
4b eine bildhafte Veranschaulichung eines transienten Objekts gemäß einer zweiten Ausführungsform der vorliegenden Erfindung, die einen Ablauf durch drei unterschiedliche Zustände zeigt, wobei jeder Zustand einen transienten Zustand gemäß einem zweiten Aspekt der vorliegenden Erfindung einschließt;
5a eine bildhafte Veranschaulichung einer Objektreferenz für ein transientes Objekt, wobei die Objektreferenz ein Sortenfeld, einen Satz von Endpunktadressen, eine Inkarnationsnummer und einen Objektschlüssel gemäß einer zweiten Ausführungsform der vorliegenden Erfindung zeigt;
5b eine bildhafte Veranschaulichung einer Objektreferenz für ein dauerhaftes Objekt, wobei die Objektreferenz ein Sortenfeld, einen Hostnamen, eine Lokator-Identifikation, einen Objektschlüssel, einen Unterobjekt-Identifizierer und einen Lokalisierungshinweis gemäß einer ersten Ausführungsform der vorliegenden Erfindung einschließt;
6 ein Flussdiagramm, das einen Prozess veranschaulicht, der von einem Client ausgeführt wird, um ein verteiltes Serverobjekt gemäß einem Verfahrensaspekt der vorliegenden Erfindung aufzurufen;
7 ein Flussdiagramm, das einen Schritt 604 der 6 im weiteren Detail veranschaulicht;
8 ein Flussdiagramm, das einen Schritt 606 der 6 im weiteren Detail veranschaulicht;
9 ein Flussdiagramm, das einen Schritt 716 der 76 im weiteren Detail veranschaulicht;
10 ein Flussdiagramm, das einen Schritt 904 der 9 im weiteren Detail veranschaulicht; und
11 ein Flussdiagramm, das einen Prozess zum Bewahren der Vorteile der vorliegenden Erfindung veranschaulicht, indem die Adressierungsinformation, die in dem Cache-Speicher verfügbar ist, erhöht wird.
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
Die vorliegende Erfindung betrifft eine verteilte Betriebsumgebung auf der Grundlage einer Objekt-orientierten Programmierung (OOP). Spezifischer offenbart diese Erfindung Verfahren, Vorrichtungen und Datenstrukturen zum Verwalten von Objekten. Die Sorten von Objekten, die diskutiert werden, schließen transiente und dauerhafte Objekte ein. Ein transientes Objekt hält keinen dauerhaften Zustand aufrecht und ist direkt an die Lebensdauer des Prozesses, unter welchem es läuft, gebunden. Im Wege einer Erklärung ist ein dauerhafter Zustand der Zustand, der von einem Prozess zu einem anderen andauernd (oder überbrückt). Andererseits kann eine dauerhaftes Objekt sowohl einen dauerhaften als auch einen transienten Zustand aufweisen und dauert typischerweise über eine Zeitlänge an. In der folgenden Diskussion werden drei unterschiedliche Sorten von Objekten detaillierte beschrieben werden, indem zuerst ein Beispiel von Computersystemen diskutiert wird, die für die vorliegende Erfindung geeignet sind, als nächstes mit einer detaillierten Beschreibung mehrerer Ausführungsformen der Vorrichtungen und Datenstrukturen der vorliegenden Erfindung fortgefahren wird, und dann weiter über die detaillierte Beschreibung der Verfahrensaspekte der vorliegenden Erfindung.
I. DEFINITION VON AUSDRÜCKEN
Wie hierin verwendet, bezieht sich der Ausdruck "verteiltes Objekt" oder "Objekt" auf ein gekapseltes Paket eines Codes und von Daten, die durch Operationen über eine definierte Schnittstelle, die einem Objekt zugeordnet ist, manipuliert werden können. Somit werden verteilte Objekte von Durchschnittsfachleuten angesehen, dass sie grundlegende Eigenschaften einschließen, die herkömmliche Programmierobjekte definieren. Jedoch unterscheiden sich verteile Objekt von herkömmlichen Programmierobjekten dadurch, dass sie zwei wichtige Merkmale einschließen. Erstens sind verteilt Objekte multilingual. Die Schnittstellen verteilte Objekte werden unter Verwendung einer Schnittstellen-Definitionssprache definiert, die auf eine Vielzahl unterschiedlicher Programmiersprachen abgebildet werden kann. Eine derartige Schnittstellen-Definitionssprache ist OMG IDL. Zweitens sind verteilte Objekte orts-unabhängig, d. h. verteilte Objekte können irgendwo in einem Netz lokalisiert sein. Dies steht in krassem Gegensatz zu herkömmlichen Programmierobjekten, die typischerweise in einem einzigen Adressraum existieren: der Adressraum des "Clients". Verteilte Objekte können Objekt-Clients oder Server sein in Abhängigkeit davon, ob sie Anforderungen an andere Objekte senden oder auf Anforderungen von anderen Objekten antworten. Anforderungen und Antworten werden über einen Object Request Broker (ORB) ausgeführt, der die Orte und den Status der Objekte kennt.
Ein "verteiltes Objektsystem" oder eine "verteilte Objektbetriebsumgebung" bezieht sich auf ein System, das verteilte Objekte umfasst, die über einen ORB kommunizieren.
Eine "Objektreferenz" oder ein "objref" ist eine Datenstruktur (es kann ein herkömmliches Programmiersprachenobjekt sein), das einen Zeiger auf ein anderes Objekt enthält. Die Erstellung und Definition von Objektreferenzen wird Durchschnittsfachleuten vertraut sein.
Ein "Client", wie er hierin definiert ist, bezieht sich auf eine Einheit, die eine Anforderung an ein Objekt sendet. In diesem Modell stellt das Objekt einen Dienst bereit und wird als ein "Serverobjekt" oder ein "Zielobjekt" bezeichnet. Somit rufen Clients Operationen oder Implementierungen von Servern auf. In manchen Fällen sind Clients selbst Objekte. In einer verteilten Objektumgebung müssen Clients keine Kenntnis der Implementierungs-Programmiersprache aufweisen, noch muss die Implementierung eine Kenntnis der Programmiersprache des Clients aufgrund der Anforderung des multilingualen Charakters derartiger Objekte aufweisen. Clients und Server in verteilten Objektbetriebsumgebungen müssen nur hinsichtlich der Schnittstellen-Definitionssprache kommunizieren. Wie oben bemerkt, wird die Anforderung durch den Client an den Server und die Antwort des Servers an den Client durch den ORB gehandhabt. Es sei darauf hingewiesen, dass der Client und der Server innerhalb des gleichen Prozesses, auf dem gleichen Hostcomputer oder auf zwei unterschiedlichen Hostcomputern existieren können.
Eine "Objektschnittstelle" ist eine Spezifikation der Operationen, Attribute und Ausnahmen, die ein Objekt bereitstellt. Vorzugsweise sind Objektschnittstellen für verteilte Objekte unter Verwendung einer IDL geschrieben. Wie obenstehend bemerkt führen Objekte Transaktionen über ihre Schnittstellen durch. Die Verwendung von Schnittstellen beseitigt deswegen den Bedarf, dass Clients die Programmiersprachen, die verwendet werden, um die Verfahren und Daten der Objekte in der Transaktion zu definieren, kennen.
Ein Paket einer Information "aufzustellen" ist, diese Information für eine Übertragung entweder über einen geteilten Speicher-Kommunikationskanal oder über eine Netzkommunikationsleitung vorzubereiten. Dies bedeutet oft ein Organisieren der Daten in einem bestimmten Format gemäß des verwendeten Kommunikationsprotokolls.
Ein Paket einer Information zu „vereinzeln" ist im wesentlichen, die Aufstellungs-Prozedur umzukehren und Daten zu erzeugen in einem Format, das in der geeigneten Umgebung aussagekräftig ist.
II. Objekte verwalten
Die vorliegende Erfindung betrifft die Gebiete verteilter Computersysteme, Client-Servercomputern und eine Objekt-orientierten Programmierung. Spezifischer lehrt die vorliegende Erfindung Verfahren, Vorrichtung und Datenstrukturen zum Verwalten transienter und dauerhafter verteilter Objekte.
Wie hierin verwendet, bezieht sich der Ausdruck "verteiltes Objekt" oder "Objekt" auf ein gekapseltes Paket eines Codes und von Daten, die durch Operationen über eine Schnittstelle manipuliert werden können. Zusätzlich kann das verteilte Objekt der vorliegenden Erfindung Merkmale aufweisen, wie sie etwa in dem Stand der Technik beschrieben sind. Beispielsweise können verteilte Objekte Objekt-Clients oder Objekt-Server sein, in Abhängigkeit davon, ob sie Anforderungen an andere Objekte senden oder auf Anforderungen von Clients antworten.
In einer verteilten Objektumgebung werden Anforderungen und Antworten über einen Object Request Broker (ORB) ausgeführt, der die Orte und den Status der Objekte kennt. Eine Architektur, die zum Implementieren eines derartigen ORB geeignet ist, wird von der Common Object Request Broker Architecture (CORBA)-Spezifikation bereitgestellt. Die CORBA-Spezifikation wurde von der Object Management Group (OMG) entwickelt, um die verteilte Computerumgebungswelt hinsichtlich der Objekte in einer verteilten Client-Serverumgebung zu definieren, wo Serverobjekte in der Lage sind, für Clients, die den Dienst anfordern, Dienste bereitzustellen. In der folgenden Diskussion werden die Ausdrücke "Objekt" und "verteiltes Objekt" austauschbar verwendet werden, die folgende Erfindung auf beide Typen ausgerichtet ist.
In einer bevorzugten Ausführungsform der vorliegenden Erfindung sind verteilte Objekte auf einem oder mehreren Computern lokalisiert, die über ein Netz miteinander verbunden sind. Das Netz kann jedwede geeignete Form annehmen. Im Wege eines Beispiels ist eine repräsentative Netzanordnung 10 in 1 veranschaulicht. Die Netzanordnung 10 schließt einen ersten Computer 12, der mit einer Übertragungsleitung 14 gekoppelt ist, ein. Das Netz 10 schließt weiter einen Server, einen Router oder dergleichen 16 zusätzlich zu anderen Computern 18, 20 und 22 ein, derart, dass Daten und Instruktionen zwischen den Netzcomputern übergeben werden können. Die Auslegung, der Aufbau und die Implementierung von Computernetzen werden Durchschnittsfachleuten vertraut sein.
Ein repräsentativer Computer 30, der zur Verwendung als die Computer 12, 18, 20 und/oder 22 der 1 geeignet ist, ist schematisch in 2 veranschaulicht. Ein Computer 30 schließt eine zentrale Verarbeitungseinheit (CPU) 32 ein, die bedirektional mit einem Schreiblesespeicher (RAM) 34 und unidirektional mit einem Lesespeicher (ROM) 36 gekoppelt ist. In typischer Weise wird der RAM 34 als ein "Notizblock"-Speicher verwendet und schließt Programmierinstruktionen und Daten, die verteilte Objekte und ihren zugeordneten Code und Zustand einschließen, für Prozesse, die gegenwärtig auf der CPU 32 arbeiten, ein. Es sei darauf hingewiesen, dass ein transienter Zustand oft in einem transienten Speicher wie etwa dem RAM 34 gespeichert ist. Der ROM 36 schließt typischerweise grundlegende Betriebsinstruktionen, Daten und Objekte ein, die von dem Computer verwendet werden, um seine Funktionen durchzuführen. Zusätzlich ist eine Massenspeichervorrichtung 38 wie etwa eine Festplatte, eine CD-ROM, eine magneto-optisches (floptical) Laufwerk, ein Bandlaufwerk oder dergleichen bidirektional mit der CPU 32 gekoppelt. Die Massenspeichervorrichtung 38 schließt allgemein zusätzliche Programmierinstruktionen, Daten und Objekte ein, die typischerweise nicht von der CPU in aktiver Verwendung sind, obwohl auf ihren Adressenraum von der CPU, z. B. einen virtuellen Speicher und dergleichen zugegriffen werden kann. Es sei darauf hingewiesen, dass ein dauerhafter Zustand oft in einem dauerhaften Speicher wie etwa der Speichervorrichtung 38 gespeichert wird. Jeder der oben beschriebenen Computer schließt wahlweise Eingangs/Ausgangsquellen 40 ein, die typischerweise Eingangsmedien wie etwa eine Tastatur, Zeigervorrichtungen (z. B. eine Maus oder einen Stift) und/oder Netzverbindung ein. Zusätzliche Massenspeichervorrichtungen (nicht gezeigt) können auch mit der CPU über eine Netzverbindung verbunden werden. Es wird von Durchschnittsfachleuten erkannt werden, dass die oben beschriebenen Hardware- und Softwareelemente, wie auch die Netzvorrichtungen, von einer Standardauslegung und von einem Standardaufbau sind, und sie werden Durchschnittsfachleuten gut vertraut sein.
Zurückkehrend auf die Diskussion des Clients und des Servers ist eine der Unterfahrungen der verteilten Objektumgebungen die Wechselwirkung zwischen dem Client, der hierin als eine Einheit definiert ist, die einen Dienst anfordert, und einem Server, der typischerweise ein Objekt ist, das den Dienst bereitstellt. Beispielsweise schließen unterschiedliche Szenarios den Client und den Server innerhalb des gleichen Prozesses, in unterschiedlichen Prozessen auf den gleichen Hostcomputer und auf unterschiedlichen Prozessen, die auf unterschiedlichen Hostcomputern laufen, ein. Diese Client-Objektwechselwirkung kann hinsichtlich eines Client-Servermodells diskutiert werden. Im Wege eines Beispiels kann ein Client in einem Prozess sein, der auf einem Netzcomputer abläuft, wie etwa dem Computer 12, der Dienste von einem Serverobjekt in einem unterschiedlichen Prozess, der auf einem entfernten Computer 18 läuft, anfordert.
Wie von Durchschnittsfachleuten erkannt werden wird, schließen die Einheiten, die ein Client sein können, ein Prozess ein, der auf einem Hostcomputer läuft, der nachstehend als ein Client-Prozess bzw. Client-Host bezeichnet, und ein Objekt, nachstehend als ein Client-Objekt bezeichnet, ein, sind aber nicht darauf beschränkt. Deswegen ist ein Client eine Einheit, die einen Dienst anfordert, ungeachtet des Typs der Einheit. Zur Klarstellung wird das Objekt, das den Dienst bereitstellt, nachstehend austauschbar als ein Zielobjekt oder ein Serverobjekt bezeichnet. Somit kann in der folgenden Beschreibung, ein Client der ein Zielobjekt aufruft, der Client jedwede Einheit wie etwa ein Client-Prozess oder ein Client-Objekt sein.
Indem die Terminologie der Client-Serverwechselwirkungen weiter ausgearbeitet wird, wird ein Client ein Zielobjekt "anrufen", um ein "Verfahren", das von dem Zielobjekt ausgeführt wird, "aufzurufen". Es sei darauf hingewiesen, dass "anrufen" und "aufrufen" geringfügig unterschiedliche Bedeutungen mit sich bringen können, die beiden Ausdrücke hierin austauschbar verwendet werden und ihre Bedeutungen aus dem Kontext der Diskussion hierin verstanden werden. Wie Durchschnittsfachleuten allbekannt ist, ist ein Verfahren eine Prozedur, die in einem Objekt enthalten ist, das anderen Einheiten, d. h. Clients zum Zweck eines Anforderns von Diensten dieses Objekts verfügbar gemacht wird. Somit ist das Objekt, das den Dienst für den Client durchführt, der Server, somit die Phrase Client-Server. Bei einem Aufrufen eines Verfahrens kann der Client auch diese Argumente, die auch als Parameter bezeichnet werden, die für das Zielobjekt notwendig sind, um das angeforderte Verfahren durchzuführen, übergeben. Es sei bitte darauf hingewiesen, dass der vorherige "Verfahren" ein Ausdruck des Stands der Technik der Objekt-orientierten Programmierung ist und sich von dem Ausdruck "Verfahren", der klassisch beim Verfassen von Patentanmeldungen verwendet wird, unterscheidet. In der folgenden Diskussion nimmt der Anmelder an, dass klargestellt ist, ob entweder durch den Kontext oder durch einen Hinweis von dem Anmelder, welche Bedeutung für den Ausdruck "Verfahren" verwendet wird.
Unter Bezugnahme als nächstes auf die 3a–3c werden einige mögliche Nummerierungen eines Client-Servermodells, die sehr repräsentativ für eine verteilte Objektumgebung sind, diskutiert werden. Wie es immer der Fall ist, wird das Client-Servermodell eine Client-Einheit und ein Zielobjekt aufweisen, das die Server-Einheit ist. Eine derartige Anordnung für die folgenden Client-Servermodelle schließt Computer wie etwa einen Computer 30 der 2 ein, der über ein Netz 14 verbunden ist, wie in 1 gezeigt.
Indem zuerst auf 3a eingegangen wird, ist ein Client-Servermodell 300, das als "Host-zu-Host" bezeichnet wird, gezeigt, wobei ein Client 302 und ein Zielobjekt 304 auf unterschiedlichen Hostcomputern innerhalb einer verteilten Objektbetriebsumgebung 301 existieren. Der Client 302 existiert in einem Client-Prozess 306, der auf einem Client-Hostcomputer 308 läuft. Der Client 302 verwendet ein erstes Ersatzobjekt 310, das eine Objektreferenz 314 hält (z. B. weist es eine erste Indirektion 312 auf dieselbe auf). Die Objektreferenz 314 stellt wiederum eine zweite Indirektion 316 auf das Zielobjekt 304 bereit. Wie hierin verwendet, ist eine Indirektion auf ein Objekt einfach ausreichend Information, um das Objekt zu lokalisieren, ob zwar vielleicht nicht im Wege einer direkten Wechselwirkung mit dem Objekt. In dem Fall der 3a wird eine erste Indirektion 312 typischerweise gerade ein direkter Zeiger auf die Objektreferenz sein, während eine zweite Indirektion 316 oft ausgearbeiteter ist. Indirektionen wie etwa die Indirektion 316 werden später unter Bezugnahme auf die 5a und 5b detaillierter diskutiert werden. Zusätzlich können andere Ersatzobjekte vorhanden sein, die in dem Client-Prozess 306 gegenwärtig sind, wie etwa ein zweites Ersatzobjekt 311, das auch die Objektreferenz 314 halten kann. In manchen Fällen können Ersatzobjekte 310 und 311 herkömmliche Programmiersprachenobjekte sein. Jedoch schließen manche verteilte Objektbetriebsumgebungen Ersatzobjekte nicht ein. In diesen Fällen wird der Client die Objektreferenz 314 ohne ein Ersatzobjekt benutzen.
Ähnlich dem Client 302 kann das Zielobjekt 304 der 3a in einem Serverprozess 318 existieren, der auf einem Server-Host 320 läuft. Andere Einheiten können auf sowohl dem Server-Host 308 als auch dem Client-Host 320 liegen. Diese schließen zusätzliche Prozesse und/oder Objekte, die unter dem Client-Prozess, dem Server-Prozess und/oder den zusätzlichen Prozessen laufen, ein, sind aber nicht darauf beschränkt. Bei zwei geeignete Prozesse sind ein Dämon_1 Prozess 317, der auf einem Client-Host 308 läuft, und ein Dämon_2 Prozess 321, der auf einem Server-Host 320 läuft. Dämon-Prozesse laufen typischerweise in dem Hintergrund und sind Durchschnittsfachleuten wohl bekannt.
Wie 3a veranschaulicht, muss in dem Host-zu-Host-Fall der Client 302 seinen Aufruf zu dem Zielobjekt 304 über mehrere "Schichten" übergeben, d. h. Komplexitäten, die nicht direkt auf den Dienst bezogen sind, der von dem Zielobjekt angefordert wird. In dem Host-zu-Host-Beispiel muss eine Netzverbindung zwischen dem Client 302 und dem Zielobjekt 304 eingerichtet werden. Wegen der unterschiedlichen Schichten, wie etwa die Client- und Server-Hosts 308 und 320 und der Client- und Server-Prozess 306 und 318 kann die Client-Server-Netzverbindung nicht direkt eingerichtet werden. Vielmehr muss der Client-Prozess 306 den Anruf interpretieren und diesen zu dem Ersatzobjekt 310 durchleiten, das den ORB verwenden kann, um den Server-Host 320 zuerst zu finden und dann den Server-Prozess 318 und das Zielobjekt 304 zu identifizieren. Weiter müssen, da diese Daten über das Netz kommuniziert werden, diese Daten aufgestellt (d. h. gemäß des Netzkommunikationsprotokolls formatiert werden, um sie so für eine Übertragung über das Netz vorzubereiten) gesendet, empfangen und schließlich vereinzelt werden. Somit ist ein Host-zu-Host ein komplizierter Fall der Client-Server-Wechselwirkung. Dementsprechend machen die zusätzlichen Schichten und resultierenden Schritte die Host-zu-Host-Client-Server-Wechselwirkung oft zu der teuerst möglichen Wechselwirkung hinsichtlich einer Systemressourcen-Benutzung.
3b zeigt ein "Prozess-zu-Prozess" Client-Servermodell, in welchem der Client 302 und das Zielobjekt 304 den gleichen Hostcomputer, einen Client-Server-Host 322 teilen. Jedoch liegen der Client 302 und das Zielobjekt 304 in unterschiedlichen Prozessen. Ähnlich zu 3a existiert der Client 302 in einem Client-Prozess 306, der auf dem Client-Server-Host 322 läuft. Der Client verwendet ein erstes Ersatzobjekt 310, das eine erste Objektreferenz 314 hält (d. h. es weist eine erste Indirektion 312 auf dasselbe auf). Die Objektreferenz 314 stellt wiederum eine zweite Indirektion 316 auf das Zielobjekt 304 bereit. Das Zielobjekt 304 existiert innerhalb eines Server-Prozesses 318, der auf dem Client-Server-Host 322 läuft. Verwandt mit dem "Host-zu-Host"-Fall können weitere Einheiten wie etwa Prozesse und/oder Objekte auf dem Client-Server-Host 322 liegen. Beispielsweise können andere Ersatzobjekte, die in dem Client-Prozess 306 gegenwärtig sind, wie etwa ein zweites Ersatzobjekt 311, da auch die Objektreferenz 314 halten kann, vorhanden sein. Jedoch schließen manche verteilte Objektbetriebsumgebungen Ersatzobjekte nicht ein. In diesen Fällen wird der Client 302 die Objektreferenz 314 ohne ein Ersatzobjekt benutzen. In jedem Fall kann die Prozess-zu-Prozess-Wechselwirkung deutlich besser als die Host-zu-Host-Wechselwirkung sein. Dies liegt teilweise daran, dass die Netzkommunikationsschritte unnötig sind.
3c zeigt ein Client-Servermodell, in welchem sowohl der Client 302 als auch das Zielobjekt 304 in dem gleichen Prozess, dem Client-Server-Prozess 324 liegen. Der Client 302 verwendet wiederum ein erstes Ersatzobjekt 310, das eine Objektreferenz 314 hält (z. B. es weist eine erste Indirektion 312 auf dasselbe auf). Die Objektreferenz 314 stellt wiederum eine zweite Indirektion 316 auf das Zielobjekt 304 bereit. In diesem Fall kann die zweite Indirektion 316 nur ein Zeiger auf einen geteilten Speicher sein. Diese Situation ist vielleicht die beste sämtliche drei beschriebenen Fälle. Keine Netzkommunikation ist notwendig, und da beide Objekte unter einem Prozess sind, existieren sie in einem Speicher, der dem Client-Server-Prozess 324 zugeordnet ist, gemeinsam. In der Situation der 3c können andere Einheiten wie etwa Objekte in einem Client-Server-Prozess 324 liegen. Beispielsweise können andere Ersatzobjekte, die in dem Client-Prozess 306 gegenwärtig sind, wie etwa ein zweites Ersatzobjekt 311, das auch die Objektreferenz 314 halten kann, vorhanden sein. Jedoch schließen manche verteilte Objektbetriebsumgebungen Ersatzobjekte nicht ein. In diesen Fällen wird der Client 302 die Objektreferenz 314 ohne ein Ersatzobjekt nutzen.
Zwei andere typische Client-Server-Szenarien, die nicht in den oben beschriebenen Figuren gezeigt sind, werden nun kurz diskutiert werden. Das erste Szenario bringt die Ausführungsformen mit sich, worin der Client ein Objekt ist. Wie von Durchschnittsfachleuten erkannt werden wird, sind die Sachverhalte, die auftreten, sehr ähnlich (oft identisch), der Client ein Objekt oder irgendeine andere Einheit ist, die einen Dienst anfordert. Das andere Szenario ist eines, worin das Client-Objekt und das Zielobjekt eben dasselbe Objekt sind. Dies kann auftreten, wenn ein Objekt einen rekursiven Anruf zu sich selbst ausführt. Während der rekursive Anruf ungewöhnlich erscheinen kann, ist diese Client-Server-Wechselwirkung ziemlich üblich und ein nützliches Werkzeug und kann auf eine Weise ähnlich (oder vielleicht identisch) zu dem Fall behandelt werden, worin ein Client-Objekt und ein Zielobjekt einzigartig sind, aber in dem gleichen Prozess existieren.
4a zeigt den Ablauf eines dauerhaften Objekts 401 durch drei unterschiedliche Zustände. Der erste Übergang 400 bringt das dauerhafte Objekt 401 von einem vorangehenden Zustand in einen Zustand 1. Der Zustand 1 des Objekts 401 schließt sowohl einen transienten Zustand 402 als auch einen dauerhaften Zustand 404 ein. Der Übergang 406 bringt das dauerhafte Objekt 401 von dem Zustand 1 in einen Zustand 2. Ähnlich dem Zustand 1 weist der Zustand 2 des Objekts 401 sowohl einen transienten Zustand 408 als auch einen dauerhaften 410 auf. Schließlich bringt der Übergang 412 das dauerhafte Objekt 401 von dem Zustand 2 in einen Zustand 3. Wiederum weist der Zustand 3 des Objekts 401 sowohl einen transienten Zustand 414 als auch einen dauerhaften Zustand 416 auf. Für das dauerhafte Objekt 401 können die Übergänge 400, 406 und 412 jedwede Operation sein, die den Zustand des Objekts 401 ändert, einschließlich der Beendigung eines Prozesses, unter welchem das Objekt existiert. Weil das dauerhafte Objekt einen dauerhaften Zustand in jeder Stufe einschließt, weist es die Kapazität auf, von Prozess zu Prozess zu überbrücken und sich selbst für lange Zeitperioden aufrechtzuerhalten.
Im Gegensatz dazu zeigt 4b den Ablauf eines transienten Objekts 417 durch drei unterschiedliche Zustände. Der erste Übergang 418 bringt das transiente Objekt 417 von einem vorangehenden Zustand in einen Zustand A. Der Zustand A des transienten Objekts 417 schließt einen transienten Zustand 420 ein, schließt aber nicht irgendeinen dauerhaften Zustand ein. Ein Übergang 422 bringt das Objekt 417 von dem Zustand A in einen Zustand B. Ähnlich dem Zustand A weist der Zustand B des transienten Objekts 417 einen transienten Zustand 424 auf und weist nicht irgendeinen dauerhaften Zustand auf. Schließlich bringt ein Übergang 426 das transiente Objekt 417 von dem Zustand B in einen Zustand C. Wiederum weist der Zustand C des transienten Objekts 417 einen transienten Zustand 428 auf und weist nicht irgendeinen dauerhaften Zustand auf. Für das transiente Objekt 417 können die Übergänge 418, 422, 426 jedwede Operation sein, die den Zustand des transienten Objekts 417 ändert, mit der Ausnahme von Operationen, die eine Beendigung des Prozesses einschließen, unter welchen das transiente Objekt 417 existiert. Weil das transiente Objekt 417 nicht irgendeinen dauerhaften Speicher einschließt, kann es nicht Prozesse überbrücken. Deswegen existieren transiente Objekte in ein und nur einem Prozess und hören auf zu existieren, wenn der Prozess aufhört. Zusätzlich sei darauf hingewiesen, dass sich ein Ort eines Prozesses und eine Adresse nicht ändern können, weswegen sich ein Ort eines transienten Objekts und eine Adresse nicht ändern können.
Aus der obigen Diskussion des Client-Servermodells und der Beziehung auf dauerhafte Objekte sollte offensichtlich sein, dass Rahmen wirksamen und flexiblen Handhaben von Client-Server-Wechselwirkungen bevorzugt sind. Ein Rahmen, der Vorrichtungen und Datenstrukturen bereitstellt, wird nun diskutiert werden.
Um die zuvor erwähnten Client-Server-Wechselwirkungen zu erleichtern, schließen Objektbetriebssysteme (einschließlich der verteilten Architektur, die durch CORBA spezifiziert ist, in typischer Weise ein Objekt ein, das als eine "Objektreferenz" bezeichnet ist. Objektreferenzen dienen sowohl dazu, die Zielobjekte einzelner Operationsanforderungen zu lokalisieren, als auch diese zu identifizieren, wie auch allgemeine Parameter einer Operation bereitzustellen. Wegen der Unterschiede beim Handhaben der unterschiedlichen Sorten von Objekte sind keine Lehren in dem Stand der Technik vorhanden, die sowohl transiente als auch dauerhafte Objekte unter dem gleichen Rahmen einschließen. Jedoch schließt die Lehre der vorliegenden Erfindung einen Rahmen zur Verwendung innerhalb einer verteilten Objektbetriebsumgebung ein, der sowohl transiente als auch dauerhafte Objekte integriert. Eine Ausführungsform, die transiente Objektreferenzen und dauerhafte Objektreferenzen einschließt, wird später detaillierter diskutiert werden.
Da Objektreferenzen einen Client auf ihr entsprechendes Zielobjekt richten, ist ein anderer aussagekräftiger Weg eines Betrachtens der Adjektive "transient" und "dauerhaft" vorhanden, wie sie verwendet werden, um den Ausdruck "Objektreferenz" zu modifizieren. Dauerhafte Objektreferenzen sind eine Indirektion (sie lokalisieren und identifizieren) auf ein verteiltes Objekt, das eine Kontinuität einer Identität aufweist. Deswegen ist die Indirektion einer dauerhaften Objektreferenz eine dauerhafte Indirektion, sowie er immer gültig ist (wenn nicht die Identität des dauerhaften Objekts zerstört wird). Im Gegensatz dazu sind transiente Objektreferenzen eine Ausrichtung auf ein verteiltes Objekt, das keine Kontinuität einer Identität aufweist. Deswegen ist die Ausrichtung einer transienten Objektreferenz eine transiente Ausrichtung.
Zusätzlich zu transienten und dauerhaften Objektreferenzen sind zwei zusätzliche Sorten von Objektreferenzen vorhanden, die erwähnt werden sollten. Die erste ist eine "Null"-Objektreferenz, und die zweite ist eine "ungültige" Objektreferenz. Ähnlich zu transienten und dauerhaften Objektreferenzen entsprechen Null-Objektreferenzen und ungültige Objektreferenzen Null- und ungültigen Objekten. Ein Null-Objekt kann ein Objekt sein, das eine Schnittstelle nicht aufweist, oder in einem Zustand ist, in welchem es Clients nicht dienen wird. In bevorzugten Ausführungsformen wird die Null-Objektreferenz unterstützt und kann deswegen codiert sein. Ein ungültiges Objekt ist typischerweise ein nicht-existierendes oder falsch gebildetes Objekt und wird üblicherweise nicht unterstützt. Deswegen kann ein ungültiges Objekt typischerweise nicht codiert werden.
5a zeigt eine bildhafte Veranschaulichung einer Datenstruktur für eine transiente Objektreferenz 500 gemäß einer Ausführungsform der vorliegenden Erfindung. Die Objektreferenz 500 schließt ein Sortenfeld 501, einen Satz von Endpunktadressen 502, eine Inkarnationsnummer 504 und einen Objektschlüssel 506 ein. In bevorzugten Ausführungsformen ist das Sortenfeld 501 ein Datenelement, das die Objektsorte repräsentiert, auf welches die Objektreferenz 500 indirekt verweist. In anderen Ausführungsformen ist das Sortenfeld 501 nicht in der Objektreferenz 500 eingeschlossen, und die Objektsorte wird durch die unterscheidenden Merkmale der Datenstruktur der Objektreferenz 500 bestimmt. Das heißt die Objektsorte, auf welche eine Objektreferenz indirekt verweist, kann eindeutig durch die Datenstruktur der Objektreferenz bestimmt werden.
Indem die Diskussion der 5a fortgesetzt wird, schließt ein Satz von Endpunktadressen 502 eine Adressierungsinformation ein, die notwendig ist, damit ein Client den Server-Host und den Server-Prozess, in welchem das Zielobjekt existieren kann, lokalisiert. Diese Information kann Elemente wie etwa die Server-Hostnetzadresse, die Server-Prozessnetzanschlussnummer und/oder den Speicherort des Zielobjekts einschließen. Überdies kann der Satz von Endpunktadressen eine Vielzahl von Adressen einschließen, wobei jede gültig sein kann. Der Satz von Endpunktadressen kann ein Datenelement einer variablen oder festen Länge einschließen. Geeignete Längen für ein Datenelement einer festen Länge liegen in dem Bereich von ungefähr 1–128-Byte, während Längen in dem Bereich von ungefähr 24–96-Byte bevorzugt sind, wobei eine Länge von ungefähr 64 Byte bevorzugter ist. Im Wege eines Beispiels kann, wenn das Netzprotokoll das altbekannte Übertragungssteuerprotokoll/Internetprotokoll (TCP/IP) ist, dann eine Adresse in dem Satz der Adressierungsinformation 502 ein 6-Byte-Datenelement einschließen, worin die ersten vier Bytes die TCP/IP-Server-Hostnetzadresse in einer Netzreihenfolge sind, und die anderen zwei Bytes die TCP/IP-Server-Prozessnetzanschlussnummer auch in einer Netzreihenfolge sind. Ein weiteres Element der Objektreferenz 500 der 5a, die Inkarnationsnummer 504, ist ein Identifizierer, der eine Fehllieferung von ORB-Anforderungen an die falsche Bestimmungsstelle in dem Fall einer Adress-Wiederverwendung verhindert. Mit anderen Worten ist es, auch mit dem Satz einer Adressierungsinformation, die die Server-Hostadresse und die Server-Prozess-Identifikation genau festlegt, möglich, dass der Server-Prozess nicht eindeutig identifiziert. Wie untenstehend diskutiert, überwindet die Inkarnationsnummer der vorliegenden Erfindung potentielle ORB-Fehllieferungen.
Während eine Fehllieferung auf den ersten Blick unmöglich ist, muss man sorgfältig betrachten, wie transiente Objekte und ihre Host-Server-Prozesse verwaltet werden. Transiente Objekte existieren nicht von Prozess zu Prozess, sondern hören vielmehr auf, wenn ihr Server-Prozess aufhört. Aber, wie Durchschnittsfachleute verstehen werden, erstellt und löscht ein laufender Computer konstant Computer-Prozesse, wobei jeder dieser Prozesse eine spezifische Netzadresse aufweist. Deswegen ist es sicher, dass ein Prozess aufhören kann, wodurch sämtliche der eindeutigen transienten Objekte, die innerhalb desselben existieren, aufhören und auch eine Netzadresse freigesetzt wird. Diese Netzadresse kann wieder verwendet werden, da nur eine unendliche Menge von Prozess-Netzadressen verfügbar sind (32, 768 oder 32K ist eine typische Anzahl). Somit kann eine Anforderung nach einem transienten Objekt, das aufgehört hat, von der ORB fehlgeleitet werden, wenn irgendeine andere unterscheidende Identifikation nicht bereitgestellt wird.
Da der ORB für das Interpretieren der Inkarnationsnummer 504 verantwortlich ist, ist der ORB und spezifischer der Objektadapter (OA) typischerweise für das Zuordnen der Inkarnationsnummer 504 verantwortlich. Diese Nummer kann willkürlich sein, solang sie von dem ORB unterscheidbar ist. Verschiedene Ausführungsformen der Inkarnationsnummer 504 werden betrachtet. Beispielsweise erlaubt es das Zuordnen der Inkarnationsnummer 504 zu einem monoton ansteigenden Wert, wie etwa einem Zeitstempel, dass der ORB zwischen unterschiedlichen Prozessen unterscheidet, die nicht gleichzeitig existieren, aber zufällig die gleiche Adresse empfangen. In anderen Fällen kann es gewünscht sein, zwei oder mehrere Prozesse zu haben, die nicht-unterscheidbar sind. In diesem Fall könnten identische Inkarnationsnummern absichtlich zugeordnet werden. Noch weitere Situationen können auftreten, wenn es gewünscht wird, dass eine vorbestimmte Nummer wie etwa eine Null der Inkarnationsnummer 504 zugeordnet wird. Jedenfalls kann die Inkarnationsnummer 504 ein Datenelement einer festen oder variablen Länge einschließen, in Abhängigkeit von dem vorbestimmten Protokoll. Geeignete Längen für ein Datenelement einer festen Länge liegen in dem Bereich von ungefähr 1–16 Byte, wobei Längen in dem Bereich von ungefähr 2–6 Byte bevorzugt sind, und eine Länge von ungefähr 4 Byte bevorzugter ist.
Wie von Durchschnittsfachleuten erkannt werden wird, ermöglicht es die Inkarnationsnummer, entweder wie in der obigen Ausführungsform oder in anderen Ausführungsformen, dass eine verpellte Objektvertriebsumgebung Objekte fehlerlos unterscheidet. Die Inkarnationsnummer ist in der vorliegenden Erfindung neu und gestattet die Verwendung dauerhafter und transienter Objekte innerhalb einer verteilten Objektumgebung.
Das letzte aufgelistete Element der transienten Objektreferenz 500 von 5a ist der Objektschlüssel 506. In einer Ausführungsform dient der Objektschlüssel 506 dazu, zwischen Objekten innerhalb des Serverprozesses zu unterscheiden. In Abhängigkeit von dem vorbestimmten Protokoll kann der Objektschlüssel 506 ein Datenelement einer festen oer variablen Länge einschließen. Geeignete Längen für ein Datenelement einer Festlänge liegen in dem Bereich von 1– 16 Bytes, wobei Längen in den Bereich von 4–8 Bytes bevorzugt sind, und eine Länge von ungefähr 6 Bytes bevorzugter ist.
5b zeigt eine bildhafte Veranschaulichung einer dauerhaften Objektreferenz 510 gemäß einer Ausführungsform der vorliegenden Erfindung. Die dauerhafte Objektreferenz 510 ist ein Objekt, das auf ein dauerhaftes Server-Objekt zeigt, und schließt ein Sortenfeld 511, einen Host-Namen 512, eine Lokatoridentifikationsnummer (Lokator-ID) 514, einen Objektschlüssel 515 und einen Unterobjekt-Identifizierer 518 ein. Wie gezeigt, kann die dauerhafte Objektreferenz auch einen optionalen Lokalisierungshinweis 520 einschließen. Wie oben unter Bezugnahme auf 5a diskutiert, ist das Sortenfeld 511 ein Datenelement, das die Objektsorte repräsentiert, auf welche die Objektreferenz 510 indirekt verweist. Der Hostname 512 schließt einen Hostcomputer ein, der einen Lokatorserver aufweist (der eine Einheit wie etwa ein Lokatorprozess oder ein Lokatorobjekt ist), der zum Aufrechterhalten der Worte der Zielobjekte verantwortlich ist. Beispielsweise kann der Host-Name 512 eine Netzadresse einschließen. In bevorzugten Ausführungsformen weist der Host-Computer, der durch den Host-Namen 512 angezeigt wird, das Zielobjekt darin liegend auf.
Unter Bezugnahme als nächstes auf das dritte aufgelistete Element der dauerhaften Objektreferenz 510 der 5b identifiziert die Lokatorgruppe ID 514 eindeutig den Lokatordienst auf dem Host, der durch seinen Hostnamen definiert ist. In einer Ausführungsform schließt die Locator-ID ein Datenelement einer festen Länge ein. Im Wege eines Beispiels ist eine geeignete Ausführungsform der Lokator-ID-515 eine Kernprozedurraufruf (RDC)-Programmnummer für den Lokator. Durchschnittsfachleute werden mit RPC-Protokollen und der Erzeugung von RPC-Programmnummern vertraut sein. Im allgemeinen wird der RPC-Dienst eine Entsprechung zwischen einer konstanten RPC-Programmnummer und der gewünschten Server-Prozessadressierungsinformation aufrecht erhalten, d. h., der RPC-Dienst wird aktualisiert, wann immer dieser Server-Prozessadressierungsprozession geändert wird. Somit muss das verteilte Objektsystem die dauerhafte Objektreferenz nicht autorisieren. In diesem Fall kann die Lokator-ID-514 ein Datenelement einer festen Länge mit einer Länge von 4 Bytes sein. Indem zu dem vierten Element der 5b als nächstes übergegangen wird, definiert der Objektschlüssel 516 in einer Ausführungsform ein Zielobjekt eindeutig bezüglich des Lokators. Somit verwendet der Lokator den Objektschlüssel 514, um zu bestimmen, welches gewünschte Zielobjekt angefordert wird.
Die kombinierten Datenelemente 512–516 bildeten ein Beispiel davon, was im Stand der Technik als eine "Indirektion" bekannt ist. Eine "Indirektion" ist ein Satz einer Information, ein Zeiger, etc., der die Client-Einheit zu einer Quelle (wie etwa einem Lokatorobjekt verweist), die die Client-Einheit auf das Objekt richten kann. Im Wege einer beschreibenden Analogie würde, wenn ein Client geographische Richtungen anforderte, eine Indirektion den Client an den Ort einer gegenwärtigen Karte richten oder vielleicht den Client mit einer Telefonnummer einer geografisch bewanderten Einzelperson versehen. Die Idee eines Verwendens einer Indirektion (anstelle einer direkten Adressierung) ist für die dauerhaften Objekte nützlich, da sie sowohl von Prozess zu Prozess als auch von Host-Computer zu Host-Computer mobil sind.
Unter fortgesetzter Bezugnahme auf 5b ist der Unter-Objekt-Identifizierer 518 ein Datenelement, das typischerweise nur von dem Zielobjekt verwendet wird, um feinkörnigere Objekte zu verwalten. Im Wege einer Analogie kann eine Tabellenkalkulation ein Objekt sein, wobei die Zellen der Tabellenkalkulation Unterobjekte sind. Die Granularität von Objekten, Unterobjekten und Verfahren und Vorrichtungen zum Verwalten von Unterobjekten sind detaillierter in der EP-A-0 733 970 beschrieben. Ein weiteres Element, das wahlweise in die dauerhafte Objektreferenz 510 geschlossen ist, ist der Lokalisierungshinweis 520. Der Lokalisierungshinweis 520 ist ein optionales Datenelement, das Details betreffend den letzten bekannten Ort des Zielobjekts bereitstellt. Der Lokalisierungshinweis 520 kann auch einen Ablauf-Zeitstempel einschließen. Im Wege einer Erklärung kann das Zielobjekt zuvor aufgerufen worden sein, womit die Adressierungsinformation für das Zielobjekt zu einer früheren Zeit wiedergewonnen wurde. Unter Verwendung dieses Lokalisierungshinweises 520 kann es das verteilte Betriebssystem vermeiden, den Anruf an den Lokator auszuführen. Natürlich muss, wenn der Lokalisierungshinweis 520 abgelaufen ist oder nicht vorhanden ist, dann der Lokator in jedem Fall angefragt werden.
Die Ausführungsform der vorliegenden Erfindung, die oben unter Bezugnahme auf die 5a und 5b beschrieben ist, dient dazu, die unterschiedlichen Sorten von Objektreferenzen in einen verteilten Betriebsumgebungsrahmen vollständig zu integrieren. Wie beschrieben kann die verteilte Objektumgebung zwischen zwei primären Sorten von Objektreferenzen unterscheiden und noch die Vorteile gemäß jeder Sorte aufrecht erhalten.
Eine weitere Integration tritt durch Benutzung der Datenelemente, die durch die vorliegende Erfindung bereitgestellt werden auf. Beispielsweise kann der Objektschlüssel in sowohl transienten als auch dauerhaften Objektreferenzen zum Transportieren einer Objektreferenz, die gemäß einem ersten Protokoll eines ersten verteilten Systems formatiert ist, in ein zweites verteiltes System, das ein zweites Protokoll benutzt, verwendet werden. Dies kann durch ein Formatieren einer zweiten Objektreferenz gemäß des zweiten Protokolls und eines Speichern derselben in einem Objektschlüssel einer variablen Länge der ersten Objektreferenz durchgeführt werden. Auf ein Emopfangen der Objektreferenz hin kann das zweite verteilte System den Objektschlüssel ausstreichen und eine Objektreferenz für das Zielobjekt erzeugen, die in dem geeigneten Format für das zweite verteilte System ist. Somit können sowohl transparente als auch dauerhafte Objektreferenzen über Protokolle durch einen identischen Mechanismus – den Objektschlüssel transferieren.
Noch ein weiterer Beleg des vollständig integrierten Rahmens, den die vorliegende Erfindung bereitstellt, kann in der Betrachtung des Lokalisierungshinweises der Datenstruktur der dauerhaften Objektreferenz gefunden werden. Wie offensichtlich sein wird, kann eine geeignete Ausführungsform für den Lokalisierungshinweis einen Satz von Adressierungsinformation, eine Inkarnationsnummer und ein Ablaufdatum einschließen. In dem Fall, wo der Lokalisierungshinweis verfügbar ist, gegenwärtig und gültig, verweist die dauerhafte Objektreferenz indirekt auf ihr dauerhaftes Objekt durch den exakt gleichen Mechanismus, durch den eine transiente Objektreferenz auf ihr transientes Objekt verweist. Nicht nur dass diese Kombination zum Integrieren der zwei Sorten von Objektreferenzen wirksam ist, legt sie auch den Rahmen für ein neues und kosteneffizientes Verfahren (bezüglich einer System-Ressourcen-Benutzung) um eine dauerhafte Zielobjekte aufzurufen, weil das Verfahren darin besteht: Anrufe an dauerhafte verteilte Objekte direkt anstelle über die Verwendung eines Lokators auszuführen.
Während die offenbarten Ausführungsformen der transienten und dauerhaften Objektreferenzen einige bevorzugte Rahmen zum implementieren des Datenstrukturaspekts der vorliegenden Erfindung bereitstellen, sind viele andere geeignete Ausführungsformen vorhanden. Beispielsweise kann das verteilte Betriebssystem in manchen Ausführungsformen jedwede Objektreferenz aktualisieren, wenn ein dauerhaftes Objekt seinen Ort bewegt. Somit können dauerhafte und transiente Objektreferenzen eine direkte Adressierungsinformation anstelle der Indirektion aufweisen, die in der Ausführungsform der dauerhaften Objektreferenz 510 der 5b beschrieben ist. In einem weiteren Beisiel können Ausführungsformen eine direkte Adressierung vollständig beseitigen, in Abhängigkeit nur von einer Indirektion. In diesem Fall kann die transiente Objektreferenz in der Form ähnlich der dauerhaften Objektreferenz 510 auftreten. Noch weitere Ausführungsformen werden Merkmale einschließen, die durch spezifische Netzkommunikationsprotokolle erforderlich sind, um einen Betrieb in ihrem spezifischen Rahmen zu ermöglichen.
Wie aus der vorangehenden Diskussion offensichtlich sein wird, wird ein verteiltes Betriebssystem, das die zuvor erwähnten Strukturen für Objekte benutzt, die transiente und dauerhafte Objekte einschließt und transiente und dauerhafte Objektreferenzen einschließen, viele Vorteile gegenüber dem Stand der Technik aufweisen. Diese Vorteile werden in der folgenden Diskussion der "Serverwechselwirkungen, die Verfahrensaspekte der vorliegenden Erfindung benutzen, klarer werden.
Indem nun auf 6 übergegangen wird, wird ein Verfahren 600 zum Implementieren der Client-Server-Wechselwirkung in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung beschrieben werden. Die Client-Server-Wechselwirkung beginnt in dem Schritt 602, wenn der Client das Server-Objekt (auch als das Zielobjekt bezeichnet) aufruft. Der Client kann jedwede geeignete Einheit wie etwa einen Client-Prozess oder ein Client-Objekt sein. In einem nächsten Schritt 604 erlangt der Client eine Adressierungsinformtion betreffend das Serverobjekt. Beispielsweise kann die erlangte Adressierungsinformation Daten einschließen, wie sie etwa in der vorangehenden Diskussion der transienten und dauerhaften Objektreferenzen beschrieben sind. Es sollte erkannt werden, dass diese Adressierungsinformation eine Mehrzahl von Adressen einschließen kann, von welchen eine spezifische Adresse ausgewählt wird. Ein Kriterium zum Auswählen der Adresse ist es, den schnellsten Modus eines Transports zwischen dem Client und dem Server zu ermöglichen. Ein weiteres übliches Kriterium zum Auswählen der Adresse ist die Sicherheit. Auch kann ein Erlangen dieser Adressierungsinformation verschiedene Schritte aufgrund der Tatsache einschließen, dass die Information in unterschiedlichen Quellen lokalisiert sein kann.
Sobald die Adressierungsfunktion in dem Schritt 604 erlangt ist, evaluiert der Client in einem Schritt 606 die Adressierungsinformation, um eine spezifische Adresse auszuwählen. In dem Schritt 606 kann der Client eine Adresse auf der Grundlange unterschiedliche Grundprinzipien einschließlich Ziele, wie etwa eine Transportgeschwindigkeit zwischen dem Client und dem Server, einer Lastteilung, einer Sicherheit und/oder Bedenken hinsichtlich der Integrität der Adressierungsinformation wählen. Eine detailliertere Veranschaulichung einer Ausführungsform der Unterschritte des Schritts 606 wird unten stehen unter Bezugnahme auf 8 diskutiert.
Indem durch das Verfahren 600 der 6 fortgefahren wird, sendet der Client in einem Schritt 608 die Anforderung an die Adresse, die in dem Schritt 606 ausgewählt ist. Wenn die Adresse eine Fernadresse ist, kann der Schritt 608 die Schritte eines Aufstellens der ausgewählten Adresse zusammen mit dem Verfahren und den Argumenten einschließen, indem eine Netzverbindung mit dem entfernten Zielobjekt eingerichtet wird, und dann ein Fernaufruf zu dem Zielobjekt ausgeführt wird. Wie hierin verwendet, steht ein "Aufstellen" von Daten darin, die Daten gemäß einem vorbestimmten Netzkommunikationsprotokoll in Vorbereitung für eine Netzübertragung zu formatieren. In einem Schritt 610 wird bestimmt, ob der Client eine Antwort erwartet und wenn dem so ist, wird eine Prozesssteuerung zu einem Schritt 612 übergeben, wobei der Client die Antwort von dem Zielobjekt empfängt. Ähnlich zu dem Schritt 608 kann, wenn das Zielobjekt entfernt ist, dann der Client die Antwort von dem Zielobjekt "vereinzelt", d. h. die Daten werden von einem vorbestimmten Netzkommunikationsprotokoll in ein Format übersetzt, das für den Client aussagekräftig ist. Nach einem Empfangen der Antwort, oder wenn keine Antwort erwartet wird, schreitet die Steuerung zu einem Schritt 614 fort, auf welchen hin die Client-Server-Wechselwirkung der 6 beständig ist.
Unter Bezugnahme nun auf 7 wird eine detailliertere Beschreibung des Schrittes 604 in Übereinstimmung mit einem Verfahrensaspekt der vorliegenden Erfindung beschrieben werden. Wie von Durchschnittsfachleuten erkannt werden wird, ist das Verfahren der 7 allgemeine Verwendung in einem verteilten Objektsystem der Benutzung der Objektreferenzen der 5a und 5b oder ähnlicher Objektreferenzen. Jedoch schließt, wie offensichtlich werden wird, der Umfang der vorliegenden Erfindung andere Ausführungsformen des Schritts 604 ein, die für zusätzliche Ausführungsformen von Objektreferenzen geeigneter sind.
Das Flussdiagramm der 7 beginnt in einem Schritt 702, wenn die Steuerung zu dem Schritt 604 der 6 übergeben wird. Der anfängliche substantielle Schritt der 7, der einen Schritt 704, bestimmt, ob die Objektsorte transient ist. Wie oben unter Bezugnahme auf die 5a und 5b diskutiert, kann die Objektsortenbestimmung durch verschiedene Verfahren, wie etwa ein Untersuchen des internen Namens erreicht werden. In dem Fall, wo die Objektsorte transient ist, verzweigt die Steuerung zu einem Schritt 706, wo die Adressierungsinformation direkt von der Objektreferenz zurückgegeben wird. Dies ist möglich, weil eine transiente Objektreferenz gemäß 5a eine direkte Adressierungsinformation im Gegensatz zu einer Indirektion aufweist. Sobald die Adressierungsinformation in dem Schritt 706 zurückgegeben ist, wird die Steuerung zu einem Schritt 708 übergeben, wo der Schritt 604 zur Erlangung der Adressierungsinformation beendet ist.
Indem der andere Zweig des Schritts 704 herunter verfolgt wird, wird, wenn die Objektsorte nicht transient ist, die Steuerung zu einem Schritt 710 übergeben, wo bestimmt wird, ob die Objektsorte dauerhaft ist. Wenn die Objektsorte nicht dauerhaft ist (das Objekt null oder ungültig ist), kann die Steuerung zu einem Schritt 712 übergeben werden, wobei eine Fehlermeldung erzeugt wird und der Schritt 604 beendet wird. Wie offensichtlich sein sollte, ist es, wenn das Objekt weder transient noch dauerhaft ist, unpassend, eine Anforderung an das Zielobjekt zu senden (da es entweder Null oder ungültig ist) und somit ist eine Fehlermeldung geeignet.
Andererseits wird, wenn in dem Schritt 710 bestimmt wird, dass die Objektsorte dauerhaft ist, dann in einem Schritt 714 ein Speicher-Cache 1 überprüft, um zu sehen, ob die Zielobjekt-Adressierungsinformation darin liegt. Wenn dem so ist, schreitet die Steuerung zu einem Schritt 720 fort, wo die Adressierungsinformation direkt von dem Cache-1 zurückgegeben wird, und dann weiter zu einem Schritt 708, wo der Schritt 604 (der eine Adressierungsinformation erlangte) beendet ist. Der Cache-Speicher kann jedweder geeigneter Speicher, wie etwa ein lokaler RAM 38 sein, der unter Bezugnahme auf 2 beschrieben ist. Ein Speichern und Wiedergewinnen der Adressierungsinformation in dem Speicher/Cache-1 gestattet einen direkten und schnellen Zugriff auf diese Information.
Wenn die Adressierungsinformation nicht in dem Cache-1 liegt, schreitet die Steuerung zu einem Schritt 716 fort, wo der Client die Adressierungsinformation erhält. In typischer Weise wird die Adressierungsinformation in dem Schritt 716 mittels einer Indirektion unter Benutzung eines Lokatordiensts erhalten, wie zuvor unter Bezugnahme auf die 5a und 5b beschrieben. Eine Ausführungsform des Schritts 716 wird detaillierter untenstehend unter Bezugnahme auf 9 beschrieben werden. Nachdem die Adressierungsinformation in dem Schritt 716 erhalten ist, wird sie in dem Cache-1 in einem Schritt 718 gespeichert, wodurch die Wirksamkeit dieses Verfahrens bewahrt wird. Zusätzlich wird ein weiterer Mechanismus zum Erhöhen der Adressierungsinformation, die in dem Cache-1 verfügbar ist, und unter Bezugnahme auf 11 beschrieben werden. Dann wird in einem Schritt 720 die Adressierungsinformation von dem Cache-1 zurückgegeben, und die Steuerung wird zu einem Schritt 708 übergeben, wo der Schritt 604 eines Erlangens der Adressierungsinformation beendet ist.
Eine Ausführungsform des Adressauswahlschritts 606 der 6 wird nun in weiterem Detail unter Bezugnahme auf 8 beschrieben werden. Diese Ausführungsform dient primär dazu, die Adressierungsinformation zu wählen, die den schnellsten Modus eines Transports zwischen dem Client und dem Server anstellen wird. Die drei unterschiedlichen Moden eines Transports, die hierin beschrieben sind, sind (in Absteigender Reihenfolge einer Transportgeschwindigkeit) ein lokaler, ein geteilter Speicher, und ein Ferntransport. Ein lokaler Transport tritt innerhalb des gleichen Prozesses auf und wird durch Kopieren der Daten innerhalb des gleichen Adressraums durchgeführt. Ein geteilter Speichertransport (kann auch als ein "gleicher Host") bezeichnet werden wird unter Verwendung der Inter-Prozess-Kommunikationsprozeduren des Host-Betriebssystems durchgeführt. Ein Ferntransport unter Verwendung von Netzeinrichtungen. Jeder davon kann in Abhängigkeit von Faktoren wie etwa dem Betriebssystem und dem Netzkommunikationsprotokoll variieren. Die Auslegung und Implementierung eines lokalen, eines geteilten und eines Ferntransports werden Durchschnittsfachleuten vertraut sein.
Das Flussdiagramm der 8 beginnt in einem Schritt 802, wenn die Steuerung zu dem Schritt 606 der 6 übergeben wird. Dann wird in einem Schritt 804 bestimmt, ob das Zielobjekt in dem kleinen Prozess läuft. Wenn dem so ist, werden dann in einem Schritt 806 die lokale Adresse und der lokale Transport gewählt, um den Client und den Server zu verbinden. Andererseits wird, wenn das Zielobjekt nicht in dem Clientprozess läuft, dann in einem Schritt 810 bestimmt, ob das Serverobjekt auf dem gleichen Host wie der Client läuft, und ob eine geteilte Speicheradressierungsinformation verfügbar ist. Wenn dem so ist, werden dann in einem Schritt 810 eine geteilte Speicheradressierung und ein geteilter Speichertransport gewählt, um den Client und den Server zu verbinden. Andernfalls wählt, wenn das Zielobjekt weder in dem Clientprozess noch in dem Client-Host liegt, ein Schritt 814 die Fernadresse und den Ferntransport aus, um den Client und den Server zu verbinden. Jedenfalls wird, nachdem die Adressierung gewählt worden ist, die Steuerung zu einem Schritt 808 übergeben, worin der Schritt 606 der 6 beendet ist.
Unter Bezugnahme als nächstes auf 9 wird eine Ausführungsform des Schritts 716 der 7 detaillierter beschrieben. Das Verfahren der 7 beginnt in einem Schritt 902, wenn der Schritt 716 zum Erhalten einer Steuerung empfängt. Als nächstes wird in einem Schritt 904 die transiente Objektreferenz für einen ORB-Dämonprozess im Wege der Lokator-ID und des Host-Namens erhalten. In einer Ausführungsform liegt ein ORB-Dämenprozess auf jedem Computersystem der verteilten Objektumgebung. Der ORB-Dämon, der spezifisch in dem Schritt 904 zu finden ist, ist ein Prozess, der auf dem Server-Hostcomputer im Hintergrund läuft, unter welchem ein Lokatorobjekt aktiviert ist. Dämon-Prozesse sind Durchschnittsfachleuten wohl bekannt. Als nächstes ruft der Client in einem Schritt 906 das Lokatorobjekt an, um ein Nachschlageverfahren aufzurufen, wobei Argumente, die den Objektschlüssel für das Zielobjekt einschließen, übergeben. Im Ansprechen darauf wird der ORB-Dämon eine direkte Adressierungsinformation für das Zielobjekt zurückgeben. In bevorzugten Ausführungsformen wird der Dämonprozess zusätzlich den Zustand des Server-Prozesses verifizieren, indem der Prozess gestartet wird, falls notwendig. Eine bevorzugte Ausführungsform einer Inbetriebnahme des Server-Prozesses kann in der EP-A-0737922 gefunden werden. Nachdem die direkte Adressierungsinformation empfangen ist, wird die Steuerung zu einem Schritt 908 übergeben, worin der Schritt 716 der 7 beendet ist.
Indem als nächstes auf 10 übergegangen wird, wird eine Ausführungsform des Schritts 904 der 9 detaillierter beschrieben werden. Das Verfahren der 10 beginnt in einem Schritt 1002, wenn der Schritt 904 für die geholte transiente Objektreferenz für den ORB-Dämon die Steuerung empfängt. In einem Schritt 1004 wird bestimmt, ob die transiente Objektreferenz für den ORB-Dämon in einem Speicher-Cache-2 liegt. Wenn dem so ist, verzweigt die Steuerung zu einem Schritt 1012, wo die transiente Objektreferenz für den ORB-Dämon direkt von dem Cache-2 zurückgegeben wird. Nachdem die transiente Objektreferenz zurückgegeben ist, wird die Steuerung zu einem Schritt 1004 übergeben, worin der Schritt 904 der 9 beendet ist.
Wenn die transiente Objektreferenz für den ORB-Dämon nicht in dem Cache-2 liegt, verzweigt die Steuerung zu einem Schritt 1006, worin der Client den Fern-Prozeduraufruf-(RPC)-Binder auf dem Server-Host anruft, indem die Lokator-ID und die Inkarnationsnummer als Argumente für den Anruf übergeben werden. Im Ansprechen darauf gibt der RPC-Binder eine Adressierungsinformation zurück und in einem Schritt 1008 konstruiert der Client die transiente Objektreferenz unter Benutzung der zurückgegebenen ORB-Dämon-Adressierungsinformation. Eine Implementierung und ein Aufbau des RPC-Binders sind Durchschnittsfachleuten wohl bekannt. Sobald die transiente Objektreferenz konstruiert worden ist, speichert der Client diese in dem Cache-2 in einem Schritt 1010, wodurch die Effizienz dieses Verfahrens bewahrt wird. Dann wird die Steuerung zu einem Schritt 1012 übergeben, wo die transiente Objektreferenz für den ORB-Dämon direkt von dem Cache-2 zurückgegeben wird. Nachdem die transiente Objektreferenz zurückgegeben ist, wird die Steuerung Schritt 1014 übergeben, worin der Schritt 904 der 9 beendet ist.
Ein Verfahren zum Erhöhen der Adressierungsinformation, die in dem Cache-1 verfügbar ist, wird nun unter Bezugnahme auf 11 beschrieben werden. Im Wege eines Hintergrunds kann eine Objektreferenz für ein dauerhaftes Objekt einen wahlweisen Lokalisierungshinweis aufweisen (wie unter Bezugnahme auf 5b und anderswo beschrieben). Der Lokalisierungshinweise schließt eine direkte Adressierungsinformation für ein Zielobjekt ein. Somit sucht jeder Lokalisierungshinweis, der den Adressierungsinformationsschritt 714 der 7 aufweist, in dem Cache-1. Überdies können, wie von Durchschnittsfachleuten erkannt werden wird, Objektreferenzen von einem Host-Computer entweder über einen Objektaufruf oder im Ansprechen auf einen Objektaufruf empfangen werden. Somit besteht das Potential, die Adressierungsinformation jedes mal dann zu erhöhen, wenn eine Objektreferenz empfangen wird.
In dem Verfahren der 11 vereinzelt ein erster Schritt 1100 eine Objektreferenz, die aus irgendeinem Grund empfangen worden ist, wie etwa die beiden erwähnten in dem voranstehenden Absatz. Dann wird in einem Schritt 1102 bestimmt, ob die Objektreferenz einen Lokalisierungshinweis aufweist. Wenn dem so ist, wird in einem Schritt 1104 die Adressierungsinformation und ein Ablaufdatum (falls vorhanden) von dem Lokalisierungshinweis in den Cache-1 gespeichert. Wenn kein Lokalisierungshinweis vorhanden ist, oder auf ein Aktualisieren des Cache-1 hin wird das Verfahren der in 11 in einem Schritt 1106 ausgeführt, und die Objektreferenz kann für ihren ursprünglich vorgesehenen Zweck verwendet werden.
In einem weiteren Verfahrensaspekt der vorliegenden Erfindung, einem, der in enger Beziehung zu dem Verfahren der 11 steht, arbeiten die getrennten Computer der verteilten Objektbetriebsumgebung zusammen, um eine Adressierungsinformation zu teilen. Deswegen kann, wenn ein Computer einen Lokatordienst verwendet, um eine Adressierungsinformation über ein Zielobjekt zu erhalten, dieser Computer wiederum diese Information unter den anderen Computern der verteilten Objektbetriebsumgebung verteilen. Ein geeigneter Weg, diese Information zu übergeben, würde im Wege einer Objektreferenz sein. Dann würde jeder Computer dieser Adressierungsinformation zusammen mit einem Ablaufdatum in seinen Cache-1-Speicher speichern.
Ein weiterer Vorteil der vorliegenden Erfindung kann nun diskutiert werden. Wie von Durchschnittsfachleuten erkannt werden wird, teilt ein Modell (das für die vorliegende Diskussion zweckmäßig ist) den ORB in drei unterschiedliche Abstraktionsebenen, die hierin als der Anwendungsebenen-ORB, der Transportebenen-ORB und der Kommunikationsebenen-ORB bezeichnet werden. Komponenten, die für den unteren Kommunikationsebenen-ORB repräsentativ sind, würden die Aktivitäten der geteilten, lokalen und Fern-Adressierung und des Transports, die oben unter Bezugnahme auf 8 diskutiert sind, einschließen. Komponenten, die darstellend für den oberen Anwendungsebenen-ORB darstellend sind, würden den anfänglichen Clienten-Anruf an den Server darstellen, wobei der Ort und die Objektsorte des Servers für den Client unsichtbar sind. Die mittlere Ebene, der Transportebenen-ORB, ist der einzige Abschnitt des ORBs, der mit der Sorte des Serverobjekts befasst sein muss. Somit löst die vorliegende Erfindung die Aufgabe eines Integrierens von transienten und dauerhaften Objekten in einer verteilten Objektumgebung, ohne über den ORB hinweg eine unangemessene Last einzuführen, wodurch die Effizienz der verteilten Objektumgebung sichergestellt wird.
Obwohl nur einige Ausführungsformen der vorliegenden Erfindung beschrieben worden sind, ist zu verstehen, dass die vorliegende Erfindung in vielen anderen spezifischen Formen ausgeführt werden kann, ohne von dem Umfang der Erfindung abzuweichen, wie in den beigefügten Ansprüchen definiert ist. Die unter Bezugnahme auf die 3a–3b diskutierten Client-Servermodelle sind nur Beispiele und sind in keiner Weise als einschränkend auszulegen. Im Wege eines Beispiels könnte das "Host-zu-Host" Modell extrapoliert werden, um mehrfache Zielobjekte einzuschließen. Das heißt, das erste Zielobjekt 304 könnte einfach eine Objektreferenz sein, die auf ein weiteres Zielobjekt indirekt verweist, vielleicht in einer weiteren verteilten Objektumgebung. Oder das erste Zielobjekt könnte einen Teil des angeforderten Dienstes durchführen und dann seinen eigenen Anruf an ein zweites Zielobjekt ausführen, bevor dem ersten Client 302 geantwortet wird. Wie erkannt werden wird, bringen die möglichen Aufzählungen viele Ausführungsformen mit sich, wovon sämtliche in den Umfang der vorliegenden Erfindung fallen.
Weiterhin können die Datenstrukturen der 5a und 5b noch in hohem Maße variiert werden und fallen noch in den Umfang der vorliegenden Erfindung. Als ein erstes Beispiel können Datenstrukturen für sowohl transiente als auch dauerhafte Objektreferenzen ohne das Sortenfeld ausgeführt werden. Noch weitere Beispiele können durch ein Betrachten der Vielfalt von Netzkommunikationsprotokollen, Betriebssystemen und Anwendungsprogrammen gefunden werden. Jede(s) von diesen kann eine spezifische Anordnung der beschriebenen Datenstrukturen erfordern. Ein Aufbau und eine Implementierung jeder dieser zahlreichen Ausführungsformen wird Durchschnittsfachleuten offensichtlich sein, und sie fallen dementsprechend in den Umfang der vorliegenden Erfindung.
Wie von Durchschnittsfachleuten für verteilte Objektsysteme erkannt werden wird, können die zugrundeliegenden Ideen hinter den beschriebenen Modellen eines Handhabens transienter und dauerhafter Objekte in einer weiten Vielfalt alternativer Ausführungsformen implementiert werden, von welchen viel zu viele vorhanden sind, als dass sie im Detail zu diskutieren sind. Jedoch werden, da die zugrundeliegende Philosophie beschrieben worden ist, verschiedene Alternativen Durchschnittsfachleuten offensichtlich sein. Im Wege eines Beispiels kann das Verfahren eines Auswählens eines Transportmodus, eine Ausführungsform, die bezüglich 8 beschrieben wurde, viele Variationen aufweisen. Das Auswahlkriterium könnte einen Lastteilungswunsch hervorheben, womit eine Fernadresse die beste Adresse unter diesem Kriterium sein könnte. Von einem anderen Aspekt könnten unterschiedliche Formen eines Transports nicht beschrieben werden. Jedoch werden, wenn andere Formen eines Transports verfügbar ist, Durchschnittsfachleute verstehen, wie die Lehre der vorliegenden Erfindung anzuwenden ist, um diese anderen Moden eines Transports zu benutzen.
Deswegen sind die vorliegenden Beispiele als veranschaulichend und nicht einschränkend anzusehen, und die Erfindung ist nicht auf die hierin gegebenen Details beschränkt, sondern kann innerhalb des Umfangs der angehängten Ansprüche modifiziert werden.

Claims

Objekt (500) zur Verwendung als eine Objektreferenz für ein transientes Objekt, wobei vorgesehen ist, dass das transiente Objekt in einem Server-Computerprozess (318, 324) liegt, der auf einem Server-Computersystem (320, 322) in einer verteilten Objektbetriebsumgebung (301) abläuft, die eine Vielzahl verteilter transienter Objekte betrachtet, wobei das Objekt eine Datenstruktur aufweist, umfassend: einen Satz von Endpunktadressen (502), die eine Adressinformation bereitstellen, um den Server-Computerprozess auf dem Server-Computersystem zu lokalisieren; eine Inkarnationsnummer (504), die es zulässt, dass der Server-Prozess eindeutig identifiziert wird; und einen Objektschlüssel (506), der dem transienten Server-Objekt entspricht; derart, dass der Satz von Endpunktadressen, die Inkarnationsnummer und der Objektschlüssel das transiente Objekt eindeutig identifizieren und lokalisieren, und wobei die Objektsorte, auf welche die Objektreferenz weist, eindeutig aus der Datenstruktur des Objekts bestimmt werden kann.
Objekt nach Anspruch 1, wobei die Datenstruktur weiter ein Sortenfeld (501) einschließt, das anzeigt, dass die transiente Objektsorte transient ist.
Objekt nach Anspruch 1, wobei der Satz von Endpunktadressen (502) ein Datenelement einer variablen Länge ist.
Objekt nach Anspruch 1, wobei der Satz von Endpunktadressen (502) ein Datenelement einer festen Länge ist.
Objekt nach Anspruch 4, wobei eine Adresse des Satzes von Endpunktadressen (502) ein Datenelement ist, das in dem Bereich von 24–128 Bytes lang ist.
Objekt nach Anspruch 5, wobei 4 Bytes der einen Adresse eine Server-Computersystem-Netzadresse ist, und 2 Bytes der einen Adresse eine Server-Computerprozess-Netzanschlussnummer ist.
Objekt nach Anspruch 1, wobei der Satz von Satz von Endpunktadressen (502) eine Server-Computersystem-Netzadresse und eine Server-Computerprozess-Netzanschlussnummer einschließt.
Objekt nach Anspruch 1, wobei die verteilte Objektbetriebsumgebung (301) einen Client einschließt, der in einem Client-Computerprozess liegt, der auf einem Client-Computersystem abläuft, und der Satz von Endpunktadressen (502) und die Inkarnationsnummer (504) zusammen anzeigen, dass der Server-Computerprozess der Client-Server-Computerprozess ist.
Objekt nach Anspruch 1, wobei die verteilte Objektbetriebsumgebung (301) einen Client einschließt, der in einem Client-Computerprozess liegt, der auf einem Client-Computersystem abläuft, und der Satz von Endpunktadressen (502) und die Inkarnationsnummer (504) zusammen anzeigen, dass das Server-Computersystem das Client-Computersystem ist.
Objekt nach Anspruch 1, wobei die Inkarnationsnummer (504) ein Datenelement einer variablen Länge ist.
Objekt nach Anspruch 10, wobei die Inkarnationsnummer (504) ein Datenelement einer festen Länge ist.
Objekt nach Anspruch 11, wobei die Inkarnationsnummer (504) ein Datenelement ist, das in dem Bereich von 1– 16 Bytes lang ist.
Objekt nach Anspruch 1, wobei die Inkarnationsnummer (504) eine Nummer ist, die die Erstellungszeit des Server-Computerprozesses anzeigt.
Objekt nach Anspruch 1, wobei die Inkarnationsnummer (504) eine vordefinierte Nummer ist, die eine vordefinierte Bedeutung für den Server-Computerprozess aufweist.
Objekt nach Anspruch 1, wobei der Objektschlüssel (506) ein Identifizierer ist, der in Verbindung mit dem Satz einer Adressierungsinformation (502) und der Inkarnationsnummer (504) eindeutig das transiente Server-Objekt identifiziert.
Objekt nach Anspruch 15, wobei der Objektschlüssel (506) eine Identifikationsnummer ist, die innerhalb des Server-Computerprozesses eindeutig ist.
Objekt nach Anspruch 1, wobei die verteilte Objektbetriebsumgebung (301) eine erste verteilte Objektbetriebsumgebung ist, und wobei der Objektschlüssel ein zweites Objekt zur Verwendung als eine zweite Objektreferenz für ein transientes Objekt einer zweiten verteilten Objektbetriebsumgebung einschließt.
Objekt nach Anspruch 17, wobei es der Objektschlüssel (506) ermöglicht, dass ein Client in der ersten verteilten Objektbetriebsumgebung das transiente Objekt der zweiten verteilten Objektbetriebsumgebung aufruft.
Transientes Server-Objekt, das einer Objektreferenz nach Anspruch 1 entspricht, wobei das transiente Server-Objekt einen transienten Zustand aufweist, der diesem zugeordnet ist, wobei der transiente Zustand in einem transienten Speicher in dem Server-Computersystem (320) gespeichert ist.
Transientes Server-Objekt nach Anspruch 19, wobei das transiente Server-Objekt direkt an den Server-Computerprozess (318) derart gebunden ist, dass, wenn der Server-Computerprozess endet, das transiente Server-Objekt aufhört zu existieren.
Verteilte Objektbetriebsumgebung (301), umfassend: eine Vielzahl von Computersystemen (12, 16, 22, 18, 20); ein Computernetz (14), das die Vielzahl von Computersystemen verbindet; und zumindest ein Objekt nach einem der Ansprüche 1 bis 20, wobei das zumindest eine Objekt auf einem der Vielzahl von Computersystemen liegt.
Verteilte Objektbetriebsumgebung (301) nach Anspruch 21, weiter einschließend ein zweites Objekt zur Verwendung als eine Objektreferenz für ein dauerhaftes Objekt, wobei vorgesehen ist, dass das dauerhafte Objekt in einem zweiten Server-Computerprozess liegt, der auf einem zweiten Server-Computersystem abläuft, wobei das zweite Objekt eine Datenstruktur aufweist, welche einschließt: einen Computersystemnamen (512), der einem Computersystem entspricht, auf welchem ein Lokatordienst existiert; eine Lokatoridentifikation (514), die einem Dämoncomputerprozess entspricht, unter welchem der Lokatordienst liegt; und einen Objektschlüssel (516), der dem dauerhaften Objekt entspricht.
Verteilte Objektbetriebsumgebung (301) nach Anspruch 22, wobei die Datenstruktur des zweiten Objekts weiter ein Sortenfeld (510) einschließt, das anzeigt, dass die Sorte des Objekts dauerhaft ist.
Verteilte Objektbetriebsumgebung (301) nach Anspruch 22, wobei die Datenstruktur des zweiten Objekts weiter einen Lokalisierungshinweis (520) einschließt.
Verteilte Objektbetriebsumgebung (301) nach Anspruch 23, wobei der Lokalisierungshinweis (520) einschließt: einen Satz von Endpunktadressen, die dem zweiten Server-Computersystem entsprechen, auf welchem das dauerhafte Server-Objekt liegt; und eine Inkarnationsnummer, die dem zweiten Server-Computerprozess entspricht, derart, dass der Satz von Endpunktadressen, die Inkarnationsnummer und der Objektschlüssel das dauerhafte Server-Objekt eindeutig identifizieren und lokalisieren.
Verteilte Objektbetriebsumgebung nach Anspruch 22, weiter einschließend: eine dritte Objektsorte zur Verwendung als eine Objektreferenz für ein Nullobjekt; und eine vierte Objektsorte zur Verwendung als eine Objektreferenz für ein ungültiges Objekt.
Objekt (510) zur Verwendung als eine Objektreferenz für ein dauerhaftes Objekt, wobei vorgesehen ist, dass das dauerhafte Objekt in einem Server-Computerprozess (318, 324) liegt, der auf einem Server-Computersystem (320, 322) in einer verteilten Objektbetriebsumgebung (301) abläuft, die eine Vielzahl verteilter dauerhafter Objekte betrachtet, wobei das Objekt eine Datenstruktur aufweist, umfassend: einen Computersystemnamen (512), der einem Computersystem entspricht, auf welchem ein Lokatordienst existiert, wobei der Lokatordienst die Orte der dauerhaften Objekte aufrecht erhält; eine Lokatoridentifikation (514), die einem Dämoncomputerprozess auf dem Computersystem, auf welchem der Lokatordienst liegt, entspricht; und einen Objektschlüssel (516), der das dauerhafte Objekt bezüglich des Lokatordienstes eindeutig definiert, und wobei die Objektsorte, auf welche die Objektreferenz weist, eindeutig aus der Datenstruktur des Objekts bestimmt werden kann.
Objekt nach Anspruch 27, wobei die Datenstruktur weiter einen Lokalisierungshinweis (520) umfasst, der Details betreffend den zuletzt bekannten Ort des dauerhaften Objekts bereitstellt.
Objekt nach Anspruch 28, wobei der Lokalisierungshinweis einschließt: einen Satz von Endpunktadressen, die dem Server-Computersystem entsprechen; und eine Inkarnationsnummer, den dem Server-Computerprozess entspricht, derart, dass der Satz von Endpunktadressen, die Inkarnationsnummer und der Objektschlüssel das dauerhafte Objekt eindeutig identifizieren und lokalisieren.
Objekt nach Anspruch 27, weiter umfassend einen Unterobjektidentifizierer (518), der die Verwaltung von Unterobjekten des dauerhaften Objekts bereitstellt.
Objekt nach Anspruch 29, wobei das Computersystem, auf welchem ein Lokatordienst existiert, das Server-Computersystem (320) ist.
Objekt nach Anspruch 27, wobei die Datenstruktur des Objekts (314) weiter ein Sortenfeld (511) einschließt, das anzeigt, dass die Sorte des dauerhaften Objekts dauerhaft ist.
Verteilte Objektbetriebsumgebung (301) umfassend: eine Vielzahl von Computersystemen (12, 16, 22, 18, 20); ein Computernetz (14), das die Vielzahl von Computersystemen verbindet; und zumindest ein Objekt nach einem der Ansprüche 27 bis 32, wobei das zumindest eine Objekt auf einem der Vielzahl von Computersystemen liegt.
Dauerhaftes Server-Objekt, das einer Objektreferenz nach Anspruch 27 entspricht, wobei das dauerhafte Server-Objekt einen dauerhaften Zustand aufweist, der diesem zugeordnet ist, wobei der dauerhafte Zustand in einem dauerhaften Speicher auf dem Server-Computersystem gespeichert ist.
Dauerhaftes Server-Objekt nach Anspruch 34, wobei das dauerhafte Server-Objekt betriebsfähig ist, derart fortzubestehen, dass, wenn der Server-Computerprozess endet, das dauerhafte Server-Objekt seinen Zustand aufrecht erhält.
Computerimplementiertes Verfahren zum Aufrechterhalten einer verteilten Objektadressierungsinformation in einem Cache-Speicher auf einem Computersystem, wobei das Computersystem zur Verwendung in einer verteilten Objektbetriebsumgebung ausgelegt ist, wobei das Verfahren die Schritte umfasst: Empfangen, unter einer Computersteuerung, einer Objektreferenz nach einem der Ansprüche 1 bis 18 oder der Ansprüche 27 bis 32, wobei die Objektreferenz einem verteilten Objekt entspricht; und Bestimmen, unter einer Computersteuerung, ob die Objektreferenz eine Adressierungsinformation einschließt, die dem verteilten Objekt entspricht, und wenn dem so ist, Schreiben, unter einer Computersteuerung, der Adressierungsinformation in den Cache.
Verfahren nach Anspruch 36, wobei der Schritt eines Empfangens einer Objektreferenz weiter einen Schritt eines Vereinzelns, unter einer Computersteuerung, der Objektreferenz einschließt.
Verfahren nach Anspruch 37, wobei der Schritt eines Empfangens einer Objektreferenz ein Teil eines Zielobjektaufrufs ist.
Verfahren nach Anspruch 38, wobei der Schritt eines Empfangens einer Objektreferenz ein Teil einer Antwort auf einen Zielobjektaufruf ist.
Verfahren nach Anspruch 36, wobei der Schritt eines Schreibens der Adressierungsinformation ein Schreiben, unter einer Computersteuerung, eines Auslaufdatums für die Adressierungsinformation in den Cache einschließt.
Computerimplementiertes Verfahren zum Aufrufen eines verteilten Server-Objekts (301), von welchem vorgesehen ist, dass es auf einem Server-Prozess (318) liegt, der auf einem Server-Computersystem (320) abläuft, wobei das Server-Objekt eine entsprechende Objektreferenz (314) nach einem der Ansprüche 1 bis 18 oder der Ansprüche 27 bis 32 aufweist, die in einem Client-Prozess liegt, der auf einem Client-Computersystem (308) abläuft, wobei das Verfahren die Schritte umfasst: Erlangen (604), unter einer Computersteuerung, einer Adressierungsinformation für das verteilte Server-Objekt; Wählen (606), unter einer Computersteuerung, einer Adresse für das verteilte Server-Objekt; und Senden (608), unter einer Computersteuerung, einer Anfrage an das verteilte Server-Objekt.
Verfahren nach Anspruch 41, weiter einschließend den Schritt eines Empfangens (612), unter einer Computersteuerung, einer Antwort von dem verteilten Server-Objekt (304).
Verfahren nach Anspruch 41, wobei der Schritt eines Erlangens einer Adressierungsinformation (604) den Unterschritt (704) eines Bestimmens, unter einer Computersteuerung, der Sorte des verteilten Server-Objekts einschließt, wobei die Sorten transiente und dauerhafte einschließen.
Verfahren nach Anspruch 43, wobei die Sorten weiter Null und ungültige einschließen, und wobei der Schritt eines Erlangens einer Adressierungsinformation weiter den Unterschritt (712) eines Zurückgebens, unter einer Computersteuerung, einer Fehlermeldung einschließt, wenn die Sorte des verteilten Server-Objekts Null oder ungültig ist.
Verfahren nach Anspruch 43, wobei der Schritt eines Erlangens einer Adressierungsinformation weiter den Unterschritt (706) eines Zurückgebens, unter einer Computersteuerung, der Adressinformation direkt von der Objektreferenz einschließt, wenn die Sorte des verteilten Server-Objekts transient ist.
Verfahren nach Anspruch 43, wobei der Schritt eines Erlangens einer Adressierungsinformation weiter die Unterschritte einschließt: Bestimmen (714), unter einer Computersteuerung, ob die Adressinformation in einem Cache-Speicher gespeichert ist, der auf dem Client-Computersystem (308) angeordnet ist; und Zurückgeben (720) unter einer Computersteuerung, der Adressinformation aus dem Cache-Speicher, wenn die Sorte des verteilten Server-Objekts dauerhaft ist.
Verfahren nach Anspruch 46, wobei bestimmt wird, dass die Adressierungsinformation anfänglich nicht in dem Cache-Speicher gespeichert ist, und folglich der Schritt eines Erlangens einer Adressierungsinformation weiter die Zwischen-Unterschritte einschließt: Erhalten (716) unter einer Computersteuerung, der Adressierungsinformation aus innerhalb der verteilten Objektbetriebsumgebung (301); und Speichern (718), unter einer Computersteuerung, der Adressierungsinformation in dem Cache-Speicher.
Verfahren nach Anspruch 47, wobei die Objektreferenz eine Lokatoridentifikation, Host-Namen und einen Objektschlüssel einschließt, und wobei der Schritt. eines Erhaltens der Adressierungsinformation die Unterschritte einschließt: Einrichten (904), unter einer Computersteuerung, von Computerkommunikationen mit einem Dämonprozess (321), der auf dem Server-Computersystem (320) läuft; und Ausgeben (906), unter einer Computersteuerung, eines Nachschlagbetriebs an den Dämonprozess, der den Objektschlüssel zu dem Dämon weitergibt.
Verfahren nach Anspruch 48, wobei der Schritt eines Einrichtens von Computerkommunikationen mit einem Dämonprozess den Schritt (1004) eines Bestimmens, unter einer Computersteuerung, einschließt, ob eine transiente Objektreferenz für den Dämonprozess (321) in einem Cache-Speicher, der auf dem Client-Computersystem (308) zu finden ist, gespeichert ist, und wenn dem so ist, der Schritt eines Einrichtens von Kommunikationen weiter den Schritt (1012) eines Zurückgebens, unter einer Computersteuerung, der transienten Objektreferenz aus dem Cache-Speicher einschließt.
Verfahren nach Anspruch 49, wobei bestimmt wird, dass die transiente Objektreferenz nicht in dem Cache-Speicher gespeichert ist, und folglich der Schritt eines Einrichtens von Kommunikationen mit einem Dämonprozess (321) weiter die Zwischenschritte einschließt: Aufrufen (1006), unter einer Computersteuerung, einer Fern-Prozedur-Aufrufbindung auf dem Server-Computersystem unter Verwendung des Host-Namens, wobei der Aufrufschritt ein Weitergeben der Lokatoridentifikation mit einer vorbestimmten Inkarnationsnummer einschließt; Empfangen, unter einer Computersteuerung, einer Adresse von dem Fern-Prozedur-Aufrufbindungs-Aufruf; Aufbauen (100), unter einer Computersteuerung, einer transienten Objektreferenz für den Dämon, wobei die transiente Objektreferenz aus der Adresse und der vorbestimmten Inkarnationsnummer aufgebaut ist; und Speichern (1010), unter einer Computersteuerung, der transienten Objektreferenz in dem Cache-Speicher.
Verfahren zum Aufrufen eines verteilten Server-Objekts (304) nach Anspruch 41, wobei der Schritt (606) eines Wählens einer Adresse den Schritt (804) eines Bestimmens, unter einer Computersteuerung, einschließt, ob der Server-Prozess und der Client-Prozess die gleichen Prozesse sind.
Verfahren nach Anspruch 51, weiter einschließend den Schritt (806) eines Wählens, unter einer Computersteuerung, einer lokalen Adresse und eines lokalen Transports, wenn der Client-Prozess und der Server-Prozess die gleichen Prozesse sind.
Verfahren nach Anspruch 51, wobei bestimmt wird, dass der Client-Prozess und der Server-Prozess nicht die gleichen Prozesse sind, und das Verfahren weiter die Schritte einschließt: Bestimmen (810), unter einer Computersteuerung, ob das Server-Computersystem das gleiche wie das Client-Computersystem ist; Wählen (812), unter einer Computersteuerung, einer geteilten Speicheradresse eines geteilten Speichertransports, wenn das Server-Computersystem das gleiche wie das Client-Computersystem ist; und Wählen (814), unter einer Computersteuerung, einer Fern-Adresse und eines Fern-Transports, wenn das Server-Computersystem nicht das gleiche wie das Client-Computersystem ist.