DE19910345A1 - Verfahren zur Nachrichtenübertragung zwischen einer einem ersten Prozeß zugewiesenen Clientinstanz und wenigstens einer mindestens einem weiteren Prozeß zugewiesenen Serverinstanz innerhalb eines verteilten Systems - Google Patents

Abstract

Eine einen ersten Prozeß enthaltende erste Instanz (ObjectHandler1) von als gegenseitige Kommunikationspartner vorgesehenen Partnerinstanzen wählt nach Empfang einer von der Clientinstanz (Client) an wenigstens eine Serverinstanz (Server) gerichtete Nachricht mindestens eine geeignete den mindestens einen weiteren Prozeß enthaltenden weitere Instanz (ObjectHandler2) der Partnerinstanzen zur Nachrichtenannahme und -weitergabe aus. Die mindestens eine den mindestens einen weiteren Prozeß enthaltende weitere Instanz leitet diese Nachricht zu wenigstens einer von ihr adressierten Serverinstanz weiter und erhält gegebenenfalls von der wenigstens einen Serverinstanz eine Nachricht zur Weiterleitung über die den ersten Prozeß enthaltende erste Instanz an die Clientinstanz.

Description

Die Erfindung betrifft ein Verfahren zur Nachrichtenübertra­ gung zwischen einer einem ersten Prozeß zugewiesenen Client­ instanz und wenigstens einer mindestens einem weiteren Prozeß zugewiesenen Serverinstanz innerhalb eines verteilten Sy­ stems.

Verteilte Systeme spielen vorzugsweise in heutigen Telekommu­ nikationssystemen, die in der Regel Multiprozessorsysteme sind, eine besondere Rolle. Ein verteiltes System ist insbe­ sondere dadurch charakterisiert, daß Prozesse jeweils unter­ schiedlichen Prozessoren zugeteilt werden können, wobei sich die Prozessoren gegebenfalls auf örtlich getrennten Plattfor­ men im verteilten System befinden können. Einer der wichtig­ sten Aspekte bei der Kommunikation zwischen verschiedenen Prozessen eines verteilten Systems ist dabei die Plattform- Transparenz. Damit ist gemeint, daß ein Prozeß, der eine Nachricht an einen anderen Prozeß senden will, die Plattform, auf der der andere Prozeß gerade abläuft, nicht kennen muß. Solch ein komplexes verteiltes System muß heutzutage noch vielen weiteren Anforderungen genügen. Es muß sich unter an­ derem als äußerst zuverlässig, möglichst flexibel sowie offen für Anpassungen und Erweiterungen erweisen. Die Software ei­ nes derartigen komplexen verteilten Systems soll daher hoch­ gradig modular mit fest definierten offenen Schnittstellen nach außen gestaltet sein, damit die einzelnen Module der Software leicht anpassungsfähig und vor allem wiederverwend­ bar sind.

Um den genannten Anforderungen insbesondere der Wiederver­ wendbarkeit von Software einigermaßen gerecht zu werden, wird die Software zu einem solchen verteilten System mit Hilfe ob­ jektorientierter Entwurfmethoden und objektorientierter Pro­ grammierung erstellt. Jedoch ist die in verteilten Systemen notwendige Zuordnung von Objekten untereinander, die meist unterschiedlichen und gegebenfalls nebenläufigen Prozessen zugewiesen werden, nicht zufriedenstellend gelöst. Teilweise muß sogar ein rein objektorientierter Systementwurf in her­ kömmliche prozedurale Programmiertechniken aufgebrochen wer­ den, wodurch der mit der Objektorientierung erreichte Effekt der Wiederverwendung von Programmteilen mehr oder weniger verloren geht.

Derzeit werden bei der Einführung von Nebenläufigkeit und Parallelverarbeitung in die Welt der Objekte folgende bekann­ te Ansätze diskutiert:

Implizite Nebenläufigkeit: Bei der Implementierung von im­ plizierter Nebenläufigkeit gibt es zwei Möglichkeiten:

• - Passive Objekte: Ein asynchroner Nachrichtenaustausch wird in einen sequenziellen synchronen Methoden- bzw. Prozeduraufruf umgewandelt. Hierbei wird die Parallel­ verarbeitung der miteinander kommunizierenden Objekte sehr eingeschränkt.
• - Aktive Objekte: Für jedes Objekt wird ein Prozeß gestar­ tet. Dieses Vorgehen führt zu einem hohen Ressourcenver­ brauch und ist deshalb nur mit einer begrenzten Anzahl von Objekten realisierbar.

