DE19832482A1

DE19832482A1 - Verfahren zur Informationsübertragung

Info

Publication number: DE19832482A1
Application number: DE19832482A
Authority: DE
Inventors: Axel Uhl
Original assignee: ABB Patent GmbH
Current assignee: ABB Patent GmbH
Priority date: 1998-07-20
Filing date: 1998-07-20
Publication date: 2000-01-27

Abstract

Die Erfindung bezieht sich auf ein Verfahren zur Übertragung von Information in einem verteilten Informationsverarbeitungssystem mit einem Kommunikationskanal zwischen Rechenprozessen, wobei der Kommunikationskanal bezüglich der Richtung der Initiierung eines Informationsaustausches insofern eingeschränkt ist, als die Initiierung nur in einer Richtung möglich ist, wie beispielsweise durch einen Firewall-Rechner gegeben. Diese Einschränkung wird durch folgendes Vorgehen überwunden: DOLLAR A a) von einem ersten Rechenprozeß wird in der zulässigen Richtung ein Verbindungsaufbau initiiert, der es einem zweiten Rechenprozeß ermöglicht, als Reaktion spontan Information in der Gegenrichtung zu übertragen, und DOLLAR A b) vom ersten Rechenprozeß wird die spontane Reaktion als Verbindungsaufbau interpretiert, der an sich aufgrund der bestehenden Einschränkung nicht möglich wäre.

Description

Die Erfindung bezieht sich auf ein Verfahren zur Informationsübertragung in einem verteilten Informationsverarbeitungssystem mit einem Kommunikationskanal zwi schen Rechenprozessen, wobei der Kommunikationskanal bezüglich der Richtung der Initiierung eines Informationsaustausches insofern eingeschränkt ist, als die Initi ierung nur in einer Richtung möglich ist. Eine solche Einschränkung ist beispielswei se bei einem Client-Server-System mit zwischengefügten Firewall-Rechner(n) gege ben.

Verteilte Internet-Applikationen erlangen zunehmend Bedeutung in verschiedenen Anwendungsgebieten. Beispiele für solche Internet-Anwendungen sind etwa Home banking und Internet-Shopping. Sie sind oftmals charakterisiert durch eine elektroni sche Auslieferung der Anwendung durch das Internet, Implementierung in der Pro grammiersprache Java, und Ablauffähigkeit in einem Web-Browser als Java-Applet.

Zunehmend werden zur Realisierung solcher Anwendungen objektorientierte Kom munikationsprotokolle eingesetzt; wie z. B. CORBA oder Java RMI, die es ermögli chen, die Kommunikation möglichst einfach, elegant und wartbar in die Programme zu integrieren.

Ein generelles Problem ergibt sich jedoch dadurch, daß Firmen und Institutionen die meisten Arbeitsplatzrechner hinter sogenannten Firewalls einrichten, die ein Ein dringen von außen auf diese Rechner verhindern. Außer ungewollt eindringender Information wird jedoch auch ein gewollter Verbindungsaufbau von außen auf die firmeninternen Arbeitsplatzrechner verhindert. Dadurch ergeben sich besondere Umstände, die bei der Entwicklung verteilter Internet-Anwendungen zu berücksichti gen sind.

Standards für die Kommunikation zwischen verteilten Objekten stellen beispielswei se CORBA (Common Object Request Broker Architecture), Java RMI (Remote Me thod Invocation) und Microsofts Distributed Common Object Model (DCOM) dar. Diese Systeme ermöglichen eine flexible Verteilung objektorientierter Applikationen. Die Hauptleistungsmerkmale dieser Standards bestehen darin, Funktions-/Metho denaufrufe auf Objekten, die sich auf beliebigen Rechnern im Netzwerk befinden, transparent abzuwickeln. Dazu gehört neben dem eigentlichen Aufruf die Übertra gung der Parameter und der Ergebnisse.

CORBA als auch RMI sind derzeit in der Programmiersprache Java zugänglich. Durch die Integration von Java mit allen gängigen Web-Browsern können dadurch im Browser lauffähige Java-Anwendungen (sog. Applets) diese Kommunikationsme chanismen grundsätzlich nutzen.

Im Umfeld des Internets hat sich das objektorientierte Paradigma für den Entwurf von Anwendungen durchgesetzt. Mittlerweile haben dabei die objektorientierten Ent wurfsmuster eine erhebliche Bedeutung erlangt. Eines dieser Muster ist das Obser ver-Pattern. Es beschreibt ein einfaches Verfahren zur Implementierung einer "Beobachtungsbeziehung" zwischen zwei oder mehr Objekten. Ändert sich ein be obachtetes Objekt, so werden die Beobachter davon in Kenntnis gesetzt.

Dieses Muster basiert auf der Idee, im beobachteten Objekt die Menge der Beobach ter zu verwalten und im Falle einer Benachrichtigung diese an alle registrierten Be obachter zu senden. Letzteres erfolgt im Zusammenhang mit CORBA, RMI oder DCOM in der Regel durch einen Methodenaufruf durch das beobachtete Objekt auf sämtlichen Beobachtern.

