DE69425699T2

DE69425699T2 - Integrierung von Systemverwaltungsdiensten mit einem unterliegenden Systemobjektmodell

Info

Publication number: DE69425699T2
Application number: DE69425699T
Authority: DE
Inventors: Mark S. Blanford; Isaac J. Heizer; Anirudh A. Sahni; Michael R.C. Seaman
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 1993-06-25
Filing date: 1994-06-23
Publication date: 2000-12-28
Anticipated expiration: 2014-06-24
Also published as: EP0631232A2; EP0987626A3; JP3949180B2; EP0987626A2; CA2124720C; DE69425699D1; US6175878B1; JPH07146848A; EP0631232A3; CA2124720A1; EP0631232B1

Description

Die vorliegende Erfindung betrifft allgemein Datenverarbeitungssysteme und insbesondere die Integrierung von Systemverwaltungsdiensten mit einem unterliegenden Systemobjektmodell.
Damit Systemverwaltungsfunktionen ihre beabsichtigten Aufgaben richtig ausführen, müssen die Funktionen den internen Zustand der Komponenten überwachen können, die sie verwalten. Herkömmliche Systemen hatten keinen Zugriff auf den internen Zustand verwalteter Komponenten gehabt. Als Ergebnis ist es häufig bei herkömmlichen Systemen schwierig gewesen, die Komponenten richtig zu verwalten. Gewisse herkömmliche Systeme haben versucht, den Zugriff auf Informationen in bezug auf verwaltete Komponenten zu vergrößern, indem eine getrennte Grundstruktur und Zugriffstechnik für die internen Zustandsinformationen hinzugefügt wurden. Solche herkömmlichen Systeme haben jedoch die internen Zustandsinformationen nicht allgemein durch übliche, für Benutzer sichtbare Systemschnittstellen und Personen-Schnittstellen verfügbar gemacht.
Z. Hong und W. McCoy, An associated object model for distributed systems, Operating Systems Review (SIGOPS), Oktober 1990, Bd. 24, Nr. 4, Seiten 34 bis 51, beschreiben ein Modell zur Unterstützung verteilter Anwendungen, das Associated Object Model genannt wird, in dem mehrere Objekte miteinander durch eine abstrakte Zuordnung kommunizieren können, wodurch die Arbeitsweise der verteilten Anwendungsobjekte (DAO) verbessert wird. Ein Broker genannter Mechanismus unterstützt die Herstellung und Beibehaltung von Zuordnungen zwischen zusammenarbeitenden DAOen. In dem Modell ist der Broker dazu bestimmt, das Auffinden von mehreren Objekten zu unterstützen. Der Broker errichtet und verwaltet abgeleitete Zuordnungen zwischen zusammenarbeitenden DAOen, der Broker liegt zwischen den DAOen in dem System und ein lokaler Broker ist an jedem Ort vorhanden, wo einige DAOen vorhanden sind. Die Aufgaben eines lokalen Brokers umfassen den Aufbau einer Zuordnung, die die entsprechenden Glieder umfaßt, das Bereitstellen eines zuverlässigen Datenübertragungsmechanismus, die Ausführung einer Abbildung von dem lokalen Namen auf einen globalen Namen, die Garantie der Einzigartigkeit der globalen Namen und die Bereitstellung von Mechanismen zur Erholung von Fehlern.
Es ist die Zielsetzung der Erfindung, ein verteiltes System zu schaffen, bei dem die Komponenten in wirksamer und passender Weise verwaltet werden können, sowie ein Verfahren zum Betrieb des verteilten Systems.
Diese Zielsetzung wird durch ein Verfahren erreicht, wie es im unabhängigen Anspruch 1 beansprucht ist, ein computerlesbares Medium, wie es im Anspruch 18 beansprucht ist, und ein verteiltes System, wie es in dem unabhängigen Anspruch 19 beansprucht ist. Bevorzugte Ausführungsformen der Erfindung sind Gegenstände der abhängigen Ansprüche.
Gemäß einem ersten Gesichtspunkt der vorliegenden Erfindung wird ein Verfahren in einem verteilten System durchgeführt, das zumindest eine Speichereinrichtung und Prozessoren zur Durchführung von Prozessen aufweist. Bei diesem Verfahren wird der interne Zustand einer verwalteten Komponente als ein Objekt in einer der Speichereinrichtungen dargestellt. Das Objekt ist für die Prozesse auf den Prozessoren sichtbar. Auf das Objekt wird dann im Auftrag von einem der Prozesse zugegriffen, um den internen Zustand der verwalteten Komponente zu erhalten.
Die verwaltete Komponente kann in eine einzige Unterkomponente oder in mehrere Unterkomponenten unterteilt werden. Jede der Unterkomponenten hat einen internen Zustand. Des weiteren kann das Verfahren den zusätzlichen Schritt umfassen, das Objekt in ein Behälterobjekt für die Komponente einzuschließen. Das Behälterobjekt wird in einer der Speichereinrichtungen gespeichert und ist für Prozesse sichtbar, die auf dem Prozessor laufen. Das Verfahren ist zur Verwendung mit mehreren Komponenten anpaßbar, die verwaltet werden sollen. Ein Systemverwaltungsobjekt kann in den Speichereinrichtungen gespeichert werden. Das Systemverwaltungsobjekt verwaltet die verwaltete Komponente.
Gemäß einem anderen Gesichtspunkt der vorliegenden Erfindung umfaßt ein verwaltetes System Speichereinrichtungen und Prozessoren zur Durchführung der Prozesse. Das verteilte System umfaßt auch eine zu verwaltende Komponente, die einen internen Zustand hat. Das verteilte System umfaßt eine Einrichtung zur Speicherung des internen Zustands der Komponente in der Speichereinrichtung als ein Objekt. Das verteilte System umfaßt des weiteren eine Einrichtung, das Objekt für die auf den Prozessoren laufenden Prozesse zugreifbar zu machen.
Gemäß einem noch anderen Gesichtspunkt der vorliegenden Erfindung wird ein Verfahren bei einem verteilten System durchgeführt, das eine Prozedurfernaufrufeinrichtung, ein erstes Datenverarbeitungssystem und ein zweites Datenverarbeitungssystem aufweist. Das erste Datenverarbeitungssystem umfaßt einen Prozessor zur Durchführung eines Prozesses. Das zweite Datenverarbeitungssystem umfaßt eine Komponente, die einen Zustand und eine Speichereinrichtung aufweist. Bei diesem Verfahren wird ein Objekt in der Speichereinrichtung des zweiten Datenverarbeitungssystems gespeichert. Das Objekt hält den Zustand der Komponente. Der Prozeß, der auf dem Prozessor des ersten Datenverarbeitungssystems läuft, verlangt Zugriff auf den Zustand der Komponente, die in dem Objekt gehalten ist. In Antwort auf die Anforderung wird ein Prozedurfernaufruf durchgeführt, wobei die Prozedurfernaufrufeinrichtung verwendet wird, Zugriff auf die Information durch den Prozeß über den Zustand der Komponente zu erlangen, die in dem Objekt gehalten ist.
Entsprechend einem noch anderen Gesichtspunkt der vorliegenden Erfindung wird ein Verfahren in einem verteilten System durchgeführt, das Speichereinrichtungen zur Speicherung von Objekten, die Namen besitzen, Prozessoren, die Programme mit Zuständen durchführen und ein Betriebssystem aufweist. Das Betriebssystem umfaßt einen Namendienst, der einen globalen Namensraum für die Namen der Objekte liefert, die in den Speichereinrichtungen gespeichert sind. Bei diesem Verfahren wird eine Variable in einem Programm erklärt, daß sie eine Variable ist, deren Wert in dem globalen Namensraum verfügbar ist. Das Programm läuft auf einem der Prozessoren, so daß der Variablen ein Wert zugeordnet wird, und der Wert wird in dem Objekt gespeichert, das in dem globalen Namensraum sichtbar ist. Die Variable kann ein Zähler sein, der mit vorbestimmten Größen erhöht wird, eine Meßeinrichtung, deren Wert sich über einen vorbestimmten Bereich ändert, oder irgendeine andere Variable, die Zustandsinformationen über das Programm hält.
Entsprechend einem zusätzlichen Gesichtspunkt der vorliegenden Erfindung wird ein Verfahren in einem verteilten System durchgeführt, das Datenverarbeitungsbetriebsmittel und zumindest eine Speichereinrichtung umfaßt. In diesem Verfahren werden die Datenverarbeitungsbetriebsmittel, die Hardwarekomponenten und/oder Softwarekomponenten umfassen können, als Objekte mit Namen modelliert. Die mit Namen versehenen Objekte werden in der Speichereinrichtung gespeichert. Systemverwaltungsobjekte mit Namen werden auch in der Speichereinrichtung gespeichert. Die Systemverwaltungsobjekte werden verwendet, die Datenverarbeitungsbetriebsmittel zu verwalten.