Explizite Nebenläufigkeit: Hierbei wird entweder eine Gruppe von Objekten (objektbezogen), wie in einem Artikel von A. Coutts, J. M. Edwards, Model-Driven Distributed Sy­ stems, IEEE Concurrency, Juli 1997, S. 55-63 beschrieben, oder mehrere Ereignisse in einer Ablaufsequenz (aufgaben­ bezogen), wie in einem Artikel von M. Awad, J. Ziegler, A Practical Approach to the Design of Concurrency in Object- Oriented Systems, Software - Practice and Experience, Sep­ tember 1997, Vol. 27(9), S. 1013-1034 erläutert, einem Prozeß zugewiesen. Bei Betrachtung der rechten Hälfte der

Fig.

3 im genannten Artikel von Awad/Ziegler und der

Fig.

5 im genannten Artikel von Coutts/Edwards ist an den Schnittstellen zwischen den Objekten, die teilweise gleichzeitig Schnittstellen zwischen den Prozessen dar­ stellen, zu erkennen, daß die Kommunikation zwischen den Objekten sowohl durch synchrone Methodenaufrufe als auch durch Interprozeßkommunikation in Form einer asynchronen Nachrichtenweitergabe erfolgt. Eine derartige Festlegung der Kommunikationsart an den Schnittstellen von Objekten hat den Nachteil, daß die Wiederverwendbarkeit und die Wartbarkeit der Objekte erheblich erschwert wird.

Insbesondere im Zusammenhang mit der Kommunikation zwischen verschiedenen Objekten eines verteilten Systems, auch Instan­ zen genannt, die untereinander in der Regel in einem soge­ nannten Client/Server-Verhältnis stehen und die verschiedenen Prozessen zugewiesen sind, ist die vorstehend erläuterte Vor­ gehensweise hinsichtlich der in einem solchen komplexen Sy­ stem erwünschten Wiederverwendbarkeit und Wartbarkeit eine sehr ungünstige Lösung.

Die Aufgabe der Erfindung besteht daher darin, ein Verfahren zur Nachrichtenübertragung zwischen sogenannten jeweils un­ terschiedlichen Prozessen zugewiesenen Client- und Serverin­ stanzen eines verteilten Systems dahingehend auszugestalten, daß bezüglich der Implementierung des Verfahrens eine mög­ lichst hohe Wiederverwendbarkeit gegeben ist und zugleich die Wartbarkeit möglichst erleichtert wird.

Diese Aufgabe wird durch die im Anspruch 1 angegebenen Merk­ male gelöst. Weitere Ausgestaltungen der Erfindung sind in Unteransprüchen gekennzeichnet.

Erfindungsgemäß wird dies dadurch erreicht, daß zur Nachrich­ tenübertragung zwischen einer einem ersten Prozeß zugewiese­ nen Clientinstanz und wenigstens einer mindestens einem wei­ teren Prozeß zugewiesenen Serverinstanz innerhalb eines ver­ teilten Systems zusätzlich als gegenseitige Kommunikations­ partner vorgesehene Partnerinstanzen eingesetzt werden. Eine den ersten Prozeß enthaltende erste Instanz der Partnerin­ stanzen wählt nach Empfang einer von der Clientinstanz an we­ nigstens eine Serverinstanz gerichtete Nachricht mindestens eine geeignete den mindestens einen weiteren Prozeß enthal­ tende weitere Instanz der Partnerinstanzen zur Nachrichtenan­ nahme und -weitergabe aus. Die mindestens einen weiteren Pro­ zeß enthaltende weitere Instanz leitet diese Nachricht zu we­ nigstens einer von ihr adressierten Serverinstanz weiter und erhält gegebenfalls von der wenigstens einen Serverinstanz eine Nachricht zur Weiterleitung über die den ersten Prozeß enthaltende erste Instanz an die Clientinstanz.

