DE10041082A1 - Verfahren zum Aufzeichnen der Kommunikation zwischen einem Client und einem Server - Google Patents

Abstract

Die vorliegende Erfindung betrifft ein Verfahren zum Aufzeichnen der Kommunikation zwischen einem Client und einem Server in Anwendungen, die auf verteilten Objektsystemen basieren. Bei dem Verfahren werden die von einem Compiler erzeugten Client-Stubs analysiert, um in den Client-Stubs Schnittstellenklassen verteilter Objekte und deren Implementation zu identifizieren. Anschließend werden die Client-Stubs durch Einbindung einer Instrumentierung in Form von Protokollanweisungen modifiziert, die die Aufrufe von in publizierten Schnittstellen der verteilten Objekte enthaltenen Methoden protokolliert und abspeichert. DOLLAR A Das Verfahren ermöglicht die einfache Aufzeichnung abarbeitbarer Kommunikationsprotokolle unabhängig von Interceptoren.

Description

Technisches Anwendungsgebiet

Die vorliegende Erfindung betrifft ein Verfahren zum Aufzeichnen der Kommunikation zwischen einem Client und einem Server in Anwendungen, die auf verteilten Ob­ jektsystemen wie z. B. RMI oder CORBA basieren.

In modernen, auf der Basis von verteilten Objekt­ systemen wie CORBA oder RMI implementierten Client- /Server-Systemen erfolgt die Kommunikation zwischen den einzelnen Clients und dem Server über einen Aufruf von Methoden in Stub- bzw. Skeleton-Klassen, die die Kommu­ nikation über das Netzwerk realisieren. Die Schnitt­ stellen der verteilten Objekte am Server haben ihre Entsprechungen auf Seite des Clients in den Methoden der Stub-Klassen. Die Stubs und Skeletons werden hier­ bei über entsprechende Compiler bzw. Generatoren aus einer Beschreibung der für die jeweilige Anwendung er­ forderlichen Schnittstellen generiert.

Gerade für die Durchführung von Systemtests für Anwendungen ist es wünschenswert, die Kommunikation zwischen den einzelnen Clients und dem Server aufzeich­ nen und später wieder abspielen zu können. Dies ermög­ licht zum einen die Durchführung von Lasttests an Ser­ vern, zum anderen die Durchführung von Regressionstests zur Sicherung der Konsistenz bei der Entwicklung großer Softwaresysteme. Hierfür ist es jedoch erforderlich, die Kommunikation zwischen den Clients und dem Server, das heißt die entsprechenden Aufrufe von Methoden sowie deren zeitliche Abfolge unter Praxisbedingungen zu ken­ nen.

Mit einer geeigneten Protokollierung dieser Kommu­ nikation können dann die aufgezeichneten Client- Aktionen unter Einsatz geeigneter Werkzeuge wiederholt und mehrfach abgespielt werden. Als Werkzeuge kommen hierbei Werkzeuge für Client/Server-Anwendungen, die die das IIOP- oder das JRMP-Protokoll benutzen, Werk­ zeuge für Client/Server-Anwendungen, die auf Enterpri­ se-JavaBeans basieren sowie Werkzeuge, die die Konsi­ stenz des Software-Entwicklungsprozesses sichern, in Frage.

Stand der Technik

Bisher werden zur Aufzeichnung der Kommunikation zwischen Clients und Servern in Netzwerken im Kontext von Anwendungen auf der Basis von CORBA so genannte In­ terceptoren eingesetzt, die speziell für die für die Übertragung benutzte ORB-Implementation programmiert bzw. an diese angepasst werden müssen. Für RMI-basierte Anwendungen ist keine Standard-Technologie bekannt. Diese Interceptoren, die die Datenströme zwischen der Client- und der Server-Anwendung abfangen, sind jedoch auf die jeweilige ORB-Implementation festgelegt.

Die Aufgabe der vorliegenden Erfindung besteht darin, ein einfaches Verfahren zur Aufzeichnung bzw. Protokollierung der Kommunikation zwischen einem Client und einem Server in auf verteilten Objektsystemen ba­ sierenden Anwendungen anzugeben, das unabhängig von Interceptoren arbeitet und auch für die Kommunikation auf Basis anderer auf dem Stub/Skeleton-Mechanismus aufset­ zender Verbindungsprotokolle einsetzbar ist.

Darstellung der Erfindung

Die Aufgabe wird mit dem Verfahren nach Patentan­ spruch 1 gelöst. Vorteilhafte Ausgestaltungen des Ver­ fahrens sind Gegenstand der Unteransprüche.

