DE69032237T2

DE69032237T2 - Objektorientierte Softwaresystembauweise

Info

Publication number: DE69032237T2
Application number: DE69032237T
Authority: DE
Inventors: Erich Conrad Arnold; Olivia Maria Gagliardi; Wayne Edward Hyatt; Lawrence Gerard Mayka; Todd Cartwright Morgan
Original assignee: AT&T Corp
Current assignee: AT&T Corp
Priority date: 1989-06-30
Filing date: 1990-06-20
Publication date: 1998-08-13
Anticipated expiration: 2010-06-21
Also published as: EP0405829B1; EP0405829A3; EP0405829A2; DE69032237D1; JPH03103927A

Description

Die vorliegende Erfindung betrifft computerimplementierte Systeme.
Bekanntlich sind große Softwaresysteme, wie zum Beispiel Software zur Steuerung eines großen Telekommunikationssystems, kompliziert und kostspielig aufzubauen. Als Versuch, dieses Problem zu vermindern, werden große Softwaresysteme oft in Segmente oder Komponenten aufgeteilt. Die verschiedenen Komponenten derzeitiger großer Softwaresysteme sind jedoch durch Abhängigkeiten untrennbar miteinander verbunden, die ein großes Ausmaß an Koordination und Verhandlung unter den Entwicklern des Softwaresystems verursachen und diese häufig dazu zwingen, ihre Bemühungen zu synchronisieren, was die Entwicklung eines Projekts verlangsamt. Typischerweise muß der Entwickler auf syntaktische Fragen eingehen, wie zum Beispiel die Art der Gestaltung einer gegebenen globalen Datenstruktur oder die Reihenfolge der Argumente, die eine Funktion eines anderen Entwicklers Verlangt. Solche gegenseitigen Abhängigkeiten tragen zu den Kosten und der Entwicklungszeit der großen und komplizierten Systeme bei. Bevor ein Programm in eine Maschine geladen werden kann, muß es kompiliert werden, d.h. aus dem Quellencodeformat, in dem der Programmierer typischerweise das Programm schreibt, in das Objektcodeformat umgewandelt werden, das von der Maschine erkannt wird. Das Kompilieren umfaßt die Berechnung der richtigen Adressen anderer Programme und Datenbereiche, mit denen das kompilierte Programm kommuniziert. Somit kann das Kompilieren erst dann durchgeführt werden, wenn alle zugehörigen Programme vollständig definiert sind. Ähnlich kann ein kompiliertes Programm eines einzelnen Entwicklers erst dann auf der Maschine getestet werden, wenn alle anderen Programme, mit denen dieses Programm kommuniziert, geschrieben wurden und auf derselben Maschine funktionieren. Ähnliche Beschränkungen sind wirksam, wenn eine Änderung in einem Programm vorgenommen wird. Wenn zum Beispiel an einer Programmkomponente eine Änderung vorgenommen wird, die von anderen Programmkomponenten verwendet wird, dann müssen die anderen Programme, die von der überarbeiteten Komponente abhängen, ebenfalls neu kompiliert werden. Um in herkömmlichen Systemen eine Änderung ordungsgemäß zu integrieren, muß das gesamte Systemprogramm neu kompiliert werden, obwohl manchmal bestimmte begrenzte Änderungen vorgenommen werden können. In großen Systemen kann die Kompilierung normalerweise nur auf Offline-Computern durchgeführt werden. Somit ist es schwierig und zeitaufwendig, in einem großen programmgesteuerten System, wie zum Beispiel einem Telekommunikationsvermittlungssystem, Änderungen einzuführen, nachdem dieses am Einsatzort installiert wurde. Bei den in derzeitigen Systemen anzutreffenden gegenseitigen Abhängigkeiten von Programmkomponenten wurde bereits vor vielen Jahren erkannt, daß sie die Komplexitäten, den Zeitaufwand und die Kosten der Entwicklung oder Modifizierung eines komplizierten Softwaresystems erhöhen. Manche, aber nicht alle Probleme der gegenseitigen Abhängigkeit werden durch die bekannte Sprache LISP gelöst. LISP wird jedoch im allgemeinen für Echtzeitsysteme nicht als langsam angesehen. Mittlerweile wird anerkannt, daß Software mehr als 80 Prozent der Entwicklungszeit und der Kosten eines umfangreichen computergestützten Systems absorbiert. Dementsprechend wird intensiv nach Verbesserungen der Softwaretechnik gesucht.
Gemäß der vorliegenden Erfindung wird ein System nach Anspruch 1 bereitgestellt.
Eine verbesserte Softwarestruktur wird mittels eines Linkermechanismus bereitgestellt, deres Softwarekomponenten ermöglicht, bei der Kommunikation statt Adressen, die mit den physikalischen Eigenschaften des Systems zusammenhängen, symbolische Namen zu verwenden. Ein Protokoll für die Kommunikation zwischen Programmen setzt ausführbare Ausdrücke ein und verwendet dabei nur symbolische Namen. Vorteilhafterweise ermöglicht dieses Protokoll die unabhängige Entwicklung von kommunizierenden Softwarekomponenten. Ein Programmelement muß die Adresse eines anderen Elements nicht kennen. Genausowenig müssen die Sender- und Empfängerprogramme auf demselben Prozessor ablaufen oder wissen, ob sie auf demselben Prozessor ablaufen oder nicht. Darüber hinaus ermöglicht die Kommunikation zwischen Programmen mittels des ausführbaren Ausdrucks asynchrone Kommunikation, wobei ein Sender weiterlaufen kann, ohne auf eine Antwort warten zu müssen, was bei Echtzeitsystemen, wie zum Beispiel bei einem anreizgesteuerten Kommunikationsvermittlungssystem, von äußerster Wichtigkeit ist. Vorteilhafterweise für das Empfängerprogramm wird der ausführbare Ausdruck auf dieselbe Weise wie ein Verfahrensaufruf empfangen. Dadurch kann das Empfängerprogramm so geschrieben werden, als ob es durch den normalen Mechanismus des Aufrufs eines Verfahrens aufgerufen würde, während die Unabhängigkeit von Softwarekomponenten beim Kompilieren aufrechterhalten wird.
In einer Ausführungsform wird durch einen Linkermechanismus, der "Laufzeitlinker" (RTL - Run Time Linker) genannt wird, die Kommunikation zwischen unabhängigen Programmelementen bereitgestellt, die hier als "Objekte" bezeichnet werden. Der Laufzeitlinker enthält Tabellen für die Konvertierung symbolischer Objektnamen in System-Adreßbezeichnungen. Die Objekte kommunizieren nicht direkt miteinander, sondern alle Objekte kommunizieren über den Laufzeitlinker durch Übertragung des symbolischen Namens eines aufgerufenen Objekts und zu übertragender Informationen zu dem Laufzeitlinker. Der Laufzeitlinker reagiert, indem er das aufgerufene Objekt an der Systemadresse des aufgerufenen Objekts aufruft. Die Struktur von Nachrichten zwischen Objekten enthält den symbolischen Namen des Zielobjekts, den Symbolischen Namen des Verfahrens des Zielobjekts, das ausgeführt werden soll, und den symbolischen Namen des Senderobjekts. Die Nachricht stellt dem ausführenden Objekt den von dem Empfänger als Ziel für eine Antwortnachricht zu verwendenden Namen des Senderobjekts bereit. Vorteilhafterweise wird es durch die ausschließliche Verwendung symbolischer Namen zur Bewirkung der Kommunikation zwischen Komponenten möglich, ein bestehendes Objekt durch ein neues zu ersetzen, das möglicherweise zusätzliche Funktionen aufweist, ohne dabei den Rest der Software zu stören. Weiterhin wird Verbindungsbearbeitungssoftware für ein Telekommunikationsvermittlungssystem in unabhängige Objekte aufgeteilt, die jeweils spezifische Verbindungsabwicklungsfunktionen durchführen, die zu ausgewählten Einrichtungen wie zum Beispiel zu Anschlüssen, Verbindungsleitungen usw. gehören. Die Objekte der Verbindungsbearbeitungssoftware kommunizieren über ausführbare Ausdrücke (Nachrichten) mittels eines Laufzeitsystems, das Nachrichten zwischen Objekten auf demselben oder auf verschiedenen Prozessoren eines Multiprozessorsystems weiterleitet

Kurze Beschreibung der Zeichnung

Die Erfindung wird durch die folgende ausführliche Beschreibung im Zusammenhang mit der Zeichnung besser verständlich.
FIG. 1 ist eine Blockschaltbilddarstellung eines beispielhaften Telekommunikationsvermittlungssystems, das die Erfindung verkörpert;
FIG. 2 und 6 sind bildliche Darstellungen von Teilen der Anwendungssoftware zur Steuerung des Vermittlungssystems von FIG. 1;
FIG. 3, 4, 5, 7 und 8 sind Flußdiagramm darstellungen der Funktionen der Anwendungssoftware bei der Herstellung einer beispielhaften Verbindung;
FIG. 9 ist eine bildliche Darstellung von Laufzeitsystemsoftware zur Verwendung in dem System von FIG. 1;
FIG. 10, 11 und 12 sind Flußdiagrammdarstellungen von Aktionssequenzen des Laufzeitsystems von FIG.
FIG. 13 bis 18 sind Darstellungen von Tabellen und Warteschlangen in dem beispielhaften System; und
FIG. 19 ist eine Darstellung einer Reserveanordnung für das System von FIG. 1.

Ausführliche Beschreibung

