DE69606184T2

DE69606184T2 - Klient-server-brücke

Info

Publication number: DE69606184T2
Application number: DE69606184T
Authority: DE
Inventors: Mark Colyer
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1995-09-15
Filing date: 1996-02-07
Publication date: 2000-07-13
Anticipated expiration: 2016-02-08
Also published as: WO1997010546A1; JP3605416B2; EP0850446B1; EP0850446A1; DE69606184D1; GB9518871D0; JPH10511794A; GB2305270A; US5862328A

Description

Klient-Server-Brücke

Bereich der Erfindung

Die vorliegende Erfindung betrifft die verteilte Datenverarbeitung in einer Client-Server-Umgebung und insbesondere die Verwendung von Brücken zwischen Clients und Servern in einer solchen Umgebung.

Der Erfindung zugrundeliegender allgemeiner Stand der Technik

Überblick über die objektorientierte Programmierung

Vor der Entwicklung der objektorientierten Programmierung war eine Form der Programmierung gebräuchlich, die als strukturierte Programmierung bekannt ist, und diese Form der Programmierung findet nach wie vor in großem Umfang Anwendung. Bei dieser Technik werden zuerst verschiedene Funktionen definiert, und das Programm besteht dann darin, dass diese definierten Funktionen zu entsprechenden Zeiten aufgerufen werden, um das Gesamtziel des Anwendungsprogramms zu erreichen. Diese Funktionen definieren die Methoden, die zur Durchführung von Operationen an den Daten verwendet werden, aber die Daten selbst definieren sie nicht. Die strukturierte Programmierung schaffte die Möglichkeit für einen Ansatz, der auf dem Modulkonzept beruht - eine wesentliche Verbesserung gegenüber dem "Spaghetticode", der schwierig zu korrigieren und zu verwalten war. Dennoch bleiben einige Nachteile der strukturierten Programmierung bestehen, wie zum Beispiel die "semantische Lücke" zwischen den Konzepten und den Definitionseinheiten in der Welt, die von dem Programm gestaltet wird, und den Konzepten in der Programmiersprache, die Beschaffenheit des Textes des Programmcodes und die Beschränkungen bei der Wiederverwendbarkeit von Code-Modulen.
Danach wurde ein neues Denkmuster in der Programmierung entwickelt, das als objektorientierte Programmierung bezeichnet wird. Bei diesem Verfahren werden anstelle von Funktionen "Klassen" definiert. Die Klassendefinitionen definieren die Methoden, die jede beliebige Instanz dieser Klasse ausführen kann, und die Attribute (oder Daten), die eine Instanz dieser Klasse enthält. Ein Objekt ist ein Teil einer Klasse und kann tatsächlich die Methoden ausführen, die in der Klassendefinition definiert sind. Ein Objekt besitzt Werte, die zu jedem der von der Klasse definierten Attribute gehören. Ein Objekt besitzt null oder mehr Attribute, und es verfügt über null oder mehr Methoden, die an dem Objekt ausgeführt werden können.
Die Schnittstelle zu dem Objekt ist die Art und Weise, in der über die Methoden auf die Attribute zugegriffen werden kann. Alle von dieser Klasse abgeleiteten Objekte benutzen die Schnittstelle dieser Klasse gemeinsam. Die Art und Weise der Realisierung eines Objekts wird vor der Anwendung, die das Objekt ausruft, verborgen. Solange sich die Schnittstelle zu dem Objekt nicht ändert, kann die Realisierung vollständig geändert werden, ohne dass die Anwendung davon betroffen wird.
Als ein einfaches Beispiel für dieses Verfahren zur Beschreibung des äußeren "Erscheinungsbilds" eines Objekts, ohne dass es notwendig ist zu beschreiben, wie das Objekt im Inneren "aussieht" oder was es im Inneren "tut", und um die beträchtlichen Vorteile dieser objektorientierten Programmierung darzustellen, mag man sich analogiehalber einen gewöhnlichen Toaster vorstellen, dessen Gestaltung nach dem objektorientierten Ansatz vorgenommen werden könnte. Die externe "Schnittstelle " würde aus dem Drehknopf bestehen, der im Wesentlichen einen Parameter zur Einstellung des gewünschten Bräunegrads des Toasts darstellt, der Öffnung, in die das Brot gesteckt wird, und einem Hebel zur Durchführung dieses Einsteckvorgangs und zur Aktivierung des Toasters. Das wichtige Konzept ist, dass der Endbenutzer eines solchen Haushaltsgeräts "das Innere" des Toasters nicht zu kennen braucht, um ihn zu verwenden, z. B. ob Wärme durch Elektrizität oder durch chemische oder andere Mittel zugeführt wird. Alles, was der Benutzer tun müsste, bestünde in der Herstellung eines korrekten Anschlusses zu diesen externen Dingen.
Mit dieser Analogie fortfahrend, besteht das Schöne an dieser Weiterentwicklung in der Programmierung darin, dass der Gestalter des Objekts, bei dem es sich um ein Modul eines Programmiercodes handeln kann, das die Ausgestaltung eines Toasters vornimmt, sich darauf konzentrieren kann, das Innere des Toasters zu verbessern, ihn beispielsweise leistungsfähiger zu machen, ohne dem Benutzer die Handhabung des Objekts zu erschweren, insofern als das Innere für den Benutzer transparent ist. Abstrakter ausgedrückt, die objektorientierte Technik kann folglich hauptsächlich als eine Technik betrachtet werden, die den Vorteil der Trennung der Schnittstelle eines Objekts von dessen Realisierung bietet. Im Zusammenhang mit Software kann das Innere des Objekts dadurch neu geschrieben und verbessert werden, ohne dass das ganze Anwendungsprogramm neu geschrieben werden muss, solange sich die externen "Dreh knöpfe" usw. und ihr erwartetes Verhalten nicht verändert haben.
Damit sich die Erfindung leichter und besser verstehen lässt, sei hinsichtlich weiterer allgemeiner Hintergrundinformationen in Bezug auf die Objekttechnik auf "Object Oriented Technology - A Managers Guide" von David A. Taylor, Copyright 1990, Servio Corporation, verwiesen.
Mit der Entwicklung der objektorientierten Programmierung wurden mehrere "Objektmodelle" von verschiedenen Organisationen und Softwarehäusern weiter verfeinert und weiterentwickelt. Diese gaben die Art und Weise an, in der Objekte und ihre externen Schnittstellen definiert werden sollten, wobei diese verschiedenen Objektmodelle unter anderem Merkmale der Kapselung und Vererbung aufwiesen. Auf einer entsprechend hohen Stufe sind diese verschiedenen Objektmodelle sehr ähnlich. Beispiele sind das System Object Model (SOM), Common Lisp Object System (CLOS), Smalltalk und C++. Tm Wesentlichen sind diese verschiedenen Objektmodelle einfach ein Regelwerk, das die Frage, was ein Objekt ist, beantwortet, wobei jedes Modell etwas andere Antworten gibt, wenn es auf tiefer angesiedelten Stufen geprüft wird. Beispielsweise unterscheiden sich verschiedene Objektmodelle in ihrer Sprachsyntax und in der Funktionsweise der Kapselung und Vererbung.
Als direkte Folge dieser Unterschiede bestand ein Problem, das durch das Vorhandensein von verschiedenen objektorientierten Sprachen und Objektmodellen geschaffen wurde, darin, dass eine Zusammenarbeit der Objektprogramme, die in vielen verschiedenen dieser Sprachen geschrieben wurden, nicht erreicht werden konnte. Dieses Problem wirkte sich nachteilig auf eines der Hauptversprechen der Objekttechnik aus, nämlich die Wiederverwendbarkeit von Code. In dem Bemühen, dieses Problem anzugehen, das der Industrie zu schaffen machte, erzielte ein Ausschuss ein Ergebnis in Form der Common Object Request Broker Architecture (CORBA), die eine standardisierte Schnittstellendefinitionssprache (Interface Definition Language (IDL)) beinhaltete. Im Kern traf die Industrie eine Vereinbarung darüber, wie Schnittstellen eines Objekts angegeben werden, d. h. ein Standard zur Definition von Objektschnittstellen wurde geschaffen, so dass von einem Lieferanten definierte Objekte von einem anderen verwendet werden konnten. Weitere Informationen finden sich in "The Common Object Request Broker: Architecture and Specification", OMG Document Number 91.12.1 Revision 1.1.

Object Request Broker (ORB)