Das vorliegende Verfahren macht sich den Informa­ tionsgehalt der von einem Compiler bzw. Generator er­ zeugten Client-Stubs zunutze, die auf Basis der Be­ schreibung der für die jeweiligen Client-Server- Anwendungen erforderlichen Schnittstellen generiert wurden. Hierbei werden die von dem Compiler bzw. Gene­ rator erzeugten Client-Stubs analysiert, um darin die Schnittstellenklassen der verteilten Objekte sowie de­ ren Implementation zu identifizieren. Anschließend wer­ den die analysierten Client-Stubs auf Basis der Analyse durch Einbinden bzw. Einweben einer Instrumentierung in Form von Protokollanweisungen modifiziert. Diese Proto­ kollanweisungen werden derart gestaltet, dass sie die Aufrufe von in publizierten Schnittstellen der verteil­ ten Objekte enthaltenen Methoden protokollieren und ab­ speichern.

Die Protokollierung sollte hierbei derart erfol­ gen, dass die erzeugten Protokolle mit entsprechenden Werkzeugen anschließend dazu benutzt werden können, um für den Server die Aktionen von Clients zu simulieren.

Die Analyse der Client-Stubs stellt für den Fach­ mann kein Problem dar. Aus diesen Client-Stubs lassen sich die erforderlichen Informationen über die Schnitt­ stellenklassen der entfernten Objekte und deren Imple­ mentationen extrahieren. Hierfür stehen dem Fachmann in Programmiersprachen, die Mittel zur Introspektion be­ reitstellen, geeignete Werkzeuge zur Verfügung.

Die Modifizierung der derart analysierten Client- Stubs durch Einfügung bzw. Einweben von entsprechenden Protokollanweisungen, die sich auf diese erkannten Schnittstellenklassen und Implementationen beziehen, ist ebenfalls mit programmiertechnischen Kenntnissen möglich.

Mit dem vorgestellten Verfahren können auf einfa­ che Weise abarbeitbare Kommunikationsprotokolle er­ stellt werden. Das Verfahren arbeitet unabhängig von herstellspezifischen Implementationen, z. B. Intercepto­ ren, und ist sowohl für die Kommunikation auf der Basis des IIOP- als auch auf der Basis des Java-spezifischen JRMP-Protokolls einsetzbar.

Unter Einsatz verschiedener Werkzeuge, die Hilfe­ stellung bei der Durchführung von Systemtests für An­ wendungen bieten, können die aufgezeichneten Protokolle einfach oder mehrfach abgespielt werden. Derartige Werkzeuge sind beispielsweise die in der Beschreibungs­ einleitung erwähnten Werkzeuge. Ein wesentliches Anwen­ dungsgebiet der Verwendung der aufgezeichneten Proto­ kolle liegt in der Simulation von Zugriffen auf Server in Client-Server-Systemen. Eine weitere Anwendung fin­ det das Verfahren in der Sicherung der Konsistenz bei der Entwicklung großer Software-Systeme.

Bei geeigneter Einbindung und Ausgestaltung der Protokollierungsfunktionen lassen sich auch Protokolle in Form lauffähiger Programme erzeugen. Der Vorteil ei­ ner derartigen Form der Protokollierung besteht darin, dass damit das Zeitverhalten der zu testenden Anwendun­ gen optimal widergespiegelt werden kann.

Das vorliegende Verfahren wird nachfolgend anhand von Ausführungsbeispielen in Verbindung mit den Zeich­ nungen nochmals näher erläutert. Hierbei zeigen:

Fig. 1 ein Beispiel für eine Architektur eines Sy­ stems auf der Basis von CORBA, das gemäß dem vorliegenden Verfahren modifiziert wurde; und

Fig. 2 stark schematisiert den Ablauf des vorliegen­ den Verfahrens.

Wege zur Ausführung der Erfindung