FIG. 1 ist eine Blockschaltbilddarstellung eines beispielhaften verteilten Telekommunikationsvermittlungssystems zur Darstellung der Prinzipien der Erfindung. Das System umfaßt eine Mehrzahl von Prozessoren 101, von denen jeder einzelne mit einem Laufzeitsystem und mit objektorientierter Anwendungssoftware zur Ausführung von Telekommunikationsfunktionen ausgestattet ist. Die Prozessoren 101 sind durch einen Bus 103 miteinander verbunden, der Rundsendefähigkeiten, wie zum Beispiel das bekannte lokale Netzwerk ETHERNET, besitzt. Die Anwendungssoftware kann in einem einzigen Prozessor resident sein oder über die verschiedenen Prozessoren 101 verteilt sein. Bestimmte Anwendungssoftware, wie zum Beispiel die Objekte, die mit Peripheriegeräten kommunizieren, befinden sich vorzugsweise in Prozessoren, die (z.B. über die Verbindungsbusse 105) physikalische Verbindungen mit den Peripheriegeräten aufweisen. Die Prozessoren 101 können zum Beispiel der IVORY-Computer der Firma Symbolics oder der MICROEXPLORER-Prozessor der Firma Texas Instruments sein, die jeweils so eingerichtet werden, das auf ihnen Common LISP ablaufen kann.
In der beispielhaften Ausführungsform von FIG. 1 umfassen drei Vermittlungsmodule 120, 130 und 140 die Prozessoren 121, 131 bzw. 141 und die Koppelnetze 122, 132 bzw. 142. Die Koppelnetze 132 und 142 können mit Teilnehmeranschlüssen 110 oder mit Verbindungsleitungen 112 verbunden werden. Das Koppelnetz 122 kann für Sonderdienste, wie zum Beispiel das Koppeln von Breitbandleitungen für Videoverbindungen, reserviert sein. Die Prozessoren 121, 131 und 141 können zum Beispiel 68000-Prozesoren von Motorola sein und werden vorzugsweise in einer Sprache unterer Ebene, wie zum Beispiel in der bekannten Sprache C, programmiert, wobei zum Beispiel eine Echtzeitversion des Betriebssystems UNIX von AT&T verwendet wird. Die Koppelnetze 122, 132 und 142 enthalten die notwendigen und bekannten Anschluß- und Verbindungsanschlußschnittstellenschaltkreise und Netzstrukturen zur Herstellung von Verbindungen. Ein weiteres Koppelnetz, das Brückennetz 115, wird bereitgestellt, um die Netz- Koppeleinrichtungen 132 und 142 miteinander zu verbinden, um Wege zwischen Anschlüssen und Verbindungsleitungen der beiden verschiedenen Vermittlungsmodule bereitzustellen. Bekannte Vermittlungssysteme können vielfältige Vermittlungsmodule besitzen, von denen viele durch ein Koppelnetz wie zum Beispiel das Netz 115 miteinander verbunden werden können. Die Vermittlungsmodule 120, 130 und 140 von FIG. 1 können zum Beispiel die Vermittlungsmodule der Vermittlungsanlage 5ESS von AT&T sein, so wie es zum Beispiel in dem AT&T Technical Journal, Juli-August 1985, Band 64, Nr. 6, Teil 2 beschrieben wird, oder auch Vermittlungsmodule gemäß dem US-Patent 4 592 048. Die verbindende Vermittlungsanlage 115 kann, wie in diesem Patent beschrieben, ein Zeitvielfach sein und durch einen bekannten Steuerprozessor 116 gesteuert werden. Die mit den Vermittlungsmodulen 130 und 140 verbundenen Anschlüsse 110 und Verbindungsleitungen 112 können standardmäßige analoge oder digitale Anschlüsse und Verbindungsleitungen sein.
Softwarefunktionen können in Funktionen unterer Ebene, die enger mit der Peripheriehardware verbunden sind, und höherer Ebene, die unabhängiger von der Hardware sind und einfacher in einer Softwareumgebung höherer Ebene wie zum Beispiel LISP ausgeführt werden können, aufgeteilt werden. Die Prozessoren 116, 121, 131 und 141 werden vorzugsweise je nach Bedarf zur Durchführung von Funktionen unterer Ebene, wie zum Beispiel der Steuerung der Netze, und anderer Funktionen, wie zum Beispiel Erkennung der Verbindungseinleitung, Gabelbetätigungen, Verbindungsbeendigung, sowie zur Durchführung der Funktionen des Zusammenstellens von Ziffern und der Bereitstellung von Rufmelde- und Wähltonsignalen auf den zugehörigen Anschlüssen und Verbindungsleitungen verwendet. Diese Funktionen werden normalerweise in speicherprogrammgesteuerten Vermittlungssystemen durchgeführt und sind in der Technik bekannt. In der vorliegenden Anordnung kommunizieren die Prozessoren 101 mit den Vermittlungsmodulprozessoren und führen höhere hardwareunabhängige Kommunikationsfunktionen aus, die für die Bereitstellung von Kommunikationsdiensten erforderlich sind.
FIG. 2 ist eine bildliche Darstellung eines Teils der Anwendungssoftware zur Durchführung höherer Kommunikationsfunktionen, der in den LISP-Prozessoren 101 resident ist. Eine grundlegende Einheit in der Struktur der Verbindungsbearbeitungssoftware ist eine Gruppe miteinander in Zusammenhang stehender Softwarekomponenten, die Objekte genannt werden. Jedes der Objekte in dem System besitzt einen eindeutigen Namen, eine Menge von Operationen, die Verfahren genannt werden, und einen Zustand, der Instanzdaten genannt wird. Die Kommunikation zwischen Objekten erfolgt durch Nachrichten, wobei Informationselemente als Schlüsselworte und Wertepaare dargestellt werden; Schlüsselworte werden durch Symbole und Werte durch eine Menge von selbsterklärenden Datentypen, d.h. Symbolen, Zahlen, Zeichenketten oder eine Liste dieser Werte, dargestellt, so wie es gewöhnlicherweise in LISP durchgeführt wird. Alle Nachrichten identifizieren den symbolischen Namen des Empfängers, den symbolischen Namen des Senders, den symbolischen Namen des Verfahrens des Empfängers, dem auf diesem Weg der Nachricht die Steuerung übergeben werden soll, und eine Liste von Argumenten, die von dem Empfängerverfahren erwartet werden. Jeder der Prozessoren 101 besitzt ein Laufzeit-Softwaresystem, durch das die Nachrichten zwischen Objekten weitergeleitet werden, was ausführlicher mit Bezug auf FIG. 10 bis 12 besprochen wird. Wenn eine Nachricht zwischen Komponenten weitergeleitet wird, die sich in demselben Prozessor befinden, dann konvertiert das Laufzeitsystem symbolische Namen in Systemadressen und leitet die Nachricht an den beabsichtigten Empfänger weiter. Wenn der beabsichtigte Empfänger nicht in dem Prozessor des Ursprungsobjekts gefunden wird, dann überträgt das Laufzeitsystem des Ursprungsprozessors die Nachricht zu dem Empfängerprozessor, und das Laufzeitsystem des Empfängerprozessors setzt die symbolischen Namen in Systemadressen um. Die Sender- und Empfängerobjekte kommunizieren direkt nur mit dem residenten Laufzeitsystem und werden nicht dadurch beeinflußt, daß eine Kommunikation zwischen Prozessoren stattfindet.
Objekte können als statisch oder dynamisch charakterisiert werden. Statische Objekte umfassen die Konfiguration der Telekommunikationsvermittlungsstelle und existieren unabhängig von allen Verbindungsaktivitäten in der Vermittlung. Dynamische Objekte werden vorübergehend erzeugt (zum Beispiel für die Dauer einer Verbindung). Objekte können durch statische oder dynamische Zwischenleitungen miteinander verbunden werden. Eine statische Zwischenleitung besteht nur zwischen statischen Komponenten und kann als Teil der Konfiguration der Vermittlung angesehen werden. Dynamische Zwischenleitungen können zwischen zwei statischen Komponenten, zwei dynamischen Komponenten oder zwischen einer statischen und einer dynamischen Komponente bestehen. Dynamische Zwischenleitungen werden nur für einen bestimmten Zweck eingerichtet, wie zum Beispiel für das Weiterleiten von Nachrichten für die Dauer einer spezifischen Verbindung. Das Laufzeitsystem erzeugt Objekte aus einer Klasse von Komponenten, die durch einen Programmierer in der Softwareumgebung definiert wird, als eine Schablone für die Art und Weise der Konstituierung der Komponenteninstanz in dem Zielsystem. Die Klasse enthält eine Definition der Instanz von Datenelementen, die durch die Komponente verwaltet werden, und die Menge von Verfahren (Programmtext), die ausschließlichen Zugang zu den Instanzdaten haben. Statische Objekte werden in dem System erzeugt, wenn die Konfiguration der Vermittlung eingeleitet oder modifiziert wird. Dynamische Objekte werden für einen spezifischen Zweck erzeugt, wie zum Beispiel für eine bestimmte Telefonverbindung, und werden bei Beendigung der Verbindung zerstört.
Für jeden aktiven Teilnehmer des Systems, der mindestens einen aktiven Telefonanschluß besitzt, der mit mindestens einem Telekommunikationsanschlußpunkt verbunden ist, existieren mindestens drei miteinander in Zusammenhang stehende Objekte. Diese sind als das Teilnehmerobjekt, das Anschlußobjekt und das Portobjekt bekannt. Ein Teilnehmer kann mehr als einen Anschluß besitzen, und es wird für jeden dem Teilnehmer zugewiesenen Anschluß ein separates Anschlußobjekt bereitgestellt. Darüber hinaus kann ein Anschluß mehr als ein zugeordnetes Portobjekt aufweisen. Zum Beispiel kann ein digitaler ISDN-Teilnehmeranschluß mehr als ein Endgerät aufweisen, und es wird für jedes solcher Endgeräte ein separates Portobjekt bereitgestellt. Für jeden verfügbaren Anschluß- oder Verbindungsleitungsabschluß des Systems wird auf dem Prozessor 101 ein Portobjekt erzeugt. Anschluß- und Teilnehmerobjekte werden erzeugt, wenn den Ports Teilnehmer zugewiesen werden. Anschlußobjekte werden durch bidirektionale statische Zwischenleitungen mit den mit ihnen in Zusammenhang stehenden Teilnehmer- und Portobjekten verbunden. Die Zwischenleitungen existieren solange, wie der Zusammenhang besteht. Diese statische Verbindung ist in FIG. 2 mit durchgängigen Linien gezeigt, während die dynamische Verbindung (z.B. für die Dauer einer Verbindung) durch gepunktete Linien gezeigt ist. Ein Portobjekt stellt die physikalische Erscheinung der Endeinrichtungen eines Teilnehmers dar und kommuniziert mit dem Prozessor des Vermittlungsmoduls, mit dem die Endeinrichtungen physikalisch verbunden sind. Wenn der Teilnehmer über einen digitalen ISDN-Teilnehmeranschluß mit der Vermittlung verbunden ist, dann ist das Portobjekt für die D-Kanal-Zeichengabeschnittstelle verantwortlich. Ein Anschlußobjekt stellt die logische Netzadresse dar und ist für die Netzleitwegführung und anschlußspezifische Funktionen verantwortlich. Ein Teilnehmerobjekt ist für die Gebührenberechnung, die Anrufüberwachung und andere Funktionen verantwortlich, die allen Anschlüssen, die der Teilnehmer besitzt, gemeinsam sind. Die verschiedenen Objekte, die in FIG. 2 gezeigt sind, können unabhängig von deren Verbindung über mehrere der Hostprozessoren 101 verteilt sein. Aus Gründen der Rationalität sind die Portobjekte vorzugsweise in denjenigen der Prozessoren 101 resident, die über den Bus 105 mit dem Vermittlungsmodul verbunden sind, mit dem die zugeordneten Endeinrichtungen verbunden sind.
Der folgende Abschnitt illustriert die Wechselwirkungen der verschiedenen Objekte bei der Herstellung einer beispielhaften Verbindung zwischen zwei Teilnehmern. Beispielsweise wird angenommen, daß eine Verbindung von einem Port aus eingeleitet wird, der der Rufnummer 555-2000 zugeordnet ist, und an die Rufnummer 555-3000 gerichtet ist. Der Ablauf dieser beispielhaften Verbindung wird mit Bezug auf FIG. 2 bis 5 beschrieben. Wie im Block 501 von FIG. 3 angegeben, wird die Bearbeitung einer Verbindung in der objektorientierten High-Level-Anwendungssoftware eingeleitet, wenn eines der Portobjekte eine Einleitungsanforderung erkennt. Der rufende Teilnehmer kann zum Beispiel mit einem der Teilnehmeranschlüsse 110 des Vermittlungsmoduls 130 verbunden sein. Die zum Beispiel durch ein Beginnzeichen auf einem analogen Anschluß erfolgende Verbindungseinleitung wird mittels bekannter Scanner oder dergleichen und zugeordneter Low-Level-Software erkannt, die auf eine standardmäßige und bekannte Weise in das Vermittlungsmodul 130 integriert ist. Eine Einleitungsanforderungsnachricht wird von dem Modul 130 aus über das Laufzeitsystem des zugeordneten der Prozessoren 101 zu dem Portobjekt übertragen. In diesem Beispiel wird das zugeordnete Portobjekt als Port A gekennzeichnet, der in FIG. 2 bei gezeigt ist. Das Portobjekt 215 sendet eine Nachricht, die die erkannte Einleitungsanforderung zu dem bei 212 gezeigten zugeordneten Anschlußobjekt widerspiegelt, bei dem es sich um das Ursprungs- Anschlußobjekt handelt, auf das sich der Block 502 in FIG. 3 bezieht. Eine beispielhafte Nachricht ist in Tabelle A gezeigt. Das Anschlußobjekt 212 erzeugt ein Verbindungs-Organisationsobjekt 250, so wie es im Block 504 gezeigt ist. Die Erzeugung des Verbindungsorganisators wird mittels einer Nachricht von dem Anschlußobjekt zu dem lokalen Laufzeitsystem durchgeführt, indem der Klassenname des gewünschten Objekts und eine optionale Objektnamenbezeichnung bereitgestellt werden. In diesem illustrativen System ist der Verbindungsorganisator ein dynamisches Objekt, das nur für die Dauer einer Verbindung existiert und zerstört wird, wenn die Verbindung beendet ist. Nachdem der Verbindungsorganisator 250 erzeugt wurde, sendet das Anschlußobjekt 212 den Namen S100 des zugeordneten Teilnehmerobjekts 210 und den Namen A123 des zugeordneten Portobjekts 215 zu dem Verbindungsorganisator 250, was im Block 506 von FIG. 3 angedeutet wird. Eine beispielhafte Nachricht ist in Tabelle A gezeigt (Nachricht 2). Der Verbindungsorganisator kennt den Namen des Anschlußobjekts, das den Organisator aufgrund der aus dem Anschlußobjekt stammenden, den Namen des Anrufers enthaltenden Übermittlungen erzeugt hat.
Der Verbindungsorganisator 250 überträgt über das Laufzeitsystem eine Nachricht zu dem Portobjekt 215 mit dem Namen A123, den der Verbindungsorganisator zuvor von dem zugeordneten Anschlußobjekt 212 empfangen hat. Die Nachricht leitet das Portobjekt dazu an, Ziffern zusammenzustellen, was im Block 508 von FIG. 3 angedeutet wird. Die Ziffern können in dem zugeordneten Vermittlungsmodul, d.h. in diesem Beispiel in dem Modul 130, auf eine bekannte Weise zusammengestellt und zu dem Portobjekt übertragen werden. In diesem Beispiel stellen die zusammengestellten Ziffern die Nummer 555- 3000 eines mit einem der Teilnehmeranschlüsse 110 des Vermittlungsmoduls 140 verbunden Teilnehmers dar. Das Portobjekt 215 überträgt die zusammengestellten Ziffern zusammen mit dem Namen seines zugeordneten Struktursteuerungsobjekts zu dem Verbindungsorganisator 250, was im Block 509 angedeutet wird. Eine beispielhafte Nachricht ist in Tabelle A gezeigt (Nachricht 3).
Den Koppelnetzen 122, 132 und 142 sind die Struktursteuerungsobjekte 230, 231 bzw. 235 zugeordnet. Die Struktursteuerung leitet von den ihr bereitgestellten Informationen über den Kanal und den anrufenden und den angerufenen Port Netzverbindungsinformationen ab und überträgt die abgeleiteten Informationen zu dem entsprechenden Prozessor zur Steuerung des zugeordneten Netzes, um die gewünschte Verbindung herzustellen. Falls sich die beiden bei einer Verbindung beteiligten Ports in demselben Vermittlungsmodul befinden, ist nur eine Struktursteuerung bei der Verbindung beteiligt. Wenn jedoch der Ursprungs-Teilnehmerport mit einem Vermittlungsmodul und der End-Teilnehmerport mit einem anderen Vermittlungsmodul verbunden ist, dann sind Ursprungs- und End-Struktursteuerungsobjekte beteiligt.
Wenn ferner zwei Vermittlungsmodule bei einer Verbindung beteiligt sind, dann muß zwischen ihnen durch das verbindende Koppelnetz 115 eine Verbindung hergestellt werden. Das Koppelnetz 115 wird durch den Prozessor 116 gesteuert, der über einen der Busse 105 mit einem der Verbindungsbearbeitungsprozessoren 101 verbunden ist. Das Koppelnetz und der Prozessor stellen für das System ein separates physikalisches Betriebsmittel dar, und ein in FIG. 2 durch die Zahl gekennzeichnetes Softwareobjekt, das als Brückensteuerung bezeichnet wird, übermittelt Verbindungsinformationen zu dem Prozessor 116. Die Brückensteuerung erhält Informationen von den bei einer Verbindung beteiligten Struktursteuerungen, um Verbindungsinformationen für das Brückennetz 115 zu erzeugen. Da die Koppelnetze 122, 132 und 142 und das Brückennetz 115 physikalische Betriebsmittel sind, werden die Struktursteuerungen und die Brückensteuerung, die den Netzen entsprechen, zu dem Zeitpunkt erzeugt, wenn das physikalische Betriebsmittel zu dem System hinzugefügt wird.
Gleichermaßen werden Portobjekte in dem Moment erzeugt, wenn Netzabschlüsse zu dem System hinzugefügt werden und der Name der dem Port zugeordneten Struktursteuerung wird in dem Portobjekt aufgezeichnet.
Ähnlich wird der Name der Brückensteuerung 250 den Struktursteuerungen bereitgestellt, die eventuell das Brückensteuerungsobjekt aufrufen müssen, um Verbindungen durch das Brückennetz zu erhalten.
Der Name der Ursprungs-Struktursteuerung, der zu dem Verbindungsorganisator 250 weitergeleitet wird, was im Block 509 angedeutet wird, ist in diesem illustrativen Beispiel FC1000, der Name der Struktursteuerung 231. Wie im Block 510 von FIG. 5 angedeutet, wird eine Nachricht einer ankommenden Verbindung durch den Verbindungsorganisator unter Verwendung des Namens des End-Anschlußobjekts, 555- 3000, rundgesendet. Eine beispielhafte Nachricht ist in Tabelle A gezeigt (Nachricht 4)5 Wenn 555-3000 tatsächlich eine aktive Nummer in dem Vermittlungssystem ist, dann existiert ein Anschlußobjekt mit diesem Namen. Alle Nachrichten, einschließlich der Rundsendenachricht aus dem Verbindungsorganisator 250, werden durch das Laufzeitsystem übertragen. Rundsendenachrichten werden über den Bus 103 zu jedem der Prozessoren verteilt, und das Laufzeitsystem jedes Prozessors empfängt und analysiert den Alias-Namen.
Wenn ein Laufzeitsystem den Rundsende-Namen als zu einem Objekt auf seinem Prozessor gehörend erkennt, dann wird die Nachricht von diesem Laufzeitsystem zu dem adressierten Objekt übertragen und wird, wie im Block 512 von Fig. 3 angedeutet, empfangen. In diesem Beispiel ist das Anschlußobjekt 222 das End-Anschlußobjekt mit dem Rundsende-Alias-Namen 555-3000 und empfängt die Nachricht.
Nach dem Empfang der Rundsendenachricht mit dem Alias-Namen 555-3000 stellt das End-Anschlußobjekt 222 fest, ob einer der beiden Ports, Port A oder Port B, die diesem Anschluß zugeordnet sind, verfügbar ist, was im Block 514 in FIG. 3 angedeutet wird. Wenn ein Port verfügbar ist, dann überträgt das End-Anschlußobjekt 222 eine Nachricht "Weg fertig" zu dem Verbindungsorganisator 250, was im Block 516 in FIG. 4 angedeutet wird. Die Nachricht enthält den Namen des End-Anschlußobjekts (zum Beispiel A456) und den Namen des End-Teilnehmerobjekts (zum Beispiel S400). Diese Namen sind dem Anschlußobjekt aufgrund der zum Zeitpunkt der Erzeugung der Teilnehmer- und Anschlußobjekte in dem Objekt mit eingeschlossenen Verknüpfung bekannt. Eine beispielhafte Nachricht ist in Tabelle A gezeigt (Nachricht 5). Wie im Block 518 von FIG. 4 angedeutet, sendet der Verbindungs- Organisator 250 eine Rufmeldenachricht (Tabelle A, Nachricht 6) zu dem End-Portobjekt 225 mit dem Namen A456, um zu bewirken, daß dieser Port seiner zugeordneten Teilnehmerendeinrichtung ein Rufmeldesignal bereitstellt, und sendet außerdem eine Nachricht (Tabelle A, Nachricht 7) zu dem Ursprungs-Portobjekt 215 mit dem Namen A123, um zu bewirken, daß seine zugeordnete Teilnehmerendeinrichtung ein hörbares Rufsignal empfängt. Das End-Portobjekt 225 sendet eine Nachricht (Tabelle A, Nachricht 8) mit dem Namen der zugeordneten Struktursteuerung 235, FC2000, zu dem Verbindungsorganisator 250, was im Block 520 angedeutet wird, und wartet auf ein Beginnzeichen. In der Zwischenzeit sendet der Verbindungsorganisator 250, wie im Block 521 angedeutet, Nachrichten (Tabelle A, Nachrichten 9 und 10) zu den Struktursteuerungen 231 und 235, um zu bewirken, daß diese einen Weg für die Herstellung einer Verbindung reservieren. In diesem Beispiel ist der anrufende Teilnehmer mit einem Modul 130 verbunden, und der angerufene Teilnehmer ist mit dem Modul 140 verbunden (FIG. 1). Dementsprechend sind bei dieser beispielhaften Verbindung die Koppelnetze 132 und 142 und das Brückennetz 115 beteiligt. Das Struktursteuerungsobjekt 231 steuert über den Bus 105 durch Nachrichten zu dem Prozessor 131 das Koppelnetz 132, die Struktursteuerung 235 steuert über den Bus 105 durch Nachrichten zu dem Prozessor 141 das Koppelnetz 142 und die Brückensteuerung 250 steuert über den Bus 105 durch Nachrichten zu dem Prozessor 116 das Brückennetz 115. Jede Struktursteuerung umfaßt die Programme und Daten zum Auswählen eines verfügbaren Weges durch ihr zugeordnetes Netz hindurch als Reaktion auf eine Nachricht, die den Namen eines dem Netz zugeordneten Portobjekts und den Namen der Brückensteuerung definiert. Tabelle A, Nachricht 9 ist eine beispielhafte Nachricht, die aus dem Verbindungsorganisator 250 (CMA123) zu der Steuerung 231 (FC1000) gesendet wird und das Portobjekt 215 (A123) und die Struktursteuerung 260 (BC5000) benennt. Tabelle A, Nachricht 10 zeigt eine analoge Nachricht, die zu der Struktursteuerung 235 gesendet wird. Solche Nachrichten werden wie im Block 521 angedeutet übertragen. Jede Struktursteuerung wählt einen Weg durch ihr zugeordnetes Netz hindurch von der Netzabschlußeinrichtung aus, die dem identifizierten Portobjekt zugeordnet ist, zu einer Zwischenverbindung zu dem Brückennetz und sendet der Brückensteuerung 260 eine Nachricht, die die gewählte Verbindung und die Identität der Verbindung identifiziert. Die Identität der Verbindung kann als dieselbe wie der Name des Verbindungsorganisators (CMA123) gewählt werden, da dies ein eindeutiger Name ist und der Verbindungsorganisator nur für die Dauer der Verbindung existiert. Die Nachrichten 11 und 12 in Tabelle A stellen Nachrichten dar, die von der Struktursteuerung 231 (FC1000) bzw. 235 (FC2000) zu der Brückensteuerung (BC5000) gesendet werden und einen Weg bei der Brückensteuerung reservieren, was im Block 522 angedeutet wird. Die Nachricht identifiziert die Verbindung (CMA123) und die von den Struktursteuerungen gewählten Netzverbindungen (X, Y).
Nach dem Empfang einer Rufmeldenachricht aus dem Verbindungsorganisator zum Anlegen eines Rufmeldesignals an die zugeordnete Endeinrichtung, was im Block 518 angedeutet wird, wartet das Portobjekt 225 auf ein Beginnzeichen aus den zugeordneten Schaltkreisen der Endeinrichtung und entsprechender Software in dem Vermittlungsmodul 140. Bei Empfang der Beginn-Meldung sendet das End-Portobjekt 225 (A456) eine Beginn-Nachricht (Tabelle A, Nachricht 13) zu dem Verbindungsorganisator 250 (CMA123), wenn wie im Block 524 von FIG. 4 angedeutet der Beginn erkannt wird.
Danach sendet der Verbindungsorganisator 250 (CMA123) eine Nachricht (Tabelle A, Nachricht 14) zu dem Ursprungs-Portobjekt 215 (A123), mit dem Senden hörbarer Signale zu dem Ursprungs-Teilnehmer aufzuhören, sendet Nachrichten (Tabelle A, Nachricht 15, 16) zu den Struktursteuerungen (FC1000, FC2000), über den reservierten Weg eine Verbindung herzustellen, und sendet für Zwecke der Gebührenberechnung eine Nachricht (Tabelle A, Nachrichten 17 und 18) zu den Teilnehmerobjekten 210 und 220, daß eine Verbindung hergestellt wurde. Die Aktionen sind allgemein im Block 526 (FIG. 4) angedeutet. Die Struktursteuerungen (FC1000, FC2000) senden Verbindungsnachrichten (Tabelle A, Nachrichten 19 und 20) zu der Brückensteuerung (BC5000), wie im Block 527 von FIG. 4 angedeutet.
Zu diesem Zeitpunkt wurde eine Verbindung hergestellt, und es können durch die Portobjekte und die Struktursteuerungsobjekte stabile Verbindungs- Audits durchgeführt werden, indem periodische Abfragenachrichten zu dem Verbindungsorganisator gesendet werden, um dessen fortgesetzte Existenz zu überprüfen. Wenn die Verbindung aus irgendeinem Grund unterbrochen wird und der Verbindungsorganisator beendet wird, dann treffen die Portobjekte und Struktursteuerungsobjekte Maßnahmen zur Beendigung der Verbindungen des Anrufs. Die stabilen Verbindungs Audits sind im Block 528 von FIG. 4 angedeutet. Wenn die Verbindung durch das Einhängen entweder durch den anrufenden oder den angerufenen Teilnehmer beendet wird, dann empfängt das zugeordnete Portobjekt eine Einhängemeldung aus dem zugeordneten Vermittlungsmodul und sendet eine Schlußnachricht (Tabelle A, Nachricht 21, 22) zu dem Verbindungsorganisator 250, die das Ende der Verbindung anzeigt, so wie es im Block 530 von FIG. 4 abgebildet ist. Der Verbindungsorganisator reagiert auf die erste solche Nachricht entweder aus dem End- oder dem Ursprungs-Portobjekt und leitet den Vorgang des Verbindungsabbaus ein. Eine zweite Einhängenachricht aus dem anderen Portobjekt wird, wenn der Abbauvorgang bereits begonnen hat, einfach ignoriert. Der Verbindungsorganisator 250 sendet Schlußnachrichten (Tabelle A, Nachrichten 23-30) zu den Struktursteuerungsobjekten 231 (FC1000) und 235 (FC2000), zu den Portobjekten 215 (A123) und 225 (A456), zu den Anschlußobjekten 212 (123) und 222 (456) und zu den Teilnehmerobjekten 210 (S100) und 220 (S400). Dies wird im Block 532 von FIG. 4 angedeutet.
Die Struktursteuerungsobjekte 231 und 233 reagieren jeweils auf die Schlußnachricht aus dem Verbindungsorganisator, indem sie eine Schlußnachricht (Tabelle A, Nachricht 31,32) zu der Brückensteuerung 260 (BC5000) senden, was im Block 533 angedeutet wird, und indem sie alle weiteren stabilen Verbindungs-Audits stoppen und den hergestellten Weg durch die zugeordneten Netze auf bekannte Weise freigeben. Ähnlich bewirkt die Brückensteuerung die Freigabe des Wegs für diese Verbindung in dem Brückennetz 115.
Außerdem stoppen die Portobjekte die Audits und korrigieren ihre internen Daten, um den Abschluß einer Verbindung anzudeuten. Die Anschlußobjekte reagieren auf die Schlußnachricht, indem sie interne Daten verändern, um den Abschluß einer Verbindung anzudeuten, was auch auf die Teilnehmerobjekte zutrifft, die zusätzlich auf die Schlußnachricht mit dem Abschluß der Zeitspanne der Gebührenberechnung reagieren. Nach der Obertragung der Schlußnachrichten zerstört sich das Verbindungs-Organisationsobjekt 250 selbst, indem es bewirkt, daß das Laufzeitsystem seinen Namen aus dem System entfernt und den für die Verbindung reservierten Speicher freigibt.
In dem Entscheidungsblock 514 von FIG. 3 prüft das End-Portobjekt, ob ein Port für eine Verbindung verfügbar ist. Wenn dies nicht der Fall ist, dann wird eine Nichtverfügbarkeitsnachricht von dem End- Portobjekt 225 zu dem Verbindungsorganisator 250 gesendet, was im Block 540 von FIG. 5 angedeutet wird.
Danach wird eine Anforderungsnachricht von dem Verbindungsorganisator zu dem End-Teilnehmerobjekt 220 gesendet, was im Block 542 angedeutet wird. Da das Teilnehmerobjekt Einzelheiten der Teilnehmer- Dienstoptionen enthält, ist die Anforderungsnachricht von dem Verbindungsorganisator zu dem Teilnehmerobjekt gleichbedeutend mit einer Anforderung weiterer Informationen. In diesem Beispiel prüft das Teilnehmerobjekt, wie im Block 546 angedeutet, ob Anrufweiterschaltung definiert wurde. Wenn ja, dann wird die Anrufweiterschaltungsnummer wie im Block 547 angedeutet zu den Verbindungsorganisatoren gesendet, und der Verbindungsorganisator sendet eine Nachricht eines ankommenden Anrufs mit der Anrufweiterschaltungsnummer rund, was im Block 510 von FIG. 3 angedeutet wird. Danach wird die Verbindung auf die gleiche Weise wie eine abgeschlossene Verbindung wie oben beschrieben behandelt. Falls die Prüfung im Block 546 anzeigt, daß keine Anrufweiterschaltung erfolgen soll, dann wird eine Zurückweisungsnachricht zu dem Verbindungsorganisator gesendet, was im Block 548 angedeutet wird. Der Verbindungsorganisator stellt dem Ursprungsport 215 eine Nachricht bereit, der Teilnehmerendeinrichtung einen Besetztton bereitzustellen. Danach wartet das System wie im Block 552 angedeutet auf ein Einhängesignal, und wenn ein Einhängesignal erkannt wird, dann wird eine Einhängenachricht von dem Ursprungs-Portobjekt 215 zu dem Verbindungsorganisator 250 gesendet, was im Block 553 angedeutet wird. Danach sendet der Verbindungsorganisator Schlußnachrichten zu dem Ursprungs-Portobjekt, dem Ursprungs-Anschlußobjekt und dem Ursprungs-Teilnehmerobjekt, was im Block 544 angedeutet wird. Als letztes zerstört sich das Verbindungs-Organisationsobjekt 250 selbst, indem es bewirkt, daß das Laufzeitsystern seinen Namen aus dem System entfernt und den für die Verbindung reservierten Speicher freigibt. Die in den Blöcken 540 bis 556 verwendeten Nachrichten sind nicht im Detail gezeigt, da diese Nachrichten den beispielhaften Nachrichten von Tabelle A gleich sind.
In den vorangehenden Absätzen wurde mit Bezug auf FIG. 3 bis 5 eine Ortsverbindung beschrieben, d.h. ein Anruf zu einer anderen Teilnehmernummer innerhalb desselben Systems, aber auf einem anderen Vermittlungsmodul. Im Fall eines Anrufs zu einem anderen Vermittlungssystem innerhalb des sogenannten Ortsnetzes (Local Access Transport Area, LATA) analysiert ein als Tandem-Agent bekanntes Objekt (das in den Zeichnungen nicht gezeigt ist) die durch den Verbindungsorganisator rundgesendete angerufene Telefonnummer und überträgt die Nummer über eine der Verbindungsleitungen 112 zu dem identifizierten System innerhalb desselben LATA. In einem solchen Fall wird der Anruf in dem Ziel-Vermittlungssystem auf die gleiche Weise wie oben mit Bezug auf FIG. 3 bis 5 für Ortsverbindungen beschrieben bearbeitet. Anrufe außerhalb des LATA, d.h. Anrufe, denen eine Bereichskennzahl vorausgeht, z.B. 1-312, erfordern einen Weitverkehrsnetzbetreiber. FIG. 6 zeigt eine Mehrzahl von Betreiber-Agentenobjekten 271, 272 und 273, die Steuerungsobjekte 290, 294 für Betreibereinrichtungen, die Verbindungsleitungssteuerungsobjekte 291, 292, ein Verbindungs-Organisationsobjekt 270, die Teilnehmer-, Anschluß- und Portobjekte 280, 281, 282 und das Struktursteuerungsobjekt 283. Die verschiedenen Betreiber-Agentenobjekte stellen verschiedene Weitverkehrsnetzbetreiber wie zum Beispiel AT&T, MCI, Sprint usw. dar. Wenn in diesem beispielhaften Vermittlungssystem eine Rufeinleitung erkannt wird, dann werden ein erzeugtes Verbindungs-Organisationsobjekt, z.B. das Verbindungs-Organisationsobjekt 270, und die von dem anrufenden Teilnehmer gewählte angerufene Nummer zu dem Verbindungs-Organisationsobjekt übertragen. Wie oben mit Bezug auf FIG. 3 beschrieben, sendet das Verbindungs-Organisationsobjekt die Nummer als einen Alias-Namen rund. Wenn die eingeleitete Verbindung eine Fernverbindung ist, dann enthält die Nummer die Bereichskennzahl. Da die Bereichskennzahl ein Teil des rundgesendeten Namens ist, reagieren nur Betreiber-Agentenobjekte. Gemäß der vorliegenden Erfindung werden den Betreiber-Agenten 271, 272, 273 Alias-Namen oder Namensteile darstellende Namensmuster (z.B. 1-518*) zugewiesen, die allen Bereichskennzahlen entsprechen, die durch den Betreiber-Agenten versorgt werden können. Das später ausführlicher zu besprechende Laufzeitsystem besitzt die Fähigkeit des Mustervergleichs, wodurch alle Nachrichten mit dem definierten Alias-Namensmuster (z.B. 1-518) an alle Objekte übermittelt werden können, die dieses Muster als einen Alias-Namen aufweisen. Wenn der Verbindungsorganisator eine Nachricht mit einem Aliasnamen rundsendet, der eine Bereichskennzahl enthält, dann wird dieser durch das Laufzeitsystem zu allen Betreiber-Agentenobjekten weitergeleitet. Somit erkennt das Laufzeitsystem im Fall, daß die rundgesendete Nummer zum Beispiel die Bereichskennzahl 1-312 enthält, daß dies das Alias-Namensmuster für die Betreiber-Agenten 271 und 272 (FIG. 6) enthält, und überträgt die Rundsendenachricht zu diesen beiden Objekten. Die Objekte enthalten Informationen, die die Belegungszustände ihrer Verbindungsleitungsschaltkreise definieren, und können deshalb feststellen, ob bei ihnen Einrichtungen für die Bearbeitung des rundgesendeten Anrufs verfügbar sind. Wenn zwei der Betreiber-Agentenobjekte 271 und 272 in der Lage sind, die Fernverbindung zu bearbeiten, dann übertragen beide eine Annahmenachricht zu dem Verbindungsorganisator 270. Der Verbindungsorganisator gibt die Nachricht seinerseits zu dem Teilnehmerobjekt 280 weiter. Das Teilnehmerobjekt kann dann gemäß einem vordefinierten Algorithmus wählen, welcher Betreiber ausgewählt wird. Als Alternative kann das Teilnehmerobjekt den Verbindungsorganisator dazu auffordern, dem Teilnehmer die Identität der verfügbaren Betreiber anzuleigen, falls der Teilnehmer über Endeinrichtungen verfügt, die in der Lage sind, solche Informationen anzuzeigen. In diesem Fall überträgt der Verbindungsorganisator 250 eine Nachricht zu dem Portobjekt 215, die bewirkt, daß dem Kunden die Informationen auf bekannte herkömmliche Weise, zum Beispiel mit ISDN-Terminals, hörbar oder durch Anzeige präsentiert werden. Das Teilnehmerobjekt gibt dem Verbindungsorganisator Informationen zurück, die einen ausgewählten Weitverkehrsnetzbetreiber definieren.
FIG. 7 und 8 stellen die Aktionen des Systems bei der Herstellung einer Fernverbindung in Flußdiagrammform dar. Wenn eine Fernverbindung von einem Teilnehmer aus eingeleitet wird, der mit einem der Anschlüsse 110 zum Beispiel des Vermittlungsmoduls 130 verbunden ist, dann wird die Einleitung in dem Verrnittlungsmodul erkannt, und es werden entsprechende Informationen zu dem zugeordneten Portobjekt der Anwendungssoftware in einem der Verbindungsbearbeitungsprozessoren 101 übertragen, so wie es bereits mit Bezug auf FIG. 3 beschrieben wurde und im Block 560 von FIG. 7 angedeutet ist. Das Portobjekt kann zum Beispiel das Portobjekt 282 sein, das dem Anschlußobjekt 281 und dem Teilnehmerobjekt 280 zugeordnet ist. Wie bereits mit Bezug auf eine Ortsverbindung beschrieben, überträgt das Portobjekt die Einleitungsinformationen über das Laufzeitsystem mittels einer Nachricht zwischen Objekten zu dem Ursprungs-Anschlußobjekt 281. Diese Aktion wird im Block 562 von FIG. 7 angedeutet. Als Reaktion erzeugt das Anschlußobjekt 281 wie im Block 564 angedeutet mittels einer Nachricht zu dem Laufzeitsystem einen Verbindungsorganisator. Der Verbindungsorganisator kann zum Beispiel der Verbindungsorganisator 270 sein, der eigens für diese Verbindung eingerichtet wird. Außerdem überträgt das Anschlußobjekt 281 die Identität des Portobjekts 282 und des zugeordneten Teilnehmerobjekts 280 zu dem Verbindungsorganisator, was im Block 566 von FIG. 6 angedeutet wird. Die Einzelheiten der Nachrichten sind nicht gezeigt, da sie den Nachrichten von Tabelle A gleichen, die ausführlich mit Bezug auf FIG. 3 bis 5 beschrieben wurden. Wie im Block 568 gezeigt, erhält das Ursprungs-Portobjekt Informationen, die von dem Teilnehmer gewählte Ziffern definieren, die in diesem Beispiel eine abgehende Fernverbindung definieren. Danach überträgt das Portobjekt 282 eine Nachricht zu dem Verbindungsorganisator 270, die den Namen seiner zugeordneten Struktursteuerung und Information definieren, die die zusammengestellten Ziffern definieren, was im Block 569 von FIG. 7 angedeutet wird. Der Verbindungsorganisator 270 überträgt eine Rundsendenachricht, die wie alle anderen Nachrichten zwischen Objekten durch das Laufzeitsystem abgewickelt wird. Die Rundsendenachricht enthält eine Bereichskennzahl, da es sich um eine Fernverbindung handelt. Zum Beispiel kann die Nummer 1-518-555-3000 sein, was als ein Alias-Name für die Rundsendenachricht verwendet wird. Dementsprechend erkennt das den Betreiber-Agenten 271 und 272 zugeordnete Laufzeitsystem den 1-518-Teil als die Alias-Namen für die Betreiber-Agentenobjekte 271 und 272 und überträgt diese Nachrichten zu diesen Objekten. Wie bereits erwähnt, können diese Objekte über eine Anzahl von Verbindungsbearbeitungsprozessoren 101 verteilt sein.
Dies hat aber weder auf die Struktur oder die Funktionsweise des Verbindungsorganisators 270 noch auf die Form oder den Inhalt der Nachricht einen Einfluß. Fachleute werden einsehen, daß gemäß einer Anwendungssoftwarestruktur dem System eine Anzahl von Weitverkehrsnetzbetreibern hinzugefügt oder aus diesem entfernt werden kann, ohne dabei das Verhalten der anderen Objekte wie zum Beispiel des Verbindungsorganisators oder seiner Client-Objekte wie zum Beispiel der Struktursteuerung 283, des Portobjekts 282, des Anschlußobjekts 281 oder des Teilnehmerobjekts (FIG. 7) auf irgendeine Weise zu beeinflussen. Um ein neues Betreiber-Agentenobjekt zu dem System hinzuzufügen, müssen neben dem Laden der Software des Betreiberobjekts und seiner verwandten Software, wie zum Beispiel Steuerungen für Einrichtungen und Verbindungsleitungsobjekte, die mit dem Prozessor des Vermittlungsmoduls kommunizieren, der physikalisch Verkehrswegeinrichtungen zugeordnet ist, als einzige Änderung des Systems nur die Identität des neuen Betreiber-Agentenobjekts und seine Alias-Namen zu dem Laufzeitsystem des einen Verbindungsbearbeitungsprozessors 101 hinzugefügt werden, in dem sich das neue Betreiberobjekt befindet, und die Namen der zugeordneten Einrichtungs- und Verbindungsleitungsobjekte zu dem Laufzeitsystem des Verbindungsbearbeitungsprozessors hinzugefügt werden, auf dem sich diese bestimmten Objekte befinden.
Im Block 572 von FIG. 7 wird die Tatsache angedeutet, daß in diesem Beispiel die Betreiber- Agentenobjekte, zum Beispiel 271 und 272, die Nachricht der abgehenden Verbindung empfangen, da die gewählte Nummer die Bereichskennzahl 1-518 enthält und diese Betreiber-Agentenobjekte jeweils den Aliasnamen 1-518 aufweisen, was in FIG. 6 zu sehen ist. Natürlich kann es mehrere Betreiber-Agentenobjekte mit demselben Alias geben. Die durch die Betreiber-Agentenobjekte 271 und 272 empfangene Nachricht hat dasselbe Format wie das in Tabelle A gezeigte Format und enthält den Namen des Sender- Verbindungsorganisators. Die Betreiber- Agentenobjekte reagieren, indem sie eine Angebotsnachricht zu dem Verbindungsorganisator 270 übertragen, die anzeigt, daß bei ihnen Einrichtungen für die Bearbeitung der abgehenden Verbindung verfügbar sind.
Wenn bei einem oder mehreren der Betreiber alle Einrichtungen besetzt sind, dann reagiert dieser nicht mit einer Nachricht. Betreiber-Agentenobjekte, die bereit sind, die Verbindung zu bearbeiten, übertragen Angebotsnachrichten zu dem Verbindungsorganisator, und der Verbindungsorganisator 270 überträgt Namen der Anbieter-Betreiberagenten zu dem Ursprungs-Teilnehmerobjekt 280. Wenn von keinem der Betreiber- Agentenobjekte eine Angebotsnachricht empfangen wird, dann überschreitet der Verbindungsorganisator 270 eine Zeitgrenze und sendet eine dies mitteilende Nachricht zu dem Teilnehmerobjekt 280. Neben dem Überschreiten einer Zeitgrenze können andere Wahlmöglichkeiten, wie zum Beispiel ein Versuch, die Verbindung auf einem privaten Netz herzustellen, bereitgestellt werden. Das Teilnehmerobjekt enthält Verbindungsbearbeitungs Optionen, die durch den Teilnehmer definiert werden, und leitet den Verbindungsorganisator dementsprechend an. Wenn der Verbindungsorganisator wie in den Blöcken 574 angedeutet eine erste Angebotsnachricht von einem Betreiberagenten empfängt, dann überträgt er den Namen des Anbieter-Agenten zu dem Teilnehmerobjekt 280, was im Block 576 von FIG. 8 angedeutet wird. So, wie der Verbindungsorganisator 270 Weitere Angebote empfängt, werden diese zu dem Teilnehmerobjekt 280 übertragen, was durch die Schleife bei 575 in FIG. 8 angedeutet wird. Die Informationen, die der Teilnehmer dem Teilnehmerobjekt bereitstellt, können ferner Informationen enthalten, die die Länge der Zeitdauer definieren, die der Teilnehmer auf Angebote von Betreiberagenten warten möchte, bevor er einen Agenten für die gegebene Verbindung auswählt. Zum Beispiel kann der Teilnehmer definieren, daß alle Verbindungen mittels eines ersten Betreiberagenten erfolgen sollen, sofern ein solcher Betreiberagent innerhalb einer vorbestimmten Zeitdauer verfügbar ist, und daß danach eine Verbindung zu einem zweiten Betreiberagenten gehen soll, falls dieser verfügbar ist, oder, wenn dies nicht der Fall ist, dann zu einem beliebigen verfügbaren Betreiber gehen soll. In der Technik sind verschiedene Auswahlalgorithmen zu Auswahl zum Beispiel von Firmennetzen oder kommerziellen Netzen für abgehende Verbindungen bekannt. Im Block 578 von FIG. 8 wird die Aktion des Teilnehmerobjekts bei der Auswahl eines Betreibers und der Übertragung der Identität des ausgewählten Betreibers zu dem Verbindungsorganisator angedeutet. Der Verbindungsorganisator überträgt die Betreiber-Identität zu der Struktursteuerung 283 und überträgt eine Nachricht zu dem ausgewählten Betreiberobjekt, die die Annahme anzeigt. In diesem Beispiel ist der Ursprungs-Teilnehmeranschluß mit dem Vermittlungsmodul 130 verbunden, was auch auf die Verbindungsleitungen des gewählten Betreiberagenten zutrifft, der in diesem Beispiel der durch das Betreiber-Agentenobjekt 271 dargestellte Betreiberagent 1 ist. Nach dem Empfang der Annahmenachricht überträgt das Betreiber-Agentenobjekt 271 die Informationen der angerufenen Nummer zu der Einrichtungssteuerung, die der für diese Verbindung zu verwendenden verfügbaren Verbindungsleitung zugeordnet ist. Das Betreiber- Agentenobjekt 271 besitzt eine Anzahl zugeordneter physikalischer Verbindungsleitungseinrichtungen, und für jede Verbindungsleitungseinrichtung existiert ein Verbindungsleitungsobjekt, das der physikalischen Verbindungsleitung auf eine Weise fest zugeordnet ist, die der Beziehung zwischen Portobjekten und physikalischen Anschlüssen entspricht. Dem Betreiber- Agentenobjekt sind die Betreiber-Einrichtungsobjekte 291, 294 zugeordnet. Jedem Betreiber-Einrichtungsobjekt kann mehr als eine Verbindungsleitung zugeordnet sein. Zur Herstellung einer Verbindung sendet das Betreiber- Agentenobjekt 271 die relevanten Informationen zu dem Einrichtungs-Steuerungsobjekt 290, was im Block 582 von FIG. 8 angedeutet wird. Die Einrichtungssteuerung wählt eine verfügbare Verbindungsleitung und überträgt die Identität der Verbindungsleitung zu dem Struktursteuerungsobjekt 283. Das Struktursteuerungsobjekt erzeugt die notwendigen Informationen zur Herstellung einer Verbindung zwischen dem identifizierten der Teilnehmeranschlüsse 110 und der identifizierten der Verbindungsleitungen 112 durch das Koppelnetz 132 hindurch. In diesem Beispiel ist nur eine Struktursteuerung beteiligt, da sowohl der Ursprungsanschluß als auch die abgehende Verbindungsleitung mit demselben Koppelnetz verbunden sind. Wenn dies nicht der Fall ist, dann muß über das Brückennetz 115 eine Verbindung zwischen den Koppelnetzen hergestellt werden, wobei wie bereits mit Bezug auf FIG. 3 bis 5 beschrieben ein Brückensteuerungsobjekt beteiligt ist.
FIG. 9 ist eine Diagrammdarstellung des Laufzeitsystems für die Prozessoren 101. In jedem der Prozessoren wird separate Laufzeitsystemsoftware bereitgestellt. In jedem Prozessor stellt das Laufzeitsystem den Mechanismus für die Kommunikation zwischen Objekten bereit. Das Laufzeitsystem 300 umfaßt ein Betriebssystem 301, bei dem es sich um das im Handel erhältliche LISP-Betriebssystem mit dem Namen GENERA handeln kann, das von der Firma Symbolics, Inc. vertrieben wird. Es existieren verschiedene Versionen von LISP. Bei einem Prototypsystem wird eine LISP- Version verwendet, die "flavors" genannt wird. Diese Version wird in Flavors, Reference Guide to Symbolics- Lisp, Symbolics, Inc., 1985, beschrieben. Das Betriebssystem 301 kann als die Basisschicht 301 des Laufzeitsystems 300 bildend angesehen werden. Der Laufzeitlinker 302 ist eine Schnittstellenschicht für die Basisschicht. Der Laufzeitlinker ist ein einzigartiges Merkmal des vorliegenden Systems und stellt den Mechanismus für die Kommunikation zwischen Objekten bereit, ohne daß das Senderobjekt dabei Positionen oder Adressen der Empfängerobjekte kennen muß. Durch diesen Linker wird eine lose verkoppelte hochmodulare Softwarestruktur möglich, bei der dem System neue Objekte hinzugefügt oder aus diesem entfernt werden können, ohne daß dabei andere in dem System bestehende Objekte gestört werden. In dieser Anordnung werden Objekten symbolische Namen gegeben, die allen anderen Objekten des Systems bekannt sind, und die Kommunikation zwischen Objekten erfolgt mittels Nachrichten, die symbolische Namen enthalten, die durch den Laufzeitlinker aufgelöst werden. Der Laufzeitlinker enthält eine Linkertabelle (FIG. 18), die einen Eintrag aufweist, der einen Datenadreßzeiger für alle Objekte auf dem Prozessor enthält, in dem der Linker abläuft. Der Laufzeitlinker verwendet den Datenzeiger in der "flavors"-Version von LISP, um einen Funktionsaufruf zu dem durch den symbolischen Namen identifizierten Objekt durchzuführen. Eine Nachricht zwischen Objekten enthält eine Verfahrensbezeichnung (siehe Tabelle A für beispielhafte Nachrichten), die eine generische Funktion von LISP darstellt. Der Laufzeitlinker verwendet die standardmäßige LISP-Funktion apply, um die in der Nachricht zwischen Objekten (siehe Tabelle A für beispielhafte Nachrichten) definierte generische LISP-Funktion aufzurufen, und leitet den Datenzeiger aus der Linkertabelle zusammen mit der Argumentenliste der Nachricht an die generische Funktion weiter. Die generische Funktion adressiert die Daten des aufgerufenen Objekts an dem Datenzeiger, und die Funktion wird in LISP ausgeführt, wobei durch die Objektdaten definierte Parameter verwendet werden. Ein Eintrag der Linkertabelle (FIG. 18) definiert entweder einen weiteren Objektnamen oder einen Datenzeiger. Wenn der Eintrag ein Objektname ist, dann schlägt der Laufzeitlinker diesen Objektnamen iterativ nach, bis er einen Datenzeiger findet.
FIG. 9 zeigt außerdem Bibliotheksfunktionen 303, die durch das Laufzeitsystem aufgerufen werden. Die Verwendung von Bibliotheksfunktionen zur Durchführung spezifischer Operationen ist bekannt. In diesem illustrativen System umfassen die Bibliotheksfunktionen eine als POST-Funktion bezeichnete Funktion, die bei der Kommunikation zwischen Objekten des Anwendungsprogramms verwendet wird, was später mit Bezug auf FIG. 11 beschrieben wird. Das Laufzeitsystem enthält ein Schedulerobjekt 310, das Computer- Maschinenzeit an diejenigen Objekte des Laufzeitsystems und des Anwendungsprogramms vergibt, die in der Linkertabelle (FIG. 18) registriert sind. Der Scheduler kann ein einziges Objekt sein, wird aber durch eine Anzahl verschiedener Objektnamen repräsentiert, um die Kommunikation zu vereinfachen. Er enthält das RUN- Objekt 311, das Interruptfunktionen, die durch INT 312 dargestellt werden, Zeitsteuerungsfunktionen, die durch CLK 314 dargestellt werden, Dispatchfunktionen, die durch DISP 315 dargestellt werden, und Füllfunktionen, die durch FILL 316 dargestellt werden, verarbeitet. Diese Funktionen werden durch das Schedulerobjekt gemäß einem vordefinierten Prioritätsalgorithmus verarbeitet, der nachfolgend mit Bezug auf FIG. 10 beschrieben wird. Während Interruptnachrichten durch einen der Verbindungsbearbeitungsprozessoren 101 empfangen werden (zum Beispiel aus einem Eingabeterminal), werden diese in eine Interrupt-Warteschlange eingereiht und letztendlich durch den Scheduler 310 für diesen Prozessor bearbeitet. Ähnlich werden Timeout- Anforderungen in eine Taktwarteschlange eingereiht und Dispatch-Anforderungen, die zum Beispiel in Verbindung mit der Übertragung von Nachrichten zwischen Objekten empfangen werden, zur Verarbeitung durch den Scheduler in eine Dispatch-Warteschlange eingereiht. Eine Füll-Warteschlange registriert durchzuführende Low- Level-Tasks wie zum Beispiel Wartungstasks.
FIG. 10 ist eine Flußdiagrammdarstellung der Ausführung des RUN-Verfahrens 311 des Schedulerobjekts 310. Wenn das RUN-Verfahren wie im Block 401 abgebildet startet, dann besteht seine erste Aufgabe darin festzustellen, ob sich auf der Interrupt-Warteschlange (FIG. 13) Interrupt-Arbeit befindet, was im Entscheidungsblock 403 angedeutet wird. Wenn ja, dann wird das als nächstes aufgelistete Interrupttask wie im Block 404 angedeutet verarbeitet, und es wird zum Block 403 zurückgesprungen, um nach weiterer Interruptarbeit zu suchen. Der Einfachheit halber werden keine verschiedenen Ebenen der Interruptpriorität berücksichtigt, die aber ohne weiteres implementiert werden könnten, indem zum Beispiel eine Warteschlange für jede Ebene hinzugefügt wird und Tasks aus der Warteschlange der höchsten Ebene zuerst ausgeführt werden. Jedes Objekt auf einem Prozessor 101, das Interruptsignale empfängt, ist in dem Scheduler 310 dieses Prozessors registriert, indem eindeutige Schlitze in der Interrupt-Warteschlange zugewiesen werden, die identifizierten Interruptquellen entsprechen. Diese Informationen werden verwendet, um Interruptsignale zu den Objekten zu leiten. Wenn eine Interruptnachricht für ein spezifisches Objekt empfangen wird, dann wird sie in den Schlitz in der Interrupt-Warteschlange eingereiht, für den das Empfängerobjekt registriert wurde. Die Verarbeitung eines Interrupttasks im Block 404 enthält eine Übertragung zu dem Interruptverfahren des registrierten Objekts für weitere Aktionen.
Wenn die Prüfung im Block 403 anzeigt, daß keine weitere Interruptarbeit zu erledigen ist, dann wird mit dem Entscheidungsblock 405 fortgefahren, in dem geprüft wird, ob irgendwelche Zeitschaltungen abgelaufen sind. Jeder Prozeß, der bei Ablauf einer spezifischen Zeitdauer gerufen werden will, überträgt eine Nachricht zu dem CLK-Objekt 314, die eine angeforderte Zeitdauer definiert. Der Scheduler reiht den Objektnamen, der von der Nachricht abgeleitet wurde, und einen Zeitwert, der zum Beispiel durch Addieren der gewünschten Zeitdauer zu der aktuellen Taktzeit abgeleitet wird, in der Reihenfolge ihrer Timeout-Zeitwerte in die Takt-Warteschlange (FIG. 14) ein. Wenn die Prüfung im Block 405 durchgeführt wird, werden die Zeitwerteinträge in der Takt-Warteschlange mit der zu diesem Zeitpunkt aktuellen Zeit verglichen, um festzustellen, ob die gewünschte Zeitdauer abgelaufen ist. Wenn eine der Zeitschaltungen ihre Zeitgrenze überschritten hat, dann wird dies wie im Block 406 angedeutet durch Senden einer Nachricht über den Laufzeitlinker zu dem Timeout-Verfahren des anfordernden Objekts verarbeitet. Als Reaktion kann das anfordernde Objekt über POST eine Nachricht an sich selbst senden, was bewirkt, daß die Nachricht in die Dispatch-Warteschlange 315 in FIG. 9 eingereiht wird. Durch diese Prozedur wird es möglich, die Timeout- Nachricht durch das anfordernde Objekt der Reihe nach zu bearbeiten, nachdem andere Nachrichten für dieses Objekt, die sich bereits in der Dispatch-Warteschlange befunden haben können, bearbeitet wurden. Als Alternative kann das Objekt unmittelbar auf den Timeout-Aufruf reagieren. Bei Abschluß eines Timeout- Tasks im Block 406 von FIG. 10 erfolgt ein Rücksprung zum Entscheidungsblock 403, um festzustellen, ob noch weitere Interruptarbeit erledigt werden muß. Wenn nicht, dann wird im Block 405 eine weitere Prüfung durchgeführt, um festzustellen, ob noch weitere Zeitschaltearbeit erledigt werden muß. Wenn keine weitere Zeitschaltearbeit erledigt werden muß, dann wird mit dem Entscheidungsblock 407 fortgefahren, in dem geprüft wird, ob sich in der Dispatch-Warteschlange Arbeit befindet. Die Dispatch-Warteschlange ist eine Liste von Objektnamen, die als Folge einer Nachricht aus einem Objekt an den Scheduler 310 oder als Folge einer Nachricht zwischen Objekten dort plaziert worden sein können. Die Informationen, die in diese Warteschlange eingereiht werden, enthalten wie in FIG. 15 gezeigt Nachrichteninformationen die Namen des Ursprungs- und des Zielobjekts. Bei der Verarbeitung eines Dispatch-Tasks wird wie im Block 408 von FIG. 10 angedeutet eine Übertragung über den Laufzeitlinker 302 zu dem identifizierten Objekt durchgeführt, und die Nachrichtendaten werden als eine Argumentenliste weitergeleitet. Bei Abschluß eines Dispatch-Tasks erfolgt wiederum ein Rücksprung zum Entscheidungsblock 403, und die oben mit Bezug auf die Blöcke 403, 405 und 407 angeführten Schritte werden wiederholt. Wenn keine weiter Dispatcharbeit erledigt werden muß, dann wird ein Fülltask ausgeführt und wiederum geprüft, ob weitere Interrupt-Zeitschalterarbeit oder Dispatcharbeit vorliegt, bevor das nächste Fülltask ausgeführt wird.
FIG. 11 ist eine Flußdiagrammdarstellung der Übertragung eines auch als Nachricht bezeichneten ausführbaren Ausdrucks zwischen Objekten, so wie es zum Beispiel mit Bezug auf FIG. 2 beschrieben wurde. Die Objekte der Anwendungssoftware kommunizieren direkt nur mit dem Laufzeitsystem des Prozessors, auf dem sie resident sind, und keines der Objekte der Anwendungssoftware kennt die Adresse oder die Position anderer Objekte. Andere Objekte werden nur durch ihre symbolischen Namen adressiert. Die Nachrichtenübertragungssequenz beginnt mit einem Aufruf der Funktion POST, die eine Funktion in der in FIG. 9 gezeigten Bibliothek 303 ist. Die Nachricht enthält den Namen des Zielobjekts und eine Bezeichnung des Verfahrens des Zielobjekts sowie ein zu übertragendes Argument (z.B. Daten), was im Block 601 von FIG. 11 angedeutet wird. POST fügt der Nachricht den Namen des Ursprungsobjekts hinzu, was im Block 603 angedeutet wird. Beispielhafte Nachrichten sind in Tabelle A gezeigt. Im Block 612 wird geprüft, ob der Name ein lokaler Alias-Name ist, indem die Alias-Tabelle von FIG. 17 überprüft wird. Diese Tabelle enthält alle durch Objekte des lokalen Prozessors registrierten Alias-Namen. Es können sich mehrere Objekte für denselben Alias-Namen registrieren. Wenn der geprüfte Name nicht in der Alias-Tabelle aufgelistet ist, dann ruft die POST-Funktion den Laufzeitlinker 302, und es wird im Block 605 geprüft, ob der Name des Zielobjekts in der Linkertabelle (FIG. 18) vorhanden ist. Wenn ein Objektname gefunden wird, was anzeigt, daß das Objekt auf dem lokalen Prozessor resident ist, dann wird die Nachricht in den Dispatcher 315 des lokalen Laufzeitsystems 300 von FIG. 9 geschrieben, was im Block 607 gezeigt wird, und auf der Dispatch- Warteschlange (FIG. 15) eingereiht. Der Scheduler 310 ruft bei der Ausführung der mit Bezug auf FIG. 10 beschriebenen Sequenzen über den Laufzeitlinker 302 das Zielobjekt auf. Dieser Aufruf kann durchaus durch Aufruf der POST-Funktion, wie mit Bezug auf Block 601 besprochen, zu der Übertragung einer weiteren Nachricht aus dem ausführenden Objekt führen.
Wenn die Prüfung im Block 605 anzeigt, daß der Name nicht in der Linkertabelle vorhanden ist, dann wird das NET-Objekt 322 aufgerufen. Das NET-Objekt stellt eine Schnittstelle mit dem Bus 103 bereit, um sowohl Daten aus dem Bus zu empfangen als auch Daten auf dem Bus zu anderen Prozessoren zu übertragen. Wenn das NET-Objekt die Nachricht von POST empfängt, dann führt es eine Suche in seiner Zieltabelle durch, was im Block 615 angedeutet wird. Ein Eintrag für diese Tabelle, die fortlaufend durch das NET-Objekt erzeugt wird, ist in FIG. 16 gezeigt. Jedesmal, wenn das NET- Objekt eine Nachricht von einem Objekt auf einem anderen der Prozessoren in dem System empfängt, verzeichnet es den Namen dieses Objekts zusammen mit der Identität des Quellenprozessors. Bei der im Block 615 durchgeführten Suche kann das NET-Objekt aus dieser Tabelle feststellen, daß der Prozessor, auf dem das Zielobjekt resident ist, bekannt ist. Diese Prüfung wird im Block 617 angedeutet. Wenn er bekannt ist, dann überträgt das NET-Objekt die Nachricht zu dem Zielprozessor und verwendet dabei seine bekannte Identifikation, was im Block 621 angedeutet wird. Falls der Objektname bei der Prüfung im Block 617 nicht in der Zieltabelle gefunden wird, was anzeigt, daß der Prozessor, auf dem das Zielobjekt resident ist, dem NET-Objekt am Senderprozessor nicht bekannt ist, dann wird mit dem Block 619 fortgefahren, und der Objektname wird auf dem Bus 103 zusammen mit der Nachricht rundgesendet. Wenn die Prüfung im Block 612 anzeigt, daß der Name ein lokaler Alias-Name ist, dann wird der entsprechende Objektname bzw. werden die entsprechenden Objektnamen wie im Block 613 angedeutet von der Alias- Tabelle abgerufen, und die Nachricht wird für jedes der in dem Eintrag der Alias-Tabelle identifizierten Objekte in das lokale Dispatch-Objekt 315 geschrieben, was im Block 614 angedeutet wird. Danach wird die Nachricht des Alias-Namens zu allen anderen Prozessoren rundgesendet, was im Block 619 angedeutet wird.
In jedem der Prozessoren 101 überprüft das bei 322 in FIG. 9 gezeigte NET-Objekt alle ankommenden Nachrichten (einschließlich Rundsendenachrichten). FIG.
12 zeigt mehrere Prüfungen, die an ankommenden Nachrichten vorgenommen werden. Die erste Prüfung, die in FIG. 12, Block 650, angedeutet wird, ist eine Prüfung, ob registrierte Muster vorliegen, nach denen das NET-Objekt suchen muß. Die Alias-Tabelle von FIG. 17 registriert alle Muster für den lokalen Prozessor.
Ein Muster ist in diesem System als eine Zeichenkette definiert, die einen Teil einer Anzahl verschiedener Namen darstellt. Von jedem Objekt, das eine Musterübereinstimmung anfordert, wird das Muster in der Alias-Tabelle registriert. Es kann ein beliebiges Muster für mehrere Objekte registriert werden. Wenn zum Beispiel das registrierte Muster 555 ist, dann würden alle für dieses Muster registrierten Objekte eine Nachricht empfangen, die zum Beispiel unter dem Alias- Namen 555-3000 rundgesendet wird, und auch alle anderen Nachrichten, die das Muster 555 enthalten. Wenn im Block 650 von FIG. 12 festgestellt wird, daß diese Maschine keine Registermuster aufweist, dann wird geprüft, ob die Nachricht eine Mischsumme enthält, was im Block 652 angedeutet wird. Die Mischsumme des Namens des Zielobjekts wird von dem übertragenden Prozessor gemäß einem standardmäßigen und bekannten Mischsummen- Algorithmus erzeugt. Das NET-Objekt führt eine (in der Zeichnung nicht gezeigte) Tabelle, die die Mischsumme für alle Namen und Alias-Narren der lokalen Linkertabelle enthält. Die Mischsumme wird separat in einem Feld der Nachricht mit eingeschlossen und kann leichter auf eine Übereinstimmung geprüft werden als eine beliebige Zeichenkette. Wenn eine solche Mischsumme vorliegt, dann wird im Block 654 eine weitere Prüfung durchgeführt, um festzustellen, ob dies eine gültige Mischsumme für diesen Prozessor ist. Wenn nicht, dann kann sie ignoriert werden, was im Block 662 von FIG. 12 angedeutet wird. Wenn die Prüfung im Block 650 anzeigt, daß registrierte Muster auf dem lokalen Prozessor vorliegen, dann wird die Mischsummenprüfung übersprungen, und es wird eine weitere Prüfung durchgeführt, um festzustellen, ob der Name der Nachricht in der Alias-Tabelle von FIG. 17 vorliegt. Wenn der Name ein Alias-Name oder -Muster ist, der bzw. das in der Alias-Tabelle verzeichnet ist, dann werden die entsprechenden Objektnamen aus der Tabelle abgerufen, was im Block 658 angedeutet wird. Danach wird die Nachricht in das Dispatch-Objekt 315 (FIG. 9) geschrieben. Die Nachricht wird dann von dem Laufzeitsystem an jedes der identifizierten Objekte übermittelt. Eine durch das NET-Objekt durchgeführte Funktion besteht darin, die Zieltabelle zu aktualisieren, was im Block 664 angedeutet wird. Die Zieltabelle ist in FIG. 16 gezeigt und wurde bereits zitiert. Die Tabelle dient dazu, die Identität des Prozessors zu verfolgen, auf dem ein Senderobjekt resident ist. Wie bereits erwähnt, wird diese Tabelle bei der Übertragung von Nachrichten zu einem Zielobjekt verwendet. Wenn der Name des Zielobjekts in der Zieltabelle vorliegt, dann kann die Nachricht direkt an den entsprechenden Prozessor adressiert werden. Wenn der Name nicht in der Tabelle vorliegt, dann wird die Nachricht rundgesendet, was ein zeitaufwendigerer Vorgang ist. Wenn der Name ein Alias-Name oder ein Muster ist, dann wird der Name des Senderobjekts aus der empfangenen Nachricht abgeleitet und wird mit der Identität des Quellenprozessors in die Zieltabelle eingetragen.
Falls die Prüfung im Block 652 anzeigt, daß die Nachricht keine Mischsumme enthält, dann wird zum Block 656 fortgefahren, um festzustellen, ob es sich wie oben beschrieben um einen lokalen oder Muster-Namen handelt. Wenn die Prüfung im Block 652 anzeigt, daß die Nachricht doch eine Mischsumme enthält, dann wird im Block 654 eine weitere Prüfung durchgeführt, um festzustellen, ob dies eine gültige Mischsumme für den lokalen Prozessor ist. Wenn nicht, dann wird sie ignoriert, da sie sich auf einen Namen bezieht, der für diese konkrete Maschine nicht registriert ist. Wenn sie eine gültige Mischsumme ist, dann wird wiederum mit Block 656 fortgefahren, da der Name auch ein Alias- oder Mustername sein kann. Wenn der Zielobjektname kein Alias oder Muster ist, dann wird eine weitere Prüfung durchgeführt, um festzustellen, ob dieser Name bei dem Laufzeitlinker registriert und in der in FIG. 18 gezeigten Linkertabelle enthalten ist. Wenn sie sich nicht in dem Laufzeitlinker befindet, dann wird die Nachricht wiederum ignoriert, was bei 662 angedeutet wird. Wenn der Objektname jedoch in der Linkertabelle vorliegt, dann wird die Nachricht in die Dispatch- Komponente 315 (FIG. 9) geschrieben, was im Block 665 angedeutet wird. Weiterhin wird die Zieltabelle mit dem Namen des Senderobjekts und dem aus der empfangenen Nachricht abgeleiteten Namen des Quellenprozessors aktualisiert, was im Block 664 angedeutet wird.
Zur Verbesserung der Zuverlässigkeit des gesamten Systems wird ein Reservesystem bereitgestellt. Einer der Prozessoren des Systems von FIG. 1 kann als ein Reserveprozessor ausgewählt und mit einem Reservedateisystem ausgestattet werden, oder es kann ein separater Prozessor hinzugefügt werden. Darüber hinaus können der Reserveprozessor und das Dateisystem dupliziert werden, um eine größere Systemzuverlässigkeit sicherzustellen. Die Reservekonfiguration ist in FIG. 19 als ein Zusatz für das System von FIG. 1 abgebildet. Sie enthält die duplizierten Reserveprozessoren 700 und 701, die jeweils ihre eigenen Dateisysteme 710 bzw. 711 besitzen und mit einer Konsole 715 verbunden sind. Jeder der Reserveprozessoren besitzt ein Reserve-Organisationsobjekt 350 und ein Konsolenobjekt 354 (FIG. 9). Das Reservesystem führt eine nichtflüchtige Kopie aller Reserveabbilder, die ihm von anderen Objekten des Systems übertragen werden. Diese Abbilder werden in dem Dateisystem 710, 711 unter dem Namen des Client- Objekts, von dem aus die Informationen empfangen werden, katalogisiert. Die Abbilder können auf Anfrage an den Reserveorganisator unter Angabe der spezifischen Client-Objekte abgerufen werden. Reserveabbilder werden für jedes der statischen Objekte der Vermittlungsstelle erzeugt, die die grundlegende Konfiguration der Vermittlung definieren. Reserveabbilder für dynamische Objekte, die nur für die Dauer einer Verbindung oder dergleichen existieren, sind nicht unbedingt erforderlich. Falls ein Prozessor ausfällt, befindet sich die einzige überdauernde Darstellung der Prozessorobjekte, die auf dem ausgefallenen Prozessor resident sind, in den Reservedateisystemen 710, 711. Eine Gruppe von Objekten, die auf dem ausgefallenen Prozessor resident sind, kann auf demselben Host oder auf einem anderen, physikalisch kompatiblen Host wiederhergestellt werden. Jeder der Prozessoren 101 (FIG. 1) in dem System ist in der Lage, zu einem als dem Initialisierungsagenten bekannten Objekt heraufgebootet zu werden. Um das Softwaresystem eines ausgefallenen Prozessors auf demselben oder auf einem anderen Prozessor wiederherzustellen, wird der betreffende Prozessor gebootet, um den Initialisierungsagenten zu aktivieren. Von der Wartungskonsole 515 (FIG. 19) aus wird über das Konsolenobjekt 354 (FIG. 9) eine Nachricht zu dem Initialisierungsagentenobjekt des betreffenden Prozessors gesendet, was bewirkt, daß das Initialisierungsagentenobjekt die Rolle des Prozessor- Agentenobjekts 327 (FIG. 9) der ausgefallenen Objektgruppe übernimmt. Typischerweise besitzt jeder der Prozessoren 101 eine Gruppe von Objekten und ein Prozessor-Agentenobjekt 327, das Reserveabbilder zu dem Reservesystem überträgt und Reserveinformationen aus dem Reservesystem wiederherstellt. Als Reaktion auf die Nachricht aus einer Wartungskonsole 515, die den Prozessor-Agenten für die wiederherzustellende Gruppe von Objekten definiert, fordert der betreffende Prozessor-Agent seine eigenen Reserveabbildobjekte von dem Reserveorganisator 723 in den Reserveprozessoren 500, 501 an. Das Reserveabbild enthält die Namen der Klassen und die Namen aller Objekte, die sich zum Zeitpunkt des Ausfalls in der Gruppe befanden. Der Prozessor-Agent 327 fährt mittels Nachrichten zu dem Reserve-Organisationsobjekt 350 mit dem Herunterladen der erforderlichen Klassendefinitionen aus dem Reserve- Datenbanksystem 510, 511 und mit der Wiederherstellung der genannten Objekte in der Reihenfolge, in der sie in dem Reserveabbild identifiziert werden, die mit der Reihenfolge, in der sie ursprünglich erzeugt wurden, übereinstimmt, fort. Der Prozessor-Agent sendet dann der Reihe nach jeder Komponente eine Nachricht, die bewirkt, daß diese durch Nachrichten zu dem Reserveorganisator 350 ihr eigenes Reserveabbild wiederherstellt. Auf diese Weise wird die Objektgruppe in demselben oder in einem anderen Prozessor gänzlich wiederhergestellt.
Durch Herzschlagsignale, die von jedem der Prozessoren übertragen und von allen anderen Prozessoren des Systems überwacht werden, ist es möglich festzustellen, daß ein bestimmter Prozessor ausgefallen ist. Der Hostprozessor, der diesen Zustand eines anderen Prozessors erkennt, kann die Rolle des ausgefallenen Prozessors übernehmen, indem er automatisch seinen Prozessor-Agenten in den Prozessor- Agenten des ausgefallenen Prozessors umwandelt, und die ausgefallene Komponentengruppe wiederherstellen. Durch diese Prozedur wird es möglich, Ersatz-Hosts, die keine wesentlichen Aufgaben ausführen, als Reaktion auf einen Prozessorausfall automatisch in Arbeits-Hosts zu konvertieren.
In einem großen Echtzeitsystem, wie zum Beispiel in einem Telekommunikationsvermittlungssystem, werden die Änderungen der Parameter der Vermittlungsstelle, die sich zum Beispiel aus den Änderungen der Dienste für Teilnehmer ergeben, vorübergehend in einen besonders gekennzeichneten Bereich eingeführt, der als der Bereich für neuere Änderungen bezeichnet wird. In dem vorliegenden System gibt es keinen zentralen Datenbereich, und alle Konfigurationsinformationen der Vermittlung und dergleichen werden in der Struktur der einzelnen Objekte mit eingeschlossen. Änderungsnachrichten können direkt über die Konsole 515 und den Konsolenorganisator 725 und den dem zu modifizierenden Objekt zugeordneten Prozessor-Agenten 721 in das entsprechende Objekt eingegeben werden. Nachrichten zu den verschiedenen Prozessor-Agenten können Nachrichten enthalten, die bewirken, daß neue Objekte in der Objektgruppe des Prozessor-Agenten erzeugt, zwischen Objektgruppen bewegt oder aus dem System entfernt werden. Nachrichten können zu einzelnen Objekten gesendet werden, um ihre lokale Konfiguration zu ändern oder um statische Verbindungen mit anderen Komponenten zu entfernen. Als Folge von Nachrichten zu den Prozessor-Agenten vorgenomme Änderungen werden von den Prozessor-Agenten in dem Reservesystem aufgezeichnet, und als Reaktion auf Nachrichten zu den einzelnen Objekten vorgenomme Änderungen werden von den Objekten selbst abgesichert.
Es ist zu verstehen, daß die oben beschriebene Anordnung nur beispielhaft für die Erfindung ist. Fachleute können zahlreiche andere Anordnungen ausarbeiten. TABELLE A NACHRICHTEN

