DE69112156T2

DE69112156T2 - Gerät zur Realisierung von Datenbanken zum Verschaffen von objektorientiertem Aufrufen von Anwendungsprogrammen.

Info

Publication number: DE69112156T2
Application number: DE69112156T
Authority: DE
Inventors: Alan N Ewald; Neal F Jacobson; Michael J Renzullo; Robert L Travis; Andrew P Wilson
Original assignee: Digital Equipment Corp
Current assignee: BEA Systems Inc
Priority date: 1990-08-14
Filing date: 1991-07-08
Publication date: 1996-06-13
Anticipated expiration: 2011-07-09
Also published as: AU7930991A; CA2049133C; EP0472279B1; AU638138B2; JP2842714B2; JPH0675846A; DE69112156D1; EP0472279A2; EP0472279A3; CA2049133A1; US5280610A

Description

I. Verwandte Patentanmeldungen

Diese Patentanmedung bezieht sich auf EP_A_0 474 340 mit dem Titel "Methoden und Vorrichtung zum Bereitstellen eines dynamischen Aufrufs von Anwendungen in einer verteilten heterogenen Umgebung", EP_A_0 474 339 mit dem Titel "Methoden und Vorrichtung zum Bereitstellen einer Client-Schnittstelle für einen objektorientierten Aufruf einer Anwendung" und EP_A_0 471 442 mit dem Titel "Methoden und Vorrichtung zum Realisieren von Server-Funktionen in einer verteilten heterogenen Umgebung", alle am gleichen Tag eingereicht, wie diese Patentanmeldung.

II. Hintergrund der Erfindung

Diese Erfindung bezieht sich auf die Wechselwirkung von Computeranwendungen in einem heterogenen Datenverarbeitungsnetzwerk. Genauer gesagt bezieht sich diese Erfindung auf die Organisation eines Datenverarbeitungsnetzwerks gemäß einem objektorientierten Modell und der Wechselwirkung von unabhängigen Anwendungen in einer solchen heterogenen Netzwerkumgebung.
Computer kommunizieren über Datenverarbeitungsnetzwerke miteinander. Die Computer selbst werden allgemein als "Knoten" bezeichnet, und ein spezifischer Typ von Computer, d.h. ein spezifischer Typ von Hardware, die einen spezifischen Typ von Betriebssystem verwendet, wird als "Plattform" bezeichnet. Netzwerke, die verschiedene Typen von Plattformen enthalten, werden "heterogene Netzwerke" genannt. Ein Grund für das Verbinden von Plattformen in einem Netzwerk ist, verschiedene Umgebungen zu schaffen, um in diesen Anwendungsprogramme (zur Abkürzung mit "Anwendungen" bezeichnet) mit miteinander geteilten Daten auszuführen.
In dem typischen Datenverarbeitungsnetzwerk speichern verschiedene Plattformen und Anwendungen, die auf verschiedenen Plattformen ablaufen, Informationen in ihrer eigenen, spezifischen Weise. Z. B. können auf einer VAX.VMS-Plattform textverarbeitende Aufgaben durch die Verwendung eines TPU-Texteditors ausgeführt werden, während auf einer MIPS.ULTRIX-Plattform textverarbeitende Aufgaben durch die Verwendung eines EMACS-Texteditors ausgeführt werden können. Benutzer eines Netzwerks, das beide Plattformen hat, können sich wünschen, Operationen von den verschiedenen Texteditoren auf den verschiedenen Plattformen zu benutzen, ohne die Details dieser Plattformen und Texteditoren kennen zu müssen.
Diese Kompatibilität war früher nicht möglich. Statt dessen fordern herkömmliche Netzwerke vom Benutzer eines heterogenen Netzwerks die Verwendung der speziellen Schnittstelle, die jede Anwendung für Operationen auf speziellen Plattformen benötigt. Konventionelle Netzwerke versagen beim Schaffen der Fähigkeit für Benutzer, zwischen Anwendungen zu kommunizieren, die eine Standardschnittstelle verwenden.
Als Beispiel der Schwierigkeiten bei Zwischenprogramm-Kommunikation in einem konventionellen heterogenen Netzwerk sei angenommen, der Benutzer einer Texteditor-Anwendung auf einer Plattform möchte auf einen Mehrfachbenutzer-Datenbank-Abfragedienst zugreifen, wie z. B. auf DIALOG für wissenschaftliche Artikel oder auf LEXIS für Gerichtsurteile auf einer anderen Plattform. Um dies auf einem herkömmlichen Netzwerk zu erreichen, müßte die Funktion der Texteditor-Anwendung unterbrochen werden, und der Datenbank-Abfragedienst müßte unter Verwendung der für den Datenbank-Abfragedienst spezifischen Befehle und Informationen aufgerufen werden. Der Benutzer müßte nicht nur die spezifischen Namen jedes gewünschten Dienstes kennen, sondern er müßte auch die Speicherstelle des Dienstes in dem Netzwerk kennen und mit den verschiedenen Befehlen und Befehlsformaten vertraut sein, die von jedem Dienst verwendet werden.
Der Artikel "Work-station LAN masters many operating systems" von Bruce Hamilton et al., ELECTRONIC DESIGN, Vol. 31, Nr. 26, Dez. 1983, HASBROUCK HEIGHTS, New Jersey US, Seite 127 - 135 beschreibt einen "Manager einer globalen Umgebung" GEM, der Arbeitsplatzrechner verbindet, die mit verschiedenen Betriebssystemen in einer virtuellen Computereinrichtung betrieben werden. Das Netzwerksystem ist auf ein objektorientiertes Konzept des GEM angewiesen, welches die Betriebsmittel wie Speicherplatz, Netzwerkverkehr und Verarbeitungseinheiten steuert und überwacht GEM könnte als ein Betriebssystem für Betriebssysteme betrachtet werden, das eine einheitliche Schnittstelle für alle Netzwerk-Betriebsmittel liefert.
GEM definiert jedes Systembetriebsmittel als eigenes Objekt, das als abstrakte Vorrichtung zum Identifizieren und Behandeln sowohl von Daten als auch von Programmen, welche die Betriebsmittel definieren, dient. Objekte korrespondieren mit physikalischen oder abstrakten Betriebsmitteln, mit Verzeichnissen, Dateien und laufenden Programmen, die in der letzten Gruppe betrachtet werden. Weil Geräte als Objekte betrachtet werden, werden ihnen auch eigene Kennungen zugeordnet.
Methoden in dem GEM-System arbeiten in Datenstrukturen, die mit den verschiedenen Objekten verknüpft sind. All die Methoden für einen bestimmten Typ von Objekt gehören zu der gleichen Klasse.
Um an einem Betriebsmittel zu arbeiten, wird eine Nachricht an sein typisches Objekt geschickt (siehe Fig. 2). Die Nachricht enthält den Namen der Funktion (z. B. Lesen) und den Namen des Zielobjekts (z.B. Datei X). Der Sender muß nur den Namen des Objekts kennen, nicht seine Klasse oder seinen physikalischen Speicherplatz.
Wenn eine Nachricht an ein Objekt gesendet wird, startet es in der Nachrichtentabelle eine Suche nach der Klasse des Objekts und liefert eine entsprechende Methode für die Ausführung.
Dennoch ist noch keine Standardschnittstelle entwickelt worden, um eine Anwendung auf einer Plattform zu ermöglichen, die eine Anwendung auf einer anderen Plattform in einem heterogenen Netzwerk auf eine wirkungsvolle und unkomplizierte Weise aufruft. Tatsächlich bewirkt eine herkömmliche Zwischenprogramm-Kommunikation lediglich Einrichtungen für den physikalischen Transport von Nachrichten und Daten zwischen den Anwendungen.
Ein Beispiel einer Einrichtung, die gegenwärtig verwendet wird, um einer Anwendung auf einer Plattform zu ermöglichen, mit einer Anwendung auf einer anderen Plattform zu kommunizieren, ist ein Fern-Prozedur-Aufruf-(RPC)System. Ein RPC- System auf einer Plattform reagiert auf Anfragen einer "aufrufenden" Anwendung zunächst durch Übersetzen der Nachrichten dieser Anwendung in ein Netzwerk-Datenformat und dann durch Übertragen der übersetzten Anfragen über das Netzwerk zu einer Empfangsplattform. Auf der Empfangsplattform decodiert eine andere Komponente des RPC-Systems die übersetzten Nachrichten in Anfragen in einem für die aufgerufene Anwendung annehmbaren Datenformat. Die Originalmeldungen von der aufrufenden Plattform müssen jedoch zu einer Syntax passen, die von der aufgerufenen Anwendung vorgeschrieben ist.
Eine andere Schwierigkeit entsteht bei konventionellen Netzwerken, wenn die Anwendung an einem entfernten Knoten nicht momentan geladen und in Betrieb ist. Viele RPC-Systeme ermöglichen nur den Fernaufruf von Anwendungen, die schon geladen und in Betrieb sind. Wenn dies nicht der Fall ist, muß der Benutzer der Client-Anwendungen irgendeinen Weg finden, die Server-Anwendung auf die Fern- Plattform zu laden, bevor er sie aufruft. Dies kann sehr einschränkend sein.
Ein Hindernis, ein netzwerkumspannendes System zu realisieren, um die Zwischenprogramm-Kommunikation zu erleichtern, war die große Menge von Systembetriebsmitteln, welche als für ein System erforderlich gehalten wurden, um all die verschiedenen Arten von Daten, Funktionen und Anwendungen in einem Netzwerk zu bearbeiten. Wenn ein Netzwerk sich vergrößert, würden die Systeme, Betriebsmittel und Anforderungen ebenso anwachsen und viele vorgeschlagene Realisierungen völlig unhandlich machen.
Daher ist eine wirkungsvolle und einfache Art nötig, damit Anwendungen auf verschiedenen Plattformen miteinander kommunizieren, wie z. B. über eine einheitliche und passende Schnittstelle für die Anwendungen. Es ist auch eine dynamische Aufrufumgebung für Anwendungen in einer verteilten heterogenen Umgebung notwendig.

III. Zusammenfassung der Erfindung

Um diese Notwendigkeit zu erreichen, sieht die vorliegende Erfindung eine Wechselwirkung von Operationen in einer objektorientierten Weise vor, durch welche ein System eher "Klassen" von Datenbeispielen und Anwendungen behandelt, als die Daten selbst zu behandeln. Die Behandlung solcher Klassen schließt eine Datenbank ein, welche Informationen über die Klassen enthält, wie z. B. bestimmte gemeinsame Attribute von Anwendungen oder Instanzen, welche von den Klassen unterstützt werden.
Client-Anwendungen können andere Anwendungen durch Senden von global (d. h. netzwerkumspannend) erkannten Nachrichten mit Parametern von fern aufrufen. Durch Benutzen sowohl der Nachrichtennamen als auch der Informationen über die Klassen bestimmter Parameter wird von der Datenbank ein Verweis auf eine spezifische Methode ausgewählt. Diese Methode wird die Operation ausführen, die in der Nachricht spezifiziert ist. Andere Informationen in der Datenbank werden dann verwendet, um den tatsächlichen Code zu lokalisieren und auszuführen, um die erwähnte Methode zu realisieren.
Insbesondere in einem Speicher, der in einem Datenverarbeitungsnetzwerk resident ist, welches einen Fernaufruf von Anwendungen ermöglicht, umfaßt eine Klassen-Datenbank zur Verwendung in dem Datenverarbeitungsnetzwerk Methodeneinträge, von denen jeder einen Verweis auf einen entsprechenden Aufrufbefehl zum Aufrufen von einer der Anwendungen enthält; Nachrichteneinträge, die Informationen für eine Mehrzahl von Nachrichten enthalten, wobei jede der Nachrichten die Arten von Operationen spezifiziert, welche an den Instanzen in einer entsprechenden einer Vielzahl von Klassen ausgeführt werden können, wobei jeder der Nachrichteneinträge eine Identifizierung einer entsprechenden Gruppe der Methodeneinträge enthält; und eine Vielzahl von Klasseneinträgen, von denen jede Informationen für eine andere, eindeutig identifizierbare Klasse enthält, wobei die Klassen Arten der Instanzen identifizieren, welche wiederum Elemente sind, die von den Anwendungen manipuliert werden können, oder auf die von den Anwendungen zugegriffen werden kann, entsprechend gemeinsamer Eigenschaften, wobei jeder der Klasseneinträge eine Identifizierung einer entsprechenden Gruppe der Nachrichteneinträge enthält.
Ein Verfahren zum Modifizieren der Klassen-Datenbank für eine neue Anwendung arbeitet gemäß dieser Erfindung in einem Datenverarbeitungsnetzwerk, das eine Klassen-Datenbank zur Verwendung für das Ermöglichen eines Fernaufrufs von Anwendungen hat. Die Klassen-Datenbank ist im Speicher in dem Datenverarbeitungsnetzwerk resident und enthält eine Vielzahl von Klasseneinträgen, die Informationen für eine Vielzahl von eindeutig identifizierbaren Klassen enthält, wobei die Klassen Arten von Instanzen identifizieren, welche wiederum die Elemente sind, welche manipuliert werden können oder auf welche von den Anwendungen zugegriffen werden kann, gemäß gemeinsamer Eigenschaften. Jeder der Klasseneinträge enthält eine Identifizierung einer entsprechenden Gruppe von Nachrichteneinträgen, und die Nachrichteneinträge enthalten Informationen für eine Vielzahl von Nachrichten, wobei jede der Nachrichten die Arten von Operationen spezifiziert, welche an Instanzen in den entsprechenden Klassen durchgeführt werden können. Jeder der Nachrichteneinträge enthält eine Identifizierung einer entsprechenden Gruppe von Methodeneinträgen, die Hinweise auf Aufrufbefehle enthält, um die Anwendungen aufzurufen. Die Anwendung enthält eine Vielzahl von Nachrichten, und das Verfahren enthält folgende Schritte, die von dem Datenverarbeitungsnetzwerk durchgeführt werden: Finden des entsprechenden Klasseneintrags für jede der Nachrichten für die neue Anwendung; Hinzufügen eines Nachrichteneintrags zu jedem entsprechenden Klasseneintrag, der eine Identifizierung der entsprechenden Nachricht enthält; und Hinzufügen von Identifikationen für Methodeneinträge zu jedem Nachrichteneintrag für die Nachricht, die dem Nachrichteneintrag entspricht.
Die begleitenden Zeichnungen, welche in dieser Beschreibung enthalten sind und einen Teil von dieser Beschreibung darstellen, zeigen eine Realisierung der Erfindung und erklären, zusammen mit der Beschreibung, die Prinzipien der Erfindung.

IV. Kurze Beschreibung der Zeichnungen

Fig. 1 ist ein Diagramm eines Netzwerks, welches in einer bevorzugten Realisierung der vorliegenden Erfindung verwendet werden kann.
Fig. 2 ist eine Abbildung der Hauptkomponenten eines objektorientierten Musters dieser Erfindung in Beziehung zu einer Anwendung.
Fig. 3 ist eine Abbildung der Beziehungen zwischen den Komponenten des objektorientierten Musters dieser Realisierung der vorliegenden Erfindung.
Fig. 4 ist eine Abbildung der Beziehungen zwischen Beispielen der Komponenten des objektorientierten Musters dieser Erfindung.
Fig. 5 ist eine Abbildung einer Struktur für eine Klassen-Datenbank gemäß der bevorzugten Realisierung und passend zu den Beziehungen, die in Fig. 4 gezeigt sind.
Fig. 6 ist ein Diagramm der verschiedenen Komponenten der bevorzugten Realisierung und des bevorzugten Verlaufs von Informationen zwischen diesen Komponenten.
Fig. 7 ist ein Diagramm, welches die Beziehungen der verschiedenen Speichersysteme untereinander in der bevorzugten Realisierung zeigt.
Fig. 8 ist ein Diagramm einer bevorzugten Struktur einer lokalen Klassen- Datenbank.
Fig. 9 ist ein Diagramm einer bevorzugten Realisierung eines Blocks in der lokalen Klassen-Datenbank, die in Fig. 8 gezeigt ist.
Fig. 10 ist eine Darstellung der Funktion einer Lade-/Entladeeinrichtung für eine globale Datenbank, eine lokale Datenbank und einen Knoten-Cachespeicher.
Fig. 11A ist ein Diagramm, das eine bevorzugte Realisierung einer Kontext- Objekt-Datenbank zeigt.
Fig. 11B ist ein Diagramm, das eine bevorzugte Realisierung einer Methoden- Überlagerungstabelle in der Kontext-Objekt-Datenbank zeigt, die in Fig. 11A gezeigt ist.
Fig. 11C ist ein Diagramm, das eine bevorzugte Speicherstruktur für eine Server-Knotentabelle in der Kontext-Objekt-Datenbank zeigt, die in Fig. 11A gezeigt ist.
Fig. 11D ist ein Diagramm, das eine bevorzugte Realisierung einer Klassen- Datenbank-Überlagerungstabelle in der Kontext-Objekt-Datenbank zeigt, die in Fig. 11A gezeigt ist.
Fig. 12 ist ein Diagramm von einzelnen Softwarekomponenten auf den Plattformen des Netzwerks.
Fig. 13 ist ein Flußdiagramm der globalen Funktion, welche durch die bevorzugte Realisierung dieser Erfindung für einen Fernaufruf von Anwendungen durchgeführt wird.
Fig. 14 ist ein ausführliches Diagramm von Komponenten des Netzwerks und des Flusses von Informationen.
Fig. 15A bis 15D sind ein Flußdiagramm der Prozedur, die von der Aufrufer- Software-Komponente nach Fig. 14 durchgeführt wird.
Fig. 16 ist eine Darstellung der Schritte, die von der Aufrufer-Software-Komponente nach Fig. 14 durchgeführt wird, um eine Methode zu ermitteln.
Fig. 17A und 17B ist ein Flußdiagramm der Schritte, die von der Steuer- Server-Softwarekomponente nach Fig. 14 durchgeführt werden.
Fig. 18A bis 18B sind ein Flußdiagramm der Schritte, die von der Absender- Softwarekomponente nach Fig. 14 durchgeführt werden.

V. Ausführliche Beschreibung der bevorzugten Realisierung

Es wird nun, wie in den begleitenden Zeichnungen gezeigt, auf die bevorzugten Realisierungen der Erfindung ausführlich Bezug genommen.
Diese Erfindung ist vorzugsweise durch Datenprozessoren realisiert, die in einer herkömmlichen Netzwerk-Bauweise organisiert sind. Die Bauweise für das bzw. die Prozeduren zum Realisieren der Anwendungs-Kompabilität sind jedoch nicht herkömmlich, da sie einen objektorientierten Lösungsweg für die Wechselwirkungen zwischen den Anwendungen in dem Netzwerk vorsehen.

A. Die Hauptkomponenten des Netzwerks

