DE19518266A1 - Kommunikationssystem mit Mitteln zum Austausch von Software - Google Patents

Description

Die Erfindung bezieht sich auf ein Kommunikationssystem mit einer Steuer­ schaltung, welche ein Betriebssystem und Anwendersoftware und Mittel zum Austausch von Software enthält.

Kommunikationssysteme enthalten Computersysteme oder Steuerschaltungen, deren Software langlebig und praktisch dauernd verfügbar sein soll. Bei Fehlern in der Software oder auch aufgrund neuer Anforderungen müssen bestimmte Software­ komponenten erneuert werden. Dabei sollte die Ausfallzeit des Kommunikations­ systems minimiert werden.

Ein Kommunikationssystem, welches paktisch keine Ausfallzeit bei dem Austausch einer Software einer Komponente eines Vermittlungssystem aufweist, ist aus der US-A-5 155 837 bekannt. Vor dem Austausch werden zuerst die Inhalte und Zustände aller Register, Prozesse und Speichereinheiten in einem speziellen Speicher während des Betriebes der alten Software gesichert (Spalte 7, Zeilen 30 bis 36). Die alte Version der Software ist dabei in einer ersten Partition geladen. Die neue Software wird anschließend in eine zweite Partition geladen. Nachdem die neue Software geladen und getestet worden ist, werden aus dem Speicher die Inhalte und Zustände aller Register, Prozesse und Speichereinheiten auf die neue Software übertragen. Diese wird dann in Betrieb genommen. Die neue Software beginnt dabei jedoch nicht an dem Prozeßpunkt zu arbeiten, an dem die alte Software angehalten worden ist, sondern an einem definierten Programmpunkt. Es werden auch nicht einzelne Softwaremodule oder -komponenten, sondern eine in sich geschlossene Software ausgetauscht.

Der Erfindung liegt daher die Aufgabe zugrunde, Softwarekomponenten auszutauschen, bei welcher außer einer kurzen Verzögerung keine Einschränkung des Betriebes erfolgt.

Die Aufgabe wird durch ein Kommunikationssystem der eingangs genannten Art dadurch gelöst, daß das Betriebssystem zum Austausch von Nachrichten vorgesehen ist und daß eine neue geladene Softwarekomponente (Nachfolgerkomponente) zum Empfang der Zustände und der Nachrichten von einem Dienst-Port einer angehaltenen, zu ersetzenden Softwarekomponente (Vorgängerkomponente) und zum Neustart mit den übertragenen Zuständen und Nachrichten vorgesehen ist.

Die Erfindung ermöglicht den Neustart der neuen Softwarekomponente an dem Programmpunkt, an dem die alte Softwarekomponente angehalten worden ist. Außerdem werden alle Zustände der alten Softwarekomponente zur neuen Software­ komponente übertragen. Dies kann aber nur für solche Systeme gelten, die ein Betriebssystem aufweisen, welches den Austausch von Nachrichten zwischen Softwarekomponenten ermöglicht. Hierbei werden Nachrichten über Softwareschnittstellen, die im folgenden als Ports bezeichnet werden, zwischen verschiedenen Prozessen ausgetauscht. Erfindungsgemäß werden also in der alten Softwarekomponente alle Zustände und alle an einem Dienst-Port anliegenden Nachrichten eingesammelt und zur neuen Softwarekomponente übertragen. Über einen Dienst-Port empfängt die Softwarekomponente alle Nachrichten von anderen Prozessen. Die neue Softwarekomponente übernimmt die neuen Zustände, führt gegebenenfalls eine Zustandstransformation durch und startet die neue Software in dem Programmpunkt der neuen Softwarekomponente, der dem der alten Software­ komponente entspricht.

Der Austausch einer Softwarekomponente erfolgt dabei so, daß keine andere Softwarekomponente davon berührt wird. Die von einer anderen Softwarekomponente eintreffenden Nachrichten werden nämlich auf die neue Softwarekomponente übertragen und nach dem Austausch weiterverarbeitet. Der Austausch erfolgt dabei so, daß nur eine kurze Verzögerung bei der Bearbeitung entsteht. Praktische Untersuchungen haben ergeben, daß die Verzögerungszeit im Bereich weniger Millisekunden liegt.