Eine Architektur für ein System auf der Basis von CORBA, bei dem das vorliegende Verfahren eingesetzt wurde, ist in der Fig. 1 zu erkennen. Die Figur zeigt einen in JAVA erstellten Client 1, der über ein IIOP- Protokoll 7 mit einem entfernten CORBA-Server 2 mit entsprechenden Objektimplementationen 2a kommuniziert. Auf Serverseite sind hierbei entsprechende IDL- Skeletons 6, auf Clientseite die gemäß dem vorliegenden Verfahren modifizierten Protokoll-Stubs 3 dargestellt, die die Kommunikation realisieren. Die Protokoll-Stubs 3 sind hierbei derart modifiziert, dass sie die durch den Client 1 veranlassten Aufrufe der Methoden der Objektimplementationen 2a protokollieren. Hierdurch kann auch für GUI-basierte Clients die Interaktion mit IDL- Schnittstellenobjekten aufgezeichnet werden, ohne dass man deren Implementation ändern muss. Die Kommunikation wird durch die Protokoll-Stubs 3 in Form eines abar­ beitbaren Protokolls 4 aufgezeichnet. Dieses Protokoll kann in einem speziellen Testrahmen 5 abgearbeitet wer­ den, um beispielsweise gegenüber dem Server 2 das Vor­ handensein eines oder mehrerer Clients 1 zu simulieren. Der Testrahmen 5 kommuniziert hierbei wiederum über entsprechende IDL-Stubs 8 mit dem Server 2.

Fig. 2 gibt einen stark schematisierten Überblick über die Architektur eines Systems zur Durchführung des vorliegenden Verfahrens. In diesem Beispiel ist der Client in der Programmiersprache Java implementiert, die Implementation der verteilten Objekte erfolgte in C++. Der Byte-Code der von einem IDL-nach-Java-Compiler generierten Client-Stubs 10 wird analysiert, was bei­ spielsweise mit einem geeigneten Werkzeug (Analysator 9) erfolgen kann. Bei der Analyse wird die Funktionali­ tät der im Paket java.lang.reflect implementierten Me­ thoden verwendet. Dabei werden die Schnittstellenklas­ sen der entfernten Objekte 2a und deren Implementatio­ nen identifiziert. Auf der Basis der bei der Analyse extrahierten Informationen werden, gegebenenfalls über verfahrensabhängige Zwischenschritte, instrumentierte Stubs (Protokoll-Stubs 3) erzeugt. Hierbei wird ausge­ nutzt, dass alle Informationen über die Beschaffenheit der IDL-Schnittstellenobjekte in den vom IDL-nach-Java- Compiler erzeugten Client-Stubs 10 enthalten sind. Wur­ den diese kompiliert, so kann auf diese Informationen mit Hilfe der Funktionen des Paketes java.lang.reflect zugegriffen werden.

Speziell für diese Anwendung müssen bei der Durch­ führung des Verfahrens zwei Varianten unterschieden werden, je nach dem, ob der Quellcode und der von einem Java-Compiler erzeugte Byte-Code der Stub-Klassen vor­ liegen oder ob lediglich der von einem Java-Compiler erzeugte Byte-Code der Stub-Klassen vorliegt.

In beiden Fällen werden unter Verwendung der im Paket java.lang.reflect implementierten Funktionalität die Client-Stubs 10 analysiert. Anhand der folgenden Regeln werden die CORBA-Schnittstellen und deren Imple­ mentationen identifiziert. Im vorliegenden Beispiel werden folgende Regeln zur Identifikation von IDL- Schnittstellen und deren Implementationen angewandt:

• - Spezialisiert die analysierte Klasse explizit oder implizit die Klasse CorbaUserException, so handelt es sich um eine Exception, die nicht weiterbehandelt wird.
• - Ist die analysierte Klasse eine Schnittstellen­ klasse, die explizit oder implizit die in der Eigen­ schaft CorbaObjectRoute spezifizierte Schnittstellen­ klasse spezialisiert, so wird die Klasse als IDL-Objekt betrachtet.
• - Spezialisiert die analysierte Klasse explizit oder implizit die in der Eigenschaft CorbaObject- ImplRoute spezifizierte Klasse, so wird die Klasse als Implementation eines IDL-Objektes betrachtet.

Liegen die Client-Stubs 10 auch im Quellcode vor, so werden zunächst die bei der Analyse extrahierten Informationen verwendet, um die notwendigen Protokoll- Anweisungen zu erzeugen. Die Protokollanweisungen wer­ den hierbei in Form von Aspekten beschrieben, die an­ schließend mittels eines Aspekt-Compilers in den Quellcode eingewebt und zu ablauffähigen Protokoll- Stubs 3 kompiliert werden. Diese Protokoll-Stubs 3 wei­ sen neben der ursprünglichen Funktionalität zusätzlich eine Protokollierungsfunktionalität auf.