Fig. 1 zeigt ein Netzwerk 50, welches verwendet werden kann, um die vorliegende Erfindung zu realisieren. Das Netzwerk 50 in Fig. 1 enthält drei unabhängige Plattformen 100, 200 und 300, welche über einen Netzwerkbus 55 verbunden sind. Obwohl die Plattformen 100, 200 und 300 als völlig heterogen gezeigt werden (d.h. die Plattform 100 wird als ein VAX-Prozessor gezeigt, der ein VMS-Betriebssystem verwendet, die Plattform 200 wird als ein MIPS-Prozessor gezeigt, der ein ULTRIX- Betriebssystem verwendet, und die Plattform 300 wird als ein 80286-Prozessor gezeigt, der ein MS-DOS-Betriebssystem verwendet), wird diese Erfindung dennoch in einem homogenen Netzwerk arbeiten. Auch ist die Anzahl der Plattformen nicht wichtig.
Die Zusammensetzung und das Protokoll des Netzwerkbusses 55 ist nicht wichtig, solange er einen Austausch der Informationen zwischen den Plattformen 100, 200 und 300 ermöglicht. Außerdem ist die spezifische Netzwerk-Architektur nicht entscheidend für diese Erfindung. Z. B. würde eine andere Netzwerk-Architektur, die gemäß dieser Erfindung verwendet werden könnte, eine Plattform als Netzwerk- Regler verwenden, mit der alle anderen Piattformen verbunden werden würden. Es wird jedoch angenommen, daß das in Fig. 1 gezeigte Netzwerk 50 die Vorteile der vorliegenden Erfindung hervorhebt.
In der bevorzugten Realisierung des Netzwerks 50 enthält jede der Plattformen 100, 200 und 300 je eine Zentraleinheit ("CPU") 110, 210 bzw. 310 und je einen Speicher 150, 250 bzw. 350.
In jeder Zentraleinheit 110, 210 und 310 sind jeweils die Anwendungen 120, 220 bzw. 320, die Betriebssysteme ("OP SYS") 140, 240 bzw. 340 und die Anwendungs-Steuer-Architektur-Einrichtungen-("ACAS") Softwarekomponenten 130, 230 bzw. 330 enthalten.
Die Anwendungen 120, 220 und 320 können Programme sein, die entweder früher geschrieben und modifiziert wurden, um mit der vorliegenden Erfindung zu funktionieren, oder speziell dafür geschrieben wurden, um aus den durch die vorliegende Erfindung gebotenen Einrichtungen Nutzen zu ziehen. Zur Beschreibung rufen entweder die Anwendungen Operationen auf, die gemäß dieser Erfindung ausgeführt werden sollen, oder sie reagieren auf den Aufruf durch andere Anwendungen.
Die ACAS-Softwarekomponenten 130, 230 und 330 realisieren den objektorientierten Lösungsweg dieser Erfindung. Vorzugsweise bestehen die ACAS-Softwarekomponenten 130, 230 und 330 aus einer Anzahl von Software-Modulen, wie nachfolgend ausführlich beschrieben.
Die Betriebssysteme 140, 240 und 340 sind die Standard-Betriebssysteme, welche mit den entsprechenden CPUs 110, 210 bzw. 310 der Plattformen 100, 200 bzw. 300 verbunden sind.
Die Speicher 150, 250 und 350 dienen mehreren Funktionen. Eine der Funktionen ist natürlich, einen allgemeinen Speicher für die jeweilige Plattform bereitzustellen. Eine andere Funktion ist, die Anwendungen 120, 220 und 320, die ACAS- Softwarekomponenten 130, 230 und 330 und die Betriebssysteme 140, 240 und 340 vor ihrer Ausführung durch die jeweilige CPU 110, 210 und 310 zu speichern.
Außerdem enthalten Teile der Speicher 150, 250 und 350 Informationen für eine netzwerkumspannende oder "globale" Datenbank, die miteinander geteilt wird und auf allen Plattformen 100, 200 und 300 im Netzwerk 50 direkt oder indirekt zur Verfügung steht. Die globale Datenbank wird nachfolgend ausführlicher beschrieben.

B. Elemente der objektorientierten Architektur

(1) Definitionen der Elemente

Objektorientierte Methoden sind beim Programmieren verwendet worden, um die Datenschnittstelle von der eigentlichen Realisierung zu trennen, aber solche Methoden sind auf heterogene Netzwerke nicht angewandt worden. In der vorliegenden Erfindung werden objektorientierte Techniken verwendet, um die eigentlichen Anwendungen und ihre Daten von der Realisierung der Verarbeitung dieser Daten durch andere Anwendungen zu trennen.
Die objektorientierte Architektur dieser Erfindung beinhaltet vorzugsweise bestimmte Schüsselelemente. Fig. 2 erklärt die Beziehung zwischen bestimmten dieser Elemente und bestimmten herkömmlichen Merkmalen von Anwendungen. Wie in Fig. 2 gezeigt, kann eine Anwendung 260 auf zwei Arten beschrieben werden. Erstens, diese Anwendung hat bestimmte Anwendungsdefinitionen 265. Z. B. könnten, wenn die Anwendung 260 ein Textverarbeitungsprogramm ist, die Anwendungsdefinitionen die Definitionen enthalten, welche Operationen dieses Textverarbeitungsprogramm ausführen kann, und mit welcher Art von Daten dieses Textverarbeitungssystem arbeiten kann.
Außerdem beinhaltet die Anwendung 260 die Anwendungsdaten 268. Die Anwendungsdaten 268 sind die spezifischen Daten, mit welchen die Anwendung 260 arbeitet.
Gemäß der vorliegenden Erfindung werden die Anwendungsdaten nicht durch die objektorientierte Architektur "verarbeitet". Statt dessen wird die vorliegende Erfindung dadurch realisiert, daß die Anwendungsdefinitionen und die Anwendungsdaten als Objektarten charakterisiert werden, welche im Rest dieser Beschreibung als Objekte bezeichnet werden. Objekte sind in Fig. 2 nicht gezeigt, aber sie durchdringen die Elemente, die gezeigt werden.
In der folgenden Besprechung wird sich die Bezeichnung "Objekt" allgemein mehrere verschiedene Arten von Elementen bezeichnen, von denen alle zwei Eigenschaften gemeinsam haben. Erstens, sie beziehen sich auf äußere Fähigkeiten, womit gemeint ist, daß die Objekte sich auf jene Teile von Anwendungsdefinitionen oder Anwendungsdaten beziehen oder sie beschreiben, die anderen Anwendungen mitgeteilt werden müssen. Zweitens, sie sind allgemein, das heißt, daß die Objekte allen Anwendungen zur Verfügung gestellt werden und daß sie daher einen allgemein bekannten und eindeutigen Namen für alle Anwendungen haben, welche Schnittstellen zu den Objekten haben. Die vorliegende Erfindung bezieht sich eher auf die Behandlung von Objekten als von spezifischen Daten oder Anwendungen.
Wie in Fig. 2 gezeigt, werden zwei Elemente der objektorientierten Architektur dieser Erfindung aus den Anwendungsdefinitionen 265 entwickelt. Eines sind die Klassen 270 und das andere sind die Methoden 280. Die Klassen sind Objekte in dem Sinne, daß sowohl die Namen der Klassen als auch die Merkmale der Klassen extern und allgemein sind. Außerdem können Klassen nicht nur zur Beschreibung von Anwendungen verwendet werden, sondern auch von Daten, die von den Anwendungen benutzt werden.
Außerdem kann man aus den Anwendungsdefinitionen 265 bestimmte Arten von Funktionen ableiten, die von dieser Anwendung ausgeführt werden, und diese sind typische Beispiele der Methoden 280. Jedoch werden die typischen Methoden 280 nicht durch das System gesteuert, sondern sie können stattdessen in Klassen organisiert werden. Die Klassen für jene Methoden (Methoden-Objekte genannt) sind allgemein und extern, sogar obwohl die spezifischen Befehle oder Funktionen, die von den Anwendungen durchgeführt werden, es nicht sind.
Die Instanzen 290, welche von den Anwendungsdaten 268 stammen, sind Elemente, die von einer Anwendung manipuliert werden können oder auf die durch eine Anwendung zugegriffen werden kann. Wiederum sind die Instanzen nicht Objekte, die von dieser Architektur verarbeitet werden. Statt dessen sind Instanzen in Klassen organisiert, so daß Instanzen in der gleichen Klasse gemeinsame Eigenschaften aufweisen. Z. B. kann eine bestimmte DECwrite-Anwendung, die ein Editor für zusammengesetzte Dokumente ist, an einer bestimmten Datei, MYFILE genannt, arbeiten. Dies ist eine besondere Datei, und sie wird nicht durch das ACAS-System bearbeitet. Statt dessen soll MYFILE zu einer Klasse von kompatiblen Dateien gehören, wie z. B. zu ASCII_FILE, welche allgemein und daher ein Klassen-Objekt ist.
Im selben Beispiel wird eine spezifische DECwrite-Anwendung nicht vom gesamten System behandelt. Statt dessen kann die spezifische DECwrite-Anwendung jedoch zu einer Klasse gehören, die DECwrite genannt wird, allgemein und ein Klassen-Objekt ist.
Wie aus Fig. 2 zu ersehen ist, können die Anwendungen dann durch die Klassen gekennzeichnet werden, zu denen die Anwendungen gehören, durch die Klassen (Methoden-Objekte), welche die spezifischen Methoden in dieser Anwendung unterstützen, und durch die Klassen-Objekte, auf welche die Methoden-Objekte angewendet werden können.
Eines der Klassenmerkmale ist, daß sie hierarchisch organisiert werden können. Dies wird nachfolgend ausführlicher erklärt, aber es kann durch Betrachten des Konzepts der Überklassen und Unterklassen vorbereitend verstanden werden. Eine Überklasse ist eine Mutter ihrer Unterklasse, und jede Unterklasse ist ein Kind von zumindest einer Überklasse. Das Überklassen-/Unterklassenverhältnis bedeutet, daß die Eigenschaften oder gemeinsamen Merkmale der Überklasse von der Unterklasse geerbt werden. Z. B. kann eine Klasse von DATA_FILES als Eigenschaften die Fähigkeit haben, geöffnet, gelesen und beschrieben zu werden. Zwei Unterklassen der Klasse DATA_FILES könnten sein SEQUENTIAL_FILES und RANDOM_ACCESS _-FILES. Die Unterklasse SEQUENTIAL-FILES könnte außer den Eigenschaften, geöffnet, gelesen und beschrieben werden zu können, auch die Eigenschaft haben, sequentiell zugreifbar zu sein, und die Unterklasse RANDOM_ACCESS_FILES könnte die Eigenschaft haben, über eine Adresse direkt zugreifbar zu sein.
Ein anderes Element der objektorientierten Architektur dieser Erfindung, das in Fig. 2 nicht wiedergegeben ist, sind Nachrichten. Nachrichten sind die Schnittstellen zwischen einem Anwendungsprogramm und den Methoden und werden in dem Anwendungsprogramm verwendet, um Funktionsarten zu spezifizieren, welche an den in der Client-Anwendung identifizierten Instanzen durchgeführt werden. Die Nachrichten sind gewöhnlich von der Form eines Wählens einer Funktion, wie z. B. PRINT, und mehrerer Parameter, welche Instanzen, Zeichenketten, Zahlen usw. sein können. Die Beziehung zwischen diesen Elementen wird im nächsten Teil bechrieben.

(2) Beziehung der Elemente zueinander

Fig. 3 ist ein Diagramm, das die Beziehung der verschiedenen Elemente zueinander, die vorher beschrieben wurden, zeigt. Wie Fig. 3 darlegt, ist jede Instanz 370 mit einer Klasse 380 verbunden. Ein anderer Weg, dies zu verstehen, ist, die Klasse 380 als eine "Schablone" für die Erstellung von Objekten in dieser Klasse zu betrachten, welche Instanzen sein können, ebenso für die Behandlung solcher Objekte. Die Bezeichnung "Schablone" kennzeichnet die Tatsache, daß die Objekte (die Daten-Elemente, -Methoden oder -Anwendungen sind,) in jeder Klasse bestimmte Merkmale oder Eigenschaften teilen, die durch diese Klasse festgelegt sind.
Eine Instanz 370 wird durch das Senden einer Nachricht 360 behandelt. Die Nachricht 360 könnte ein Prozeß sein, wie z. B. EDIT, READ oder PRINT. Von Nachrichten kann man sagen, daß sie durch die Klasse "unterstützt" werden, was bedeutet, daß die Auslegung der Nachricht von den Klassen abhängt, zu welchen die Instanzen in dieser Nachricht gehören. Z. B. kann eine PRINT-Nachricht (Druckbefehl) anders ausgelegt werden, wenn die Instanz eine Textdatei in der Klasse TEXT_FILE ist, als im Gegensatz dazu eine Farbgraphikdatei in einer Klasse COLOR_GRAPHICS.
Eine Nachricht 360 beschreibt nicht die Realisierung einer bestimmten Funktion; sie stellt nur die Schnittstelle zu der Realisierung der betreffenden Funktion dar. Somit muß man, um die betreffende Funktion zu finden, die durch eine bestimmte Nachricht 360 (d. h. die Methode) aufgerufen wird, nicht nur die Nachricht prüfen, sondern auch die Klasse der Instanz. Um einen spezifischen Prozeß zu veranlassen stattzufinden, muß die Nachricht 360 einem tatsächlich ablauffähigen Programmcode zugeordnet werden. Dieses Zuordnen geschieht durch Finden der betreffenden Nachricht 360, die zu der bestimmten Klasse 380 der betreffenden Instanz 370 gehört, und dann durch Finden der betreffenden Methode 390, welche zu der Nachricht 360 gehört, die von der Klasse 380 unterstützt wird. Die Methode 390 repräsentiert den tatsächlich durchführbaren Programmcode zum Realisieren der gewünschten Funktion der Nachricht 360 an der Instanz 370.

(3) Organisation

Fig. 4 zeigt eine Darstellung darüber, wie die verschiedenen objektorientierten Architekturelemente für ihre spezifische Darstellung im Speicher vorbereitend organisiert werden können. Wie aus Fig. 4 ersichtlich ist, gibt es eine komplexe Beziehung, die zwischen den Klassen und den Methoden besteht. Es wird sowohl für Beziehung als auch für Klassen in der bevorzugten Realisierung eine Hierarchie verwendet, um den objektorientierten Lösungsweg durchzuführen, der nötig ist, um den Verhaltensrelationen zu entsprechen, welche zwischen den Anwendungen bestehen müssen. Die genannten spezifischen Beispiele sind jedoch lediglich erläuternd, und andere Arten von Darstellungen dieser Klassen und Methoden könnten für Fachleute offensichtlich sein.
In der schematischen Darstellung, die in Fig. 4 gezeigt ist, gibt es hauptsächlich zwei Verzweigungen der Hierarchie. Eine wird durch das Methoden-Objekt 400, die andere durch die Klasse 450 gebildet. Die Verzweigungen und Hierarchien unterscheiden sich darin, was sie geerbt haben. In der Klassenhierarchie besteht die Erbschaft im Verhalten, weil eine solche Erbschaft Nachrichten beinhaltet. In der Methodenhierarchie besteht die Erbschaft nur aus Attributen. Die Brücke zwischen der Klassenhierarchie und der Methodenhierarchie führt über die Nachrichten, wie z. B. die Nachrichten 490 und 495, und die Methoden-Karten, wie z. B. die Abbildungen 493 und 498. In der in Fig. 4 gezeigten Methodenhierarchie erben die Methoden- Objekte 410, 415 und 420, welche entsprechend als WORD_C_CUT_MS-DOS, WORD_C_READ_VMS und WORD_C_READ_ULTRIX dargestellt werden, vom Methoden-Objekt 400. In Fig. 4 könnte z. B. das Methoden-Objekt 400 Attribute (nicht gezeigt) haben, welche angeben, daß die Methoden eine bestimmte Dialogart benutzen, und eine bestimmte Art von Server-Einschaltart haben.
Das Methoden-Objekt 410 steht für die CUT-Funktion in EMACS-Anwendungen. Verbunden mit der Methode 410 ist eine Gruppe von Attributen 430, welche die von dem Methoden-Objekt 400 geerbten enthält. Kurz gesagt, das Attribut Platform- Type gibt die Plattform an, auf welcher das Methoden-Objekt ausgeführt werden kann. Das Attribut InteractionType beschreibt die tatsächliche Art von Methode, welche innerhalb eines bestimmten Methoden-Servers ausgeführt wird. Beispiele von Werten für dieses Attribut, welche nachfolgend erklärt werden, sind: BUILT_IN, SCRIPT_SERVER und DYNAMIC_LOAD. Das Attribut ServerStartupType zeigt einen geeigneten Aufrufmechanismus an, der von dem Methoden-Server benutzt werden soll. Beispiele von Werten für dieses Attribut, welche auch nachfolgend erklärt werden, sind: SHELL, DYNAMIC_LOAD und NAMED_APPLICATION.
Die Gruppe von Attributen 430 legt fest, daß die zugeordneten Methoden auf Plattformen arbeiten, die einen Prozessor 80286 mit dem Betriebssystem MS-DOS haben, und sie haben einen BUILT_IN-Dialogtyp und einen NAMED_APPLICATION- Server-Einschalttyp.
Ähnlich beim Methoden-Objekt 415, welches für die READ-Funktion bei EMACS-Anwendungen steht. Der Methode 415 ist eine Gruppe von Attributen 435 zugeordnet, welche die vom Methoden-Objekt 400 enthält, aber welche auch festlegt, daß die zugeordneten Methoden auf VAX-Plattformen arbeiten, wobei sie im VMS- Betriebssystem betrieben werden, und sie haben einen Dialogtyp BUILT_IN und einen NAMED_APPLICATION-Server-Einschalttyp.
Das Methoden-Objekt 420 ist eine Unterklasse vom Methoden-Objekt 400, das für die READ-Funktion in EMACS-Anwendungen steht. Die Attribute 440 für die Methodenklasse 420 hat einen Plattformtyp mit einem MIPS-Prozessor, der im ULTRIX- Betriebssystem mit einem BUILT_IN-Dialogtyp betrieben wird, und einen NAMED_APPLICATION-Server-Einschalttyp.
Die Klasse 450 ist andererseits eine Überklasse von der Klasse 460, die FILES genannt wird, und einer Klasse 465, die APPLICATIONS genannt wird. Die Klasse 460 bezieht sich auf Datenobjekte. Wie in Fig. 4 gezeigt, ist die Klasse 460 die Attribute haben würde (nicht gezeigt), eine Überkasse von der Klasse 470. Die Klasse 470 wird ASCII_FILE genannt. Z. B. könnte die Klasse 470 all die Dateien innerhalb des Netzwerks 50 darstellen (siehe Fig. 1), die die gemeinsamen Eigenschaften von ASCII-Dateien haben. Die gemeinsamen Eigenschaften können in den Attributen für die Klasse 470 beschrieben werden, welche in Fig. 4 nicht gezeigt sind.
Die Klasse 470 würde dann die Klasse für mehrere Instanzen sein, aber die Instanzen werden in Fig. 4 nicht gezeigt, weil sie nicht durch die objektorientierte Architektur behandelt werden. Was in Fig. 4 gezeigt wird, sind die Nachrichten, welche die Klasse 470 unterstützen wird, und das einzige, was einfachheitshalber gezeigt ist, ist die EDIT-Nachricht 490.
Daß eine Klasse eine Nachricht unterstützt bedeutet, daß, wenn die Nachricht als eine Schnittstelle zu dieser objektorientierten Architektur verwendet wird, sie mit der Klasse, die sie unterstützt, verwendet werden kann, und daher auch Instanzen innerhalb dieser Klasse. Somit kann in dem in Fig. 4 gezeigten Beispiel eine EDIT- Nachricht an alle Instanzen in der Klasse ASCII_FILE geschickt werden.
Die Klasse APPLICATIONS (Anwendungen) 465 ist auch eine Überklasse, und eine ihrer Unterklassen, die EDITOR-Klasse 475, wird gezeigt. Die EDITOR-Klasse 475 ist eine Überklasse für spezifische Anwendungsklassen 480, 483 und 485, die WORD_A WORD_B oder WORD_C entsprechen. Jede der Klassen, wie z. B. WORD_C 485, stellt eine spezifische Anwendung dar, wie z.B. EMACS oder TPU. Somit wird jede Anwendung durch eine Klasse definiert. Eine Anwendungsklasse kann sich jedoch auf das Realisierungsverhalten von mehr als einer Anwendung beziehen.
Die Anwendungsklassen unterstützen auch Nachrichten, was durch die Nachricht CUT 495 gezeigt wird, die durch die Anwendungsklasse 485 unterstützt wird. Dies entspricht der Tatsache, daß zum Zeitpunkt der Definition der Klasse festgelegt wurde, daß irgendeine Anwendung, die die Klasse 485 repräsentiert, eine Nachricht CUT unterstützen muß.
Wie oben kurz erwähnt, werden in der bevorzugten Realisierung Anwendungen in einer Hierarchie von Klassen organisiert, mit einer Mutterkasse, die als Überklasse bezeichnet wird, und Kinderklassen, die als Unterklassen bezeichnet werden.
In Fig. 4 ist Klasse 465 eine Überklasse, die EDITOR genannt wird. Alle Unterklassen dieser Überklasse würden zumindest die gleiche Menge von bestimmten, eindeutigen Merkmalen oder Attributen der Überklasse haben. In Fig. 4 sind die Unterklassen der Überklasse 475 EDITOR: WORD_A 480, WORD_B 483 und WORD_C 485. WORD_A könnte die TPU-Anwendungen darstellen, WORD_B 483 könnte alle LSE- Anwendungen darstellen und WORD_C 485 könnte alle EMACS-Anwendungen darstellen. Jede dieser Unterklassen würde zusätzlich zu den Merkmalen und Attributen, die sie von der Überklasse 475 geerbt haben, ihre eigene Menge von einmaligen Merkmalen und Attributen haben, welche sich in einer Weise unterscheiden, daß sie ihre Trennung als Unterklassen innerhalb der Überklasse 475 EDITOR ermöglichen.
In der bevorzugten Realisierung dieser Erfindung erlauben spezifische Erbschaftsregeln die Mehrfachvererbung unter den Klassen. Dies bedeutet, daß irgendeine Unterklasse mehr als eine Überklasse haben kann. Weil diese Art von Erbschaft zum Definitionszeitpunkt Zweideutigkeiten schaffen kann, werden die Überklassen zum Definitionszeitpunkt als "geordnet" betrachtet, um mögliche Erbschaftskonflikte zu beseitigen. Z. B. wird zu dem Zeitpunkt der später beschriebenen Definition einer Unterklasse, wenn irgendwelche Konflikte wegen der doppelten Definition einer Nachricht oder eines Attributs für mehr als eine der aufgeführten Überklassen entstehen, die Nachricht oder das Attribut in der am höchsten angeordneten Klasse als das von der Unterklasse geerbte betrachtet.
Wie oben erwähnt, besteht die Relation zwischen den Methoden-Objekten und der Klasse aus Methoden-Karten. Fig. 4 zeigt zwei Methoden-Karten 493 und 498. Jede der Klassen hat Nachrichten, von denen jede auf eine bestimmte Methoden- Karte vorweist. Somit ist die Methoden-Karte 493 mit der EDIT-Nachricht 490 verknüpft und die Methoden-Karte 498 mit der CUT-Nachricht 495.
Vorzugsweise enthalten die Methoden-Karten den Namen eines Methoden- Objekts, das mit den Nachrichten verknüpft ist. Die Methoden-Karten könnten auch den Namen einer anderen Klasse und Nachricht enthalten. So enthält die Methoden- Karte 493 den Namen von zwei Methoden-Objekten. Die Methoden-Karte 493 enthält den Namen von einem Methoden-Objekt WORD_C_READ MIPS.ULTRIX 494, der ein Name des Methoden-Objekts 420 ist, und den Namen von einem Methoden-Objekt WORD_C_READ VMS 496, der ein Name eines Methoden-Objekts 415 ist.
Auf ähnliche Weise enthält die Methoden-Karte 498 für die Nachricht CUT 495 den Namen WORD_C_CUT 80286.MS-DOS 499, welcher der Name des Methoden- Objekts 410 ist.
Auf diese Weise können die Methoden-Karten 493 und 498 verwendet werden, um die Attributgruppen 430, 435 und 440 entsprechend den Methoden-Objekten 410, 415 bzw. 420 zu lokalisieren. Die spezifische Art, auf welche dieser Typ von Befehl verwendet wird, um Methoden zu lokalisieren, wird nachfolgend genauer beschrieben.