Auf diese Weise wird die Festlegung der Kommunikationsart zwischen der Clientinstanz und der mindestens einen Serverin­ stanz in die einen Prozeß enthaltenden, als gegenseitige Kom­ munikationspartner vorgesehenen Partnerinstanzen verlagert. So werden die Nachrichten zwischen der Clientinstanz und der den ersten Prozeß enthaltenden ersten Instanz sowie zwischen der mindestens einen Serverinstanz und der mindestens einen weiteren Prozeß enthaltenden weiteren Instanz synchron z. B. durch Prozedur- bzw. Methodenaufruf übertragen. Die Nachrich­ tenübertragung zwischen einer den ersten Prozeß enthaltenden ersten Instanz und einer mindestens einen weiteren Prozeß enthaltenden weiteren Instanz kann dann entkoppelt von den Kommunikationsschnittstellen der Clientinstanz und mindestens einen Serverinstanz asynchron oder synchron erfolgen. Dadurch wird eine maximale Wiederverwendbarkeit vorwiegend bezüglich der Implementierung der Client- und der mindestens einen Ser­ verinstanz erreicht. Die Wartbarkeit wird ebenfalls erheblich verbessert dadurch, daß allenfalls die Kommunikationsschnitt­ stellen zwischen der den ersten Prozeß enthaltenden ersten Instanz und der mindestens einen weiteren Prozeß enthaltenden weiteren Instanz angepaßt werden müssen, jedoch die Kommuni­ kationsschnittstellen der Client- und der mindestens einen Severinstanz unberührt bleiben.

Eine weitere vorteilhafte Ausgestaltung der Erfindung sieht vor, daß die den ersten Prozeß enthaltenden erste Instanz die Auswahl der mindestens einen weiteren Prozeß enthaltenden weiteren Instanz anhand einer Zuordnungstabelle trifft. In dieser Zuordnungstabelle ist die Art der von der Clientin­ stanz aussendbaren Nachrichten und die Adresse der mindestens einen weiteren Prozeß enthaltenden weiteren Instanz eingetra­ gen. Eine Zuordnungstabelle hat den Vorteil, daß ihr Inhalt jederzeit änderbar ist, und der den ersten Prozeß enthalten­ den ersten Instanz eine schnelle Auswahl ermöglicht.

Gemäß einer zweckmäßigen Weiterbildung der Erfindung ist die durch die den ersten Prozeß enthaltende ersten Instanz ge­ troffene Auswahl dynamisch in Abhängigkeit von der Systemaus­ lastung änderbar. Dadurch können Systemabstürze sowie Ver­ klemmungen bei der Zuteilung der Prozesse auf die Prozessoren vermieden werden.

Eine weitere Ausgestaltung der Erfindung betrifft den Spezi­ alfall, daß der erste Prozeß und der mindestens eine weitere Prozeß zusammenfallen. In diesem Fall sind die den ersten Prozeß enthaltende erste Instanz und die den mindestens einen weiteren Prozeß enthaltende weitere Instanz in einer Instanz vereinigt. Dadurch kann das erfindungsgemäße Verfahren ohne Anpassungen auf diesen Spezialfall angewendet werden.

Eine weitere nützliche Ausgestaltung der Erfindung ist in der Art der Implementierung zu sehen. So können sämtliche Instan­ zen (Client-, Server-, die den ersten Prozeß enthaltende In­ stanz und Partnerinstanz) in Form von Objekten implementiert werden, deren Struktur durch Objektklassen festgelegt wird. So weisen die den ersten Prozeß enthaltende erste Instanz und die mindestens einen weiteren Prozeß enthaltende weitere In­ stanz vorzugsweise jeweils die Struktur einer gemeinsamen Ob­ jektklasse auf. Auf diese Weise werden die Grundsätze der rein objektorientierten Programmierung ausgenutzt, wodurch ein hoher Grad an Modularität, eine hohe Wiederverwendbarkeit und Wartbarkeit erreicht wird.

Eine weitere Ausgestaltung der Erfindung ist in einer sehr zweckmäßigen Verwendung des erfindungsgemäßen Verfahrens auf ein Fernsprechvermittlungssytem zu sehen. Demnach kommen alle vorstehend erwähnten Vorteile auch im Zusammenhang mit einem Fernsprechvermittlungssystem zum Tragen.

Nachstehend wird ein Ausführungsbeispiel der Erfindung unter Bezugnahme auf eine Zeichnung näher beschrieben.

In der Zeichnung zeigen:

Fig. 1 ein beispielhaftes Ablaufdiagramm des erfindungsgemä­ ßen Verfahrens,

