DE69228621T2

DE69228621T2 - Objektorientiertes verteiltes Rechnersystem

Info

Publication number: DE69228621T2
Application number: DE69228621T
Authority: DE
Inventors: Kenneth C. Newton Ma 02159 Arnold; Michael J. Palo Alto Ca 94306 Cannon; Marlena Somerville Ma 02144 Erdos; Brian D. Scotts Valley Ca 95066 Harrison; D. Jeffrey Nashua Nh 03063 Hoffman; Brian W. Los Altos Ca 94022 Mcbride; Douglas B. Hollis Nh 03049 Robinson; Andrew F. Bristol Bs16 5Af Seaborne; Peter S. Cupertino Ca 95014 Showman; Lamar D. San Jose Ca 95129 Smith; James A. Dracut Ma 01826 Waldo
Original assignee: Hewlett Packard Co
Current assignee: Hewlett Packard Development Co LP
Priority date: 1991-02-25
Filing date: 1992-01-28
Publication date: 1999-07-22
Anticipated expiration: 2012-01-29
Also published as: EP0501610A3; JP3573762B2; EP0501610A2; EP0501610B1; DE69228621D1; US5475817A; JPH05181814A

Description

"Verteilte Berechnung" ist auf dem Gebiet der Computerverarbeitung ein gut bekanntes Konzept. Grundsätzlich erlaubt eine verteilte Berechnung, daß Prozesse auf unterschiedlichen Computern in einem Netzwerk von Computern miteinander kommunizieren und Dienste füreinander liefern. Die Computer in dem Netzwerk können unterschiedliche Maschinenarchitekturen und Betriebssysteme aufweisen.
Das üblichste Musterbeispiel einer verteilten Berechnung ist als das "Client-Server-Modell" bekannt. Verbraucher von Diensten, sogenannte Clients, führen Anforderungen zu Dienstanbietern, d. h. Servern, durch.
Es existieren verschiedene Nachteile einer verteilten Client-Server-Berechnung. Beispielsweise erfordern gegenwärtige Systeme, daß Client-Prozesse codiert werden, um exakt die Standorte der Server, die dieselben zu verwenden wünschen, zu erfassen (oder "zu kennen"). Wenn ein Server den Standort ändert, während ein Client denselben verwendet, muß der Client codiert sein, um eine Relokalisierung des Servers durchzuführen. Ohne eine derartige Relokalisierung wird ein Versuch des Client fehlschlagen, mit dem Server zu kommunizieren.
Die meisten Systeme erfordern ferner, daß ein Server vor irgendeiner versuchten Verwendung durch einen Client aktiv ist. Ein Client, der versucht, einen inaktiven Server zu verwenden, wird bei seinem Versuch, den Dienst, den er benötigt, zu erhalten, fehlschlagen.
Andere verteilte Computersysteme befassen sich entweder nicht mit Computerprogrammierungsentitäten, die als "Objekte" bezeichnet werden, oder erfordern, daß Objekte mit einem speziellen Objektmodell, das durch das System diktiert wird, übereinstimmen. Da in einem gegebenen System höchstens ein Objektmodell existiert und keine gemeinsamen Modelle über Systeme hinweg, sind solche verteilten Computersysteme unangemessen begrenzt. Das heißt, daß derartige Systeme in ihrer Fähigkeit begrenzt sind, eine neue Technologie aufzunehmen und sich auf Problembereiche zu erweitern, für die das System ursprünglich nicht entworfen wurde.
Ein verteiltes Objekt-orientiertes System ist aus dem bekannten Dokument D = "A communication system architecture for the Office" von Amine Benkiran u. a.; PROCEEDINGS EIGHT ANNUAL JOINT CONFERENCE OF THE IEEE COMPUTER AND COMMUNICATIONS SOCIETIES, 23. April 1989, OTTAWA, ONT., KANADA, S. 382-392, bekannt. Dieses Dokument beschreibt ein System mit einer verteilten Architektur, das durch eine Hierarchie von Objektmaschinen unterstützt wird, welche eine transparente Kommunikation zwischen einem Satz von verbundenen heterogenen. Computer- und Kommunikations-Systemen unter Verwendung eines Objektmodells ermöglicht. Das Konzept der Objektverwaltung "Object Management" ist in D definiert, siehe Seite 385, linke Spalte, zweiter Absatz. Es existiert ferner ein Kommunikationsverwalter (Communication Manager) mit der Aufgabe, Aufrufe zu einem Bestimmungsbereichsobjekt weiterzuleiten, siehe Seite 385, rechte Spalte, letzter Absatz. In dem System aus D ist ein zusätzlicher Mechanismus erforderlich, um zwischen entfernten Verwalterkomponenten zu kommunizieren. Dieser Mechanismus wird in D als Fernaktivierung bezeichnet. Die Verwendung eines Fernaufrufs erfordert eine explizite Adressierung des LOM (LOM = Local Object Manager = lokaler Objektverwalter), auf dem sich die Bestimmungsverwaltungskomponente befindet, siehe D, Seite 386, linke Spalte. Es ist erwünscht, eine Möglichkeit zu finden, um sich nicht auf eine explizite Adressierung, wie in D, zu stützen. Die Lösung für dieses Problem ist durch das Objektorientierte Computersystem gemäß dem unabhängigen Anspruch 1 definiert.
Wie er hierin verwendet ist, ist der Ausdruck "Objekt" eine Programmierungsentität, die einen bestimmten Zustand und ei nen Satz von definierten Verhaltensweisen umfaßt. Der Zustand ist durch Daten, die durch das Objekt gehalten werden, dargestellt. Das Verhalten ist hinsichtlich Operationen, die das Objekt durchführen kann, spezifiziert. Operationen werden durch einen ausführbaren Code realisiert. Konzeptmäßig sind die Daten und der Code in dem Objekt untrennbar miteinander verbunden. Objekte können "dauerhaft" ("persistent") sein, d. h. dieselben können weiterhin existieren, selbst wenn dieselben inaktiv sind oder der Computer, auf dem dieselben existieren, ausgefallen ist oder abgeschaltet wurde. Ferner können Objekte Anforderungen für Dienste zu anderen Objekten ausgeben und überdies Dienste liefern.
Gemäß der Verwendung hierin bezieht sich der Ausdruck "Klasse" auf den Typ eines Objekts und spezifiziert, um welche Art von Objekt es sich handelt. Beispielsweise sind Garfield und Snoopy, obwohl es sich um unterschiedliche "Objekte" handelt, beide "Zeichentrickfiguren". "Zeichentrickfigur" ist die Klasse von jedem. Eine unterschiedliche Art einer Entität, sagen wird das World Trade Center, hätte eine, unterschiedliche Klasse (in diesem Fall vielleicht "Gebäude").
Gemäß der Verwendung hierin ist ein "Objektverwalter" eine Entität, die Gruppierungen von Objekten verwaltet, die die Existenz und den Betrieb jedes Objekts unterstützen.
Ferner ist der Ausdruck "Objektmodell", wie er hierin verwendet ist, eine Abstraktion der Aktivitäten, die eine spezielle Klasse eines Objektverwalters durchführt, sowie die Art und Weise, auf die derselbe dieselben durchführt. Diese Aktivitäten umfassen (i) die Verwaltung des dauerhaften Zustands von Objekten, (ii) die Abbildung von Operationen bezüglich Objekten in einen Code.
Gemäß dem vorhergehenden werden Verbesserungen bei der verteilten Berechnung benötigt.
Die vorliegende Erfindung liefert ein verteiltes Computer system, das die Probleme des Stands der Technik löst. Speziell liefert die vorliegende Erfindung ein Objektorientiertes verteiltes Computersystem, das, anders als andere verteilte Computersysteme, nicht erfordert, daß Clients von Diensten codiert sind, um die Standorte der Dienstanbieter zu kennen oder zu erfassen. Ferner erkennt dieses System, im Unterschied zu anderen Objektorientierten Computersystemen, Objekte, die mit verschiedenen Objektmodellen übereinstimmen.
Insbesondere liefert die vorliegende Erfindung eine Verwaltungsvorrichtung für ein Objekt-orientiertes verteiltes Computersystem. Die Verwaltungsvorrichtung verwendet einen Lokalisierungsdienst zum Lokalisieren gewünschter Objekte in einem System im Auftrag von anfordernden Objekten oder Prozessen (d. h. Anforderern (Requestern)). Ein Anforderer muß nicht codiert sein, um irgendeine Kenntnis von dem Lokalisierungsdienst zu besitzen (geschweige denn von Einzelheiten des Lokalisierungsdienstes).
Speziell wird der Lokalisierungsdienst automatisch kontaktiert, wenn ein Anforderer eine Anforderung zu einem einen Dienst liefernden Objekt, d. h. einem "Zielobjekt", durchführt. Das bevorzugte Ausführungsbeispiel verwendet eine Verarbeitungseinrichtung, um den Lokalisierungsdienst innerhalb automatisch erzeugter Kontrollabschnitte (Stubs) aufzurufen. Ferner lokalisiert der Lokalisierungsdienst Objekte basierend auf der Identität des Objekts, wobei jedes Objekt in dem System eine eindeutige Identität besitzt. Diese eindeutige Identität codiert eine Anzeige des Computers, auf dem das Objekt erzeugt wurde.
Der Lokalisierungsdienst umfaßt verschiedene Arten von Entitäten in dem System. Es existieren Objektverwalter, von denen jeder die Existenz und den Betrieb der Objekte, die demselben zugeordnet sind, unterstützt; Verwalter von Objektverwaltern, von denen jeder eine Gruppierung von Objektverwaltern verwaltet; Objektregion-Verwalter, von denen jeder den Standort von Objekten bezüglich der Computer in dem System verfolgt. Eine unterschiedliche Objektregion ist für jede verschiedene Gruppierung von Computern definiert, wobei jede Region ihren eigenen Objektregion-Verwalter aufweist. Um eine Abbildung zwischen Computern und Objektregion-Verwaltern zu liefern, verwendet der Lokalisierungsdienst eine Abbildungseinrichtung.
Gemäß einem Aspekt der vorliegenden Erfindung ist eine gemeinsame generische Schnittstelle verwendet, die eine gemeinsame Einrichtung zur Kommunikation mit und zwischen den Objektverwaltern, Verwaltern von Objektverwaltern, Objektregion-Verwaltern und der Abbildungseinrichtung ermöglicht.
Zusätzlich basieren die Objektverwalter auf jeweiligen Objektmodellen. Objekte, die einem Objektverwalter, der auf einem Objektmodell basiert, zugeordnet sind, sind in der Lage Anforderungen zu Objekten zu senden, die einem jeweiligen Objektverwalter zugeordnet sind, der auf einem unterschiedlichen Objektmodell basiert.
Ferner existiert bei einem Ausführungsbeispiel eine generische Schnittstelle, die durch Objektverwalter unterstützt wird, die durch einen gemeinsamen Verwalter von Objektverwaltern verwaltet werden, derart, daß der Verwalter von Objektverwaltern in der Lage ist, mit jedem seiner Objektverwalter auf eine Art und Weise, die frei von einer expliziten Kenntnis des jeweiligen Objektmodells des Objektverwalters ist, zu kommunizieren.
Vorzugsweise behandelt jeder Objektverwalter Gruppierungen von Objekten, die demselben zugeordnet sind, als jeweilige Äquivalenzklassen. Zu diesem Zweck verfolgt der Objektverwalter eine Objektprozeßzuordnung als eine Gruppe und nicht individuell. Ferner liefern die Objektverwalter vorzugsweise eine Deaktivierung von Prozessen als automatische Antwort auf das System, das Betriebsmittel benötigt.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung verwendet die Verwaltungsvorrichtung ferner eine Einrichtung zum Behandeln einer Anforderung nach einem Zielobjekt unabhängig von einer Zuordnung des Zielobjekts zu einem Prozeß zum Zeitpunkt der Anforderung. Zu diesem Zweck erscheinen alle Objekte in dem System für Verarbeitungsanforderungen verfügbar zu sein, selbst wenn ein gegebenes Zielobjekt zum Zeitpunkt der Anforderung einem Prozeß nicht zugeordnet sein kann.
Anders ausgedrückt liefert ein Objekt-orientiertes verteiltes Computersystem gemäß der vorliegenden Erfindung eine Computereinrichtung zum Implementieren von Operationen und Daten eines Zielobjekts, in einem Prozeß der mehreren Prozesse des Systems, ansprechend auf eine Anforderung zu dem Zielobjekt. Folglich ist die Verfügbarkeit jedes Objekts unabhängig von der Zuordnung des Objekts zu einem Prozeß zum Zeitpunkt der Anforderung definiert.
Die vorher genannten und weitere Aufgaben, Merkmale und Vorteile der Erfindung werden aus der folgenden spezielleren Beschreibung von bevorzugten Ausführungsbeispielen der Erfindung, wie sie in den beigefügten Zeichnungen gezeigt sind, in denen in allen Ansichten gleiche Bezugszeichen gleiche Teile bezeichnen, offensichtlich. Die Zeichnungen sind nicht notwendigerweise maßstabsgetreu, wobei stattdessen das Hauptaugenmerk auf der Veranschaulichung der Grundsätze der Erfindung liegt.
Fig. 1 ist ein schematisches Diagramm eines Objektorientierten verteilten Computersystems, das die vorliegende Erfindung verkörpert.
Fig. 2 ist ein Blockdiagramm einer Objekt/Prozeß-Verwaltungsvorrichtung der vorliegenden Erfindung, die in dem System von Fig. 1 verwendet ist.
Fig. 3a und 3b zeigen eine Objektaktivierung bei der vor liegenden Erfindung.
In den Fig. 1 und 2 ist ein Objekt-orientiertes verteiltes Computersystem 11 dargestellt, das die vorliegende Erfindung verkörpert. Das System 11 umfaßt eine Mehrzahl von lose gekoppelten Computern 37, die ein Netzwerk bilden. Auf jedem Computer 37 kann oder können ein oder mehrere Prozesse 39 existieren, in denen verschiedene Objekte 13 jeweilige Operationen durchführen. Die Objekte 13 in Fig. 1 befinden sich in dem gleichen oder in unterschiedlichen Prozessen 39 auf dem gleichen oder unterschiedlichen Computern 37 des Netzwerks, das das Objekt-orientierte verteilte Computersystem 11 definiert.
Im Herz des Systems 11 befindet sich eine Objekt/Prozeß-Verwaltungsvorrichtung 15 gemäß der vorliegenden Erfindung. Zusammenfassend handhabt die Vorrichtung 15 die folgenden Objektverhalten:
(1) registriert alle existierenden Objekte 13 in dem System 11;
(2) ermöglicht, daß Objekte 13a Anforderungen zu anderen Objekten 13b ausgeben (dieselben befinden sich möglicherweise in unterschiedlichen Adreßräumen und/oder Computern); und
(3) liefert die Anforderungen und verwaltet deren Ausführung.
Die Vorrichtung 15 erfordert nicht, daß Objekte 13 kompiliert oder miteinander verknüpft werden, bevor man eine Anforderung zu dem anderen ausgeben kann. Ein Objekt 13 kann eine Anforderung zu jedem anderen Objekt 13 in dem System ausgeben, vorausgesetzt, dasselbe besitzt einen Bezug zu diesem Objekt.
Ferner unterstützt die erfindungsgemäße Vorrichtung 15 die Verteilung von Objekten 13 unter Prozessen in dem System 11. Ein Objekt oder ein Prozeß kann Anforderungen zu Objekten auf anderen Computern in dem Netzwerk ausgeben. Das Objekt oder der Prozeß (d. h. der Anforderer oder Client), der die Anforderung ausgibt, muß keine Kenntnis davon besitzen, auf welchem Computer das Zielobjekt zu finden ist, oder sogar, ob sich das Zielobjekt auf einem unterschiedlichen Computer befindet. Die erfindungsgemäße Vorrichtung 15 bestimmt den Standort des Zielobjekts auf eine automatische Art und Weise im Auftrag eines Clients ohne eine explizite menschliche Codierung von Clientaufrufen zu einem Lokalisierungsdienst (was nachfolgend erläutert wird). Unterschiedliche Arten von Netzwerken können unterstützt werden, einschließlich Funknetzwerke, beispielsweise viele lokale Netze (LANs; LAN = Local Area Network), und verbindungsorientierte Netzwerke, beispielsweise viele Großbereichsnetzwerke (WANs; WAN = Wide Area Network).
Zusätzlich unterstützt die Vorrichtung 15 eine Heterogenität. Unterschiedliche Computertypen können in dem Netzwerk gemischt sein. Die erfindungsgemäße Vorrichtung 15 verwaltet beliebige Unterschiede zwischen den Computern, die das Objekt, das die Anforderung ausgibt (den Sender), und das Objekt, das die Anforderung ausführt (den Empfänger), enthalten. Ein gemeinsames Problem tritt auf, wenn zwei Computer unterschiedliche Prozessoren besitzen, die Daten unterschiedlich darstellen. Beispielsweise speichern Prozessoren der Serie Motorola 68xxx und Prozessoren der Serie Intel 80xxx ganze Zahlen unterschiedlich in einem Speicher. Die erfindungsgemäße Vorrichtung 15 verwaltet, wenn notwendig, die Übersetzung der Parameter der Anforderungen zwischen den Formaten der zwei Computer.
Die erfindungsgemäße Vorrichtung 15 unterstützt ferner mehrere Benutzersitzungen gleichzeitig. Die Vorrichtung 11 kann Objekte auf einem Einzelbenutzercomputer, beispielsweise einem Personalcomputer oder einer Einzelbenutzer-Workstation, verwalten. In gleicher Weise kann die Vorrichtung 15 Objekte auf einem Viel-Benutzer-Computer verwalten. Objekte, die durch die Vorrichtung 15 verwaltet werden, können gleichzeitig Dienste im Auftrag mehrerer unterschiedlicher Benutzer durchführen. Die Vorrichtung 15 enthält einen Sicherheitsmechanismus, um vor einer nicht-autorisierten Verwendung von Diensten zu schützen.
Ferner ist die Vorrichtung 15 skalierbar. Bei dem Netzwerk von Computern läuft eine Implementierung der erfindungsgemäßen Vorrichtung 15 auf jedem Computer. Im einfachsten Fall kann die Vorrichtung 15 effizient auf einem alleinstehenden Einzelbenutzercomputer wirksam sein. Im entgegengesetzten Fall kann die Vorrichtung 15 effizient auf jeder Maschine in einem gesamten Netzwerk wirksam sein, das alle Computer eines großen multinationalen Unternehmens umfaßt.
Um das vorhergehende zu erreichen, besitzt die erfindungsgemäße Vorrichtung 15 eine Zweischichtstruktur. Die untere Schicht ist aus Kommunikationsdiensten 19 gebildet, die einen einheitlichen Mechanismus zum Ausgeben und Liefern von Anforderungen zwischen Objekten 13 liefern. Die Kommunikationsdienstschicht 19 ermöglicht, daß Anforderungen zwischen Objekten geliefert werden, indem, neben anderen Operationen, Datendarstellungen umgewandelt werden, wenn sich das Anfordererobjekt und das Zielobjekt auf unterschiedlichen Arten von Computern befinden. Überdies sind Sicherheitsmechanismen vorgesehen, um einen nicht-autorisierten Zugriff auf Objekte zu verhindern. Die Kommunikationsdienste 19 isolieren ferner den Rest der Verwaltungsvorrichtung 15 und die Objekte 13 vor den Einflüssen unterschiedlicher Netzwerktopologien, unterschiedlicher Protokolle und unterschiedlicher Software.
Eine obere Schicht der Verwaltungsvorrichtung 15 ist aus Objektverwaltungsdiensten 17 gebildet, die Objektverwalter 23, 25 und einen Lokalisierungsdienst 21 umfassen. Die Objektverwalter 23, 25 liefern Dienste, beispielsweise eine Objekt-Aktivierung und -Deaktivierung und eine Objektklassen installation. Der Lokalisierungsdienst 21 ermöglicht, daß die Vorrichtung einen Kommunikationsweg zu einem speziellen Objekt 13 bestimmt. Folglich verwaltet die Objektverwaltungsdienst-Schicht 17 den Lebenszyklus (Erzeugung, Erhaltung und Löschung) und den Standort eines Objekts.
Bei dem bevorzugten Ausführungsbeispiel sind die Kommunikationsdienste 19 und die Objektverwaltungsdienste 17 durch eine Laufzeitbibliothek 27, Objektverwalter 23, Verwalter von Objektverwaltern 29 und einen Lokalisierungsdienst 21, die in Fig. 2 gezeigt sind, implementiert. Die Laufzeitbibliothek 27 befindet sich in den Adreßräumen der Objekte 13, die durch das Computersystem 11 verwaltet werden, und kann als Teil aller dieser Objekte betrachtet werden. Die Laufzeitbibliothek 27 liefert eine elementare Schnittstelle, die bei der Kommunikation in dem System 11 durch alle Objekte 13 verwendet wird. Vorzugsweise enthält die Laufzeitbibliothek 27 einen Code, der eine Kommunikation mit dem dauerhaften Speicherverwalter (der nachfolgend beschrieben wird) ermöglicht, und einen Code, der die Erzeugung von Objektbezügen, die durch die Lokalisierungsdienste 21 verwendet werden, ermöglicht.
Die Objektverwalter 23 sind für die direkte Verwaltung der Objekte 13, die Aktivierung und Deaktivierung der Objekte, das Liefern von Meldungen zu Objekten und das Verfolgen dessen, welcher Zustand auch immer für diese Aktivitäten benötigt wird, verantwortlich. Zu diesem Zweck ist jedes Objekt 13 einem Objektverwalter 23 zugeordnet, derart, daß unterschiedliche Mehrzahlen von Objekten durch unterschiedliche Objektverwalter verwaltet werden. Die vorliegende Erfindung liefert zumindest einen Standardobjektverwalter 25 in der Verwaltungsvorrichtung 15. Ein minimaler Teilsatz der Operationsschnittstellen des Standardobjektverwalters 25 definiert die Dienste, die durch alle anderen Objektverwalter 23 geliefert werden müssen. Folgend diesen Schnittstellen und einer gemeinsamen generischen Schnittstelle, die durch den Objektverwalter-Verwalter (der nachfolgend erläutert wird) verwendet wird, ist es möglich, daß neue Objektverwalter nachfolgend hinzugefügt werden.
Jeder Objektverwalter 23 ist einem Objektverwalter-Verwalter (MOM; MOM = Manager of Object Managers) 29 zugeordnet. Ferner ist einem solchen MOM 29 ein Standardobjektverwalter 25 (default object manager) zugeordnet. Jeder Objektverwalter- Verwalter (MOM) 29 ist für das Empfangen von Meldungen, die für Objekte 13 bestimmt sind, die den Objektverwaltern 23 zugeordnet sind, die derselbe (der MOM) verwaltet, verantwortlich. Jeder MOM 29 ist ferner für das Finden des Objektverwalters 23, dem ein gegebenes Objekt zugeordnet ist, verantwortlich, weshalb der MOM 29 als die lokale Dokumentationsstelle für Anforderungen dient. Anders ausgedrückt ist der MOM 29 als ein gut bekannter Empfangspunkt für Anforderungen, die für ein beliebiges der Objekte, die durch einen beliebigen der Objektverwalter 23 verwaltet werden, welche wiederum durch den Objektverwalter-Verwalter (MOM) 29 verwaltet werden (demselben zugeordnet sind), hereinkommen.
Die Lokalisierungsdienste 21 sind für das Finden des gegenwärtigen Standorts eines beliebigen Objekts 13 in dem System 11 verantwortlich. Diese Dienste 21 werden auf eine automatische Art und Weise durch das System 11 verwendet und sind für Programmierer, die Anwendungen in dem System 11 schreiben, und für Benutzer, die Objekte 13 in dem System 11 verwenden, vollständig verborgen. Insbesondere liefert die vorliegende Erfindung eine Verarbeitungseinrichtung zum automatischen Aufrufen der Lokalisierungsdienste im Auftrag des anfordernden Objekts (oder Prozesses), ansprechend auf eine Anforderung für ein Zielobjekt. Folglich müssen die anfordernden Objekte (oder Prozesse) nicht explizit codiert sein, um die Lokalisierungsdienste 21 aufzurufen, wie es gemäß dem Stand der Technik erforderlich ist.
Die Laufzeitbibliothek und der Objektverwalter-Verwalter (MOM) 29 sind sowohl in der Kommunikationsdienstschicht 19 der Verwaltungsvorrichtung 15 als auch den Objektverwal tungsschichten wirksam. In der Kommunikationsdienstschicht 19 handhabt die Laufzeitbibliothek 27 das Leiten von Meldungen von einem Objekt 13 zu einem anderen, wobei der Objektverwalter-Verwalter (MOM) 29 als der Objektlokalisierungsdienst unterster Ebene wirksam ist. In der Objektverwaltungsdienstschicht 17 handhabt die Laufzeitbibliothek 27 zusammen mit dem Satz von Objektverwaltern 23 primär den Objekt-Lebenszyklus.
Eine Kommunikation aus der Sicht der Objekte 13 findet durch die Laufzeitkomponente der Schichten 17, 19 statt. Die Laufzeitbibliothek 27 kontaktiert die Lokalisierungsdienste 21, um ein Zielobjekt 13b zu finden, und sendet Meldungen von dem Objekt 13 zu einem Objekt 13b, wie als nächstes erläutert wird. Es sei bemerkt, daß die Lokalisierungsdienste 21 auf einem bestimmten Computer oder Computern in dem Gesamtsystem 11 ablaufen. Aus der Sicht des Objekts 13 befinden sich diese Dienste 21 jedoch nicht auf irgendeinem speziellen Computer 37. Daher zeigen die Fig. 1 und 2 diese Dienste 21 als existierend, jedoch nicht auf einer speziellen Maschine 37 befindlich.
Bezugnehmend auf Fig. 2 verwenden die Lokalisierungsdienste 21 eine Hierarchie von Elementen. Wie vorher erwähnt wurde, sind Objekte 13 in einem Prozeß oder Prozessen 39 eines Computers oder unterschiedlicher Computer 37 wirksam. Eine Mehrzahl oder eine Gruppe von Objekten 13 ist einem Objektverwalter 23 zugeordnet, der für die Verwaltung dieser Objekte 13 verantwortlich ist. Die Objektverwalter 23 sind wiederum gruppiert und einem Objektverwalter-Verwalter (MOM) 29 zugeordnet. Jeder Objektverwalter 23 basiert auf einem jeweiligen Objektmodell, wobei in dem System 11 eine beliebige Anzahl von Objektmodellen existiert. Die Objektverwalter 23 unterschiedlicher Objektmodelle sind in der Lage, über eine generische Schnittstelle, die später erläutert wird, durch einen gemeinsamen MOM 29 gehandhabt zu werden. Zusätzlich sind Objekte, die einem Objektverwalter 23 zugeordnet sind, der auf einem Objektmodell basiert, in der La ge, Anforderungen zu Objekten zu senden, die einem jeweiligen Objektverwalter zugeordnet sind, der auf einem unterschiedlichen Objektmodell basiert, wie detailliert nachfolgend erläutert wird.
Ferner ist jeder MOM 29 einem Objektregion-Verwalter 31 wie folgt zugeordnet. Unterschiedliche Objektregionen sind durch Sätze von Computern 37, die zu administrativen Zwecken zusammengruppiert sind, definiert. Für jede Objektregion existiert ein Objektregion-Verwalter 31 (ORE). Die Rolle des Objektregion-Verwalters 31 besteht darin, Objektbezüge auf einen (möglicherweise leeren) Satz des Objektverwalter-Verwalters (MOM) 29 abzubilden, der Kenntnis von Zielobjekten 13b besitzen könnte. Ein Objektregion-Verwalter 31 umfaßt eine einzelne Datenbank und einen Satz von Prozessen, die eine Abfrage der Datenbank und eine Manipulation derselben ermöglichen. Vorzugsweise ist ein logisch einzelner Objektregion-Verwalter 31 zu Zwecken einer hohen Verfügbarkeit in der Region vervielfältigt. Jede Region besitzt ihren eigenen unterschiedlichen Objektregion-Verwalter 31.
In der nächsten Hierarchieebene von Elementen in den Lokalisierungsdiensten 21 befinden sich Meta-Objektregion-Verwalter 33 (MORE). Diese Verwalter bilden Objektbezüge auf die Identifizierer des geeigneten Objektregion-Verwalters 31, der etwas über dieses Objekt weiß, ab. Verschiedene Meta-Objektregion-Verwalter 33 kommunizieren miteinander, um eine Lokalisierung von Objekten 13 zwischen Objektregionen zu ermöglichen. Wie die Objektregion-Verwalter 31 umfaßt jeder Meta-Objektregion-Verwalter 33 eine einzelne Datenbank und einen Satz von Prozessen, die diese Datenbank abfragen und manipulieren. Jeder logisch einzelne Meta-Objektregion-Verwalter 33 kann vervielfältigt sein. Jedes System besitzt seinen eigenen unterschiedlichen Meta-Objektregion-Verwalter 33.
Auf der Abschlußebene der Hierarchie befinden sich Geschwister-Meta-Objektregion-Verwalter 35 (SMORE), die eine Liste von zwei oder mehr unterschiedlichen Meta-Objektregion-Verwaltern 33 halten.
Bei dem bevorzugten Ausführungsbeispiel existiert eine gemeinsame generische Schnittstelle zwischen den unterschiedlichen Entitäten der vorher genannten Hierarchie. Die gemeinsame generische Schnittstelle ermöglicht eine gemeinsame Einrichtung zur Kommunikation zwischen und unter Objektverwaltern 23, MOMS 29, Objektregion-Verwaltern 31 und Abbildungsverwaltern 33.
Eine Wechselwirkung unter Objekten 13 findet durch Anforderungen statt, die von einem Anforderer (d. h. Objekt oder Prozeß) zu einem Zielobjekt gesendet werden, die nach einer bestimmten Operation bezüglich des Zielobjekts fragen. Operationsaufrufe sind die elementare Kommunikationsform zwischen Objekten 13, die sich in dem Rahmenwerk befinden, das durch die Verwaltungsvorrichtung 15 der vorliegenden Erfindung definiert ist. Grundsätzlich ist eine Operation eine Möglichkeit, Anforderungen dahingehend durchzuführen, daß ein Zielobjekt bestimmte Informationen liefert, eine bestimmte Manipulation seines eigenen Zustands durchführt und/oder Operationen bezüglich anderer Objekte durchführt. Eine Operation ist durch seine Aufrufsignatur definiert. Die Signatur besteht aus einem Rückgabetyp (möglicherweise Null), einer Liste von Parameterspezifikationen und Informationen dahingehend, ob die Operation synchron (voreingestellt) oder asynchron ist.
Die Verwaltungsvorrichtung 15 der vorliegenden Erfindung definiert ihre Operationsaufrufe zu Objekten derart, daß alle die folgende syntaktische Form aufweisen:
return_type
Operation_Name(
objref_t target_object,
type Param1,
...,
type ParamN
);
Eine verdeckte Abwicklung, die als objref_t bezeichnet wird, wird verwendet, um das Objekt, zu dem die Anforderung gesendet werden soll (d. h. das Zielobjekt), zu identifizieren. Bei dem bevorzugten Ausführungsbeispiel ist objref_t ein Zeiger auf eine System-definierte Struktur, die implementierungsabhängig ist. Die interne Struktur solcher Abwicklungen ist für Benutzer des Systems 11 nicht sichtbar oder verfügbar. Benutzer des Systems 11 erzeugen oder löschen objref_t-Abwicklungen durch Aufrufe in die Laufzeitbibliothek 27.
Bestimme Parameter werden konzeptmäßig durch Bezugnahme übertragen; das heißt, daß dieselben den Status von Ausgabe- oder Eingabe-Ausgabe-Parametern besitzen. Der erste Parameter für alle Operationen besteht in System-definierten Objekt-Bezugnahmen auf das Zielobjekt, das die Anforderung empfangen soll. Wenn das Verfahren, das durch den Aufruf aufgerufen wird, einen einfachen Wert zurückgibt, wird dieser Wert als der Rückgabewert für die Operation zurückgegeben. Wenn das Verfahren mehrere Werte zurückgibt, werden diese Werte in den Parametern zu der Operation zurückgegeben, die zum Zurückgeben von Werten in der Lage sind. Ferner sind alle Operationen der Verwaltungsvorrichtung 15 definiert, um einen Statuswert zurückzugeben, der verwendet werden kann, um zu bestimmen, ob die Operation erfolgreich war. Wenn die Operation fehlschlägt, zeigt der Statuswert die Beschaffenheit des Fehlschlags an.
Eine Schnittstelle ist ein nicht-leerer Satz von Operationen, die logisch in Beziehung stehen und eine semantische Einheit bilden. Die Verwaltungsvorrichtung 15 macht die folgende Anforderung bezüglich Schnittstellen: wenn eine Objektklasse irgendeine Operation in einer Schnittstelle unterstützt, muß dieselbe alle der Mitglieder des Satzes von Operationen, die diese Schnittstelle bilden, unterstützen.
Ferner wird jede Schnittstelle durch einen Schnittstellenidentifizierer identifiziert, der durch den Implementierer, der die Schnittstelle ursprünglich entworfen hat, zugewiesen wird.
Ein Verfahren ist der Code, der eine Operation implementiert. Für eine gegebene Operation kann dieser Code aufgrund von Unterschieden der Computerarchitektur oder aus anderen Gründen von einem Objekt 13 zu einem anderen variieren. Eine Operation wird verwendet, um die Aktion zu spezifizieren, die auf einem Objekt 13 durchgeführt werden muß. Eine Anforderung, die von einem Objekt 13 gemacht wird, wird auf ein Verfahren auf diesem Objekt 13 abgebildet. Diese Abbildung ordnet eine spezielle Implementierung der Operation zu, die in einer Schnittstelle definiert ist, die durch das Objekt 13 unterstützt wird. Es steht in der Verantwortung des Klassenimplementierers, sicherzustellen, daß das Verfahren, das der Operationsanforderung zugeordnet ist, die geeigneten Aktionen durchführt, um der Anforderung die bestimmungsgemäßen Semantiken zu geben.
Entsprechend dem vorher genannten tritt ansprechend auf einen Objektoperationsaufruf von einem Anforderer der MOM des Objektverwalters des Zielobjekts mit dem Objektverwalterin Wechselwirkung, um die Anforderung zu dem Zielobjekt 13b weiterzuleiten. Der Objektverwalter 23, der dem Zielobjekt 13b, das den Operationsaufruf empfängt, zugeordnet ist, stellt ferner sicher, daß das Zielobjekt 13b in der Lage ist, die Anforderung zu empfangen.
Die Objektverwalter-Verwalter (MOMs) 29 sind entworfen, um die Hinzufügung mehrerer Objektverwalter 23 während der Lebenszeit des Computersystems 11 zu ermöglichen. Dies wird durch eine gemeinsame generische Schnittstelle erreicht, die durch die Objektverwalter 23, die durch einen gemeinsamen MOM 29 verwaltet werden, unterstützt wird, derart, daß der MOM 29 in der Lage ist, ohne explizite Kenntnis des Objektmodells, auf dem der Objektverwalter basiert, mit allen Ob jektverwaltern 23 zu kommunizieren. Die genaue Art und Weise, auf die der MOM 29 und ein spezieller Objektverwalter 23 kommunizieren, ist für jede spezielle Implementierung des Objektverwalter-Verwalters 29 die gleiche, kann jedoch von Implementierung zu Implementierung variieren.
Die Trennung der Objektverwalter-Verwalter (MOMs) 29 und der einzelnen Objektverwalter 23 ermöglicht, daß Objekte mit sehr unterschiedlichen Attributen nebeneinander in dem Computersystem 11 existieren, ohne die Fähigkeit dieser Objekte 13, zusammenzuarbeiten, zu begrenzen. Die Trennung ermöglicht ferner, daß die MOMs 29 die Kommunikationsdienste, die in dem gesamten System 11 verwendet werden, kennen, während die einzelnen Objektverwalter 23 die Einzelheiten der Objekte 13 kennen, die denselben zugeordnet sind.
Überdies ermöglicht dieses Aufsplitten von Wissen, daß die MOMs 29 Anforderungen für jeden Objekttyp 13 empfangen. Ansprechend auf den Empfang einer Anforderung bestimmt der MOM 29, ob das Zielobjekt 13b der Anforderung ein solches ist, das durch einen der Objektverwalter 23, die diesem MOM 29 zugeordnet sind, verwaltet wird. Wiederum stellen die einzelnen Objektverwalter 23 des Zielobjekts 13b sicher, daß das Zielobjekt 13b bereit ist, die Anforderung zu empfangen. Der Objektverwalter ist in der Lage, dies zu erreichen, indem derselbe spezielle Kenntnis bezüglich des Zielobjekts 13b, das verwaltet wird, besitzt oder erfaßt. In einem Fall macht es das Sicherstellen, daß ein Zielobjekt 13b bereit ist, eine Anforderung zu empfangen, erforderlich, daß der zugeordnete Objektverwalter 23 das Zielobjekt 13b aktiviert. Dies erfordert wiederum, daß der zugeordnete Objektverwalter 23 das Ausführungsmodell und das dauerhafte Speicherschema, das durch das Zielobjekt verwendet wird, kennt.
Der Nettoeffekt der vorher genannten Trennung der Verantwortlichkeit zwischen den Objektverwalter-Verwaltern (MOMs) 29 und den einzelnen Objektverwaltern 23 kann wie folgt neu formuliert werden. Der MOM 29 wirkt sowohl als gut bekannter Empfangspunkt und als ein Weiterleitungsmittel für Anforderungen, während die Objektverwalter, die dem MOM 29 zugeordnet sind, als die Objektmodell-spezifischen Aktivierungsmittel und Manipulierungsmittel der Objekte 13b wirksam sind.
Um in dem verteilten Computersystem, das durch die Verwaltungsvorrichtung 15 definiert ist, wirksam zu sein, unterstützen Objekte 13 bestimmte Operationen. Bei dem bevorzugten Ausführungsbeispiel unterstützen alle Objekte 13 die folgenden Funktionen.
acl_t
get_acl(
objref_t object,
status_t *status
);
Die Funktion get_acl gibt eine Zugriffssteuerliste, die dem Objekt zugeordnet ist, das durch den Parameter "objekt" bezeichnet ist, zurück.
boolean
set_acl(
objref_t object,
acl_t to_acl,
status_t *status
);
Die Funktion set_acl_id ordnet die Zugriffssteuerliste, die mit to_acl bezeichnet ist, dem Objekt zu, das durch den Parameter "objekt" bezeichnet ist. Die Funktion gibt den Wert "wahr" zurück, wenn die Einstellung erfolgreich ist, und sonst "falsch". Es sei bemerkt, daß die Zugriffssteuerliste, die gegenwärtig dem Parameter "objekt" zugeordnet ist, dem Sender der Anforderung das Recht geben muß, die Zugriffssteuerliste einzustellen, damit die Operation erfolgreich ist.
boolean
set_class_id(
objref_t object,
classid_t to_class,
status_t *status
);
Die Funktion set_class_id ändert den Klassenidentifizierer, der dem Objekt zugeordnet ist, das durch den Parameter "objekt" bezeichnet ist, auf den Wert, der in to_class spezifiziert ist. Die Funktion gibt den Wert "wahr" zurück, wenn die Einstellung erfolgreich war; andernfalls gibt die Funktion einen Wert "falsch" zurück.
boolean
ing_colocation(
objref_t of_object,
objref_t with_object,
Status_t *status
);
Die Funktion ing_colocation fragt bezüglich des Objekts, das mit of_object bezeichnet ist, ob dasselbe gemeinsam mit dem Objekt, das durch with_object bezeichnet ist, angeordnet ist. Die Funktion gibt "wahr" zurück, wenn die Objekte zusammen angeordnet sind; wobei die Funktion andernfalls "falsch" zurückgibt. Es sei bemerkt, daß die Semantik der gemeinsamen Anordnung von dem dauerhaften Speichermechanismus und/oder dem Objektverwalter, der den Objekten zugeordnet ist, abhängt.
Während der Lauf Zeit werden Aufrufe oder Operationsanforderungen wie folgt verarbeitet. Die Laufzeitbibliothek 27 ist mit allen Objekten 13 verbunden. Dieselbe dient sowohl als Ausgangspunkt für das Senden von Anforderungen als auch als endgültige Bestimmung für das Empfangen von Anforderungen. Als ein Teil dieser Funktion liefert die Laufzeitbibliothek 27 eine Schnittstelle, um Objektbezugnahmen aufzubauen, die elementare Entitäten in den Lokalisierungsdiensten 21 sind. Die Laufzeitbibliothek 27 liefert ferner eine Schnittstelle zu dem Dauerhaft-Speicher-Verwalter (Persistent Storage Manager), was ermöglicht, daß Objekte ihren dauerhaften Zustand mit der Hilfe des Standardobjektverwalters 25 verwalten, wie später erläutert wird.
Das Senden und Empfangen von Anforderungen ist für den Benutzer des Systems 11 und den Schreiber von Objekten 13, oder genauer von Klassen von Objekten, transparent. Die Anforderungsübertragung ist durch die interne Laufzeitfunktionalität und durch die Kontrollabschnitte (d. h. Schnittstellencodefragmente), die durch einen Schnittstellenkompiler erzeugt werden, wenn derselbe die Operationsschnittstellen der Klasse verarbeitet, definiert. Jedoch sind drei Funktionen aus der Laufzeitbibliothek 27 exportiert. Die erste Funktion ermöglicht den Vergleich von zwei Objekt-Bezugnahme-Abwicklungen, um zu bestimmen, ob sich dieselben auf das gleiche Objekt beziehen. Die zweite Funktion ermöglicht die Erzeugung einer Objektbezugnahme auf ein Klassenobjekt. Die dritte Funktion ermöglicht den Abbau einer Objekt-Bezugnahme-Abwicklung.
Die erste exportierte Laufzeitfunktion lautet bei dem bevorzugten Ausführungsbeispiel wie folgt:
boolean
omf_objref_equal(
objref_t ref1,
objref_t ref2,
status_t *status
);
Die Funktion omf_objref_equal gibt den Wert "wahr" zurück, wenn die Objekt-Bezugnahme-Abwicklungen von ref1 und ref2 sich jeweils auf das gleiche Objekt beziehen; andernfalls gibt die Funktion den Wert "falsch" zurück.
Die zweite exportierte Laufzeitfunktion lautet bei dem bevorzugten Ausführungsbeispiel wie folgt:
objref_t
omf_dup_objref(
objref_t to_dup,
status_t *status
);
Der Aufruf omf_dup_ objref erzeugt ein Doppel der Objekt-Bezugnahme, die durch den Parameter to_dup geliefert wird. Die resultierende Objekt-Bezugnahme kann zu weiteren Objekten gegeben werden.
Die dritte exportierte Laufzeitfunktion lautet bei dem bevorzugten Ausführungsbeispiel:
void
omf_free_objref(
objref_t to_free,
status_t *status
);
Die Funktion omf_free_objref löscht eine Objekt-Bezugnahme- Abwicklung aus dem Speicher.
Andere Funktionen, die in der Laufzeitschnittstelle verwendet werden, lauten wie folgt:
objref_t
omf_create(
classid_t obj_class,
objref_t group_with,
tid_t in_trans,
status_t *status
);
Die Funktion omf-create informiert den Objektverwalter, daß ein Objekt existiert. Ansprechend darauf gibt der Objektverwalter eine Objekt-Bezugnahme auf das neue Objekt zurück, die dann durch dieses Objekt verwendet werden kann, um sich selbst für andere Objekte zu identifizieren. Der Aufruf spezifiziert die Klasse des neuen Objekts in obj_class. Ferner ermöglicht der Parameter group_with, daß das erzeugte Objekt als in der gleichen Gruppe wie das Objekt, das durch diesen Parameter bezeichnet wird, befindlich registriert wird. Wenn zwei Objekte in der gleichen Gruppe sind, kann der Objektverwalter annehmen, daß die Objekte einander vertrauen, und kann bestimmte Annahmen treffen, die eine Optimierung ermöglichen. Beispielsweise könnten bei einer Implementierung, die aktive Objekte Prozessen zuweist, Objekte, die in der gleichen Gruppe sind, in dem gleichen Prozeß plaziert werden. Zu diesem Zweck behandelt der Objektverwalter 23 Gruppen der Objekte, die demselben zugeordnet sind, als jeweilige Äquivalenzklassen. Wiederum verfolgt der Objektverwalter 23 effektiv nur den Zustand der Gruppen von Objekten, die demselben zugeordnet sind, und nicht den Zustand von einzelnen Objekten 13 in einer Gruppe.
boolean
omf_delete(
objref_t to_delete,
tid_t trans_id,
status_t *status
);
Die Funktion omf_delete informiert den Objektverwalter, der einem Objekt zugeordnet ist, daß das Objekt, das durch to_delete bezeichnet ist, gelöscht wird. Das effektive Ergebnis des Aufrufs ist die Beseitigung der gesamten Aufzeichnung des Objekts mit dem Objektverwalter. Es sei bemerkt, daß dieser Aufruf den dauerhaften Speicher, der dem Objekt zugeordnet ist, nicht löscht. Die Funktion gibt einen Wert "wahr" zurück, wenn sie erfolgreich ist; andernfalls gibt dieselbe einen Wert "falsch" zurück.
boolean
omf_change_identity(
objref_t object,
tid_t trans_id,
objref_t new_id,
status_t *status
);
Die Funktion omf_change_identity ändert die zugrundeliegende Identität des Objekts, das durch den Parameter "objekt" bezeichnet ist, in die, die durch new_id geliefert wird. Dieser Aufruf wird grundsätzlich nur verwendet, wenn das Objekt, das vorher durch new_id bezeichnet wird, wenn dies existiert, gelöscht wurde oder zu löschen ist. Die Funktion gibt einen Wert "wahr" zurück, wenn sie erfolgreich ist; andernfalls gibt dieselbe einen Wert "falsch" zurück.
Der Dauerhaft-Speicher-Verwalter (PSM; PSM = Persistent Storage Manager) ermöglicht, daß Objekte ihren dauerhaften Zustand verwalten. Der PSM ist dem Standardobjektverwalter zugeordnet, wobei durch die Laufzeitschnittstelle auf denselben zugegriffen wird, die auf alle Objekte 13 in dem System 11 zugreifen kann. Der Satz von Aufrufen, der der PSM- Schnittstelle zugeordnet ist, ermöglicht, daß ein Objekt 13 Objekte des Typs "Zeiger-Auf-Datei" (gemäß der Definition in dem POSIX-Standard) aus der Objektidentität des Objekts erhält. Das Objekt 13 kann dann auf eine beliebige Art und Weise, die dasselbe bevorzugt, seinen dauerhaften Zustand unter Verwendung der bezeichneten Datei lesen oder schreiben.
Es sei bemerkt, daß es nicht erforderlich ist, daß ein Objekt 13, das durch den Standardobjektverwalter 25 verwaltet wird, den PSM verwendet, um seinen dauerhaften Zustand zu speichern. Jedoch muß ein Objekt, das sich entscheidet, den PSM nicht zu verwenden, alle Manipulationen des dauerhaften Zustands des Objekts 13 ohne die Hilfe des Standardobjektverwalters 25 durchführen.
Die Schnittstelle zu dem PSM besteht aus den folgenden Aufrufen. Diese Aufrufe werden nicht zu einem Objekt 13 geleitet, sondern sind lokale Aufrufe, die in der Systemlaufzeit implementiert sind, auf die alle Objekte 13 zugreifen können, und die in dem gleichen Prozeßraum 39 wie das aufrufende Objekt 13 ausgeführt werden. Diese Funktionen können am besten als eine Bibliothek angesehen werden, die den Kleber liefert, der ein Objekt 13 und den Objektverwalter 25 dieses Objekts zusammenhält.
FILE*
psm_create(
objref_t location,
tid_t trans_id,
objref_t *obj_created,
objref_t group_with,
classid_t obj_class_id,
acl_t init_acl,
mode_t cr_mode,
status_t *status
);
Die Funktion psm_create erzeugt eine Datei an dem gleichen Ort wie das Objekt, das durch den Parameter "location" bezeichnet wird. Die Objektidentität des erzeugten Objekts wird in dem Parameter obj_created zurückgegeben. Bei dem bevorzugten Ausführungsbeispiel codiert die Objektidentität eine Anzeige des Computers 37, auf dem das Objekt erzeugt wurde. Ein Zeiger auf die Datei, die als Teil der Operation erzeugt wurde, wird als der Zurückgabewert der Funktion zurückgegeben. Das Objekt und die zurückgegebene Datei besitzen beide die anfängliche Zugriffssteuerliste (ACL; ACL = Access Control List), die in init_acl geliefert wird, wobei die Datei in dem Modus erzeugt wird, der durch cr_mode angezeigt ist. Das Objekt wird mit dem Objektverwalter als von dem Typ, der durch obj_class_id angezeigt wird, seiend registriert.
Es ist wichtig zu realisieren, daß psm_create kein Objekt erzeugt, sondern lediglich eine dauerhafte Speicherung und eine Anfangsobjekt-Bezugnahme liefert und die Existenz des Objekts mit einem Objektverwalter registriert. Eine vollständige Objekterzeugung kann weitere Aktivitäten erfordern, beispielsweise die Initialisierung des Objektzustands. Dies wird durch den Code, der das Objekt tatsächlich erzeugt, berücksichtigt. Der psm_create-Aufruf wird durch diesen Code durchgeführt, um das System von der Existenz des neuen Objekts zu informieren.
FILE*
psm_open(
objref_t object,
tid_t trans_id,
mode_t open_mode,
status_t *status
);
Die Funktion psm_open gibt einen Zeiger auf die Datei zurück, die dem Objekt zugeordnet ist, das durch die Objektidentität in dem Parameter "objekt" identifiziert ist, geöffnet mit dem Modus, der durch den Parameter open_mode spezifiziert ist. Die Datei muß mit einem Aufruf von psm_create erzeugt worden sein.
boolean
psm_delete(
objref_t object,
tid_t trans_id,
status_t *status
);
Die Funktion psm_delete wird die Datei löschen, die dem Objekt zugeordnet ist, das durch die Objektidentität identifiziert ist, die in dem Parameter "objekt" übertragen wird, und wird ferner jedwede Bezugnahme auf das Objekt in dem Ob jektverwalter beseitigen. Die Funktion gibt "wahr" zurück, wenn das Löschen erfolgreich ist, und gibt andernfalls einen Wert "falsch" zurück.
objref_t
psm_create_link(
objref_t to_object,
tid_t in_trans,
oid_t class_id,
acl_t mit_acl,
status_t *status
);
Die Funktion psm_create link erzeugt ein Objekt, das permanent dem Objekt zugeordnet ist, das durch den Parameter to_object bezeichnet wird. Das erzeugte Objekt wird die Klasse besitzen, die in class_id spezifiziert ist. Wenn es spezifiziert ist, wird das Objekt eine Zugriffssteuerliste init_acl aufweisen; andernfalls wird das Objekt die ACL (Zugriffssteuerliste) des Objekts, das durch to_object bezeichnet ist, aufweisen. Das neu erzeugte Objekt wird dem dauerhaften Speicher von to_object zugeordnet, wobei das Durchführen eines nachfolgenden psm_open auf der Objekt-Bezugnahme, die durch diesen Aufruf zurückgegeben wird, den gleichen Wert zurückgeben wird, wie das Durchführen von psm_open auf to_object. Die Funktion wird ferner das Objekt als in der gleichen Prozeßgruppe wie to_object befindlich registrieren.
acl_t
psm_get_acl(
objref_t for_object,
status_t *status
);
Die Funktion psm_get_acl_id gibt die Zugriffssteuerliste für das Objekt, das durch den Parameter for object identifiziert ist, zurück.
boolean
psm_set_acl(
objref_t for_object,
acl_t new_acl,
status_t *status
);
Die Funktion psm_set_acl_id stellt die ACL für das Objekt, das durch den Parameter for object identifiziert ist, auf new_acl ein. Die Funktion gibt "wahr" zurück, wenn sie erfolgreich ist, und sonst "falsch".
boolean
psm_change_identity(
objref_t object,
tid_t trans_id,
objref_t new_id,
status_t *status
);
Die Funktion psm_change_oid wird die Objektidentität des Objekts, das durch den Parameter "objekt" identifiziert ist, in die neue Objektidentität ändern, die in dem Parameter new_id übertragen wird. Dieser Aufruf wird nur verwendet, wenn das Objekt, das vorher durch new_id, wenn dieses vorhanden ist, bezeichnet wurde, gelöscht wurde oder gelöscht werden soll. Die Funktion gibt einen Wert von "wahr" zurück, wenn sie erfolgreich ist; andernfalls gibt sie einen Wert von "falsch" zurück.
boolean
psm_ing_colocation(
objref_t object,
status_t *status
);
Die Funktion psm_ing_colocation wird verwendet, um zu bestimmen, ob das Objekt, das durch den Parameter "objekt" identifiziert ist, in dem gleichen dauerhaften Speicher wie das Objekt, das den Aufruf durchführt, angeordnet ist. Die Funktion gibt "wahr" zurück, wenn die Objekte gemeinsam angeordnet sind, und sonst "falsch".
char*
psm_get_path(
objref_t object,
status_t *status
);
Die Funktion pam_get_path gibt eine implementierungsabhängige mit Null abgeschlossene Zeichenfolge zurück, die dem Pfadnamen der Datei, die den dauerhaften Zustand in dem lokalen Dateisystem des Objekts, das durch den Parameter "objekt" bezeichnet ist, enthält, entspricht, wenn eine solche existiert, entspricht. Die Zeichenfolge wird durch die Verwaltungsvorrichtung nicht interpretiert; der Programmierer ist verantwortlich für das Verständnis der Zeichenfolge in dem Zusammenhang des lokalen Systems und für das Bestimmen, welche Operationen bezüglich solcher Zeichenfolgen in diesem lokalen System unterstützt werden. Wenn das lokale System das Konzept der Dateipfadnamen nicht unterstützt, gibt psm_get_path NULL mit einem Fehlerzustandscode zurück.

