DE69226858T2

DE69226858T2 - Kommunikationssystem

Info

Publication number: DE69226858T2
Application number: DE69226858T
Authority: DE
Inventors: Steve John Long Eaton Nottinghamshire Ng10 1Ph Atkins; Jeffrey Norman Stapleford Nottinghamshire Ng9 8Lb Froggatt; Leonard William Long Eaton Nottinghamshire Ng10 3Ng Parker
Original assignee: GPT Ltd
Current assignee: Ericsson AB
Priority date: 1992-01-31
Filing date: 1992-12-18
Publication date: 1999-01-21
Anticipated expiration: 2012-12-19
Also published as: EP0553560A3; EP0553560B1; ATE170640T1; FI930389A0; GB2263797A; GB2263797B; GB9202072D0; JPH05282165A; DE69226858D1; AU662784B2; FI930389A7; AU3106193A; FI930389L; CN1059747C; EP0553560A2; ES2121829T3; US5734902A; DK0553560T3; CA2088429A1; CN1078336A

Description

Die Erfindung betrifft ein objektorientiertes System.
In den vergangenen Jahren ist zunehmend eine neue Programmiermethode zu Entwicklung von Softwareprogrammen verwendet worden.
Diese Methode wird als Objektorientierung bezeichnet und ist auf alle Stufen des Softwareentwicklungslebenszyklus von der Analyse bis zur Codierung anwendbar. Das angewendete Grundprinzip besteht darin, Objekte zu konstruieren, die eine Kapselung von Daten und den Funktionen, die auf diesen Daten arbeiten, darstellen, so daß folgendes gilt:
a. Objekte kommunizieren miteinander nur durch Weitergabe von Nachrichten.
b. Der Benutzer eines Objekts muß nichts über die interne Implementierung des Objekts wissen, sondern nur etwas über die Dienste, die es (durch den Empfang einer gültigen Nachricht) bereitstellen kann.
c. Die gewählten Objekte sollten irgendeine Beziehung zum dem vorliegenden Problem aufweisen. Im allgemeinen enthalten objektorientierte Softwaresysteme Objekte, die Abstraktionen von Entitäten innerhalb des Systems, das die Software überwachen oder steuern soll, sind.
Diese einfache Beschreibung charakterisiert Objektorientierung als Methode nicht vollständig, dient aber als Grundlage, um die Erfindung zu verstehen. Obwohl Objekte über Softwarebegriffe definiert worden sind, können Objekte auch als Mischungen von Software und Hardware verstanden werden, z. B. kann die Übermittlung einer Nachricht an ein Objekt in einem Verhalten resultieren, das den Zustand von Hardware, die gesteuert wird, beeinflußt, so daß der "Software"-Teil des Objekts effektiv nicht mehr als ein Schnittstellenmechanismus für den "Hardware"-Teil des Objekts ist.
Da Objekte in Telekommunikationssystemen nur durch Übergabe von Nachrichten kommunizieren, bietet dies bei der Entwicklung objektorientierter Systeme ein großes Maß an Flexibilität im Hinblick auf die Architektur. Dies führt zu dem Problem, daß es nur kleine Unterschiede gibt zwischen dem Austauschen einer Nachricht zwischen Objekten, die in einem einzelnen Prozeß existieren, die in getrennten Prozessen auf der gleichen Maschine existieren und solchen auf verschiedenen Maschinen. Es ist nur der Mechanismus zur Übergabe der Nachricht, der sich in jedem Fall unterscheidet. Die Folge davon ist, daß es nicht mehr eine feste Beziehung zwischen Objekten, Prozessen und Maschinen gibt.
Der Begriff "Prozeß" wird allgemein in Software-Kreisen benutzt, um einen Teil von Software zu bezeichnen, der verzahnt mit anderen Prozessen auf derselben Maschine abläuft, d. h. die Ausführung der Instruktionen innerhalb eines Prozesses hängt nicht von der Initialisierung oder Beendigung von Instruktionen in einem anderen Prozeß ab. Diese verzahnte Verarbeitung wird gewöhnlich dadurch erreicht, daß ein Multitasking-Betriebssystem benutzt wird, um die Systemverarbeitungszeit unter den Prozessen aufzuteilen. Wenn ein solcher Aufteilungsmechanismus nicht bereitgestellt wird, kann es auf einer Maschine nur einen Prozeß geben.
In objektorientierten Systemen ist es für ein einzelnes Objekt normal, viele Benutzer zu haben. Wenn die Benutzer eines Objekts Objekte innerhalb des gleichen Prozesses sind, kann keine verzahnte Verarbeitung beteiligt sein und die Nachrichten werden sequentiell ankommen. Wenn das Objekt von Objekten in verschiedenen Prozessen benutzt werden soll, muß die Frage, wie parallele Zugriffe gehandhabt werden, behandelt werden.
Obwohl im folgenden auf Prozesses allein Bezug genommen wird, kann genau das gleiche auf Objekte, die über mehr als eine Maschine verteilt sind, angewendet werden.
Das Problem ist früher unter Benutzung des üblichen Client-Server-Modells behandelt worden. Bei diesem Zugang wird das von einer Anzahl von gleichzeitigen Objekten zu benutzende Objekt in einen eigenen Prozeß gesetzt - dieser ist als Server-Prozeß bekannt. Die Objekte in anderen Prozessen (nun als Client-Prozesse bekannt) können dann Nachrichten an das Objekt im Serverprozeß übergeben, um dessen Verhalten zu nutzen. Die Parallelität von Anfragen wird durch eine Form eines Warteschlangenmechanismus an der Schnittstelle zu dem Server-Prozeß gehandhabt, der als Teil des Mechanismus für Inter-Prozeß-Nachrichtenaustausch (interprocess message mechanism) vorgesehen ist.
Obwohl dieser Mechanismus funktioniert, weist er eine Anzahl von Nachteilen auf:
a. Die Funktion des Server-Prozesses ist es, die Parallelität durch Serialisierung zu behandeln, d. h. daß die Nachrichten nur in eine Warteschlange gesetzt werden und eine nach der anderen behandelt wird. Die Parallelität, die versucht worden war, ist effektiv weggeworfen worden. Wie annehmbar dies ist, wird von dem tatsächlichen, betrachteten System abhängen, jedoch kann ein solches Schema auf Systemen, die Parallelverarbeitung durch die Benutzung mehrerer Maschinen erzielt haben, zu zwangsweisen Leerlaufzeiten führen, während Clients auf Serverantworten warten, und resultiert in nicht optimaler Leistung.
b. Nachrichtenübergabe zwischen Objekten innerhalb desselben Prozesses ist immer viel schneller als Nachrichtenübergabe zwischen Objekten in verschiedenen Prozessen. Der Client- Server-Zugang erzwingt die Benutzung des langsameren Mechanismus. Wenn die Objektkommunikation so weit wie möglich innerhalb eines Prozesses gehalten werden könnte, würden lohnende Leistungsverbesserungen gewonnen.
c. Typische objektorientierte Designs führen zu einer große Anzahl von Objekten, die von vielen verschiedenen Prozessen benutzt werden müssen. Der Client-Server-Zügang führt typischerweise zu einem Kompromiß zwischen den zwei Extremen, alle Objekte in einen einzelnen Server-Prozeß zu setzen oder jedes Objekt in einen eigenen Prozeß zu setzen. Die Benutzung eines einzelnen Server-Prozesses führt zu einem Nachrichten-Engpaß, wodurch der Systembetrieb auf die Geschwindigkeit, mit der die Server-Warteschlange bedient wird, verlangsamt wird, und, bedingt durch die Beschränktheit der Systemressourcen, ist die Anzahl der Objekte normalerweise zu groß, um in der Praxis jedem einzelnen einen Prozeß zuzuweisen. Bei großen Systemen kann ein zufriedenstellender Kompromiß in Übereinstimmung mit der erforderlichen Systemleistung nicht erzielt werden.
Um die obigen Probleme (a-c) anzugehen ist das "Shared object model" der Erfindung entwickelt worden.
Wenn Objekte in verschiedenen Prozessen ein anderes Objekt zwischen sich benutzen möchten, kann dieses Objekt als ein gemeinsam genutztes Objekt aufgefaßt werden. Eine Alternative zur Erzeugung eines Server-Prozesses ist es, eine Kopie dieses gemeinsam genutzten Objektes in jedem der Prozesse zu erzeugen, die auf es zugreifen wollen. Alle an das gemeinsam genutzte Objekt übergebenen Nachrichten scheinen innerhalb desselben Prozesses zu sein, darüber hinaus findet keine Serialisierung der Nachrichten in einer Warteschlange statt, d. h. die Parallelität ist erhalten. Dies klingt ideal, außer daß, damit dieses gemeinsam genutzte Objekt ein gemeinsam genutztes Objekt ist, jede Kopie in jedem Prozeß genau gleich sein muß.
Ein Objekt ist durch seine internen Daten und seine Methoden (den Funktionen, die als Reaktion auf ankommende Nachrichten auf seinen internen Daten arbeiten,) charakterisiert. Die internen Daten eines Objekts sind gewöhnlich dynamisch und verändern sich mit der Zeit. Die Methoden eines Objekts sind statischer, da sie normalerweise zu der Erzeugungszeit des Systems (oder früher) definiert werden, und verändern sich nicht während der Lebensdauer des Systems. Wenn Kopien eines gemeinsam genutzten Objekts gemacht werden, sind es daher nur die internen Daten, die konsistent gehalten werden müssen. Wenn die in einem Prozeß genutzten Methoden nur zu Leseoperationen auf den internen Daten des gemeinsam genutzten Objekts führen, tritt kein Problem auf. Wenn jedoch die aktivierten Methoden zu einer Änderung der internen Daten führen, z. B. Schreiboperationen, dann müssen solche Änderungen für jede Kopie des gemeinsam genutzten Objekts durchgeführt werden, um Konsistenz aufrechtzuerhalten.
Dieses kann nur durch Inter-Prozeß-Nachrichtenaustausch (Nachrichtenaustausch zwischen Prozessen) erreicht werden. Es muß eine Datenstruktur erzeugt und unterhalten werden, die jeden Prozeß genau aufführt, der gegenwärtig des gemeinsam genutzte Objekt benutzt. Wenn in einem der Prozesse die internen Daten des gemeinsam genutzten Objekts verändert werden, wird diese Tabelle benutzt, um die in anderen Prozessen vorhandenen Kopien neu zu erzeugen oder zu aktualisieren.
Ein Vorschlag für eine objektorientierte Anordnung, in der Objekte bei einer Anzahl von physikalisch abgesetzten Knoten kopiert werden können, wird in dem Artikel "The Treatment of Persistent Objects in Arjuna" (The Computer Journal, Vol. 32, No. 4, August 1989, Seiten 323-332, Cambridge UK) beschrieben. Dieser Vorschlag betrifft die Bereitstellung von fehlertoleranten, verteilten Systemen, die relativ widerstandsfähig gegen den Ausfall einzelner Knoten und den Verlust von Nachrichten sind. Dauerhafte (persistente) Objekte werden in nicht-flüchtigen Speichern gespeichert. Um ein Objekt zu aktivieren, ist es notwendig, es von dem nicht-flüchtigen Speicher in flüchtige Speicher zu kopieren. Auf die Kopie im flüchtigen Speicher wird dann zugegriffen. Wenn der Zugriff die Änderung von Daten beinhaltet, wird die geänderte flüchtige Kopie benutzt, um die nicht-flüchtige Kopie zu aktualisieren, wenn der Zugriff normal beendet wird. Sollte ein Ausfall auftreten, während die flüchtige Kopie benutzt wird, kann die nichtflüchtige Kopie benutzt werden, um den Betrieb wiederaufzunehmen.
Sollte ein Knoten ein bei einem anderen Knoten gespeichertes, gemeinsam genutztes Objekt zu benutzen wünschen, wird, wenn nur Lese- (READ-) Operationen erforderlich sind, eine lokale Kopie erzeugt und es wird direkt auf sie zugegriffen, wodurch die Notwendigkeit eines Client-Server-Prozesses vermieden wird.
Wenn jedoch eine Schreib-(WRITE-) Operation erfolgen soll, wird keine lokale Kopie gemacht. Stattdessen müssen einzelne Client- Server-Prozesse zwischen dem Prozeß, der die Schreiboperationen erzeugt, und den replizierten Kopien des Objekts erzeugt werden.
Die replizierten Objekte werden dann so konfiguriert, daß sie funktionell einem einzelnen Objekt äquivalent sind und jegliche Änderungen sofort zu allen replizierten Kopien über ihre entsprechenden Client-Server-Prozesse geleitet werden. Obwohl dies Konsistenz erhält, ist die Bereitstellung eines dedizierten Client-Server-Prozesses für jede replizierte Kopie erforderlich, um die Möglichkeit einer Datenänderung zu berücksichtigen.
Der "shared object"- Zugang (Zugang über gemeinsam genutzte Objekte) der vorliegenden Erfindung behandelt das Problem der Gleichzeitigkeit, da es über die vielfachen Kopien des gemeinsam genutzten Objekts weiterbesteht. Inter-Prozeß-Nachrichtenaustausch wird weiterhin benutzt, jedoch nur, wenn eine Methode eines gemeinsam genutzten Objekts, die zu einer Änderung der internen Daten führt, benutzt wird, der schnellere Intra-Prozeß- Nachrichtenaustausch wird jedoch für alle anderen Methoden benutzt. Das Problem, Objekte den Server-Prozessen zuzuweisen, und die damit verbundenen Leistungsprobleme werden beseitigt. Dies soll nicht heißen, daß das Client-Server-Modell nicht benutzt werden soll - es gibt noch immer Umstände, unter denen es vernünftig wäre, diese Einrichtung statt des "shared object"- Zugangs zu benutzen. Außerdem hat der "shared object"-Zugang auch einige potentielle Nachteile, nämlich:
a. Wenn ein Objekt gemeinschaftlich von vielen Prozessen genutzt wird, muß eine große Datentabelle geführt werden. (In dem Client-Server-Zugang jedoch würde eine solche Situation zu einem Nachrichten-Engpaß führen).
b. Um sicherzustellen, daß Aktualisierungen des internen Zustands von gemeinsam genutzten Objekten konsistent durchgeführt werden, müssen Objektsperren benutzt werden, d. h. um sicherzustellen, daß die Daten nicht von zwei verschiedenen Prozessen zur gleichen Zeit aktualisiert werden.
Ein erster Aspekt der Erfindung sieht ein Verfahren zum Betreiben eines objektorientierten Systems vor, das
Mittel zur Speicherung eines veränderbare Daten enthaltenden Objekts und
Mittel zur Bereitstellung einer Kopie des Objekts für mindestens einen von den Mitteln zur Speicherung eines Objekts abgesetzten Prozeß, der ein entsprechendes Mittel zur Speicherung der Kopie des Objekts aufweist, enthält, enthaltend die Schritte:
Zusenden einer Kopie des Objekts an mindestens einen der Prozesse, die von den Mitteln zur Speicherung eines Objekts abgesetzt sind,
Speichern der Kopie des Objekts in einem entsprechenden Mittel zur Speicherung,
Ändern der änderbaren Daten des Objekts,
Mitteilen des Vorhandenseins der Änderung an den oder jeden abgesetzten Prozeß, der eine Kopie des Objekts hat und
Zusenden einer Kopie der geänderten Daten an den oder jeden abgesetzten Prozeß in Antwort auf eine Anforderung der geänderte Daten von dem oder jedem abgesetzten Prozeß.
Wenn eine Kopie eines Objekts in einem Prozeß gemacht wird, wird die Benutzung des Objekts durch den Prozeß aufgezeichnet. Wenn irgendein Prozeß die Bezugskopie eines Objekts aktualisiert, werden alle Prozesse, die ein Bild des Objekts haben, informiert. Jeder Prozeß kann dann seine eigene Darstellung des Objekts neu abgleichen, indem er die Bezugsdaten neu liest.
Ein zweiter Aspekt der Erfindung sieht ein objektorientiertes System vor, das
Mittel zur Speicherung eines änderbare Daten enthaltenden Objekts,
mindestens ein Mittel zur Speicherung einer Kopie des Objekts in einem von den Mitteln zur Speicherung eines Objekts abgesetzten Prozeß,
Mittel zur Änderung der änderbaren Daten des Objekts,
Mittel zur Benachrichtigung des mindestens einen Mittels zur Speicherung einer Kopie des Objekts darüber, daß die änderbaren Daten des Objekts geändert worden sind und
Mittel zur Zusendung einer Kopie der geänderten Daten des Objekts an eine Kopie des Objekts in Antwort auf eine Anforderung des abgesetzten Prozesses, in dem die Kopie des Objekts gespeichert ist, für eine Kopie der geänderten Daten aufweist.
Die Daten für das gemeinsam genutzte Objekt können von Prozessen, die gerade tatsächlich auf das Objekt zugreifen, aktualisiert werden. Ein Benachrichtigungsmechanismus (BOUing) wird dazu benutzt, andere Prozesse darüber zu informieren, daß das Objekt sich geändert hat. Diese Prozesse sind dann dafür verantwortlich, wenn notwendig, die Daten des gemeinsam genutzten Objekts neu zu lesen. Durch den BOUing Mechanismus werden keine Daten transportiert.
Die vorliegende Erfindung wird nun an einem Beispiel beschrieben.
Die Standardimplementierung eines Client-Server-Zugangs besteht darin, kleine Stücke von Code (manchmal als "message stubs" bezeichnet) in den Client- und Server-Prozessen zu benutzen, die eine Schnittstelle mit einer Form der Inter-Prozeß-Kommunikation (interprocess communication) (IPC) zu bilden. Der Zweck des Codes in dem Client-Prozeß besteht nur darin, Anforderungen an das Objekt in dem Server-Prozeß als Nachrichten zu dem Server- Prozeß unter Benutzung des IPC-Mechanismus weiterzuleiten. Der IPC-Prozeß wird die Nachrichten in eine Warteschlange bei dem Server-Prozeß stellen, wobei die kleine Menge Code in dem Server-Prozeß die Warteschlange liest und die Anforderungen an das Objekt zur Bedienung leitet. Den ganzen Prozeß kann man sich als eine Röhre (Pipe) denken, die an einem Ende von dem oder den Client-Prozeß bzw. -Prozessen Anforderungen entgegen nimmt und sie an dem anderen Ende der Röhre an das entsprechende Objekt in dem Server-Prozeß liefert. Alle zur Bedienung der Anforderungen (und nicht nur zum Transport) notwendigen Aktivitäten werden in dem Server-Prozeß abgewickelt.
Die Implementierung des "shared object"-Zugangs ersetzt die "Röhre" (Pipe) durch einen Mechanismus, der Anforderungen lokal innerhalb des Prozesses unter Benutzung des gemeinsam genutzten Objekts behandelt. Nur wenn solche Anforderungen die internen Daten des gemeinsam genutzten Objekts ändern, wird die Inter- Prozeß-Kommunikation benutzt werden, um sicherzustellen daß andere Kopien des Objekts mit den Änderungen abglichen werden.
Objekte, die gemeinsam innerhalb des Systems benutzt werden sollen, müssen als solche zur Kompilierungszeit identifiziert sein. Dies wird dadurch erreicht, daß eine Klasse für gemeinsam genutzte Objekte definiert wird, von der Objekte, die diese Eigenschaft aufweisen möchten, erben können. Jedesmal wenn ein gemeinsam genutztes Objekt erzeugt wird, wird eine Kopie dieses Objekts innerhalb des anfordernden Prozesses erzeugt. Wenn dies das erste Mal ist, daß das Objekt erzeugt wird, dann werden zwei weitere Elemente erzeugt; eine Kopie der Daten des Objekts wird zusammen mit einer "benutzt-von"-Tabelle, in die ein Bezeichner für den anfordernden Prozeß geschrieben wird, in dem gemeinsam genutzten Speicher erzeugt. Nachfolgende Erzeugungen dieses gemeinsam genutzten Objekts durch andere Prozesse werden zu einer Kopie des Objekts, die innerhalb des Prozesses erzeugt wird, führen, deren interne Daten eine genaue Kopie der in dem gemeinsam genutzten Speicher gespeicherten Daten sind, und die "benutzt-von"-Tabelle wird mit der ID (Prozeßidentifikation) des anfordernden Prozesses aktualisiert.
Den gemeinsam genutzten Speicher kann man sich als einen globalen Datenbereich denken, auf den jeder beliebige Prozeß zugreifen kann.
Jedesmal wenn eine Anforderung für ein gemeinsam genutztes Objekt gemacht wird, wird diese Anfrage lokal von dem Prozeß bedient. Wenn die Anforderung zu einer Änderung der internen Daten des gemeinsam genutzten Objekts führt, wird die Kopie der Daten des gemeinsam genutzten Objekts im gemeinsam benutzten Speicher aktualisiert, um die Änderung(en) wiederzugeben. Zusätzlich dazu wird es notwendig sein, ein Signal an jeden anderen Prozeß, der das veränderte gemeinsam genutzte Objekt benutzt, zu senden, um anzuzeigen, daß eine Änderung stattgefunden hat, so daß sie ihre lokalen Kopien des gemeinsam genutzten Objekts mit den in dem gemeinsam genutzten Speicher gespeicherten geänderten Daten abgleichen können. Dieser Signalisierungsprozeß wird mit "Broadcast on Update" (oder BOU) (Rundsenden bei Aktualisierung) bezeichnet und dadurch realisiert, daß die "benutzt-von"-Tabelle benutzt wird, um ein Signal an alle als Benutzer des gemeinsam genutzten Objekts registrierten Prozesse zu senden. Jeder Prozeß, der gemeinsam genutzte Objekte enthält, muß einen BOU-Signalhandler enthalten, der sicherstellt, daß das BOU-Signal zu den notwendigen Aktualisierungen führt.
Es ist natürlich möglich, daß ein Prozeß ab einem Zeitpunkt ein gemeinsam genutztes Objekt nicht länger benötigt. Wenn dies passiert, wird das gemeinsam genutzte Objekt aus dem Prozeß entfernt und die "benutzt-von"-Tabelle geändert, in dem die Identifikation des anfordernden Prozesses gelöscht wird.