Ein Kommunikationssystem kann ein Computersystem sein, eine Vermittlungsstelle, ein Computernetzwerk oder auch Serversysteme, wie z. B. ein Vide-On-Demand- Server. Ein Computersystem enthält wenigstens einen Computer, in dem eine Softwarekomponente ausgetauscht werden soll.

Eine Softwarekomponente oder ein Prozeß enthält genau einen Thread. Ein Thread ist ein in sich selbst sequentiell ablaufendes Programmstück. Der Thread weist einen ersten Teil zur Übernahme und geeigneten Umsetzung der Zustände und Nachrichten des Dienst-Ports einer alten Softwarekomponente und einen zweiten Teil zum Einsammeln der Zustände des Prozesses und der Nachrichten des Dienst- Ports auf.

Der Austausch einer Softwarekomponente wird von einem Austauschmanager gesteuert, welcher zum Laden und Starten einer Softwarekomponente vorgesehen ist.

Die neue Softwarekomponente kann dabei von einer Wartungsvorrichtung an den Austauschmanager geliefert worden sein, an der auch neue Softwarekomponenten entwickelt werden können. Als Übertragungsmedium kann beispielsweise das Telefonnetz dienen.

Ausführungsbeispiele der Erfindung werden nachstehend anhand der Figuren näher erläutert. Es zeigen:

Fig. 1 ein Computersystem mit einer Wartungsvorrichtung und einem Computer, der austauschbare Softwarekomponenten enthält,

Fig. 2 den Nachrichtenfluß zwischen dem Austauschmanager, einer neuen und alten Softwarekomponente,

Fig. 3 ein Vermittlungssystem mit einer Wartungsvorrichtung und einer Steuerschaltung, die austauschbare Softwarekomponenten enthält,

Fig. 4 ein Zustandsdiagramm einer nicht austauschbaren Software­ komponente und

Fig. 5 ein Zustandsdiagramm einer austauschbaren Softwarekomponente.

In Fig. 1 ist ein Computersystem mit einem Computer 1 und einer Wartungs­ vorrichtung 2 dargestellt. Der Computer enthält Hardwarekomponenten 3, ein Betriebssystem 4, Anwendersoftware 5 und einen Austauschmanager 11. Das Betriebssystem 4 muß eine Kommunikation zwischen Softwarekomponenten der Anwendersoftware 5 über Nachrichten ermöglichen (z. B. nachrichtenorientiertes Betriebssystem (message based operating system)). Die Nachrichten oder Daten werden dabei über Softwareschnittstellen ausgetauscht. Im folgenden wird eine Softwareschnittstellen als Port bezeichnet.

Der Austauschmanager 11 ist eine Softwareprogramm, mit dessen Hilfe Kompo­ nenten der Anwendersoftware 5 ausgetauscht werden können. In der Fig. 1 sind die einzelnen Softwarekomponenten durch Kreise dargestellt. Die Verbindungen zwischen den Kreisen sollen Nachrichtenflüsse zwischen den Softwarekomponenten andeuten.