Das Observer-Pattern wird am häufigsten zur Realisierung des Model-View-Con troller Prinzips verwendet. Es geht dabei um die Entkoppelung der Informations anzeige von ihrer internen Repräsentation. Dabei wird das Muster eingesetzt, indem eine Anzeige-Komponente die entsprechende interne Repräsentation des anzuzei genden Datums in obigem Sinne "beobachtet" und somit bei Änderung des Datums eine Nachricht erhält. Die Komponente kann dann die Anzeige aktualisieren und somit dem geänderten Wert anpassen. Ein Beispiel wäre eine Kontostandsanzeige, die nach einer Überweisung aktualisiert werden muß. Der Vorteil der Anwendung des Musters liegt in besagter Entkoppelung, denn das beobachtete Objekt, hier der Kontostand, muß a priori keine Kenntnis über Anzahl und Beschaffenheit der Beob achter besitzen. Weitere Beobachter können dynamisch während des Programm laufs hinzugefügt oder entfernt werden.

Als Literatur zu dem erwähnten Stand der Technik werden genannt:
The Object Management Group, What is CORBA
http://www.omg.org/about/wicorba.htm
Robert Orfali, Dan Harkey, Jeri Edwards, Instant CORBA, John Wiley & Sons, 1997 Sun Microsystems, Java Remote Method Invocation,
http://java.sun.com/products/rmi
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns:
Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. H. Yoshida, Naruto University of Education, MVC (Model-View-Controller),
http://erpc1,naruto-u.ac.jp/∼geant4/thesis/mvc.html H. Yoshida, Smalltalk Software Development, SuperAscii Vol. 6 1991 bis Vol. 18 1992.

Bei der naheliegenden Implementierung in einem Client-Server-System, wie sie auch beispielsweise im Buch von Erich Gamma et al. vorgeschlagen wird, erfolgt üblicherweise ein Methodenaufruf vom Server zum Client. Der Server hält nämlich in der Regel die interne Repräsentation eines Datums, welches dann auf dem Client visualisiert wird.

Hierbei ergibt sich ein Problem, wenn der Client-Rechner sich in einem nach außen durch einen Firewall abgeschotteten Firmennetz befindet. In diesem Fall kann der Server keinen gewöhnlichen Methodenaufruf zum Client durchführen, da der Fire wall-Rechner die zugehörigen Datenpakete zurückweist.

Eine andere Möglichkeit besteht darin, Änderungen an Serverdaten durch wiederhol te Inspektionen, welche vom Client ausgelöst werden, festzustellen. Dabei wäre dann kein Aufruf vom Server zum Client notwendig. Jedoch wird in der Regel eine unbestimmte Anzahl von Methodenaufrufen vergeudet, ohne daß wirklich eine Ände rung stattgefunden hat. Man bezeichnet dieses Verfahren auch als "Active Polling", da hierbei der Client proaktiv Änderungen abfragt.

Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren zur Informationsübertra gung in einem verteilten Informationsverarbeitungssystem anzugeben, mit dem - trotz bestehender Einschränkung bezüglich der Initialisierungsrichtung - eine spon tane Änderungsmitteilung in der an sich gesperrten Richtung ermöglicht wird.

Diese Aufgabe wird durch ein Verfahren zur Informationsübertragung mit den im An spruch 1 angegebenen Merkmalen gelöst. Vorteilhafte Ausgestaltungen sind in wei teren Ansprüchen angegeben.

Eine weitere Beschreibung des erfindungsgemäßen Verfahrens, das hier auch als "Passive Polling" bezeichnet wird, erfolgt nachstehend anhand von Beispielen und der Zeichnungsfigur.

Unter Anwendung des Verfahrens kann man beispielsweise die Einschränkung der Firewall-Technologie für den Fall des Observer-Musters in einem Client-Server-Sys tem umgehen. Hierbei ruft der Client eine Methode auf dem Server auf, um Än derungen festzustellen. Diese wird auf dem Server zunächst auf ein Ereignis war tend blockiert und kehrt in zwei Fällen zurück:

- es gab eine Änderung der beobachteten Daten auf dem Server.
Der Server läßt in dem Moment, wo nach der klassischen Implementierung des Observer-Musters eigentlich ein Methodenaufruf vom Server zum Client erfolgen würde, die blockierte Methode durch Aufheben der Blockierung weiterlaufen. Die dann weiterlaufende Methode kehrt zum Client zurück und zeigt im Rückgabe wert die Art der Änderung an.
- der Client beendet die Beobachtungsbeziehung.
Dazu muß der Client eine entsprechende Methode auf dem Serverobjekt aufru fen, welche dann ebenfalls die blockierte Pollingmethode zurückkehren läßt. In diesem Fall zeigt das Resultat der zurückkehrenden Methode an, daß die Beob achtungsbeziehung aufgehoben wurde.

