DE60119553T2

DE60119553T2 - Multiplexingeinheit, system und verfahren für die kommunikation über ein rechner-netzwerk

Info

Publication number: DE60119553T2
Application number: DE60119553T
Authority: DE
Inventors: Pierre Dor; Alexis Grandemange; Vincent Lextrait; Veronique Marquion; Francois Weissert
Original assignee: Amadeus SAS
Current assignee: Amadeus SAS
Priority date: 2000-10-02
Filing date: 2001-10-02
Publication date: 2007-05-03
Anticipated expiration: 2021-10-03
Also published as: US20040062255A1; FR2814827B1; DE60119553D1; ES2264990T3; ATE326107T1; EP1323277A1; FR2814827A1; NZ525036A; WO2002030085A1; US7428596B2; AU2001295650B2; AU9565001A; EP1323277B1

Description

Die vorliegende Erfindung betrifft eine Multiplexeinheit zur Kommunikation in einem Computernetz zwischen einer Vielzahl von Client-Rechnern, die Client-Programme unterstützen, und einem oder mehreren Servern, die Anwendungsprogramme unterstützen, wobei die Client- und Anwendungsprogramme inkompatibel sein können.
Sie betrifft auch ein Kommunikationssystem, das eine oder mehrere solcher Einheiten integriert, sowie ein Verfahren, das es umsetzen kann.
Die Erfindung findet vor allem Anwendung auf dem Gebiet der Reservierung von Reisen oder Transporten über EDV-Systeme.
Solche Systeme, allgemein als CRS (Computerized Reservation Systems) bezeichnet, benutzen Mitteilungen durch Computernetze, um Kunden (wie Angestellte in der Reisebranche oder Privatpersonen) mit den zentralen Diensten der von den Reservierungen betroffenen Unternehmen in Verbindung zu setzen.
Diese Systeme setzen sehr unterschiedliche Bestandteile ein, wie Server, Terminals von Computern, individuelle EDV-Arbeitsplätze, und dies durch verschiedene Verbindungen, oft kombinierte, bestehend aus örtlichen oder Weltnetzen.
Diese Heterogenität findet sich auch bei den Formaten der Daten und Kommunikationsprotokolle wieder. Wenn auch bestimmte Protokolle wie die Kombination HTTP/HTML genügend standardisiert sind, um Kompatibilitätsprobleme zu begrenzen, erfordern andere wie IIOP oder JRMP, dass die Teile sich auf gemein same Schnittstellen einigen, auch wenn die Art, es auf einem Netz darzustellen, standardisiert ist.
Es besteht somit ein wichtiger Bedarf, den Betriebs- und Kommunikationsmodus in den EDV-Systemen wie oben beschrieben zu rationalisieren.
Diesbezüglich werden Multiplex-Vorrichtungen derzeit in mehreren Varianten vorgeschlagen. Sie sichern insgesamt eine Zentralisierung der Verbindungen und eine Reduzierung der Zahl der für die Zuführung der Daten notwendigen Verbindungen.
Sie sind jedoch nicht vollständig zufriedenstellend. So haben sie Reaktionszeitprobleme oder sie sind, wenn sie in der Nähe einer Gruppe von Maschinen angelegt werden, umständlich zu bedienen.
Außerdem ist es schwer, eine große Zahl von Clients zu verwalten: die Server müssen mehrere Versionen der Anwendungen unterstützen, um den Anforderungen von Clients nachzukommen, deren Software auf verschiedenen Aktualisierungsstufen ist.
Ein anderer Nachteil der derzeitigen Systeme ist, dass ihre Verwendung nicht geschmeidig ist, vor allem bezüglich der Lastaufteilung zwischen den Servern, der Fehlerbehebung und bei eventuellen Überlastungen.
Lösungen für die erwähnten Probleme sind vorgeschlagen worden, wie die Verwendung von Middleware.
Es handelt sich um Software, die eine Vermittlerfunktion zwischen einem Client-Teil und einem Server-Teil des Systems hat.
Ihre Verwendung bringt jedoch schwerwiegende Anpassungen der Anwendungen mit sich. Sie haben daher negative Auswirkungen auf die Entwicklungszeiten und -kosten. Dieser Nachteil ist umso bedeutender, als die Middleware auch verlegt werden muss, was die Gefahren der Nichtkompatibilität steigert und die Verwaltungsaufgaben verkompliziert.
Auf dem Gebiet der Vereinbarkeit der in den EDV-Systemen eingesetzten Anwendungen bieten die Multiplexmittel und die derzeit bekannte Middleware keine spezifische Lösung.
Dabei ist aus dem Dokument WO-A-99/44155 eine Vorrichtung zur Datenkonvertierung und aufgeteilten Auslastung in einem Computernetz bekannt. Gemäß diesem Dokument erfolgt systematisch eine Konvertierung der Daten in ein festes Format, um ihre Behandlung zu erleichtern. Ein Serverzuweisungssystem zu bestimmten Clients und eine Verwaltung ihres Engpasses wird ebenfalls vorgestellt.
Dieses System ist statisch und gestattet es nicht, den Server je nach dem Inhalt der Client-Mitteilungen zu wählen.
Diese Vorrichtung ist eindeutig auf den Gebrauch eines einzigen Protokolls hin gerichtet, nämlich EDIFACT. Sie versucht nicht, eine vollständige Kompatibilität zu sichern, egal welche Formate und Protokolle ein gegebener Server verwendet.
Außerdem beschränkt sich die vorgeschlagene aufgeteilte Auslastung auf Einzelsituationen und versucht nicht, die Aktivität der Server insgesamt zu verwalten. Außerdem ist dieses System nicht modular, was seine Entwicklungsfähigkeit behindert, und der Weg der Mitteilungen besteht aus zahlreichen Etappen, die die Antwortzeit des Netzes negativ beeinflussen.
Der Mechanismus ist in dem Code der Clients und Server verwirklicht, die somit abgewandelt werden müssen, um ihn in die Praxis umzusetzen.
Das Dokument WO-A-00/28433 zeigt eine Multiplex-Schnittstelle zwischen Clients und Servern in einem Kommunikationsnetz à la Internet. Die vorgeschlagene Schnittstelleneinheit ist einerseits mit einer Vielzahl von Clients und andererseits mit einer Vielzahl von Servern verbunden. Die Schnittstelle öffnet die Verbindungen mit den Servern, hält sie aufrecht und sichert die Verbindung mit den Clients. Dieses Dokument offenbart eine vollständige Zentralisierung der Kommunikation in Richtung auf ein System, das nicht zwischen den Arten von Clients und den Arten von Servern unterscheidet. Dieses System sichert nur ein dynamisches Routing in Abhängigkeit von den Daten der ausgetauschten Mitteilungen.
Das Dokument US-A-5,951,694 zeigt ein Netz von Online-Diensten mit Verbindung von verschiedenen Client-Rechnern und von verschiedenen Servern über ein Netz von großer Ausdehnung und über Kommunikationsportale. Dieses System ist speziell mit der Durchführung und dem Betrieb der Portale für eine gleichzeitige Verbindung der Clients mit den Servern vorgesehen. Die Verwaltung des Routings ist somit spezifisch dynamisch.
Das Dokument US-A-5,799,173 beschreibt ein Verfahren, um den Betrieb einer Vielzahl von Servern als Antwort auf Anfragen dynamisch zu kontrollieren. Dieses Dokument bezieht sich im Wesentlichen auf die Optimierung der Bearbeitung der Anfragen auf Höhe der Server statt der Bildung einer homogenen Einheit zur Konvertierung und zum Routing. Diese Entgegenhaltung zeigt im Wesentlichen eine Möglichkeit zur aufgeteilten Auslastung durch die Schaffung von Reihen auf Höhe der Server.
Die Offenbarung DLLaGator Version 2.3General Availability bezieht sich auf ein EDV-Produkt ohne Bezug auf den Kommunikationsbereich in einem Computernetz zwischen einer Vielzahl von Client-Rechnern, die Client-Programme unterstützen, und mehreren Servern, die Anwendungsprogramme unterstützen.
Man kennt auch aus dem Dokument EP-A-0 969 367 ein Aufgabenverwaltungssystem zwischen Subsystemen eines EDV-Systems. Dieses Dokument ist speziell auf einen besonderen Durchführungsmodus der aufgeteilten Auslastung in dem EDV-System konzentriert. Es zeigt keine allgemeine Einheit zum Multiplexbetrieb mit der besonderen Vorrichtung zur Konvertierung und zum Routing von jeder Anfrage in dem Computernetz.
Man kennt ebenfalls aus der Offenbarung der Herren SCHIEMANN und BORMAN mit dem Titel „A new approach for load balancing in high-performance decision support systems" eine besondere Vorrichtung, um die aufgeteilte Auslastung in einem EDV- System mit spezifischen Mitteln für die parallele Verwaltung einer Vielzahl von Aufgaben zu sichern.
Schließlich kennt man aus dem Dokument WO-A-00/46683 einen Apparat und eine Methode zur Datenkonvertierung in einem Computernetz, bei denen die Daten verschiedener Art systematisch in ein einheitliches Format konvertiert werden. Die Daten werden außerdem zwischen verschiedenen Servern und Clients mittels klassischer Routing-Mittel geleitet und nicht modular.
Die hier vorgeschlagene Erfindung hat zum Ziel, die Nachteile der bisher bekannten Techniken zu beheben.
Eine ihrer Hauptaufgaben ist eine wirksame Konvertierung der Mitteilungen, um sie mit jedweder Zielanwendung kompatibel zu machen. Die Erfindung gestattet somit eine Kommunikation zwischen allen Komponenten des Netzes.
Sie gestattet gleichzeitig, den Multiplexbetrieb der Daten unter Einsatz der Ein- und Ausgangsverwaltungsmodule zu organisieren die leicht von einem Verwaltungsorgan kontrolliert werden: zum Beispiel die Integration einer neuen Art von Client in dem System erfolgt schnell durch die Schaffung eines neuen Eingangsverwaltungsmoduls. Clients, die dasselbe Protokoll benutzen, und unter denselben Bedingungen, können sich dasselbe Eingangsverwaltungsmodul teilen. Man sieht, dass die hier dargestellte Erfindung Modularität und Anpassungsfähigkeit an die strukturelle oder funktionale Evolution des Netzes bietet.
Sie sichert auch eine optimierte Verwaltung der Überlastung der Server durch eine aufgeteilte Auslastung gemäß bestimmten Kriterien wie der Art der Anfrage, Belastung, eventuelle Pannen.
Diese Einheit ist außerdem zentralisiert verwaltbar.
Andere Zwecke und Vorteile der Erfindung gehen aus der folgenden Beschreibung hervor, die eine bevorzugte, aber nicht einschränkende Ausführungsform zeigt.
Die vorliegende Erfindung betrifft eine Multiplexeinheit zur Kommunikation in einem Computernetz zwischen einer Vielzahl von Client-Rechnern, die Client-Programme unterstützen, und einem oder mehreren Servern, die Anwendungsprogramme unterstützen, wobei die Client- und Anwendungsprogramme inkompatibel sein können, wie in Anspruch 1 beansprucht.
Diese Einheit wird in den folgenden Varianten auftreten können:

– die Routing-Mittel enthalten Mittel zur aufgeteilten Auslastung zum Definieren der Identität eines Ziel-Servers für die Behandlung einer Anfrage, gemäß den Lastbedingungen;
– die Routing-Mittel enthalten mindestens ein Routing-Anwendungsmodul, das mit den übrigen Routing-Mitteln verbindbar und fähig ist, Routing-Funktionen gemäß vorgegebenen Regeln durchzuführen;
– die Konvertierungsmittel enthalten mindestens ein Konvertierungs-Anwendungsmodul, das mit dem Rest der Konvertierungsmittel verbindbar ist und fähig ist, vorgegebene Konvertierungsfunktionen durchzuführen;
– die Ausgangsverwaltungsmodule enthalten eine Warteschlangenvorrichtung, die in der Lage ist, die Eingänge zu den Servern zu konzentrieren;
– sie enthält ein Verwaltungsmodul, das in der Lage ist, die Schaffung, die Abschaffung, die Abänderung und den Betriebszustand der Ein- und Ausgangsverwaltungsmodule zu verwalten.

Die Erfindung betrifft auch ein Kommunikationssystem in einem Computernetz zwischen einer Vielzahl von Client-Rechnern, die Client-Programme unterstützen, und einem oder mehreren Servern, die Anwendungsprogramme unterstützen, wobei die Client- und Anwendungsprogramme inkompatibel sein können, gekennzeichnet durch die Tatsache, dass es mindestens eine erfindungsgemäße Multiplexeinheit enthält.
Gemäß einer Ausführungsart enthält das System eine Überwachungseinrichtung, die in der Lage ist, das Verwaltungsmodul für die Multiplexeinheit(en) zu steuern.
Gemäß einer anderen Möglichkeit enthält es Erweiterungen in Form von Bibliotheken mit dynamischer Verbindung, um von einer Multiplexeinheit beladen zu werden, um die Anwendungsmodule zu enthalten.
Die Erfindung betrifft schließlich auch ein Kommunikationsverfahren in einem Computernetz zwischen einer Vielzahl von Client-Rechnern, die Client-Programme unterstützen, und einem oder mehreren Servern, die Anwendungsprogramme unterstützen, wobei die Client- und Anwendungsprogramme inkompatibel sein können, das in der Lage ist, von dem erfindungsgemäßen System wie in Anspruch 10 beansprucht verwendet zu werden.
Dieses Verfahren wird die folgenden Schritte enthalten können:

– die erkannten Daten der Anfrage für ihr Routing umfassen die Art ihres Inhalts;
– für das Routing der Anfrage und der vom Ziel-Server abgegebenen Mitteilung nimmt man mindestens ein verbindbares Routing-Anwendungsmodul in Anspruch, um vorgegebene Routing-Funktionen durchzuführen;
– zur Konvertierung der Anfrage und der vom Ziel-Server abgegebenen Mitteilung nimmt man mindestens ein verbindbares Konvertierungs-Anwendungsmodul in Anspruch, um vorgegebene Konvertierungsfunktionen durchzuführen.

Man verwaltet den Engpass/die Überlastung auf verschiedene Art, je nach Zahl und Art der Ausgangsverwaltungsmodule, die vom Mechanismus zum Routing ausgewählt wurden:

– wenn ein einziges Ausgangsverwaltungsmodul beim Routing gefunden wurde und Engpassmitteilungen erhält, dann verwaltet man die Überlastung mittels:
– Definition, auf der Ebene des Ausgangsverwaltungsmoduls, einer maximalen Zahl von Mitteilungen, die von dem Server bis zu einer neuen Definition behandelt werden kann;
– Zählung der vom Ausgangsverwaltungsmodul empfangenen Client-Mitteilungen;
– Subtraktion der Zahl der empfangenen Client-Mitteilungen von der maximalen Zahl, um eine Zahl von zulässigen Mitteilungen zu erhalten, um ein Überlastungsniveau zu bestimmen.
– wenn alle beim Routing gefundenen Ausgangsverwaltungsmodule Überlastungs-Mitteilungen erhalten, führt man für jedes die folgenden Operationen durch:
– Definition, auf der Ebene des Ausgangsverwaltungsmoduls, einer maximalen Zahl von Mitteilungen, die von dem Server bis zu einer neuen Definition behandelt werden kann;
– Zählung der vom Ausgangsverwaltungsmodul empfangenen Client-Mitteilungen;
– Subtraktion der Zahl der empfangenen Client-Mitteilungen von der maximalen Zahl, um eine Zahl von zulässigen Mitteilungen zu erhalten, um ein Überlastungsniveau zu bestimmen. und man wählt das Ausgangsverwaltungsmodul, das das beste Überlastungsniveau hat.
– wenn nur ein Teil der beim Routing gefundenen Ausgangsverwaltungsmodule Überlastungsmitteilungen erhalten und der andere Teil nicht überlastet ist:
1. führt man für jedes Ausgangsverwaltungsmodul, das Überlastungsmitteilungen empfängt, die folgenden Operationen durch:
– Definition, auf der Ebene des Ausgangsverwaltungsmoduls, einer maximalen Zahl von Mitteilungen, die von dem Server bis zu einer neuen Definition behandelt werden kann;
– Zählung der vom Ausgangsverwaltungsmodul empfangenen Client-Mitteilungen;
– Subtraktion der Zahl der empfangenen Client-Mitteilungen von der maximalen Zahl, um eine Zahl von zulässigen Mitteilungen zu erhalten, um ein Überlastungsniveau zu bestimmen;
– man teilt die Zahl der zulässigen Mitteilungen durch die Zeit, die bis zu einer neuen Definition der maximalen Zahl von zulässigen Mitteilungen bleibt, um eine Frequenz der Unterbreitung von Anfragen zu erhalten;
– man fügt zur laufenden Zeit die Frequenz der Unterbreitung von Anfragen hinzu, um zu bestimmen, ab wann das Ausgangsverwaltungsmodul eine neue Client-Mitteilung akzeptieren kann;
2. orientiert man die Client-Mitteilung in Richtung auf das erste Ausgangsverwaltungsmodul, das Überlastungsmitteilungen empfängt, das sie annehmen kann;
3. orientiert man die Client-Mitteilung in Richtung auf ein anderes Ausgangsverwaltungsmodul, wenn kein Ausgangsverwaltungsmodul, das Überlastungsmitteilungen empfängt, sie annehmen kann;
– man verteilt die Last zwischen den Ausgangsverwaltungsmodulen, die keine Überlastungsmitteilungen erhalten, durch die folgenden Operationen:
1. Konstruktion einer Tabelle der Ausgangsverwaltungsmodule, die keine Überlastungsmitteilungen erhalten;
2. Inkrementierung eines Zählers bei jeder erhaltenen Client-Mitteilung;
3. Teilung der Zahl des Zählers durch die Zahl der Ausgangsverwaltungsmodule, die keine Überlastungsmitteilungen erhalten;
4. Benutzung des Rests der Teilung als Register in der Tabelle, um das Ausgangsverwaltungsmodul zu finden, das keine Überlastungsmitteilungen empfängt.