C. Klassen-Datenbankstruktur

Die Klassen und Methoden-Objekte der Netzwerk-Architektur werden, wie in Fig. 5 dargestellt, in einer Klassen-Datenbank 500 gespeichert,. Die Klassen-Datenbank 500 stellt eine nicht redundante Sammlung von untereinander zusammenhängenden Datenelementen dar, die aufgeteilt und von dem Netzwerk 50 verwendet werden können.
Die Klassen-Datenbank 500 in Fig. 5 besteht aus zwei Arten von Objekten, ähnlich den in Fig. 4 gezeigten. Die Objekte sind entweder Klassen 505 oder Methoden 549. Jede der Klassen 505 entspricht einer allgemeinen externen Darstellung der Instanzen der entsprechenden Klasse. Z. B. entspricht in Fig. 5 das Klassen-Objekt ASCII_FILE 506 einer allgemeinen externen Darstellung aller Elemente der Gruppe von Instanzen, welche die Merkmale der Klasse ASCII_FILE 506 haben. Die Merkmale werden durch die entsprechende Gruppe von Attributen 510 dargestellt.
In der bevorzugten Realisierung können die Attribute 510, die den Klassen 505 entsprechen, auf jede Art verwendet werden, die der Systementwickler oder Benutzer wünscht. Z. B. können die Attribute 511 für die Klasse ASCII_FILE 506 den Namen eines Piktogramms enthalten, um die Klasse 506 auf dem Bildschirm darzustellen.
Jede der Klassen 505 unterstützt auch eine Gruppe von Nachrichten 520. Eine Nachricht besteht aus einem "Verbum" oder Nachrichten-Namen, wie z. B. CUT, READ oder EDIT, der Wähler genannt wird, und aus Parametern. Jeder der Parameter besteht aus einem Namen, einem Typ und einer Richtung. Der Name ist "typisiert", was bedeutet, daß der Name von einer bestimmten Art ist, z. B. eine ganze Zahl, ein Buchstabe oder eine Zeichenkette. Die möglichen Richtungen für jeden Parameter können "hinein" "heraus" und "hinein/heraus" sein. Wenn ein Parameter in einer Nachricht ein "hinein" als Richtung hat, bedeutet dies, daß der Parameter eine Eingabe für eine Methode ist, die aufgerufen werden soll (wird nachfolgend erläutert). Wenn ein Parameter in einer Nachricht ein "heraus" als Richtung hat, bedeutet dies, daß der Parameter eine Ausgabe von einer Methode ist. Wenn ein Parameter in einer Nachricht ein "hinein/heraus" als Richtung hat, bedeutet dies, daß der Parameter sowohl eine Eingabe in eine Methode als auch eine Ausgabe aus einer Methode ist.
Die Nachrichten 520 sind Darstellungen für die gültigen Operationen, die jede der durch die entsprechende Klasse 500 dargestellten Instanzen unterstützen kann. Z. B. unterstützt in Fig. 5 das Klassen-Objekt ASCII_FILE 506 die Gruppe von Nachrichten 520, welche die Nachrichten 521 und 525 beinhaltet. Die spezifischen Nachrichten in der Nachrichtengruppe 520 sind OPEN (PARA_1, PARA_2...) 521 und EDIT (PARA_1, PARA_2...) 525. Z.B. könnte PARA_1 in der Nachricht EDIT (PARA_1) den "Dateinamen: Zeichenkette, hinein/heraus" darstellen, wobei Dateiname der Name des Parameters, Zeichenkette der Parametertyp und hinein/heraus die Richtung des Parameters sind.
Die Nachrichten 521 und 525 beziehen sich auf die jeweilige Methoden-Karte 530 und 540. Jede der Methoden-Karten 530 und 540 enthalten eine Gruppe von Verweisen auf die entsprechenden Methoden-Objekte 549 in der Klassen-Datenbank 500 oder auf die Namen von anderen Klassen und Nachrichten. Z. B. enthält die Methoden-Karte 530 die Verweise 531 und 533, von denen jeder einem anderen Methoden-Objekt entspricht (nicht gezeigt). Die Methoden-Karte 540 enthält auch die Verweise 541 und 543, von denen jeder einem anderen der Methoden-Objekte 549 in der Klassen-Datenbank 500 entspricht. Das entsprechende Methoden-Objekt für den Verweis 541 ist in Fig. 5 nicht gezeigt. Zum Zweck dieses Beispiels zeigt Fig. 5, daß der Verweis 543 in der Methoden-Karte 540 auf das Methoden-Objekt 550 verweist, welches ED_3_READ ist.
Wie oben erklärt, sind die Methoden-Objekte 549 in der Klassen-Datenbank 500 auch hierarchisch gespeichert. Jedes der Methoden-Objekte 549 ist typisch für einen Verweis auf einen ausführbaren Code, der fähig ist, eine Methode auszuführen.
In einem Netzwerk-Datenverarbeitungssystem wie dem der bevorzugten Realisierung können viele Instanzen des ausführbaren Codes mit jedem der Methoden- Objekte 549 verknüpft sein und fähig sein, die Funktionen auszuführen, die von jedem Methoden-Objekt identifiziert wurden. Als Beispiel kann in jedem der Speicher 150, 250 und 350 (Fig. 1) eine Installation des ausführbaren Codes vorliegen, der mit dem Methoden-Objekt ED_3_READ 550 verknüpft ist, wobei jeder der ausführbaren Codes fähig ist, die Funktionen des Methoden-Objekts ED_3_READ 550 auf einer entsprechenden der Plattformen 100, 200 und 300 auszuführen. Das System gemäß der bevorzugten Realisierung beinhaltet einen Prozeß, welcher zwischen den drei ausführbaren Codes wählt.
Anders als die mit den Klassen verknüpften Attribute 510 werden die Methoden-Attribute 560 der Klassen-Datenbank 500, die mit den Methoden-Objekten 549 verknüpft sind, zum Ausfindigmachen und Ausführen einer Instanz verwendet, die mit einem bestimmten Methoden-Objekt in dem Netzwerk verknüpft ist, wie z. B. das Methoden-Objekt 550. Zum Zweck der Vereinfachung zeigt Fig. 5 nur eine Gruppe von Methoden-Attributen 561 in der Klassen-Datenbank 500. Die Gruppe 561 ist mit dem Methoden-Objekt 550 der Methoden-Objekte 549 in der Klassen-Datenbank 500 verknüpft. Obwohl einige der Methoden-Attribute in den Gruppen 560, die willkürlich durch die Benutzer des Systems spezifiziert sein können und durch das System während der Ausführung verwendet werden können, sind bestimmte Attribute für den Prozeß kritisch.
Wie in Fig. 5 gezeigt, enthalten die Methoden-Attribute in der Gruppe 561 den PlatformType = 80286.MS-DOS, den InteractionType = BUILT_IN und den Server- StartupType = SHELL.
In der bevorzugten Realisierung sind zwei andere Methoden-Attribute in der Methoden-Attributgruppe 561 enthalten. Eines ist ein InvocationString-Attribut, welches eine Aufrufzeichenkette festlegt, die verwendet werden muß, um den spezifizierten Methoden-Server zu starten, wenn er gestartet werden muß. Der Wert dieses Attributs muß ein Wert sein, der sich für die entsprechende Plattform eignet, die in dem ersten Attribut spezifiziert ist. Wenn z. B. der Wert des PlatformType-Attributs MIPS.ULTRIX ist und der Wert des ServerStartupType-Attributs SHELL ist, dann sollte der Wert dieses Attributs ein entsprechender ULTRIX-Kommandointerpreter- Befehl sein.

D. Informationsfluß

Vor der Beschreibung der Einzelheiten der bevorzugten Realisierung dieser Erfindung wird der Fluß der Informationen durch das gesamte System unter Bezugnahme auf Fig. 6 erklärt.
Fig. 6 enthält ein Diagramm 600, das, wie in Fig. 1 gezeigt, verschiedene Komponenten des Netzwerks 50 und das Fließen der Informationen zwischen diesen Komponenten zeigt. Die Anwendungen 610 und 670 in Fig. 6 entsprechen jede irgendeiner der Anwendungen 120, 220 bzw. 320, und von den ACAS-Softwarekomponenten 620 und 660 entspricht jede irgendeiner der ACAS-Softwarekomponenten 130, 230 oder 330. Die Klassen-Datenbanken 640 und die Kontext-Objekt-Datenbanken 630 werden in einem oder mehreren der Speicher 150, 250 und 350 gespeichert.
Wie nachfolgend genauer erklärt wird, sendet eine Anwendung 610, welche als "Client-Anwendung" bezeichnet wird, Nachrichten. Die Nachrichten können Instanzbehandlungen enthalten, welche Einrichtungen sind, die verwendet werden, um die Instanzen der Client- (oder irgend einer anderen) Anwendung zu identifizieren. Die Nachrichten werden durch die ACAS-Softwarekomponente 620 auf der Clientplattform empfangen.
Die ACAS-Softwarekomponente 620 verwendet dann die Namen der Nachrichten und die Klassen der Instanzen, auf die von den Instanzbehandlungen Bezug genommen wurde, um die Methoden-Karten in den Klassen-Datenbanken 640 zu finden. Die ACAS-Softwarekomponente 620 kann auch die Kontext-Informationen von den Kontext-Objekt-Datenbanken 630 benutzen, um eine Methoden-Kennung aus der Methoden-Karte auszuwählen, wobei die Kennung die Methode darstellt, die ausgeführt werden muß. Die Kontext-Informationen werden auch dazu verwendet, eine Plattform auszuwählen, die "Server-Plattform" genannt wird, auf welcher die ausgewählte Methode auszuführen ist. Die Kontext-Informationen werden nachfolgend ausführlich beschrieben.
Die ACAS-Softwarekomponente 620 sendet die Methoden-Kennung, die sie von der Klassen-Datenbank 640 abgerufen hat, und die Instanzbehandlungen an die ACAS-Softwarekomponente 620 auf der Server-Plattform. Danach führt die ACAS- Softwarekomponente 660 die geeigneten Schritte durch, um die gekennzeichnete Methode auszuführen, die eine "Server-Anwendung" 670 verwendet, oder sie verständigt die ACAS-Softwarekomponente 620, daß die Server-Plattform, welche die ACAS-Softwarekomponente 660 enthält, auf die Anforderung nicht antworten kann. In diesem letzteren Fall überprüft die ACAS-Softwarekomponente 620 dann die Kontext- Informationen, um eine andere Plattform in dem Netzwerk als Server-Plattform zu wählen, oder sie informiert andernfalls den Client, daß die Anforderung mißlungen ist.
Wenn die Ausführung der Methode, die in Fig. 6 durch die Server-Anwendung 670 identifiziert ist, eine Nachricht erzeugt, die an die Client-Anwendung 610 zurückgegeben werden soll, dann wird diese Nachricht zusammen mit zusätzlichen Informationen von der Server-Anwendung 670 zu der ACAS-Softwarekomponente 660 auf der Server-Plattform übermittelt. Die ACAS-Softwarekomponente 660 auf der Server- Plattform sendet dann Antworten an die ACAS-Softwarekomponente 620 auf der Client-Plattform, welche diese Antworten an die Client-Anwendung 610 auf der Client- Plattform weiterschickt.
All diese Transaktionen werden nachfolgend ausführlicher beschrieben.

E. Speichersysteme

(1) Allgemeine Klassen-Datenbank