Claims

1. Verfahren zum Betreiben eines objektorientierten Systems, das

Mittel zur Speicherung eines veränderbare Daten enthaltenden Objekts und

Mittel zur Bereitstellung einer Kopie des Objekts für mindestens einen von den Mitteln zur Speicherung eines Objekts abgesetzten Prozeß, der ein entsprechendes Mittel zur Speicherung der Kopie des Objekts aufweist, enthält, enthaltend die Schritte:

Zusenden einer Kopie des Objekts an mindestens einen der Prozesse, die von den Mitteln zur Speicherung eines Objekts abgesetzt sind,

Speichern der Kopie des Objekts in einem entsprechenden Mittel zur Speicherung,

Ändern der änderbaren Daten des Objekts,

Mitteilen des Vorhandenseins der Änderung an den oder jeden abgesetzten Prozeß, der eine Kopie des Objekts hat und

Zusenden einer Kopie der geänderten Daten an den oder jeden abgesetzten Prozeß in Antwort auf eine Anforderung der geänderte Daten von dem oder jedem abgesetzten Prozeß.

2. Verfahren nach Anspruch 1, weiter aufweisend die Schritte:

Ändern der änderbaren Daten einer Kopie des Objekts und Mitteilen der geänderten Daten der Kopie an das Objekt, wobei der Schritt des Änderns der änderbaren Daten die änderbaren Daten des Objekts so ändert, daß sie den in der Kopie des Objekts enthaltenen änderbaren Daten entsprechen.

3. Objektorientiertes System, enthaltend:

Mittel zur Speicherung eines änderbare Daten enthaltenden Objekts,

mindestens ein Mittel zur Speicherung einer Kopie des Objekts in einem von den Mitteln zur Speicherung eines Objekts abgesetzten Prozeß,

Mittel zur Änderung der änderbaren Daten des Objekts,

Mittel zur Benachrichtigung des mindestens einen Mittels zur Speicherung einer Kopie des Objekts darüber, daß die änderbaren Daten des Objekts geändert worden sind und Mittel zur Zusendung einer Kopie der geänderten Daten des Objekts an eine Kopie des Objekts in Antwort auf eine Anforderung des abgesetzten Prozesses, in dem die Kopie des Objekts gespeichert ist, für eine Kopie der geänderten Daten.

4. System nach Anspruch 3, enthaltend:

Mittel zur Änderung der änderbaren Daten einer Kopie des Objekts,

in dem das Mittel zur Änderung der änderbaren Daten des Objekts die änderbaren Daten des Objekts so ändert, daß sie den geänderten Daten der Kopie des Objekts entsprechen.