Aktivierung von Objekten

In den meisten Systemen müssen Objekte (oder Programme) vor der Verwendung explizit aufgerufen werden. Bei dem Objektorientierten verteilten Computersystem 11 der vorliegenden Erfindung werden Objekte 13 bei Bedarf aktiviert, ohne eine explizite Operation zu erfordern, um dieselben zu aktivieren. Die bloße Verwendung eines Objekts 13 durch eine Anforderung wird bewirken, daß ein Objekt aktiviert wird, wenn dasselbe nicht bereits in seinem aktiven Zustand ist.
Gemäß der Verwendung hierin ist ein Objekt, das in der Lage ist, auf Anforderungen zu antworten, als "aktiv" definiert. Damit ein Objekt 13 in der Lage ist, auf Anforderungen zu antworten, muß der Code für die Objektklasse in einen Prozeß 39 geladen werden, die unterstützten Anforderungsschnittstellen müssen codemäßig den Implementierungen derselben zugeordnet werden, und die dauerhaften Daten des Objekts 13 müssen hochgeladen werden. Diese letzten zwei Schritte werden durch eine "Klasseninitialisierungs"-Routine bzw. eine "Objektwiedergewinnungs"-Routine durchgeführt. Das Laden des Klassencodes muß auf eine maschinenabhängige Art und Weise gehandhabt werden. Sobald diese Schritte abgeschlossen sind, ist das Objekt 13 bereit und in der Lage, auf sämtliche Anforderungen, die dasselbe unterstützt, zu antworten.
Die Entitäten, die bei dem bevorzugten Ausführungsbeispiel in die Objektaktivierung involviert sind, sind: ein Programm, das als "Genobj" 55 bezeichnet wird, der Standardobjektverwalter 25, eine Entität, die als ein Klassenexperte 57 bezeichnet ist, und die Laufzeitbibliothek 27. Genobj 55 (Fig. 3b) ist ein Verfahren, dessen Funktion darin besteht, Objekte 13 vorzubereiten, um Anforderungen zu empfangen. Ein Objekt, das derart vorbereitet ist, wird als in seinem aktiven Zustand befindlich betrachtet. Genobj 55 bereitet ein Objekt 13 vor, indem (i) der Code der Objektklasse in den Adreßraum von Genobj 55 geladen wird (wenn notwendig), (ii) die "Klasseninitialisierungs"-Funktion für die Objektklasse aufgerufen wird, und (iii) die "Objektwiedergewinnungs"- Funktion mit den dauerhaften Daten des Objekts aufgerufen wird. Weitere Programme mit einer Funktion, die ähnlich derjenigen von Genobj ist, sind geeignet.
In diesem Zusammenhang verwaltet der Standardobjektverwalter 25 einen Satz von Objekten und einen Satz von Prozessen. Die Objekte des Standardobjektverwalters 25 sind mehr oder weniger permanent, wobei die Prozesse jedoch nach Bedarf initiiert oder beendet werden. Der Ständardobjektverwalter kennt die Klasse von jedem seiner Objekte und den Ort der dauerhaften Daten jedes Objekts. Der Standardobjektverwalter 25 weiß ferner, ob ein gegebenes Objekt 13 (oder eine Gruppe von in Beziehung stehenden Objekten) gegenwärtig einem der Prozesse, die durch den Standardobjektverwalter 25 verwaltet werden, zugeordnet ist oder nicht. Der Standardobjektverwalter 25 berücksichtigt ein Objekt oder eine Objektgruppe, die einem Prozeß zugeordnet ist, um in der Lage zu sein, Meldungen zu empfangen, und daher, um "aktiv" zu sein. Der Standardobjektverwalter 25 wird im Verlauf der "Aktivierung" eines Objekts 13 einen Prozeß 39 initiieren, der für die Klasse des Objekts geeignet ist. Wenn eine Klasse kein Programm 39 zur Initiierung spezifiziert, initiiert der Standardobjektverwalter 25 Genobj 55.
Der Klassenexperte 57 (Fig. 3b) ist eine Entität, die Informationen über eine Objektklasse (oder einen Satz von Klassen) verwaltet. Die Informationen umfassen die Betriebsschnittstellen, die die Klasse unterstützt, und die Namen bestimmter Initialisierungsfunktionen für die Klasse. Der Klassenexperte 57 hält ferner Informationen, die die Implementierung (codemäßig) der Objektklasse betreffen.
Die Laufzeitbibliothek 27 wurde vorher beschrieben. Kurz gesagt befindet sich die Laufzeitbibliothek 27 in jedem Objekt 13 und daher in jedem Prozeß 39. Die Laufzeitbibliothek, die sich in Genobj 55 befindet, tritt zusätzlich mit Genobj 55 in Wechselwirkung, um die Aktivierung und Deaktivierung von Objekten 13 zu koordinieren.
Gemäß der Verwendung in der folgenden Erläuterung ist ein "Benutzer" ein Mensch, der das Objekt-orientierte verteilte Computersystem 11 der vorliegenden Erfindung verwendet. Ein "Client" ist ein Programm oder Objekt, das eine Anforderung (oder einen Verfahrensaufruf) zu einem anderen Objekt in dem System 11 durchführt. Der "Client" kann auch die Entität sein, mit der der Benutzer interagiert, typischerweise über eine Tastatur und/oder eine Maus. Die versuchte Verwendung eines Objekts 13 durch einen Client bewirkt, daß das Objekt 13 aktiviert wird, wenn das Objekt nicht bereits in seinem aktiven Zustand ist. Ferner werden die Ausdrücke "Funktion", "Routine", "Abwicklungsmittel" und "Prozedur" in dieser Erläuterung austauschbar verwendet.
Zu Zwecken der Veranschaulichung und nicht zur Begrenzung sei angenommen, daß ein Benutzer M die Telefonnummer eines anderen Benutzers J wissen will. Der Benutzer M fragt einfach durch seine Computeranwendung nach "Telefoninformationen" bezüglich des Benutzers J. Typischerweise schließt dies das Tippen des Namens des Benutzers J durch den Benutzer M in eine Menüauswahl oder ein Formular, das durch die Computeranwendung angezeigt wird, ein. Wie in Fig. 2 gezeigt ist, führt die Computeranwendung dann die Anforderungs-Seiten- Version der "Erhalte-Telefon_Info"-Anforderung durch, die durch das Telefoninformations-Objekt 13a ("pi"-Objekt; pi = phone information), das sich irgendwo in dem System 11 befindet, exportiert wird. Die Anforderungs-Seite-Version der Anforderung wirkt mit der Laufzeitbibliothek 27, die sich in dem Anforderungsprozeß 39a befindet, zusammen. Die Laufzeitbibliothek 27 kontaktiert zuerst die Lokalisierungsdienste 21, um den Ort des Objektverwalters 25 des pi-Objekts 13a zu finden. Die Laufzeitbibliothek 27 sendet dann die tatsächliche "Erhalte-Telefon_Info"-Operationsanforderung zu dem Objektverwalter-Verwalter (MOM) 29a, der den Objektverwalter 25 des Objekts verwaltet.
Die Laufzeitbibliothek 27 in dem MOM 29a (Objektverwalterverwalter) empfängt das Paket, das die Anforderung enthält, die durch die Computeranwendung 39a des Benutzers M gesendet wurde. Die Laufzeitbibliothek 27 fragt den Objektverwalter- Verwalter 29a, ob derselbe weiß, wohin das Paket geleitet werden soll. Spezieller ausgedrückt leitet die Laufzeitbibliothek 27 die Objektidentität und den Schnittstellenidentifizierer, der in dem Paket unter jeweiligen Parametern gefunden wurde, weiter und erwartet einen "Endpunkt" (d. h. eine Lokalsockeladresse) zu empfangen, zu der das Paket weitergeleitet werden kann.
Ansprechend darauf fragt der Objektverwalter-Verwalter 29a jeden seiner Objektverwalter 23, ob der Objektverwalter das angeforderte Objekt verwaltet (d. h. das Objekt, das durch die Objektidentität, die durch die Laufzeitbibliothek 27 weitergeleitet wird, spezifiziert ist). Der Standardobjektverwalter 25 überprüft seine internen Tabellen 51 (Fig. 3a), um zu sehen, ob er das Objekt 13a verwaltet. Wenn dies der Fall ist, hält der Standardobjektverwalter 25 den Identifizierer der Gruppe von Objekten, zu der das spezifizierte Objekt 13a gehört. (Objektgruppen, die nur ein Objekt enthalten, sind erlaubt). Der Standardobjektverwalter 25 sucht dann den Zustand der Gruppe von Objekten. Eine Gruppe kann in einem beliebigen der folgenden drei Zustände sein:
"Aktiv" - die Gruppe ist bereits einem Prozeß 39 zugeordnet. Zumindest ein Endpunkt für diesen Prozeß ist zur Verwendung und zum Weiterleiten von Paketen verfügbar.
"Anhängig" - ein Prozeß 39 wurde für die Gruppe initiiert, wobei der Prozeß jedoch noch nicht seine Endpunkte mit dem Standardobjektverwalter 25 registriert hat.
"Inaktiv" - es gibt keinen Prozeß 39, der der Gruppe zugeordnet ist.
Wenn die Gruppe "aktiv" ist, gibt der Standardobjektverwalter 25 die Endpunkte des Prozesses 39, der der Gruppe zugeordnet ist, zurück. Wenn die Gruppe "anhängig" ist, gibt der. Standardobjektverwalter 25 keine Endpunkte zurück, da derselbe diese noch nicht besitzt, gibt jedoch eine Anzeige zurück, daß er das spezifizierte Objekt verwaltet. Wenn die Gruppe "inaktiv" ist, beschafft der Standardobjektverwalter 25 einen Prozeß 39 für die Gruppe.
Bei dem bevorzugten Ausführungsbeispiel erreicht der Standardobjektverwalter 25 eine Prozeßbeschaffung für eine Gruppe entsprechend der Darstellung in Fig. 3a wie folgt. Zu nächst überprüft der Standardobjektverwalter 25a einen Pool 47 von "verfügbaren" Prozessen 39c, 39d. Ein verfügbarer Prozeß ist ein solcher, der einen oder mehrere Endpunkte bei dem Standardobjektverwalter 25 registriert hat, der jedoch noch keiner Objektgruppe zugeordnet ist. Der Standardobjektverwalter 25 überprüft jeden Prozeß 39 in dem Pool 47, um einen zu finden, der mit der Klasse des spezifizierten Objekts kompatibel ist. Bestimmte Prozesse (beispielsweise Beispiele von Genobj) sind mit vielen Klassen kompatibel, wobei jedoch andere darauf beschränkt sein können, nur Objekte einer speziellen Klasse zu behandeln. Wenn der Standardobjektverwalter 25 einen kompatiblen Prozeß 39c in dem Pool 47 findet, markiert er die Gruppe als "aktiv" in den internen Tabellen 51 des Standardobjektverwalters. Der Standardobjektverwalter 25 ordnet die Endpunkte des gefundenen Prozesses 39c und den Prozeßbetriebssystemidentifizierer ferner der Gruppe zu. Der Standardverwalter 25 gibt als nächstes die neu zugeordneten Endpunkte zu dem Objektverwalter-Verwalter 29a zurück und entfernt den Prozeß 39c aus dem verfügbaren Prozeßpool 47.
Wenn der Standardobjektverwalter 25 in dem Pool 47 von verfügbaren Prozessen keinen kompatiblen Prozeß findet, initiiert der Standardobjektverwalter 25 einen kompatiblen Prozeß 39f. Um dies durchzuführen, bestimmt der Standardobjektverwalter 25 den Pfad eines kompatiblen Prozesses 39f durch das Betrachten von Informationen, die zu der Klasse des Objekts gehören. Wie genannt wurde, wird, wenn eine Klasse keinen Prozeß spezifiziert, der Standardobjektverwalter 25 Genobj 55 initiieren. Nach dem Initiieren des Prozesses 39f markiert der Standardobjektverwalter 25 in seinen internen Tabellen 51, daß die Gruppe des Objekts in "anhängiger Aktivierung" ist. Der Standardobjektverwalter 25 setzt ferner einen Eintrag 39f in einen Pool 53 von "anhängigen Prozessen". Der Eintrag für den Prozeß 39f enthält den Betriebssystemidentifizierer des Prozesses und die Identität der Gruppe, für die der Prozeß 39f bestimmt ist.
Wenn der Prozeß 39f seine Endpunkte registriert (über eine Register Endpunkte-Anforderung an den Standardverwalter 25), wird sein Eintrag aus dem anhängigen Prozeßpool 53 beseitigt, wobei die Gruppe, für die derselbe bestimmt ist, durch den Standardverwalter 25 in den internen Tabellen 51 als "aktiv" markiert wird. Der Standardobjektverwalter 25 ordnet die Gruppe den Endpunkten des Prozesses und dem Prozeßidentifizierer in seinen internen Tabellen 51 zu. Es sei bemerkt, daß, wenn ein Prozeß, der ohne eine Gruppenzuordnung initiiert wird, seine Endpunkte registriert, derselbe von dem Pool 53 anhängiger Prozesse zu dem Pool 47 verfügbarer Prozesse bewegt wird.
In dem Fall, daß Genobj 55 durch den Standardobjektverwalter 25 initiiert wird, ist Genobj wie folgt gemäß der Darstellung in Fig. 3b wirksam. Bald nachdem es durch den Standardobjektverwalter 25 initiiert wurde, fragt Genobj 55 die Laufzeitbibliothek 27 nach Endpunkten. Nach dem Beschaffen der Endpunkte führt Genobj 55 die "Registriere Endpunkte"- Anforderung zu dem Standardobjektverwalter 25 durch. Die Parameter für die Anforderung umfassen den Betriebssystem-Prozeßidentifizierer dieses Beispiels von Genobj 55 und die Endpunkte, die aus der Laufzeitbibliothek 27 beschafft wurden.
Zusätzlich zu der Registrierung der Endpunkte bei dem Standardobjektverwalter 25 führt Genobj 55 eine Registrierung (einer unterschiedlichen Art) mit der Laufzeitbibliothek 27 durch. Genobj 55 registriert eine "Unbekanntes-Objekt"-Funktion 61 (eine Funktion, die aufgerufen wird, wenn die Laufzeitbibliothek 27 eine Anforderung empfängt, bezüglich der sie nicht weiß, wie sie dieselbe handhaben soll). Nach dem Durchführen beider Registrierungen schaltet Genobj 55 die Steuerung zu der Laufzeitbibliothek 27, die nun das Empfangen von Anforderungen beginnen kann (die durch den Standardobjektverwalter 25 weitergeleitet werden oder möglicherweise direkt durch Anforderer gesendet werden). Wenn die Laufzeitbibliothek 27 eine Anforderung empfängt, bezüglich der sie nicht weiß, wie sie dieselbe handhaben soll, ruft die Laufzeitbibliothek 27 die Unbekanntes-Objekt-Funktion 61 auf.
Die Unbekanntes-Objekt-Funktion (oder das Abwicklungsmittel) 61 von Genobj wirken mit dem Standardobjektverwalter 25 durch die get_obj_info()-Anforderung zusammen, um die Klasse des Objekts und den Ort der dauerhaften Daten des Objekts zu bestimmen. Unter Verwendung des gerade beschafften Klassenidentifizierers lokalisiert und kontaktiert die Funktion 61 den Experten 57 für die Klasse. Von dem Klassenexperten 57 findet die Funktion die Namen der Klasseninitialisierungsfunktion und der Objektwiedergewinnungsfunktion durch die Anforderung get_class_info(), wie in Fig. 3b gezeigt ist. Die Unbekanntes-Objekt-Funktion 61 erhält möglicherweise ebenfalls Informationen, die dieselbe benötigt, um die Implementierung der Klasse in den Funktionenadreßraum zu laden. Nach dem Laden der Klassenimplementierung ruft die Unbekanntes-Objekt-Funktion 61 die Klasseninitialisierungsfunktion auf. Der primäre Zweck der Klasseninitialisierungsfunktion besteht darin, die Klassenoperation-Schnittstellen und Deaktivierungsabwicklungsmittel in der Laufzeitbibliothek 27 zu registrieren. Die Unbekanntes-Objekt-Funktion 61 ruft dann die Klassen-Objektwiedergewinnungsfunktion auf, die das Überleiten an den Ort der dauerhaften Daten des Objekts umfaßt. Nachdem die Wiedergewinnungsroutine abgeschlossen ist, registriert die Unbekanntes-Objekt-Funktion 61 das Objekt und die Klasse in der Laufzeitbibliothek 27. Schließlich gibt die Unbekanntes-Objekt-Funktion 61 die Steuerung zu der Laufzeitbibliothek 27 zurück.
Die Laufzeitbibliothek besitzt nun ausreichend Informationen (die von den Anforderungsregistrierungen und der Objekt/Klassen-Registrierung empfangen werden), um die Anforderung (das Paket) ordnungsgemäß zu verarbeiten. Dabei ist das Objekt, das wiedergewonnen wurde, nun bereit, um die Anforderung, die durch das Paket spezifiziert ist, zu empfangen. Die Laufzeitbibliothek 27 ruft einfach den Kontrollabschnitt auf, den das Objekt für die Anforderung registriert hat, und überträgt die Daten, die in dem Anforderungspaket gefunden werden. Der Kontrollabschnitt vereinigt die Daten und ruft das geeignete Verfahren des Objekts auf.
Wenn die nächste Anforderung für das Objekt 13 in einem Paket ankommt, wird die Laufzeitbibliothek 27 in der Lage sein, den Kontrollabschnitt direkt ohne Umleitung zu der Unbekanntes-Objekt-Funktion 61 aufzurufen, da das Objekt zu diesem Zeitpunkt "bekannt" ist.
Der Vorteil der vorher genannten Prozedur besteht darin, daß dieselbe für den Benutzer und für Client-Programme transparent ist. Der Client, der die Anforderung bezüglich des Objekts aufgerufen hat, besitzt keine Kenntnis davon, ob vor der Ausgabe der Anforderung das Objekt 13 aktiv ist oder nicht. Diesbezüglich erscheinen alle Objekte für Verarbeitungsanforderungen verfügbar oder aktiv zu sein, selbst wenn dieselben gegenwärtig keinem Prozeß zugeordnet sind. Folglich liefert die vorliegende Erfindung eine Computereinrichtung zum Implementieren von Operationen und Daten eines Zielobjekts (und darüberhinaus zum Empfangen und Behandeln von Anforderungen) für ein Zielobjekt, unabhängig von der Zuordnung des Zielobjekts zu einem Prozeß zu dem Zeitpunkt, zu dem die Anforderung erteilt wurde.

