-
Die
Erfindung bezieht sich auf ein Messaging-System für eine Telekommunikationssteuerung,
welche in Realzeit arbeitet und mehrfache verteilte Subsysteme aufweist,
beispielsweise eine Hauptsteuerung und mehrere Leitungskarten. Die
Erfindung bezieht sich insbesondere auf solche Systeme, die eine
Anzahl von Schaltungen aufweisen, in welche Software eingebettet
ist.
-
Bisher
bestand das Verfahren zum Messaging innerhalb dieser Systeme darin,
dafür eigens bestimmte
Kommunikationsprotokolle bereitzustellen, welche in Hardware-Busse
und Schnittstellenschaltungen eingebettet waren, um eine Realzeit-Leistung
zu erzielen. Beispielsweise beschreibt die
US 5 678 006 ein Messaging-System
in einer Telekommunikationssteuerung, welches mehrere verteilte
Subsysteme aufweist. Ein solches Verfahren war für viele Situationen zufriedenstellend.
-
In
den vergangenen Jahren bestand ein wachsendes Bedürfnis bei
Telekommunikationssteuerungen darin, dass diese eine eigene Flexibilität aufweisen,
um Modifikation zuzulassen. Eine derartige Modifikation ist sowohl
zum Ändern
der Funktionalität des
Systems erforderlich als auch dazu da, um zu erlauben, ein Wachstum
für ständig wachsende
Transaktionsdatenmengen zu befriedigen. Messaging-Protokolle, die
auf eine Funktionalität
höherer
Ebene oder niedrigerer Ebene eingebunden sind, neigen dazu, die
Fähigkeit
zu hemmen, Telekommunikationsteuerungen zu modifizieren.
-
Es
ist eine Aufgabe der Erfindung, ein Messaging-System für eine Telekommunikationssteuerung,
welches eine einfache Modifikation von Resourcen erlaubt, welches
Telekommunikationsfunktionen ausführt, und von Anwendungen bereitzustellen,
welche diese Funktionen steuern und anfordern.
-
Eine
Weiterentwicklung dieser Aufgabe besteht darin, das Messaging-System
von den Anwendungen und Resourcen zu entkoppeln, so dass sie unabhängig vom
Messaging-System
modifiziert werden können.
-
Eine
weitere Aufgabe besteht darin, diese Flexibilität zu erreichen, ohne die Ansprechzeit
zu beeinträchtigen,
so dass eine Realzeitleistung dennoch erreicht wird.
-
Die
Erfindung stellt ein Messaging-System bei einer Telekommunikationssteuerung
bereit, welches mehrere verteilte Subsysteme aufweist, wobei das
Messaging-System aufweist:
Mittel in einem anfordernden Subsystem
zum Erstellen eines Proxy zum Steuern von Messaging für eine Funktion,
die in Echtzeit von einer Resource auf einem Ressourcen-Subsystem ausgeführt werden
soll, wobei die Funktion von einer Anwendung auf dem anfordernden
Subsystem angefordert wird;
eine Middleware-Engine in dem anfordernden
Subsystem, umfassend Mittel, um als Reaktion auf den Proxy in Echtzeit
tätig zu
werden und eine Funktionsanforderungsmeldung zu erzeugen und die
genannte Meldung zu dem Resourcen-Subsystem zu übertragen;
eine Middleware-Enginge
in dem Resourcen-Subsystem, umfassend Mittel zum Lesen der Meldung, Ermitteln
eines Servers in Verbindung mit der Funktion und Aktivieren des
Servers;
Mittel in dem Server zum Regeln der Leistung der Funktion
durch die Resource;
Mittel in der Resourcen-Middleware-Engine
zum Zurückgeben
der Kontrolle an den Proxy, wenn die Funktion vollendet ist; und
Mittel
in dem anfordernden Subsystem zum Beenden des Proxy, wenn die anfordernde
Anwendung zufrieden gestellt ist.
-
Der
Rahmen der vorliegenden Erfindung richtet sich auf die Probleme
des Standes der Technik, da die Verwendung einer Middleware-Engine
das Entkoppeln des Messaging-Systems
von den Anwendungen und den Resourcen in einer Art erlaubt, dass
sie unabhängig
gemäß ihrer
Leistung modifiziert werden können.
-
Vorzugsweise
weist jede Middleware-Engine eine Einrichtung auf, um als Anforderungs-
oder als Resourcen-Middleware-Engine zu arbeiten, so dass Funktionsanforderungen
bidirektional sind.
-
Bei
einer Ausführungsform
weisen die Subsysteme eine Hauptsystemsteuerung und mehrere Leitungskarten
auf.
-
Bei
einer anderen Ausführungsform
weist die Anforderungsanwendung eine Einrichtung auf, um den Proxy
zu erzeugen und um den Proxy zu beenden.
-
Bei
einer Ausführungsform
ist der Proxy eine Instanz einer Proxy-Objektklasse, Vorzugsweise
ist der Server eine Instanz einer Server-Objektklasse.
-
Bei
einer Ausführungsform
ist der Server in einem nichtflüchtigen
Speicher gespeichert.
-
Bei
einer weiteren Ausführungsform
ist die anfordernde Middleware-Engine mit der Anwendung lediglich über den
Proxy gekoppelt, so dass die Anwendung unabhängig von der Middleware-Engine
erzeugt oder modifiziert werden kann.
-
Bei
einer weiteren Ausführungsform
ist die Resource-Middleware-Engine mit der Resource lediglich über den
Server gekoppelt, so dass die Resource unabhängig von der Middleware-Engine
erzeugt oder modifiziert werden kann.
-
Vorzugsweise
registriert sich der Server automatisch bei der Middleware-Engine.
-
Bei
einer weiteren Ausführungsform
registriert sich die Server sowohl für aktive als auch für redundante
Resourcen bei der Resourcen-Middleware-Engine, um automatische Redundanz
bereitzustellen.
-
Vorzugsweise
weist die anfordernde Anwendung eine Einrichtung auf, um den Proxy
zu erzeugen, wobei ein logischer oder ein realer Schlüssel für die Resource
und die Funktion präsentiert
wird.
-
Bei
einer Ausführungsform
weist die Meldung die Schlüsselfunktions-Parameterargumente auf.
-
Bei
einer weiteren Ausführungsform
steuert der Proxy eine von mehreren Arten von Meldungstransaktionen,
einschließlich
einer synchronen Art, in der die Funktion aufgerufen, eine Antwort
erwartet und ein Rückgabewert
zur anfordernden Anwendung geführt
wird, und einer synchronen Art, in der die Funktion lediglich aufgerufen
wird.
-
Bei
einer anderen Ausführungsform
steuert der Proxy eine verzögerte
synchrone Transaktion, in der eine Funktion aufgerufen und eine
Antwort übertragen
wird und eine Anwendung die Antwort später abruft.
-
Bei
einer Ausführungsform
initialisiert der Proxy mehrere Versuchswiederholungen bei einem Versagen
der angeforderten Funktion.
-
Bei
einem anderen Merkmal liefert die Erfindung ein Telekommunikationssystem,
welches ein Messaging-System nach einem der vorhergehenden Ansprüche aufweist.
-
Die
Erfindung wird besser aus der folgenden Beschreibung einiger Ausführungsformen,
die lediglich beispielhaft angegeben werden, unter Bezugnahme auf
die beiliegenden Zeichnungen verstanden, in denen:
-
1 eine
Diagrammdarstellung eines Telekommunikationssteuerungs-Messaging-Systems und
einer interaktive Anwendung mit Anwendungen und Resourcen der Steuerung
ist;
-
2 bis 5 Diagramme
sind, die Messaging-Systemkomponenten zeigen; und
-
6 bis 18 Informations-Flussdiagramme
sind, die die Arbeitsweise des Messaging-Systems zeigen.
-
Mit
Hilfe von 1 wird zunächst ein Messaging-System in
einer Steuerung 1 kurz beschrieben. Die Steuerung 1 umfasst
eine Hauptsteuerung 2 und Leitungskarten 3. Die
Hauptsteuerung 2 umfasst eine Hauptsteuerungsanwendung 5 und
einen SNMP-Agenten 6, der eine Schnittstelle mit einer Verwaltungsstation 7 bildet.
Die Hauptsteuerung 2 umfasst außerdem eine Middleware-Engine 11,
welche über
Proxys 12 mit der Anwendung 5 interaktiv arbeitet.
Die Middleware-Engine 11 kommuniziert über eine Mitteilungs-Handhabungsebene
und einer realen Ebene, die allgemein durch das Bezugszeichen 20 angedeutet
ist, mit entsprechenden Middleware-Engines 11 in der Leitungskarte 3.
Die Middleware-Engine jeder Leitungskarte 3 ist mit einer
Leitungskarten-Anwendung 10 über Server 13 gekoppelt.
Zusätzlich
gibt es eine IDL-Schnittstelle zwischen der Leitungskarten-Anwendung 10 und
der Middleware-Engine 11, um zuzulassen, dass die Leitungskarte
Kartenkommunikation leitet. Bei dieser Schnittstelle sind die Proxys
und die Server aus Einfachheitsgründen nicht explizit dargestellt.
-
Die
Server 13 registrieren sich in einer allgemeinen Weise
mit der Middleware-Engine
und nicht durch eine Art von Hardware-Festcodierung. Dies stellt
sicher, dass die Middleware-Engine keine Modifikation bei Bildung
zusätzlicher
Server erfordert.
-
Die
zentralen Steuerungs-IDL-Schnittstellen verlangen nach einer Verwendung
einer Middleware-Engine 11 in einem anfordernden Subsystem
und einer Middleware-Engine 11 in einem Resourcen-Subsystem.
Jede Middleware-Engine 11 umfasst Funktionalität, um bidirektionale
Funktionsrufe bereitzustellen. Für
die Zwecke dieser Beschreibung werden die Ausdrücke "Anfordern von Middleware-Engine" und "Resourcen-Middleware-Engine" jedoch dazu verwendet,
die Rollen zu zeigen, die sie für
einen bestimmten Funktionsruf spielen.
-
Das
Messaging-System weist die Middleware-Engine 11 im Subsystem 2 und 3,
die Server-Objekte 13 (welche im nichtflüchtigen
Speicher gespeichert sind) und die Funktionalität bei Anwendungen zum Bilden
von Proxys auf. Die Proxys und die Server sind beide Instanzen von
Objektklassen. Die Proxys jedoch sind bezüglich ihrer Natur so, wie sie
existieren, lediglich während
eines bestimmten Funktionsrufs transient, während die Server permanent sind,
da sie mit Resourcen eher als bestimmte Funktionsrufe verknüpft sind.
-
Unter
Bezugnahme wieder auf 1 wird, wenn die Steuerungsanwendung 5 eine
Funktion bezüglich
einer Quelle einer entfernten Leitungskarte 3 anfordert,
ein Proxy durch die Anwendung erzeugt. Der Proxy ist eine Instanz
einer Proxy-Objektklasse. Der Proxy wird durch Präsentieren
eines logischen oder eines realen Schlüssels gebildet, der den Server identifiziert.
Der Proxy übernimmt
die Steuerung des Funktionsrufs und fordert eine Mitteilung an,
welche über
die Middleware-Engine 11 zur Fern-Leitungskarte 3 zu
liefern ist, welche die angeforderten Dienste unterstützt. Die
Resourcen-Middleware-Engine bestimmt den Server 13, der
zu rufen ist, und leitet die Operation zu diesem Server weiter.
Der Server 13 ruft dann die reale Resourcenfunktionalität durch
Rufen der lokalen Funktion. Bei Beendigung liefert der Server 13 Daten
zum anrufenden Proxy zurück,
der wiederum die Steuerung zur anrufenden Anwendung zurückbringt.
Wenn die Anwendung den Betrieb beendet hat, wird der Proxy beendet.
-
Viele
Vorteile werden aus diesem Messaging-System-Aufbau deutlich. Ein
derartiger Vorteil ist die Tatsache, dass es sehr wenig Speicher-
oder Verarbeitungsgesamtaufwand beim anfordernden Subsystem gibt,
da die Proxys transient sind und lediglich während des Funktionsrufs existieren.
Dies hilft, eine Realzeitleistung in einer eingebetteten Umgebung
zu erreichen, die traditionell durch einen Speicher und die Verarbeitungsleistung
begrenzt ist. Ein weiterer Hauptvorteil ist die Tatsache, dass die anfordernde
Anwendung lediglich mit der Middleware-Engine über die Proxys gekoppelt ist.
Die Anwendung erzeugt den Proxy, und der Proxy übernimmt dann die Steuerung
durch Richten der Middleware-Engine, um die Funktionsanforderungsmitteilung zu übertragen.
Daher können
die anfordernden Anwendungen modifiziert werden, gelöscht werden oder
unabhängig
von der Middleware-Engine hinzugefügt werden. In gleicher Weise
ist die Resource-Middleware-Engine lediglich mit den Resourcen über die
Serverobjekte 13 gekoppelt. Die Serverobjekte 13 registrieren
sich bei der Middleware-Engine automatisch. Daher können die
Resourcen unabhängig
von der Resourcen-Middleware-Engine modifiziert, ergänzt oder
gelöscht
werden.
-
Die
anfordernde Anwendung muss nicht wissen, welche Redundanz bereitgestellt
wird und welche die aktuelle aktive Resource ist. Diese Ebene an Funktionalität wird aufgrund
des proxy-erzeugenden Schlüssels,
der eine logische oder reale Adresse identifiziert, und durch Mehrfachumformen
der Information durch die Middleware-Engine an alle Leitungskarten
automatisch erreicht.
-
Die
anfordernde Anwendung muss lediglich einen Resourcenschlüssel identifizieren,
um den Proxy zu erzeugen. Dies kann ein logischer Schlüssel für logische
Resourcen sein. Ein Beispiel einer Situation, bei dem logische Schlüssel verwendet
werden, ist die Erzeugung eines logischen Alarms in einer Leitungskarte.
Ein realer Schlüssel
würde verwendet
werden, beispielsweise dazu, um einen Leistungsschwellenwert für eine bestimmte
Leitungskarte festzulegen. Der Proxy vermeidet Informationshandlungs-Gesamtaufwand
bei der an fordernden Anwendung, indem automatisch der Funktionsruf
gesteuert und Aktionen durch-führt werden,
beispielsweise automatisches Wiederversuchen des Rufs, wenn ein Versagen
auftritt.
-
Drei
Arten an Transaktionen können
für einen
Funktionsruf erforderlich sein. Diese sind synchron, asynchron und
verzögert-synchron.
Für eine synchrone
Transaktion wird die Funktion aufgerufen, der Server wartet, bis
die Funktion durchgeführt
wurde, und der Server überträgt einen
Rückgabewert zum
anfordernden Proxy. Für
eine asynchrone Transaktion wird die Funktion auf lediglich aufgerufen,
und es tritt keine weitere Aktion auf. Für eine verzögerte synchrone Transaktion
wird die Funktion durch die Anwendung, welche den Proxy erzeugt, aufgerufen,
und die Middleware kehrt unmittelbar zur Anwendung zurück. Die
Anwendung kann später
die Middleware-Antwort abfragen, beispielsweise nach Ablauf eines
Timers.
-
Mit
Hilfe von 2 bis 5 werden
die Mechanismen hinter dem Messaging-System ausführlicher beschrieben. Der Proxy 12 besitzt
ein Proxyobjekt 12(a) und eine Meta-Ebenen-Architektur 12(b). Die
Messaging-Engine 11 ist mit einem Informations-Handhabungssystem
(MHS) 30 einer niedrigeren Ebene verbunden, die wiederum
mit einer realen Ebene 31 zur Mitteilungsübertragung
verbunden ist. Der Server 13 umfasst einen Objekt-Adapter 13(a) eine
Meta-Ebene 13(b) und ein Objekt 13(c). In 2 sind
die anfordernden und die Resource-Middleware-Engines 11 aus
Darstellungsgründen
zu einer Box kombiniert.
-
Wie
in 3 gezeigt ist, umfasst der Proxy den Betrieb,
die Schnittstelle und allgemeine Komponenten 40, 41 und 42 auf
der Meta-Ebene.
-
Wie
in 4 gezeigt ist, umfasst der Server 13 unbestimmt-bezogene
Komponenten 50, betriebs-bezogene Komponenten 51 und 52 und schnittstellen-bezogene
Komponenten 53 und 54.
-
5 ist
ein statisches Middleware-Modell, welches mit den Dynamik-Modellsequenz-Diagrammen
von 6 bis 18 verknüpft ist. Mit Hilfe von 6 bis 18 sind
Beispiele von Funktionsrufen gezeigt. Diese zeigen die synchronen,
asynchronen und verzögerten
synchronen Transaktionsarten.
-
6 zeigt
einen synchronen Ruf für
das Verfahren foo, welches eine synchrone Operation ist. Der Proxy
kehrt nicht zurück,
bis der Server abschließt
und ein Ergebnis zum Proxy zurückbringt. Die
Sequenz ist wie folgt:
Die anfordernde Anwendung instruiert
das System 1, einen Proxy X zu erzeugen.
Der Kunde
ruft die Funktion foo in bezug auf den Proxy X auf.
Der Proxy
X verpackt die Anfrage als Information und überträgt diese über den Objekt-Adapter, der
die Information interpretiert, und ruft die Funktion foo in bezug
auf den Server X, der das Serverobjekt nutzt.
Der Rückgabewert
foo wird zurück
zum Objekt-Adapter gebracht, der das Ergebnis zum Proxy X als Information
sendet.
Der Proxy X interpretiert die Information und liefert das
Ergebnis als Rückgabewert
von der Funktion foo zurück.
-
Ein
verzögerter
synchroner Ruf kann ebenfalls getätigt werden. Beispielsweise
kann der Kunde ein Verfahren longfoo auf dem Server X aufrufen, ohne
auf den entfernten Server zu warten, um eine Antwort auszuführen und
zurückzubringen.
Dies erlaubt es dem Kunden, andere Aufgaben in der Zwischenzeit
durchzuführen,
wobei er periodisch einen Nicht-Warte-Modus zur Antwort überprüft.
-
Wie
in 7 gezeigt ist, bildet der Kunde einen ProxyOperationOn-Proxy,
der angibt, dass dieser auf der Operation longfoo ist. Der Kunde
ruft das Verfahren sendDeferred auf, wobei er die erforderten Parameter,
wenn es welche gibt, durchlässt.
Dieses Verfahren verpackt die Anforderung wie eine Information und überträgt diese über den
Objekt-Adapter, speichert den Handel intern und kehrt zum Kunden zurück. Der
Kunde ruft pollResponse auf dem ProxyOperationOn-Objekt. Dieses
wiederum ruft isReplyAvailable auf der Middleware-Engine, jedoch, wenn noch
keine Antwort verfügbar
ist, schickt er falsch zurück.
Der Objekt-Adapter
interpretiert die Information und ruft die Funktion longfoo auf
dem Server X. Das Ergebnis von longfoo wird zurück zum Objekt-Adapter gebracht,
der das Ergebnis zum Proxy X über
eine Mitteilung liefert. Der Kunde ruft pollResponse auf dem ProxyOperationOn-Objekt, wobei er
dieses Mal wirklich zurückläuft. Die
Antwort wird dann abgerufen und durch den Kunden interpretiert.
-
Einweganforderungen
werden ebenfalls durch das System gehandhabt. Das Verfahren shortfoo
ist eine Einwegoperation. Dieses Verfahren wird auf dem Proxy X
gerufen, wie in 8 gezeigt ist. Der Proxy X verpackt
die Anforderung wie vorher und überträgt diese
zum Objekt-Adapter. Die Funktion shortfoo auf dem Proxy X kehrt
unmittelbar zurück, der
Objektadapter interpretiert die Mitteilung und ruft die Funktion
shortfoo auf dem Server X. Der Objektadapter sendet keine Antwort,
da er kennt, dass das Verfahren ein Einwegverfahren ist.
-
9 zeigt
die Situation, bei der eine Mitteilung nicht von der Informationsebene
gesendet wird. In diesem Fall löscht
der Proxy das Ausnahmeobjekt des Proxys. Nachdem versucht wird,
das Mitteilungsversagen zu senden, aufgetreten ist, wird das Versagen
zurück zum
Proxy gebracht. Der Proxy interpretiert dies als SendFail und sendet
das exception object. Das Proxy-Verfahren liefert eine Antwort zurück, und
der Kunde prüft
das Ausnahmeobjekt des Proxys und ermittelt die Ausnahme und handhabt
diese in geeigneter Weise.
-
Das
System handhabt außerdem
eine Situation, wo eine Mitteilung gesendet wird, jedoch nicht empfangen
wird, wie in 10 gezeigt ist. In diesem Fall,
nachdem der Betrieb ausgeführt
wird und als wirklich zurückgegeben
wird, wird die Mitteilung niemals am Bestimmungsort empfangen. Der
Proxy wartet auf eine Antwort und zählt. Diese wird als Ablaufzeit
interpretiert und das Ausnahmeobjekt wird festgelegt. Dies erlaubt
es dem Kunden, die Ausnahme zu ermitteln und diese geeignet zu handhaben.
-
11 zeigt
die Situation, bei der eine Information gesendet und empfangen wird,
jedoch der Kunde zählt,
während
er wartet. Ein derartiges Szenario kann auftreten, wenn die Dauer
einer Fernoperation nicht vorhersagbar ist, oder wenn der Fern-Server
belegt ist. Natürlich
sollte der verzögerte synchrone
Mechanismus verwendet werden, wenn erwartet wird, dass eine Zählzeit auftreten
kann. Wie in 11 gezeigt ist, hat, während der
Objekt-Adapter longfoo auf dem Server X ruft, der Proxy getReplyMsg
ausgeführt,
um die Antwort vom Server abzurufen, jedoch zählt, um auf eine Antwort zu
warten. Der Proxy setzt das Ausnahmeobjekt ohne ein Auszählen, und
das Verfahren kehrt zurück.
Der Kunde prüft
das Ausnahmeobjekt 11 des Proxys, ermittelt die Ausnahme
und handhabt diese. Später
wurde longfoo beendet und liefert eine Antwort zurück, die einen
erfolgreichen Abschluss zeigt, wobei jedoch die Mitteilung durch
die Messaging-Ebene ausrangiert wird.
-
Mit
Hilfe von 12 wird eine Situation gezeigt,
bei der der Zielbetrieb nicht erkannt wird. In diesem Fall verfehlt
es der Objekt-Adapter, die Mitteilung zu interpretieren, und eine
Antwort, die dies zeigt, wird zum Proxy geliefert. Der Proxy empfängt die
Replymessage von der Mitteilungsebene, ruft die Ausnahmeinformation
ab und setzt das Ausnahmeobjekt des Proxys. Dies erlaubt es dem
Kunden, diese zu handhaben.
-
13 zeigt
die Sequenz, wenn die Serveroperation versagt. In diesem Beispiel
wird das Verfahren foo gerufen. Wenn das Verswagen auftritt, ruft das
Verfahren foo das UserException Objekt auf und setzt einen Fehlerstatus,
um den Objekt-Adapter wiederum zu veranlassen, eine Information
zu senden, die ein Benutzerebenenversagen zeigt. Der Proxy wiederum
setzt das Ausnahmeobjekt 11, um wiederum es dem Kunden
zu erlauben, das Versagen zu handhaben.
-
Wie
oben beschrieben arbeitet das Messaging-System interaktiv zwischen
einer Anwendungsebene und einer Mitteilungslieferebene. 14 zeigt
eine Situation, bei der ein Kunde einen Kartenstatus bestimmt. Der
Kunde ruft getCard auf einem Card-Proxy. Das System arbeitet wie
oben beschrieben, bis das getCard-Verfahren auf dem Serverobjekt
aufgerufen wird, welches die angeforderte Schnittstelle unterstützt. Dieses
Verfahren ruft eine C-Funktion
auf, die den aktuellen Kartenzustand zum Objekt-Adapter zurückbringt.
Dies wird wie ein Verfahren verpackt und wird zum Proxy-Objekt zurückgeliefert,
der die Information interpretiert und den Kartenzustand zum Kunden
zurückbringt.
-
15 zeigt
eine Sequenz, um den Leitungsstatus einer realen Beendigung einer
DSI-Karte (reales Übertragungsmedium)
zu bestimmen. In diesem Fall wird ein DSI-Proxy verwendet, und der
Objekt-Adapter lokalisiert das DSI-Serverobjekt und ruft dessen
getLineStatus-Verfahren auf. Der DSI-Proxy empfängt nachfolgend die Antwort.
-
16 zeigt
eine Situation, bei der eine Alarminformation und ein Verlust eines
Signals auf DSI übertragen
werden. Dies ist ein Einwegbetrieb. Die IPC-Software ermittelt einen
Verlust eines Signals auf der DS1-Leitung und ruft den Steuerungs-DS1-Proxy
auf und ruft das commsAlarmOccured-Verfahren auf dem Proxy auf,
indem es dieses zum Port-Identifizierer liefert. Nach diesem Betrieb kehrt
der Proxy zurück
ohne Antwort. Das commsAlarmOccured-Verfahren wird auf dem Steuerungs-DS1-Server
aufgerufen.
-
Das
synchrone Verzögerungsverfahren
kann zum Herunterladen von Software verwendet werden, wie in 17 gezeigt
ist. Der Kunde bildet ein ProxyOperationOn-Objekt, indem er dieses
angibt, auf der Operation startDownload zu sein. Der Kunde ruft
das Verfahren auf sendDeffered, wobei er zu diesem die erforderlichen
Parameter leitet. Nachdem die Anforderung als eine Mitteilung verpackt
ist, wird die Mitteilungshandhabung durch das ProxyOperationOn-Objekt
gespeichert, wobei dieses wiederum ReplyAvailable auf der Mitteilungsebene
ruft. Wenn keine Antwort verfügbar
ist, wird dies als falsch zurückgebracht.
Auf der Zielkarte wird die heruntergeladene Softwareaufgabe beendet
und das Ergebnis zum Objekt-Adapter zurückgebracht, der eine Antwortinformation
zurück
zur Steuerung liefert, die das Ergebnis enthält. Die Steuerung ruft wiederum
pollResponse im ProxyOperationOn-Objekt
auf, wobei diese dieses Mal als wahr zurückgebracht wird. Die Steuerung
ruft dann getResponse. Diese erlangt die zurückgebrachte Mitteilung, prüft diese
nach einem Fehlercode in der Antwort, extrahiert das Ergebnis und
liefert diese zurück
zur Steuerung. Die Steuerung prüft das
Ausnahmeobjekt, um zu sehen, ob eine Ausnahme aufgetreten ist, findet
diese jedoch gelöscht,
zeigt dies, dass das Ergebnis gültig
ist.
-
Mit
Hilfe von 18 wird schließlich die
Initialisierung einer neuen Karte gezeigt. Ein Initialisierungsverfahren
auf dem Serverobjekt wird aufgerufen und eine Folge, über welche
man sich selbst identifizieren kann, wird zum Objekt-Adapter weitergeleitet.
Die Kartensoftware verarbeitet das allgemeine Initialisierungsverfahren
(Namen-ID) in bezug auf das Serverobjekt. Das Serverobjekt speichert
die Namen ID und ruft das RegisterInterface-Verfahren in bezug auf den Objekt-Adapter
auf, und leitet dieses selbst zu diesem. Dies macht den Objekt-Adapter von
dessen Anwesenheit aufmerksam und erlaubt Anforderungen, die zu
diesem geleitet werden. Der Objekt-Adapter zeigt, ob eine Registrierung
erfolgreich war oder nicht.
-
Es
sei angemerkt, dass die Erfindung eine Realzeit-Informationsübertragung
in einer Telekommunikationssteuerung in einer Weise bereitstellt,
bei der Flexibilität
bezüglich
der Ausbildung und der Modifikation der Steuerung selbst ermöglicht werden. Dies
erlaubt beispielsweise die Hinzufügung neuer Funktionalität und außerdem die
Erweiterung von Resourcen, um existierende Funktionalität durchzuführen.
-
Die
Erfindung ist nicht auf die oben beschriebenen Ausführungsformen
beschränkt,
sondern kann bezüglich
der Konstruktion und des Details innerhalb des Rahmens der Ansprüche variiert
werden.