Der in der CORBA-Architektur beschriebene Object Request Broker (ORB) ist mit dem Remote Procedure Call (RPC) vergleichbar, der denjenigen vertraut ist, die in UNIX-Betriebssystemumgebungen arbeiten (UNIX ist ein ausschließlich durch X/Open Co. Ltd. lizenziertes Warenzeichen).
Ein System nach dem Stand der Technik ist in Fig. 1 veranschaulicht, die ein Blockdiagramm eines in einer Client/Server-Umgebung befindlichen Object Request. Broker nach dem Stand der Technik darstellt.
Der ORB ist in zwei Teile geteilt, von denen der Teil 50 in jedem der Clients, die den ORB verwenden, und der Teil 52 in jedem der Server, die den ORB unterstützen, ausgeführt werden. Ebenso wie ein RPC ist ein ORB ein Mechanismus, der Client- Anwendungen 48, die in einem Adressraum 53 tätig sind, eine Kommunikation mit Objekten 51 in einem anderen Adressraum 54 ermöglicht. Die Objekte 51, die sich in dem anderen Adressraum 54 befinden, bei dem es sich nicht um denselben Adressraum handelt, in dem die Client-Anwendung 48 ausgeführt wird, also den Adressraum 53, werden als "ferne" Objekte bezeichnet. Objekte, die sich in demselben Adressraum 53 befinden, in dem sich auch die Client-Anwendung 48 befindet, werden als "lokale" Objekte bezeichnet. Ein ORB 50 fängt einen Aufruf von einer Client-Anwendung 48 in einem Adressraum 53 ab, bindet ihn in ein Netzwerkprotokoll ein, decodiert den Aufruf für das Zielobjekt 51 in einem anderen Adressraum 54 und sendet die Ergebnisse an die aufrufende Client-Anwendung 48 zurück. Dadurch kann eine Client-Anwendung 48, die in einem Adressraum (lokal) arbeitet, mit Objekten 51 in einem anderen Adressraum (fern) kommunizieren. Der ORB ist eine Verbesserung gegenüber dem RPC, da er so ausgelegt ist, dass er den höheren Grad an Flexibilität und Leistung bereitstellt, den die objektorientierte Programmierung bietet. Die Funktion eines Stellvertreterobjekts 49 wird nachstehend näher erläutert.
Proceedings of the Second International Workshop on Object Orientation in Operating Systems, Dourdon, Frankreich, 24, bis 25. September 1992, Los Alamitos, CA, USA, IEEE CONPUT. SOC. PRESS, Seiten 212 bis 220, beschreiben einen solchen Object Request Broker nach dem Stand der Technik.
"Objektmodelle" wurden von verschiedener Organisationen und Softwarehäusern entwickelt. Die Objektmodelle geben die Art und Weise an, in der Objekte und ihre externen Schnittstellen zu definieren sind. Eines dieser Objektmodelle ist das System Object Model (SOM) von der IBM Corporation. Bei SOM laufen alle Anwendungen, die Objekte verwenden, in einem einzigen Adressraum, in dem sich auch die Objekte befinden. Eine Entwicklung innerhalb von SOM ist ein Gerüst aus Objektklassen mit der Bezeichnung Distributed System Object Model (DSOM). Bei DSOM können Anwendungen (die in Clients laufen) in einem Adressraum auf Objekte in einem anderen Adressraum (wie zum Beispiel einem Adressraum, der einem Server gehört) zugreifen. Diese Adressräume können sich in demselben System oder in verschiedenen Systemen befinden. Tatsächlich brauchen die Systeme nicht dieselbe Plattform auszuführen. Eine Client-Anwendung beispielsweise, die in einem Adressraum auf einem OS/2-System läuft, kann auf ein Objekt zugreifen, das sich in einem Adressraum auf einem AIX/6000-System befindet, oder umgekehrt. Sowohl SOM als auch DSOM sind in "SOMobjects: A Practical Introduction to SOM and DSOM" beschrieben, veröffentlicht von der IBM Corporation, Copyright 1994, Bestellnummer GG24-4357- 00.
Die Europäische Patentanmeldung 0 501 610 beschreibt einen Mechanismus, der es Objekten in verschiedenen Prozessen erlaubt zu kommunizieren. Programme werden ausdrücklich so geschrieben, dass sie die Übertragungsschnittstelle Application Programming Interface (Anwendungsprogrammierschnittstelle, API) benutzen.
Das oben erwähnte System Object Model (SOM) ist ein Objektmodell, das CORBA und IDL entspricht. Entsprechung bedeutet, dass SOM-Objekte der CORBA-Semantik folgen und in der Syntax von IDL definiert werden.
Das DSOM-Gerüst ermöglicht Realisierungen von Objekten, bei denen der Client-Programmierer nicht den Ort oder die Art der Plattform kennen muss, an dem beziehungsweise auf der ein Zielobjekt verwirklicht wird. Die Übertragungseinrichtungen, die für diese Kommunikation zwischen Prozessen verwendet werden, werden vor dem Programmierer vollständig verborgen.

Client-Server-Architektur

In einer Client-Server-Architektur werden Anwendungsprogramme in bestimmte Tasks aufgeteilt, die als einzelne Komponenten ausgeführt werden. Jeder der Komponenten wird eine Rolle als Client oder als Server zugewiesen. Eine einzelne Komponente kann für bestimmte Zwecke die Rolle eines Servers und für andere Zwecke die Rolle eines Client übernehmen. Jede der Komponenten arbeitet unabhängig und übernimmt bestimmte Verantwortungen. Diejenigen Komponenten, denen die Rolle eines Client zugewiesen wird, fordern Dienste von einem Server an, indem sie Methodenaufrufe auf einem Objekt in einem Serverprozess durchführen. Diejenigen Komponenten, denen die Rolle eines Servers zugewiesen wird, erbringen Dienste, indem sie diese Methodenaufrufe empfangen, die Methoden auf dem geeigneten Objekt aufrufen und die Ergebnisse an den Client zurücksenden. Der Nachrichtenaustausch zwischen den Clients und den Servern erfolgt mit Hilfe eines vorher festgelegten Protokolls. Server können viele Clients bedienen, und Clients können die Dienste von vielen Servern in Anspruch nehmen.
Sofern der Client oder der Server nicht über einen bestimmten internen Code verfügen, ist es in einem solchen System nicht möglich, die Anforderungen, die von dem Client an den Server gestellt werden, zu überwachen oder zu protokollieren oder mit diesen Anforderungen verbundene Daten zu überwachen oder zu protokollieren. Gegebenenfalls ist es erwünscht, solche Anfor derungen zum Zweck der Fehlerbestimmung zu überwachen oder zu protokollieren.
In dem vorstehend beschriebenen System ist eine gleichmäßige Verteilung der Arbeitslast zwischen Servern nicht möglich, außer wenn der Client so ausgelegt wurde, dass er eine solche Funktion zur gleichmäßigen Verteilung der Arbeitslast in sich selbst beinhaltet. Nachteile der Integration einer solchen Funktion zur gleichmäßigen Verteilung der Arbeitslast in den Client selbst sind der mit jeder Anforderung verbundene Mehraufwand im Client und die Komplexität, mit der jeder der Clients, der eine solche Funktion zur gleichmäßigen Verteilung der Arbeitslast enthält, behaftet wird. Eine gleichmäßige Verteilung der Arbeitslast ist wünschenswert, um die Gesamtleistungsfähigkeit für den Client zu verbessern, indem der Server ausgewählt wird, der die beste Leistungsfähigkeit bietet.
Zwischen jedem der Clients und jedem der Server, von dem der Client Dienste anfordern können möchte, muss es eine Kommunikationsverbindung geben. In einem System, in dem es viele Clients und viele Server gibt, hat dies eine beträchtliche Unübersichtlichkeit zur Folge.

Stand der Technik