Claims

1. Verteiltes Telekommunikationsvermittlungssystem mit einer Mehrzahl von Prozessoren (101), die durch einen Bus (103) miteinander verbunden sind, wobei jeder Prozessor mit einem Laufzeitsystem (300) und mit einer objektorientierten Anwendungssoftware zur Ausführung von Telekommunikationsfunktionen ausgestattet ist, wodurch jedes Objekt einen eindeutigen symbolischen Namen, eine Menge von Operationen, die Verfahren genannt werden, und einen Zustand, der Instanzdaten genannt wird, besitzt und mit einem anderen Objekt durch Nachrichten kommuniziert, wobei die besagten Nachrichten jeweils einen symbolischen Namen eines Ursprungsobjekts und eines Zielobjekts, eine Verfahrensbezeichnung für das Verfahren des Zielobjekts und eine Argumentenliste umfassen, bei der es sich um Daten handelt, die von dem bezeichneten Verfahren erwartet werden, wobei jedes Objekt der besagten Mehrzahl von Objekten einen Teil der Systemoperationen steuert und jedes Laufzeitsystem (300) ein Betriebssystem und einen Linker (302) umfaßt, wobei der besagte Linker eine Linkertabelle mit Einträgen für alle Objekte auf dem Prozessor (101) enthält, in dem der Linker abläuft,