Ein Diagramm des ganzen Speichersystems 700 wird in Fig. 7 gezeigt. Das Speichersystem 700 enthält eine globale Klassen-Datenbank 705 und lokale Klassen- Datenbanken 710, 730 und 750. Ein netzwerkumspannender Speicher 705 ist auch vorgesehen, um, wie nachfolgend beschrieben, für Benutzer des Netzwerks bestimmte andere Informationen zur Verfügung zu stellen.
Die globale Klassen-Datenbank 705 enthält Informationen, die für alle Plattformen zugänglich sind. Vorzugsweise wird die globale Klassen-Datenbank 705 über die Speicher der Plattformen verteilt. Z. B. wird die globale Klassen-Datenbank 705 in Fig. 7 als in jedem der Speicher 150, 250 und 350 teilweise resident gezeigt. Der Rest der globalen Klassen-Datenbank 705 würde in anderen Speichern, die nicht in Fig. 7 gezeigt werden, resident sein. Die Inhalte der globalen Klassen-Datenbank 705 sind hinsichtlich der Fig. 4 und 5 schon beschrieben worden.
Fachleute werden erkennen, daß die in Fig. 7 gezeigte verteilte Speicheranordnung nicht erforderlich ist, um die vorliegende Erfindung auszuführen. Z. B. könnte die gesamte globale Klassen-Datenbank 705 in dem Speicher eines einzigen Knotens oder in einem dafür vorgesehenen Speicher gespeichert werden, ohne die Prinzipien dieser Erfindung zu beeinflussen.
Außerdem wird gezeigt, daß jeder der Speicher 150, 250 und 350 eine lokale Klassen-Datenbank 710, 730 und 750 und ebenso einen entsprechenden Knoten- Cachespeicher 720, 740 bzw. 760 hat. Die Informationen in den lokalen Klassen- Datenbanken sind nur für Benutzer der entsprechenden Plattform zugänglich. Die Knoten-Cachespeicher 720, 740 und 760 werden verwendet, um eine Kopie von Teilen der globalen Klassen-Datenbank 705 aufzunehmen, auf die von der entsprechenden Plattform häufig zugegriffen wird.
Das Datenbanksystem, das verwendet wird, um die globale Klassen-Datenbank-Struktur auszuführen, sollte die globale Eindeutigkeit der Namen innerhalb einer einzelnen Datenbank unterstützen, ebenso die Eindeutigkeit der Kennungen über Datenbanken, die Zugriffs-Steuereinrichtungen und die geeigneten Speicher- und Abfrageeinrichtungen. Eine globale Namenseindeutigkeit für Objekte ist wichtig, weil sie allgemein sind. Kennungs-Eindeutigkeit ermöglicht Datenbanken, kombiniert zu werden, wie nachfolgend erklärt wird.
Zugriffs-Steuereinrichtungen des Datenbanksystems müssen einem autorisierten Benutzer auf irgendeiner Plattform in dem Netzwerk ermöglichen, Objekte und Attribute zu speichern und abzurufen, und sie müssen Sicherheitskontrolle und Syntaxprüfung vorsehen, um eine Beschädigung der Integrität der globalen Klassen- Datenbank 705 zu vermeiden. Einige der Einzelheiten dieser Kontrolle werden nachfolgend erörtert. Der Rest enthält bekannte Datenbank-Verwaltungsmethoden.
Die bevorzugte Realisierung erfordert, daß jedem Objekt in der globalen Klassen-Datenbank 705 eine Objektkennung zugewiesen werden kann, welche wie ein Objektname dazu verwendet werden kann, auf ein Objekt zu verweisen. Objektkennungen sind auch vorzugsweise sprachneutral, weil sie binäre Codes sind.
Objektkennungen werden auf einem "global" übereinstimmenden Schema festgelegt und sind innerhalb irgendeiner Anzahl von Klassen-Datenbanken einmalig. Objektnamen müssen andererseits nur innerhalb einer einzigen Klassen-Datenbank einmalig sein. Die Unterschiede zwischen den Klassen-Namen und -Kennungen können durch ein Beispiel besser gewürdigt werden. Angenommen, von zwei Firmen hat jede ihre eigene Klassen-Datenbank und wünscht, diese Datenbanken zu verschmelzen. Diese Datenbanken können Klassen mit den gleichen Namen haben, welche in der verschmolzenen Datenbank verschieden sein sollten, und dieser Unterschied kann durch die global einmalige Kennung beibehalten werden. Die Datenbanken können auch zwei Klassen mit verschiedenen Namen haben, welche in der verschmolzenen Datenbank gleich sein sollten. Diese Klassen können dazu gebracht werden, die gleiche Klassen-Kennung zu haben. Somit erlauben die Objektkennungen der gleichen Klasse in der globalen Klassen-Datenbank, auch durch mehr als einen Klassennamen identifiziert zu werden. Z. B. kann der Klassenname EDITORS in der globalen Klassen-Datenbank in dem Netzwerk auch durch den Klassennamen WPROCESSORS identifiziert werden.
Eine andere Software-Komponente, welche auch in jeder der ACAS-Softwarekomponenten 130, 230 und 330 enthalten ist, sieht die Einrichtung vor, eine einmalige Objektkennung zum Gebrauch und Speichern in den Klassen-Datenbanken zu schaffen. Vorzugsweise irgendein Speicherschema, das von einer Anwendung verwendet wird, welche die ununterbrochene Speicherung von Objektnamen erfordert, sollte die Objektkennungen eher speichern als die Objektnamen, um Namenskonflikte zwischen mehreren globalen Klassen-Datenbanken zu vermeiden.
Es wird nicht beabsichtigt, in der globalen Klassen-Datenbank 705 Anwendungsinstanz-Daten zu speichern, weil Anwendungen vorzugsweise ihre eigenen Gruppen von Anwendungsinstanz-Daten vollständig behandeln. Dies ermöglicht bestehenden Anwendungen, ihre laufenden Speicherstrategien fortzuführen, und beschränkt die Speichermöglichkeiten nicht, die für neue Anwendungen zur Verfügung stehen.
Die bevorzugte Realisierung sieht jedoch zwei Einrichtungen vor, Speicher- Klassen und Instanz-Benennung, was Anwendungen ermöglicht, ihre privat behandelten Instanzen mit der globalen Klassen-Datenbank 705, die durch die bevorzugte Realisierung betrieben wird, zu verbinden.
Die Speicher-Klassen sind eine Abstraktion, die einer Anwendung ermöglicht festzulegen, wie privat behandelte Instanzen zu interpretieren sind. Die Speicher- Klassen bieten eine Alternative zum Identifizieren der Klasse jeder Instanz, wenn die Instanz in einer Nachricht verwendet wird. In der bevorzugten Realisierung identifizieren die Speicher-Klassen Speichersysteme, wie z. B. Verwahrungsorte oder Dateien, welche Namen von Instanzen enthalten. Z. B. kann eine Speicher-Klasse eine bekannte Speichereinrichtung wie z. B. "RMS_FILE" oder "UNIX_FILE" beschreiben.
In der objektorientierten Architektur dieser Erfindung werden Speicher-Klassen auch als Klassen betrachtet. Ähnlich anderen Klassen, die in der Klassen-Datenbank gespeichert sind, kann die Speicher-Klasse als eine tatsächliche, objektorientierte Klassendefinition betrachtet werden, die aus Attributen, Nachrichten und Methoden besteht. Die Methoden, die mit jeder Speicher-Klasse verknüpft sind, werden verwendet, um den Klassennamen für eine Instanz, die mit dem betreffenden, durch die Speicher-Klasse der Instanz identifizierten Speichersystem verknüpft ist, wiederzufinden.
Die andere Einrichtung, die Instanz-Benennung, verwendet in der bevorzugten Realisierung eine Norm zum Benennen von Instanzen. Die Norm-Instanzbehandlung ist eine Zeichenkette, die durch die folgende logische Architektur dargestellt wird:
< Klasse> < Speicher_Klasse> < Speicherplatz> < Instanz_Verweis_Daten> . Die Bezeichnung "Klasse" ist der Name der jeweiligen ACAS-Klasse. Die Bezeichnung "Speicher_Klasse" ist eine Alternative zu dem Klassennamen und ist der Name der Speicher-Klasse. Die Bezeichnung "Speicherplatz" ist der logische Platz, wie z. B. der Knoten der Instanz. Der "Speicherplatz" ist wahlfrei und wird verwendet, wenn ein Client von einer Methode verlangt, daß sie an dem gleichen Speicherplatz läuft, an dem die Instanz sich befindet. Die Bezeichnung "Instanz_Verweis_Daten" ist der private Teil der Instanzbehandlung der Anwendung.
Instanzbehandlungen ermöglichen Realisierungen, sich auf Instanzen abstrakt zu beziehen, wodurch sie vermeiden, die Instanzen selbst behandeln zu müssen.
Die Instanzbehandlung umfaßt vorzugsweise die Klasse oder (falls nötig) die Speicher-Klasse, den Speicherplatz der Instanz und die Kennung für die Instanz. Z. B. in der Nachricht:
EDIT (INSTANCE_HANDLE)
stellt EDIT den gewünschten Prozeß dar. Die Zeichenkette INSTANCE_HANDLE könnte ASCII_FILE/NODE_1/MYFILE.TXT sein. In dieser Instanzbehandlung stellt ASCII_FILE die Klasse dar, Knoten_1 ist der Speicherplatz der Instanz und MYFILE.TXT ist die Kennung der Instanz. Diese Nachricht stellt ausreichend Klassen- und Nachrichteninformation bereit, um die richtige Methoden-Karte zu finden. Es wird für Fachleute offensichtlich sein, daß für die Zeichenkette INSTANCE_HANDLE andere Formate verwendet werden können, um die gleichen Ziele zu erreichen, wie die bevorzugte Realisierung es tut.
Wie oben erklärt, haben alle Klassen in einer globalen Klassen-Datenbank der bevorzugten Realisierung die einmalige Namen in der betreffenden globalen Klassen- Datenbank. Der Klassenname wird allgemein durch den Benutzer bestimmt, der die Klasse als erster festlegt.

(2) Lokale Klassen-Datenbanken

Zusätzlich zu einer globalen Klassen-Datenbank unterstützt die bevorzugte Realisierung auch lokale Klassen-Datenbanken für Klassen- und Methoden-Definitionen. Die lokalen Klassen-Datenbanken funktionieren ähnlich wie die globale Klassen- Datenbank, nur die Inhalte der lokalen Klassen-Datenbanken sind nicht allgemein verfügbar. Sie müssen nur für ihren lokalen Knoten zur Verfügung stehen. Somit müssen die lokalen Klassen-Datenbanken nicht in andere Knoten verteilt oder repliziert werden.
Fig. 7 zeigt eine bevorzugte Realisierung der lokalen Klassen-Datenbanken 710, 730 und 750 jeweils in den Speichern 150, 250 bzw. 350. Die lokalen Klassen-Datenbanken 710, 730 und 750 enthalten die Klassen- und Methoden-Informationen, die durch die entsprechenden Knoten erzeugt wurden, welche noch nicht zu der globalen Klassen-Datenbank hinzugefügt worden sind.
In dem bevorzugten Ausführungsbeispiel enthalten die Speicher 150, 250 und 350 auch jeweils Knoten-Cachespeicher 720, 740 bzw. 760, welche Methoden- und Klasseninformation, die von der globalen Klassen-Datenbank 705 geladen worden war, enthalten. Die Cache-Speicher sind eine Optimierung und nicht unbedingt erforderlich.
Das Datenbanksystem, das verwendet wird, um die lokale Klassen-Datenbank zu realisieren, muß innerhalb einer Datenbank Namenseindeutigkeit schaffen. Eine Zugriffssteuerung für die lokale Klassen-Datenbank ist nur auf der Ebene der Datenbank erforderlich. Die bevorzugte Realisierung einer lokalen Klassen-Datenbank verläßt sich auf die zugrundeliegende Sicherheitseinrichtung innerhalb des Datenbanksystems, um den Zugriff auf die Inhalte der lokalen Klassen-Datenbank zu kontrollieren.
Die Verwendung der lokalen Klassen-Datenbank hat mehrere Vorteile gegenüber der Verwendung der globalen Klassen-Datenbank. Z. B. schafft die lokale Klassen-Datenbank die Fähigkeit für Anwendungen in jedem Knoten, die Kommunikation untereinander in einer objektorientierten Weise fortzusetzen, sogar wenn das Netzwerk nicht zur Verfügung steht. In einer solchen Situation können die Anwendungen in dem Knoten fortfahren, andere Anwendungen, die für diesen Knoten lokal sind, aufzurufen.
Außerdem bewirkt die Verwendung einer lokalen Klassen-Datenbank bessere Leistung für die Anwendungen, die sich in dem gleichen Knoten befinden, wie die lokale Klassen-Datenbank, weil viele Aufrufe vollständig innerhalb der Grenzen einer einzigen Plattform behandelt werden können. Auf Plattformen, auf welchen die meisten Anwendungen höchstwahrscheinlich Aufrufe benutzen werden, die lokal behandelt werden können, kann die Verwendung der lokalen Klassen-Datenbank die Notwendigkeit von Netzwerkaktivität ausschalten oder sehr reduzieren, wie z. B. das Zugreifen auf die globale Klassen-Datenbank, um einen Aufruf zu erreichen.
Die Klassen-Datenbanken werden vorzugsweise nach einer Klassen- und Methodeninformation abgesucht, indem die lokalen Datenbanken vor der globalen Datenbank abgesucht werden. Die lokalen Datenbanken von jedem Knoten werden vorzugsweise in einer vorher festgelegten Reihenfolge abgesucht, wie nachfolgend erklärt wird. Sobald die gewünschten Informationen ausfindig gemacht wurden, wird die Suche beendet. Nur wenn die gewünschten Informationen in einer lokalen Datenbank nicht ausfindig gemacht werden können, wird die globale Datenbank abgesucht. Somit bestimmt die Suchreihenfolge die "Priorität" der Klassen-Datenbanken.
Fig. 8 zeigt einen Entwurf von einem Teil einer lokalen Klassen-Datenbank 800. Dieser Entwurf ist jedoch für die Erfindung nicht kritisch. Vorzugsweise enthält die lokale Klassen-Datenbank 800 einen Datenbankkopf 810, welcher verwendet wird, um andere Organisations-Informationen in der lokalen Klassen-Datenbank 800 ausfindig zu machen, wie z. B. Zeiger und Zuweisungsquoten. Die lokale Klassen- Datenbank 800 enthält auch einen Blockspeicherplatz 815, der eine Anzahl von Blocks 820, 822 und 824 enthält, welche die Informationen über die Klassen und Methoden enthalten.
Fig. 9 zeigt eine bevorzugte Anordnung des Blocks 900, welcher Block 820, 822 oder 824 sein könnte. Block 900 enthält ein Verzeichnis 910 zum Identifizieren der Speicherstellen der Objekte innerhalb der Blocks, das sich am Beginn von Block 900 befindet, und einen Objekt-Speicherteil 920.
Die Einträge 955 und 965 im Verzeichnis 910 entsprechen jeweils einem anderen Objekt 950 und 960, die sich in dem Objekt-Speicherteil 920 von Block 900 befinden. Jeder Verzeichniseintrag enthält einen Wert für ein ID-Feld 912, welcher das entsprechende Objekt identifiziert, einen Wert für ein OFFSET-Feld 915, welcher den relativen Speicherplatz des entsprechenden Objekts in dem Block 900 darstellt, und einen Wert für ein SIZE-Feld 917, welcher den Teil von Block 900 angibt, der dem entsprechenden Objekt zugeteilt ist.
Die Objekte 950 und 960 sind vorzugsweise als Zeichenfolge formatiert, obwohl andere Techniken verwendet werden können.
Nochmal zu Fig. 8: Die lokale Klassen-Datenbank 800 enthält vorzugsweise einen NAME-TO-ID-INDEX 830, welcher den Objekten ermöglicht abgerufen zu werden, indem ihre Namen mit Objektkennungen korreliert wird.
Die Objektkennungen sind in ID-TO-BLOCK NO.MAP 840 enthalten. Die Karte 840 stellt für jedes einzigartige Objekt Blocknummern bereit, das in der lokalen Klassen-Datenbank 800 identifiziert wird.
Das restliche Feld in der lokalen Klassen-Datenbank 800 ist BLOCK TABLE 850. BLOCK TABLE 850 enthält vorzugsweise die Speicherplätze der Blocks 820, 822 und 824 und die Speicherplätze des zur Verfügung stehenden Platzes 829 innerhalb der lokalen Klassen-Datenbank 800. Der zur Verfügung stehende Platz 829 ist der unverwendete Platz des Blockspeicherplatzes 815, der von der lokalen Klassen- Datenbank 800 alloziert wird.
Um ein Objekt von der lokalen Klassen-Datenbank 800 abzurufen, wird der Name dieses Objekts dem NAME-TO-ID-INDEX 830 zugeordnet. Die Kennungsinformation von NAME-TO-ID-INDEX 830 wird dann der entsprechenden Blocknummer zugeordnet, indem die ID-TO-BLOCK NO.MAP 840 verwendet wird.
Die Zuordnung liefert die Blocknummer, wo das gewünschte Objekt sich im Moment befindet. Wenn der Block mit dem gewünschten Objekt einmal ausfindig gemacht ist, wird das Objekt gefunden, indem das Objekt-Verzeichnis 910 verwendet wird (Fig. 9).

(3) Die Lade-/Entladeeinrichtung

Wie in Fig. 10 gezeigt, wird eine Lade-/Entladeeinrichtungs- (LOADER/UNLOADER) Software-Komponente 1010 vorzugsweise mit einer lokalen Klassen-Datenbank 1000, einer globalen Klassen-Datenbank 1020 und einem Knoten-Cachespeicher 1030 verbunden. Die Lade-/Entladeeinrichtungs-Software-Komponente 1010, welche ein Teil der ACAS-Softwarekomponenten 130, 230 und 330 (Fig. 1) ist, wird verwendet, um die Übertragung von ACAS-Informationen zu und von der lokalen Datenbank 1020, dem Knoten-Cachespeicher 1030 und der globalen Klassen-Datenbank 1020 zu steuern. In der bevorzugten Realisierung gestattet die Lade- /Entladeeinrichtungs-Software-Komponente 1010 der lokalen Klassen-Datenbank 1000, Informationen in die globale Klassen-Datenbank 1020 zu laden, und ermöglicht dem Knoten-Cachespeicher 1030, Klassen-Datenbank-Informationen von der globalen Klassen-Datenbank 1020 zurückzugewinnen. Während des Ladens und Entladens verwendet die Lade-/Entladeeinrichtungs-Komponente 1010 zum Speichern vorzugsweise den Speicher 150.
Die Lade-/Entladeeinrichtungs-Software-Komponente 1010 wird durch einen Benutzer aktiviert, der die Klassen-Informationen in der lokalen Klassen-Datenbank 1000 zur globalen Klassen-Datenbank 1020 zu übertragen wünscht. Die Übertragung macht die vorher nur für die Plattform zugänglichen Informationen für alle Netzwerk- Benutzer in der globalen Klassen-Datenbank 1020 zugänglich. Die Übertragung von Klassen-Informationen von der lokalen Klassen-Datenbank 1000 zu der globalen Klassen-Datenbank 1020 wird vorzugsweise durch Senden der Klassen- und Methoden-Objektdefinitionen in einem ASCII-Format an die Lade-/Entladeeinrichtungs- Software-Komponente 1010 zum Laden in die globale Klassen-Datenbank erreicht. Die Lade-/Entladeeinrichtungs-Software-Komponente 1010 führt vorzugsweise einen Prozeß durch, um Sprachdefinitionen, die in der lokalen Klassen-Datenbank gespeichert sind, zu analysieren, und übersetzt diese Definitionen in eine entsprechende ASCII-Darstellung. Die Lade-/Entladeeinrichtung 1010 formatiert dann diese ASCII- Darstellung, damit sie von der globalen Klassen-Datenbank in einem geeigneten Format gespeichert wird.
Die Lade-/Entladeeinrichtungs-Software-Komponente 1010 muß auch auf Anforderungen von dem Benutzer reagieren, um Informationen von der globalen Klassen-Datenbank 1020 zu entladen oder zurückzugewinnen, um sie in den Knoten- Cachespeicher 1030 zu laden. Die zurückgewonnenen Informationen werden vorzugsweise durch die Lade-/Entladeeinrichtungs-Software-Komponente 1010 in die Sprachdefinitionen übersetzt, welche in den Knoten-Cachespeicher 1030 gespeichert werden.

F. Erstellen und Definieren/Registrieren von Klassen und Methoden

(1) Erstellung