Die Verlagerung von Funktionen ermöglicht Anwendungsprogrammen den Zugriff auf Dateien, die einem anderen System gehören, indem sie Dateisteuerungsanforderungen übermitteln, und die Übertragung von Daten an oder von Warteschlangen mit Übergangsdaten oder mit Zwischenspeichern in anderen Systemen, indem sie Anforderungen für Übergangsdaten und Zwischenspeicherfunktionen übermitteln. Sie ermöglicht auch die Einleitung von Transaktionen in anderen Systemen, die Protokolle vom Typ SNA LU Type 6 ausführen. Mit Hilfe von Einträgen in einer Ressourcendefinitionstabelle kann der Systemprogrammierer angeben, dass sich die genannte Ressource nicht auf dem lokalen (oder anfordernden) System, sondern auf einem fernen (oder besitzenden) System befindet. Die Verwendung der Funktionsverlagerung ist sowohl für das anfordernde als auch das ferne System transparent. Die Protokollierung und die Überwachung von Anforderungen und zugehörigen Daten sind möglich, müssen aber für jede Anwendung, in der eine solche Überwachung erwünscht ist, getrennt ausgeführt werden. Weitere Informationen über die Verlagerung von Funktionen findet man in "CICS/ESA V4.1 Intercommunication Guide", veröffentlicht von der IBM Corporation, Copyright 1977, 1994, Bestellnummer SC33-1181-00.
Mit Stellvertretern kann einer lokalen Anwendung, die in einem Client ausgeführt wird, der Zugriff auf ferne Ressourcen in einem Server gestattet werden. Ein Stellvertreter ist ein Objekt, wie beispielsweise das Stellvertreterobjekt 49 in Fig. 1, das ein anderes Objekt darstellt, seine Nachrichten empfängt und sie in irgendeiner Weise verarbeitet. Dies schließt oftmals die Weiterleitung der Nachricht an das Zielobjekt, wie beispielsweise das Zielobjekt 51 in Fig. 1, ein. Stellvertreter stellen in der objektorientierten Programmierung ein bekanntes Verfahren dar und werden von DSOM (Distributed System Object Model) verwendet - eine ausführliche Beschreibung findet sich im Benutzerhandbuch SOMobjects Developer Toolkit User's Guide Version 2.0, das Bestandteil der SOMobjects Publications ist und von der IBM Corporation veröffentlicht wurde, Copyright 1994, Bestellnummer S96F-E649. Ein Stellvertreter empfängt Anforderungsnachrichten vor, einem Client, die an einen Server gesendet werden müssen, und er empfängt Antwort nachrichten vom Server, die an den Client gesendet werden müssen. Er kann keine asynchronen Antwortnachrichten vom Server für den Client empfangen. Ein Stellvertreter ist grundsätzlich einem einzigen Zielobjekt in einem Server und nicht mehreren Objekten in einem einzigen Server oder In mehreren Servern zugeordnet.
Die Europäische Patentanmeldung 0 518 195 beschreibt eine plattformunabhängige Anwendungsprogrammierschnittstelle (Application Programming Interface, API), die durch Bibliotheksroutinen, die mit Anwendungsprogrammen verbunden sind, realisiert wird. Die Anwendungsprogramme sind speziell für die API geschrieben, und die Client- und Serverprozesse müssen ausdrücklich Kenntnis von der API haben und sie verwenden. Das Problem bei dieser Ausführung ist, dass sie keinen transparenten Mechanismus bereitstellt, um Client-Server-Datenflüsse abzufangen, ohne dass sich der Client und der Server der Umleitung bewusst sind.
Die PCT-Patentanmeldung WO 95/17718 beschreibt eine objektorientierte Schnittstelle zu Remote Procedure Calls (RPCs), die in das Betriebssystem integriert ist. Client- und Serverprogramme werden speziell so geschrieben, dass sie die RPC Application Programming Interface (API) verwenden, wenn sie miteinander kommunizieren. Diese Ausführung stellt ebenfalls keinen transparenten Mechanismus bereit, um Client-Server-Datenflüsse abzufangen, ohne dass sich der Client und der Server der Umleitung bewusst sind.
In dem Artikel "Building a better app, SQL style", PC Magazine, Band 13, Nummer 10, 31. Mai 1994, beschreibt G. Gagnon ein Verfahren, mit dem sich eine gemeinsame API auf viele verschiedene APIs abbilden lässt.
In dem Artikel "SQL*NET version 2: client/server networking is easier with SQL*NET V2 and the MultiProtocol Interchange", DBMS, Band 5, Nummer 9, August 1992, beschreibt S. Roti eine zwischengeschaltete Komponente, die eine Umsetzung von einer API in eine andere API vornimmt. Die Vermittlereinheiten werden speziell so geschrieben, dass sie die Umsetzungsaufgabe, die ihnen abverlangt wird, ausführen. Ohne die Vermittlereinheit kommunizieren die für die beiden APIs geschriebenen Komponenten nicht.

Beschreibung der Erfindung

Folglich stellt die Erfindung eine Brücke zur Verwendung zwischen einem Client und einem Server in einem verteilten objektorientierten Datenverarbeitungssystem bereit, wobei die Brücke eine Schnittstelle zu einem Stellvertreterobjekt festlegt, das sich im Adressraum des Client befindet, die der Schnittstelle eines Servers entspricht, und eine Schnittstelle zum Server, die der Schnittstelle eines Stellvertreterobjekts entspricht, das sich im Adressraum des Client befindet, wobei die Brücke zwischen dem Stellvertreterobjekt, das sich im Adressraum des Client befindet, und dem Server transparent eingefügt wird und eine Kennung verzeichnet, die dem Stellvertreterobjekt zugeordnet ist, das sich im Adressraum des Client befindet.
In einer ersten Ausführungsform arbeiten der Client und der Server asynchron, die Brücke wird von einem Client und einem Server durch Vererbung abgeleitet, die Brücke überschreibt Me thoden, die sie von dem Server geerbt hat, um den Namen des Client, der die Anforderung stellt, zu verzeichnen und um die Anforderung an den Server weiterzuleiten, und die Brücke überschreibt Methoden, die sie von dem Client geerbt hat, um Antwortparameter an den Client weiterzuleiten.
In einer zweiten Ausführungsform arbeiten der Client und der Server synchron, die Brücke wird von einem Server durch Vererbung abgeleitet, und sie überschreibt Methoden, die sie von dem Server geerbt hat, um die Methoden auf dem Server aufzurufen und um Antwortparameter an den Client weiterzuleiten.
In einer bevorzugten Ausführungsform umfasst die Brücke des Weiteren ein Mittel zur Überwachung und Protokollierung von Anforderungen zwischen dem Client und dem Server und von Daten, die zu diesen Anforderungen gehören. In einer bevorzugten Ausführungsform umfasst die Brücke darüber hinaus auch ein Mittel zur gleichmäßigen Verteilung der Arbeitslast zwischen den Servern. Eine solche gleichmäßige Verteilung der Arbeitslast kann vorgenommen werden, indem Antwortzeiten gemessen und als Antwort auf die gemessene Antwortzeit Anforderungen von Clients an Server geleitet werden. In einer weiteren bevorzugten Ausführungsform ist die Brücke mit m Clients und n Servern verbunden (wobei n und m ganze Zahlen größer oder gleich 2 sind) und verringert die Anzahl der Netzwerkverbindungen von n*m auf n+m.
Vorzugsweise sind die Schnittstellen zwischen Objekten CORBA- Schnittstellen, und das verteilte objektorientierte Datenverarbeitungssystem verwendet DSOM-Klassenbibliotheken. Jedoch ist die Erfindung nicht auf die Anwendung in CORBA-konformen Systemen oder die Verwendung solcher Klassenbibliotheken be schränkt. Das verteilte objektorientierte System könnte beispielsweise dem Component Object Model (COM) von Microsoft entsprechen, oder es könnte Klassenbibliotheken der Distributed Object Management Facility (DOMF) verwenden, die von SunSoft als Distributed Object Environinent und von Hewlett- Packard Co. als ORB Plus erhältlich sind.
Die Erfindung stellt auch ein Verfahren zum Betreiben eines verteilten Client-Server-Datenverarbeitungssystems bereit, das die Schritte der Festlegung einer Schnittstelle für eine Brücke in der Weise umfasst, dass die Schnittstelle zu einem Stellvertreterobjekt, das sich im Adressraum des Client befindet, der Schnittstelle eines Servers entspricht, der Festlegung einer Schnittstelle zum Server, die der Schnittstelle eines Stellvertreterobjekts entspricht, das sich im Adressraum des Client befindet, und des Verzeichnens einer Kennung durch die Brücke, die dem Stellvertreterobjekt zugeordnet ist, das sich im Adressraum des Client befindet.
In einer ersten Ausführungsform arbeiten der Client und der Server asynchron, und der Schritt der Festlegung einer Schnittstelle zum Client umfasst das Ableiten der Schnittstelle zum Client von einem Server durch Vererbung und das Überschreiben von Methoden, die von dem Server geerbt wurden, um den Namen des Client, der die Anforderung stellt, zu verzeichnen und um die Anforderung an den Server weiterzuleiten, und der Schritt der Festlegung einer Schnittstelle zum Server umfasst das Ableiten der Schnittstelle zum Server von einem Client durch Vererbung und das Überschreiben von Methoden, die von dem Client geerbt wurden, um Antwortparameter an den Client weiterzuleiten.
In einer zweiten Ausführungsform arbeiten der Client und der Server synchron, und der Schritt der Festlegung einer Schnittstelle zum Client umfasst das Ableiten der Schnittstelle zum Client von einem Server durch Vererbung und das Überschreiben von Methoden, die von dem Server geerbt wurden, um die Methoden auf dem Server aufzurufen und um Antwortparameter an den Client weiterzuleiten.
Die Erfindung stellt auch ein verteiltes objektorientiertes Datenverarbeitungssystem bereit, das einen oder mehr Server, einen oder mehr Clients und eine Brücke, wie sie vorstehend beschrieben wurde, umfasst.

Kurze Beschreibung der Zeichnungen