wobei der besagte Linker (302) auf die besagten Nachrichten reagiert, um durch Konsultieren der Linkertabelle eine oder mehrere Zieladressen für die besagte Nachricht zu bestimmen, wobei die besagte Linkertabelle eine Mehrzahl von symbolischen Namen und eine entsprechende Mehrzahl von Zieladreßzeigern aufweist, wobei mindestens ein Zieladreßzeiger für jeden symbolischen Namen vorliegt, und wodurch der Linker den Adreßzeiger verwendet, um einen Funktionsaufruf zu dem durch den symbolischen Namen identifizierten Objekt durchzuführen, und wodurch das Verfahren in dem besagten, durch die Verfahrensbezeichnung identifizierten Objekt aufgerufen wird, und wobei jedes Objekt der besagten Mehrzahl von Objekten ein Mittel umfaßt, um sich selbst zu der besagten Linkertabelle hinzuzufügen, indem es seinen einen oder seine mehreren symbolischen Namen und seinen Adreßzeiger zu der besagten Linkertabelle hinzufügt, und jedes Objekt der besagten Mehrzahl von Objekten ein Mittel umfaßt, um sich selbst von der besagten Linkertabelle zu entfernen, indem es seinen einen oder seine mehreren symbolischen Namen und seinen Adreßzeiger aus der besagten Linkertabelle entfernt, wobei aber die Kommunikation zwischen Objekten nicht durch ein solches Hinzufügen und Entfernen gestört wird und der Linker die besagte Kommunikation abschließen kann, indem er bewirkt, daß die besagte eine bzw. die besagten mehreren vordefinierten Systemoperationen an der besagten Argumentenliste der besagten Nachricht vorgenommen werden.