Vorzugsweise Klassen werden unter Verwendung einer nicht-verfahrensorientierten Programmiersprache, wie z. B. der in der Lade-/Entladeeinrichtung verwendeten, definiert und dann kompiliert und in eine Klassen-Datenbank geladen. Die Sprache, der Kompilierer und die Lade-Software sind vorzugsweise Komponenten einer Objekt-Definitionseinrichtung. Andere wohlbekannte Techniken würden für Fachleute auch offensichtlich sein.
Die Objekt-Definitionseinrichtung ist Teil der ACAS-Softwarekomponenten 130, 230 und 330 (Fig. 1) und stellt eine Einrichtung bereit, um Klassen, Nachrichten, Klassen-Attribute, Methoden und Methoden-Attribute festzulegen. Diese Einrichtung sieht auch die Spezifikation der Vererbung unter den Klassen vor und kann, zusammen mit der Lade-/Entladeeinrichtungs-Software-Komponente 1010, die oben beschrieben wurde, verwendet werden, um die bestehenden Definitionen innerhalb der globalen Klassen-Datenbank und der lokalen Klassen-Datenbank zu modifizieren. Zusätzlich führt die Objekt-Definitionseinrichtung vorzugsweise die nötigen Syntaxprüfungen der Klassendefinitionseingabe und Methoden-Definitionseingabe durch, die verwendet wird, um neue Klassen- und Methoden-Definitionen innerhalb der globalen Klassen-Datenbank zu schaffen.
Ein Benutzer der Objekt-Definitionseinrichtung muß bestimmte Informationen spezifizieren, um eine Klasse zu schaffen. Diese Informationen umfassen vorzugsweise: einen globalen Klassennamen und eine globale Klassenkennung; globale Namen und Kennungen (wenn existent) der Überklassen dieser Klasse; Nachrichten, die von dieser Klasse unterstützt werden, zusammen mit ihren entsprechenden Arten von Argumenten (wenn existent); festgelegte Methoden-Karten und die Nachrichten, auf welche sich jede Karte bezieht; und Attribute, die für diese Klasse definiert sind.
Jede Nachricht wird vorzugsweise durch Schaffung einer Architektur einschließlich des Namens der Nachricht, der Parameter, die durch die Nachricht unterstützt werden, und eine entsprechende Methoden-Karte spezifiziert. Jede Nachrichtenstruktur wird in der bevorzugten Realisierung in zwei Gruppen von Werten umgewandelt. Eine Gruppe von Werten enthält den Nachrichten-Namen und die Liste der Parameter, die von der Nachricht unterstützt werden. Die andere Gruppe von Werten legt eine Gruppe von Methoden-Objekten fest, welche die Realisierungen der Nachricht darstellen.
Die Methoden-Objekte werden innerhalb der Netzwerkumgebung in der gleichen Weise wie die Klassen definiert. Die Objekt-Definitionseinrichtung der bevorzugten Realisierung hat jedoch besondere Bestimmungen für das Definieren von Methoden-Objekten. Die folgenden Informationen werden spezifiziert, wenn ein Methoden- Objekt definiert wird; der globale Name und die globale Kennung des Methoden- Objekts; die globalen Namen und Kennungen der Überklassen der Methoden-Objekte; und Metadaten (d.h. Beschreibungen von Daten), die als Methoden-Attribute gespeichert sind. Die Methoden-Definition spezifiziert auch die Argumente und ihre Arten entsprechend den Parametern in der Nachricht, und ob die Methode eine Parameter-Liste enthält. Diese Parameter-Liste stellt die Eingabe dar, die von dem ablauffähigen Code (nachfolgend beschrieben), der geeignet ist, von der Methode aufgerufen zu werden, gewünscht wird.

(2) Methoden-/Klassen-Definition

In der bevorzugten Realisierung kann das Laden von Klassen- und Methoden- Definitionen entweder vor der Laufzeit oder dynamisch während der Laufzeit geschehen. Klassen- und Methoden-Objekte können entweder lokal an einem Knoten innerhalb des Netzwerks ("lokale Definition" genannt) zugänglich sein oder allgemein von allen Plattformen in dem Netzwerk ("globale Definition" genannt). Sowohl die lokale als auch die globale Definition kann durchgeführt werden, indem die Lade-/Entladeeinrichtungs-Software-Komponente 1010 oder irgendeine andere annehmbare Einrichtung verwendet wird.

(3) Server-Registrierung

Der Zweck der Server-Registrierung ist, Methoden-Server zu finden, die für Dienstanforderungen von Nachrichten zur Verfügung stehen. Methoden-Server sind die aktiven (d.h. momentan laufenden) Operationen, die die Methoden realisieren. Ein Methoden-Server kann die Ausführung des Codes einer einzelnen Anwendung oder von vielen Teilen des Codes einer oder mehrerer Anwendungen enthalten.
Die Registrierung von Methoden-Servern ist verschieden von der Definition der Klassen- und Methoden-Objekte. Während die Definition von Klassen- und Methoden-Objekten verwendet wird, um ihre Anwesenheit in dem System zu kennzeichnen, wird die Registrierung von Methoden-Servern verwendet, um ihren Status (d.h. ihre Verfügbarkeit) zu verfolgen. Wenn ein Methoden-Server nicht registriert wird, ist er für das System nicht bekannt.

(4) Anwendungsinstallation & Definition

Vorzugsweise Unterstützungseinrichtungen werden für das Registrieren und Installieren von Anwendungen in dem Netzwerk vorgesehen. Die bevorzugte Realisierung schafft die Fähigkeit, Anwendungen und Anwendungsfragmente in dem objektorientierten Modell der Klassen, Unterklassen, Nachrichten und Methoden, die in einer Klassen-Datenbank gespeichert sind, zu definieren. Die Definition von Anwendungen ist in dieser Art kritisch für den Prozeß der Zwischen-Anwendungs-Kommunikation, die von der bevorzugten Realisierung dieser Erfindung ausgeführt wird. Besonders das Speichern von Klassen, Unterklassen, Nachrichten und Methoden in einer Klassen-Datenbank erlaubt einer Anwendung, während der Laufzeit die Klassen- Datenbank zu aktualisieren und unter Verwendung der aktualisierten Klassen-Datenbank die Datenverarbeitung fortzusetzen, ohne sie neu kompilieren und verbinden zu müssen.
Anwendungen werden auf die gleiche Weise definiert wie andere Klassen. Tatsächlich wird, wie oben erklärt, eine Anwendung selbst definiert, eine bestimmte Sorte von Klasse zu sein.
Anwendungen werden auf eigenen Plattformen auf die Art installiert, wie es für das betreffende Betriebssystem auf dieser Plattform nötig ist. In der bevorzugten Realisierung dieser Erfindung erfordert die Installation einer Anwendung auch einige zusätzliche Funktionen. Z. B. muß eine Anwendung, wenn sie nicht schon definiert worden ist, ihre eigene Klassendefinition bereitstellen, die als eine Unterklasse der vorhandenen ACAS_APPLICATION definiert wird.
Die Anwendungs-Installation kann Klassendefinitionen benutzen, die schon installiert sind, oder kann neue Definitionen hinzufügen. Bei der Anwendungs-Installation kann eine Installationsprozedur die Klassendefinitionen, die von der Anwendung unterstützt werden, in entweder eine lokale Klassen-Datenbank oder die globale Klassen-Datenbank kompilieren und registrieren, wobei sie die Lade-/Entladeeinrichtungs-Software-Komponente 1010 verwendet, die oben beschrieben wurde, und sie muß die Methoden-Karten der Datenobjekt-Klassen aktualisieren, die durch die die neuen Anwendungen beeinflußt werden. Die Anwendungs-Installation beinhaltet auch die oben besprochenen Methoden-Objekt-Definitionsprozeduren.

G. Kontext-Objekt-Datenbanken

In der bevorzugten Realisierung dieser Erfindung stellt die Kontext-Objekt- Datenbank 630 (siehe Fig. 6) eine Einrichtung zum Definieren der Prioritäten, die zum Beschließen der Methoden verwendet werden müssen, bereit, eine Einrichtung um die Plattformen für die Ausführung einer Methode zu wählen, und um die Klassen- Datenbanken in dem Netzwerk zu lokalisieren. In dem Netzwerk 50 in Fig. 1 können mehrere Ebenen von Kontext-Objekt-Datenbanken existieren. Z. B. kann eine Ebene aus einer Benutzer-Kontext-Objekt-Datenbank und eine andere Ebene aus einer Gruppen-Kontext-Objekt-Datenbank bestehen. System-(oder Plattform-)Kontext- Objekt-Datenbanken können auch verwendet werden, um für Benutzer der ganzen Plattform Prioritäten festzulegen. Alle Kontext-Objekt-Datenbanken liefern Prioritäten während eines Methoden-Beschlusses, aber die Gruppen-Kontext-Objekt-Datenbank kann von den ACAS-Softwarekomponenten 130, 230 und 330 verwendet werden, um die Prioritäten von mehr als einem Benutzer zu erkennen, und die System-Kontext- Objekt-Datenbank kann verwendet werden, um die Prioritäten von mehr als einer Gruppe zu erkennen. Vorzugsweise werden die Datenbanken in der Kontext-Objekt- Datenbank 630 so verwendet, daß bei dem Methoden-Beschluß Prioritäten in den Benutzer-Kontext-Objekt-Datenbanken jene in den Gruppen-Kontext-Objekt-Datenbanken überlagern, was wiederum die System-Kontext-Objekt-Datenbanken überlagert.
Die Kontext-Objekt-Datenbank 630 sitzt auf der Plattform, die während einer speziellen Netzwerksitzung mit einem Benutzer verbunden ist. In der Login-Prozedur, die ausgeführt wird, wenn ein Benutzer in das Netzwerk eintritt, werden die in der mit dem Benutzer verbundenen Kontext-Objekt-Datenbank gespeicherten Informationen für späteren Gebrauch während der Funktion der ACAS-Software aufgerufen.
Fig. 11A zeigt ein bevorzugtes Speichersystem für eine Kontext-Objekt-Datenbank 1100. Die Kontext-Objekt-Datenbank 1100 enthält eine Methoden-Überlagerungstabelle 1110, eine Server-Knotentabelle 1150 und eine Klassen-Datenbank- Überlagerungstabelle 1170 sowie andere, benutzerdefinierte Tabellen 1180. Die Methoden-Überlagerungstabelle wird während des Methoden-Beschlusses verwendet, was nachfolgend ausführlich beschrieben wird, um in Abhängigkeit von einem Nachrichten-Namen und einer in einer Instanzbehandlung identifizierten Klasse eine bevorzugte Methode zu wählen. Die Server-Knotentabelle 1150 wird während der Aufrufer-Funktionen verwendet, was auch nachfolgend ausführlich beschrieben ist, um Plattformen in dem Netzwerk, die als Server-Plattform geeignet sind, zu wählen und lokalisieren. Die Klassen-Datenbank-Überlagerungstabelle 1170 definiert einen Auftrag zum Suchen nach Methoden- und Klassen-Informationen in den lokalen Klassen-Datenbanken.
Die Tabellen 1110, 1150 und 1170 sind systemgelieferte Tabellen. Benutzer können auch ihre eigenen Tabellen 1180 liefern, um ihre spezifischen Prioritäten zu bewirken.
Eine bevorzugte Realisierung einer Methoden-Überlagerungstabelle 1110 wird in Fig. 11B gezeigt. Die Methoden-Überlagerungstabelle 1110 enthält eine Tabelle von Methodenwähl-Attributnamen 1115 und den zugehörigen Werten 1120. Jeder Eintrag spezifiziert für einen Attributnamen 1150 einen bevorzugten Wert 1120. Z.B. wird in Fig. 11B die bevorzugte Plattform als VAX.VMS spezifiziert, und der bevorzugte Koppeltyp ist BUILT IN. Wenn mehr als eine Methode als Funktion einer Nachricht identifiziert wird, werden die Prioritäten in der Tabelle 1110 verwendet werden, um eine dieser Methoden zu wählen. Wenn kein Wert für ein Attribut spezifiziert wird, wird angenommen, daß es keine Priorität gibt.
Eine bevorzugte Realisierung einer Server-Knotentabelle 1150 der Kontext- Objekt-Datenbank 1100 wird in Fig. 11C gezeigt. Die Server-Knotentabelle 1150 ist eine geordnete Tabelle von Knoten in dem Netzwerk 50 von Fig. 1. Jeder der Einträge in der Tabelle 1150 entspricht einem Plattformtyp 1152 und der Speicherstelle der Knoten 1154 in dem Netzwerk 50 mit dem entsprechenden Plattformtyp, welcher verwendet werden kann, um die gewählte Methode zu realisieren. Z.B. identifiziert die Tabelle 1150 zwei Knoten für einen Plattformtyp TYPE A, Knoten a und Knoten b.
Fig. 11D enthält eine bevorzugte Realisierung der Klassen-Datenbank-Überlagerungstabelle 1170. Die Tabelle 1170 enthält mehrere Einträge, welche einen Namen einer lokalen Klassen-Datenbank 1172 und ihrer Speicherstelle 1174 enthalten.
Somit ist die Datenbank DB_SCH_LST für den Eintrag 1175 an den Speicherstellen db1 und db2 und wird vor anderen lokalen Klassen-Objekt-Datenbanken gesucht, die weiter unten auf der Tabelle 1170 aufgeführt sind.
Die bevorzugte Realisierung der vorliegenden Erfindung enthält eine Schnittstelle, die allen Benutzern des Netzwerks zur Verfügung steht, und welche die Fähigkeit bereitstellt, Kontext-Objekt-Datenbanken zu erzeugen und Einträge innerhalb jeder der System-Kontext-Objekt-Datenbanken hinzuzufügen, zu modifizieren und zu löschen. Diese Schnittstelle führt vorzugsweise eine Standardkompilierung durch, um diese Funktionen durchzuführen. Um z. B. einen Eintrag zu einer Kontext-Objekt-Datenbank hinzuzufügen, würde ein Benutzer unter Verwendung der vorgesehenen Schnittstelle einen Befehl eingeben. Der Befehl würde dann von den ACAS-Softwarekomponenten 130, 230 und 330 (Fig. 1) interpretiert werden, um den Standardkompilierer zu veranlassen, die von der Schnittstelle empfangenen Daten in das richtige Format zu übersetzen.

H. ACAS-Dienst

(1) Allgemeine Funktionen