Ausführungsformen der Erfindung werden nun anhand eines Beispiels und mit Bezug auf die beiliegenden Zeichnungen beschrieben, in denen:
Fig. 1 ein Blockdiagramm eines Object Request Broker nach dem Stand der Technik ist, der sich in einer Client/Server-Umgebung befindet;
Fig. 2 ein Blockschaltbild eines Datenverarbeitungssystem nach dem Stand der Technik ist, das sich zum Einsatz mit der vorliegenden Erfindung eignet;
Fig. 3 ein Blockdiagramm eines Systems ist, das zusammen mit einer Brücke der vorliegenden Erfindung einen Client und einen Server nach dem Stand der Technik enthält, die für einen asynchronen Betrieb konfiguriert sind;
Fig. 4 ein Flussdiagramm des asynchronen Betriebs eines Client und eines Servers nach dem Stand der Technik ist;
Fig. 5 ein Flussdiagramm des asynchronen Betriebs des Systems von Fig. 3 gemäß der vorliegenden Erfindung ist;
Fig. 6 ein Blockdiagramm eines Systems ist, das zusammen mit einer Brücke der vorliegenden Erfindung einen Client und einen Server nach dem Stand der Technik enthält, die für einen synchronen Betrieb konfiguriert sind;
Fig. 7 ein Flussdiagramm des synchronen Betriebs eines Client und eines Servers nach dem Stand der Technik ist;
Fig. 8 ein Flussdiagramm des synchronen Betriebs des Systems von Fig. 6 gemäß der vorliegenden Erfindung ist;
Fig. 9 ein Blockdiagramm ist, das die gleichmäßige Verteilung der Arbeitslast zwischen mehreren Servern unter Verwendung einer Brücke gemäß der vorliegenden Erfindung zeigt;
Fig. 10 ein Blockschaltbild ist, das die dem Stand der Technik entsprechende Verbindung von mehreren Clients mit mehreren Servern zeigt; und
Fig. 11 ein Blockschaltbild ist, das die Verbindung von mehreren Clients mit mehreren Servern unter Verwendung einer Brücke gemäß der vorliegenden Erfindung zeigt.

Ausführliche Beschreibung der Erfindung

Geeignete Hardware, in der die Erfindung realisiert werden kann

Die Erfindung kann auf einer Vielzahl von Rechnern oder einem Rechnerverbund unter mehreren verschiedenen Betriebssystemen ausgeführt werden. Der Rechner könnte beispielsweise ein Personal Computer, ein Minicomputer, ein Großrechner oder ein Rechner sein, der in einem aus anderen Rechnern bestehenden verteilten Netzwerk betrieben wird. Obwohl die jeweilige Wahl des Rechners lediglich durch die Anforderungen an die Kapazität des Arbeitsspeichers und des Plattenspeichers eingeschränkt wird, könnten Rechner der Rechnerserie IBM PS/2 bei der vorliegenden Erfindung verwendet werden (IBM ist ein eingetragenes Warenzeichen, und PS/2 ist ein Warenzeichen der IBM Corporation). Weitere Informationen über die Rechnerserie PS/2 von IBM findet der Leser im "Technical Reference Manual Personal System/2 (Model 80)", IBM Corporation Teile-Nr. 68X 2256, Bestellnummer SGSX-2254. Ein Betriebssystem, das auf einem Personal Computer vom Typ IBM PS/2 lauftähig ist, ist das Betriebssystem OS/2 2.0 von IBM. Weitere Informationen über das Betriebssystem IBM OS/2 2.0 findet der Leser in "OS/2 2.0 Technical Library, Programming Guide Vol. 1, 2, 3, Version 2.00", Bestellnummern 10G6261, 10G6495, 10G6494 (OS/2 ist ein Warenzeichen der IBM Corporation).
Alternativ dazu ist das Rechnersystem möglicherweise ein System der Rechnerreihe IBM RISC System/6000, die unter dem Betriebssystem AIX laufen (RISC System/6000 und AIX sind Warenzeichen der IBM Corporation). Die verschiedenen Modelle der Rechnerreihe RISC System/6000 sind in vielen Veröffentlichun gen der IBM Corporation beschrieben, zum Beispiel in "RISC System/6000, 7073 and 7016 POWERstation and POWERserver Hardware Technical Reference", Bestellnummer SA2: 3-2644-00 (POWERstation und POWERserver sind Warenzeichen der IBM Corporation). Das Betriebssystem AIX ist in "General Concepts and Procedure -- AIX Version 3 for RISC System/6000", Bestellnummer SC23-2202- 00, sowie in anderen Veröffentlichungen der IBM Corporation beschrieben.
In Fig. 2 ist ein Rechner 10, der eine Systemeinheit 11, eine Tastatur 12, eine Maus 13 und einen Bildschirm 14 umfasst, in Form eines Blockschaltbildes gezeigt. Die Systemeinheit 11 enthält einen Systembus oder eine Vielzahl von Systembussen 21, an den beziehungsweise an die verschiedene Komponenten angeschlossen sind und über den/die die Kommunikation zwischen den verschiedenen Komponenten erfolgt. Der Mikroprozessor 22 ist mit dem Systembus 21 verbunden und wird von einem Nur- Lese-Speicher (ROM) 23 und einem Direktzugriffsspeicher (RAM) 24, die ebenfalls an den Systembus 21 angeschlossen sind, unterstützt. Ein Mikroprozessor der Rechnerreihe IBM PS/2 ist ein Mikroprozessor der Mikroprozessorfamilie von Intel, zu der die Mikroprozessoren vom Typ 386 oder 486 gehören. Jedoch können andere Mikroprozessoren einschließlich, aber nicht darauf beschränkt, Prozessoren der Mikroprozessorfamilie von Motorola, wie beispielsweise die Mikroprozessoren vom Typ 68000, 68020 oder 68030, und verschiedene Reduced-Instruction-Set- Computer-(RISC-)Mikroprozessoren, wie beispielsweise der von IBM hergestellte PowerPC-Chip, oder andere Mikroprozessoren von Hewlett Packard, Sun, Motorola und anderen Herstellern in dem bestimmten Rechner verwendet werden.
ROM 23 enthält neben anderem Code das Basic Input-Output System (BIOS), das grundlegende Hardwareoperationen, wie zum Beispiel die interaktive Kommunikation, sowie die Plattenlaufwerke und die Tastatur steuert. RAM 24 ist der Hauptspeicher, in den das Betriebssystem und Anwendungsprogramme geladen werden. Der Speicherverwaltungschip 25 ist mit dem Systembus 21 verbunden und steuert Direktspeicherzugriffsoperationen einschließlich der Weiterleitung von Daten zwischen dem RAM 24 und dem Festplattenlaufwerk 26 sowie dem Diskettenlaufwerk 27. Das CD-ROM-Laufwerk 32, das ebenfalls an den Systembus 21 angeschlossen ist, dient zur Speicherung einer großen Datenmenge, z. B. eines Multimediaprogramms oder einer Multimediapräsentation.
Verschiedene E/A-Steuereinheiten sind ebenfalls mit diesem Systembus 21 verbunden: die Tastatur-Steuereinheit 28, die Maus- Steuereinheit 29, die Video-Steuereinheit 30 und die Audio- Steuereinheit 31. Die Tastatur-Steuereinheit 28 stellt erwartungsgemäß die Hardwareschnittstelle für die Tastatur 12 bereit, die Maus-Steuereinheit 29 stellt die Hardwareschnittstelle für die Maus 13 bereit, die Video-Steuereinheit 30 bildet die Hardwareschnittstelle für den Bildschirm 14, und die Audio-Steuereinheit 31 bildet die Hardwareschnittstelle für die Lautsprecher 15a und 15b. Eine E/A-Steuereinheit 40, wie beispielsweise ein Token-Ring-Adapter, ermöglicht die Übertragung an andere, ähnlich konfigurierte Datenverarbeitungssysteme über ein Netzwerk 46.
In einer der bevorzugten Ausführungen der Erfindung befindet sich der Satz von Befehlen 48 bis 52, der zuvor mit Bezug auf Fig. 1 beschrieben wurde, im Direktzugriffsspeicher 24 von einem oder mehr Datenverarbeitungssystemen, die im Allgemeinen in der vorstehend beschriebenen Art und Weise konfiguriert sind. Bis er vom Datenverarbeitungssystem benötigt wird, kann der Befehlssatz in einem anderen Rechnerspeicher, zum Beispiel im Festplattenlaufwerk 26 oder in einem auswechselbaren Speicher, wie zum Beispiel einer optischen Platte, zur schließlichen Verwendung im CD-ROM-Laufwerk 32 oder auf einer Diskette zur schließlichen Verwendung im Diskettenlaufwerk 27 abgelegt werden. Die Speicheradressräume, die mittels der ORBs miteinander verbunden werden, können sich in getrennten Systemen befinden, die über das Netzwerk 46 miteinander kommunizieren, oder sie können zwei oder mehr Adressräume 53, 54 im Speicher eines einzigen Datenverarbeitungssystems sein, wie in Fig. 2 dargestellt ist.