Fig. 2 ein Anwendungsbeispiel im Bereich einer System-Alar­ mierung in einem Telekommunikationssystem wie z. B. einem Fernsprechvermittlungssystem.

Eine Legende zu den Figuren ist im Anhang am Ende der Be­ schreibung zu finden.

Fig. 1 beschreibt in einem Ablaufdiagramm die Nachrichten­ übertragung zwischen einer einem ersten Prozeß zugewiesenen Clientinstanz und einer einem weiteren Prozeß zugewiesenen Serverinstanz. Die Instanzen Client, Server, die den ersten Prozeß enthaltende erste Instanz und die den mindestens einen weiteren Prozeß enthaltende weitere Instanz sowie die Aktion, die von der Serverinstanz ausgeführt wird, werden in Form von Objekten mit Kästchen dargestellt. So entpricht das Objekt Client einer Clientinstanz, das Objekt Server einer Serverin­ stanz, das Objekt ObjectHandler1 einer den ersten Prozeß ent­ haltenden ersten aktiven Instanz der als gegenseitige Kommu­ nikationspartner vorgesehenen Partnerinstanzen, das Objekt ObjectHandler2 einer den weiteren Prozeß enthaltenden weite­ ren aktiven Instanz der Partnerinstanzen, das Objekt Action einer Aktion und das Objekt Confirm Action einer Rückmel­ dungsaktion auf eine angeforderte Aktion. Die aktiven Instan­ zen, die die jeweiligen Prozesse enthalten, sind hierbei durch Kästchen mit fett gezeichneten Linien gekennzeichnet. Die Art der Aktion wird erst beim Aufruf des speziellen Ob­ jekts Action bestimmt.

Im Falle einer vom Client angeforderten vom Server auszufüh­ renden Aktion mit Rückmeldung läuft das Verfahren beispiels­ weise wie folgt ab:

Ein Client fordert vom Server eine Aktion an, auf die eine Rückmeldung erfolgen soll. Der Client ruft die Aktion auf und muß nicht wissen, welcher Prozeß bzw. auf welcher Prozessor- Plattform die Aktion ausgeführt werden soll. Der Objecthand­ ler1 stellt den Client dafür die Aufrufprozedur invoke_action bereit. Nach dem Aufruf der Prozedur invoke_action, in der objektorientierten Programmierung auch Methode genannt, wird dem ObjectHandler1 eine eindeutige Nummer (get handle number) zugeordnet und es wird ein Zeitnehmer gestartet (start ti­ mer), der bei nicht rechtzeitigem Eintreffen der Rückmeldung eine Fehlerbehandlung auslöst. Danach sucht der ObjectHand­ ler1 nach einer als Kommunikationspartner vorgesehenen Part­ nerinstanz z. B. ObjectHandler2 (find target ObjectHandler), der der Aktion abhängig von der Art der Aktion zugeordnet ist, und übermittelt die Nachricht der Aktionsanforderung ac­ tion request an den ObjectHandler2. Der ObjectHandler2 nimmt die Nachricht entgegen, speichert die Adresse seines Kommuni­ kationspartners ObjectHandler1 (store communication partner) zusammen mit der dem ObjectHandler1 eindeutig zugeordneten Nummer und führt die Prozedur des Objekts Action aus (execu­ te). Das Objekt Action veranlaßt daraufhin den vom Client adressierten Server zur Ausführung der Aktion durch den Pro­ zeduraufruf action. Nach der Ausführung der Aktion sendet der Server in analoger Weise indirekt eine Rückmeldung zum Client zurück. Demnach laufen folgende Prozeduraufrufe, Nachrichten­ übertragungen und Aktionen vom Server in Richtung zum Client ab. Prozeduraufruf Invoke_action, lösche Adresse des Kommuni­ kationspartners sowie Übertragung der Aktionsanforderungs­ nachricht für die Rückmeldung action_request vom ObjectHand­ ler2 zum ObjectHandler1, der dem ObjectHandler2 aufgrund der zugeordneten Nummer bekannt ist, ObjectHandler1 löscht die zugeordnete Nummer (release handle number) und stoppt den Zeitnehmer (stop timer), zur Übermittlung der Rückmeldung ruft ObjectHandler1 die Prozedur execute des Objekts Confirm Action auf und zuletzt führt Objekt Conform Action die Proze­ dur confirm_action des Client aus.