Kurze Beschreibung der Zeichnungen

Fig. 1 ist ein Blockdiagramm eines verteilten Systems zur Durchführung einer bevorzugten Ausführungsform der vorliegenden Erfindung.
Fig. 2 ist ein Blockdiagramm eines Datenverarbeitungssystems des verteilten Systems der Fig. 1.
Fig. 3 ist ein Blockdiagramm, das ausführlicher zwei Datenverarbeitungssysteme in dem verteilten System der Fig. 1 darstellt.
Fig. 4 ist ein Schema, das einen verteilten Namensraum darstellt, der entsprechender der bevorzugten Ausführungsform der vorliegenden Erfindung erzeugt wird.
Fig. 5 ist ein Flußdiagramm, das die von der bevorzugten Ausführungsform der vorliegenden Erfindung durchgeführten Schritte darstellt, die gemeinsame Benutzung interner Zustandsinformationen in dem verteilten System der Fig. 1 zu gestatten.
Fig. 6 ist ein Flußdiagramm, das die Schritte darstellt, die zur Verwendung eines Instruments in dem verteilten System der Fig. 1 durchgeführt werden.

Ausführliche Beschreibung der Erfindung

Die bevorzugte Ausführungsform der vorliegenden Erfindung integriert Systemverwaltungsdienste mit einem unterliegenden Systemobjektmodell. Fig. 1 zeigt ein Blockdiagramm eines verteilten Systems 10 zur Durchführung der bevorzugten Ausführungsform der vorliegenden Erfindung. Der Durchschnittsfachmann auf dem Gebiet sieht, daß das verteilte System 10 der Fig. 1 nur beispielhaft ist, und erkennt, daß die vorliegende Erfindung in anderen verteilten Systemen durchgeführt werden kann. Das verteilte System 10 umfaßt vier Datenverarbeitungssysteme 11A, 11B, 11C und 11D. Die Datenverarbeitungssysteme 11A, 11B, 11C und 11D stehen miteinander über ein Netz 12, wie ein lokales Netz (LAN), in Verbindung.
Fig. 2 zeigt ein ausführlicheres Blockdiagramm des Datenverarbeitungssystems 11A. Es wird zum Zweck der Einfachheit bei der Erörterung unten angenommen, daß die Datenverarbeitungssysteme 11B, 11C und 11D die gleichen Konfigurationen haben. Das Datenverarbeitungssystem 11A umfaßt eine zentrale Verarbeitungseinheit (CPU) 14, einen Speicher 16, eine Tastatur 18, eine Maus 20 und eine Videoanzeige 22. Der Speicher 16 hält eine Kopie eines objektorientierten Betriebssystems 24. Eine getrennte Kopie des Betriebssystems 24 läuft in jedem der Datenverarbeitungssysteme 11A, 11B, 11C und 11D (Fig. 1). Das Betriebssystem 24 ist in eine Anzahl Untersysteme unterteilbar, die ein Systemverwaltungsuntersystem umfassen, das zur Verwaltung von Komponenten des Systems verantwortlich ist. Das Verwaltungsuntersystem der Systeme ist der Brennpunkt der Erörterung unten.
Damit jemand versteht, wie die bevorzugte Ausführungsform der vorliegenden Erfindung arbeitet, ist es zunächst notwendig, gewisse objektorientierte Programmierkonzepte zu verstehen, die darin verwendet werden. Ein erstes, objektorientiertes, von der bevorzugten Ausführungsform verwendetes Konzept ist die Bezeichnung eines "Objekts". Ein "Objekt" ist eine Gesamtheit, die eine Kombination aus zumindest zwei Dingen ist: Daten, die einen internen Zustand des Objekts spezifizieren, und Funktionen, die auf die Daten wirken. Ein Objekt kann als eine Kombination von Datenstrukturen und Funktionen betrachtet werden. Die Funktionen sind darauf beschränkt, nur die Elemente der Datenstruktur zu verarbeiten.
Ein eng verwandtes Konzept ist das Konzept einer "Schnittstelle". Eine "Schnittstelle" ist eine Gruppe semantisch verwandter Funktionen, die in einer mit Namen versehenen Einheit organisiert sind (der Name ist die Kennung der Schnittstelle). Schnittstellen haben der Definition nach keine Instantiierungen (d. h., eine Schnittstelle enthält keinen Code zur Ausführung von Funktion, die in der Schnittstelle identifiziert sind); vielmehr spezifizieren Schnittstellen einen Satz von Signaturen für Funktionen. "Instantüerung" bezieht sich auf den Prozeß, Strukturen innerhalb des Speichers zu erzeugen, die ein Objekt darstellen, so daß Operationen an dem Objekt hervorgerufen werden können. Wenn ein Objekt eine Schnittstelle "unterstützt", liefert das Objekt Code für die Funktionen, die durch die Schnittstelle festgelegt sind. Somit ist das Objekt, das die Schnittstelle unterstützt, dafür verantwortlich, den Code zur Ausführung der Funktionen der Schnittstelle zu liefern. Der Code, der vorgesehen wird, muß den Signaturen der Funktionen entsprechen, die durch die Schnittstelle festgelegt sind (d. h., der Code muß die gleichen Parameter und Funktionalität wie in der Schnittstelle spezifiziert aufweisen). Entsprechend kann eine Schnittstelle als ein Standard betrachtet werden, dem Objekte entsprechen müssen.
Ein anderes in der bevorzugten Ausführungsform verwendetes Konzept ist die Bezeichnung eines "Moniker". Ein "Moniker" ist ein zusammengesetzter Name für ein Objekt, das einen Zeiger zu dem Objekt enthält. Eine formalere Definition eines Moniker ist ein Objekt, der die IMoniker Schnittstelle unterstützt (wie durch das Microsoft OLE 2.0 Protokoll festgelegt). Die IMoniker Schnittstelle umfaßt eine Funktion, um den Moniker an das Objekt zu binden, auf das der Zeiger des Monikers zeigt. Das Binden bringt ein Objekt in einen Arbeitszustand, so daß Dienste, die von dem Objekt geliefert werden, aufgerufen werden können. Man erkennt, daß die vorliegende Erfindung nicht auf Ausführungsformen begrenzt ist, die Moniker verwenden. Die Diskussion der Moniker bei der bevorzugten Ausführungsform ist lediglich beispielhaft.
Wie es oben erwähnt wurde, integriert die bevorzugte Ausführungsform der vorliegenden Erfindung das Systemverwaltungs-Untersystem in das unterliegende Objektmodell des objektorientierten Betriebssystems 24. Mit anderen Worten modelliert das Betriebssystem Komponenten des verteilten Systems 10 als Objekte, und das Systemverwaltungs-Untersystem wird in die Objekte integriert. Die Integration des Systemverwaltungs-Untersystems mit dem unterliegenden Systemobjektmodell liefert eine vereinheitlichte Methode, auf Systemverwaltungsfunktionen zuzugreifen. Des weiteren erleichtert die Integration die Verwendung von Werkzeugen in dem Systemverwaltungs-Untersy stem, die von anderen Untersystemen des Betriebssystems 24 bereitgestellt werden. Des weiteren erlaubt die Integration, daß das Systemverwaltungs-Untersystem ohne weiteres Zugriff auf interne Zustandsinformationen über verwaltete Komponenten gewinnt, die als Objekte modelliert sind. Das kumulative Ergebnis der Integration ist eine wesentliche Verringerung der Last, die dem Systemverwaltungs-Untersystem auferlegt ist, und eine wesentliche Zunahme der dem Systemverwaltungs-Untersystem verfügbaren Leistungen.
Die Systemverwaltung ist bei der bevorzugten Ausführungsform der vorliegenden Erfindung vorgesehen, indem den Systemkomponenten erlaubt wird, daß sie so konstruiert werden, daß sie ohne weiteres verwaltbar sind, und indem Dienstprogramme zur Verwaltung der Systemkomponenten bereitgestellt werden. Jede Systemkomponente in dem verteilten System 10 ist als ein Objekt modelliert. Unterkomponenten einer Komponente können auch getrennt als Objekte modelliert werden. Systemkomponenten werden gebildet, damit sie verwaltbar sind, indem die Komponenten und Unterkomponenten in Objekte eingeschlossen werden, die in dem globalen Namensraum sichtbar sind. Die Unterkomponenten und die Komponenten umfassen Eigenschaften, die Zustandsinformationen festlegen. Da die Zustandsinformation in einem Objekt gehalten wird, das in dem globalen verteilten Namensraum sichtbar ist, können andere Objekte Zugriff auf die Zustandsinformation gewinnen. Da die Komponenten und Unterkomponenten als Objekte modelliert werden, sind sie ohne weiteres auffindbar und zugriffsbereit. Im allgemeinen unterstützt jedes verwaltete Objekt Schnittstellen, die Dienste für andere Requesterobjekte bereitstellen.
Die Arbeitsweise des Systemverwaltungs-Untersystem der bevorzugten Ausführungsform wird vielleicht am besten anhand eines Beispiels erklärt. Das Systemverwaltungs- Untersystem ist nicht in einem einzigen der Datenverarbeitungssysteme 11A, 11B, 11C und 11 D isoliert. Vielmehr wir die Verantwortung des Systemverwaltungs-Untersystems auf die Datenverarbeitungssysteme 11A, 11B, 11C und 11D verteilt, so daß die Datenverarbeitungssysteme gemeinsam die Systemverwaltung durchführen. Wie es in Fig. 3 gezeigt ist, sei angenommen, daß das Datenverarbeitungssystem 11A bei der Durchführung von Systemverwaltungsfunktionen wünscht, zusätzliche Informationen über den Zustand eines Datenservers 26 herauszufinden, der fernliegend in einem Speicher 16' des Datenverarbeitungssystems 11B gehalten wird. Bei diesem Beispiel ist der Datei server 26 die verwaltete Komponente, die das Systemverwaltungs-Untersystem zu verwalten sucht. Der Zustand des Dateiservers 26 ist der Bequemlichkeit halber in eine Anzahl von Unterkomponenten unterteilt. Insbesondere ist der Dateiserver 26 in einen Anforderungsempfänger, einen Anforderungsprozessor und einen Ergebnisrückgeber unterteilt. Der Anforderungsempfänger ist verantwortlich, Anforderungen für einen Dienst von dem Dateiserver zu empfangen. Der Anforderungsprozessor ist verantwortlich, solche Anforderungen zu verarbeiten, und der Ergebnisrückgeber ist verantwortlich, die Ergebnisse des Diensts an den Requester zurückzugeben, der den Dienst verlangte.
Man erkennt, daß der Satz von Unterkomponenten, der in einer verwalteten Komponente enthalten ist, nicht der gleiche bleiben muß; vielmehr können sich die Unterkomponenten dynamisch mit der Zeit ändern, so daß Unterkomponenten mit fortschreitender Zeit hinzugefügt oder entfernt werden. Man erkennt auch, daß die Unterkomponenten hierarchisch organisiert werden können.
Die CPU 14' des Datenverarbeitungssystems 11 B stellt Informationen über den Datenserver 26 und seine Unterkomponenten her, die anderen Komponenten in dem verteilten System 10 (Fig. 1) zur Verfügung stehen, indem ein Objekt 32 für den Dateiserver und Objekte 34A, 34B und 34C für die Unterkomponenten erzeugt werden, die Zustandsinformationen über den Dateiserver und seine Unterkomponenten halten, wie es in Fig. 4 dargestellt ist. Diese Objekte 32, 34A, 34B und 34C sind in einem verteilten Namensraum 28 sichtbar. Jedes der Datenverarbeitungssysteme 11A, 11 B, 11 C und 11 D (Fig. 1) in dem verteilten System 10 hat Zugriff auf die Objekte in dem verteilten Namensraum 28 (Fig. 4). Der verteilte Namensraum 28 umfaßt auch Objekte 30A, 30B, 30C und 30D, die die Datenverarbeitungssysteme 11A, 11 B, 11 C bzw. 11 D modellieren.
Das Dateiserverobjekt 32 ist ein "Behälter". Ein Behälter ist eine Gesamtheit, die andere Objekte enthält. Bei dem Beispiel der Fig. 4 ist das Dateiserverobjekt 32 ein Behälter, der Objekte 34A, 34B und 34C für die entsprechenden Unterkomponenten des Dateiservers 26 enthält. Daher kann eine verwaltete Komponente als ein Behälterobjekt modelliert werden, das Objekte für die Unterkomponenten des verwalteten Objekts hält.
Das Dateiserverobjekt 32 ist auch ein spezieller Typ eines Objekts, das als ein Verknüpfungspunkt bekannt ist und sich von anderen Objekten in dem verteilten Namens raum 28 unterscheidet. Ein Verknüpfungspunkt ist ein Objekt, das als eine Verknüpfung zwischen zwei Namensräumen dient. Das Dateiserverobjekt 32 ist ein Verknüpfungspunkt, der den verteilten Namensraum mit dem Namensraum der Unterkomponentenobjekte 34A, 34B und 34C verbindet. Zugriff auf die Unterkomponentenobjekte 34A, 34B und 34C kann durch das Dateiserver-Behälterobjekt 32 vorgenommen werden. Jedes der Unterkomponentenobjekte 34A, 34B und 34C unterstützt eine Schnittstelle, um ihr Verhalten zu überwachen und zu verwalten. Des weiteren hält jedes der Unterkomponentenobjekte 34A, 34B und 34C Zustandsinformationen in bezug auf die entsprechende Unterkomponente, die mit dem Objekt verbunden ist. Diese Zustandsinformationen werden in Eigenschaftssätzen gehalten, die in den Unterkomponentenobjekten 34A, 34B und 34C gespeichert sind, die abgefragt werden können, um die in ihnen enthaltenen Zustandsinformationen zu erhalten.
Der Verknüpfungspunkt für das Dateiserverobjekt 32 speichert eine global einzigartige Kennung ID (GUID) für das Dateiserverobjekt 32. Diese GUID wird verwendet, um eindeutig das Dateiserverobjekt 32 in dem verteilten Namensraum 28 zu erkennen. Zusätzlich wird eine laufende Fernprozedurruf-(RPC)-Adresse für einen "Agenten" des Dateiservers 26 in dem Dateiserverobjekt 32 gespeichert. Der Agent ist ein Körper eines Bibliothekscodes, der von dem Betriebssystem 24 bereitgestellt wird und mehreren Zwecken dient, einschließlich der Herstellung von Unterkomponentenobjekten 34A, 34B und 34C, die in dem verteilten globalen Namensraum 28 sichtbar sind. Der Agent liefert auch einen Prozedurfernaufruf-(RPC)-Server, um Prozedurfernaufrufe im Auftrag des Dateiservers und seiner Unterkomponenten herzustellen. Es gibt eine unmittelbare eins-zueins Entsprechung zwischen einer verwalteten Komponente, wie dem Dateiserver, und ihrem Agenten. Das Betriebssystem 24 liefert Anwendungsprogrammschnittstellen (A- Pls), um dem Benutzer zu ermöglichen, einen neuen Agenten zu erzeugen, Objekte für verwaltete Komponenten und Unterkomponenten zu erzeugen, Objekte für verwaltete Komponenten und Unterkomponenten zu entfernen und eine Antwort auf Operationen an verwalteten Komponenten und Unterkomponenten zu liefern. Der Agent kann Werte ausgewählter Eigenschaften eines verwalteten Objekts wiedergewinnen, und der Agent kann die Werte der Eigenschaften abändern, die in verwalteten Objekten gehalten sind.
Unter Rückkehr zu dem Beispiel der Fig. 4 sei angenommen, daß das Datenverarbeitungssytem 11A Zugriff auf das Unterkomponentenobjekt 34B des Requesterprozessors sucht. Fig. 5 zeigt ein Flußdiagramm der Schritte, die durchgeführt werden, um Zugriff auf die Zustandsinformationen zu erhalten, die in dem Requesterprozessorobjekt 34B gehalten sind. Anfangs verlangt das Datenverarbeitungssystem 11A Zugriff auf dis Zustandsinformationen, die in dem Unterkomponentenobjekt 34B des Requesterprozessors gehalten sind (Schritt 40 in Fig. 5). Das Betriebssystem 24 (Fig. 2) erkennt, daß das Unterkomponentenobjekt 34B des Requesterprozessors ein Fernobjekt ist, das in dem Datenverabeitungssystem 11 B gespeichert ist. Als Ergebnis wird der Agent für die Unterkomponentenobjekte 34A, 34B und 34C in dem Datenverarbeitungssystem 11 B aufgerufen, wobei eine RPC-Einrichtung verwendet wird, die als Teil des Betriebssystems 24 vorgesehen ist. Der Agent lädt seinerzeit Prozedurfernaufruf-(RPC)-Anzapfroutinen (stub routines), die Daten packen und die RPC-Einrichtung verwenden, den RPC-Aufruf zu dem Datenverarbeitungssystem 11 B durchzuführen. Zwei Sätze Anzapfroutinen werden geladen.
Zuerst wird ein Satz Anzapfroutinen bei dem Datenverabeitungssystem 11A geladen, um den RPC-Aufruf zu machen, und zweitens wird ein Satz Anzapfroutinen bei dem Datenverarbeitungssystem 11 B geladen, um den Rückruf auf das Datenverarbeitungssystem 11A herzustellen (Schritt 42 in Fig. 5). Die RPC-Anzapfroutinen bei dem Datenverarbeitungssytem 11A werden dann ausgeführt, um den RPC-Server des Agenten aufzurufen, der den RPC-Aufruf durchführt (Schritt 44). Die Zustandsinformationen werden örtlich bei dem Datenverarbeitungssytem 11 B abgefragt (Schritt 46 in Fig. 5). Die Zustandsinformationen werden abgefragt, indem zuerst ein Moniker für eine Schnittstelle gefunden wird, die von dem Unterkomponentenobjekt 34B des Requesterprozessors unterstützt wird (Fig. 4) und die die Abfrage der Zustandsinformationen ermöglicht, die in dem Unterkomponentenobjekt des Requesterprozessors gehalten sind. Dieser Moniker wird unter Verwendung der Querylnterface() Funktion erhalten.
Jedes Objekt in dem verteilten Namensraum 28 muß nach Definition die IUnknown Schnittstelle unterstützen (d. h., alle Objekte unterstützen Schnittstellen, die die I- Unknown Schnittstelle erben). Die IUnknown Schnittstelle umfaßt die Funktion Querylnterface(), um abzufragen, ob ein Objekt eine bestimmte Schnittstelle unterstützt. Die Querylnterfacefunktion() kehrt zurück, um einen Zeiger zu dem Code zur Ausführung der Funktionen zu erhalten. Im allgemeinen muß, wenn immer eine Funktion aufgerufen wird, die Teil einer Schnittstelle ist, die von einem Objekt unterstützt wird, die Querylnterfacefunktion() zuerst aufgerufen werden.
Der durch den Aufruf der Querylnterfacefunktion() erhaltene Moniker zeigt zu einer Stelle der Schnittstelle, die von dem Unterkomponentenobjekt 34B des Requesterprozessors unterstützt wird (Fig. 4). Der Moniker wird dann verwendet, auf Funktionen zuzugreifen, um Zustandsinformationen abzufragen, die in dem Unterkomponentenobjekt 348 des Requesterprozessors gehalten sind.
Sobald die Zustandsinformationen lokal an dem Datenverarbeitungssystem 11 B erhalten worden sind, wird ein Rückaufruf zu dem Datenverarbeitungssystem 11 A gemacht, wobei die RPC-Anzapfroutinen verwendet werden, die früher geladen worden sind (Schritt 48 in Fig. 5). Das Datenverarbeitungssystem 11A erhält dann die Zustandsinformationen und verwendet die Zustandsinformationen für Systemverwaltungsfunktionen (Schritt 50 in Fig. 5).
Das oben beschriebene Beispiel stellt dar, wie die bevorzugte Ausführungsform der vorliegenden Erfindung die Systemverwaltungsaufgaben erleichtert. Insbesondere schließt die bevorzugte Ausführungsform Zustandsinformationen für verwaltete Komponenten in Objekte ein, die in dem verteilten Namensraum sichtbar sind, so daß ein Fernzugriff auf die Zustandsinformationen möglich ist. Des weiteren können, da die Zustandsinformationen in das unterliegende Systemobjektmodell integriert sind, die Objekte, die Zustandsinformationen halten, verarbeitet und verwaltet werden, wobei Werkzeuge eingesetzt werden, die bei allen Arten von Objekten verwendet werden können.
Das Betriebssystem 24 der bevorzugten Ausführungsform der vorliegenden Erfindung liefert zumindest zwei Arten "Instrumente". Instrumente sind Variable, deren Wert in dem verteilten Namensraum 28 sichtbar ist. Fig. 6 ist ein Flußdiagramm, das zeigt, wie Instrumente bei der bevorzugten Ausführungsform der vorliegenden Erfindung verwendet werden. Anfangs wird eine Variable als ein Instrumente innerhalb eines Anwendungsprogramms erklärt (Schritt S2 in Fig. 6). Das Anwendungsprogramm ordnet dann dem Instrument einen Wert während seiner Ausführung zu (Schritt S4). Der dem Instrumente zugeordnete Wert wird in einem entsprechenden Objekt eingeschlossen, das in dem verteilten Namensraum 28 sichtbar ist (Schritt S6). Entsprechend kann der Wert des Instruments erhalten werden, indem das entsprechende Objekt abgefragt wird.
Instrumente stehen in drei Arten zur Verfügung. Ein Benutzer spezifiziert mit der Erklärung des Typs der Variablen, welche Art Instrument er wünscht. Eine erste Art Instrument ist ein Zähler. Der Zähler wirkt in einer einem Wegstreckenmesser entsprechenden Weise dahingehend, daß sein Wert stets zunimmt, bis er zurückgesetzt wird. Ähnlich ist eine zweite Art Instrument ein Meßinstrument, das wie ein Meßgerät wirkt, das zwischen einem Bereich von Werten schwanken kann.
Die bevorzugte Ausführungsform der vorliegenden Erfindung schafft auch einen zusätzlichen Mechanismus, um Zustandsinformationen in dem verteilten Namensraum 28 anzuordnen. Dieser Mechanismus ist als Arbeitsstations-Verwaltungsagent bekannt. Der Arbeitsstations-Verwaltungsagent gibt den gegenwärtigen Zustand einer Arbeitsstation in den verteilten globalen Namensraum 28.
Während die vorliegende Erfindung unter Bezugnahme auf eine bevorzugte Ausführungsform von ihr beschrieben worden ist, erkennt der Durchschnittsfachmann auf dem Gebiet nichtsdestotrotz, daß verschiedene Abänderungen in der Form und bei Einzelheiten vorgenommen werden können, ohne von der vorliegenden Erfindung abzuweichen, wie sie in den beigefügten Ansprüchen definiert ist. Beispielsweise muß die vorliegende Erfindung keine Schnittstellen oder Moniker verwenden, vielmehr können andere alternative Mechanismen verwendet werden.