Brücke

Bezug nehmend auf Fig. 3, wird bei der vorliegenden Erfindung eine Brücke 300 zwischen dem Client 53 und dem Server 54 eingefügt. Die Brücke 300 hat den Zweck, Anforderungen vom Client 53 zu empfangen, die für den Server 54 bestimmt sind, die Anforderungen an den Server 54 weiterzuleiten, Antworten vom Server 54 zu empfangen, die für den Client 53 bestimmt sind, und die Antworten an den Client 53 weiterzuleiten. Die Brücke 300 stellt eine Schnittstelle zum Client 53 dar, die der des Servers 54 entspricht, und eine Schnittstelle zum Server 54, die der des Client 53 entspricht. Auf diese Weise können weder der Client 53 noch der Server 54 das Vorhandensein der Brücke 300 feststellen, und beide arbeiten so, als wäre sie nicht vorhanden.
Zwei Ausführungsformen der Erfindung werden beschrieben, eine für den Betrieb in einer asynchronen Umgebung und eine für den Betrieb in einer synchronen Umgebung. In einer asynchronen Umgebung (die in Fig. 5 gezeigt ist) fährt der Client 53 mit anderen Verarbeitungsaufgaben fort, während er auf eine Antwort vom Server 54 wartet. In einer synchronen Umgebung (die in Fig. 8 gezeigt ist) wartet der Client 53 auf eine Antwort vom Server 54, bevor er mit der Verarbeitung fortfährt.

Asynchrone Umgebung

Nehmen wir nochmals Bezug auf Fig. 3, welche die Bestandteile einer Brücke 300 zur Verwendung mit einem Client und einem Server enthält, die in einer asynchronen Betriebsart arbeiten. Der Client 53, die Brücke 300 und der Server 54 enthalten alle etwas, das in der Terminologie von DSOM als Server-Objekt bezeichnet wird. Diese Server-Objekte sind jeweils als das Server-Objekt des Client 404, das Server-Objekt der Brücke 301 und das Server-Objekt des Servers 501 gezeigt. Diese Objekte sind nicht mit den Funktionen zu verwechseln, die ein Server ausführt, oder mit dem Server selbst. Ein Server-Objekt ist ein Objekt, das Objekte in einem Server verwaltet, damit Client-Anwendungen Objekte in Servern erzeugen und löschen können. Es stellt auch fest, welches Objekt in einem Server eine Anforderung verarbeiten soll und sendet diese Anforderungen, die es für den Server empfängt, zur Ausführung an das festgestellte Objekt.
Der Client 53 enthält mindestens ein Objekt mit der Bezeichnung Objekt des Client 403, das im Client die Anforderung für einen vom Server 54 zu erbringenden Dienst stellt. Eine Client-Anwendung (nicht gezeigt) ruft das Objekt des Client 403 zur Ausführung von Operationen an Daten auf. Diese Operationen werden entweder lokal im Objekt des Client 403 selbst oder fern ausgeführt, indem das Objekt des Client 403 Dienste von einem Server 54 anfordert. Der Server 54 enthält mindestens ein Objekt mit der Bezeichnung Objekt des Servers 503 (das nicht mit einem Server-Objekt zu verwechseln ist). Dies entspricht einem Zielobjekt, das zuvor mit Bezug auf die Fig. 1 und 2 beschrieben wurde. Es handelt sich dabei um das Objekt, das tatsächlich die vom Objekt des Client 403 angeforderten Dienste erbringt. Die Brücke 300 enthält ein Objekt mit der Bezeichnung Objekt der Brücke 304, das die Funktionen der Brücke selbst bereitstellt.

Stellvertreterobjekte

