WO2000054150A2 - Verfahren zur nachrichtenübertragung zwischen einer einem ersten prozess zugewiesenen clientinstanz und wenigstens einer mindestens einem weiteren prozess zugewiesenen serverinstanz innerhalb eines verteilten systems - Google Patents
Verfahren zur nachrichtenübertragung zwischen einer einem ersten prozess zugewiesenen clientinstanz und wenigstens einer mindestens einem weiteren prozess zugewiesenen serverinstanz innerhalb eines verteilten systems Download PDFInfo
- Publication number
- WO2000054150A2 WO2000054150A2 PCT/DE2000/000623 DE0000623W WO0054150A2 WO 2000054150 A2 WO2000054150 A2 WO 2000054150A2 DE 0000623 W DE0000623 W DE 0000623W WO 0054150 A2 WO0054150 A2 WO 0054150A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- instance
- client
- server
- message
- action
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
- G06F9/548—Object oriented; Remote method invocation [RMI]
Definitions
- the invention relates to a method for message transmission between a client instance assigned to a first process and at least one server instance assigned to at least one further process within a distributed system.
- Distributed systems preferably play a special role in today's telecommunications systems, which are generally multiprocessor systems.
- a distributed system is characterized in particular by the fact that processes can each be assigned to different processors, the processors possibly being located on spatially separate platforms in the distributed system.
- One of the most important aspects in the communication between different processes of a distributed system is the platform transparency. This means that a process that wants to send a message to another process does not have to know the platform on which the other process is currently running.
- Such a complex distributed system must meet many other requirements today. Among other things, it must prove to be extremely reliable, as flexible as possible and open to adjustments and extensions.
- the software of such a complex distributed system should therefore be designed to be highly modular with firmly defined open interfaces to the outside, so that the individual modules of the software are easily adaptable and, above all, reusable.
- Implicit concurrency There are two ways to implement implicit concurrency:
- - Passive objects An asynchronous message exchange is converted into a sequential synchronous method or procedure call. The parallel processing of the objects communicating with each other is very limited.
- Active objects A process is started for each object. This procedure leads to high resource consumption and can therefore only be realized with a limited number of objects.
- the object of the invention is therefore to design a method for message transmission between so-called different processes assigned client and server instances of a distributed system in such a way that the implementation of the method is as high as possible reusable and at the same time the maintainability is facilitated as much as possible.
- this is achieved by assigning a first process for message transmission between A client instance and at least one server instance assigned to at least one further process within a distributed system can also be used as partner instances provided as mutual communication partners.
- a first instance of the partner instances containing the first process selects at least one suitable further instance of the partner instances containing the at least one further process for message acceptance and forwarding.
- the further instance containing at least one further process forwards this message to at least one server instance addressed by it and optionally receives a message from the at least one server instance for forwarding to the client instance via the first instance containing the first process.
- the definition of the type of communication between the client instance and the at least one server instance is shifted to the partner instances containing a process and intended as mutual communication partners.
- the messages between the client instance and the first instance containing the first process and between the at least one server instance and the further instance containing at least one further process are synchronized, e.g. transmitted by procedure or method call.
- the message transmission between a first instance containing the first process and a further instance containing at least one further process can then take place asynchronously or synchronously, decoupled from the communication interfaces of the client instance and at least one server instance. This ensures maximum reusability, primarily with regard to the implementation of the client and at least one server instance.
- the maintainability is also considerably improved in that at most the communication interfaces between the first process containing the first process
- a further advantageous embodiment of the invention provides that the first instance containing the first process makes the selection of the further instance containing at least one further process on the basis of an assignment table.
- the type of messages that can be sent by the client instance and the address of the further instance containing at least one further process are entered in this assignment table.
- An assignment table has the advantage that its content can be changed at any time and enables the first instance containing the first process to be selected quickly.
- the selection made by the first instance containing the first process can be changed dynamically depending on the system load. This prevents system crashes and deadlocks when the processes are allocated to the processors.
- Another embodiment of the invention relates to the special case that the first process and the at least one further process coincide.
- the first instance containing the first process and the further instance containing the at least one further process are combined in one instance.
- the method according to the invention can be applied to this special case without adjustments.
- All instances can be implemented in the form of objects, the structure of which is determined by object classes.
- the first instance containing the first process and the further instance containing at least one further process preferably each have the structure of a common object. class. In this way, the principles of purely object-oriented programming are exploited, resulting in a high degree of modularity, high reusability and maintainability.
- Another embodiment of the invention can be seen in a very expedient use of the method according to the invention on a telephone switching system. Accordingly, all of the advantages mentioned above also come into play in connection with a telephone switching system.
- FIG. 1 shows an exemplary flow chart of the method according to the invention
- Figure 2 shows an application example in the area of a system alarm in a telecommunications system such as a telephone switching system
- FIG. 1 describes in a flowchart the message transmission between a client instance assigned to a first process and a server instance assigned to a further process.
- the instances client, server, the first instance containing the first process and the further instance containing the at least one further process, and the action which is carried out by the server instance are represented in the form of objects with boxes.
- the Client object corresponds to a client instance
- the Server object corresponds to a server instance
- the ObjectHandler1 object corresponds to a first active instance containing the first process.
- partner instances provided, the object ObjectHandler2 of a further active instance of the partner instances containing the further process, the object action of an action and the object confirmation action of a feedback action on a requested action.
- the active instances that contain the respective processes are identified by boxes with bold lines. The type of action is only determined when the special Action object is called.
- a client requests an action from the server, on which one
- the client calls the action and does not have to know which process or on which processor platform the action is to be carried out.
- the object handler provides the client with the invoke_action call procedure.
- the ObjectHandler1 is assigned a unique number (get handle number) and a timer is started (start timer), which triggers an error handling if the feedback does not arrive in time .
- the ObjectHandler searches for a partner instance intended as a communication partner, for example ObjectHandler2 (find target ObjectHandler), which is assigned to the action depending on the type of action, and transmits the message of the action request action_request to the ObjectHandler2.
- the ObjectHandler2 accepts the message, stores the address of its communication partner Objecthandlerl (disrupt communication partner) together with the number clearly assigned to the ObjectHandlerl and executes the procedure of the Action object (execute).
- the Action object then causes the server addressed by the client to execute the action by calling the action procedure.
- the Server in an analogous way indirectly returns feedback to the client. Accordingly, the following procedure calls, message transfers and actions run from the server towards the client.
- Procedure call Invoke_action delete address of the communication partner and transfer of the action request message for the feedback action_request from ObjectHandler2 to ObjectHandlerl, which is known to ObjectHandler2 due to the assigned number, ObjectHandlerl deletes the assigned number (release handle number) and stops the timer (stop timer), to transmit the feedback, Objecthandlerl calls the execute procedure of the Confirm Action object and lastly, the Conform Action object executes the client's confirm_action procedure.
- the inventive method of message transmission from the client to the server proceeds in a similar manner to that described above. There are no steps like get handle number, start timer, disturb communication partner and the steps regarding the feedback from the server towards the client.
- the ObjectHandlerl will either pass the action_request message to an ObjectHandler2 and the ObjectHandler2 ensures that the action is carried out by several servers, or the ObjectHandlerl sends several action_request messages to several ObjectHandler2 containing the server process, each of which causes the server to execute the action.
- the ObjectHandlerl sends several action_request messages to several ObjectHandler2 containing the server process, each of which causes the server to execute the action.
- a combination of the two variants mentioned is also possible.
- the ObjectHandlerl is used in each case send an action_request message to the ObjectHandler2 containing the different processes and the ObjectHandler2 each cause the server to execute the action.
- each server can also act as a client and each client can also act as a server, and client and server function can be combined in one object.
- the objects ObjectHandlerl and ObjectHandler2 are combined into a single object.
- the ObjectHandler1 sends the action_request message to itself in this case.
- Figure 2 shows an application example in the area of a system alarm in a telecommunication system e.g. a telephone switching system.
- An alarm balance monitor (ABM) object has the task of drawing an alarm balance sheet for all alarms of the alarmable instances (AMOI) it monitors.
- the alarm balance monitor requires at least one so-called SIBS object, which is located on a processor platform and provides it with a collected information relating to the monitored alarmable instances.
- the boxes represent the objects Caller, AMOI (AlarmManagerObjectInstance), SIBS (SiteBalanceSupply) and ABM (AlarmBalanceMonitor).
- the arrows can be used to transmit messages across process boundaries indicated the objects.
- the message transmission corresponds to the message transmission between client and server described in FIG. 1.
- the Caller object can act as a client and the AMOI object as a server.
- a monitored alarmable instance AMOI receives a new alarm from a caller, checks the parameters determining the alarm (checkjparams) and creates a new alarm instance (create contained alarm).
- - Confirm A feedback from the instance AMOI to the instance Caller after the system alarm call set_alarm.
- At least one server object SIBS is requested to collect the information required for the alarm balance (aecumulate alarm status of all associated AMOI).
- the server object ABM is then requested to receive the at least one SIBS object Collect information for the alarm balance (accumulate alarm status of all associated SIBS).
- the messages are transmitted from one object to another object via an active first instance and via an active further partner instance, e.g. via the ObjectHandler1 and via the ObjectHandler2 from FIG. 1, both of which are not shown in FIG. 2.
- the selection of the object handler 2 made by the ObjectHandler 1 can be made on the basis of an assignment table.
- the assignment table looks like this, for example:
- the assignment of the ObjectHandler2 can be changed depending on the system load.
Abstract
Eine einen ersten Prozeß enthaltende erste Instanz (ObjectHandler1) von als gegenseitige Kommunikationspartner vorgesehenen Partnerinstanzen wählt nach Empfang einer von der Clientinstanz (Client) an wenigstens eine Serverinstanz (Server) gerichtete Nachricht mindestens eine geeignete den mindestens einen weiteren Prozeß enthaltenden weitere Instanz (ObjectHandler2) der Partnerinstanzen zur Nachrichtenannahme und -weitergabe aus. Die mindestens eine den mindestens einen weiteren Prozeß enthaltende weitere Instanz leitet diese Nachricht zu wenigstens einer von ihr adressierten Serverinstanz weiter und erhält gegebenfalls von der wenigstens einen Serverinstanz eine Nachricht zur Weiterleitung über die den ersten Prozeß enthaltende erste Instanz an die Clientinstanz.
Description
Beschreibung
Verfahren zur Nachrichtenübertragung zwischen einer einem ersten Prozeß zugewiesenen Clientinstanz und wenigstens einer mindestens einem weiteren Prozeß zugewiesenen Serverinstanz innerhalb eines verteilten Systems
Die Erfindung betrifft ein Verfahren zur Nachrichtenübertragung zwischen einer einem ersten Prozeß zugewiesenen Client- instanz und wenigstens einer mindestens einem weiteren Prozeß zugewiesenen Serverinstanz innerhalb eines verteilten Systems .
Verteilte Systeme spielen vorzugsweise in heutigen Telekommu- nikationssystemen, die in der Regel Multiprozessorsysteme sind, eine besondere Rolle. Ein verteiltes System ist insbesondere dadurch charakterisiert, daß Prozesse jeweils unterschiedlichen Prozessoren zugeteilt werden können, wobei sich die Prozessoren gegebenfalls auf örtlich getrennten Plattfor- men im verteilten System befinden können. Einer der wichtigsten Aspekte bei der Kommunikation zwischen verschiedenen Prozessen eines verteilten Systems ist dabei die Plattform- Transparenz. Damit ist gemeint, daß ein Prozeß, der eine Nachricht an einen anderen Prozeß senden will, die Plattform, auf der der andere Prozeß gerade abläuft, nicht kennen muß. Solch ein komplexes verteiltes System muß heutzutage noch vielen weiteren Anforderungen genügen. Es muß sich unter anderem als äußerst zuverlässig, möglichst flexibel sowie offen für Anpassungen und Erweiterungen erweisen. Die Software ei- nes derartigen komplexen verteilten Systems soll daher hochgradig modular mit fest definierten offenen Schnittsstellen nach außen gestaltet sein, damit die einzelnen Module der Software leicht anpassungsfähig und vor allem wiederverwendbar sind.
Um den genannten Anforderungen insbesondere der Wiederverwendbarkeit von Software einigermaßen gerecht zu werden, wird
die Software zu einem solchen verteilten System mit Hilfe objektorientierter Entwurfmethoden und objektorientierter Programmierung erstellt. Jedoch ist die in verteilten Systemen notwendige Zuordnung von Objekten untereinander, die meist unterschiedlichen und gegebenfalls nebenläufigen Prozessen zugewiesen werden, nicht zufriedenstellend gelöst. Teilweise muß sogar ein rein objektorientierter Systementwurf in herkömmliche prozedurale Programmiertechniken aufgebrochen werden, wodurch der mit der Objektorientierung erreichte Effekt der Wiederverwendung von Programmteilen mehr oder weniger verloren geht.
Derzeit werden bei der Einführung von Nebenläufigkeit und Parallelverarbeitung in die Welt der Objekte folgende bekann- te Ansätze diskutiert:
• Implizite Nebenläufigkeit : Bei der Implementierung von implizierter Nebenläufigkeit gibt es zwei Möglichkeiten:
- Passive Objekte: Ein asynchroner Nachrichtenaustausch wird in einen sequenziellen synchronen Methoden- bzw. Prozeduraufruf umgewandelt. Hierbei wird die Parallelverarbeitung der miteinander kommunizierenden Objekte sehr eingeschränkt. - Aktive Objekte: Für jedes Objekt wird ein Prozeß gestartet. Dieses Vorgehen führt zu einem hohen Ressourcenverbrauch und ist deshalb nur mit einer begrenzten Anzahl von Objekten realisierbar.
• Explizite Nebenläufigkeit: Hierbei wird entweder eine
Gruppe von Objekten (objektbezogen) , wie in einem Artikel von A. Coutts, J. M. Edwards, Model-Driven Distributed Systems, IEEE Concurrency, Juli 1997, S. 55-63 beschrieben, oder mehrere Ereignisse in einer Ablaufsequenz (aufgaben- bezogen) , wie in einem Artikel von M. Awad, J. Ziegler, A Practical Approach to the Design of Concurrency in Object- Oriented Systems, Software - Practice and Experience, Sep-
tember 1997, Vol. 27(9), S. 1013-1034 erläutert, einem Prozeß zugewiesen. Bei Betrachtung der rechten Hälfte der Figur 3 im genannten Artikel von Awad/Ziegler und der Figur 5 im genannten Artikel von Coutts/Edwards ist an den Schnittstellen zwischen den Objekten, die teilweise gleichzeitig Schnittstellen zwischen den Prozessen darstellen, zu erkennen, daß die Kommunkation zwischen den Objekten sowohl durch synchrone Methodenaufrufe als auch durch Interprozeßkommunikation in Form einer asynchronen Nachrichtenweitergabe erfolgt. Eine derartige Festlegung der Kommunikationsart an den Schnittstellen von Objekten hat den Nachteil, daß die Wiederverwendbarkeit und die Wartbarkeit der Objekte erheblich erschwert wird.
Insbesondere im Zusammenhang mit der Kommunikation zwischen verschiedenen Objekten eines verteilten Systems, auch Instanzen genannt, die untereinander in der Regel in einem sogenannten Client/Server-Verhältnis stehen und die verschiedenen Prozessen zugewiesen sind, ist die vorstehend erläuterte Vor- gehensweise hinsichtlich der in einem solchen komplexen System erwünschten Wiederverwendbarkeit und Wartbarkeit eine sehr ungünstige Lösung.
Die Aufgabe der Erfindung besteht daher darin, ein Verfahren zur Nachrichtenübertragung zwischen sogenannten jeweils unterschiedlichen Prozessen zugewiesenen Client- und Serverinstanzen eines verteilten Systems dahingehend auszugestalten, daß bezüglich der Implementierung des Verfahrens eine möglichst hohe Wiederverwendbarkeit gegeben ist und zugleich die Wartbarkeit möglichst erleichtert wird.
Diese Aufgabe wird durch die im Anspruch 1 angegebenen Merkmale gelöst. Weitere Ausgestaltungen der Erfindung sind in Unteransprüchen gekennzeichnet.
Erfindungsgemäß wird dies dadurch erreicht, daß zur Nachrichtenübertragung zwischen einer einem ersten Prozeß zugewiese-
nen Clientinstanz und wenigstens einer mindestens einem weiteren Prozeß zugewiesenen Serverinstanz innerhalb eines verteilten Systems zusätzlich als gegenseitige Kommunikations- partner vorgesehene Partnerinstanzen eingesetzt werden. Eine den ersten Prozeß enthaltende erste Instanz der Partnerinstanzen wählt nach Empfang einer von der Clientinstanz an wenigstens eine Serverinstanz gerichtete Nachricht mindestens eine geeignete den mindestens einen weiteren Prozeß enthaltende weitere Instanz der Partnerinstanzen zur Nachrichtenan- nähme und -weitergäbe aus. Die mindestens einen weiteren Prozeß enthaltende weitere Instanz leitet diese Nachricht zu wenigstens einer von ihr adressierten Serverinstanz weiter und erhält gegebenfalls von der wenigstens einen Serverinstanz eine Nachricht zur Weiterleitung über die den ersten Prozeß enthaltende erste Instanz an die Clientinstanz.
Auf diese Weise wird die Festlegung der Kommunikationsart zwischen der Clientinstanz und der mindestens einen Serverinstanz in die einen Prozeß enthaltenden, als gegenseitige Kom- munikationspartner vorgesehenen Partnerinstanzen verlagert. So werden die Nachrichten zwischen der Clientinstanz und der den ersten Prozeß enthaltenden ersten Instanz sowie zwischen der mindestens einen Serverinstanz und der mindestens einen weiteren Prozeß enthaltenden weiteren Instanz synchron z.B. durch Prozedur- bzw. Methodenaufruf übertragen. Die Nachrichtenübertragung zwischen einer den ersten Prozeß enthaltenden ersten Instanz und einer mindestens einen weiteren Prozeß enthaltenden weiteren Instanz kann dann entkoppelt von den Kommunikationsschnittstellen der Clientinstanz und mindestens einen Serverinstanz asynchron oder synchron erfolgen. Dadurch wird eine maximale Wiederverwendbarkeit vorwiegend bezüglich der Implementierung der Client- und der mindestens einen Serverinstanz erreicht. Die Wartbarkeit wird ebenfalls erheblich verbessert dadurch, daß allenfalls die Kommunikationsschnitt- stellen zwischen der den ersten Prozeß enthaltenden ersten
Instanz und der mindestens einen weiteren Prozeß enthaltenden weiteren Instanz angepaßt werden müssen, jedoch die Kommuni-
kationsschnittstellen der Client- und der mindestens einen Severinstanz unberührt bleiben.
Eine weitere vorteilhafte Ausgestaltung der Erfindung sieht vor, daß die den ersten Prozeß enthaltenden erste Instanz die Auswahl der mindestens einen weiteren Prozeß enthaltenden weiteren Instanz anhand einer Zuordnungstabelle trifft. In dieser Zuordnungstabelle ist die Art der von der Clientinstanz aussendbaren Nachrichten und die Adresse der mindestens einen weiteren Prozeß enthaltenden weiteren Instanz eingetragen. Eine Zuordnungstabelle hat den Vorteil, daß ihr Inhalt jederzeit änderbar ist, und der den ersten Prozeß enthaltenden ersten Instanz eine schnelle Auswahl ermöglicht.
Gemäß einer zweckmäßigen Weiterbildung der Erfindung ist die durch die den ersten Prozeß enthaltende ersten Instanz getroffene Auswahl dynamisch in Abhängigkeit von der Systemauslastung änderbar. Dadurch können Systemabstürze sowie Verklemmungen bei der Zuteilung der Prozesse auf die Prozessoren vermieden werden.
Eine weitere Ausgestaltung der Erfindung betrifft den Spezi- alfall, daß der erste Prozeß und der mindestens eine weitere Prozeß zusammenfallen. In diesem Fall sind die den ersten Prozeß enthaltende erste Instanz und die den mindestens einen weiteren Prozeß enthaltende weitere Instanz in einer Instanz vereinigt. Dadurch kann das erfindungsgemäße Verfahren ohne Anpassungen auf diesen Spezialfall angewendet werden.
Eine weitere nützliche Ausgestaltung der Erfindung ist in der Art der Implementierung zu sehen. So können sämtliche Instanzen (Client-, Server- , die den ersten Prozeß enthaltende Instanz und Partnerinstanz) in Form von Objekten implementiert werden, deren Struktur durch Objektklassen festgelegt wird. So weisen die den ersten Prozeß enthaltende erste Instanz und die mindestens einen weiteren Prozeß enthaltende weitere Instanz vorzugsweise jeweils die Struktur einer gemeinsamen Ob-
jektklasse auf. Auf diese Weise werden die Grundsätze der rein objektorientierten Programmierung ausgenutzt, wodurch ein hoher Grad an Modularität, eine hohe Wiederverwendbarkeit und Wartbarkeit erreicht wird.
Eine weitere Ausgestaltung der Erfindung ist in einer sehr zweckmäßigen Verwendung des erfindungsgemäßen Verfahrens auf ein Fernsprechvermittlungssytem zu sehen. Demnach kommen alle vorstehend erwähnten Vorteile auch im Zusammenhang mit einem Fernsprechvermittlungssystem zum Tragen.
Nachstehend wird ein Ausführungsbeispiel der Erfindung unter Bezugnahme auf eine Zeichnung näher beschrieben.
In der Zeichnung zeigen:
Figur 1 ein beispielhaftes Ablaufdiagramm des erfindungsgemäßen Verfahrens,
Figur 2 ein Anwendungsbeispiel im Bereich einer System-Alarmierung in einem Telekommunikationssystem wie z.B. einem FernsprechvermittlungsSystem
Eine Legende zu den Figuren ist im Anhang am Ende der Be- Schreibung zu finden.
Figur 1 beschreibt in einem Ablaufdiagramm die Nachrichtenübertragung zwischen einer einem ersten Prozeß zugewiesenen Clientinstanz und einer einem weiteren Prozeß zugewiesenen Serverinstanz. Die Instanzen Client, Server , die den ersten Prozeß enthaltende erste Instanz und die den mindestens einen weiteren Prozeß enthaltende weitere Instanz sowie die Aktion, die von der Serverinstanz ausgeführt wird, werden in Form von Objekten mit Kästchen dargestellt. So entpricht das Objekt Client einer Clientinstanz, das Objekt Server einer Serverinstanz, das Objekt ObjectHandler1 einer den ersten Prozeß enthaltenden ersten aktiven Instanz der als gegenseitige Kommu-
nikationspartner vorgesehenen Partnerinstanzen, das Objekt ObjectHandler2 einer den weiteren Prozeß enthaltenden weiteren aktiven Instanz der Partnerinstanzen, das Objekt Action einer Aktion und das Objekt Confirm Action einer Rückmeldungsaktion auf eine angeforderte Aktion. Die aktiven Instanzen, die die jeweiligen Prozesse enthalten, sind hierbei durch Kästchen mit fett gezeichneten Linien gekennzeichnet. Die Art der Aktion wird erst beim Aufruf des speziellen Objekts Action bestimmt.
Im Falle einer vom Client angeforderten vom Server auszuführenden Aktion mit Rückmeldung läuft das Verfahren beispielsweise wie folgt ab:
Ein Client fordert vom Server eine Aktion an, auf die eine
Rückmeldung erfolgen soll. Der Client ruft die Aktion auf und muß nicht wissen, welcher Prozeß bzw. auf welcher Prozessor- Plattform die Aktion ausgeführt werden soll. Der Objecthand- lerl stellt den Client dafür die Aufrufprozedur invoke_action bereit. Nach dem Aufruf der Prozedur invoke_action, in der objektorientierten Programmierung auch Methode genannt, wird dem ObjectHandler1 eine eindeutige Nummer (get handle number) zugeordnet und es wird ein Zeitnehmer gestartet (start ti- mer) , der bei nicht rechtzeitigem Eintreffen der Rückmeldung eine Fehlerbehandlung auslöst. Danach sucht der ObjectHand- lerl nach einer als Kommunikationspartner vorgesehenen Partnerinstanz z.B. ObjectHandler2 (find target ObjectHandler), der der Aktion abhängig von der Art der Aktion zugeordnet ist, und übermittelt die Nachricht der Aktionsanforderung ac- tion_request an den ObjectHandler2. Der ObjectHandler2 nimmt die Nachricht entgegen, speichert die Adresse seines Kommunikationspartners Objecthandlerl (störe communication partner) zusammen mit der dem ObjectHandlerl eindeutig zugeordneten Nummer und führt die Prozedur des Objekts Action aus (execu- te) . Das Objekt Action veranlaßt daraufhin den vom Client adressierten Server zur Ausführung der Aktion durch den Prozeduraufruf action. Nach der Ausführung der Aktion sendet der
Server in analoger Weise indirekt eine Rückmeldung zum Client zurück. Demnach laufen folgende Prozeduraufrufe, Nachrichtenübertragungen und Aktionen vom Server in Richtung zum Client ab. Prozeduraufruf Invoke_action, lösche Adresse des Kommuni- kationspartners sowie Übertragung der Aktionsanforderungs- nachricht für die Rückmeldung action_request vom ObjectHand- ler2 zum ObjectHandlerl, der dem ObjectHandler2 aufgrund der zugeordneten Nummer bekannt ist, ObjectHandlerl löscht die zugeordnete Nummer (release handle number) und stoppt den Zeitnehmer (stop timer) , zur Übermittlung der Rückmeldung ruft Objecthandlerl die Prozedur execute des Objekts Confirm Action auf und zuletzt führt Objekt Conform Action die Prozedur confirm_action des Client aus.
Im Falle einer vom Client angeforderten Aktion des Servers ohne Rückmeldung läuft das erfindungsgemäße Verfahren der Nachrichtenübertragung vom Client zum Server in ähnlicher Weise wie vorstehend beschrieben ab. Es entfallen die Abiaufschritte get handle number, start timer, störe communication partner und die Schritte bezüglich der Rückmeldung vom Server in Richtung zum Client.
Im Falle eines sogenannten Broadcasts, d.h. ein Client fordert von mehreren Servern eine Aktion an, gibt es verschiede- ne Möglichkeiten:
- Wenn die vom Client adressierten Server einem gemeinsamen Prozeß zugewiesen sind, wird der ObjectHandlerl die ac- tion_request-Nachricht entweder an einen ObjectHandler2 weitergeben und der ObjectHandler2 sorgt dafür, daß die Aktion von mehreren Servern ausgeführt wird, oder der ObjectHandlerl sendet mehrere action_request-Nachrichten an mehrere den Server-Prozeß enthaltende ObjectHandler2, die jeweils die Server zur Ausführung der Aktion veranlassen. Auch ist eine Kombination aus beiden genannten Varianten möglich.
- Wenn die vom Client adressierten Server unterschiedlichen Prozessen zugewiesen sind, wird der ObjectHandlerl jeweils
eine action_request-Nachricht an die die unterschiedlichen Prozessen enthaltenden ObjectHandler2 senden und die Ob- jectHandler2 veranlassen jeweils die Server zur Ausführung der Aktion.
Auch hier sind sämtliche Kombinationen der erwähnten Möglichkeiten denkbar.
Üblicherweise sind in einem verteilten System mehrere Aktio- nen auszuführen, so daß selbstverständlich jeder Server auch als Client und jeder Client auch als Server agieren kann sowie in einem Objekt Client- und Serverfunktion vereint sein können.
Die vorteilhafte Entkopplung der Prozeßschnittstellen von den Objektschnittstellen des Client und des Servers ist daran zu erkennen, daß die Kommunikation zwischen den Client und dem Server synchron durch Prozedur- bzw. Methodenaufrufe realisiert wird und nur die Nachrichtenübergabe zwischen den Ob- jectHandlerl und ObjectHandler2 gegebenfalls asynchron über die Prozeßgrenzen hinweg durchgeführt wird.
In dem Spezialfall, daß der Client und der Server, die sich beispielsweise auf einer gemeinsamen Plattform befinden, dem- selben Prozeß zugewiesen werden können, sind die Objekte ObjectHandlerl und ObjectHandler2 zu einem einzigen Objekt vereinigt. Gemäß der Figur 1 sendet der ObjectHandlerl die ac- tion_request-Nachricht in diesem Fall an sich selbst.
Figur 2 zeigt ein Anwendungsbeispiel im Bereich einer System- Alarmierung in einem Telekommunikationssystem z.B. einem FernsprechvermittlungsSystem.
Bei einer System-Alarmierung gibt es beispielsweise folgende Objekte, die zugleich als Client und Server agieren und untereinander unterschiedliche Aktionen anfordern können. Au-
ßerde können sich die Objekte auf verschiedenen Plattformen befinden.
Ein Objekt Alarmbilanz-Monitor (ABM) hat die Aufgabe, eine Alarmbilanz über alle Alarme der von ihm überwachten alarmierbaren Instanzen (AMOI) zu ziehen. Um die Alarmbilanz ziehen zu können, benötigt der Alarmbilanz-Monitor mindestens ein sogenanntes SIBS-Objekt, das sich auf einer Prozessorplattform befindet und ihm eine gesammelte Information bezüg- lieh der überwachten alarmierbaren Instanzen liefert.
Die Kästchen stellen die Objekte Caller, AMOI (AlarmManage- dObjectlnstance) , SIBS (SiteBalanceSupply) und ABM (AlarmBa- lanceMonitor) dar. Durch die Pfeile, deren Art in der Legende im Anhang nicht aufgeführt ist, wird die Nachrichtenübertragung gegebenfalls über Prozeßgrenzen hinweg zwischen den Objekten angedeutet. Die Nachrichtenübertragung entspricht dabei der in der Figur 1 beschriebenen Nachrichtenübertragung zwischen Client und Server. So kann beispielsweise das Cal- ler-Objekt als Client und das AMOI-Objekt als Server agieren. Entsprechendes gilt auch für die übrigen Objekte AMOI und SIBS sowie SIBS und ABM.
Nach einem System-Alarm-Aufruf set_alarm wird beispielsweise folgender Ablauf von Aktionen ausgelöst:
- Set_alarm: Eine überwachte alarmierbare Instanz AMOI erhält von einem Aufrufer Caller einen neuen Alarm, prüft die den Alarm bestimmenden Parameter (checkjparams) und kreiert eine neue Alarminstanz (create contained alarm) . - Confirm: Eine Rückmeldung von der Instanz AMOI an die Instanz Caller nach dem System-Alarm- ufruf set_alarm.
- Balance SIBS: Mindestens ein Serverobjekt SIBS wird aufgefordert, die erhaltenen für die Alarmbilanz notwendigen Informationen zu sammeln (aecumulate alarm Status of all associated AMOI) .
- Balance ABM: Danach wird das Serverobjekt ABM aufgefordert, die von den mindestens einen SIBS-Objekt erhaltenen
Informationen für die Alarmbilanz zu sammeln (accumulate alarm Status of all associated SIBS) .
Da die Aktionen über Prozeßgrenzen hinweg angefordert werden, werden die Nachrichten von einem Objekt zu einem weiteren Objekt über eine aktive erste Instanz und über eine aktive weitere Partnerinstanz übertragen wie z.B. über den ObjectHandlerl und über den ObjectHandler2 aus Figur 1, die beide in der Figur 2 nicht dargestellt sind.
Die durch den ObjectHandlerl getroffende Auswahl des Objekt- Handlers 2 kann anhand einer Zuordnungstabelle vorgenommen werden. Die Zuordnungstabelle sieht beispielsweise wie folgt aus :
Sofern eine bestimmte Aktion von unterschiedlichen Serverobjekten ausgeführt werden kann, kann die Zuordnung des Ob- jectHandler2 abhängig von der Systemauslastung geändert werden.
ANHANG
Legende zu den Figuren:
= Instanz = Prozeduraufruf mit Ausführung (synchron)
= Senden einer Nachricht (asynchron)I
= aktive Instanz, die einen Prozess enthält
= Instanz wartet auf Rückmeldung
Claims
1. Verfahren zur Nachrichtenübertragung zwischen einer einem ersten Prozeß zugewiesenen Clientinstanz (Client) und we- nigstens einer mindestens einem weiteren Prozeß zugewiesenen Serverinstanz (Server) innerhalb eines verteilten Systems, wobei eine den ersten Prozeß enthaltende erste Instanz (ObjectHandlerl) von als gegenseitige Kommunikationspartner vorgesehenen Partnerinstanzen nach Empfang ei- ner von der Clientinstanz an wenigstens eine Serverinstanz gerichteten Nachricht mindestens eine geeignete den mindestens einen weiteren Prozeß enthaltende weitere Instanz (ObjectHandler2) der Partnerinstanzen zur Nachrichtenannahme und -Weitergabe auswählt, die die Nachricht zu we- nigstens einer von ihr adressierten Serverinstanz weiterleitet und gegebenfalls von der wenigstens einen Serverinstanz eine Nachricht zur Weiterleitung über die den ersten Prozeß enthaltende erste Instanz an die Clientinstanz erhält.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die den ersten Prozeß enhaltende erste Instanz die Auswahl der mindestens einen weiteren Prozeß enthaltenden weiteren Instanz anhand einer Zuordnungstabelle zwischen der Art der von der Clientinstanz aussendbaren Nachrichten und der Adresse der mindestens einen weiteren Prozeß enthaltenden weiteren Instanz trifft.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß die durch die den ersten Prozeß enthaltende erste
Instanz getroffene Auswahl dynamisch in Abhängigkeit von der Systemauslastung änderbar ist.
4. Verfahren nach einem der vorhergehenden Ansprüche, da- durch gekennzeichnet, daß dann, wenn der erste
Prozeß und der mindestens eine weitere Prozeß zusammenfallen, die den ersten Prozeß enthaltende erste Instanz und die den mindestens einen weiteren Prozeß enthaltende weitere Instanz in einer Instanz vereinigt sind.
5. Verfahren nach einem der vorhergehenden Ansprüche, da- durch gekennzeichnet, daß sämtliche Instanzen in Form von Objekten implementiert sind, deren Struktur durch Objektklassen festgelegt wird.
6. Verfahren nach einem der vorhergehenden Ansprüche, da- durch gekennzeichnet, daß es auf ein Fernsprechvermittlungssystem angewendet wird.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE10080578T DE10080578D2 (de) | 1999-03-09 | 2000-03-01 | Verfahren zur Nachrichtenübertragung zwischen einer einem ersten Prozess zugewiesenen Clientinstanz und wenigstens einer mindestens einem weiteren Prozess zugewiesenen Serverinstanz innerhalb eines verteilten Systems |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE1999110345 DE19910345A1 (de) | 1999-03-09 | 1999-03-09 | Verfahren zur Nachrichtenübertragung zwischen einer einem ersten Prozeß zugewiesenen Clientinstanz und wenigstens einer mindestens einem weiteren Prozeß zugewiesenen Serverinstanz innerhalb eines verteilten Systems |
| DE19910345.3 | 1999-03-09 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| WO2000054150A2 true WO2000054150A2 (de) | 2000-09-14 |
| WO2000054150A3 WO2000054150A3 (de) | 2001-04-05 |
| WO2000054150A9 WO2000054150A9 (de) | 2001-09-20 |
Family
ID=7900257
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/DE2000/000623 WO2000054150A2 (de) | 1999-03-09 | 2000-03-01 | Verfahren zur nachrichtenübertragung zwischen einer einem ersten prozess zugewiesenen clientinstanz und wenigstens einer mindestens einem weiteren prozess zugewiesenen serverinstanz innerhalb eines verteilten systems |
Country Status (3)
| Country | Link |
|---|---|
| CN (1) | CN1350673A (de) |
| DE (2) | DE19910345A1 (de) |
| WO (1) | WO2000054150A2 (de) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0623876A2 (de) * | 1993-04-30 | 1994-11-09 | International Business Machines Corporation | Vorrichtung und Verfahren zur Bindung von Objektverwaltern für kooperative Verarbeitung in einer Objektorientierten Rechnerumgebung |
| GB2305270A (en) * | 1995-09-15 | 1997-04-02 | Ibm | Bridge for a client-server environment |
| WO1998002814A1 (en) * | 1996-07-15 | 1998-01-22 | Next Software, Inc. | Method and apparatus for dynamically brokering object messages among object models |
| EP0834807A1 (de) * | 1996-08-26 | 1998-04-08 | Tandem Computers Incorporated | Verfahren und Gerät zur Durchführung von effizienten CORBA-Transaktionen |
| EP0860776A1 (de) * | 1997-02-19 | 1998-08-26 | Hitachi, Ltd. | Interobjekt-Kommunikationsverfahren |
| US5802367A (en) * | 1995-07-07 | 1998-09-01 | Microsoft Corporation | Method and system for transparently executing code using a surrogate process |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5329619A (en) * | 1992-10-30 | 1994-07-12 | Software Ag | Cooperative processing interface and communication broker for heterogeneous computing environments |
| US6446204B1 (en) * | 1997-10-31 | 2002-09-03 | Oracle Corporation | Method and apparatus for implementing an extensible authentication mechanism in a web application server |
-
1999
- 1999-03-09 DE DE1999110345 patent/DE19910345A1/de not_active Withdrawn
-
2000
- 2000-03-01 WO PCT/DE2000/000623 patent/WO2000054150A2/de active Application Filing
- 2000-03-01 CN CN 00807384 patent/CN1350673A/zh active Pending
- 2000-03-01 DE DE10080578T patent/DE10080578D2/de not_active Expired - Fee Related
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0623876A2 (de) * | 1993-04-30 | 1994-11-09 | International Business Machines Corporation | Vorrichtung und Verfahren zur Bindung von Objektverwaltern für kooperative Verarbeitung in einer Objektorientierten Rechnerumgebung |
| US5802367A (en) * | 1995-07-07 | 1998-09-01 | Microsoft Corporation | Method and system for transparently executing code using a surrogate process |
| GB2305270A (en) * | 1995-09-15 | 1997-04-02 | Ibm | Bridge for a client-server environment |
| WO1998002814A1 (en) * | 1996-07-15 | 1998-01-22 | Next Software, Inc. | Method and apparatus for dynamically brokering object messages among object models |
| EP0834807A1 (de) * | 1996-08-26 | 1998-04-08 | Tandem Computers Incorporated | Verfahren und Gerät zur Durchführung von effizienten CORBA-Transaktionen |
| EP0860776A1 (de) * | 1997-02-19 | 1998-08-26 | Hitachi, Ltd. | Interobjekt-Kommunikationsverfahren |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2000054150A9 (de) | 2001-09-20 |
| DE19910345A1 (de) | 2000-09-21 |
| CN1350673A (zh) | 2002-05-22 |
| WO2000054150A3 (de) | 2001-04-05 |
| DE10080578D2 (de) | 2002-03-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| DE69530734T2 (de) | System und Verfahren zur Workflow-Verwaltung | |
| DE69728601T2 (de) | Client-Server-Architektur mit nebenläufigen Servern | |
| DE602005004334T2 (de) | Nms zur Verarbeitung von Multi-Server Ereignissen | |
| DE69734432T2 (de) | Verfahren und Vorrichtung zur Absendung von Clientverfahrenanrufen in einem Server Rechnersystem | |
| DE19511770B4 (de) | Datensuchsystem sowie Verfahren zum Nachrüsten eines solchen | |
| DE112008002439T5 (de) | Architektur und Protokoll für die erweiterbare und skalierbare Kommunikation | |
| DE102005016587B4 (de) | Verfahren zum Bilden einer gemeinsamen Kommunikationssitzung, Verfahren zum Bilden einer ersten Kommunikationssitzung und einer zweiten Kommunikationssitzung aus einer gemeinsamen Kommunikationssitzung und Kommunikationssitzungs-Steuerungs-Server | |
| DE69732221T2 (de) | Verfahren zum Anbieten von einem Dienst an Fernmeldenetzbenutzern | |
| DE60312498T2 (de) | Wahlfähigster server in einer umgebung mit einer allgemeinen arbeit-warteschlange | |
| DE69828544T2 (de) | Verfahren und Vorrichtung zum Nachrichtenaustausch zwischen mehreren Nachrichtenaustauschdiensten | |
| DE10222361C2 (de) | Verfahren zum Betreiben eines verteilten Rechnernetzwerks umfassend mehrere verteilt angeordnete Rechner | |
| DE10296696T5 (de) | Dynamische Verteilung von Teilnehmern bei einer zentralisierten Telefonkonferenz | |
| EP0466948A1 (de) | Kommunikationssystem mit einem der zentralen Steuerung dienenden Multiprozessorsystem | |
| EP1049013A2 (de) | Interprozesskommunikationssystem | |
| WO2000054150A2 (de) | Verfahren zur nachrichtenübertragung zwischen einer einem ersten prozess zugewiesenen clientinstanz und wenigstens einer mindestens einem weiteren prozess zugewiesenen serverinstanz innerhalb eines verteilten systems | |
| EP1977583B1 (de) | Verfahren zur Übermittlung einer Nachricht und Netzwerk | |
| DE60016430T2 (de) | Verfahren und system zur übertragung einer meldungskette für datenbanken | |
| DE60221118T2 (de) | Dienst applikationsarchitektur für dienstenanbieter von integrierende kommunikationsnetzwerken | |
| DE60119553T2 (de) | Multiplexingeinheit, system und verfahren für die kommunikation über ein rechner-netzwerk | |
| EP0782810B1 (de) | Verfahren und anordnung zur auflösung von leistungsmerkmal-interaktionen in einem kommunikationssystem | |
| EP2815558A1 (de) | Übertragen von datenströmen zwischen einem endgerät und einem sicherheitsmodul | |
| DE60036976T2 (de) | Verfahren zur Änderung eines Protokolls zwischen verteilten Objekten | |
| DE10123822B4 (de) | Verfahren, System und maschinenlesbares Programmspeichergerät zur Überwachung einer Dienstverbindung zwischen einem Clientprozess und einem Serverprozess | |
| DE60004161T2 (de) | Schnittstelle zu einem Netzwerkverwaltungssystem eines Kommunikationsnetzes | |
| DE60036503T2 (de) | Verfahren zur Kommunikation zwischen Fernobjekten |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| WWE | Wipo information: entry into national phase |
Ref document number: 00807384.8 Country of ref document: CN |
|
| AK | Designated states |
Kind code of ref document: A2 Designated state(s): CN DE ID US |
|
| AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE |
|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
| DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
| AK | Designated states |
Kind code of ref document: A3 Designated state(s): CN DE ID US |
|
| AL | Designated countries for regional patents |
Kind code of ref document: A3 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE |
|
| AK | Designated states |
Kind code of ref document: C2 Designated state(s): CN DE ID US |
|
| AL | Designated countries for regional patents |
Kind code of ref document: C2 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE |
|
| COP | Corrected version of pamphlet |
Free format text: PAGES 6-12, DESCRIPTION, REPLACED BY NEW PAGES 6-12; PAGES 1/2-2/2, DRAWINGS, REPLACED BY NEW PAGES 1/2-2/2; AFTER RECTIFICATION OF OBVIOUS ERRORS AS AUTHORIZED BY THE INTERNATIONAL SEARCHING AUTHORITY |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 09936385 Country of ref document: US |
|
| REF | Corresponds to |
Ref document number: 10080578 Country of ref document: DE Date of ref document: 20020307 |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 10080578 Country of ref document: DE |
|
| 122 | Ep: pct application non-entry in european phase |