Claims

1. Verfahren zum Betreiben eines verteilten Systems, wobei das verteilte System (10) eine Speichereinrichtung (16) zur Speicherung von Objekten, einen Prozessor (14) zur Ausführung eines Prozesses und eine verwaltete Komponente mit einem internen Zustand aufweist, wobei das Verfahren die Schritte umfaßt:

Herstellen von Objekten in einem verteilten Namensraum (28), der für den Prozeß sichtbar ist, gekennzeichnet durch

Speichern des internen Zustands der verwalteten Komponente als ein Objekt in der Speichereinrichtung (16); und

Zugreifen auf das Objekt, um Zugriff auf den internen Zustand der durch den Prozeß verwalteten Komponente zu erhalten.

2. Verfahren, wie in Anspruch 1 beansprucht, wobei das Objekt eine Schnittstelle zum Zugreifen auf das Objekt unterstützt.

3. Verfahren, wie in Anspruch 1 oder 2 beansprucht, wobei das Objekt eine Schnittstelle zur Abfrage unterstützt, ob das Objekt eine bestimmte Schnittstelle unterstützt, wobei die Schnittstelle als eine IUnknown Schnittstelle bezeichnet wird.

4. Verfahren, wie in einem der Ansprüche 1 bis 3 beansprucht, wobei das Objekt eine Schnittstelle zum Binden eines Monikers an das Objekt unterstützt, die Schnittstelle als IMoniker Schnittstelle bezeichnet wird und der Moniker einen Zeiger zu einem Objekt umfaßt.