Mit der vorhergehenden Beschreibung der bestimmten Komponenten der bevorzugten Realisierung dieser Erfindung sollte ein besseres Verständnis der ACAS- Komponenten gewonnen werden. Vorzugsweise wird die vorliegende Erfindung realisiert, indem ein Client-/Server-Modell verwendet wird, bei welchem ein Client Anforderungen stellt und ein Server auf die Anforderungen antwortet. In der folgenden Besprechung wird der Dienst oder der Prozeß, der mit einer Client-Anwendung auf einer Client-Plattform verknüpft ist, "Client-Dienst" genannt, und der Dienst oder der Prozeß, der mit einer Server-Anwendung verknüpft ist, die auf einer Server-Plattform durchgeführt wird, "Server-Dienst" genannt. Der Client-Dienst und der Server-Dienst der bevorzugten Realisierung verlassen sich auf ein Transportsystem, welches zum Übertragen von Nachrichten von der Clientplattform zu und von der Server-Plattform geeignet ist. In der bevorzugten Realisierung wird ein RPC-ähnliches Kommunikationssystem als Transportsystem verwendet.
Jede der in Fig. 1 gezeigten ACAS-Softwarekomponenten 130, 230 und 330 enthält vorzugsweise Client-Dienst-Komponenten und die Server-Dienst-Komponenten, welche entsprechend die Client- bzw. Server-Dienste darstellen. Dies wird z. B. in Fig. 12 gezeigt, welche ein Diagramm von zwei Piattformen 1200 und 1300 und einem Netzwerkbus 55 ist. Die Plattformen 1200 und 1300 können mit irgendeiner der Plattformen 100, 200 oder 300 in Fig. 1 entsprechen.
In den Plattformen 1200 und 1300 sind entsprechend die Speicher 1250 bzw. 1350 und die CPUs 1210 bzw. 1310 untergebracht. Die Elemente auf den Plattformen 1200 und 1300 funktionieren auf die gleiche Weise wie ähnliche Elemente, die oben mit Verweis auf Fig. 1 beschrieben wurden. Die CPU 1210 führt eine Client-Anwendung 1220 aus, und die CPU 1310 führt eine Server-Anwendung 1320 aus. Die CPUs 1210 und 1310 führen auch entsprechend OP SYS 1 1240 bzw. OP SYS 2 1340 und die entsprechenden ACAS-Softwarekomponenten 1230 bzw. 1330 aus.
Die ACAS-Softwarekomponenten 1230 und 1330 enthalten vorzugsweise jeweils die Absender-Software-Komponenten 1232 bzw. 1332, die Steuer-Server-Software-Komponenten 1234 bzw. 1334, die Aufrufer-Software-Komponenten 1236 bzw. 1336 und die Server-Software-Komponenten 1237 bzw. 1337. Meistens stellen die Aufrufer-Software-Komponenten 1236 und 1336 den Client-Dienst und die Absender- Software-Komponenten 1232 und 1332 den Server-Dienst dar. Die Hilfs-Software- Komponenten 1237 und 1337 stellen einige andere Operationen der bevorzugten Realisierung dar. Da die Plattformen 1200 und 1300 in dem Netzwerk eine entsprechende Aufrufer-Software-Komponente 1236 bzw. 1336, eine entsprechende Steuer- Server-Software-Komponente 1234 bzw. 1334 und eine entsprechende Absender- Software-Komponente 1232 bzw. 1332 enthalten, kann die Plattform entweder als Client oder als Server dienen.
In der bevorzugten Realisierung haben die Aufrufer-Software-Komponenten 1236 und 1336 und die Absender-Software-Komponenten 1232 und 1332 die Verantwortung für das Interpretieren der Klassen- und Methoden-Informationen in den Klassen-Datenbanken, sowie der Kontext-Daten in der Kontext-Objekt-Datenbank, um die geeignete Methode zum Aufrufen festzulegen, um festzulegen, wie diese Methode aufzurufen ist, und um die nötigen Kommandos abzuschicken, damit der Code zum Realisieren der Methode ausgeführt wird. Die Aufrufer-Software-Komponenten 1236 und 1336 und die Absender-Software-Komponenten 1232 und 1332 isolieren auch die Client-Anwendungen von den Einzelheiten des Methoden-Aufrufs und den Transportebene-Einrichtungen.
Die Steuer-Server-Software-Komponenten 1234 und 1334 haben mehrere Funktionen. Eine Funktion ist, Informationen über augenblicklich laufenden Server- Anwendungen auf den Plattformen 1200 und 1300 in dem Netzwerk 50 zu speichern. Die Steuer-Server-Software-Komponenten 1234 und 1334 führen auch Operationen aus, um neue Anwendungen zu starten, welche Methoden-Server werden. Eine andere Funktion, die von den Steuer-Server-Software-Komponenten 1234 und 1334 durchgeführt wird, ist die Methoden-Server-Registrierung. Z. B. speichert die Steuer- Server-Software-Komponente 1334 Informationen hinsichtlich des Methoden-Servers der durch die Server-Anwendung 1320, welche augenblicklich auf der Server-Plattform 1300 läuft, identifiziert wird. Die Steuer-Server-Software-Komponente 1334 kommuniziert auch mit der Server-Registrier-Einrichtung in dem netzwerkumspannenden Speicher 704 (Fig. 7), um die Statusinformation hinsichtlich der Server-Anwendung 1320 zu speichern.
Die Hilfs-Software-Komponenten 1237 bzw. 1337 stellen Funktionen der ACAS-Softwarekomponenten 1230 und 1330 dar, wie z. B. Klassen- und Methoden- Objekt-Definition und -Registration, Methoden-ausführbare Registrierung (nachfolgend beschrieben) in einem Methoden-ausführbaren Katalog von jeder Plattform und Funktionen der Lade-/Entladeeinrichtungs-Software-Komponente 1010 (Fig. 10).
Für die folgende Beschreibung wird die Plattform 1200 als Clientplattform bezeichnet und die Plattform 1300 wird als Server-Plattform bezeichnet. In diesem Beispiel kommuniziert die Client-Anwendung 1220 mit der Server-Anwendung 1320 auf der Server-Plattform 1300 auf eine objektorientierte Art. Es ist gemäß der vorliegenden Erfindung und in der bevorzugten Realisierung für eine Client-Anwendung auf einer Plattform auch möglich, mit einer Server-Anwendung auf der gleichen Plattform zu kommunizieren.
Wenn die Client-Anwendung 1220 mit der Server-Anwendung 1320 kommuniziert, sind die Absender-Software-Komponente 1232 und die Steuer-Server-Software-Komponente 1234 der Clientplattform 1200 nicht beteiligt, und daher sind sie in Fig. 12 schraffiert. Die Aufrufer-Software-Komponente 1336 der Server-Plattform 1300 ist gleichfalls schraffiert, weil sie nicht aktiv ist.
Fig. 13 ist ein Flußdiagramm 1360, das die Hauptfunktionen, die in einem Aufruf einer Methode gemäß der bevorzugten Realisierung ausgeführt werden, darstellt. Vor dem Beginnen der Schritte im Flußdiagramm 1360 sind die ACAS-Softwarekomponenten 1230 und 1330 am Anfang in einem "Warte-"Zustand.
Wenn die Client-Anwendung 1220 eine Methoden-Aufruf-Anforderung überträgt, beginnen die Operationen der ACAS-Softwarekomponenten 1230 und 1330, die in Fig. 13 gezeigt sind. Diese Methoden-Aufruf-Anforderung enthält eine Eingabe- Nachricht, welche die gewünschte Funktion der Client-Anwendung 1220 identifiziert.
Als erstes wird die Methoden-Aufruf-Anforderung von der Aufrufer-Software- Komponente 1236 (Schritt 1370) empfangen, welche die Methoden-Aufruf-Anforderung verarbeitet (Schritt 1375). Der Aufrufer-Prozeß wird nachfolgend genauer beschrieben. Das übliche Ergebnis des Aufrufer-Prozesses ist eine verarbeitete Methoden-Aufruf-Anforderung.
Die Aufrufer-Software-Komponente 1236 überträgt dann die verarbeitete Methoden-Aufruf-Anforderung über den Netzwerkbus 55 an die Absender-Software- Komponente 1332 (Schritt 1380). Die Absender-Software-Komponente 1332 und der Steuer-Helfer 1334 beginnen dann ihre Operationen.
Nach dem Empfangen der verarbeiteten Methoden-Aufruf-Anforderung veranlassen die Absender-Software-Komponente 1332 und die Steuer-Server-Software- Komponente 1234, daß die durch die Aufruf-Anforderung identifizierte Methode von der Server-Anwendung 1320 ausgeführt wird (Schritt 1390). Sobald die Server-Anwendung 1320 die Ausführung der Methode beendet, gibt sie mögliche Argumente aus, die bei der Ausführung entstehen, und die Absender-Software-Komponente 1332 erzeugt eine Statusmeldung (z. B. "erfolgreich"). Die Ausgabeargumente und die Statusmeldung werden der verarbeiteten Methoden-Aufruf-Anforderung zugeordnet, die nun "Antwort" genannt wird. Diese Antwort wird dann von der Absender- Software-Komponente 1332 zu der Aufrufer-Software-Komponente 1236 übertragen. Die Aufrufer-Software-Komponente 1236 beendet ihre Verarbeitung, indem sie die Antwort, die sie von der Absender-Software-Komponente 1332 erhalten hat, der originalen Methoden-Aufruf-Anforderung zuordnet, und an die Client-Anwendung 1220 zurückgibt (Schritt 1395).
Die vorhergehende Erklärung der ACAS-Softwarekomponenten 1230 und 1330 erlaubt eine größere Würdigung des Informationsflusses in der bevorzugten Realisierung dieser Erfindung. Fig. 14 zeigt zusätzliche Elemente des Netzwerks 50, die durch einen Fluß von Informationen von der Aufrufer-Software-Komponente 1236 zu der Absender-Software-Komponente 1332 beeinflußt werden. Zusätzlich zu der Client-Anwendung 1220, der Server-Anwendung 1320, der Aufrufer-Software-Komponente 1236, der Absender-Software-Komponente 1332 und der Steuer-Server-Software-Komponente 1234 enthält Fig. 14 die Kontext-Objekt-Datenbanken 630 (Fig. 6), die Klassen-Datenbanken 640 (Fig. 6), eine Server-Registrierungs-Einrichtung 1420 und eine Steuer-Server-Registratur 1425, welche von der Steuer-Server-Software- Komponente 1234 erzeugt wird und den ausführbaren Code auf der Server-Plattform überwacht.
Wie in Fig. 14 gezeigt, enthalten die Kontext-Objekt-Datenbanken 630 eine Benutzer-Kontext-Objekt-Datenbank 1402, eine Klassen-Kontext-Objekt-Datenbank 1404 und eine System-Kontext-Objekt-Datenbank 1406, von denen jede oben in der Beschreibung der Kontext-Objekt-Datenbanken beschrieben worden ist. Die Klassen- Datenbanken 640 enthalten eine lokale Datenbank 1000 (Fig. 10), einen Knoten- Cachespeicher 1030 und eine globale Klassen-Datenbank 1020. Jedes dieser Elemente von Klassen-Datenbanken 640 ist oben bei der Beschreibung der Klassen- Datenbanken beschrieben worden.
Wie oben erklärt, beginnt der Fluß der Informationen, wenn die Client-Anwendung 1220 eine Methoden-Aufruf-Anforderung erzeugt, welche zu der Aufrufer-Software-Komponente 1236 geschickt wird. Diese Schnittstelle wird vorzugsweise von einem InvokeMethod-Prozeduraufruf der bevorzugten Realisierung bereitgestellt.
In dem InvokeMethod-Prozeduraufruf übergibt die Client-Anwendung 1220 an die Aufrufer-Software-Komponente 1236 eine Instanzbehandlung, eine Nachricht (einschließlich einem Nachrichten-Namen und einer Parametertabelle), einer Kontext- Objekt-Abwicklung und, wahlweise, einer Ausgabe-Instanzbehandlung.
Wie oben ausführlich besprochen, ist die Instanzbehandlung eine Einheit, welche die momentane Instanz identifiziert, die die Client-Anwendung 1220 gewählt hat, um sie in den Methoden-Aufruf einzubeziehen. Der Nachrichten-Name stellt den gewünschten Prozeß an der Instanz dar. Die Nachrichten-Parameter-Liste besteht aus den Parametern, die von der Nachricht angefordert werden. Die Kontext-Objekt-Abwicklung ist ein Verweis, der die Kontext-Objekt-Datenbank identifiziert, die in dem Aufruf-Prozeß, der nachfolgend ausführlich beschrieben wird, verwendet werden soll. Die Ausgabe-Instanzbehandlung stellt eine Instanz des momentanen Methoden- Servers dar, der mit der aufgerufenen Methode verknüpft ist. Dies ermöglicht der Client-Anwendung, weiterhin einen Dialog mit dem gleichen Methoden-Server zu führen. Die Semantik der Ausgabe-Instanzbehandlung ist die gleiche wie die für die Instanzbehandlung.
Wenn die Aufrufer-Software-Komponente die Methoden-Aufruf-Anforderung empfängt, fragt die Aufrufer-Software-Komponente 1236 die Kontext-Objekt-Datenbanken 630 und die Klassen-Datenbanken 640 ab, um eine Methoden-Kennung zu finden. Diese Prozedur ist oben besprochen worden.
Nachdem die geeignete Methoden-Kennung für den Nachrichten-Namen ermittelt wurde, fragt die Aufrufer-Software-Komponente 1236 als nächstes die Server- Registrierungs-Einrichtung 1420 und die Kontext-Objekt-Datenbank 630 ab, um die Server-Plattform zu finden, auf welcher die mit der Methoden-Kennung verknüpfte Methode auszuführen ist. Die Server-Registrierungs-Einrichtung 1420 wird verwendet, um einen aktiven Methoden-Server (wenn vorhanden) ausfindig zu machen, der fähig ist, die mit der Methoden-Kennung verknüpfte Methode durchzuführen. Ein aktiver Methoden-Server ist ein Methoden-Server, wie z.B. die Server-Anwendung 1320, welche sich selbst dem Netzwerk 50 als schon gestartet bekannt gemacht hat.
Wenn es einen aktiven Methoden-Server gibt, fragt die Aufrufer-Software- Komponente auch die Server-Plattform-Tabellen der Kontext-Objekt-Datenbank 630 ab, um den Ort einer entfernten Plattform in dem Netzwerk 50 zu ermitteln (Fig. 1), welche der Benutzer der Client-Anwendung 1220 bevorzugen würde, um die Methode der Aufruf-Anforderung, die von der Aufrufer-Software-Komponente 1236 verarbeitet wurde, auszuführen. Wenn jedoch die Server-Anwendung 1320 nicht zur Verfügung steht, meldet die Steuer-Server-Software-Komponente 1234 der Aufrufer-Software- Komponente 1236, daß die Server-Anwendung nicht auf der gewählten entfernten Plattform zur Verfügung steht. Die Aufrufer-Software-Komponente 1236, beginnt, wie oben erläutert, erneut mit der Abfrage der Server-Plattform-Tabelle der Kontext-Objekt-Datenbanken 630 und der Server-Registrierungs-Einrichtung 1420, um eine andere Plattform in dem Netzwerk 50 zu wählen, auf welcher die identifizierte Methode auszuführen ist.
Als nächstes überträgt die Aufrufer-Software-Komponente 1236 eine Abfrage an die Steuer-Server-Software-Komponente 1234 der bevorzugten Server-Plattform, welche die Steuer-Server-Software-Komponente 1234 veranlaßt, eine Steuer-Server- Registratur 1425 abzufragen, um zu ermitteln, ob der gewünschte Methoden-Server auf der bevorzugten Server-Plattform zur Verfügung steht, um die in der verarbeiteten Methoden-Aufruf-Anforderung identifizierte Methode zu verarbeiten. Die Verfügbarkeit eines Methoden-Servers wird in der bevorzugten Realisierung durch Prüfen in der Steuer-Server-Registratur 1425 ermittelt, um herauszufinden, ob der Methoden- Server momentan fähig ist, die von den Client-Anwendungen aufgerufene Methode zu verarbeiten.
Wenn die Steuer-Server-Software-Komponente 1234 der Aufrufer-Software- Komponente 1236 anzeigt, daß der Methoden-Server in Form der Server-Anwendung 1320 zur Verfügung steht, überträgt die Aufrufer-Software-Komponente 1236 die verarbeitete Methoden-Aufruf-Anforderung zu der Absender-Software-Komponente 1332 der Server-Plattform. Die Aufrufer-Software-Komponente 1236 kann auch Informationen von der Kontext-Objekt-Datenbank 630 übertragen, welche dann von dem gewünschten Methoden-Server verwendet werden können.
Die Absender-Software-Komponente 1332 beginnt dann, die gewünschte Methode zu verarbeiten. Dieser Prozeß, der als "Absende-Prozeß" bezeichnet wird, beinhaltet im allgemeinen das Absenden der Methoden-Kennung, um die Ausführung der Methode durch die Server-Anwendung 1320 zu beginnen.
Wenn jedoch die Server-Registrierungs-Einrichtung 1420 nicht anzeigt, daß irgendwelche Kopien der Server-Anwendung 1320 momentan auf einer Plattform in dem Netzwerk laufen, dann kann die Aufrufer-Software-Komponente 1236 eine Anfrage an die Steuer-Server-Software-Komponente 1234 übertragen, wobei sie die von den Kontext-Objekt-Datenbanken 630 und den Klassen-Datenbanken 640 abgerufenen Informationen verwendet, um die Server-Anwendung 1320 zu starten. Nachdem die Server-Anwendung 1320 gestartet ist, fordert die Steuer-Server-Software-Komponente 1334 die Server-Registrierungs-Einrichtung 1420 auf, den netzwerkumspannenden Speicher 704 (Fig. 7) zu aktualisieren, um anzuzeigen, daß die Server-Anwendung 1320 läuft. Die Steuer-Server-Software-Komponente aktualisiert auch die Steuer-Server-Registratur 1405, um anzuzeigen, daß die Server-Anwendung 1320 zur Verfügung steht. Die Aufrufer-Software-Komponente 1236 überträgt dann die verarbeitete Methoden-Aufruf-Anforderung an die Absender-Software-Komponente 1332, um die der Methoden-Kennung der verarbeiteten Methoden-Aufruf-Anforderung entsprechende Methode auszuführen.
Nachdem die Server-Anwendung 1320 ihre Verarbeitung abgeschlossen hat, schickt sie irgendwelche von der verarbeiteten Methoden-Aufruf-Anforderung angeforderten Ausgabe-Informationen an die Absender-Software-Komponente 1332 zurück. Die Absender-Software-Komponente 1332 schickt dann eine Antwort, wie oben beschrieben, an die Aufrufer-Software-Komponente 1236 zurück, zusammen mit eventuellen Ausgabe-Informationen, die den Ausgabe-Argumenten der von der Absender-Software-Komponente 1332 erhaltenen verarbeiteten Methoden-Aufruf-Anforderung zugeordnet sind.

(2) Aufrufer-Operation