Die Wartungsvorrichtungsvorrichtung 2 könnte ein entfernt liegender Computer sein, von dem aus eine neue Softwarekomponente geliefert wird. Hierbei ist es denkbar, daß die neue Softwarekomponente an diesem Computer entwickelt und getestet wird. Zur Übertragung der neuen Softwarekomponente können bekannte Übertragungs­ medien und Protokolle verwendet werden. Beispielsweise ist eine Übertragung über ein Telefonnetz möglich. Die neue Softwarekomponente könnte aber auch direkt in den Computer 1 geladen werden (z. B. mit Hilfe einer lokalen Wartungsvorrichtung (Laptop).

Der Austauschmanager 11 lädt die neue Softwarekomponente in den Computer 1 und startet sie dort. Die neue Komponente meldet sich bei dem Austausch­ manager 11 an und bekommt mitgeteilt, ob sie eine existierende alte Komponente ersetzen soll. Falls das der Fall ist, sendet die neue Komponente, die eine Nachfolgerkomponente darstellt, einen Austauschbefehl (request) an die alte Komponente, die eine Vorgängerkomponente darstellt. Die Vorgängerkomponente sammelt ihre Zustandsinformationen und überträgt diesen Zustand zur Nachfolgerkomponente. Außerdem meldet die Vorgängerkomponente dem Austauschmanager 11, daß sie gestoppt hat. Danach setzt die Nachfolgerkomponente die Arbeit exakt an der Stelle fort, an der die Vorgängerkomponente gestoppt wurde. Damit dieser Austausch, ohne daß der Computer außer Betrieb genommen wird, durchgeführt werden kann, sind in den Komponenten der Anwendersoftware noch bestimmte Veränderungen gegenüber nicht austauschbaren Komponenten vorgenommen worden.

Wie oben erwähnt müssen die Softwarekomponenten, welche austauschbar sein sollen, gegenüber konventionellen Softwarekomponenten Erweiterungen besitzen. Eine Softwarekomponente weist genau einen Thread auf, der einen Dienst-Port für den Empfang von Nachrichten (messages) von einem Klienten und einen Teil zur Antwort auf die Nachrichten an einen Klienten aufweist. Ein Thread ist ein in sich selbst sequentiell ablaufendes Programmstück. Ein Klient ist eine andere Softwarekomponente (Prozeß). Damit eine Softwarekomponente austauschbar wird, muß sie einen Austausch-Punkt bzw. Restart-Punkt im Thread aufweisen. In der Regel sind der Austausch-Punkt und der Restart-Punkt identisch.

In Fig. 2 ist schematisch der Nachrichtenfluß zwischen dem Austauschmanager 11 (hier als AM bezeichnet), der Vorgängerkomponente VK und der Nachfolger­ komponente NK dargestellt. Nachdem die neue Komponente NK vom Austauschmanager gestartet worden ist (Pfeil ST), werden von dieser bestimmte Informationen geholt (Punkt P1). Die Vorgängerkomponente VK ermöglicht am Punkt P2 die Erfüllung ihrer Aufgaben, d. h. z. B. die Bearbeitung externer, anliegender Nachrichten. Die Nachfolgerkomponente NK meldet sich dann beim Austauschmanager 11 (AM) an (Pfeil AN), der anschließend der Nachfolger­ komponente NK den Befehl zum Austausch der Komponenten gibt (Pfeil EX1). Dieser Befehl wird von der Nachfolgerkomponente NK weiter an die Vorgänger­ komponente VK gegeben (Pfeil EX2). Daraufhin sammelt die Vorgängerkomponente VK ihren Zustand (Punkt P3) und liefert diesen an die Nachfolgerkomponente NK (Pfeil ZU). Die Nachfolgerkomponente NK rekonstruiert aus den empfangenen Zuständen die Objekte und führt gegebenenfalls eine Zustandstransformation durch. Alle Nachrichten die während des Austauschvorgangs für einen Dienst-Port der Vorgängerkomponente VK bestimmt waren, werden dadurch zum Dienst-Port der Nachfolgerkomponente NK gegeben. Anschließend meldet die Vorgängerkomponente VK dem Austauschmanager 11 (AM), daß sie gestoppt hat (Pfeil VG) und löscht sich (Punkt P4). Die neue Komponente NK übernimmt danach die Bearbeitung der externe Nachrichten (Punkt P5).

Der Computer 1 könnte beispielsweise auch ein Server in einem Computernetzwerk sein. Eine weitere Anwendungsmöglichkeit besteht für Systeme, welche zur Übertragung von Nachrichten vorgesehen sind. Ein Beispiel ist ein Vermittlungs­ system, deren wesentliche Blöcke in Fig. 3 gezeigt sind. Das Vermittlungssystem enthält ein Koppelfeld 6 welches auf Eingangsleitungen 7 empfangene Signale an eine oder mehrere Ausgangsleitungen 8 weitergibt. Zur Steuerung des Koppelfeldes dient eine Steuerschaltung 9, die außer den notwendigen Hardwarebestandteilen ein Betriebssystem, Anwendersoftware und einen Austauschmanager enthält. Zum Austausch von Komponenten der Anwendersoftware ist eine Wartungsvorrichtung 10 vorgesehen, die mit der Steuerschaltung 9 auf dieselbe Weise wie die Wartungs­ vorrichtung 2 mit dem Computer 1 zusammenarbeitet.

Anhand eines in der Programmiersprache C++ geschriebenen Prozesses soll im folgenden etwas detaillierter der Aufbau einer austauschbaren Softwarekomponente erläutert werden. Zuerst wird der konventionelle Aufbau des Prozesses ohne die für den Austausch notwendigen, erfindungsgemäßen Maßnahmen beschrieben. Der Prozeß ermöglicht mittels Spracheingaben ein Telefonbuch zu verwalten. Der Telefonbuch-Prozeß stellt anderen Prozessen drei Methoden zur Verfügung. Das ist erstens das Hinzufügen eines Eintrages zum Telefonbuch, zweitens das Löschen eines Eintrages aus dem Telefonbuch und drittens das Ermitteln eines Eintrages aus vorgegebenen Sprachdaten. Ein Prozeß liefert dazu dem Telefonbuch-Prozeß eine Nachricht, aus der die entsprechende gewünschte Methode herausgefunden wird. Die Implementation des Telefonbuch-Prozesses ist im folgenden aufgeführt:

Bei der oben dargestellten Implementation sind nur die Deklarationen aufgeführt, welche zum Verständnis des Telefonbuch-Prozesses erforderlich sind. Das Programm enthält zur Bezugnahme Abschnittsnummern, welche nicht Bestandteil des Programmtextes sind. Einzelne Programmabschnitte werden jeweils durch vorangestellte, in Klammern angegebene Zahlen gekennzeichnet.

In den Abschnitten (1) und (3) sind Importe und Deklarationen von Klassen von Objekten enthalten, die im Telefonbuch-Prozeß verwendet werden. In dem Ab­ schnitt (1) werden einige Bibliotheken (Headerdateien) in den Prozeß eingebunden, die verschiedene weitere Klassen zur Verfügung stellen. Die jeweilige Bedeutung der einzelnen Bibliotheken ist in den Kommentarzeilen erläutert.

Abschnitt (3) zeigt die Definition einer internen Telefonbuch-Klasse "PhoneBook". Die Implementationen für "Enter", "Remove" und "Give" sind nicht im einzelnen aufgeführt. Die Methode "Enter" erlaubt das Einfügen eines Namens mit Telefonnummer und Sprachreferenz (Sprachprobe) in das Telefonbuch, die Methode "Remove" erlaubt das Löschen eines durch den Namen referenzierten Eintrages aus dem Telefonbuch und die Methode "Give" ermöglicht das Finden eines Eintrages im Telefonbuch der auf einer Sprachreferenz basiert. In diesem Fall sucht jemand also Einträge unter einen Namen, den er sprachlich vorgibt. Die Methoden "Enter", "Remove" und "Give" erhalten und übergeben jeweils die in den Klammern zu den jeweiligen Methoden angegebenen Parameter.

In Abschnitt (8) sind die Methoden aufgeführt, die der Telefonbuch-Prozeß anderen Prozessen zur Verfügung stellt. In Abschnitt (9) ist der Port (Dienst-Port) definiert, über den die Methodenaufrufe von anderen Prozessen an das Telefonbuch erfolgen.

Ein Port dient zur Versendung von Nachrichten an andere Prozesse. In Abschnitt (9) wird auch das Telefonbuch-Objekt "PhoneBook" deklariert, das ebenso wie die vorherige Port-Deklaration den Zustand des Softwareobjektes bildet. Das Objekt "PhoneBook" verwaltet alle relevanten Daten des Telefonbuchs.

In den Abschnitt (10) bis (16) wird die Hauptfunktion des Telefonbuch-Prozesses angegeben. Diese Funktion wird als Thread ausgeführt. Der Thread besteht aus einen Initialisierungsteil im Abschnitt (13) und einer Endlosschleife (ab Ab­ schnitt (14)), in der Methodenaufrufe empfangen werden (Abschnitt (15)) und in der die Methodenaufrufe ausgeführt werden (Abschnitt (16)). Im Initialisierungsteil im Abschnitt (13) wird der Anfangszustand des Softwareobjektes gesetzt. In der Schleife, die mit Abschnitt (14) beginnt, wird auf eine Anforderung gewartet. Falls eine Nachricht von dem Dienst-Port empfangen worden ist (Abschnitt (15)) wird diese im Puffer "message" abgelegt. Die Nachricht enthält immer zuerst den Typ der aufgerufenen Methode und je nach Methode noch zusätzliche Parameter. In Abhängigkeit vom Typ (Request) wird entweder zur Methode "Enter", zur Methode "Remove" oder zur Methode "Give" gesprungen. Die Methode "Enter" fügt in das Telefonbuch-Objekt "phoneBook" den Namen, die Telefonnummer und eine Sprachreferenz ein. Die Methode "Remove" entfernt aus dem Telefonbuch-Objekt "phoneBook" den Namen mit den entsprechenden Eintragungen. Für die Methode "Give" wird z. B. noch eine Sprachreferenz übermittelt, die in eine Variable "reference" vom Typ "AudioData" abgelegt wird. Über einen Aufruf der Methode "Give" des internen Objekts "phoneBook" werden dazu ein Nutzername "name" und eine Telefonnummer "phoneNumber" ermittelt und mittels des Befehls "reply" an den Klienten gesendet, der nach der entsprechenden Telefonnummer gefragt hat. In Abschnitt (18) ist eine Deklaration aufgeführt, durch die der Thread instantiiert, mit der die Funktion "phoneBookService" verbunden und gestartet wird. Die Funktion "phoneBookService" beginnt ab Abschnitt (10).

Der Ablauf des Threads kann durch das in der Fig. 4 dargestellte Zustandsdiagramm noch weiter veranschaulicht werden. Block 23 bezeichnet den Zustand (Zustand L, loaded), in den das gesamte Softwareobjekt von dem Austauschmanager 11 in den Arbeitsspeicher des Computers 1 oder der Steuerschaltung 9 geladen wurde. Nach der Initialisierung tritt der Thread in einen Initialisierungszustand (Zustand I, initialized), was der Block 24 angibt. Der nächste Zustand RAC (running application code) zeigt die eigentliche Ausführung des Threads (Block 25) und wird im Programm durch die Abschnitte (14) bis (16) beschrieben. Der Zustand RAC weist weitere Unterzustände WFR (Block 26, waiting for requests), ME (Block 27, processing "enter"), MR (Block 28, processing "remove") und MG (Block 29, processing "give") auf. Der Pfeil mit dem Punkt auf der linken Seite des Blockes 26 kennzeichnet den Unterzustand, der eingenommen wird, wenn das Programm in den übergeordneten Zustand eintritt. Im konkreten Beispiel heißt das, daß der Zustand RAC immer mit dem Unterzustand WFR beginnt. Im Zustand WFR wird auf Nachrichten gewartet. Nach Eintreffen einer Nachricht wird in einen der Zustände ME, MR oder MG gesprungen. Diese Zustände korrespondieren mit der Ausführung der Methoden "Enter", "Remove" und "Give". Nach Beenden einer der Methoden wird in den Zustand WFR zurückgesprungen.

Um den Austausch einer Softwarekomponente durchzuführen, ist der oben dargestellte Telefonbuch-Prozeß durch weitere Deklarationen zu erweitern. Diese zusätzlichen Abschnitte und die schon oben beschriebenen Abschnitte des Telefonbuch-Prozesses sind im folgenden aufgeführt:

Der oben gezeigte Programmablauf ist für den Fall vorgesehen, daß diese Software­ komponente eine andere (Vorgängerkomponente) ersetzen soll, und für den anderen Fall, daß diese Softwarekomponente durch eine andere neue Softwarekomponente (Nachfolgerkomponente) ersetzt wird. Die Softwarekomponente, welche die erfindungsgemäßen Maßnahmen enthält, verwendet ein zusätzliches Modul "exchange.hxx" (Abschnitt (2)), das zwei Methoden "getExcInfo" und "setExcInfo" zur Verfügung stellt. Die Methode "getExcInfo" stellt die Zustandsinformationen der zu ersetzenden Komponente der neuen Komponente zur Verfügung. Demgegenüber übergibt die Methode "setExcInfo" Zustandsinformationen der aktuellen Komponente an eine sie ersetzende neue Komponente. Jeder Thread ruft also zu Beginn seiner Abarbeitung genau einmal die Methode "getExcInfo" und beendet seine Abarbeitung mit "setExcInfo" (vgl. die unten aufgeführten Programmabläufe).

Die Deklarationen im Abschnitt (3) werden um zusätzliche Methodenaufrufe erweitert, die in den auf den Abschnitt (3) folgenden Abschnitten (4) und (5) aufgeführt sind. Prinzipiell werden alle internen Objekte, soweit noch nicht vorhanden, um zwei weitere Methoden erweitert. Eine Methode ist erforderlich, um den neuen Zustand des Objektes der Nachfolgerkomponente aus dem Zustand eines ähnlichen Objektes der Vorgängerkomponente zu konstruieren (Abschnitt (4)) und eine weitere Methode, um den Zustand der Vorgängerkomponente in eine als Nachricht versendbare Form zu verpacken (Abschnitt (5)). Es wird der Methodenaufruf "PhoneBook (Bin buf)" verwendet, der ein Objekt aus einem Pufferabbild konstruiert (Abschnitt (4)). Dieser Methodenaufruf wird benötigt, wenn die beschriebene Softwarekomponente den Zustand ihres internen Objektes "phoneBook" aus dem übertragenen Zustand vom "phoneBook" der Vorgänger­ komponente gewinnt. Zusätzlich wird in Abschnitt (5) eine Methode aufgerufen, die das Ablegen des Objektzustandes in einen Puffer erlaubt. Diese Methode ist erforderlich, wenn die hier beschriebene Softwarekomponente (Vorgängerkompo­ nente) den Zustand ihres internen Objektes "phoneBook" an eine Nachfolger­ komponente übertragen möchte.

Prinzipiell ist es zulässig, daß die internen Objekte einer Nachfolgerkomponente nicht identisch mit den internen Objekten der zu ersetzenden Komponente (Vorgängerkomponente) sind. In dem Ausführungsbeispiel soll das für das interne Objekt "phoneBook" der Fall sein. Gelöst wird diese Inkompatibilität durch die Bereitstellung einer Transferfunktion "stateTransformation" (Abschnitt (7)). Diese Funktion muß in der Lage sein, den alten Typ "OldPhoneBook" (Abschnitt (6)) des internen Objektes "phoneBook" in seine neue Repräsentation umzuwandeln. Das erfolgt unmittelbar, nachdem der Zustand der alten Objekte empfangen wurde (siehe Abschnitt (12)).

Der Abschnitt (8) gibt einen vom Objekt bereitgestellten weiteren Dienst an. Dieser Dienst "exchange" ermöglicht den Austausch der Softwarekomponente.

Der Thread des Telefonbuchprozesses enthält zwei zusätzliche Programmteile. Einer ist für die Übernahme der Zustände von einer Vorgängerkomponente und der andere Teile für die Übergabe der Zustände an eine Nachfolgerkomponente verantwortlich. Ob eine Vorgängerkomponente existiert wird mittels der Methode "getExcInfo" (siehe unten) ermittelt. Existiert eine solche, dann übermittelt "getExcInfo" auch den Zustand der Vorgängerkomponente. Dieser wird zur Rekonstruktion der internen Objekte "phoneBookEntry" und "phoneBook" benutzt (Abschnitt (12)). Existiert keine Vorgängerkomponente, dann wird die Komponente ganz normal gestartet (Abschnitt (13)). Das Erzeugen des neuen Dienst-Ports wird mit den Anweisungen in den Abschnitten (12) und (13) realisiert. Alle noch nicht abgearbeiteten Nachrichten des Dienst-Ports der alten Softwarekomponente sind Bestandteil von diesem Zustand und werden übergeben. Weiter wird im Abschnitt (12) der alte Zustand des Telefonbuches aus dem Puffer "state" extrahiert und in der Variablen "oldPhoneBook" abgelegt. Die oben beschriebene Zustandstransferfunktion, die den Zustand eines alten Telefonbuches in den Zustand eines neuen Telefonbuches abbildet, wird in Abschnitt (12) angewendet. Ein solcher Transfer ist beispielsweise erforderlich, wenn ein neues Feld "Postleitzahlen" hinzukommt oder dieses Feld einen anderen Typ erhält (z. B. 5 anstatt 4 Zeichen).

Der zweite neue Programmteil (Abschnitt (17)) realisiert den für den Austausch der Komponente gegen eine Nachfolgerkomponente notwendigen Dienst "Exchange". Zuerst wird in Abschnitt (17) der augenblickliche Zustand der alten Software­ komponente (Vorgängerkomponente) in einem Puffer "state" abgelegt. Es werden z. B. der Zustand einschließlich der Nachrichten des Dienst-Ports "phoneBookEntry" in dem Puffer "state" gespeichert. Der in dem Puffer "state" abgelegte Zustand der alten Softwarekomponente wird mittels "setExcInfo" an die neu einzusetzende Softwarekomponente (Nachfolgerkomponente) gesendet. Die Methode "setExcInfo" bricht gleichzeitig die Softwarekomponente ab.

Der Ablauf des Threads in der Softwarekomponente mit den erfindungsgemäßen Maßnahmen kann ebenfalls durch ein Zustandsdiagramm beschrieben werden, welches in der Fig. 5 gezeigt ist. Alle Zustände, die mit denen in der Fig. 4 identisch sind, weisen dieselben Bezeichnungen auf. Der Zustand RS (Block 30, receiving state) gibt den Zustand nach einem Neustart der Softwarekomponente an, bei der auf die Übertragung des Zustandes der alten Komponente gewartet wird. Erhält die Softwarekomponente am Ende ihrer Lebensdauer dann selbst ein Austauschsignal, wechselt sie in den Zustand CS (Block 31, collecting state). In diesem Zustand sammelt sie die Zustände ihrer internen Objekte. Der Zustand TS (Block 32, transferring state) gibt die Übertragung der Zustände von der alten auf die neue Softwarekomponente an. Das Beenden einer alten Softwarekomponente wird durch den Zustand TE (Block 33, terminated) angegeben.

Das Modul "exchange.hxx", welches die Methoden "getExcInfo" und "setExcInfo" definiert, wird im folgenden aufgelistet:

In Abschnitt (1) wird ein Symbol "FLYER-EXCHANGE" getestet und, falls es nicht definiert ist, gesetzt. Das verhindert das mehrfache Inkludieren (Einfügen) dieses Moduls. Abschnitt (2) inkludiert die Definition der Klasse "bin". Die Methode "getExcInfo", welche die Zustandinformationen für die Nachfolger­ komponente liefert, wird in Abschnitt (3) definiert. Die Methode besitzt die Parameter "portName", "excReqCode", "maxState", "state" und "return". "portName" gibt den Namen des Ports an, über den die Leistungen dieser Softwarekomponente in Anspruch genommen werden. "excReqCode" ist ein Anforderungskode, der zur Einleitung des Austauschvorganges an die alte, zu ersetzende Softwarekomponente gesendet werden soll. Die maximale Größe des erwarteten Zustandes in Byte gibt "maxState" an. In "state" wird der zu über­ tragende Zustand des Threads abgelegt. Der Rückkehrwert der Funktion "getExcInfo" ist gleich 0 (FALSE), falls kein Austausch stattfinden soll, d. h. falls die Komponente einfach nur neu gestartet werden soll.

In Abschnitt (4) wird die Methode definiert, welche die Zustandsinformationen des alten Threads der Vorgängerkomponente, die in "state" abgelegt sind, an die Nachfolgerkomponente überbringt. Die Funktion "setExcInfo" kehrt nicht zurück. Der aufrufende Thread wird gelöscht.

Das Modul "exchange.cxx", dessen Programmablauf unten dargestellt ist, beinhaltet die Implementierung der in dem Modul "exchange.hxx" beschriebenen Schnittstelle:

Abschnitt (1) enthält Importe bzw. Deklarationen verwendeter Klassen. So stellt z. B. "excstub_.hxx" eine Schnittstelle zum Austauschmanager 11 zur Verfügung.

Abschnitt (2) definiert die Konstanten "False" und "True".

Abschnitt (3) deklariert ein Objekt "excStub", über das der Austauschmanager 11 angesprochen wird. Abschnitt (4) deklariert ein String-Objekt, das lediglich zum Informationstransfer (Namenstransfer) zwischen "getExcInfo" und "setExcInfo" benutzt wird.

Im Abschnitt (5) beginnt die Implementation der Methode "getExcInfo". Im Abschnitt (6) meldet sich die Softwarekomponente beim Austauschmanager 11 an und erfährt, ob sie neu gestartet wird oder ob sie eine existierende Komponente (Vorgängerkomponente) ersetzen soll.

Soll eine Vorgängerkomponente ersetzt werden, so wird im Abschnitt (7) ein Referenz-Port geschaffen, der den Dienst-Port der zu ersetzenden Komponente referenziert. Der Vorgängerkomponente wird nun ein Austauschbefehl mittels "servicePort.call" gesendet. Sie schickt daraufhin ihren Zustand zurück, der in "state" abgespeichert und als Parameter "state" von "getExcInfo" übergeben wird.

Abschnitt (8) enthält die Implementierung von "setExcInfo". Dabei wird zuerst der eingesammelte Zustand "state" an den Sender des Austauschbefehls zurückgeschickt ("reply(state)"). Dann wird der Austauschmanager 11 informiert, daß die Softwarekomponente (Vorgängerkomponente) gestoppt hat ("excStub.stopped(servicePortName)") und die Softwarekomponente löscht sich selbst.

Claims (6)

1. Kommunikationssystem mit einer Steuerschaltung (3, 9), welche ein Betriebssystem (4) und Anwendersoftware (5) und Mittel (11) zum Austausch von Software enthält, dadurch gekennzeichnet, daß das Betriebssystem (4) zum Austausch von Nachrichten vorgesehen ist und daß eine neue geladene Softwarekomponente (Nachfolgerkomponente) zum Empfang der Zustände und der Nachrichten von einem Dienst-Port einer angehaltenen, zu ersetzenden Softwarekomponente (Vorgängerkomponente) und zum Neustart mit den übertragenen Zuständen und Nachrichten vorgesehen ist.

2. Kommunikationssystem nach Anspruch 1, dadurch gekennzeichnet, daß eine austauschbare Softwarekomponente einen Thread enthält und daß der Thread einen ersten Teil zur Übernahme und geeigneten Umsetzung der Zustände und Nachrichten des Dienst-Ports einer alten Softwarekomponente und einen zweiten Teil zum Einsammeln der Zustände des Prozesses und der Nachrichten des Dienst-Ports enthält.

3. Kommunikationssystem nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß ein Austauschmanager (11) zum Laden und Starten einer Softwarekomponente vorgesehen ist.

4. Kommunikationssystem nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, daß eine Wartungsvorrichtung (2, 10) zur Lieferung einer neuen Software­ komponente über ein Übertragungsmedium an den Austauschmanager (11) vorgesehen ist.

5. Kommunikationssystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß bei einer veränderten Struktur der Nachfolgerkomponente zur Vorgängerkomponente die Nachfolgerkomponente zur Durchführung einer Zustandstransformation vorgesehen ist.

6. Computersystem mit wenigstens einem Computer (1), welcher ein Betriebs­ system (4) und Anwendersoftware (5) und Mittel (11) zum Austausch von Software enthält, dadurch gekennzeichnet, daß das Betriebssystem zum Austausch von Nachrichten vorgesehen ist und daß eine neue geladene Softwarekomponente (Nachfolgerkomponente) zum Empfang der Zustände und der Nachrichten von einem Dienst-Port einer angehaltenen, zu ersetzenden Softwarekomponente (Vorgängerkomponente) und zum Neustart mit den übertragenen Zuständen und Nachrichten vorgesehen ist.