5. Verfahren, wie in einem der Ansprüche 1 bis 4 beansprucht, das des weiteren den Schritt umfaßt: Speichern eines Systemverwaltungsobjekts zur Verwaltung der verwalteten Komponente in der Speichereinrichtung (16).

6. Verfahren, wie in Anspruch 5 beansprucht, das des weiteren den Schritt umfaßt: Verwalten der verwalteten Komponente unter Verwendung des Systemverwaltungsobjekts.

7. Verfahren, wie in einem der Ansprüche 1 bis 6 beansprucht, das des weiteren den Schritt umfaßt: Bereitstellen eines Namensdienstes zur Organisation der Namen von Objekten in dem verteilten Namensraum (28).

8. Verfahren, wie in einem der Ansprüche 1 bis 7 beansprucht, das des weiteren die Schritte umfaßt:

Unterteilen der verwalteten Komponente in mehrere Unterkomponenten, wobei jede Unterkomponente einen internen Zustand aufweist; und

Speichern des internen Zustands einer jeden Unterkomponente in einem getrennten Objekt in der Speichereinrichtung (16), wobei jedes Objekt in dem verteilten Namensraum (28) für den Prozeß sichtbar ist.

9. Verfahren, wie in Anspruch 8 beansprucht, das des weiteren die Schritte umfaßt: Einschließen der Objekte, die die internen Zustände der Unterkomponenten speichern, in das Objekt, das den internen Zustand der verwalteten Komponente speichert, so daß auf die Objekte, die die internen Zustände der Unterkomponenten speichern, durch das Objekt zugegriffen werden kann, das den internen Zustand der verwalteten Komponente speichert.