2. System nach Anspruch 1, wobei der besagte Linker ein Mittel zum Vergleichen des besagten symbolischen Namens in der besagten Nachricht mit den besagten symbolischen Namen in den besagten Linkertabellen umfaßt und der besagte Linker bewirkt, daß die besagte eine bzw. die besagten mehreren vordefinierten Operationen nur dann an der Argumentenliste der besagten Nachricht vorgenommen werden, wenn der besagte symbolische Name in der besagten Nachricht in der besagten Linkertabelle gefunden wird.

3. System nach Anspruch 2, wobei ein Mittel bereitgestellt wird, um die besagte Nachricht zu einem anderen Prozessor der besagten Mehrzahl von Prozessoren zu übertragen, wenn der besagte symbolische Name in der besagten Nachricht nicht in der besagten Linkertabelle gefunden wird.

4. System nach Anspruch 3, wobei der besagte Linker eine Netzwerkadreßtabelle umfaßt, die eine Liste von symbolischen Namen und einen entsprechenden, für jeden symbolischen Namen identifizierten Prozessor umfaßt, und das besagte Mittel zur Übertragung der besagten Nachricht zu einem anderen Prozessor der besagten Mehrzahl von Prozessoren folgendes umfaßt:

ein Mittel zum Vergleichen des besagten symbolischen Namens in der besagten Nachricht mit Einträgen der besagten Netzwerkadreßtabelle; und