Deaktivierung von Objekten

Die Klasseninitialisierungsroutine der Klasse des Objekts ist verantwortlich für die Registrierung einer Deaktivierungsabwicklung in der Laufzeitbibliothek. Bei dem bevorzugten Ausführungsbeispiel liefern die Objektverwalter 23 eine Deaktivierung von Prozessen automatisch ansprechend auf das System 11, das Betriebsmittel benötigt. Wenn Genobj 55 eine Prozeßbeendigungsanforderung von dem Standardobjektverwalter 25 empfängt, wird dasselbe die Laufzeitbibliothek 27 fragen, um die Deaktivierungsabwicklungsmittel für jedes registrierte Objekt 13 aufzurufen. Die Beendigungsanforderung von dem Standardobjektverwalter 25 besitzt einen "Prioritäts"-Parameter, der anzeigt, wie wichtig es ist, den Prozeß 39 zu beenden. Es existieren zumindest drei Prioritätswerte, die der Parameter annehmen kann, die von "Bitte beenden, wenn du nicht beschäftigt bist" bis "Beende oder stirb ungnädig" reichen. Genobj 55 leitet den Prioritätsparameter zu der Laufzeitroutine "Deaktiviere_Objekte" weiter, die die Deaktivierungsabwicklungsmittel aufruft. Bevor die Deaktivierungsabwicklungsmittel aufgerufen werden, vergleicht die Deaktiviere_Objekte-Routine den Wert des Prioritätsparameters mit den "Beendigungs-Unwilligkeits"-Werten, die durch jedes Objekt 13 registriert sind. Wenn der Prioritätspegel größer ist als jeder "Unwilligkeits"-Pegel, werden die Deaktivierungsabwicklungsmittel aufgerufen. Wenn dies nicht der Fall ist, kehrt die "Deaktiviere_Objekte"-Routine zu Genobj 55 zurück, wobei der gegenwärtig maximale Unwilligkeitspegel weitergeleitet wird, wobei Genobj 55 wiederum diesen Wert zudem Standardobjektverwalter 25 zurückleitet.
Ein Objekt 13 ist in der Lage, seinen "Unwilligkeits"-Pegel zu ändern, wann immer es geeignet ist. Beispielsweise kann ein Objekt 13, das für eine bestimmte Zeit überhaupt keine Verfahrensanforderungen empfangen hat, der Laufzeitbibliothek 27 sagen, daß sein Unwilligkeitspegel gering ist. Wenn dieses Objekt 13 danach Verfahrensanforderungen empfangen soll, könnte es der Laufzeitbibliothek 27 mitteilen, daß sein Unwilligkeitspegel hoch war. Die Laufzeitbibliothek 27 verfolgt den gegenwärtigen Unwilligkeitspegel jedes Objekts 13.