10. Verfahren, wie in einem der Ansprüche 1 bis 8 beansprucht, wobei das verteilte System (10) des weiteren eine zweite, verwaltete Komponente mit einem internen Zustand umfaßt, und das Verfahren des weiteren den Schritt umfaßt: Speichern des internen Zustands der zweiten, verwalteten Komponente als ein Ob jekt in der Speichereinrichtung (16), wobei das Objekt in dem verteilten Namensraum (28) für den Prozeß sichtbar ist.

11. Verfahren, wie in einem der Ansprüche 1 bis 10 beansprucht, wobei das verteilte System (10) des weiteren umfaßt:

eine Prozedurfernaufrufeinrichtung,

ein erstes Datenverarbeitungssystem (11), das den Prozessor (14) umfaßt, und ein zweites Datenverarbeitungssystem (11), das die Speichereinrichtung (16) umfaßt; und wobei das Verfahren des weiteren die Schritte umfaßt:

Verlangen von Zugriff auf den internen Zustand der Komponente in dem Prozeß, und

Durchführen eines Prozedurfernaufrufs in Antwort auf den Schritt der Zugriffsanforderung, wobei die Prozedurfernaufrufeinrichtung verwendet wird, um den Schritt des Zugriffs auf das Objekt im Auftrag des Prozesses durchzuführen.