Der Teil der Operation des Methoden-Aufrufs, der von der Aufrufer-Software- Komponente 1236 ausgeführt wird, kann nun ausführlicher beschrieben werden. Vorzugsweise besteht dieser Teil aus mehreren getrennten Phasen, welche die Feststellung der richtigen aufzurufenden Methode (Methoden-Beschluß), die Server-Verbindung oder das Hochfahren und die Transport-Ebene-Kommunikationen beinhalten, um das Absenden einer Kennung an die richtige Methode, die von dem Methoden- Server oder einem anderen ablauffähigen Code durchgeführt werden muß, zu ermöglichen.
Die Fig. 15A - 15D und 16 enthalten Flußdiagramme der Prozeduren, die von der Aufrufer-Software-Komponente 1236 der Fig. 12 und 14 ausgeführt oder aufgerufen werden. Die Haupt-Steuerprozedur 1550 in den Fig. 15A - 15D stellt die Schritte 1370, 1375 und 1380 (Fig. 13) dar, die von der Aufrufer-Software-Komponente 1236 durchgeführt werden.
Wie bei der Prozedur 1360 läuft vor dem Beginnen der Haupt-Steuerprozedur 1550 die Client-Anwendung 1220 (Fig. 12 und 14) normal ohne eine Methoden- Aufruf-Anforderung, und die ACAS-Softwarekomponente 1230 ist in einem "Warte"- Zustand. Wenn die Client-Anwendung 1220 eine Methoden-Aufruf-Anforderung erzeugt, wobei sie den InvokeMethod-Prozeduraufruf verwendet, dann beginnt die Haupt-Steuerprozedur 1550 (Schritt 1552 in Fig. 15A), wobei die Aufrufer-Software- Komponente 1236 die Methoden-Aufruf-Anforderung empfängt (Schritt 1555).
Die Aufrufer-Software-Komponente 1236 macht die Methoden-Aufruf-Anforderung gültig (Schritt 1557). Wenn es einen Fehler gab, erzeugt die Aufrufer-Software-Komponente 1236 eine Fehlermeldung (Schritt 1558), welche die Aufrufer- Software-Komponente 1236 zu der Client-Anwendung 1220 zurückschickt (Schritt 1599 in Fig. 15D).
Wenn die Methoden-Aufruf-Anforderung gültig ist (Schritt 1557 in Fig. 15A), beschließt die Aufrufer-Software-Komponente 1236 als nächstes die Methode, die von der Nachricht in dem InvokeMethod-Aufruf aufzurufen ist, die Klassen-Datenbanken und die Kontext-Objekt-Datenbanken 630 (Schritt 1560). Der Methoden-Beschluß ist der Prozeß des Feststellens oder Identifizierens der entsprechenden Methode.
Fig. 16 zeigt eine bevorzugte Prozedur 1600, um Methoden zu beschließen. Obwohl oben auf den Methoden-Beschluß Bezug genommen wurde, zeigt die Prozedur 1600 einen solchen Beschluß viel ausführlicher, als bisher.
In der bevorzugten Realisierung wird die Feststellung der richtigen aufzurufenden Methode indirekt von der Aufrufer-Software-Komponente 1236 bearbeitet. Die meiste Arbeit für den Methoden-Beschluß wird dann von den Hilfs-Software-Komponenten 1237 und 1337 der ACAS-Softwarekomponenten 1230 und 1330 bearbeitet. In der bevorzugten Realisierung ruft die Hilfs-Software-Komponente 1237 Informationen von den Kontext-Objekt-Datenbanken und den Klassen-Datenbanken ab. Natürlich könnte die Aufrufer-Software-Komponente 1236 auch solche Informationen abrufen.
Nach dem Beginnen der Methoden-Beschluß-Prozedur 1600 (Schritt 1605) legt die Aufrufer-Software-Komponente 1236 fest, ob die Instanzbehandlung den Speicherklassen-Namenteil (Schritt 1610) enthält. Wenn eine Speicher-Klasse existiert, wird sie ausfindig gemacht (Schritt 1620) und eine spezielle Methode wird aufgerufen, um den Namen der Klasse abzurufen, der mit der Instanzbehandlung verknüpft ist (Schritt 1630).
Nach dem Aufrufen der von der Speicher-Klasse identifizierten Methode, um den Klassennamen abzurufen, oder nach dem Feststellen, daß die Instanzbehandlung den Speicher-Klasse-Namen nicht enthielt, wird ein Prozeß durch die Aufrufer- Software-Komponente 1236 durchgeführt, um die Klassen-Informationen für die Klassen-Datenbanken 640 ausfindig zu machen (Fig. 6 und 14), wobei die oben beschriebene Suchreihenfolge verwendet wird (Schritt 1640). Wenn z. B. die Nachrichten EDIT (INSTANCE_HANDLE) war, wobei die Instanzbehandlung ASCII_FILE/NODE_1/MYFILE.TXT war, kann der Klassenname ASCII_FILE verwendet werden, um die Klasse ASCII_FILE 1645 in den Klassen-Datenbanken 640 zu finden.
Mit dem Namen der Nachricht, EDIT, wird die geeignete Methoden-Karte 1655 dann von den Klassen-Datenbanken 640 zurückgewonnen (Schritt 1650). In dem spezifischen Beispiel in der Beschreibung würde die Hilfs-Software-Komponente 1237 der bevorzugten Realisierung dann die Methoden-Karte 1655 abrufen und prüfen, um sicherzugehen, daß die in dem Schritt 1640 befindlichen Klassen-Informationen den Nachrichten-Namen EDIT enthalten. Dies stellt sicher, daß die entsprechende Nachricht von der Klasse unterstützt wird.
Wie Fig. 16 zeigt, enthält die Methoden-Karte 1655 die Methoden-Objekte METHOD 1 und METHOD 2 für den Nachrichten-Namen EDIT und die Klasse ASCII_FILE 1645. Verbunden mit dem Methoden-Objekt METHOD 1 ist ein Satz von Attributen 1657, und mit dem Methoden-Objekt METHOD 2 ist ein Satz von Attributen 1659 verbunden. Der Satz von Attributen 1657 zeigt an, daß METHOD 1 fähig ist, auf PLATFORM_TYPE A ausgeführt zu werden, und der Satz von Attributen 1659 zeigt an, daß METHOD 2 fähig ist, auf PLATFORM_TYPE B ausgeführt zu werden.
Weil es mehrere Methoden-Objekte in der Methoden-Karte geben könnte, wird auf die Kontext-Objekt-Datenbanken 630 Bezug genommen, um irgendwelche Zweideutigkeiten zu beseitigen (Schritt 1660). Bei der Bezugnahme auf die Kontext- Objekt-Datenbanken 630 wird die beibehaltene, geeignete Server-Knotentabelle 1150 auch abgerufen, um später verwendet zu werden.
Die Einträge (falls vorhanden) in den Kontext-Objekt-Datenbanken 630 werden dann mit den Attributen in dem Satz von Methoden-Objekten in der Methoden-Karte (Schritt 1670) verglichen, um das Methoden-Objekt und somit die geeignete Methode auszuwählen, um die gewünschte Funktion, die von der Nachricht dargestellt wird auszuführen (Schritt 1680). In Fig. 16 enthält eine Methoden-überlagernde Tabelle 1665 einen Eintrag 1668, der anzeigt, daß die Benutzerpriorität für PlatformType A ist. Unter Verwenung dieses Eintrags 1668 wählt die Aufrufer-Software-Komponente 1236 von den Klassen-Datenbanken 640 die geeignete Methode 1686, um die gewünschte Funktion EDIT auszuführen. In dem in Fig. 16 gezeigten Beispiel ist die geeignete Methode die Methode 1, die auf PLATFORM_TYPE A auszuführen ist. Die Prozedur 1600 kehrt nun zu der Haupt-Steuerprozedur 1550 von Fig. 15 zurück (Schritt 1685).
Wenn an irgendeinem Punkt während der Operation der Methoden-Beschluß- Prozedur 1600 ein Fehler vorkommt (wie z. B. während Schritt 1640, die bei der Instanzbehandlung identifizierte Klasse war nicht in den Klassen-Datenbanken aufzufinden), kehrt die Methoden-Beschluß-Prozedur 1600 mit einer Nachricht, die diesen Fehler anzeigt, zurück.
Nach der Rückkehr von der Methoden-Beschluß-Prozedur 1600 wird eine Feststellung durchgeführt, ob während des Methoden-Beschluß-Prozesses ein Fehler auftrat (Schritt 1562 in Fig. 15A). Wenn die Antwort "ja" ist, dann erzeugt die Aufrufer- Software-Komponente 1236 die entsprechende Fehlermeldung (Schritt 1563) und schickt die Fehlermeldung an die Client-Anwendung 1220 (Schritt 1599 in Fig. 15D).
Andernfalls, wenn die Methode ohne Fehler beschlossen wurde (Schritt 1562 in Fig. 15A), überprüft die Aufrufer-Software-Komponente 1236 dann die Methoden- Attribute entsprechend der Kennung der beschlossenen Methode, um die entprechende Methode auf einer entprechenden Plattform in dem Netzwerk auszufünren. Wenn diese Methoden-Attribute anzeigen, daß die Methode schon mit der Client- Anwendung 1220 verbunden ist (Schritt 1565 in Fig. 15B), z. B. der Wert des InteractionType-Methoden-Attributs "BUILT_IN" ist, dann wird eine Prüfung auf einen Aktivierungsfehler durchgeführt (Schritt 1566). Wenn es einen gab, wird eine Fehlermeldung erzeugt (Schritt 1576), und die Steuerung wird an die Client-Anwendung 1220 zurückgegeben (Schritt 1599 in Fig. 15D).
Wenn ein Fehler aufgetreten ist, wird ein Erfolgs-Flag generiert (Schritt 1567) und die beschlossene Methode wird von dem in der Client-Anwendung 1220 schon residenten Code ausgeführt (Schritt 1569).
Wenn die Methoden-Attribute nicht anzeigen, daß die Methode schon mit der Client-Anwendung 1220 verbunden worden ist (Schritt 1565 in Fig. 15B), fragt die Aufrufer-Software-Komponente 1236, ob die Methoden-Attribute anzeigen, daß die Methode dynamisch ladbar ist (Schritt 1570). Dynamisch ladbare Methoden stellen ablauffähige Methoden dar, welche mit ablauffähigem Code von Client-Anwendungen während der Laufzeit vereint werden können. Fachleute werden erkennen, daß eine dynamisch ladbare Methode eine ablauffähige Methode sein könnte, die durch eine Unterprozedur oder Funktion einer Client-Anwendung identifiziert ist. Vorzugsweise wird die Prüfung auf einen dynamisch ladbaren Methoden-Server durch die Feststellung erreicht, ob der Wert des InteractionType-Methoden-Attributs "DYNAMIC_LOAD" ist. Wenn ja, dann versucht die Aufrufer-Software-Komponente 1236, den durch die beschlossene Methode identifizierten ablauffähigen Code in die Client-Anwendung 1220 zu laden (Schritt 1572).
Wenn während des Ladens des ablauffähigen Codes (Schritt 1574) ein Fehler aufgetreten ist, dann erzeugt die Aufrufer-Software-Komponente 1236 eine Nachricht, die angibt, daß ein Ladefehler auftrat (Schritt 1576), und schickt die Ladefehler-Nachricht an die Client-Anwendung 1220 zurück (Schritt 1599 in Fig. 15D).
Andernfalls erzeugt die Aufrufer-Software-Komponente 1236 dann, wenn es keinen Ladefehler gab (Schritt 1574), ein Flag, das die erfolgreiche Beendigung des Methoden-Aufrufs anzeigt (Schritt 1567. Als nächstes wird der dynamisch geladene ablauffähige Code entsprechend der beschlossenen Methode ausgeführt (Schritt 1569) und die Steuerung kehrt zusammen mit irgendwelchen Ausgabe-Argumenten zu der Client-Anwendung 1220 zurück (Schritt 1599 in Fig. 15D). Irgendwelche Fehler, die beim Ausführen verbundener oder dynamisch ladbarer Methoden-Server auftraten, werden vorzugsweise als Parameterwerte zurückgeschickt.
Wenn die Methoden-Attribute eine früher verbundene oder dynamisch ladbare Methode nicht anzeigen (Schritt 1565 und 1570 in Fig. 15B), dann muß die Aufrufer- Software-Komponente 1236 einen laufenden Methoden-Server auf einer Plattform in dem Netzwerk, welches die beschlossene Methode bearbeiten kann, ausfindig machen, wie oben hinsichtlich der Fig. 14 beschrieben wurde.
Wenn die von der Server-Registrierungs-Einrichtung 1420 (Schritt 1578) abgerufenen Informationen anzeigen, daß es mindestens einen laufenden Methoden-Server gibt, der fähig ist, die von der beschlossenen Methode identifizierte Methode durchzuführen (Schritt 1579 in Fig. 15C), dann vergleicht die Aufrufer-Software-Komponente 1236 die von der Server-Registrierungs-Einrichtung 1420 abgerufenen Informationen mit den Einträgen in der Server-Knotentabelle, die sie von den Kontext- Objekt-Datenbanken 630 während der Methoden-Beschluß-Prozedur 1600 abgerufen hat, um eine Server-Plattform in dem Netzwerk zu wählen (Schritt 1580).
Nach dem Wählen einer Server-Plattform überträgt die Aufrufer-Software- Komponente 1236 einen QueryServer-Aufruf an die Steuer-Server-Software-Komponente 1334 der ausgewählten Server-Plattform (Schritt 1581). Das Funktionieren der Steuer-Server-Software-Komponente 1334 wird nachfolgend in Verbindung mit Fig. 17A und 17B ausführlich beschrieben. Kurz gesagt, die Steuer-Server-Software-Komponente 1334 ermittelt, ob der gewünschte Methoden-Server zur Verfügung steht oder nicht.
Die Haupt-Steuerprozedur 1550 der Aufrufer-Software-Komponente 1236 macht dann mit Schritt 1582 (Fig. 15C) weiter, indem sie eine von der Steuer-Server- Software-Komponente 1334 erzeugte Nachricht über die Verfügbarkeit des gewünschten Methoden-Servers empfängt und die Nachricht in ein von der Client- Plattform erkennbares Format übersetzt. Die Aufrufer-Software-Komponente 1236 ermittelt über die Steuer-Server-Software-Komponente 1334, ob der Methoden- Server entsprechend der beschlossenen Methode zur Verfügung steht, die von der beschlossenen Methode identifizierte Methode zu bearbeiten (Schritt 1583). Wenn der entsprechende Methoden-Server zur Verfügung steht, dann wird das Verarbeiten der Aufrufer-Software-Komponente 1236 in Fig. 15D mit der Frage fortgesetzt, ob der Methoden-Server ein asynchroner Methoden-Server ist (Schritt 1593 in Fig. 15D). Asynchrone Methoden-Server sind in der Technik bekannt.
Wenn der Methoden-Server asynchron ist (Schritt 1593), dann wird die Steuer- Server-Software-Komponente 1334 aufgerufen, indem der Signalserver-Aufruf verwendet wird, um den Methoden-Server zu signalisieren (Schritt 1594). Wenn der Methoden-Server nicht asynchron ist (Schritt 1593) oder nachdem ein asynchroner Methoden-Server signalisiert wurde (Schritt 1594), wird die verarbeitete Methoden- Aufruf-Anforderung einschließlich der Kennung für die Methode und der Informationen, die von den Kontext-Objekt-Datenbanken während des Methoden-Beschlusses abgerufenen wurden, in eine Datenstruktur gepackt, die für die Kommunikation in dem Netzwerk verwendet wird (Schritt 1595), und die Aufrufer-Software-Komponente 1236 überträgt dann die gepackte und verarbeitete Methoden-Aufruf-Anforderung an die Absender-Software-Komponente 1332. Die Operationen der Absender-Softwarekomponente 1332 wird nachfolgend mit Verweis auf die Fig. 18A und 18B beschrieben.
Nachem die Absender-Software-Komponente 1332 ihre Verarbeitung beendet und eine gepackte Antwort gesendet hat, empfängt die Aufrufer-Software-Komponente 1236 die gepackte Antwort (Schritt 1597), entpackt die Antwort (Schritt 1598) und schickt die Antwort an die Client-Anwendung 1220 zurück, um ihre Verarbeitung abzuschließen (Schritt 1599).
Wenn in der früheren Ermittlung (Schritt 1583 in Fig. 15C) herausgefunden wurde, daß der laufende Methoden-Server nicht zur Verfügung steht, stellt die Aufrufer-Software-Komponente 1236 fest, ob die Server-Registrierungs-Einrichtung 1420 anzeigte, daß irgenwelche andere laufende Methoden-Server fähig sind, die durch die beschlossene Methode identifizierte Methode durchzuführen (Schritt 1584). Wenn ja, dann werden die abgerufenen Informationen mit der Server-Knotentabelle in der Kontext-Objekt-Datenbank 630 verglichen, und ein QueryServer-Aufruf wird an die Steuer-Server-Software-Komponente 1334 geschickt (Schritt 1581).
Andernfalls wählt die Aufrufer-Software-Komponente den Server-Knoten mit der höchsten Priorität aus der Server-Knotentabelle (Schritt 1586). Mit der Steuer- Server-Software-Komponente 1334 dieser gewählten Server-Plattform wird dann unter Verwendung des StartServer-Aufrufs Kontakt aufgenommen, was der Steuer-Server-Software-Komponente 1334 angibt, das Starten der entprechenden Anwendung, welche der durch die beschlossene Methode identifizierten Methode entspricht, zu versuchen (Schritt 1587).
Nachdem die Steuer-Server-Software-Komponente 1334 ihre Verarbeitung abgeschlossen und eine Nachricht übertragen hat, empfängt die Aufrufer-Software- Komponente 1236 die übertragene Nachricht, welche sie dann entpackt (Schritt 1588).
Wenn die Anwendung gestartet und zu einem Methoden-Server wurde (Schritt 1589), dann beendet die Aufrufer-Software-Komponente 1236 ihre Operationen, welche schon beschrieben worden sind (Schritt 1593 in Fig. 15D). Wenn die Anwendung nicht gestartet wurde (Schritt 1589), dann fragt die Aufrufer-Software-Komponente 1236, ob es noch weitere Knoten in der Server-Knotentabelle der Kontext-Objekt-Datenbanken 630 gibt (Schritt 1590). Wenn nicht, dann wird eine Fehlermeldung erzeugt, die anzeigt, daß der Methoden-Aufruf nicht erfolgreich war, weil keine Server- Plattform ausfindig gemacht werden konnte (Schritt 1592), und daß eine Fehlermeldung an die Client-Anwendung 1220 zurückgeschickt worden ist (Schritt 1599 in Fig. 15D).
Wenn es jedoch andere Knoten in der Server-Knotentabelle gibt (Schritt 1590 in Fig. 15C), dann wird die Plattform mit der nächsthöchsten Priorität gewählt (Schritt 1591), und die Verarbeitung der Aufrufer-Software-Komponente 1236 kehrt zu Schritt 1589 in Fig. 15C zurück. Die aus den Schritten 1587, 1588, 1589, 1590 und 1591 bestehende Schleife wird durchgeführt, bis der Methoden-Server gestartet wird (Schritt 1589) oder bis keine weiteren Plattformen auf den Server-Plattform-Listen sind (Schritt 1590).

(3) Steuer-Server-Operation

Die Fig. 17A und 17B zeigen die Steuer-Server-Prozedur 1700, welche die Operationen der Steuer-Server-Software-Komponente 1334 darstellt. Fachleute werden viele andere Wege zur Realisierung der Funktionen der Steuer-Server-Software- Komponente 1334 kennen.
Nach dem Beginnen der Steuer-Server-Prozedur 1700 mit Schritt 1702 in Fig. 17A empfängt die Steuer-Server-Software-Komponente 1334 eine Steuer-Server- Nachricht (Schritt 1705). Als Reaktion ermittelt die Steuer-Server-Software-Komponente 1334, ob die Steuer-Server-Nachricht anzeigt, daß eine auf einer gemeinsamen Plattform mit der Steuer-Server-Software-Komponente 1334 laufende Anwendung fordert, als ein Methoden-Server registriert zu werden, um Methoden-Aufruf- Anforderungen zu bearbeiten (Schritt 1710). Wenn die Antwort "ja" ist, dann registriert die Steuer-Server-Software-Komponente 1334 die Server-Anwendung durch Aufzeichnen der nötigen Informationen über die Server-Anwendung mit der Steuer- Server-Registratur 1425 als einen Methoden-Server, um anzuzeigen, daß der Methoden-Server zur Verfügung steht. Die Steuer-Server-Software-Komponente 1334 benachrichtigt auch die Server-Registrierungs-Einrichtung 1420, sie möge anzeigen, daß der Methoden-Server in Betrieb ist (Schritt 1715). Der laufende und zur Verfügung stehende Methoden-Server kann auch entprechende Methoden ausführen. Die Steuer-Server-Software-Komponente 1334 erzeugt auch eine Erfolgsmeldung (Schritt 1729), die zu der nun registrierten Anwendung zurückgeschickt wird (Schritt 1799 in Fig. 17B).
Wenn die Steuer-Server-Nachricht nicht anzeigt, daß eine Anwendung wünscht, registriert zu werden (Schritt 1710 in Fig. 17A), dann ermittelt die Steuer- Server-Software-Komponente, ob die Steuer-Server-Nachricht anzeigt, daß ein laufender, registrierter Methoden-Server fordert, daß er mit der Steuer-Server-Software- Komponente 1334 und der Server-Registrierungs-Einrichtung 1420 aus der Registrierung gelöscht wird (Schritt 1720). Wenn ja, dann löscht die Steuer-Server-Software- Komponente 1334 die Registrierung des Methoden-Servers durch Entfernen der Informationen aus der Steuer-Server-Registratur 1425. Dies zeigt an, daß die von dem Methoden-Server identifizierte Anwendung nicht mehr zur Verfügung steht. Die Steuer-Server-Software-Komponente 1334 benachrichtigt auch die Server-Registrierungs- Einrichtung 1420, die in dem netzwerkumspannenden Speicher 704 gespeicherten Informationen zu entfernen (Schritt 1725) Die Steuer-Server-Software-Komponente 1334 erzeugt dann eine Erfolgsmeldung (Schritt 1729), die zu der nun unregistrierten Anwendung zurückgeschickt wird (Schritt 1799 in Fig. 17B).
Wenn die Steuer-Server-Nachricht nicht anzeigt, daß eine Anwendung gefordert hat, selbst registriert oder aus der Registrierung gelöscht zu werden, ermittelt die Steuer-Server-Software-Komponente 1334, ob die Steuer-Server-Nachricht anzeigt, daß die Aufrufer-Software-Komponente 1236 wünscht, einem asynchronen Methoden-Server zu signalisieren, zu erwarten, aufgerufen zu werden, um eine verarbeitete Methoden-Aufruf-Anforderung auszuführen (Schritt 1730). Wenn dies der Fall ist, führt die Steuer-Server-Software-Komponente 1334 einen Prozeß aus, der den asynchronen Methoden-Server signalisiert (Schritt 1735) und die Verarbeitung abschließt (Schritt 1799 in Fig. 17B).
Wie oben erläutert, kann die bevorzugte Realisierung dieser Erfindung sowohl mit Anwendungen arbeiten, die geschrieben wurden, um die Merkmale dieser Erfindung auszunützen, oder mit früher geschriebenen Anwendungen, die für die Benutzung mit der bevorzugten Realisierung modifiziert worden sind. Beim solchen Schreiben oder Modifizieren asynchroner Anwendungen, die mit der bevorzugten Realisierung arbeiten sollen, bezieht ein Benutzer Programmcode mit ein, der teilweise diese asynchronen Signale erkennt und, wie oben beschrieben, diese Signale und die folgenden verarbeiteten schlangestehenden Methoden-Aufruf-Anforderungen registriert. Diese Operationen werden nachfolgend mit Hinweis auf die Operationen beschrieben, die von der Absender-Software-Komponente 1332 ausgeführt werden.
Wenn keine anderen Funktionen angefordert worden sind, ermittelt die Steuer- Server-Software-Komponente 1334, ob die Steuer-Server-Nachricht anzeigt, daß die Aufrufer-Software-Komponente 1236 fordert, daß eine neue Anwendung, die auf der gleichen Plattform wie die Steuer-Server-Software-Komponente 1334 sitzt, gestartet werden sollte, um ein Methoden-Server zu werden, um eine Methode zu verarbeiten (Schritt 1740 in Fig. 17B). Wenn ja, dann prüft die Steuer-Server-Software-Komponente 1334 die Steuer-Server-Registratur 1425 (Schritt 1745), um zu ermitteln, ob die ablauffähige Methode der neuen Anwendung, die der beschlossenen Methode entspricht, auf der gewählten Plattform sitzt (Schritt 1750).
Die Steuer-Server-Registratur 1425 hat eine lokale Reichweite, so daß nur die Server-Plattform 1300 die residenten, ablauffähigen Methoden kennt. Die Registrierung der ablauffähigen Methoden in der Registratur 1425 beinhaltet die Registrierung des aktuellen ablauffähigen Codes in ablauffähigen Dateien, z. B. Kommandointerpreter-Manuskripten, die eine Methode realisieren, und den Status jener ablauffähigen Methode. Diese Elemente haben vorzugsweise nur einen lokalen Registrierungsbereich, weil es nicht notwendig ist, den ablauffähigen Code allgemein zu verwalten.
Wenn die entsprechende ablauffähige Methode in der Steuer-Server-Registratur 1425 identifiziert wird, dann kann die gewählte Plattform eine Server-Plattform sein. Die Steuer-Server-Software-Komponente 1334 führt einen Prozeß aus, um die entsprechende ablauffähige Methode zu starten, und registriert den resutierenden Methoden-Server mit der Server-Registrierungs-Einrichtung 1420 und mit der Steuer- Server-Registratur 1425, um anzuzeigen, daß der neu gestartete Methoden-Server sowohl läuft als auch zur Verfügung steht (Schritt 1752). Während dieses Startprozesses erzeugt die Steuer-Server-Software-Komponente 1334 auch eine Kontext- Objekt-Datenbank, die von dem gestarteten Methoden-Server verwendet werden kann. Als nächstes erzeugt die Steuer-Server-Software-Komponente 1334 dann eine Nachricht, die anzeigt, daß die Anwendung entsprechend der beschlossenen Methode gestartet worden ist und nun ein Methoden-Server ist (Schritt 1754). Diese Nachricht wird dann zu der Aufrufer-Software-Komponente 1236 übertragen, die forderte, daß der Methoden-Server gestartet wird (Schritt 1790), und die Steuer-Server-Software-Komponente 1334 hat ihre Verarbeitung abgeschlossen (Schritt 1799).
Wenn die ablauffähige Methode entsprechend der beschlossenen Methode in der Steuer-Server-Registratur 1425 nicht identifiziert wird, dann erzeugt die Steuer- Server-Software-Komponente 1334 eine entprechende Nachricht, die anzeigt, daß die ablauffähige Methode nicht gestartet worden ist (Schritt 1756). Diese Nachricht wird dann zu der Aufrufer-Software-Komponente 1236 übertragen, welche forderte daß der Methoden-Server gestartet wird (Schritt 1790), und die Steuer-Server-Software-Komponente 1334 hat ihre Verarbeitung abgeschlossen (Schritt 1799).
Wenn keine weitere Funktion angefordert worden ist, ermittelt die Steuer- Server-Software-Komponente 1334, ob die Steuer-Server-Nachricht eine Anforderung von der Aufrufer-Software-Komponente 1236 von Informationen bezüglich der Verfügbarkeit eines laufenden Methoden-Servers ist, um eine Methode, die durch die beschlossene Methode identifiziert wurde, auszuführen (Schritt 1760). Wenn nicht erzeugt die Steuer-Server-Software-Komponente 1334 eine Fehlermeldung (Schritt 1780), überträgt diese Nachricht an die Aufrufer-Software-Komponente 1236 (Schritt 1790) und schließt ihre Verarbeitung ab (Schritt 1799).
Andernfalls ruft die Steuer-Server-Software-Komponente 1334 die angeforderten Informationen über den laufenden Methoden-Server von der Steuer-Server-Registratur 1425 (Schritt 1765) ab. Wenn die Informationen von der Steuer-Server-Registratur 1425 anzeigen, daß der Methoden-Server, der von der beschlossenen Methode identifiziert wurde, zur Verfügung steht (Schritt 1770), dann erzeugt die Steuer- Server-Software-Komponente 1334 eine Nachricht, welche die Verfügbarkeit des Methoden-Servers anzeigt (Schritt 1775). Diese Nachricht wird dann zu der Aufrufer- Software-Komponente 1236 übertragen (Schritt 1790), und die Verarbeitung der Steuer-Server-Software-Komponente 1334 wird abgeschlossen (Schritt 1799).
Wenn jedoch die Steuer-Server-Software-Komponente 1334 anzeigt, daß der Methoden-Server nicht zur Verfügung steht (Schritt 1770), dann erzeugt die Steuer- Server-Software-Komponente 1334 eine Nachricht, welche die Nicht-Verfügbarkeit des Methoden-Servers anzeigt (Schritt 1777). Die Steuer-Server-Software-Komponente 1334 überträgt dann die erzeugte Nachricht an die Aufrufer-Software-Komponente 1236 (Schritt 1790) und die Verarbeitung der Steuer-Server-Software-Komponente 1334 wird abgeschlossen (Schritt 1799).

(4) Absender-Operation

Der Prozeß des Absendens der Methoden-Server besteht aus Absende- Methoden, die durch die Methoden-Server und Transport-Ebene-Kommunikation bearbeitet werden müssen. Die Absender-Software-Komponente 1332 bearbeitet auch verschiedene Arten von Methoden-Aufrufen.
Asynchrone Methoden-Aufrufe fordern nicht, daß die Client-Anwendung auf den identifizierten Methoden-Server wartet, um die Verarbeitung zu beenden. Z. B. kann die Aufruf-Anforderung in einer Schlange untergebracht werden, um ausgeführt zu werden, und der RPC-Transportebene-Aufruf kann zu der Aufrufer-Software- Komponente 1236 zurückkehren und der Client-Anwendung erlauben, ihre eigene Verarbeitung fortzuführen, ohne "blockiert" oder an der Fortsetzung gehindert zu sein. Die Schlange der verarbeiteten Methoden-Aufruf-Anforderungen, die von den Aufrufer-Software-Komponenten empfangen wurden, werden dann von der Absender- Software-Komponente 1332 geprüft, wie z. B. in einer Absender-Prozedur 1800 in Fig. 18, und gemäß einer vorher festgelegten Reihenfolge durchgeführt.
Asynchrone Methoden-Aufrufe können angefordert werden, wenn die Client- Anwendung nicht erwartet, von dem Methoden-Server eine Antwort zurückzubekommen. Die einzige Antwort wird eine Anzeige sein, ob der Methoden-Aufruf von einer ACAS-Softwarekomponente auf einer Server-Plattform erfolgreich empfangen worden ist. Die Antwort zeigt nicht an, ob die Ausführung erfolgreich war, und wird nicht irgendwelche Ausgaben des aktuellen Methoden-Aufrufs enthalten, wie sie es für synchrone Methoden-Aufrufe könnte.
Synchrone Methoden-Aufrufe sind der vorgegebene Modus für alle Methoden- Aufrufe. Mit asynchronen Methoden-Aufrufen erwartet die Client-Anwendung, welche die Methoden aufrief, eine Antwort, bevor sie ihre eigene Verarbeitung fortsetzt.
Die Fig. 18A und 18B sind ein Flußdiagramm der Prozeduren, die von der Absender-Software-Komponente 1332 der Fig. 12 und 14 aufgerufen wurden. Die Absender-Prozedur 1800 stellt die Schritte 1385, 1390 und 1395 (Fig. 13) dar, die von der Absender-Software-Komponente 1332 durchgeführt wurden.
Vor dem Beginnen der Absender-Prozedur 1800 ist die Absender-Software- Komponente 1332 in einem "Warte"-Status, wobei sie auf eine bearbeitete Methoden- Aufruf-Anforderung von einer Aufrufer-Software-Komponente in dem Netzwerk wartet. Nach dem Beginnen der Absender-Prozedur 1800 (Schritt 1802) empfängt die Absender-Software-Komponente 1332 über den Netzwerk-Transport-Dienst eine Transport-Datenstruktur. Diese Transport-Datenstruktur stellt eine gepackte und verarbeitete Methoden-Aufruf-Anforderung dar, die von einer Aufrufer-Software-Komponente in dem Netzwerk übertragen wurde (Schritt 1805). Nach dem Empfangen dieser Transport-Datenstruktur entpackt und übersetzt die Absender-Software-Komponente 1332 die Transport-Datenstruktur in eine Datenstruktur, die für die Server-Plattform erkennbar ist (Schritt 1810). Die Absender-Software-Komponente 1332 aktualisiert dann eine Kontext-Objekt-Datenbank, die mit dem laufenden Methoden-Server verknüpft ist (Schritt 1815). Eine Kontext-Objekt-Datenbank 1100 kann mit dem laufenden Methoden-Server verknüpft werden, indem sie entweder von der Steuer-Server- Software-Komponente 1334 geschaffen wird, wenn der Methoden-Server startet, oder indem ein Benutzer sich auf der Server-Plattform anmeldet und den Methoden-Server startet.
Die Absender-Software-Komponente 1332 fragt als nächstes, ob die verarbeitete Methoden-Aufruf-Anforderung, die sie erhält, eine asynchrone Aufruf-Anforderung ist, die von einem asynchronen Methoden-Server verarbeitet werden soll (Schritt 1820). Wenn nicht, dann fragt die Absender-Software-Komponente 1332, ob die Aufruf-Anforderung die Identifizierung einer gültigen Methode enthält, welche eine Methode ist, die von dem Methoden-Server bearbeitet werden kann (Schritt 1825). Wenn nicht, dann wird eine Fehlermeldung erzeugt (Schritt 1840), welche dann als Antwort gepackt (Schritt 1890 in Fig. 18B) und an die Aufrufer-Software-Komponente 1236 übertragen wird (Schritt 1895), bevor die Absender-Prozedur beendet wird (Schritt 1899).
Wenn die Aufruf-Anforderung die Identifizierung einer gültigen Methode enthält (Schritt 1825 in Fig. 18A), dann sendet die Absender-Software-Komponente 1332 die von der erhaltenen Aufruf-Anforderung identifizierte gültige Methode ab, um von dem Methoden-Server ausgeführt zu werden (Schritt 1830). Wenn ein Fehler während der Ausführung der gültigen Methode durch den Methoden-Server auftrat (Schritt 1835), erzeugt die Absender-Software-Komponente 1332 eine entprechende Fehlermeldung (Schritt 1849). Die Absender-Software-Komponente 1332 packt dann die Fehlermeldung zu einer Antwort (Schritt 1890 in Fig. 18B) und schickt die gepackte Fehlermeldung an die Aufrufer-Software-Komponente (Schritt 1895), bevor sie die Absender-Prozedur abschließt (Schritt 1899).
Wenn kein Ausführungsfehler auftrat (Schritt 1835 in Fig. 18A), dann packt die Absender-Software-Komponente 1332 eine Antwort (Schritt 1890 in Fig. 18B), welche in diesem Fall die verarbeitete Methoden-Aufruf-Anforderung ist, die irgendeine Ausgabe von dem Methoden-Server enthält, welcher die Methode bearbeitete, die von der beschlossenen Methode identifiziert wurde (Schritt 1860 in Fig. 15A). Nachdem die Antwort gepackt worden ist, wird sie zu der Aufrufer-Software-Komponente übertragen, welche ursprünglich die original bearbeitete Methoden-Aufruf-Anforderung sendete (Schritt 1895), und die Absender-Verarbeitung ist abgeschlossen (Schritt 1899).
Wenn die von der Absender-Software-Komponente empfangene verarbeitete Methoden-Aufruf-Anforderung eine asynchrone Aufruf-Anforderung ist (Schritt 1820 in Fig. 18A), dann wird die asynchrone Aufruf-Anforderung vorzugsweise in einer Schlange untergebracht, um von der Absender-Software-Komponente 1332 versandt zu werden, damit sie später als Methoden-Server verarbeitet wird (Schritt 1850). Eine Nachricht, die den Erfolg einer asynchronen Aufruf-Anforderung anzeigt, wird erzeugt (Schritt 1855), zu einer Antwort auf die erhaltene, verarbeitete Methoden-Aufruf-Anforderung gepackt (Schritt 1860) und dann an die Aufrufer-Software-Komponente geschickt, welche ursprünglich die verarbeitete Methoden-Aufruf-Anforderung schickte (Schritt 1865).
In der bevorzugten Realisierung führen asynchrone Methoden-Server asynchrone Methoden-Aufruf-Anforderungen in der Reihenfolge aus, in der sie zuvor in einer Schlange untergebracht wurden. Beim Ausführen der asynchronen Anforderungen fragt die Absender-Software-Komponente 1332, ob es irgendwelche Methoden- Aufruf-Anforderungen in der Schlange gibt, die von dem asynchronen Methoden-Server zu verarbeiten sind (Schritt 1870 in Fig. 18B). Wenn es keine Methoden-Aufruf- Anforderungen in der Schlange gibt (Schritt 1870), dann ist die Absender-Verarbeitung abgeschlossen (Schritt 1899).
Wenn es asynchrone Methoden-Aufruf-Anforderungen in der Schlange gibt (Schritt 1870), nimmt die Absender-Software-Komponente 1332 die nächste asynchrone Methoden-Aufruf-Anforderung aus der Schlange heraus (Schritt 1875). Wenn die aus der Schlange genommene Anforderung ungültig ist (Schritt 1880), wie z. B. eine Anforderung, die von dem Methoden-Server nicht bearbeitet werden kann, dann kehrt die Verarbeitung zurück, um herauszufinden, ob es andere Methoden-Aufruf- Anforderungen in der Schlange gibt (Schritt 1870).
Wenn die aus der Schlange genommene Anforderung gültig ist (Schritt 1880), dann sendet die Absender-Software-Komponente 1332 die asynchrone Methoden- Aufruf-Anforderung, die sie aus der Schlange genommen hat, um sie durch den asynchronen Methoden-Server zu bearbeiten, ab (Schritt 1885).
Dann wird die Frage gestellt, ob bei der Bearbeitung des Methoden-Servers ein Fehler auftrat (Schritt 1887). Der Fehler wird dann, wenn vorhanden, aufgezeichnet (Schritt 1888), oder wenn kein Fehler auftrat, prüft die Absender-Software-Komponente 1332 die Schlange (Schritt 1870). Auf diese Weise werden alle asynchronen Aufruf-Anforderungen in der Schlange nacheinander bearbeitet, ohne die Client-Anwendung, die die Methoden-Aufruf-Anforderung verursachte, zu blockieren.

1. Zusammenfassung

Die vorliegende Erfindung stellt somit eine wirkungsvolle und einfache Weise für eine Anwendung auf einer Plattform bereit, eine Anwendung auf der gleichen oder einer anderen Plattform aufzurufen, ohne Einzelheiten über die andere Plattform oder gar über die andere Anwendung kennen zu müssen. Solch ein Aufruf kann sogar zwischen ungleichen Plattformen in einem heterogenen Netzwerk stattfinden.
Weil gemäß der objektorientierten Techniken dieser Erfindung die Daten (oder Instanzen) und Anwendungen nicht verwaltet werden, können diese Daten und Anwendungen auf die Art verwaltet werden, die von den Anwendungsentwicklern gewählt wird. Da stattdessen nur Objekte und Verweise auf Anwendungen verwaltet werden, werden die Voraussetzungen an Systemkapazitäten verringert, und die Flexibilität des Systems wird erhöht.

Claims

1. Vorrichtung zur Verwendung in einem Datenverarbeitungsnetzwerk, welches eine Vielzahl von Anwendungen aufweist, die für die Durchführung von Operationen an Instanzen und für das Senden und Empfangen von Nachrichten, z.B. einschließlich Kennungen für die Instanz und Operationsarten, geeignet sind, sowie

eine Vielzahl von Instanzen entsprechend jeder der Anwendungen und

eine Vielzahl von Plattformen, die zur Ausführung der Anwendungen unter der Steuerung von Betriebssystemen arbeiten,

wobei die Vorrichtung zum Organisieren der Kommunikation zwischen den Anwendungen in einer objektorientierten Weise verwendet wird und folgendes enthält:

einen Speicher in dem Netzwerk, der eine Datenbank enthält, wobei die Datenbank folgendes aufweist:

eine Vielzahl von Methoden-Einträgen, von denen jeder Methoden-Eintrag einem Server einer der Anwendungen entspricht und Informationen für den Aufruf einer Prozedur enthält, um dieser Server-Anwendung zu ermöglichen, auf einer entsprechenden Server-Plattform eine spezifizierte Operation an einer spezifizierten Instanz durchzuführen,

eine Vielzahl von nicht-redundanten Klassen-Einträgen, wobei jeder der Klassen-Einträge Informationen über eine Klasse enthält, die aus einer oder mehreren Instanzen besteht, welche gemeinsame Eigenschaften teilen und außerdem eine Identifizierung von einem oder mehreren Nachrichten-Einträgen enthalten, und

eine Vielzahl von Nachrichten-Einträgen, die in einem entsprechenden Klassen-Eintrag identifiziert sind, wobei jeder der Nachrichten-Einträge Informationen über die Art der Operationen spezifiziert, welche an den mit dem entsprechenden Klassen-Eintrag verknüpften Instanzen durchgeführt werden können, und außerdem einen Verweis auf einen oder mehrere der Nachrichten-Einträge enthalten

eine Datenbank-Steuereinrichtung, die mit dem Speicher in dem Netzwerk verbunden ist, mit:

einer Einrichtung, die auf eine Nachricht von einer Kunden-Anwendung reagiert, zum Wählen eines Methoden-Eintrags entsprechend den Klassen- Einträgen und Nachrichten-Einträgen, die mit der Instanz und der Art der in der Nachricht identifizierten Operation verknüpft sind,

einer Einrichtung, die auf die Nachricht und den gewählten Methoden- Eintrag reagiert, zum Wählen einer Server-Anwendung auf einer entsprechenden Server-Plattform, die zum Ausführen der angeforderten Prozedur auf einer entsprechenden Server-Plattform (670) geeignet ist, und

einer Einrichtung zum Übertragen der Kennung für die Instanz und den Verweis auf eine Prozedur, die in dem gewählten Methoden-Eintrag zu der Server-Plattform 1300 enthalten ist.

2. Vorrichtung nach Anspruch 1, wobei die Methoden-Einträge in jedem der Nachrichten-Einträge durch eine Methoden-Karte mit Verweisen versehen sind.

3. Vorrichtung nach Anspruch 1, wobei jeder der Methode-Einträge eine Liste von Attributwerten enthält, welche die entsprechende Anwendung beschreibt.

4. Vorrichtung nach Anspruch 1, wobei die Klassen-Einträge oder Methoden- Einträge hierarchisch in Überklassen und Unterklassen geordnet sind, so daß diejenigen der Klassen-Einträge oder Methoden-Einträge, welche Unterklassen einer entsprechenden Überklasse darstellen, die Informationen über die entsprechende Überklasse erben.

5. Vorrichtung nach Anspruch 1, wobei die Datenbank einen globalen Klassenteil enthält, welcher für das ganze Netzwerk zugänglich ist.

6. Vorrichtung nach Anspruch 1, wobei die Datenbank lokale Teile enthält, welche auch für nur einen Teil des Netzwerks zugänglich sind.

7. Vorrichtung nach Anspruch 1, die außerdem eine Objekt-Definitions- Einrichtung aufweist, die mit dem Speicher in dem Netzwerk verbunden ist, zum Aktualisieren der Einträge in der Datenbank.

8. Vorrichtung nach Anspruch 7, wobei die Datenbank einen globalen Klassenteil enthält, welcher für das gesamte Netzwerk zugänglich ist, und einen lokalen Teil, welcher auch für nur einen Teil des Netzwerks zugänglich ist,

wobei die Datenbank-Steuereinrichtung eine Einrichtung zum Durchsuchen der lokalen Datenbanken in einer vorher festgelegten Reihenfolge vor dem Durchsuchen der globalen Klassen-Datenbank aufweist, und

wobei die Objekt-Definitions-Einrichtung eine Einrichtung zum Erzeugen von global einmaligen Kennungen für die Arten der Operationen und Instanzen aufweist.