Die beiliegenden Zeichnungen sind als Richtbeispiele gegeben und nicht einschränkend. Sie stellen eine Ausführungsform dar. Mit ihrer Hilfe ist die Erfindung leicht zu verstehen.
1 und 2 zeigen zwei Multiplex-Ausführungsbeispiele gemäß dem Stand der Technik.
3 zeigt schematisch die Anordnung einer Middleware zwischen einem Client-Teil und einem Server-Teil.
4 ist eine Gesamtansicht der Erfindung.
5 veranschaulicht verschiedene Betriebsphasen der Erfindung.
In 2 ist der klassische Aufbau eines Computernetzes dargestellt. In diesem Netz ist eine Vielzahl von Client-Rechnern 1 mit einem oder mehreren Servern 3 verbunden, die oft weit entfernt von den Client-Rechnern sind. Als Beispiel können die Clients mit dem Netz verbundene Privatpersonen sein, zum Beispiel mit einem weltweiten Netz 2, wie das Internet, oder Angestellte aus der Reisebranche. Es kann sich auch um EDV-Server handeln.
Die Netze setzen üblicherweise zahlreiche Client-Rechner ein. Man muss daher vorzugsweise versuchen, die Zahl der Verbindungen zwischen den Client-Rechnern 1 und den Servern 3 zu minimalisieren, durch Konzentrations- und Aufteilungsoperationen mittels eines Multiplexbetriebs.
In 2 sind bestimmte Client-Rechner 1 durch das Netz 2 in Verbindung mit einem einzigen Server 3. Die Clients müssen wissen, mit welchem/n Server(n) sie sich verbinden können. Die Einrichtungszeit der Verbindungen ist sehr wichtig, und bei Störung der Verbindung kann der Client im Allgemeinen nicht wissen, ob die Störung am Netz liegt oder am Server. Der einzige Weg für ihn, um mit den Pannen fertig zu werden, ist, zu versuchen, eine Verbindung mit einem anderen Server herzustellen, der denselben Dienst anbietet, was lange dauert, gefährlich ist und die Benutzung und die Entwicklung des Client-Programms verkompliziert.
Man hat Multiplexbetriebe vorgeschlagen, die eine bessere Reaktionszeit ermöglichen. Eine Ausgestaltung hiervon ist in 1 veranschaulicht. In diesem Rahmen sind Multiplexer 4 einer Gruppe von Client-Rechnern 1 nachgeschaltet, um ihre Kommunikation mit dem Netz 2 zu verwalten.
Es leuchtet ein, dass, wenn die Multiplexer 4 multipliziert werden, die Verwaltung des Netzes schwierig wird. In der Tat, bei Anpassung, Entwicklung oder Evolution von bestimmten Bestandteilen des Netzes ist es notwendig, Aktualisierungen bei Multiplexern 4 durchzuführen, die weit entfernt sein können, und sich manchmal bei einem Client oder bei einem Handelspartner befinden.
Um diesen Nachteilen und den vorher erwähnten für diesen Typ von Multiplexbetrieb abzuhelfen, hat man den Gebrauch von Middleware 9 wie in 3 dargestellt vorgeschlagen.
In dieser Figur stellt eine Middleware 9 eine Vermittler-Software zwischen einem Client-Teil und einem Server-Teil dar.
Der Client-Teil umfasst eine Client-Tätigkeitsebene 5, auf der bestimmte Verarbeitungen durchgeführt werden, sowie eine Schnittstellenebene 7 mit der Middleware 9.
Andererseits ist eine Server-Tätigkeitsebene 6 vorhanden und kommuniziert in Richtung auf die Middleware 9 über eine Schnittstellenebene 8.
Die Nachteile der Benutzung einer Middleware 9 sind schon erwähnt worden.
Die von der Erfindung vorgeschlagene Lösung ist schematisch in den 4 und 5 veranschaulicht.
Allgemein sieht man in 4, dass die Erfindung eine Client-Tätigkeitsebene 10 und eine Server-Tätigkeitsebene 11 in Verbindung setzt. Diese Verbindung wird von Standard-Netzschnittstellenschichten 12, 13 durchgeführt.
Um die Kommunikation durchzuführen, ist ein erfindungsgemäßes Kommunikationssystem 15 vorhanden und mit einer Standardnetzschicht 14 verbunden.
Schematisch ist das Kommunikationssystem 15 in zwei Blöcken von Diagrammen dargestellt, die die Modularität der Erfindung zeigen.
Ebenfalls sind durch Pfeile die Transfers von Mitteilungen von der Client-Tätigkeitsebene 10 zur Server-Tätigkeitsebene 11 dargestellt. Die Richtung der Pfeile, hier nur als Beispiel gezeigt, ist Client-Server, aber die Gegenrichtung wird natürlich ebenfalls durchgeführt.
Eine Anfrage 20 wird von der Client-Tätigkeitsebene 10 an das Kommunikationssystem 15 gerichtet und durch das erfindungsgemäße Kommunikations-System 15 auf der Tätigkeitsebene des Servers 11 in einer Client-Mitteilung 22 umgewandelt.
Zur Übertragung einer solchen Client-Mitteilung 22 an den Server werden Routing-Funktionen und eventuell Funktionen zur aufgeteilten Auslastung oder auch zur Konvertierung durchgeführt.
Im weiteren Verlauf der Beschreibung und zum besseren Verständnis der Erfindung bezeichnet der Ausdruck „Anfrage 20" eine vom Client geschickte Mitteilung und das Wort „Antwort 21" eine vom Client erhaltene Mitteilung.
In 5 sieht man, dass als Beispiel eine Kommunikation zwischen einem Client-Rechner 16 und einem Server 17 dargestellt ist.
Ihre Verbindung erfolgt über eine erfindungsgemäße Multiplexeinheit. Eine solche Einheit kann eine Vielzahl von Client-Rechnern 16 und Server 17 einsetzen. Außerdem kann das erfindungsgemäße System, das die so dargestellte Multiplexeinheit enthält, andere ähnliche erfindungsgemäße Einheiten enthalten.
Das vorgeschlagene System ist somit vollkommen modular und organisiert und kann zentralisiert kontrolliert und verwaltet werden.
Es folgt eine Beschreibung besonderer Ausführungsarten der erfindungsgemäßen Multiplexeinheiten.
5 zeigt für jeden Client-Rechner 16 die Bildung eines Eingangsverwaltungsmoduls 18. Ein solches Verwaltungsmodul 18 wird für jeden zu verbindenden Typ von Client-Rechnern geschaffen und kann je nach Bedarf verändert oder gelöscht werden.
Das Eingangsverwaltungsmodul sichert den Empfang der Anfragen 20, die von dem Client-Rechner stammen, und die Übertragung der Antworten 21 auf diese Anfragen 20. Ein Pfeil 20 zeigt den Weg der Anfrage, die von einem Client-Programm stammt, das von dem Client-Rechner 16 gestützt wird.
Außerdem weist man in der Multiplexeinheit ein Ausgangsverwaltungsmodul 19 einem oder mehreren Servern 17 zu. Auf ähnliche Weise hat das Ausgangsverwaltungsmodul 19 die Funktion, die Mitteilungen zu empfangen, die der oder die Server 17 behandeln soll(en), und sie zu ihm oder ihnen zu leiten.
Wie dargestellt, wird ein System von Warteschlangen verwendet, um eine Reihe von Client-Mitteilungen 22 zu bilden, die auf der Ebene des Ausgangsverwaltungsmoduls 19 zu behandeln sind. Eine Warteschlangenvorrichtung 26 zu diesem Thema ist in 5 veranschaulicht.
Routing-Mittel sind vorhanden, um ein oder mehrere Ausgangsverwaltungsmodule 19 zu bestimmen, an die die Anfrage 20, die vom Client-Rechner stammt, übertragen werden soll.
Die Routing-Mittel, die einerseits mit dem Eingangsverwaltungsmodul 18 und andererseits mit dem Ausgangsverwaltungsmodul 19 verbunden sind, gestatten es, die Identität mindestens eines Ziel-Ausgangsverwaltungsmoduls für die Behandlung einer Anfrage 20 zu definieren, und umgekehrt, die Identität des Client-Rechners, an den die Mitteilung 23, die vom Ziel-Server stammt, adressiert werden muss.
Vorzugsweise enthalten die Routing-Mittel Mittel zur aufgeteilten Auslastung 27, die es gestatten, die Identität eines einzigen Ausgangsverwaltungsmoduls 19 für die Behandlung der Anfrage 20 gemäß Belastungswerten zu definieren.
Ausführungsarten dieser Aufteilung werden weiter unten beschrieben, aber wir geben hier bereits Parameter an, die erfasst werden können: der Ausfall von eventuellen Servern, die Überlastung der Server, die Art der zu behandelnden Mitteilungen.
Die Lastbedingungen werden in dem System im Wesentlichen durch Mitteilungen der maximalen Zahl von Mitteilungen definiert, die normalerweise von Überlastungsverursachern stammen. Letztere können auf Höhe der Server installiert werden oder unabhängig.
Außerdem folgt später die Beschreibung eines Verwaltungsmoduls 36, das Default-Werte beibehalten kann, um nötigenfalls, bei einem Ausfall des Überlastungsverursachers, Ersatz zu liefern.
Bei einer vorteilhaften Möglichkeit enthalten die Routing-Mittel ein oder mehrere Routing-Anwendungsmodule 24, 30. Diese Module sind mit Routing-Subsystemen 29, 34 verbunden, die mit den Eingangs- 18 und Ausgangsverwaltungsmodulen 19 verbunden sind.
Die Routing-Anwendungsmodule 24, 34 sind mit dem Rest der Routing-Mittel verbindbar, was eine perfekte Betriebsmodularität sichert.
Vorzugsweise werden die Zuführungsentscheidungen auf der Ebene der Anwendungsmodule 24, 34 getroffen. Diese Entscheidungen werden danach von dem Rest der Routing-Mittel angewendet.
Je nach den durchzuführenden Routing-Operationen können verschiedene Anwendungsmodule verwendet und verbunden werden.
Angesichts des Ausmaßes der eingesetzten Computernetze stellen sich Kompatibilitätsprobleme bezüglich der Formate und der Transferprotokolle, die von den Client-Anwendungen und den Anwendungen der Server benutzt werden.
Um dem abzuhelfen, umfasst die hier vorgestellte Multiplexeinheit Konvertierungsmittel. Diese Mittel sichern die Konvertierung, wenn nötig, des Inhalts der Anfragen 20 in kompatible Client-Mitteilungen 22, die somit von dem Anwendungsprogramm des Ziel-Servers 17 benutzbar sind. Die Konvertierungsmittel führen auch eine Konvertierung des Inhalts der Mitteilung 23, die vom Ziel-Server 17 stammt, in eine Antwort 21 durch, die mit dem adressierten Client-Programm kompatibel ist.
Vorteilhafterweise ist die Konzeption der Konvertierungsmittel ähnlich der der Routing-Mittel. Dies bedeutet, dass die Konvertierungsmittel Konvertierungssubsysteme 28, 33 enthalten, die mit Konvertierungs-Anwendungsmodulen 25, 31 kommunizieren können, mit denen sie verbunden sind. Parallel zu den Routing-Mitteln wird es möglich sein, die Anwendungsmodule 25, 31 zu verwenden und sich entwickeln zu lassen, gemäß den durchzuführenden Konvertierungsfunktionen.
Ein Anwendungsmodul wird durch Konfiguration mit einem Eingangs- oder Ausgangsverwaltungsmodul verbunden. Entsprechend kann man in einer erfindungsgemäßen Multiplexeinheit mehrere verschiedene Anwendungsmodule koexistieren lassen. Es ist ebenfalls möglich, welche abzuwandeln oder neue einzusetzen, ohne die Multiplexeinheit anzuhalten.
Die Subsysteme wie dargestellt können ein oder mehrere verbindbare Anwendungsmodule in Anspruch nehmen.
Innerhalb der Multiplexeinheit bildet man vorzugsweise ein Verwaltungsmodul 36. Das Verwaltungsmodul 36 verwaltet die Eingangs- 18 und Ausgangsverwaltungsmodule 19 der Einheit. Das Modul 36 schafft, löscht oder verändert die Ein- und Ausgangsverwaltungsmodule. Außerdem kann es statistische Funktionen und Funktionen zur Prüfung des Zustandes der Module durchführen, auch des Zustandes ihrer Belastung und ihrer Überlastung. Bei einer vorteilhaften Möglichkeit kann die Verwaltung auf ein oder mehrere Verwaltungsanwendungsmodule 35 ausgedehnt sein. Diese Module gestatten die Verwaltung der Routing- und Konvertierungs-Anwendungsmodule und insbesondere, ihnen Routingtabellen und Beschreibungen von Mitteilungen zu liefern.
Mehrere Multiplexeinheiten, wie sie gerade beschrieben wurden, können verwendet werden, um ein erfindungsgemäßes Kommunikationssystem zu bilden. In diesem Rahmen werden die Multiplexeinheiten parallel benutzt und leiten eine Vielzahl von Client-Rechnern 16 und Servern 17.
Auf diese Weise erfolgt die Kontrolle des Kommunikationssystems zentralisiert für alle Multiplexeinheiten. So kann das System eine Überwachungseinrichtung umfassen, die in der Lage ist, die Verwaltungsmodule 36 der Einheiten zu steuern.
Durch verschiedene Verwaltungs- und Kontrollwerkzeuge kann ein Nutzer, zum Beispiel über eine grafische Schnittstelle, das System durch Einwirkung auf die Überwachungseinrichtung verwalten und kontrollieren, er selbst steuert die Verwaltungsmodule 36.
Außerdem kann die Parallelisierung von mehreren Multiplexeinheiten in Zusammenhang mit der Benutzung von Erweiterungen in Form von Bibliotheken mit dynamischer Verbindung erfolgen (DLL – Dynamic Link Libraries). Diese Erweiterungen können auf Wunsch von der einen oder der anderen Multiplexeinheit belastet werden, um ihre Funktionen zu erweitern. Diese Funktionen können den Routing-Subsystemen 29, 34, den Konvertierungssubsystemen 28, 33 und der Überwachung und der Verwaltung der Multiplexeinheiten nützen.
Diese Bibliotheken mit dynamischer Verbindung können alle folgenden Elemente darstellen: Anwendungsmodule 24, 25, 30, 31 und Verwaltungs-Anwendungsmodule 35.
Die Funktionen des Systems können ebenfalls durch dieses Mittel erweitert werden, was die Verwaltung der Überlastung des Servers betrifft.
Es folgt eine Beschreibung des erfindungsgemäßen Kommunikationsverfahrens, das gleichzeitig von dem vorher beschriebenen Kommunikationssystem und von den in dem System enthaltenen Multiplexeinheiten verwendet werden kann und Teil der Erfindung ist.
Wir beziehen uns weiter auf 5, um die Phasen dieses Verfahrens zu veranschaulichen.
Wie vorher bezüglich der Multiplexeinheit angegeben, verbinden die Clients sich mit einem Eingangsverwaltungsmodul. Ein Ausgangsverwaltungsmodul verbindet sich mit einem oder mehreren Servern oder wartet gemäß einem anderen Modus auf die Verbindungen der Server. Man findet das Prinzip der Erfindung wieder, nämlich, ohne Abänderung die existierenden Clients und Server und ihre Bedürfnisse zu befriedigen. Wenn eine Anfrage 20 an den Rest des Systems zu ihrer Behandlung gerichtet werden muss, wird sie in Richtung auf einen Server 17 geleitet, unter Beachtung der Routingdaten. Darunter sind die Adresse des Eingangsverwaltungsmoduls 18 und die Netzadresse des Client-Rechners 16.
Andere Parameter können dazu dienen, das Routing der Anfrage 20 zu bestimmen, und vor allem den Inhalt der Anfrage. So umfasst das Routing eine Kontrolle und Analyse des Inhalts der Anfrage 20.
Vorzugsweise erfolgt das Routing in zwei Phasen, deren eine von einem Subsystem zum Routing 29 in Verbindung mit dem Eingangsverwaltungsmodul 18 ausgeht. Die zweite nimmt mindestens ein Routing-Anwendungsmodul 24 in Anspruch, das mit dem Subsystem 29 verbindbar ist. Da es über Routingparameter verfügt, bestimmt das Anwendungsmodul 24 die Identität von einem oder mehreren Ausgangsverwaltungsmodulen 19. Das Routing erfolgt dann durch das Subsystem 29.
Falls mehrere Möglichkeiten von Ziel-Servern definiert worden sind, kann man einen einzigen davon nach Kriterien der Aufteilung der Belastungen auswählen.
Später folgt eine Beschreibung der Varianten der Erfindung, die eine solche Aufteilung der Belastungen unter den Ausgangsverwaltungsmodulen 19 nach Überlastungskriterien durchführen.
Wenn die Identität des Ausgangsverwaltungsmoduls 19 am Ende des Routings bestimmt worden ist, führt man eine Konvertierung der Anfrage 20 in eine Client-Mitteilung 22 durch, die mit den Ziel-Servern 17 kompatibel ist.
Wenn es nötig ist, kann die Konvertierung ebenfalls in zwei Phasen erfolgen. Die erste besteht darin, von einem Konvertierungssubsystem 28 aus ein Konvertierungs-Anwendungsmodul 25 in Anspruch zu nehmen, das verbunden ist. Das Subsystem 28 nimmt ein oder mehrere Konvertierungs-Anwendungsmodule 25 je nach der durchzuführenden Konvertierung in Anspruch.
Das Konvertierungs-Anwendungsmodul 25 gibt dem Subsystem 28 eine Client-Mitteilung 22 zurück, die mit dem Server 17 kompatibel ist.
Diese Client-Mitteilung 22 wird an den Server 17 über das Ausgangsverwaltungsmodul 19 des Servers 17 übertragen.
Auf der Ebene des Ausgangsverwaltungsmoduls 19 wird eine Warteschlange geschaffen, um die Client-Mitteilungen 22 zu empfangen, die Rolle eines Puffers zu spielen und die Mitteilungen anschließend an den Server 17 zu senden.
Eine Warteschlange ist erforderlich, soweit die Eingangsverwaltungsmodule 18 „multithread" sind: das heißt, fähig, mehrere Anfragen gleichzeitig zu deponieren.
Ein anderer „thread"-Ausführungsweg wird jedem Server 17 zugewiesen, und die verschiedenen Ausführungswege holen Mitteilungen parallel von der Warteschlange 26 ab.
Wenn die Client-Mitteilung auf Höhe des Servers 17 behandelt worden ist, gibt dieser eine Server-Mitteilung 23 zurück.
Wie auf Höhe des Verwaltungsmoduls 18 beschrieben, erfolgt ein Routing und dann eine Konvertierung durch Inanspruchnahme von Routing- 30 und Konvertierungs-Anwendungsmodulen 31.
Das Routing der Mitteilung 23 erfolgt je nach der Erkennung der Natur dieser Mitteilung 23.
Die Konvertierungsoperation könnte vor der Routingfunktion durchgeführt werden, aber sie wird vorzugsweise danach verwirklicht. In der Tat handelt es sich um eine längere Operation, aber mit weniger unsicherem Ausgang als die des Routings.
Gemäß einer bevorzugten Variante des erfindungsgemäßen Verfahrens verwaltet man die Überlastung des oder der Server(s), oder wenigstens eines Teils der in dem System enthalten Server 17.
Man verwaltet die Überlastung verschieden je nach Zahl und Art der Ausgangsverwaltungsmodule, die vom Mechanismus zum Routing ausgewählt wurden.
Wenn ein einziges Ausgangsverwaltungsmodul beim Routing gefunden wurde und Überlastungsmitteilungen erhält, dann verwaltet man seine Überlastung durch:

– Definition, auf der Ebene des Ausgangsverwaltungsmoduls, einer maximalen Zahl von Mitteilungen, die von dem Server bis zu einer neuen Definition behandelt werden kann;
– Zählung der vom Ausgangsverwaltungsmodul empfangenen Mitteilungen;
– Subtraktion der Zahl der Mitteilungen von der maximalen Zahl, um eine Zahl von zulässigen Mitteilungen zu erhalten, um ein Überlastungsniveau zu bestimmen.

Wenn alle gefundenen Ausgangsverwaltungsmodule Überlastungsmitteilungen erhalten, dann behält jedes Ausgangsverwaltungsmodul eine Zahl von zulässigen Mitteilungen, wie oben beschrieben. Der Routing-Mechanismus wählt das Ausgangsverwaltungsmodul mit der größten Zahl von zulässigen Mitteilungen, das heißt das beste Überlastungsniveau.
Wenn ein Teil der gefundenen Ausgangsverwaltungsmodule Überlastungsmitteilungen erhält und ein anderer Teil keine erhält und somit nicht überlastet ist, zielt das Routing darauf ab, in den Grenzen der auferlegten Überlastung die überlasteten Ausgangsverwaltungsmodule maximal zu benutzen und dann die bleibende Last unter den nicht überlasteten Ausgangsverwaltungsmodulen gerecht aufzuteilen. Zu diesem Zweck berechnet man für jedes überlastete Ausgangsverwaltungsmodul eine Anfragefrequenz, indem man die Zahl der zulässigen Mitteilungen durch die Zeit teilt, die bis zu einer neuen Definition der maximalen Zahl von zulässigen Mitteilungen bleibt, und von dieser Frequenz ausgehend, ab wann dieses Ausgangs verwaltungsmodul eine Anfrage akzeptieren kann. Der Routing-Mechanismus wählt das erste überlastete Ausgangsverwaltungsmodul, das eine Anfrage akzeptieren kann, und wenn er keines findet, wählt er ein nicht überlastetes Verwaltungsmodul gemäß dem Mechanismus zur aufgeteilten Auslastung als Default.
Zu diesem Zweck und gemäß einer bevorzugten Variante hat man einen Zähler, der bei jeder erhaltenen Mitteilung um 1 zunimmt und im Falle einer Kapazitätsüberschreitung neu initialisiert. Der Routing-Mechanismus erstellt eine Tabelle der ausgewählten Ausgangsverwaltungsmodule. Er berechnet den Rest der Teilung des Zählers durch die Zahl der ausgewählten Ausgangsverwaltungsmodule und wählt das diesem Index in der Tabelle entsprechende Ausgangsverwaltungsmodul.