12. Verfahren, wie in einem der Ansprüche 1 bis 11 beansprucht,

wobei die verwaltete Komponente ein Programm ist, und

das Verfahren des weiteren die Schritte umfaßt:

Erklären einer Variablen in dem Programm als eine Variable, auf die in dem verteilten Namensraum (28) zugreifbar ist,

Durchführen des Programms, so daß der Variablen ein Wert zugeordnet wird, und Speichern des Werts der Variablen in dem Objekt.

13. Verfahren, wie in Anspruch 12 beansprucht, wobei die Variable ein Zähler ist, und der Schritt, das Programm durchzuführen, des weiteren den Schritt umfaßt: Erhöhen der Variablen um eine vorbestimmte Größe.

14. Verfahren, wie in Anspruch 12 oder 13 beansprucht, wobei der Schritt, das Programm durchzuführen, des weiteren den Schritt umfaßt: Zuordnen eines Werts der Variablen, der den Zustand des Programms spezifiziert.

15. Verfahren, wie in einem der Ansprüche 1 bis 10 beansprucht, wobei die verwaltete Komponente ein Datenverarbeitungsbetriebsmittel ist, und das Verfahren des weiteren den Schritt umfaßt: Modellieren, des Datenverarbeitungsbetriebsmittels als ein Objekt.