ein Mittel zur Übertragung der besagten Nachricht zu dem besagten entsprechenden identifizierten Prozessor; wenn das besagte Vergleichungsmittel den besagten symbolischen Namen in der besagten Netzwerkadreßtabelle findet, und zur Rundsendung des besagten symbolischen Namens zu der besagten Mehrzahl von Prozessoren, wenn das besagte Vergleichungsmittel den besagten symbolischen Namen nicht in der besagten Netzwerkadreßtabelle findet.

5. System nach Anspruch 4, wobei der besagte Linker eine Tabelle umfaßt, die eine Liste von lokalen Alias-Namen und ein entsprechendes lokales oder mehrere entsprechende lokale Objektmittel umfaßt, und der besagte Linker ein Mittel zur Feststellung, ob der besagte symbolische Name in der besagten Nachricht in der besagten Tabelle lokaler Alias-Namen gefunden wird, umfaßt, wobei, wenn der besagte symbolische Name in der besagten Nachricht in der besagten Tabelle lokaler Alias-Namen gefunden wird, der besagte Linker die besagte Nachricht an alle lokalen Objektmittel übermittelt, die dem besagten Alias-Namen entsprechen.

6. System nach Anspruch 5, wobei der besagte Linker ein Mittel umfaßt, um den besagten symbolischen Namen zu der besagten Mehrzahl von Prozessoren rundzusenden, wenn der besagte symbolische Name in der besagten Nachricht nicht in der besagten Tabelle lokaler Alias-Namen gefunden wird.