Objekte, die andere Objekte in ihrer Objektgruppe aktivieren

Die Wiedergewinnungsroutine eines Objekts kann entscheiden (basierend auf seinen dauerhaften Daten), daß dasselbe weitere Objekte in seiner Objektgruppe benötigt, die in Genobj aktiv sind. Die Wiedergewinnungsroutine kann bewirken, daß ein anderes Objekt aktiviert wird, indem die Unbekanntes-Objekt-Funktion 61 (Abwicklungsmittel) von Genobj aufgerufen wird, wobei die Objektidentität des gewünschten Objekts 13 zugeführt wird. Die Wiedergewinnungsroutine kann dies für so viele Objekte durchführen, wie benötigt werden. Das Unbekanntes-Objekt-Abwicklungsmittel 61 überprüft, um zu sehen, daß das gewünschte Objekt nicht bereits aktiv ist. Wenn das Objekt nicht aktiv ist, verhält sich das Abwicklungsmittel 61 im wesentlichen auf die gleiche Weise, wie es sich verhält, wenn es durch die Laufzeitbibliothek 27 aufgerufen wird, wie oben beschrieben wurde. Die Unterschiede beziehen sich auf das Ausgeben einer Gleichzeitigkeitssteuerung, und nicht auf irgendwelche Unterschiede im Endeffekt. Es sei bemerkt, daß Aufrufe zu dem Unbekanntes-Objekt-Abwicklungsmittel 61 rekursiv sein können. Beispielsweise kann das Abwicklungsmittel durch die Laufzeitbibliothek 27 bezüglich eines speziellen Objekts "A" aufgerufen werden, dessen Wiedergewinnungsroutine das Abwicklungsmittel bezüglich des Objekts "B" aufruft. Die Wiedergewinnungsroutine für "B" kann wiederum das Abwicklungsmittel bezüglich des Objekts "C" aufrufen, usw. Schließlich werden die Klassen aller benötigter Objekte 13 initialisiert sein und die Zustände derselben wiedergewonnen sein, wobei die Steuerung schließlich zu der Laufzeitbibliothek 27 zurückkehrt.