16. Verfahren, wie in Anspruch 15 beansprucht, wobei das Datenverarbeitungsbetriebsmittel eine Hardwarekomponente umfaßt.

17. Verfahren, wie in Anspruch 15 oder 16 beansprucht, wobei das Datenverarbeitungsbetriebsmittel eine Softwarekomponente umfaßt.

18. Computerlesbares Medium, das Befehle zur Ausführung des computerisierten Verfahrens umfaßt, wie es in einem der Ansprüche 1 bis 17 beansprucht ist.

19. Verteiltes System (17) mit einer Einrichtung zur Herstellung von Objekten in einem verteilten Namensraum (28), der für einen Prozeß sichtbar ist, gekennzeichnet durch

eine Speichereinrichtung (16) zur Speicherung von Objekten,

einen Prozessor (14) zur Ausführung des Prozesses,

eine verwaltete Komponente mit einem internen Zustand,

eine Einrichtung zur Speicherung des internen Zustands der verwalteten Komponente als ein Objekt in der Speichereinrichtung (16) und

eine Einrichtung zum Zugreifen auf das Objekt, um durch den Prozeß Zugriff auf den internen Zustand der verwalteten Komponente zu erlangen.

20. Verteiltes System (10), wie in Anspruch 19 beansprucht, wobei das Objekt eine Schnittstelle zum Zugreifen auf das Objekt unterstützt.