Im Falle einer vom Client angeforderten Aktion des Servers ohne Rückmeldung läuft das erfindungsgemäße Verfahren der Nachrichtenübertragung vom Client zum Server in ähnlicher Weise wie vorstehend beschrieben ab. Es entfallen die Ablauf­ schritte get handle number, start timer, store communication partner und die Schritte bezüglich der Rückmeldung vom Server in Richtung zum Client.

Im Falle eines sogenannten Broadcasts, d. h. ein Client for­ dert von mehreren Servern eine Aktion an, gibt es verschiede­ ne Möglichkeiten:

• - Wenn die vom Client adressierten Server einem gemeinsamen Prozeß zugewiesen sind, wird der ObjectHandler1 die ac­ tion_request-Nachricht entweder an einen ObjectHandler2 weitergeben und der ObjectHandler2 sorgt dafür, daß die Aktion von mehreren Servern ausgeführt wird, oder der Ob­ jectHandler1 sendet mehrere action_request-Nachrichten an mehrere den Server-Prozeß enthaltende ObjectHandler2, die jeweils die Server zur Ausführung der Aktion veranlassen. Auch ist eine Kombination aus beiden genannten Varianten möglich.
• - Wenn die vom Client adressierten Server unterschiedlichen Prozessen zugewiesen sind, wird der ObjectHandler1 jeweils eine action_request-Nachricht an die die unterschiedlichen Prozessen enthaltenden ObjectHandler2 senden und die Ob­ jectHandler2 veranlassen jeweils die Server zur Ausführung der Aktion.

Auch hier sind sämtliche Kombinationen der erwähnten Möglich­ keiten denkbar.

Üblicherweise sind in einem verteilten System mehrere Aktio­ nen auszuführen, so daß selbstverständlich jeder Server auch als Client und jeder Client auch als Server agieren kann so­ wie in einem Objekt Client- und Serverfunktion vereint sein können.

Die vorteilhafte Entkopplung der Prozeßschnittstellen von den Objektschnittstellen des Client und des Servers ist daran zu erkennen, daß die Kommunikation zwischen den Client und dem Server synchron durch Prozedur- bzw. Methodenaufrufe reali­ siert wird und nur die Nachrichtenübergabe zwischen den Ob­ jectl-Handler1 und ObjectHandler2 gegebenfalls asynchron über die Prozeßgrenzen hinweg durchgeführt wird.

In dem Spezialfall, daß der Client und der Server, die sich beispielsweise auf einer gemeinsamen Plattform befinden, dem­ selben Prozeß zugewiesen werden können, sind die Objekte Ob­ jectHandler1 und ObjectHandler2 zu einem einzigen Objekt ver­ einigt. Gemäß der Fig. 1 sendet der ObjectHandler1 die ac­ tion_request-Nachricht in diesem Fall an sich selbst.

Fig. 2 zeigt ein Anwendungsbeispiel im Bereich einer System- Alarmierung in einem Telekommunikationssystem z. B. einem Fernsprechvermittlungssystem.

Bei einer System-Alarmierung gibt es beispielsweise folgende Objekte, die zugleich als Client und Server agieren und un­ tereinander unterschiedliche Aktionen anfordern können. Au­ ßerdem können sich die Objekte auf verschiedenen Plattformen befinden.

Ein Objekt Alarmbilanz-Monitor (ABM) hat die Aufgabe, eine Alarmbilanz über alle Alarme der von ihm überwachten alar­ mierbaren Instanzen (AMOI) zu ziehen. Um die Alarmbilanz zie­ hen zu können, benötigt der Alarmbilanz-Monitor mindestens ein sogenanntes SIBS-Objekt, das sich auf einer Prozessor­ plattform befindet und ihm eine gesammelte Information bezüg­ lich der überwachten alarmierbaren Instanzen liefert.

Die Kästchen stellen die Objekte Caller, AMOI (AlarmManage­ dObjectInstance), SIBS (SiteBalanceSupply) und ABM (AlarmBa­ lanceMonitor) dar. Durch die Pfeile, deren Art in der Legende im Anhang nicht aufgeführt ist, wird die Nachrichtenübertra­ gung gegebenfalls über Prozeßgrenzen hinweg zwischen den Ob­ jekten angedeutet. Die Nachrichtenübertragung entspricht da­ bei der in der Fig. 1 beschriebenen Nachrichtenübertragung zwischen Client und Server. So kann beispielsweise das Cal­ ler-Objekt als Client und das AMOI-Objekt als Server agieren. Entsprechendes gilt auch für die übrigen Objekte AMOI und SIBS sowie SIBS und ABM.