Steuerung des Klassenladens und der Initialisierung

Eine beliebige Anzahl von Objekten in einer Objektgruppe kann von der gleichen Klasse sein. Wenn jedes Objekt 13 in Genobj 55 aktiviert wird, überprüft Genobj, um zu sehen, ob es bereits die Klasse des Objekts "geladen" und initialisiert hat. Wenn dies der Fall ist, wird Genobj 55 davon absehen, die Klasse wieder zu laden und zu reinitialisieren. Genobj 55 ruft jedoch die Wiedergewinnungsfunktion auf, unabhängig davon, ob die Klasse vorher geladen wurde. Dies ist der Fall, da die Wiedergewinnungsfunktion dazu dient, den Zustand des Objekts 13 wiederzugewinnen, und nicht die Klas se (wobei dies für jedes Objekt durchgeführt werden muß).

Äquivalente

Obwohl die Erfindung speziell bezugnehmend auf ein bevorzugtes Ausführungsbeispiel derselben gezeigt und beschrieben wurde, ist es für Fachleute offensichtlich, daß verschiedene Änderungen in Form und Detail in derselben durchgeführt werden können, ohne von dem Schutzbereich der Erfindung, wie er durch die beigefügten Ansprüche definiert ist, abzuweichen.

Claims

1. Ein Objekt-orientiertes verteiltes Computersystem (11), das eine Mehrzahl von Objektmodellen unterstützt, wobei jedes Objektmodell durch die Art und Weise, auf die der dauerhafte Zustand der Objekte des Modells verwaltet wird, und die Art und Weise definiert ist, auf die Operationen bezüglich der Objekte des Modells in einen Code abgebildet werden, um die Operationen durchzuführen, wobei das Abbilden in den Code das Ausführungsmodell der Objekte des Modells ist, mit folgenden Merkmalen:

einem ersten Computer (1),

einem zweiten Computer (2),

einem Verwalter von Objektverwaltern (29a), der sich in dem ersten Computer befindet,

einem Verwalter von Objektverwaltern (29b), der sich in dem zweiten Computer befindet,

einer Mehrzahl von Objektverwaltern (23a, ..., 23n), die sich in dem ersten Computer befinden, wobei jeder auf einem unterschiedlichen Objektmodell basiert,

zumindest einem Objektverwalter (25), der sich in dem zweiten Computer befindet, der auf einem Objektmodell basiert,

Objekte eines Objektmodells (13a), die einen dauerhaften Zustand und ein Ausführungsmodell umfassen, und die Operationsanforderungen zu Objekten eines unterschiedlichen Objektmodells kommunizieren, indem Auf rufe in dem System durchgeführt werden, wobei jede Anforderung (i) einen Objektidentifizierer, der ein Zielobjekt (13b) anzeigt, und (ii) eine Anzeige einer Operation, die wunschgemäß durch das Zielobjekt durchgeführt werden soll, aufweist, wobei jeder Objektverwalter eine Operation und eine Existenz von Objekten, die diesem Objektverwalter zugeordnet sind, entsprechend dem Objektmodell dieses Objektverwalters unterstützt, und wobei jeder Verwalter von Objektverwaltern auf eine Art und Weise, die frei von einem vorprogrammierten Code bei dem Operationsaufruf ist, mit jeweiligen zugeordneten Objektverwaltern der jeweiligen Objektmodelle der Objektverwalter kommuniziert, um Objekte zu lokalisieren, zu denen Operationsanforderungen kommuniziert werden sollen, derart, daß eine Anforderung durch ein erstes Objekt, das durch einen ersten Objektverwalter auf dem ersten Computer verwaltet wird, um eine Operation bezüglich eines zweiten Objekts, das durch einen zweiten Objektverwalter auf dem gleichen Computer verwaltet wird, durchzuführen, von dem ersten Objekt zu dem Verwalter von Objektverwaltern auf dem ersten Computer und dann zu dem zweiten Objektverwalter kommuniziert wird, wobei der Verwalter von Objektverwaltern auf dem ersten Computer auf das erste Objekt anspricht und (i) basierend auf dem Identifizierer des zweiten Objekts, jedoch unabhängig von dem Typ des zweiten Objekts und unabhängig von dem Objektmodell des zweiten Objektverwalters, bestimmt, ob das zweite Objekt von dem zweiten Objektverwalter verwaltet wird, und (ii) die Anforderung zu dem zweiten Objektverwalter kommuniziert, wobei der zweite Objektverwalter den dauerhaften Zustand und das Ausführungsmodell des zweiten Objekts entsprechend seinem Objektmodell erhält und aus denselben das zweite Objekt aktiviert und die Anforderung zu dem zweiten Objekt liefert, und

