-
Die vorliegende Erfindung hat eine Programmstruktur für ein
Datenverarbeitungssystem, insbesondere für ein
Telekommunikationssystem, zum Gegenstand.
-
Die Telekommunikationssysteme und insbesondere die
Datenverarbeitungssysteme greifen auf die Technik von
Rechnern zurück. Die in diesen Rechnern ausgeführte
Software hat im Allgemeinen eine Struktur von
Funktionsblöcken, die auf Daten wirken, die sich außerhalb
von ihnen befinden. In dieser Hinsicht werden die Systeme
SDL von CCITT und ESTELLE von ISO genannt. Jeder
Funktionsblock erfüllt eine Funktion, kann aber auf einen
weiteren Block zurückgreifen, um einen Teil dieser Funktion
zu erfüllen, welcher, wenn er an der Reihe ist, auf einen
weiteren Block zurückgreifen kann, usw. Die Funktionsblöcke
kommunizieren durch Nachrichten miteinander.
-
Wenn die Struktur dieser bekannten Systeme den Methoden der
Funktionsanalyse voll entspricht, kann man ihr vorwerfen,
dass es zu einer Vielfalt von Typen von Funktionsblöcken
und im Zusammenhang damit zu einer großen Komplexität in
der Kommunikation zwischen Blöcken führt.
-
Es sind andererseits Techniken zur Softwarestrukturierung
durch "Objekte" bekannt, wobei jedes Objekt Daten und
Prozeduren, die sie verwenden, umgruppiert. Die
Kommunikation zwischen Objekten erfolgt dort immer noch
durch Nachrichten. Die Druckschrift EP-A-405 829 (ATT)
enthält eine Beschreibung eines Telekommunikationssystems,
bei welchem Objekte indirekt kommunizieren, indem sie einen
"Run-time"-Linker verwenden. Es wird beispielsweise der
Artikel "Les approches objets et le langage LRO2 (KEOPS)"
von C. Roche et al. zitiert, der in "Technique et Science
Informatique", Bd. 8, Nr. 1, 1989, veröffentlicht wurde. Es
wird insbesondere erläutert, wie die Objekte als Instanzen
von vorher vorhandenen Klassen, welche bereits Objekte
sind, leicht erzeugt werden. Die Klassen sind wiederum
durch Beziehungen organisiert, die die Erzeugung von neuen
Klassen ausgehend von vorhandenen Klassen gestatten. Zwei
erwähnte Beziehungen sind insbesondere die
Erbschaftsbeziehung, nach welcher eine Instanz, die "erbt",
eine Kopie der Daten und der Prozeduren der Klasse
empfängt, in die sie sich einträgt, sowie die
Hierarchiebeziehung, unter der man versteht, dass eine
Klasse der Zugangsweg zu einer anderen Klasse mit
niedrigerem hierarchischem Rang ist.
-
Bei der Strukturierung durch Objekte sind signifikante
Vorteile zu erkennen, was die Konzeption, die Einstellung
und Wartung von umfangreichen Programmen betrifft.
-
Die klassische Strukturierung durch Objekte berücksichtigt
jedoch nicht die vielfachen Interaktionen, denen man in den
Telekommunikationssystemen begegnet.
-
Außerdem sind die eine Vielfalt der Arten von
Funktionsblöcken und eine große Komplexität in der
Kommunikation zwischen den Blöcken betreffenden Nachteile
auch bei der Strukturierung durch Objekte vorhanden, wie
sie in der erwähnten Veröffentlichung beschrieben ist.
-
Die vorliegende Erfindung, die in den Ansprüchen 1 bis 6
definiert ist, hat somit eine Programmstruktur für ein
Datenverarbeitungssystem, insbesondere ein
Telekommunikationssystem, zum Gegenstand, die den
Erfordernissen vom "Echtzeit"-Typ entspricht, wobei sie
sich die Vorteile der Strukturierung durch "Objekte"
zunutze macht, aber wobei sie die Nachteile, die im
Hinblick auf sie genannt wurden, wesentlich verringert.
-
Die Programmstruktur für ein Datenverarbeitungssystem,
insbesondere ein Telekommunikationssystem, umfasst
Strukturobjekte, die jeweils Daten und Prozeduren, die
Programme sind, die die Daten des Objekts nutzen, so dass
das Objekt als "Dienstlieferant" auftritt, im Sinne der
Mitteilung · 200 von CCITT beinhalten und jeweils
wenigstens einen Zugangspunkt zum Dienst umfassen, an
welchen von einem "Dienstnutzer" eine für das Objekt
bestimmte Nachricht gesendet werden kann, wiederum im Sinne
der Mitteilung · 200 von CCITT, wobei eine solche Nachricht
insbesondere einen Kopf und Parameter aufweist, wobei der
Kopf insbesondere eine Objektidentität beinhaltet, wobei
jedes Strukturobjekt durch Beziehungen mit anderen Objekten
verbunden ist, die es hinsichtlich dieser anderen Objekte
strukturell anordnen.
-
Die Programmstruktur der Erfindung erreicht die dargelegten
Ziele dadurch, dass jedes Objekt aus einem oder mehreren
Modulen für den Zugangspunkt zum Dienst und einem oder
mehreren Kernmodulen besteht, und dass die Kommunikation
zwischen Objekten durch Übertragung von Nachrichten
zwischen einem Modul für den Zugangspunkt zum Dienst eines
einführenden Objekts und einem Modul für den Zugangspunkt
zum Dienst eines Empfängerobjekts stattfindet, wobei die
Übertragung dieser Nachrichten durch Vermittlung eines
einen Kommunikationsdienst bildenden Objekts ausgeführt
wird, das die zu leitenden Nachrichten von den einführenden
Objekten empfängt und sie an die Empfängerobjekte liefert,
wobei dieser Kommunikationsdienst bei der Bestimmung der
Identität des Empfänger-Strukturobjekts Daten beinhaltet,
die die Beziehungen zwischen den Objekten definieren und
sich gleichzeitig auf die Objektidentität des Kopfes der
Nachricht beziehen.
-
Die erfindungsgemäße Einführung von modularen
Strukturobjekten gestattet, bei einer Erhöhung der
Komplexität der Objekte die Anzahl zu verringern, ohne
jedoch die Konzeption kostspieliger zu machen. Die
Kommunikation durch Nachrichten, die im Wesentlichen
asynchron ist und die folglich kostspielige Schutzmaßnahmen
erfordert, um den "Echtzeit"-Aspekt der Verarbeitung zu
bewahren, kann so auf Kommunikationen zwischen relativ
wenig zahlreichen Objekten beschränkt werden. Außerdem
gestattet die Strukturierung der Software durch
Beziehungen, die die Objekte in bezug aufeinander
einordnen, Beziehungen, die vom Kommunikationsdienst
berücksichtigt werden, dass die Nachrichten geleitet
werden, ohne dass die Objekte die Struktur kennen müssen,
in welche sie sich einfügen, wobei eine stark
ausgearbeitete zugelassen wird, die selbst auch bei der
Verringerung der Anzahl von Objekten, somit bei der
leichteren Lösung von Echtzeitproblemen, mitwirkt.
-
Die Programmstruktur ist außerdem dadurch gekennzeichnet,
dass das Kommunikationsprotokoll im Modul für den
Zugangspunkt zum Dienst des Empfängerobjekts definiert ist
und es durch dieses letztere für das Modul für den
Zugangspunkt zum Dienst des einführenden Objekts
spezifiziert ist, damit dieses es anwendet.
-
Diese Anordnung gestattet, dass das einführende Objekt
nicht mehr die Art des Empfänger-Strukturobjekts kennt, was
die Konzeption dieser Objekte erleichtert.
-
Außerdem enthält erfindungsgemäß der Kopf der Nachrichten
die Identität einer Operation, die vom Empfängerobjekt für
die Nachricht angefordert wurde, und berücksichtigt der
Kommunikationsdienst die Identität der angeforderten
Operation bei der Auswahl des Zugangspunktes zum Dienst
eines Empfänger-Strukturobjektes, dem eine Nachricht
gesendet werden soll.
-
Die Erfindung sieht darüber hinaus vor, dass die
Beziehungen insbesondere die Abhängigkeit, die Nutzung, den
Einschließung und die Homologie umfassen.
-
Die verschiedenen Aufgaben und Merkmale der Erfindung
werden nun in der nachfolgenden Beschreibung einer
Ausführungsform der vorliegenden Erfindung ausführlicher
dargelegt, die unter Bezugnahme auf die beigefügten
Zeichnungen gemacht wurde, welche darstellen:
-
Fig. 1 ein Objekt mit einem oder mehreren einzelnen
Zugangspunkten zum Dienst, die in der
Programmstruktur der Erfindung eingeschlossen
sind,
-
Fig. 2 eine Ausführungsform des Objekts der Fig. 1 in
Form eines Automaten mit eingeschwungenen
Zuständen,
-
Fig. 3 die allgemeine Struktur eines Objekts CACO, das
gemäß der vorliegenden Erfindung konzipiert ist,
-
Fig. 4 die allgemeine Struktur eines im Objekt CACO der
Fig. 2 eingeschlossenen Objekts CSIG,
-
Fig. 5 die allgemeine Struktur eines im Objekt CACO der
Fig. 2 eingeschlossenen Objekts CTPP,
-
Fig. 6 die allgemeine Struktur eines im Objekt CACO der
Fig. 2 eingeschlossenen Objekts CSPP,
-
Fig. 7 ein Ausführungsbeispiel der Mittel zum
Nachrichtenrouting gemäß der Erfindung,
-
Fig. 8 eine Ausführungsvariante der Mittel zum
Nachrichtenrouting der Fig. 7.
-
Fig. 1 stellt in Form eines Prinzipbildes ein
Strukturobjekt OBJ dar, das der in der Präambel der
vorliegenden Anmeldung gelieferten Definition entspricht
und das somit Daten und Prozeduren umfasst. Die
Organisation dieser Prozeduren ist irgendeine. Sie können
einen Algorithmus, ein System zur Datenmanipulation, einen
Automaten mit eingeschwungenen Zuständen usw. bilden. Ein
Strukturobjekt wird durch seine Attribute bestimmt, d. h.
durch die Strukturelemente, die es bilden, und durch die
Funktionen, die es dank der Ausführung der
Verarbeitungsprogramme, die es enthält, erfüllt; im
Folgenden ist außerdem zu sehen, dass es auch durch die
Beziehungen charakterisiert wird, die es mit Struktur- oder
ausschließlich funktionellen Objekten verbinden. Eine auf
solche Objekte gestützte Struktur weist Vorteile auf, was
die Validierung und die Wiederverwendung der Software für
die Objekte betrifft.
-
Ein Strukturobjekt umfasst einen oder mehrere
Kommunikationsanschlüsse, die "Zugangspunkte zum Dienst" im
Sinne der bereits genannten Mitteilung · 200 von CCITT
bilden. Jeder von ihnen ist mit einem Modul für den
Zugangspunkt zum Dienst versehen. Im vorgeschlagenen
Beispiel umfasst das Objekt OBJ drei Zugangspunkte zum
Dienst, pc1, pc2, pcn, die jeweils SAP1, SAP2, SAPn für den
Zugangspunkt zum Dienst versehen sind. Die Zugangspunkte
zum Dienst des Objekts OBJ sind jeweils durch
Zugangsschnittstellen I-OBJ1, I-OBJ2, I-OBJn zugänglich.
Die Schnittstelle definiert den Austausch zwischen einem
weiteren Objekt, als Nutzer des Objekts OBJ gesehen, und
einem Zugangspunkt zum Dienst, der dem Objekt OBJ, als
Dienstanbieter gesehen, entspricht. Die Ingangsetzung des
Objekts OBJ ausgehend von einem weiteren Objekt
(beispielsweise U1) wird so durch die Übertragung einer
Nachricht vom Objekt U1 zu einem der Module für den
Zugangspunkt zum Dienst, beispielsweise SAP1, des Objekts
OBJ gemäß einem Kommunikationsprotokoll erreicht, das durch
die entsprechende Schnittstelle I-OBJ1 verwirklicht wird.
Im Allgemeinen kann in der Höhe der Schnittstelle ein
Kommunikationsprotokoll als die Gesamtheit der Regeln zur
Bildung und der Prozesse zur Interpretation der Nachrichten
definiert werden, wobei es dort die Ausführung von
Kommunikationsvorgängen einschließt, die vom Inhalt solcher
Nachrichten angefordert werden.
-
Gemäß einem der Aspekte der Erfindung gehört das
Kommunikationsprotokoll zum Zugangspunkt zum Dienst des
Dienstanbieter-Empfängerobjekts für eine Nachricht, und
jede Kommunikation beginnt mit einem Austausch, der
ausgehend von einer vom Modul für den Zugangspunkt zum
Dienst des Empfängerobjekts gelieferten Information das
Protokoll identifiziert, das anzuwenden vereinbart ist, und
überträgt die Übertragung der Nachricht zum einführenden
Nutzerobjekt. Das Objekt OBJ braucht somit den Nutzer U1
nicht zu kennen, um das anzuwendende
Kommunikationsprotokoll zu bestimmen. Und der Nutzer
braucht das anzuwendende Kommunikationsprotokoll nicht
vorher zu kennen.
-
Die an die Zugangspunkte pc1, pc2, pcn zum Dienst
gelieferten Nachrichten werden von den Modulen SAP1, SAP2,
SAPn für den Zugangspunkt zum Dienst verarbeitet, die es
übernehmen, jedes was es betrifft, eine eingehende
Nachricht zu übernehmen, zu analysieren und jeden Vorgang
auszuführen, der sich daraus ergibt, wobei dieser oft darin
besteht, den Kern N in Bereitschaft zu versetzen, um die
Durchführung der angeforderten Prozeduren zu erhalten.
Jedes dieser Module für den Zugangspunkt zum Dienst, zur
Vereinfachung SAP genannt, kennt somit ein
Kommunikationsprotokoll und wendet es auf der Seite der
Zugangsschnittstelle an.
-
Die verschiedenen SAP kommunizieren mit dem Kern N des
Objekts OBJ durch Nachrichten, die von einzelnen Zugängen
übertragen werden, die vorzugsweise der gleichen internen
Schnittstelle I-N entsprechen. Das bedeutet, dass die
Kommunikation zwischen der verschiedenen SAP und dem Kern N
damit den gemeinsamen Kommunikationsregeln gehorchen und
dass die SAP soweit es nötig ist die Anpassung zwischen den
verschiedenen Zugangsprotokollen und dem Kern ausführen.
Das vereinfacht diesen letzteren.
-
Der Kern N wendet die Prozeduren an, die zusammen die dem
Objekt OBJ übertragene(n) Funktion oder Funktionen bilden.
Vorzugsweise hat der Kern N selbst eine modulare Struktur;
er umfasst beispielsweise Module N1, N2, N3, wobei jedes
von ihnen in bezug auf die anderen autonom ist und eine
Untermenge der Prozeduren des Objekts OBJ ausführt. Die in
einem SAP bei Empfang einer von einem Nutzer kommenden
Nachricht ausgeführte Verarbeitung umfasst eine Analyse,
die eventuell zu der Ermittlung führt, dass ein besonderes
Modul des Kerns aktiviert werden soll. Diese Analyse ist je
nach dem SAP, um das es sich handelt, unterschiedlich, so
dass die vom Objekt OBJ ausgeführte Funktion vom SAP
abhängt, über welches sie aktiviert wird.
-
Um ein einfaches Beispiel zu geben: SAP1 kann zur
Ausführung der normalen Funktion des Objektes OBJ, SAP2 zur
Ausführung von Wartungsoperationen und SAPn zur Beobachtung
des Verkehrs dienen. Es ist offensichtlich, dass sich die
ausgeführten Prozeduren je nachdem unterscheiden, ob das
Objekt OBJ über das eine oder das andere dieser SAP
beansprucht wird.
-
Obwohl es in Fig. 1 nicht dargestellt ist, schließt die
modulare Struktur des Kerns außerdem den Fall ein, in dem
die Ausführung einer Funktion das Eingreifen mehrerer
Kernmodule erfordert, wobei jedes aktivierte Kernmodul ein
weiteres Kernmodul beanspruchen kann. Die Kommunikation
zwischen Kernmodulen erfolgt über eine Schnittstelle I-N,
ganz wie die Kommunikation des SAP mit einem Kernmodul, und
sie gestattet verschiedenen Kernmodulen, nacheinander
einzuwirken.
-
Das Objekt OBJ umfasst außerdem ein Datenmodul DON. Die
Daten, die dort verzeichnet sind, umfassen
herkömmlicherweise bestimmte, von anderen Objekten
empfangene, zeitweilige Arbeitsdaten, die am Ende der
Ausführung einer Funktion aufgegeben werden, das Objekt
beschreibende, semipermanente, interne Daten, die von
Mitteln eingetragen werden, die das Gebiet der vorliegenden
Erfindung verlassen und die während der Verarbeitung nicht
verändert werden, sowie Funktionsdatenmengen, die jeweils
einer der verschiedenen Anrufverarbeitungen oder
allgemeiner jeder Transaktion während der Ausführung durch
das Objekt OBJ entsprechen, die "Kontexte" genannt werden,
wobei jeder dieser Transaktionen ein Kontext eigen ist und
die ganze Zeit der Verarbeitung der Transaktion beibehalten
wird. Das Datenmodul DON ist für die SAP und den Kern über
eine Schnittstelle I-DON zugänglich, das gleiche gilt für
alle Nutzer des Datenmoduls DON. Dies gestattet, dort von
anderen Objekten eingeführte Daten einzutragen, auf
Anregung der SAP semipermanente Informationen zu verändern
oder auf Anregung vom Kern die Kontexte zu aktualisieren.
-
Es werden vorher nicht mehr die Anordnungen beschrieben,
die im Modul N1 des Kerns N diesem gestatten, eine
angeforderte Funktion entsprechend einer internen
Nachricht, die zu ihm übertragen wird, auszuführen. Es
genügt zu erwähnen, dass sich in dieser Hinsicht das Modul
N1 beispielsweise einem Kontext des Datenmoduls DON
anschließt, der durch einen in der Nachricht enthaltenen
Hinweis bezeichnet ist, und ein ebenfalls in der Nachricht
angegebenes Ereignis verarbeitet, beispielsweise nach der
Art eines Automaten mit eingeschwungenen Zuständen.
-
Das Format der über die SAP empfangenen oder zu anderen
Objekten übertragenen Nachrichten gemäß der Erfindung ist
das folgende:
-
< Nachricht> = < Kopf> < Parameter> , worin
-
< Kopf> = < Objekt> < SAP> < Operation> < Anfragetyp> .
-
Das Feld < Objekt> bezeichnet ein Objekt, und es können
daraus die Merkmale des Objekts hergeleitet werden. Wenn
die Nachricht von einem Sendeobjekt zusammengesetzt wird,
kann das Feld < Objekt> ein Objekt bezeichnen, das
"funktionell" genannt wird, welchem kein Strukturobjekt
entspricht. Die gleiche Nachricht enthält, wenn sie an ein
Empfängerobjekt gegeben wird, im Feld < Objekt> , die
Identität des Empfänger-Strukturobjekts. Wir werden später
auf diese verschiedenen Aspekte zurückkommen. Das Feld
< Objekt> kann sich in Form einer mnemonischen Bezeichnung
mit mehrere alphabetischen Buchstaben ausdrücken, welche in
codierter Form beispielsweise 12 Bit umfasst.
-
Das Feld < SAP> bezeichnet das SAP unter denjenigen, das das
Objekt umfasst. Es kann sich in Form einer auf 4 Bit
codierten mnemonischen Bezeichnung ausdrücken.
-
Das Feld < Operation> bezeichnet eine der im System
vorgesehenen Operationen. Gemäß einem der Aspekte der
Erfindung sind die von den verschiedenen Objekten
geforderten Operationen kollektiv als eine Menge von
Operationen definiert, und jedes Objekt führt eine in
dieser Menge enthaltene Untermenge von Operationen aus. Die
Gesamtanzahl dieser Operationen ist sehr begrenzt. Sie
können sich in Form von drei alphabetischen Buchstaben
ausdrücken und auf 8 Bit codiert sein.
-
Das Feld < Anfragetyp> bezeichnet den Typ der begonnenen
Transaktion oder insbesondere die Phase in einem Austausch
bezüglich der bezeichneten Operation, die mehrere mögliche
Phasen umfasst. Es gibt nur einige unterschiedliche
Transaktionen. Sie werden einzeln durch zwei alphabetische
Buchstaben identifiziert und auf 4 Bit codiert.
-
Dieses Beispiel zeigt, dass sich der Kopf der Nachrichten
auf vier Oktetts beschränken kann.
-
Außerdem wird bemerkt, dass das Paar < Operation>
< Anfragetyp> eine Ausführungsphase im Rahmen der für das
Paar < Objekt> < SAP> bestimmten allgemeinen Funktion
identifiziert.
-
Was die < Parameter> betrifft, können sie viel unhandlicher
sein; dies hängt von der geforderten Operation und vom
Anfragetyp ab, was insbesondere die Daten bestimmt, die im
Hinblick auf die auszuführende Verarbeitung zum Objekt
übertragen werden müssen. Die Struktur der < Parameter> ist
durch den Kopf der Nachricht und insbesondere durch den
Wert der Elemente < SAP> , < Operation> und < Anfragetyp>
definiert.
-
Die Rolle eines SAP beim Empfang einer solchen Nachricht
ist beispielsweise, die Felder < Objekt> und < SAP> zu
verifizieren, die mit der Identität des Objekts und des SAP
sowie mit der Beschaffenheit der vom Feld < Operation>
geforderten Operation übereinstimmen müssen, die Felder
< Operation> und < Anfragetyp> zu decodieren, um das
Kernmodul, beispielsweise N1, zu identifizieren, das beim
Empfang der Nachricht, um die es sich handelt, antworten
muss, wobei diese Decodierung für jedes SAP spezifisch ist,
d. h. seine eigene Identität berücksichtigt, und eine
interne Nachricht vorzubereiten, die ihm über die
entsprechende interne Schnittstelle I-N übertragen wird,
sowie die < Parameter> an das Datenmodul DON zu senden, zu
welchem sie über die interne Schnittstelle I-DON übertragen
werden, damit sie in einer den Modulen des Kerns N zur
Verfügung stehenden, vordefinierten Speicherzone des Moduls
DON aufgezeichnet werden. Dann kann das Kernmodul N1 allein
oder in Zusammenarbeit mit anderen Kernmodulen seine
Funktion erfüllen.
-
Während das Prinzipbild der Fig. 1 für ein Objekt eine im
Wesentlichen strukturelle Darstellung liefert, wird nun,
indem man sich Fig. 2 zuwendet, ein im Wesentlichen
organisches Ausführungsbeispiel gegeben.
-
Fig. 2 stellt einen Automaten AEF mit eingeschwungenen
Zuständen dar, der zwei Unterautomaten SAEF1 und SAEF2 mit
eingeschwungenen Zuständen beinhaltet. Der erste dieser
Unterautomaten, SAEF1, umfasst zwei "Automatenbausteine"
BAEF11 und BAEF12, während der zweite Unterautomat
Bausteine BAEF21 und BAEF22 umfasst.
-
Der Zugang zum Automaten AEF erfolgt über eine
Schnittstelle Ia. Eine solche Schnittstelle arbeitet
vorzugsweise im FIFO-Modus (zuerst eingegangen - zuerst
ausgegangen); sie ist somit im Wesentlichen asynchron. Die
Austausche zwischen den Unterautomaten SAEF1 und SAEF2
erfolgen über eine Schnittstelle Is. Obwohl es in der Figur
nicht erscheint, erfolgen die Austausche zwischen dem
Automaten AEF und den Unterautomaten über dieselbe
Schnittstelle Is. Eine solche Schnittstelle arbeitet
vorzugsweise gemäß dem Modus "innere Reihe", bei welchem
die Arbeit des Unterautomaten von einer Anfrage außerhalb
des Automaten nicht unterbrochen werden kann. Man sagt,
dass eine solche Schnittstelle synchron ist. Die Austausche
zwischen den Automatenbausteinen BAEF11 und BAEF12 erfolgen
über eine Schnittstelle Ib. Obwohl es in der Figur nicht
erscheint, erfolgen die Austausche zwischen dem
Unterautomaten SAEF1 und den Unterautomaten, die er
beinhaltet, über dieselbe Schnittstelle Is. Das ist ebenso,
was den Unterautomaten SAEF2 und die Automatenbausteine
betrifft, die er beinhaltet. Die Schnittstelle Ib kann vom
"Rendevous"-Typ sein, das heißt, dass die Arbeit der
Automatenbausteine untereinander und in Beziehung mit dem
Unterautomaten, der sie enthält, verbunden ist und dass die
im Stadium der Konzeption vorhandene Trennung eines
Unterautomaten in Automatenbausteine bei der Ausführung
nicht mehr besteht.
-
Die Automaten, um die es sich handelt, haben auf der
Automatenbaustein-, Unterautomaten- oder Automatenebene von
Petri-Netzen, die in der Technik wohlbekannt sind,
abgeleitete Strukturen.
-
In der Praxis kann so das Objekt OBJ der Fig. 1 vom Typ
des Automaten AEF der Fig. 2 sein. Jedes SAP des Objekts
OBJ nimmt die Form eines Unterautomaten SAEF1, SAEF2 ...
an, der im Verhältnis ein Automatenbaustein pro Operation
aus mehreren Automatenbausteinen bestehen kann. Die
Verkettung der Arbeit dieser Bausteine wird durch die
Erzeugung von internen Ereignissen erhalten, wobei jedes
von ihnen die geeignete Antwort des Empfänger-
Automatenbausteins bewirkt, wonach dieser die Kontrolle an
den Unterautomaten zurückgehen lässt, so dass die
Synchronisation zwischen den Automatenbausteinen kein
Problem darstellt. Jedes Modul des Kerns nimmt ebenfalls
die Form eines Unterautomaten an, umfasst aber nur einen
einzigen Baustein, weil jedes von ihnen nur einen einzigen
Prozess abarbeitet.
-
So erfolgt nur die Kommunikation zwischen Objekten durch
Nachrichten, wobei die von einem Objekt zum anderen zu
übertragenden Daten im Teil < Parameter> der Nachrichten
enthalten sind. Dagegen erfolgt im Inneren eines Objekts
(gemäß Fig. 2 AEF) die Kommunikation im Wesentlichen durch
gemeinsame Variablen, die in den Daten DON des Objekts
festgehalten und für die verschiedenen Elemente, die das
Objekt bilden, zugänglich sind.
-
Ebenso ist nur die Kommunikation zwischen den Objekten
asynchron, da ja nur die Nachrichten zwischen den Objekten
in FIFO gebracht sind, so dass die Echtzeitprobleme, die
Zeitgebungen erfordern, um die eventuelle Überschreitung
der den Operationen zugeteilten Zeit zu überwachen, auf
dieser Ebene untergebracht sind, wobei so die Entwicklung
der internen Logik der Objekte gestattet wird, ohne dass
dort die Sorgen bezüglich der Echtzeit durchschlagen.
-
Es wird nun unter Bezugnahme auf Fig. 3 bis 6 eine
Anwendung der Programmstruktur der vorliegenden Erfindung
beschrieben.
-
In der nachfolgenden Beschreibung werden für den Augenblick
die "Multiprocessing"-Aspekte weggelassen, die einer
solchen Struktur gestatten, vielfache Anrufe scheinbar
gleichzeitig zu verarbeiten, und es wird nur das
beschrieben, was sich auf einen einzigen Anruf bezieht.
Ebenso wird nichts über "Multiprozessor"-Aspekte gesagt,
und es kann für den Augenblick angenommen werden, dass die
Gesamtheit der Struktur der Anmeldung in einem einzigen
Prozessor enthalten ist.
-
Fig. 3 stellt die Gesamtheit der Struktur der Anmeldung
dar, die zwei obere Schnittstellen I-CACO1 und I-CACO2, ein
Gesamtobjekt CACO und zwei untere Schnittstellen I-CLCE und
I-CTNC umfasst. Das Gesamtobjekt CACO hat die Verantwortung
für die Anrufsteuerungsfunktion in einem Vermittlungsnetz.
In allgemeiner Weise entspricht der Anruf einer
Kommunikationsanforderung oder ähnlichen Anforderung, die
von einem Nutzer des Vermittlungssystems ausgeht, und die
Anrufsteuerung besteht darin, Vermittlungsmittel und andere
in Betrieb zu setzen, um auf die Kommunikationsanforderung
zu antworten. Die obere Schnittstelle I-CACO1 ist die
Schnittstelle mit der Kommunikationsfunktion auf der Seite
der anrufenden Leitung. Die obere Schnittstelle I-CACO2 ist
die Schnittstelle mit der Kommunikationsfunktion auf der
Seite der angerufenen Leitung. Auf der unteren Seite gibt
die Schnittstelle I-CTNC Zugang zur Funktion der
Linienführungssuche im Hinblick auf die Bestimmung einer
Linienführung, die gestattet, die anrufende Leitung mit der
angerufenen Leitung zu verbinden. Die Schnittstelle I-CLCE
gibt Zugang zur lokalen Verbindungsausrüstung, die dafür
verantwortlich ist, die physikalische Verbindung zwischen
der anrufenden Leitung und der angerufenen Leitung gemäß
der bestimmten Linienführung aufzubauen.
-
Das Objekt CACO besitzt SAP in Übereinstimmung mit dem, was
gerade in Beziehung auf Fig. 1 beschrieben wurde. Die SAP
werden von nun an einfacher durch eine Art kleine Raute
dargestellt, die das Bezugszeichen des SAP tragen. Das
Objekt CACO empfängt so eine Nachricht von der
Schnittstelle I-CACO1 über das SAP c1. Es überträgt sie
über die Schnittstelle I-CGxx1 an das SAP x1 eines von
mehreren eingeschlossenen Objekten CGxx. Was die
Schnittstellen I-CACO2, I-CLCE, I-CTNC, die SAP c2, c3, c4
des Objekts CACO und die internen SAP x2, y2 und y3, diese
beiden letzteren im Zusammenhang mit einem weiteren von
mehreren eingeschlossenen Objekten CSyy über Schnittstellen
I-CACO3 und I-CACO4, betrifft, wird die gleiche Anordnung
angetroffen.
-
Das Objekt CACO enthält somit an der oberen Seite in der
Figur eine Reihe von ähnlichen Objekten, wie es die
Zeichnung eines in bezug auf das erste in Perspektive
gezeichneten, zweiten Objekts unterstreicht, die das
gemeinschaftliche Bezugszeichen COxx tragen und auf die das
Objekt CACO über jeweilige Schnittstellen I-CGxx1 und I-
CGxx2 und jeweilige SAPx1 und x2 zugreift. Diese Objekte
verarbeiten jeweils ein Protokoll zur Kommunikation mit den
Teilnehmern. Fig. 4 stellt eines, mit CGIG bezeichnet, in
ausführlicher Weise dar, das somit eine Form des Objekts
CGxx ist, das mit SAPxi1 und xi2 versehen ist, die über
jeweilige Schnittstellen I-CGIG1 und I-CGIG2 für das Objekt
CACO zugänglich sind. Wie zu sehen ist, besteht das Objekt
CGIG aus zwei internen Objekten, einem Kommunikationsobjekt
COSG auf der anrufenden Seite und einem
Kommunikationsobjekt CTSG auf der angerufenen Seite. Diese
internen Objekte weisen jeweils ein SAP, go1 bzw. gt1, das
an ein entsprechendes der SAP xi1 und xi2 des Objekts CGIG
gekoppelt ist, über welches sie die
Kommunikationsnachrichten auf der Seite von Teilnehmern
über jeweilige Schnittstellen I-COSG und I-CTSG empfangen,
die die Kommunikation mit dem Objekt CSIG sicherstellen,
sowie ein zweites SAP, go2 bzw. gt2 auf, das an ein
entsprechendes der SAP xi3 und xi4 des Objekts CGIG auf der
unteren Seite für den Zugang zu weiteren Objekten gekoppelt
ist, die ebenfalls im Hauptobjekt CACO eingeschlossen sind.
-
Das Objekt CACO enthält auch eine Reihe von
Telekommunikationsdienst-Anbieterobjekten, die gemäß der
gleichen Darstellung wie für das Objekt CGxx
gemeinschaftlich mit CTxx bezeichnet sind und auf welche
die Objekte CGxx über jeweilige Schnittstellen I-CTxx1 und
I-CTxx2 und jeweilige SAP t1 und t2 zugreifen. Diese
Objekte verarbeiten jeweils die die Lieferung eines
besonderen Telekommunikationsdienstes betreffenden
Funktionen. Eines unter ihnen, mit CTPP bezeichnet, dass in
Fig. 3 identifiziert ist, ist in Fig. 5 dargestellt. Es
liefert den Telekommunikationsdienst von Punkt zu Punkt.
Dieses Objekt ist mit SAP ti1 und ti2 versehen, die für die
Objekte CGxx über jeweilige Schnittstellen I-CTPP1 und I-
CTPP2 zugänglich sind. Wie zu sehen ist, besteht das Objekt
CTPP aus zwei internen Objekten, einem Kommunikationsobjekt
COTP auf der Seite des anrufenden Teilnehmers und einem
Kommunikationsobjekt CTTP auf der Seite des angerufenen
Teilnehmers. Diese internen Objekte weisen jeweils ein SAP,
co1 bzw. ct1, das an ein entsprechendes der SAP ti1 und ti2
des Objekts CTPP gekoppelt ist, über welche das Objekt die
von Objekten CGxx stammenden Kommunikationsnachrichten auf
der Seite der Teilnehmer empfängt, sowie ein zweites SAP,
co3 bzw. ct3, auf, die beide für den Zugang zu
gemeinschaftlich mit dem Bezugszeichen CSyy angegebenen,
weiteren Objekten mit dem SAP t3 des Objekts CTPP auf der
unteren Seite gekoppelt sind. Außerdem ist ein SAP co2 des
Objekts COTP mit einem SAP ct2 des Objekts CTTP direkt
verbunden, was den direkten Austausch von Nachrichten
zwischen den beiden eingeschlossenen Objekten gestattet.
Schließlich besitzt das Objekt COTP ein zusätzliches SAP
c04, das über das SAP t5 des Objekts CTPP an ein in Fig. 3
dargestelltes, zusätzliches Objekt CROU gekoppelt ist, das
zum Definieren einer Verbindungsbahn vom anfordernden
Teilnehmer mit einer Kommunikationseinrichtung verwendet
wird, die Signalaustausche mit dem anfordernden Teilnehmer
vornimmt (im Wesentlichen den Empfang) der angeforderten
Nummer. Zur Vereinfachung wurden die zu den verschiedenen
SAP der Einrichtung der Fig. 4 gehörigen Schnittstellen
nicht dargestellt.
-
Das Objekt CACO enthält noch eine Reihe von
Dienstkomponenten genannten Objekten, die gemäß der
gleichen Darstellung wie für das Objekt CGxx
gemeinschaftlich CSyy bezeichnet werden und auf welche die
Objekte CTxx über eine Schnittstelle I-CSyy und ein SAP s1
zugreifen. Diese Objekte verarbeiten jeweils die Funktionen
bezüglich einer Komponente eines betreffenden Dienstes, wie
Sprachkommunikation, Bildkommunikation usw. Eines unter
ihnen, mit CSPP bezeichnet, das in Fig. 3 identifiziert
ist, ist in Fig. 6 dargestellt. Es liefert eine
Dienstkomponente, wie die Sprachkommunikation, und besteht
selbst aus zwei internen Objekten, einem
Kommunikationsobjekt COSP auf der Seite des anrufenden
Teilnehmers und einem Kommunikationsobjekt CTSP auf der
Seite des angerufenen Teilnehmers. Diese internen Objekte
weisen jeweils ein SAP, so1 bzw. st1, das an das SAP s1
gekoppelt ist, über welches sie die
Kommunikationsnachrichten auf der Seite von Teilnehmern
über eine nicht dargestellte gemeinsame Schnittstelle
empfangen, die die Kommunikation mit dem Objekt CTxx
sicherstellt, sowie ein zweites SAP, so2 bzw. st2, die
gemeinsam an das SAP s3 des Objekts CSPP auf der unteren
Seite gekoppelt sind, und ein drittes SAP, so3 bzw. st3,
auf, die gemeinsam an das SAP s4 des Objekts CSPP für den
Zugang zu weiteren Objekten über die Schnittstellen I-CLCE
und I-CTNC gekoppelt sind, wie weiter oben angegeben.
-
Das Objekt CACO enthält schließlich wenigstens das bereits
genannte zusätzliche Objekt CROU, auf welches die Objekte
CTxx jeweils über ihr SAP t5 zugreifen. Dieses Objekt CROU
weist nur ein einziges SAP, r1, auf, das als Hilfsmittel
der Objekte CTxx gesehen werden soll, auf welches diese zur
Ausführung einer Funktion, die ihnen gemeinsam ist, in
einem Frage-Antwort-Modus zurückgreifen, wobei das einzige
SAP eine Frage eines Objekts empfängt und zu diesem Objekt
die Antwort des Objekts CROU überträgt.
-
Das Vorhergehende bildet ein Ausführungsbeispiel der
Programmstruktur der Erfindung in einem besonderen
Anwendungsfall. Um die Verwendung darzustellen, wird unten
kurz unter Bezugnahme auf Fig. 3 bis 6 ein Beispiel von
in dieser Struktur ausgetauschten Nachrichten und
durchgeführten Funktionen beim Aufbau einer
Sprachkommunikation zwischen zwei Teilnehmern gegeben.
Eine von einem anrufenden Teilnehmer ausgehende
Kommunikationsanforderung gelangt zum Objekt CACO in Form
einer Nachricht, die über die Schnittstelle I-CACO1 an das
SAP c1 geliefert wird. Es handelt sich um eine Nachricht
zur Anforderung des Aufbaus einer Kommunikation, die von
einem anrufenden Teilnehmer ausgeht, auch wird sie sofort
zum Objekt CGIG übertragen und in diesem zum Objekt COSG.
-
Das Objekt COSG sendet in Antwort auf seinem SAP go2 eine
Nachricht, die CTPP.t1 - EST. RQ genannt wird, entsprechend
dem Inhalt ihres Kopfes, der dem entspricht, der vorher
angegeben wurde. Diese Nachricht wird somit zum SAP ti1 des
Objekts CTPP gesendet. Der Aufbau (EST) einer Kommunikation
ist angefordert (RQ). Die begleitenden Parameter
identifizieren den Teilnehmer, um den es sich handelt, und
seine Eigenschaften, insbesondere die Tatsache, dass er
durch Sprachsignal kommuniziert.
-
Aufgrund dessen, dass diese Nachricht an das SAP ti1
gesendet wird, wird die Nachricht zum eingeschlossenen
Objekt COTP über sein SAP co1 übertragen. Dieses letztere
sendet wiederum eine Nachricht, die über sein SAP co4
geliefert wird, zum SAP t5 des Objekts CTPP mit dem Ziel
Objekt CROU, das weiter oben genannt wurde, wobei die
Nachricht CROU - DET.RQ genannt wird. Diese Nachricht wird
somit zum Objekt CROU gesendet, das nur ein SAP besitzt. Es
ist somit ein Verbindungsweg (DET) angefordert (RQ), der
durch die oben genannten Parameter definiert ist.
-
Das Objekt CROU antwortet dafür mit einer Nachricht, die
CROU - DET.CF genannt wird, die die wesentlichen Elemente
des Kopfes der Anforderungsnachricht (CROU - DET) wieder
aufnimmt, was ihre Führung stromaufwärts zum Nutzerobjekt
hin mit einem neuen Anfragetyp (CF, das eine Antwort auf
eine Anforderung angibt) gestattet und in den Parametern
dieser Nachricht den angeforderten Weg liefert.
-
Das Objekt COTP sendet dann über sein SAP co3 eine neue
Nachricht, die CSPP.s2 - OREST.RQ genannt wird. Diese
Nachricht ist somit für das SAP s1 des Objekts CSPP
bestimmt und fordert (RQ) eine Verbindung (OREST) auf der
Seite des anrufenden Teilnehmers an, wobei sie den bereits
erhaltenen Weg liefert. Beim Aufbau dieser Verbindung
antwortet das Objekt CSPP dafür mit einer Nachricht, die
CSPP - OREST.CF genannt wird.
-
Es wird hier die Beschreibung des Prozesses, der sonst
ausführlicher dargelegt werden könnte, indem weitere
Objekte berücksichtigt werden, beendet, weil sie bereits
ausreicht, um deutlich zu machen, dass die Struktur des
beschriebenen Anwenderprogramms außer der Tatsache, dass
dieses aus Objekten besteht, die jeweils eine im Rahmen des
Anrufverarbeitungsprozesses genutzte Funktion haben,
zwischen den Objekten vorgesehene Kommunikationskanäle
umfasst, d. h. Mittel zum Leiten von Nachrichten zwischen
Objekten gemäß ihrem Kopf in Übereinstimmung mit dem Platz,
den jedes Objekt in der Anwendungsstruktur einnimmt.
-
Man könnte sich in der Tat vorstellen, dass bei jedem
Anwendungsfall des Programms vorgesehen wird, dass jedes
Objekt die gesamte Anwendungsstruktur oder zumindest die
Objekte kennt, zu welchen es Nachrichten zu übertragen hat.
Das Senderobjekt überträgt die Nachricht direkt zum
Empfängerobjekt. Mehr oder weniger ausgearbeitete Varianten
dieser Konzeption sind leicht vorzustellen. Sie leiden alle
unter der Anforderung, die gerade genannt wurde: vor der
Gestaltung irgendeines Objekts müssen die Identitäten der
Objekte bereits bekannt sein, mit welchen dieses erste
Objekt kommuniziert. Es ist gut zu verstehen, dass wenn die
Identifikation der Funktionen, welche ein gegebenes Objekt
aufrufen muss, notwendig ist, es andererseits wünschenswert
ist, die Identifikation der Objekte, die diese Funktionen
ausführen, verzögern zu können. Es wird zu sehen sein, dass
dies über die Verwendung von Beziehungen zwischen Objekten
geht, wie einem Mittel zum Routing von Nachrichten zu den
Objekten hin, die die Funktionen ausführen, die die
Nachricht anfordern.
-
Die Programmstrukturierung durch Objekten, wie am Anfang
dieses Textes angegeben, sieht bereits das Vorhandensein
von strukturierenden Beziehungen vor. Erfindungsgemäß sind
die Beziehungen, die zwischen den Objekten der
Programmstruktur vorhanden sein können:
-
- die Nutzungsbeziehung, die angibt, dass ein Objekt von
einem anderen genutzt wird,
-
- die Abhängigkeits- oder Hierarchiebeziehung, die
angibt, dass ein Objekt eine besondere Form eines
(hierarchisch höheren) Modellobjekts ist,
-
- die Einschließungsbeziehung, die angibt, dass ein
Objekt in einem anderen eingeschlossen ist;
-
- die Homologiebeziehung, die angibt, dass ein Objekt zu
einem anderen homolog ist, was gestattet, ein Objekt
in zwei getrennt identifizierte, homologe Teile zu
teilen.
-
Diese Beziehungen sind in der unter Bezugnahme auf Fig.
3 bis 6 beschriebenen Struktur leicht zu finden. Das Objekt
CROU wird vom Objekt CTxx genutzt. Das Objekt CTPP hängt
vom Objekt CTxx ab. Die Objekte COTP und CTTP sind im
Objekt CTPP eingeschlossen. Sie sind außerdem zueinander
homolog.
-
Erfindungsgemäß ist es vorgesehen, die Nachrichten mit
einem Kopf entsprechend dem, der weiter oben beschrieben
wurde, durch Mittel zum Routing von Nachrichten zu leiten,
die einen Kommunikationsdienst bilden, welcher bei jeder
Anwendung solche Beziehungen derart berücksichtigt, dass
das eine Nachricht sendende Objekt nicht die Identität des
Objekts zu kennen braucht, das die von dieser Nachricht
angeforderte Operation ausführt, was darauf hinausläuft,
ihm zu gestatten, die Funktion eines hypothetischen
Objekts, für welches die Operation angefordert wird; mit
der Auflage für den Kommunikationsdienst zu nennen, das
strukturelle Empfängerobjekt zu identifizieren, zu welchem
diese Nachricht schließlich gesendet werden soll.
-
Ebenfalls erfindungsgemäß bildet dieser
Kommunikationsdienst ein Objekt. Und dieses Objekt greift
für die tatsächliche Übertragung der Nachricht zu ihrem
Empfänger, wenn dieser einmal identifiziert ist, auf ein
weiteres Objekt zurück. Solche Objekte werden nun unter
Bezugnahme auf Fig. 7 beschrieben, die ein
Ausführungsbeispiel des Nachrichtenkommunikationsdienstes
gemäß der Erfindung darstellt.
-
Im Beispiel von Fig. 7 kommunizieren Objekte X, Y (oder
eher SAP X, Y von nicht dargestellten jeweiligen Objekten,
aber dies läuft auf das gleiche hinaus) untereinander mit
Hilfe von Objekten RLA und IACS zum Übertragen von
Nachrichten. Die zu übertragende Nachricht, die
beispielsweise vom Objekt X stammt, das das einführende
Objekt ist, ist im Feld < Parameter> einer über das Objekt X
zum SAP la1 des Objekts RLA gesendeten
Kommunikationsnachricht eingeschlossen. In Antwort darauf
baut das Objekt RLA eine Verbindung zwischen dem
einführenden Objekt und dem Objekt Y auf, an welches die zu
übertragende Nachricht übergeben werden soll, d. h. an ein
tatsächliches strukturelles Empfängerobjekt für die
Nachricht, und liefert die zu übertragende Nachricht an
dieses Empfängerobjekt über sein SAP la2. Beim Aufbau
dieser Verbindung berücksichtigt das Objekt RLA die
Programmstruktur, d. h. die Beziehungen zwischen den
Objekten, um ausgehend vom Kopf der Nachricht und
insbesondere den Feldern < Objekt> und < SAP> und in
Anwendung der Beziehungen, die auf das im Feld < Objekt>
genannte Objekt angewendet werden, die Identität des
strukturellen Empfängerobjekts zu bestimmen. Das Objekt RLA
übersetzt folglich den Kopf der Nachricht und übergibt dem
Objekt IACS die Sorge, die Nachricht physikalisch bis zum
Empfängerobjekt zu leiten.
-
Die Beziehungen selbst sind im Datenmodul des Objekts RLA
in Form von Ausdrücken des Typs eingetragen:
-
- < OBJEKTi> < SAPm> < D> < OBJEKTj> < SAPn> , was angibt,
dass das mit < OBJEKTi> bezeichnete Objekt vom mit
< OBJEKTj> bezeichneten Objekt abhängt, mit < D>
angegebene Beziehung, und genauer, dass der Kopf einer
Nachricht, die < OBJEKTi> < SAPm> enthält, in einen Kopf
übersetzt werden muss, der < OBJEKTj> < SAPn> enthält,
wonach nur mehr die Nachricht gemäß diesem neuen Kopf
geleitet werden muss, was von IACS gefordert wird,
oder
-
- <
OBJEKTi> < SAPm> < U> < OBJEKTj> < SAPn> oder
-
- < OBJEKTi> < SAPm> < I> < OBJEKTj> < SAPn> oder
-
- < OBJEKTi> < SAPm> < H> < OBJEKTj> < SAPn> ,
-
Ausdrücke, in welchen < U> , < I> , < H> die Nutzungs-,
Einschließungs- und Homologiebeziehungen darstellen.
-
Die Erwähnung der Identität eines SAP in den Beziehungen
oben ist wahlfrei.
-
Das Objekt RLA in der Version der Fig. 7 fragt somit bei
Empfang einer Nachricht, die von irgendeinem Objekt über
sein SAP la1 zu ihm gelangt, die in seinem Datenmodul
gespeicherten Beziehungen ab und modifiziert den Kopf der
Nachricht entsprechend diesen Beziehungen. Dann übergibt es
sie über sein SAP la3 an das SAP la1 des Objekts IACS.
Dieses leitet die Nachricht über Übertragungswege und
übergibt sie am Bestimmungsort über sein SAP la2 an das SAP
la4 des Objekts RLA, das sie über sein SAP la2 an das
Empfängerobjekt liefert, dessen Identität im Kopf der
Nachricht angegeben ist. Insbesondere können die
Übertragungs- und Empfängerorgane für die Nachricht in
physikalisch getrennten Datenverarbeitungseinrichtungen
eingesetzt sein. Das Objekt RLA ist in jeder dieser
Einrichtungen mit einem vollständigen Datenmodul vorhanden,
um seine Funktion zugunsten der in der Einrichtung
eingesetzten Objekte erfüllen zu können. Ebenso ist das
Objekt IACS in jeder der Einrichtungen vorhanden, und ihre
verschiedenen Teile sind miteinander verbunden, um die
Leitung von Nachrichten zwischen ihnen entsprechend ihrem
Kopf zu gestatten.
-
Wir wenden uns nun der Fig. 8 zu, die eine mehr
ausgearbeitete Version der Objekte RLA und IACS der Fig. 7
darstellt, bei welcher einerseits das Objekt RLA zwei
eingeschlossene Objekte umfasst, das Sendeobjekt EMRLA, das
mit sendeseitigen Beziehungen für die Leitung von
Nachrichten beaufschlagt ist, und das Empfangsobjekt RERLA,
das mit empfangsseitigen Beziehungen für die Leitung der
Nachrichten beaufschlagt ist, und andererseits IACS drei
eingeschlossene Objekte enthält, die drei Modi zur Leitung
der Nachrichten liefern, das Objekt DTG zur
Datagrammübertragung, das Objekt QR zur Übertragung von
Frage-Antwort und das Objekt SS zur Übertragung der
Sitzung.
-
Die SAP la3 und la4 sind durch das übersetzt, was als drei
Zwei-Richtungs-SAP la31, la32 und la33 dargestellt ist,
aber tatsächlich drei Paaren von SAP für den Zugang zu drei
im Objekt IACS eingeschlossenen Objekten entspricht.
-
Das Objekt DTG zur Datagrammübertragung empfängt eine
Nachricht vom Objekt EMRLA, das im Objekt RLA
eingeschlossen ist, wobei es den Empfang angibt, es
überträgt zum Objekt RERLA, das im Objekt RLA
eingeschlossen ist, wobei es eine Rückmeldung empfängt, und
liefert eine Angabe über die Übergabe der Nachricht zum
Objekt EMRLA hin. So ist zu sehen, dass ein Datagramm eine
Nachricht ist, die keine Antwort umfasst.
-
Das Objekt QR zur Übertragung von Frage-Antwort gestattet
einen Übertragungsmodus ähnlich dem Vorhergehenden, sieht
aber außerdem die Übertragung einer Antwortnachricht auf
die als eine Frage betrachtete, geleitete erste Nachricht
in umgekehrter Richtung vor.
-
Das Objekt SS zur Übertragung der Sitzung ist im
Unterschied zu den beiden Vorhergehenden, die nur darauf
zielen, eine einzige Nachricht zu leiten, für die
Übertragung von mehreren Nachrichten in beiden Richtungen
zwischen den beiden definierten Objekten eingerichtet. Die
Eröffnung der Sitzung wird von einer ersten Nachricht vom
einführenden Objekt angefordert; sie wird vom
Empfängerobjekt angenommen. Dann werden die Nachrichten
geleitet, ohne dass ein Grund vorhanden ist, eine Antwort
vorzusehen. Es wird einfach die Übergabe der Nachricht
signalisiert.
-
Es wird sich nicht weiter über die Übertragungsmodi
ausgelassen, weil man sich entsprechend den
Kommunikationsanforderungen eine große Anzahl vorstellen
kann.
-
Im Vorhergehenden wurden schließlich die Multiprocessing-
Aspekte erwähnt, die sonst außerhalb des Gebietes der
Erfindung liegen.
-
Es wird jedoch daran erinnert, dass jedes Objekt, und dies
lässt sich auch auf die Objekte RLA und IACS anwenden, in
seinen Funktionsdaten "Kontexte" umfasst, eine Menge von
Daten bezüglich der Verarbeitung eines Anrufs. So kann das
Objekt aufgerufen werden, um eine Stufe in der Verarbeitung
eines Anrufs auszuführen, der vorher in Erwartung eines
Ereignisses, das geschehen wird, beispielsweise die Antwort
des angerufenen Teilnehmers oder die Bestätigung des
Aufbaus einer Verbindung oder noch die Antwort, dass ein
anderes Objekt seinen eigenen Teil in der Anrufverarbeitung
auszuführen hat, ausgesetzt wurde. Dieses Ereignis wird ihm
durch eine Nachricht signalisiert. Herkömmlicherweise ist
dieser Nachricht eine Information beigefügt, die auf die
eine oder die andere Weise den Anruf, um den es sich
handelt, somit den "Kontext" identifiziert, auf welchen
sich das Objekt beziehen muss, und die die vor der
Aussetzung der Verarbeitung im besagten Objekt erreichte
Situation beschreibt. Die Verarbeitungsstufe wird
hinsichtlich dieses Kontextes ausgeführt, der, bevor das
Objekt am Ende der Verarbeitungsstufe die Verarbeitung des
betrachteten Anrufs aufgibt, wobei es für die Verarbeitung
eines weiteren Anrufs verfügbar wird, modifiziert, indem
sie sich auf einen anderen Kontext bezieht.
-
Gemäß einem zusätzlichen Merkmal der Erfindung ist es das
Objekt RLA, das den Nachrichtenknmmunikationsdienst
liefert, dem die Verantwortung für die Multiprocessing-
Aspekte übertragen wurde, d. h. die Sorge, einer
Anrufverarbeitung in einem wegen dieses Anrufs zum ersten
Mal beanspruchten Objekts einen Kontext zuzuweisen und den
auszuführenden Kontext jedes Mal, wenn dieses Objekt für
denselben Anruf von neuem beansprucht wird, zu
identifizieren, was ausgehend von der Identität des
Kontextes des einführenden Objektes, auch vom Objekt RLA
bekannt, erfolgen kann, usw.
-
Es ist ganz offensichtlich, dass die vorhergehenden
Beschreibungen nur als nicht einschränkendes Beispiel
gegeben wurden und dass zahlreiche Varianten vorstellbar
sind, ohne deswegen den Rahmen der Erfindung zu verlassen.