Nach einem System-Alarm-Aufruf set_alarm wird beispielsweise folgender Ablauf von Aktionen ausgelöst:

• - Set_alarm: Eine überwachte alarmierbare Instanz AMOI er­ hält von einem Aufrufer Caller einen neuen Alarm, prüft die den Alarm bestimmenden Parameter (check_params) und kreiert eine neue Alarminstanz (create_contained alarm).
• - Confirm: Eine Rückmeldung von der Instanz AMOI an die In­ stanz Caller nach dem System-Alarm-Aufruf set_alarm.
• - Balance SIBS: Mindestens ein Serverobjekt SIBS wird aufge­ fordert, die erhaltenen für die Alarmbilanz notwendigen Informationen zu sammeln (accumulate alarm status of all associated AMOI).
• - Balance ABM: Danach wird das Serverobjekt ABM aufgefor­ dert, die von den mindestens einen SIBS-Objekt erhaltenen Informationen für die Alarmbilanz zu sammeln (accumulate alarm status of all associated SIBS).

Da die Aktionen über Prozeßgrenzen hinweg angefordert werden, werden die Nachrichten von einem Objekt zu einem weiteren Ob­ jekt über eine aktive erste Instanz und über eine aktive wei­ tere Partnerinstanz übertragen wie z. B. über den ObjectHand­ ler1 und über den ObjectHandler2 aus Fig. 1, die beide in der Fig. 2 nicht dargestellt sind.

Die durch den ObjectHandler1 getroffende Auswahl des Objekt- Handlers2 kann anhand einer Zuordnungstabelle vorgenommen werden. Die Zuordnungstabelle sieht beispielsweise wie folgt aus:

Sofern eine bestimmte Aktion von unterschiedlichen Serverob­ jekten ausgeführt werden kann, kann die Zuordnung des Ob­ jectHandler2 abhängig von der Systemauslastung geändert wer­ den.

ANHANG

Legende zu den Figuren:

Claims (6)

1. Verfahren zur Nachrichtenübertragung zwischen einer einem ersten Prozeß zugewiesenen Clientinstanz (Client) und we­ nigstens einer mindestens einem weiteren Prozeß zugewiese­ nen Serverinstanz (Server) innerhalb eines verteilten Sy­ stems, wobei eine den ersten Prozeß enthaltende erste In­ stanz (ObjectHandler1) von als gegenseitige Kommunikati­ onspartner vorgesehenen Partnerinstanzen nach Empfang ei­ ner von der Clientinstanz an wenigstens eine Serverinstanz gerichteten Nachricht mindestens eine geeignete den minde­ stens einen weiteren Prozeß enthaltende weitere Instanz (ObjectHandler2) der Partnerinstanzen zur Nachrichtenan­ nahme und -weitergabe auswählt, die die Nachricht zu we­ nigstens einer von ihr adressierten Serverinstanz weiter­ leitet und gegebenfalls von der wenigstens einen Serverin­ stanz eine Nachricht zur Weiterleitung über die den ersten Prozeß enthaltende erste Instanz an die Clientinstanz er­ hält.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die den ersten Prozeß enhaltende erste Instanz die Auswahl der mindestens einen weiteren Prozeß enthaltenden weiteren Instanz anhand einer Zuordnungstabelle zwischen der Art der von der Clientinstanz aussendbaren Nachrichten und der Adresse der mindestens einen weiteren Prozeß ent­ haltenden weiteren Instanz trifft.

3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß die durch die den ersten Prozeß enthaltende erste Instanz getroffene Auswahl dynamisch in Abhängigkeit von der Systemauslastung änderbar ist.

4. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß dann, wenn der erste Prozeß und der mindestens eine weitere Prozeß zusammenfal­ len, die den ersten Prozeß enthaltende erste Instanz und die den mindestens einen weiteren Prozeß enthaltende wei­ tere Instanz in einer Instanz vereinigt sind.

5. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß sämtliche Instanzen in Form von Objekten implementiert sind, deren Struktur durch Objektklassen festgelegt wird.

6. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß es auf ein Fernsprech­ vermittlungssystem angewendet wird.