wobei eine Anforderung durch das erste Objekt, das durch den ersten Objektverwalter auf dem ersten Computer verwaltet wird, um eine Operation bezüglich eines dritten Objekts (13d), das durch einen dritten Objektverwalter (23) auf dem zweiten Computer verwaltet wird, durchzuführen, von dem ersten Objekt zu dem Verwalter von Objektverwaltern auf dem zweiten Computer und dann zu dem dritten Objektverwalter kommuniziert wird, wobei der Verwalter von Objektverwaltern auf dem zweiten Computer auf das erste Objekt anspricht, und (i) basierend auf dem Identifizierer des dritten Objekts, jedoch unabhängig von dem Typ des dritten Objekts und unabhängig von dem Objektmodell des dritten Objektverwalters, bestimmt, ob das dritte Objekt durch den dritten Objektverwalter verwaltet wird, und (ii) die Anforderung zu dem dritten Objektverwalter kommuniziert, wobei der dritte Objektverwalter entsprechend seinem Objektmodell den dauerhaften Zustand und das Ausführungsmodell des dritten Objekts erhält und aus denselben das dritte Objekt aktiviert und die Anforderung zu dem dritten Objekt liefert.

2. Das Objekt-orientierte verteilte Computersystem gemäß Anspruch 1, bei dem jeder Verwalter von Objektverwaltern eine gemeinsame Schnittstelle verwendet, um mit jedem der Objektverwalter, die sich auf dem gleichen Computer befinden, zu kommunizieren.