In beiden Fällen werden nur Aufrufe vom Client zum Server, nicht aber umgekehrt durchgeführt. Die Lösung gerät somit nicht in Konflikt mit bestehenden Firewalls.

Für den Entwickler bleibt die Implementierung des Musters ähnlich verborgen wie bei der Standardimplementierung. Bei letzterer wird die beobachtende Klasse als Unterklasse einer Observer-Klasse, die beobachtete Klasse als Unterklasse einer Observable-Klasse programmiert. Die Observer-Unterklasse muß dabei eine Metho de implementieren, die im Falle einer Notifikation aufgerufen werden soll (z. B. upda te), während Observable Methoden anbietet, um Änderungen an Beobachter zu melden (z. B. notifyObservers) und Beobachter an- und abzumelden (addObserver/re moveObserver). Als einziger Unterschied zu diesem Standard erfolgt bei der vor geschlagenen Lösung das An- und Abmelden durch einen Aufruf auf dem beobach tenden (nicht dem beobachteten) Objekt. Dadurch wird es möglich, die Behandlung der verschiedenen Varianten, wie die Polling-Methode zurückkehren kann (mit Up date-Nachricht oder mit Ende-Kennzeichen, s. o.), vor dem Benutzer der Klasse zu verbergen.

Fig. 1 zeigt schematisch die Funktionsweise des Passive Pollings.

C stellt hierbei den Client dar, S den Server, F den Firewall. In C ruft eine auf dem Objekt o₁ laufende Methode die Methode startobserving (o₃) auf dem Observer o₂ auf. Diese wiederum erzeugt eine dem Observer o₁ zugeordnete Queue q auf dem Server und startet eine neue Aktivität (Thread) auf dem Client, welche dann die get- Update()-gu Methode auf o₃ aufruft. Wie in Fig. 1 gezeigt, ruft dieser Thread eine Methode auf der Queue auf g, welche versucht, ein Update-Ereignis aus der Queue zu lesen. Dadurch verweilt dieser Thread auf dem Server solange, bis durch einen modifizierenden Aufruf in das Objekt o₃ sich als verändert betrachtet und auf sich selbst die Benachrichtigung der Observer durch Aufruf n auslöst. Dieser Aufruf n fügt für alle registrierten Observer (in Fig. 1 nur einer) in deren Queue q ein ent sprechendes Objekt ein (Schritt p). Das hebt die Blockierung des g-Aufrufs und damit des getUpdate()-Aufrufs gu auf, so daß dieser zum Client zurückkehren kann.

Dort wird die Rückkehr der getUpdate()-Methode umgesetzt in den Aufruf der upda te()-Methode u, die der Entwickler auf der Client-Seite selbst implementieren kann/muß. Nach deren Abarbeitung wird erneut ein getUpdate() auf dem Server aufgeru fen (neuer Aufruf gu). Dieser Vorgang wiederholt sich solange, bis auf dem Client die Observer-Beziehung von o₁ zu o₃ beendet werden soll. Dazu wird auf o₁ die Methode endObserving (o₃) aufgerufen, welche diesen Aufruf zum Server weiterlei tet (Schritt eo). Dort wird dann im zweiten Schritt p ein speziell markiertes Update-Er eignis in die entsprechende Queue q geschrieben, was wiederum den getUpda te()-Aufruf zurückkehren läßt. Anstatt nach dem Empfang dieses markierten Update- Ereignisses erneut die update()-Methode auf dem Client auszulösen, beendet sich der Client-seitige Thread.

Claims

1. Verfahren zur Übertragung von Information in einem verteilten Informati onsverarbeitungssystem mit einem Kommunikationskanal zwischen Rechenprozes sen, wobei der Kommunikationskanal bezüglich der Richtung der Initiierung eines Informationsaustausches insofern eingeschränkt ist, als die Initiierung nur in einer Richtung möglich ist, und wobei diese Einschränkung durch folgendes Vorgehen überwunden wird:

a) von einem ersten Rechenprozeß wird in der zulässigen Richtung ein Verbin dungsaufbau initiiert, der es einem zweiten Rechenprozeß ermöglicht, als Reaktion spontan Information in der Gegenrichtung zu übertragen, und
b) vom ersten Rechenprozeß wird die spontane Reaktion als Verbindungsauf bau interpretiert, der an sich aufgrund der bestehenden Einschränkung nicht möglich wäre.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß als Kommuni kationskanal ein durch eine objektorientierte Middleware realisierter Methodenaufruf verwendet wird.

3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß die objektori entierte Middleware ausgewählt wird aus Java RMI, Microsoft DCOM oder CORBA.

4. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekenn zeichnet, daß die Einschränkung der Kommunikationsverbindung durch ein Fire wall-System erfolgt.

5. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekenn zeichnet, daß es verwendet wird für eine Implementierung eines Observer-Musters.