Der Client 53, die Brücke 300 und der Server 54 enthalten alle etwas, das in der DSOM-Terminologie als Stellvertreterobjekt bezeichnet wird. Ein Stellvertreterobjekt ist ein Objekt, das als lokaler Vertreter eines fernen Zielobjekts dient. Ein Stellvertreterobjekt erbt die Schnittstelle des Zielobjekts, so dass es auf dieselben Methoden antwortet. Auf dem Stellvertreterobjekt aufgerufene Methoden werden nicht lokal ausgeführt, sondern zur Ausführung an das wirkliche Zielobjekt weitergeleitet. Ein Programm, das in einem Client läuft, hat für jedes ferne Objekt in einem Server, an dem es Operationen ausführt, immer ein lokales Stellvertreterobjekt im Client. Das Stellvertreterobjekt enthält einen Zeiger auf den Speicherplatz im Server, an dem sich das Zielobjekt befindet. Immer wenn eine Anforderung an einen fernen Server gestellt wird, eine Methode auf einem fernen Objekt aufzurufen, wird das Stellvertreterobjekt von der DSOM-Laufzeitumgebung erzeugt.
Der Client 53 enthält ein Stellvertreterobjekt mit der Bezeichnung Server-Stellvertreter der Brücke 401, bei dem es sich um den lokalen Vertreter des Server-Objekts der Brücke 301 handelt. Der Client ist der Meinung, dass dies das Server- Objekt des Servers 501 in dem Server darstellt, der die Dienste erbringt. Ebenso enthält die Brücke 300 ein Stellvertreterobjekt mit der Bezeichnung Server-Stellvertreter des Servers 302, bei dem es sich um den lokalen Vertreter des Server- Objekts des Servers 501 handelt. Wie vorstehend erklärt wurde, ist ein Server-Objekt ein Objekt, das Objekte im Server verwaltet.
Der Client 53 enthält auch ein Stellvertreterobjekt mit der Bezeichnung Objektstellvertreter der Brücke 402, bei dem es sich um den lokalen Vertreter des Objekts der Brücke 304 handelt. Der Client ist der Meinung, dass dies das Objekt 503 in dem Server darstellt, der die Dienste erbringt. Ebenso enthält die Brücke 300 ein Stellvertreterobjekt mit der Bezeichnung Objektstellvertreter des Servers 303, bei dem es sich um den lokalen Vertreter des Objekts des Servers 503 handelt. Diese Stellvertreter werden bei den Übertragungen zwischen dem Client 53 und dem Server 54 verwendet, die vom Client 53 eingeleitet werden. In einem asynchronen System werden Übertragungen auch vom Server 54 eingeleitet, wenn er eine Antwort für den Client 53 hat. Diese Übertragungen werden mittels eines Objektstellvertreters der Brücke 502, der sich im Server 54 befindet und dem Server 54 die Kommunikation mit der Brücke 300 ermöglicht, und mittels eines Objektstellvertreters des Client 305 erreicht, der sich in der Brücke 300 befindet und der Brücke 300 die Kommunikation mit den Client 53 ermöglicht.
Wie nun aus der vorstehenden Beschreibung hervorgeht, werden die in Fig. 3 gezeigten Objekte und die Stellvertreterobjekte, die sich im oberen Teil eines jeden der Blöcke befinden, die den Client 53, die Brücke 300 und den Server 54 darstellen, bei der Erzeugung, der Löschung und Positionierung von Objekten durch den Client und die Brücke verwendet. Die in Fig. 3 gezeigten Objekte und die Stellvertreterobjekte, die sich im unteren Teil eines jeden der Blöcke befinden, die den Client 53, die Brücke 300 und den Server 54 darstellen, werden bei dem Übertragungsprozess zwischen dem Client 53, der Brücke 300 und dem Server 54 verwendet.
Fig. 4 zeigt den Dialogverkehr zwischen einem Client nach dem Stand der Technik und einem Server nach dem Stand der Technik über ein Netzwerk nach dem Stand der Technik in einer asynchronen Umgebung. In einer asynchronen Umgebung leitet der Client eine Kommunikation mit dem Server ein, indem er an den Server eine Anforderung für die Erbringung eines Dienstes stellt. Der Server bestätigt die Anforderung, und der Client fährt mit anderen Verarbeitungsaufgaben fort. Der Server kann die Anforderung nach einer Verzögerung abarbeiten, während er gegebenenfalls auch andere Verarbeitungsaufgaben zum Abschluss bringt. Wenn der Server die Anforderung abgearbeitet hat, leitet er eine weitere Kommunikation mit dem Client ein, indem er dem Client eine Antwort zukommen lässt. Diese Kommunikation wird von dem "Server" eingeleitet, der tatsächlich eine Anforderung an den "Client" stellt, wobei diese Anforderung darin besteht, die Antwort von der vorherigen Anforderung anzunehmen. Unter diesen Umständen ist zu berücksichtigen, dass der "Server" und der "Client" vertauschte Rollen haben, wobei der Server den Client um Annahme der Antwort nachsucht. Dies ist der Grund dafür, dass der Client im asynchronen Betrieb ein Server-Objekt benötigt.
Im Schritt 310 stellt der Client eine Anforderung für einen vom Server zu erbringenden Dienst. Diese Anforderung wird im Schritt 320 über das Netzwerk an den Server übertragen. Im Schritt 322 sendet der Server eine sofortige Bestätigung an den Client. Im Schritt 330 nimmt der Server die Anforderung für die Erbringung eines Dienstes an und geht dazu über, die Anforderung für die Erbringung eines Dienstes im Schritt 332 zu verarbeiten. Während der Server die Anforderung verarbeitet, bringt der Client im Schritt 312 andere Verarbeitungsaufgaben zum Abschluss. Vor der Verarbeitung dieser Anforderung ist der Server möglicherweise auch mit der Verarbeitung anderer Anforderungen beschäftigt. Nachdem die Verarbeitung der Anforderung im Schritt 332 abgeschlossen wurde, sendet der Server im Schritt 334 eine Antwort 324 an den Client. Die Antwort wird im Schritt 314 empfangen, und der Client fährt mit der Verarbeitung fort.
Fig. 5 zeigt den Dialogverkehr, der stattfindet, wenn eine Brücke in das asynchrone System von Fig. 4 eingefügt wird. Die Interaktionen des Client in den Schritten 310, 312 und 314 sind gleich wie in Fig. 4, ebenso wie die Interaktionen des Servers in den Schritten 330, 332 und 334. Die Anforderung 320, die sofortige Rückgabe 322 und die Antwort 324 werden zwischen dem Client und der Brücke und zwischen der Brücke und dem Server in entsprechende Reaktionen aufgeteilt. Die Arbeitsweise der Brücke als Reaktion auf diese Interaktionen wird nun beschrieben. Im Schritt 310 wird eine Anforderung 320A vom Client an die Brücke übertragen. Im Schritt 410 sendet die Brücke eine sofortige Bestätigung 322A an den Client, und die Brücke nimmt die Anforderung für die Erbringung eines Dienstes 320A an. Statt die Anforderung zu verarbeiten, verzeichnet die Brücke im Schritt 412 den Namen des Client und bringt jedwede zusätzliche Verarbeitung im Schritt 414 zum Abschluss.
Bei dieser zusätzlichen Verarbeitung kann es sich um jedwede zusätzliche Verarbeitung handeln, die gewünscht wird, um die Anforderung von dem Client oder deren zugehörige Daten vollständig zu verarbeiten. Eine solche Verarbeitung kann Änderungen an der Anforderung oder den zugehörigen Daten vornehmen, oder sie kann die Anforderung und die zugehörigen Daten unverändert lassen. Beispiele für eine solche Verarbeitung sind unter anderem:
1. Die Tatsache, dass die in der Anforderung ausführlich angegebene Methode mit Parametern aufgerufen wurde, die gleich den zu der Anforderung gehörenden Daten sind und protokolliert werden können;
2. die Verarbeitung kann durchgeführt werden, um festzustellen, an welchen von mehreren Servern diese Anforderung weitergeleitet werden muss, um eine gleichmäßige Verteilung der Arbeitslast zwischen den Servern vorzunehmen, wobei die Ergebnisse dieser Verarbeitung zur Feststellung dienen, wohin die Anforderung geleitet wird; oder
3. die Anforderung kann geprüft werden, um festzustellen, an welchen Server der Client seiner Meinung nach die Anforderung geschickt hat, und dann wird die Anforderung von der Brücke an diesen Server geleitet.
Im Schritt 416 leitet die Brücke die Anforderung für die Erbringung eines Dienstes 320B an den Server weiter. Im Schritt 330 sendet der Server eine sofortige Bestätigung 322B an die Brücke. Während der Server die Anforderung verarbeitet, bringt die Brücke im Schritt 420 andere Verarbeitungsaufgaben zum Abschluss. Nachdem die Verarbeitung der Anforderung durch den Server im Schritt 332 abgeschlossen wurde, sendet der Server im Schritt 334 eine Antwort 324A an die Brücke. Die Antwort wird im Schritt 430 empfangen, und jedwede zusätzliche Verarbeitung, wie beispielsweise die Protokollierung der Parameter, die der Server an den Client zurückgesandt hat, wird im Schritt 432 von der Brücke durchgeführt. Im Schritt 434 leitet die Brücke dann die Antwort 324B an den Client weiter.
Eine Brücke (300 in Fig. 3) wird von einem Client-Objekt und einem Server-Objekt durch Vererbung abgeleitet. Das bedeutet, dass die Brücke die Schnittstelle (das heißt alle Attribute und Methoden) von sowohl dem Client-Objekt als auch dem Server-Objekt erbt. Das Beispiel 1 zeigt, wie eine Brücke in der Sprache IDL bei einem asynchronen System definiert wird. Beispiel 1 - Definition einer asynchronen Brückenklasse

Synchrone Umgebung