Liegt nur der von einem Java-Compiler erzeugte Byte-Code der Stub-Klassen vor, so werden die bei der Analyse extrahierten Informationen dazu verwendet, die entsprechenden Byte-Codes der Stub-Klassen zu modifi­ zieren. Zusätzlich werden Protokollanweisungen als Ja­ va-Quellcode generiert, die dann kompiliert werden und auf die modifizierten Stub-Klassen bezug nehmen.

Der vorliegend beschriebene Protokollmechanismus basiert darauf, dass in die Quellen der Client-Stubs, sofern diese vorliegen, automatisch explizite Proto­ koll-Anweisungen eingefügt werden, die die aufgerufenen IDL-Schnittstellen-Methoden mit den aktuellen Parame­ tern in Form von Listen-Ausdrücken ausgeben. Mittels spezieller Testrahmen können diese Protokolle später wieder ausgewertet werden. Werden die Stubs mit den eingewebten Protokoll-Anweisungen kompiliert, so können automatisch Testdaten gewonnen werden, die zu einem späteren Zeitpunkt mit den Testrahmen zur Durchführung von Regressions- oder Lasttests abgespielt werden kön­ nen.

Im Folgenden ist ein Beispiel angeführt, das die Arbeitsweise des Verfahrens zeigt.

Die Datei Bank.idl beschreibt die Schnittstelle eines Demonstrationssystems. Objekte des Typs Account bieten die folgende Funktionalität

• - Setzen des Kontostandes
• - Abrufen des Konostandes
• - Durchführung von Einzahlungen.

Account-Objekte residieren auf einem entfernten Server und werden über das IIOP-Protokoll angesprochen. Die Client-Stubs wurden gemäß der beschriebenen Technik instrumentiert. Die Datei Bank.dat zeigt den Mitschnitt der Kommunikation für einen Testlauf. Das Protokoll wurde in Form von Lisp-Ausdrücken generiert, um es spä­ ter in einer geeigneten Umgebung wieder ablaufen lassen zu können.

Bezugszeichenliste

1

Java-Client

2

CORBA-Server

2

a Objektimplementation

3

Protokoll-Stubs

4

Protokoll

5

Testrahmen

6

IDL-Skeletons

7

IIOP

8

IDL-Stubs

9

Analysator

10

Client-Stubs

Claims (7)

1. Verfahren zum Aufzeichnen der Kommunikation zwi­ schen einem Client (3) und einem Server (2) in An­ wendungen, die auf verteilten Objektsystemen, ins­ besondere RMI oder CORBA, basieren, mit folgenden Schritten:

• - Analysieren von Client-Stubs (10) in den jewei­ ligen Anwendungen, um in den Client-Stubs (10) Schnittstellenklassen verteilter Objekte (2a) und deren Implementation zu identifizieren,
• - Modifikation der Client-Stubs (10) durch Einbin­ den einer Instrumentierung in Form von Protokoll- Anweisungen, die Aufrufe von in publizierten Schnittstellen der verteilten Objekte (2a) enthal­ tenen Methoden protokolliert und abspeichert.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Protokollierung derart erfolgt, dass die abgespeicherten Aufrufe unter Einsatz entsprechen­ der Werkzeuge (5) abgearbeitet und zur Simulation der Aktionen des Clients (3) gegenüber einem Ser­ ver (2) benutzt werden können.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass bei Client-Stubs (10), die durch einen IDL- nach-Java-Compiler generiert wurden, der Byte-Code der Client-Stubs (10) unter Einsatz von Mitteln der Introspektion, beispielsweise der im Paket java.lang.reflect implementierten Methoden, analy­ siert wird.

4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Einbindung der Instrumentierung durch Be­ schreibung der Protokoll-Anweisungen in Form von Aspekten, die mittels eines Aspekt-Compilers in den Quellcode der Client-Stubs (10) eingebunden und zu ablauffähigen modifizierten Client-Stubs (3) kompiliert werden, erfolgt.

5. Verfahren nach Anspruch 1 bis 3, dadurch gekennzeichnet, dass die Einbindung der Instrumentierung erfolgt, indem die Byte-Codes der Client-Stubs (3) modifi­ ziert und zusätzlich Protokoll-Anweisungen als Ja­ va-Quellcode generiert und kompiliert werden, die auf die modifizierten Client-Stubs (3) Bezug neh­ men.

6. Anwendung des durch das vorangehende Verfahren er­ stellten Protokolls (4) für Lasttests von Servern (2).

7. Anwendung des durch das vorangehende Verfahren er­ stellten Protokolls (4) für Regressionstests bei der Softwareentwicklung.