21. Verteiltes System (10), wie in Anspruch 19 oder 20 beansprucht, wobei das Objekt eine Schnittstelle zur Abfrage unterstützt, ob das Objekt eine bestimmte Schnittstelle unterstützt, wobei die Schnittstelle als eine IUnknown Schnittstelle bezeichnet wird.

22. Verteiltes System (10), wie in einem der Ansprüche 19 bis 21 beansprucht, wobei das Objekt eine Schnittstelle zum Binden eines Moniker an das Objekt unterstützt, die Schnittstelle als IMoniker Schnittstelle bezeichnet wird und der Moniker einen Zeiger zu einem Objekt umfaßt.

23. Verteiltes System (10), wie in einem der Ansprüche 19 bis 22 beansprucht, weiterhin umfassend: eine Einrichtung zur Speicherung eines Systemverwaltungsobjekts zur Verwaltung der verwalteten Komponente in der Speichereinrichtung (16).

24. Verteiltes System (10), wie in Anspruch 23 beansprucht, das des weiteren eine Einrichtung zur Verwaltung der verwalteten Komponente unter Verwendung des Systemverwaltungsobjekts umfaßt.

25. Verteiltes System (10), wie in einem der Ansprüche 19 bis 24 beansprucht, das des weiteren eine Einrichtung (24) umfaßt, einen Namensdienst zur Organisation der Namen von Objekten in dem verteilten Namensraum (28) bereitzustellen.

26. Verteiltes System (10), wie in einem der Ansprüche 19 bis 25 beansprucht, das des weiteren umfaßt,

eine Einrichtung zum Unterteilen der verwalteten Komponente in mehrere Unterkomponenten, wobei jede Unterkomponente einen internen Zustand aufweist; und

eine Einrichtung zum Speichern des internen Zustands einer jeden Unterkomponente in einem getrennten Objekt in der Speichereinrichtung (16), wobei jedes Objekt in dem verteilten Namensraum (28) für den Prozeß sichtbar ist.

27. Verteiltes System (10), wie in Anspruch 26 beansprucht, das des weiteren eine Einrichtung zum Einschließen der Objekte, die die internen Zustände der Unterkomponenten speichern, in dem Objekt umfaßt, das den internen Zustand der verwalteten Komponente speichert, so daß auf die Objekte, die die internen Zustände der Unterkomponenten speichern, durch das Objekt zugegriffen werden kann, das den internen Zustand der verwalteten Komponente speichert.

28. Verteiltes System (10), wie in einem der Ansprüche 19 bis 27, das des weiteren eine zweite, verwaltete Komponente mit einem internen Zustand und eine Einrichtung umfaßt, den internen Zustand der zweiten, verwalteten Komponente als ein Objekt in der Speichereinrichtung (16) zu speichern, wobei das Objekt in dem verteilten Namensraum (28) für den Prozeß sichtbar ist.

29. Verteiltes System (10), wie in einem der Ansprüche 19 bis 28 beansprucht, das des weiteren umfaßt:

eine Prozedurfernaufrufeinrichtung,

ein erstes Datenverarbeitungssystem (11), das den Prozessor (14) umfaßt,

ein zweites Datenverarbeitungssystem (11), das die Speichereinrichtung (16) umfaßt;

eine Einrichtung zur Zugriffsanforderung in dem Prozeß auf den internen Zustand der Komponente; und

eine Einrichtung zur Ausführung eines Prozedurfernaufruf in Antwort auf die Einrichtung zur Zugriffsanforderung, wobei die Prozedurfernaufrufeinrichtung verwendet wird, die Einrichtung zum Zugreifen auf das Objekt im Auftrag des Prozesses zu betreiben.

30. Verteiltes System (10), wie in einem der Ansprüche 19 bis 29 beansprucht, bei dem

die verwaltete Komponente ein Programm ist, und

das Verteiltes System (10), des weiteren umfaßt:

eine Einrichtung zum Erklären einer Variable in dem Programm als eine Variable, auf die in dem verteilten Namensraum (28) zugreifbar ist,

eine Einrichtung zur Ausführung des Programms, so daß der Variablen ein Wert zugeordnet wird, und

eine Einrichtung zum Speichern des Werts der Variablen in dem Objekt.

31. Verteiltes System (10), wie in Anspruch 30 beansprucht, wobei

die Variable ein Zähler ist, und

die Einrichtung zur Ausführung des Programms des weiteren eine Einrichtung umfaßt, die Variable um einen vorbestimmten Wert zu erhöhen.

32. Verteiltes System (10), wie in Anspruch 30 oder 31 beansprucht, wobei die Einrichtung zur Ausführung des Programms des weiteren eine Einrichtung umfaßt, einen Wert, der den Zustand des Programms spezifiziert, der Variablen zuzuordnen.

33. Verteiltes System (10), wie in einem der Ansprüche 19 bis 29 beansprucht, wobei die verwaltete Komponente ein Datenverarbeitungsbetriebsmittel ist, und das Verteiltes System (10), des weiteren eine Einrichtung umfaßt, das Datenverarbeitungsbetriebsmittel als ein Objekt zu modellieren.

34. Verteiltes System (10), wie in Anspruch 33 beansprucht, wobei das Datenverarbeitungsbetriebsmittel eine Hardwarekomponente umfaßt.

35. Verteiltes System (10), wie in Anspruch 33 oder 34 beansprucht, wobei das Datenverarbeitungsbetriebsmittel eine Softwarekomponente umfaßt.