Nehmen wir nochmals Bezug auf Fig. 6, welche die Bestandteile einer Brücke 300 zur Verwendung mit einem Client 53 und einem Server 54 enthält, die in einer synchronen Betriebsart arbeiten. Die Brücke 300 und der Server 54 enthalten ein Server-Objekt. Diese Server-Objekte sind jeweils als das Server-Objekt der Brücke 301 und das Server-Objekt des Servers 501 gezeigt. Der Server 54 enthält mindestens ein Objekt mit der Bezeichnung Objekt des Servers 503 (das nicht mit einem Server-Objekt zu verwechseln ist). Dies ist das Objekt, das tatsächlich die von dem Client angeforderten Dienste erb ringt. Die Brücke 300 enthält ein Objekt mit der Bezeichnung Objekt der Brücke 304, das die Funktionen der Brücke selbst bereitstellt.
Der Client 53 enthält ein Stellvertreterobjekt mit der Bezeichnung Server-Stellvertreter der Brücke 401, bei dem es sich um den lokalen Vertreter des Server-Objekts der Brücke 301 handelt. Der Client ist der Meinung, dass dies das Server- Objekt des Servers 501 in dem Server darstellt, der die Dienste erbringt. Ebenso enthält die Brücke 300 ein Stellvertreterobjekt mit der Bezeichnung Server-Stellvertreter des Servers 302, bei dem es sich um den lokalen Vertreter des Server- Objekts des Servers 501 handelt. Wie vorstehend erklärt wurde, ist ein Server-Objekt ein Objekt, das Objekte im Server verwaltet.
Der Client 53 enthält auch ein Stellvertreterobjekt mit der Bezeichnung Objektstellvertreter der Brücke 402, bei dem es sich um den lokalen Vertreter des Objekts der Brücke 304 handelt. Der Client ist der Meinung, dass dies das Objekt 503 in dem Server darstellt, der die Dienste erbringt. Ebenso enthält die Brücke 300 ein Stellvertreterobjekt mit der Bezeichnung Objektstellvertreter des Servers 303, bei dem es sich um den lokalen Vertreter des Objekts des Servers 503 handelt. Diese Stellvertreter werden bei den Übertragungen zwischen dem Client 53 und dem Server 54 verwendet, die vom Client 53 eingeleitet werden.
In einem synchronen System werden Übertragungen nur vom Client 53 eingeleitet. Diese Übertragungen werden mittels des Objektstellvertreters der Brücke 402, der sich im Client 53 befindet und dem Client 53 die Kommunikation mit der Brücke 300 ermöglicht, und mittels eines Objektstellvertreters des Servers 303 erreicht, der sich in der Brücke 300 befindet und der Brücke 300 die Kommunikation mit dem Server 54 ermöglicht.
Wie aus Fig. 6 hervorgeht, werden die Objekte und die Stellvertreterobjekte, die sich im oberen Teil eines jeden der Blöcke befinden, die den Client 53, die Brücke 300 und den Server 54 darstellen, bei der Erzeugung, der Löschung und Positionierung von Objekten durch den Client und die Brücke verwendet. Die Objekte und die Stellvertreterobjekte, die sich im unteren Teil eines jeden der Blöcke befinden, die den Client 53, die Brücke 300 und den Server 54 darstellen, werden bei dem Übertragungsprozess zwischen dem Client 53, der Brücke 300 und dem Server 54 verwendet.
Fig. 7 zeigt den Dialogverkehr zwischen einem Client nach dem Stand der Technik und einem Server nach dem Stand der Technik über ein Netzwerk nach dem Stand der Technik in einer synchronen Umgebung. In einer synchronen Umgebung leitet der Client eine Kommunikation mit dem Server ein, indem er an den Server eine Anforderung für die Erbringung eines Dienstes stellt. Der Server arbeitet die Anforderung ab und schickt das Ergebnis an den Client zurück, indem er einfach die sich aus der Verarbeitung der Anforderung ergebenden Parameter zurückgibt (??). Der Server leitet keine Übertragung mit dem Client ein, um die Anwort zurückzusenden. Der Client 53 empfängt die Antwort einfach über Rückgabeparameter von der Methode, die er auf dem Server 54 aufgerufen hat.
Bei dem System nach dem Stand der Technik gibt es zwei Unterschiede zwischen dem Betrieb in einer asynchronen Umgebung, die vorstehend mit Bezug auf Fig. 4 beschrieben wurde, und einer synchronen Umgebung. Der erste Unterschied ist, dass der Client, nachdem er im Schritt 310 eine Anforderung für die Erbringung eines Dienstes gestellt hat, andere Verarbeitungsaufgaben im Schritt 312 nicht zum Abschluss bringt, sondern stattdessen im Schritt 510 auf eine Antwort vom Server wartet. Der zweite Unterschied ist, dass der Server im Schritt 322 keine sofortige Bestätigung an den Client schickt. Ansonsten sind die nummerierten Schritte in Fig. 7 mit den entsprechenden nummerierten Schritten in Fig. 4 identisch.
Fig. 8 zeigt den Dialogverkehr, der stattfindet, wenn eine Brücke in das synchrone System von Fig. 7 eingefügt wird. Die Interaktionen des Client in den Schritten 310 und 314 sind gleich wie in Fig. 7, ebenso wie die Interaktionen des Servers in den Schritten 330, 332 und 334. Die Anforderung 320 und die Antwort 324 werden zwischen dem Client und der Brücke und zwischen der Brücke und dem Server in entsprechende Reaktionen aufgeteilt. Die Arbeitsweise der Brücke als Reaktion auf diese Interaktionen wird nun beschrieben.
Im Schritt 410 nimmt die Brücke die Anforderung für die Erbringung eines Dienstes 320A an. Statt die Anforderung zu verarbeiten, verzeichnet die Brücke den Namen des Client im Schritt 412 und bringt jedwede zusätzliche Verarbeitung im Schritt 414 zum Abschluss. Diese zusätzliche Verarbeitung kann beliebige oder alle Elemente der zusätzlichen Verarbeitung enthalten, die vorstehend in Verbindung mit der asynchronen Umgebung und mit Bezug auf Fig. 5 beschrieben wurden. Im Schritt 416 leitet die Brücke die Anforderung für die Erbringung eines Dienstes an den Server weiter. Während der Server die Anforderung verarbeitet, wartet die Brücke im Schritt 610 auf eine Antwort vom Server. Nachdem der Server im Schritt 332 die Verarbeitung der Anforderung abgeschlossen hat, sendet er im Schritt 334 eine Antwort 324A an die Brücke. Die Antwort wird im Schritt 430 empfangen, und im Schritt 432 führt die Brücke jedwede zusätzliche Verarbeitung durch, wie zum Beispiel die Protokollierung der vom Server an den Client zurückgesandten Parameter. Im Schritt 434 leitet die Brücke 300 dann die Antwort 324B an den Client weiter.
Wie aus der vorstehenden Beschreibung hervorgeht, arbeitet der Client synchron mit der Brücke, und folglich ist die Schnittstelle, die der Client von der Brücke sieht, genauso ausgelegt, als würde der Client direkt mit dem Server kommunizieren. Die Brücke arbeitet synchron mit dem Server, und folglich ist die Schnittstelle, die der Server von der Brücke sieht, genauso ausgelegt, als würde der Server direkt mit dem Client kommunizieren.
Eine Brücke wird nur von einem Server abgeleitet. Ausdrückliche Client-Objekte brauchen nicht vorhanden zu sein, da ein Client 53 einfach eine Methode auf einem Server 54 aufruft und die Antwort über Rückgabeparameter in genau dieser Methode empfängt. Vom Server 54 wird keine getrennte Kommunikation eingeleitet. Das Beispiel 2 zeigt, wie ein Objekt 300 für ein synchrones System definiert wird. Beispiel 2 - Definition einer synchronen Brückenklasse

Einfügen der Brücke

Der Aufbau und die Definition einer Brücke wurden vorstehend sowohl für den asynchronen Betrieb als auch den synchronen Be trieb näher bezeichnet. Nachdem eine Brücke zur Verwendung in einer der beiden Betriebsarten definiert worden ist, muss die definierte Brücke transparent zwischen den Client und den Server eingefügt werden, so dass bei einer Anforderung, einen Server zu erzeugen, stattdessen eine Brücke mit der vollständigen Schnittstelle eines Server-Objekts erzeugt wird.
Der Client 53 und der Server 54 enthalten Instanzen von jeweiligen Client- und Server-Klassen. Es gibt viele verschiedene Methoden, die zum Auffinden von fernen Objekten, zur Erzeugung einer Instanz eines fernen Objekts und zum Aufrufen von Methoden auf fernen Objekten verwendet werden können.
Eine typische, repräsentative Methode nach dem Stand der Technik wird nun beschrieben, wobei nochmals Bezug auf Fig. 1 genommen wird.
1. Ein DSOM Object Manager (SOMD_ObjectMgr) (der sich in 50 befindet) wurde entweder bei der Initialisierung des Client erzeugt oder muss jetzt durch Aufruf der Funktion SOMD_Init () erzeugt werden, die im Client 53 als Teil des Object Request Broker 50 zur Verfügung steht.
2. Der Client 53 führt eine Methode auf dem SOMD_ObjectMgr aus, um einen Server 54 einer geeigneten Objektklasse zur Verwendung mit dem Client 53 zu lokalisieren.
SOMD_ObjectMgr erzeugt im Client 53 ein Stellvertreterobjekt (das sich in 50 befindet) als lokalen Vertreter für das Server-Objekt (das sich in 52 befindet) auf dem fernen Server 54. Man beachte, dass im fernen Server 54 noch kein Server-Objekt vorhanden ist.
3. Der Client 53 gibt einen Methodenaufruf somdCreateObj() auf dem Server-Stellvertreterobjekt aus. In dem Methodenaufruf ist als Parameter die Klasse des Zielobjekts 51 enthalten, das der Client erzeugen möchte. Mit dem fernen Server wird eine Verbindung aufgebaut, und auf dem fernen Server 54 wird ein Server-Objekt (nicht gezeigt) der geeigneten Klasse erzeugt. Sobald das Server-Objekt (nicht gezeigt) erzeugt worden ist, erzeugt es selbst ein Zielobjekt 51 der angeforderten Klasse im Server 54. Als Teil der Rückgabeparameter werden dem Client 53 Informationen geliefert, die es ihm ermöglichen, für das Zielobjekt 51 ein Stellvertreterobjekt 49 zu erzeugen.
4. Der Client ist nun in der Lage, Methodenaufrufe auf seinem lokalen Stellvertreterobjekt 49 auszugeben, die auf dem Zielobjekt 51 ausgeführt werden, und die Ergebnisse werden an den Client 53 zurückgesandt.
Es kann mehr als eine Klasse von Server-Objekten geben. Beispielsweise kann es eine Klasse von Servern zur Verwendung bei der Erbringung von Druckdiensten, eine weitere für Dateispeicherdienste und noch eine für Übertragungsdienste geben. Nach dem Stand der Technik kommunizieren diese ohne die Hilfe der vorliegenden Erfindung miteinander.
Das Verfahren, mit dem die Brücke transparent zwischen den Client und den Server eingefügt wird, wird nun mit Bezug auf Fig. 3 beschrieben.
Eine Brückenklasse wird erzeugt, die einer jeden der Server- Objektklassen nach dem Stand der Technik; entspricht. Das Server-Objekt des Servers 501 ist eine Instanz einer Server-Ob jektklasse nach dem Stand der Technik. Das Server-Objekt der Brücke 301 ist eine Unterklasse der vorgegebenen Serverklasse. In dem obigen Beispiel kann es eine Brückenklasse von Servern zur Verwendung bei der Erbringung von Druckdiensten, eine andere für Dateispeicherdienste und noch eine für Übertragungsdienste geben.
Das Server-Objekt (das von der Serverklasse geerbt wurde) im Rahmen der Definition einer jeden Brückenserverklasse wird geändert, so dass es, wenn das Server-Objekt der Brücke 301 als Teil einer Brückenserverklasse erzeugt wird, die Änderungen enthält. Die Änderungen werden an der Methode, die Zielobjekte erzeugt, und der Methode, die vom Server-Objekt empfangene Methoden Zielobjekten im Server zuweist, vorgenommen.
Die geänderte Methode zur Erzeugung des Objekts des Servers 503 (eines Zielobjekts) nimmt die Anforderung vom Client zur Erzeugung eines Objekts des Servers 503 in einem Server an und konstruiert an seiner Stelle ein Brückenobjekt 304.
Die geänderte Methode, die vom Server-Objekt der Brücke 301 empfangene Methoden Objekten des Servers 503 (Zielobjekten) im Server zuweist, verzeichnet einfach den Namen des Client (Schritt 412 in Fig. 5), bringt die zusätzliche Verarbeitung zum Abschluss (Schritt 414 in Fig. 5) und ruft die ursprüngliche Zuweisungsmethode auf, um die Methode dem Objekt zuzuweisen.