1: Client-Rechner
2: Kommunikationsnetze
3: Server
4: Multiplexer
5: Client-Tätigkeitsebene
6: Server-Tätigkeitsebene
7: Schnittstellenebene zur Middleware
8: Schnittstellenebene zur Middleware
9: Middleware
10: Client-Tätigkeitsebene
11: Server-Tätigkeitsebene
12: Schnittstellenebene Netz
13: Schnittstellenebene Netz
14: allgemeine Netzschicht
15: Kommunikationssystem
16: Client-Rechner
17: Server
18: Eingangsverwaltungsmodul
19: Ausgangsverwaltungsmodul
20: Anfrage
21: Antwort
22: Client-Mitteilung
23: Server-Mitteilung
24, 30: Routing-Anwendungsmodul
25, 31: Konvertierungs-Anwendungsmodul
26: Warteschlangenvorrichtung
27: Mittel zur aufgeteilten Auslastung
28, 33: Konvertierungssubsystem
29, 34: Routing-Subsystem
35: Verwaltungsanwendungsmodul
36: Verwaltungsmodul

Claims

Multiplexeinheit für den Dialog in einem Computernetz zwischen einer Vielzahl von Client-Rechnern (16), die Client-Programme unterstützen, und einer Vielzahl von Servern (17), die Anwendungsprogramme unterstützen, wobei die Client- und die Anwendungsprogramme inkompatibel sein können und die genannten Einheit Routing-Mittel und Konvertierungsmittel besitzt, dadurch gekennzeichnet dass sie aufweist: – für jeden Typ Client-Rechner (16) ein Eingangsverwaltungsmodul (18), das die Anfragen (20) der Client-Programme empfängt und die Antworten (21) an sie überträgt; – für einen Server (17) oder eine Gruppe von Servern, ein Ausgangsverwaltungsmodul (19), das dem Server die an ihn gerichteten Client-Mitteilungen (22) sendet und die Antworten (21) an die Eingangsverwaltungsmodule (18) der Client-Rechner (16) sendet, und dass Routing-Mittel (214, 30, 29, 34) mit den Eingangs- und den Ausgangsverwaltungsmodulen (18, 19) verbunden sind und die Identität mindestens eines Ausgangsverwaltungsmoduls (1) festlegen können, um die Anfrage (20) zu verarbeiten und den Client-Rechner (16) festzulegen, an den die aus dem Ziel-Server (17) kommende Mitteilung (23) gerichtet werden soll, dass die Konvertierungsmittel (28, 33, 25, 31), wenn notwendig, den Inhalt der Anfrage (20) in eine mit dem Anwendungsprogramm des Ziel-Servers (17) kompatible Client-Mitteilung (22) und den Inhalt der aus dem Ziel-Server (17) kommenden Mitteilung (23) in eine mit dem Client-Programm kompatible Antwort (21) umsetzen können.
Einheit gemäß Anspruch 1, gekennzeichnet dadurch, dass die Routing-Mittel Einrichtungen zur Lastaufteilung (27) besitzen, welche zur Verarbeitung einer Anfrage (20), je nach Auslastungsbedingungen, einen Ziel-Server (17) festlegen können.
Einheit gemäß Anspruch 1 oder 2, gekennzeichnet dadurch, dass die Routing-Mittel mindestens ein Routing-Anwendungsmodul (24, 30) besitzen, das mit den übrigen Routing-Mitteln verbindbar ist und die Routingfunktionen entsprechend vorgegebenen Regeln ausführen kann.
Einheit gemäß einem der Ansprüche 1 bis 3, gekennzeichnet dadurch, dass die Konvertierungsmittel mindestens ein Konvertierungs-Anwendungsmodul (25, 31) besitzen, das mit den übrigen Konvertierungsmitteln verbindbar ist und die vorgegebenen Konvertierungsfunktionen ausführen kann.
Einheit gemäß einem der Ansprüche 1 bis 4, gekennzeichnet dadurch, dass die Ausgangsverwaltungsmodule eine Warteschlangeneinrichtung (26) besitzen, welche die Eingänge auf die Server (17) konzentrieren kann.
Einheit gemäß einem der Ansprüche 1 bis 5, gekennzeichnet dadurch, dass sie ein Verwaltungsmodul (36) besitzt, das die Erstellung, die Löschung, die Änderung und den Betriebszustand der Ein- und Ausgangsverwaltungsmodule (18, 19) steuern kann.
Kommunikationssystem in einem Computernetz zwischen einer Vielzahl von Client-Rechnern (16), die Client-Programme unterstützen, und einem oder mehreren Servern (17), die Anwendungsprogramme unterstützen, wobei die Client- und Anwendungsprogramme inkompatibel sein können, gekennzeichnet dadurch, dass es mindestens eine Multiplexeinheit gemäß einem der Ansprüche 1 bis 6 integriert.
Kommunikationssystem in einem Computernetz zwischen einer Vielzahl von Client-Rechnern (16), die Client-Programme unterstützen, und einem oder mehreren Servern (17), die Anwendungsprogramme unterstützen, wobei die Client- und Anwendungsprogramme inkompatibel sein können, dadurch gekennzeichnet, dass es mindestens eine Multiplexeinheit gemäß Anspruch 6 integriert, dass es eine Überwachungseinrichtung umfasst, mit welcher das Verwaltungsmodul der einen oder mehreren Multiplexeinheiten gesteuert werden kann.
Kommunikationssystem in einem Computernetz zwischen einer Vielzahl von Client-Rechnern (16), die Client-Programme unterstützen, und einem oder mehreren Servern (17), die Anwendungsprogramme unterstützen, wobei die Client- und Anwendungsprogramme inkompatibel sein können, dadurch gekennzeichnet, dass es mindestens eine Multiplexeinheit gemäß Anspruch 3 oder Anspruch 4 integriert, dass es Erweiterungen in Form von Bibliotheken mit dynamischer Schnittstelle umfasst, die von einer Multiplexeinheit geladen werden können, um die Anwendungsmodule (24, 30, 25, 31) zu enthalten.
Kommunikationssystem in einem Computernetz zwischen einer Vielzahl von Client-Rechnern (16), die Client-Programme unterstützen, und einem oder mehreren Servern (17), die Anwendungsprogramme unterstützen, wobei die Client- und Anwendungsprogramme inkompatibel sein können, das Verfahren zur Ausführung von Routing- und Konvertierungsaktionen verwendet wird und in dem System gemäß Anspruch 7, 8 oder 9 eingesetzt werden kann, dadurch gekennzeichnet, dass jeder Client-Rechner (16) eines bestimmten Typs mit einem Eingangsverwaltungsmodul (18) verbunden wird, das die Anfragen (20) des Client-Programms empfängt und ihm die Antworten (21) überträgt, dass an einen Server (17) ein Ausgangsverwaltungsmodul (19) angeschlossen wird, das dem Server (17) die an ihn gerichteten Client-Mitteilungen (22) sendet und die Antworten (21) an die Eingangsverwaltungsmodule (18) der Client-Rechner (16) überträgt, dass das Routing der Anfrage (20) durch Erkennung der Daten der Anfrage (20) erfolgt, darunter der Adresse des Eingangsverwaltungsmoduls (18) und der Netzadresse des Client-Rechners (16), der sie gesendet hat, und dass anschließend anhand dieser Daten mindestens ein Ziel-Server (17) ermittelt wird, dass die Anfrage (20) in eine Client-Mitteilung (22), deren Format mit dem oder den Ziel-Server(n) (17) kompatibel ist, umgesetzt wird, dass die Client-Mitteilung (22) zur Weiterleitung an das Ausgangsverwaltungsmodul (19) des Ziel-Servers (17) gesandt wird, dass das Routing der aus dem Ziel-Server (17) kommenden und vom Ausgangsverwaltungsmodul (19) übermittelten Mitteilung (23) durch Erkennung der aus dem Ziel-Server (17) kommenden Mitteilung (23) erfolgt und anschließend, entsprechend dem Ergebnis der Erkennung, der entsprechende Client-Rechner (16) festgelegt wird, dass die aus dem Ziel-Server (17) kommende Mitteilung (23), wenn notwendig, vor oder nach dem Routing in eine Antwort (21) umgesetzt wird, deren Format mit dem oder den Client-Rechnern (16) kompatibel ist, dass die Antwort (21) zur Weiterleitung an das Eingangsverwaltungsmodul (18) des Client-Rechners (16) gesendet wird.
Kommunikationsverfahren gemäß Anspruch 10, gekennzeichnet dadurch, dass die Daten der Anfrage (20), die zum Routing erkannt werden, die Art ihres Inhalts enthalten.
Kommunikationsverfahren gemäß Anspruch 10 oder 11, gekennzeichnet dadurch, dass zum Routing der Anfrage (20) und der aus dem Ziel-Server (17) kommenden Mitteilung (23) mindestens ein Routing-Anwendungsmodul (24, 30) angesteuert wird, das zur Ausführung der vorbestimmten Routing-Funktionen anschließbar ist.
Kommunikationsverfahren gemäß einem der Ansprüche 10 bis 12, gekennzeichnet dadurch, dass zur Umsetzung der Anfrage (20) und der aus dem Ziel-Server (17) kommenden Mitteilung (23) mindestens ein Anwendungsmodul für die Umsetzung (25, 31) angesteuert wird, das zur Ausführung der vorbestimmten Konvertierungsfunktionen anschließbar ist.
Kommunikationsverfahren gemäß einem der Ansprüche 10 bis 13, gekennzeichnet dadurch, dass, wenn ein einziges Ausgangsverwaltungsmodul (19) bei dem Routing gefunden wurde und Überlastungsmitteilungen empfangen werden, diese Überlastungen wie folgt zu verwalten sind: – Festlegung einer maximalen Zahl von Mitteilungen auf Ebene des Ausgangsverwaltungsmoduls (19), die vom Server (17) bis zur nächsten Festlegung verarbeitet werden können, – Zählung der vom Ausgangsverwaltungsmodul (19) empfangenen Mitteilungen, – Subtraktion der Zahl der Mitteilungen von der maximalen Zahl, um zu einer zulässigen Zahl von Mitteilungen zu gelangen und eine neue Überlastung festzulegen.
Kommunikationsverfahren gemäß einem der Ansprüche 10 bis 13, gekennzeichnet dadurch, dass, wenn alle Ausgangsverwaltungsmodule (19), die beim Routing gefunden wurden, Überlastungsmitteilungen empfangen, für jeden von diesen folgende Verarbeitungsschritte ausgeführt werden: – Festlegung einer maximalen Zahl von Mitteilungen auf Ebene des Ausgangsverwaltungsmoduls (19), die vom Server (17) bis zur nächsten Festlegung verarbeitet werden können, – Zählung der vom Ausgangsverwaltungsmodul (19) empfangenen Mitteilungen (22), – Subtraktion der Zahl der empfangenen Client-Mitteilungen (22) von der maximalen Zahl, um zu einer zulässigen Zahl von Mitteilungen zu gelangen und eine neue Überlastung festzulegen, und man das Ausgangsverwaltungsmodul (19) wählt, das die günstigste Überlastung besitzt.
Kommunikationsverfahren gemäß einem der Ansprüche 10 bis 13, gekennzeichnet dadurch, dass, wenn nur ein Teil der Ausgangsverwaltungsmodule (19), die beim Routing gefunden wurden, Überlastungsmitteilungen empfangen, und die übrigen von dieser Überlastung nicht betroffen sind: 1. für jedes diese Überlastungsmitteilung empfangende Ausgangsverwaltungsmodul (19) folgende Verarbeitungsschritte durchgeführt werden: – Festlegung einer maximalen Zahl von Mitteilungen auf Ebene des Ausgangsverwaltungsmoduls (19), die vom Server (17) bis zu einer neuen Festlegung verarbeitet werden können, – Zählung der vom Ausgangsverwaltungsmodul (19) empfangenen Client-Mitteilungen (22), – Subtraktion der Zahl der empfangenen Client-Mitteilungen (22) von der maximalen Zahl, um zu einer zulässigen Zahl von Mitteilungen zu gelangen und eine neue Überlastung festzulegen, – Teilung der Zahl der zulässigen Mitteilungen durch die bis zur nächsten Festlegung der maximal zulässigen Zahl von Mitteilungen verbleibenden Zeit, um eine Anfragefrequenz zu ermitteln, – Hinzufügen der Anfragefrequenz zur aktuellen Zeit, um zu bestimmen, ab wann das Ausgangsverwaltungsmodul (19) wieder eine neue Client-Mitteilung (22) entgegennehmen kann, 2. Weiterleitung der Client-Mitteilung (22) an das erste Ausgangsverwaltungsmodul (19), das die Überlastungsmitteilungen empfängt und sie entgegennehmen kann, 3. Weiterleitung der Client-Mitteilung (22) an ein anderes Ausgangsverwaltungsmodul (19), wenn keines der die Überlastungsmitteilungen empfangenden Ausgangsverwaltungsmodule (19) diese entgegennehmen kann.
Kommunikationsverfahren gemäß Anspruch 16, gekennzeichnet dadurch, dass die Last auf diejenigen Ausgangsverwaltungsmodule (19) verteilt wird, welche die Überlastungsmitteilungen nicht empfangen, durch folgende Verarbeitungsschritte: 1. Anlage einer Tabelle von Ausgangsverwaltungsmodulen (129), welche die Überlastungsmitteilungen nicht erhalten, 2. Inkrementierung eines Zählers bei jeder eingegangenen Client-Mitteilung (22), 3. ganzzahlige Teilung des Zählerstandes durch die Zahl der Ausgangsverwaltungsmodule (19), welche die Überlastungsmitteilungen nicht erhalten, 4. Verwendung des bei der Teilung verbleibenden Rests als Zeiger in der Tabelle, um das Ausgangsverwaltungsmodul (19) zu finden, der keine zu verwendende Überlastungsmitteilung erhält.