Anwendungen der vorstehend beschriebenen Ausführungsformen

Bezug nehmend auf Fig. 9, kann ein einzelner Client 53 unter Verwendung der Brücke 300 der vorliegenden Erfindung, die vor stehend beschrieben wurde, Dienste von mehreren Servern 54A bis 54D anfordern. Der Client weiß nicht, dass die Anforderungen auf verschiedenen Servern 54A bis 54D ausgeführt werden. Die Brücke 300 entscheidet, an welchen der diversen Server 54A bis 54D die Anforderung geleitet werden soll.
Eine gleichmäßige Verteilung der Arbeitslast zwischen jedem der diversen Server 54A bis 54D lässt sich ohne zusätzliche Programmierung entweder im Client 53 oder in den Servern 54A bis 54D erreichen. In einer Ausführungsform, die eine gleichmäßige Verteilung der Arbeitslast erreicht, verwendet die Brücke 300 einen "Round-Robin"-Algorithmus. Bei diesem Algorithmus wird jede neue Anforderung eines Client an den nächsten Server 54A bis 54D in Folge geleitet. In einer anderen Ausführungsform, die dem Erreichen einer gleichmäßigen Verteilung der Arbeitslast dient, werden die von jedem der Server 54A bis 54D erhaltenen Antwortzeiten gemessen, und komplexere Algorithmen, die dem Fachmann bekannt sind, werden verwendet, um die Arbeitslast gleichmäßig zwischen den Servern 54A bis 54D zu verteilen. Beide Ausführungsformen können realisiert werden, ohne Änderungen am Code in einem der Server 54A bis 54D oder im Client 53 vornehmen zu müssen.
Fig. 10 zeigt drei Clients 53A bis 53C, die an drei nach dem Stand der Technik verbundene Server 54A bis 54C angeschlossen sind. Jeder der Clients 53A bis 53C hat eine Verbindung 901 bis 909 zu jedem der Server 54A bis 54C. Somit gibt es zwischen den Clients und den Servern insgesamt neun Verbindungen 901 bis 909.
Bezug nehmend auf Fig. 11, kann es mit der Brücke 300 der vorliegenden Erfindung, die vorstehend beschrieben wurde, meh rere Clients 53A bis 53C geben, die Dienste von mehreren Servern 54A bis 54C anfordern, ohne dass einer der Clients 53A bis 53C weiß, dass die Anforderungen auf verschiedenen Servern 54A bis 54C ausgeführt werden oder dass die Server 54A bis 54C andere Anforderungen für andere Clients 53A bis 53C ausführen. Die Brücke 300 entscheidet, an welchen der diversen Servern 54A bis 54C jede einzelne Anforderung von jedem der Clients 53A bis 53C geleitet werden soll.
Die Anzahl der Verbindungen im Netzwerk wird verringert, indem alle Anforderungen durch die Brücke 300 geleitet werden. In verallgemeinerter Form wird die Anzahl der Verbindungen in einem System mit n Clients 53 und m Servern 54 von n*m auf n+m verringert.

Claims

1. Brücke (300) zur Verwendung zwischen einem Client (53) und einem Server (54) in einem verteilten objektorientierten Datenverarbeitungssystem, wobei die Brücke eine Schnittstelle zu einem Stellvertreterobjekt hat, das sich im Adressraum des Client befindet, die der Schnittstelle eines Servers entspricht, und eine Schnittstelle zum Server, die der Schnittstelle eines Stellvertreterobjekts entspricht, das sich im Adressraum des. Client befindet, wobei die Brücke zwischen dem Stellvertreterobjekt, das sich im Adressraum des Client befindet, und dem Server transparent eingefügt wird und eine Kennung verzeichnet, die dem Stellvertreterobjekt zugeordnet ist, das sich im Adressraum des Client befindet.

2. Brücke (300) nach Anspruch 1, wobei:

der Client (53) und der Server (54) asynchron arbeiten; die Brücke von einem Client und einem Server durch Vererbung abgeleitet wird;

die Brücke Methoden überschreibt, die sie von dem Server geerbt hat, um den Namen des Client, der die Anforderung stellt, zu verzeichnen und um die Anforderung an den Server weiterzuleiten; und

die Brücke Methoden überschreibt, die sie von dem Client geerbt hat, um Antwortparameter an den Client weiterzuleiten.

3. Brücke (300) nach Anspruch 1, wobei:

der Client (53) und der Server (54) synchron arbeiten;

die Brücke von einem Server durch Vererbung abgeleitet wird; und

die Brücke Methoden überschreibt, die sie von dem Server geerbt hat, um die Methoden auf dem Server aufzurufen und um Antwortparameter an den Client zurückzusenden.

4. Brücke (300) nach Anspruch 1, die des Weiteren ein Mittel zur Überwachung und Protokollierung von Anforderungen zwischen dem Client (53) und dem Server (54) und von Daten, die zu diesen Anforderungen gehören, umfasst.

5. Brücke (300) nach Anspruch 1, die des Weiteren ein Mittel zur gleichmäßigen Verteilung der Arbeitslast zwischen den Servern (54) umfasst.

6. Brücke (300) nach Anspruch 5, wobei das Mittel zur gleichmäßigen Verteilung der Arbeitslast Antwortzeiten misst und als Antwort auf die gemessene Antwortzeit Anforderungen von den Clients (53) an die Server (54) leitet.

7. Brücke (300) nach Anspruch 1, wobei:

das verteilte objektorientierte Datenverarbeitungssystem m Clients (53) und n Server (54) umfasst (wobei n und m ganze Zahlen größer oder gleich 2 sind), wobei jeder der m Clients in der Lage ist, Dienste von jedem der n Server anzufordern;

die Brücke mit den m Clients und den n Servern verbunden ist; und

die Brücke dadurch die Anzahl der Verbindungen zwischen den m Clients und den n Servern von n*m auf n+m verringert.

8. Brücke (300) nach einem der Ansprüche 1 bis 7, wobei die Schnittstellen zwischen Objekten CORBA-Schnittstellen sind.

9. Brücke (300) nach Anspruch 8, wobei das verteilte objektorientierte Datenverarbeitungssystem DSOM-Klassenbibliotheken verwendet.

10. Verfahren zum Betreiben eines verteilten Client-Server- Datenverarbeitungssystems, das die folgenden Schritte umfasst:

Festlegen einer Schnittstelle für eine Brücke (300) in der Weise, dass die Schnittstelle zu einem Stellvertreterobjekt, das sich im Adressraum des Client (53) befindet, der Schnittstelle eines Servers (54) entspricht und die Schnittstelle zu einem Server der Schnittstelle eines Stellvertreterobjekts entspricht, das sich im Adressraum des Client befindet;

Transparentes Einfügen der Brücke zwischen dem Stellvertreterobjekt, das sich im Adressraum des Client befindet, und dem Server; und

Verzeichnen einer Kennung durch die Brücke, die dem Stellvertreterobjekt zugeordnet ist, das sich im Adressraum des Client befindet.

11. Verfahren nach Anspruch 11, wobei der Client (53) und der Server (54) asynchron arbeiten und der Schritt der Festlegung einer Schnittstelle Folgendes umfasst:

Ableiten der Schnittstelle zu einem Client von einem Server durch Vererbung;

Überschreiben von Methoden, die von, dem Server geerbt wurden, um den Namen des Client, der die Anforderung stellt, zu verzeichnen und um die Anforderung an den Server weiterzuleiten;

Ableiten der Schnittstelle zu einem Server von einem Client durch Vererbung; und

Überschreiben von Methoden, die von, dem Client geerbt wurden, um Antwortparameter an den Client weiterzuleiten.

12. Verfahren nach Anspruch 11, wobei der Client (53) und der Server (54) synchron arbeiten und der Schritt der Festlegung einer Schnittstelle Folgendes umfasst:

Ableiten der Schnittstelle zu einem Client von einem Server durch Vererbung; und

Überschreiben von Methoden, die vor, dem Server geerbt wurden, um die Methoden auf dem Server aufzurufen und um Antwortparameter an den Client zurückzusenden.

13. Verteiltes objektorientiertes Datenverarbeitungssystem, das einen oder mehr Server (54), einen oder mehr Clients (53) und eine Brücke (300) nach einem der Ansprüche 1 bis 7 umfasst.