-
Die vorliegende Erfindung betrifft
ein Verfahren zum Aufzeichnen der Kommunikation zwischen einem Client
und einem Server in Anwendungen, die auf verteilten Objektsystemen
wie z.B. RMI oder CORBA basieren.
-
In modernen, auf der Basis von verteilten
Objektsystemen 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
Kommunikation über
das Netzwerk realisieren. Die Schnittstellen der verteilten Objekte
am Server haben ihre Entsprechungen auf Seite des Clients in den Methoden
der Stub-Klassen. Die Stubs und Skeletons werden hierbei über entsprechende
Compiler bzw. Generatoren aus einer Beschreibung der für die jeweilige
Anwendung erforderlichen 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
aufzeichnen und später
wieder abspielen zu können. Dies
ermöglicht
zum einen die Durchführung
von Lasttests an Servern, 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 kennen.
-
Mit einer geeigneten Protokollierung
dieser Kommunikation 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, Werkzeuge für
Client/Server-Anwendungen, die auf Enterprise-JavaBeans basieren
sowie Werkzeuge, die die Konsistenz des Software-Entwicklungsprozesses
sichern, in Frage.
-
Bisher werden zur Aufzeichnung der
Kommunikation zwischen Clients und Servern in Netzwerken im Kontext
von Anwendungen auf der Basis von CORBA so genannte Interceptoren
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.
-
Aus der
US 6,105,059 ist ein Verfahren zum
Bereitstellen von Informationen über
den Status der Programmausführung
in verteilten Computersystemen bekannt. Durch Modifikation von Client-
und von Server-Stubs werden zusätzliche
Stub-Codes erzeugt, die Datenpakete bzw. Daten über den Status der Programmausführung bei
oder während
eines RPC erzeugen. Diese zusätzlich
erzeugten Datenpakete werden zwischen dem Client und dem Server
in beiden Richtungen ausgetauscht und stehen dort jeweils beliebigen
Anwendungen, insbesondere einem Debug-Werkzeug, zur Verfügung.
-
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 basierenden Anwendungen anzugeben, das
unabhängig
von In terceptoren arbeitet und auch für die Kommunikation auf Basis
anderer auf dem Stub/Skeleton-Mechanismus aufsetzender Verbindungsprotokolle
einsetzbar ist.
-
Darstellung
der Erfindung
-
Die Aufgabe wird mit dem Verfahren
nach Patentanspruch 1 gelöst.
Vorteilhafte Ausgestaltungen des Verfahrens sind Gegenstand der
Unteransprüche.
-
Das vorliegende Verfahren macht sich
den Informationsgehalt der von einem Compiler bzw. Generator erzeugten
Client-Stubs zunutze, die auf Basis der Beschreibung der für die jeweiligen
Client-Server-Anwendungen
erforderlichen Schnittstellen generiert wurden. Hierbei werden die
von dem Compiler bzw. Generator erzeugten Client-Stubs analysiert,
um darin die Schnittstellenklassen der verteilten Objekte sowie
deren Implementation zu identifizieren. Anschließend werden die analysierten
Client-Stubs auf Basis der Analyse durch Einbinden bzw. Einweben
einer Instrumentierung in Form von Protokollanweisungen modifiziert.
Diese Protokollanweisungen werden derart gestaltet, dass sie die
Aufrufe von in publizierten Schnittstellen der verteilten Objekte
enthaltenen Methoden protokollieren und abspeichern.
-
Die Protokollierung sollte hierbei
derart erfolgen, 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
Fachmann kein Problem dar. Aus diesen Client-Stubs lassen sich die
erforderlichen Informationen über
die Schnittstellenklassen der entfernten Objekte und deren Implementationen
extrahieren. Hierfür
stehen dem Fachmann in Programmiersprachen, die Mittel zur Introspektion
bereitstellen, 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
einfache Weise abarbeitbare Kommunikationsprotokolle erstellt werden.
Das Verfahren arbeitet unabhängig
von herstellspezifischen Implementationen, z.B. Interceptoren, 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 Hilfestellung bei der Durchführung
von Systemtests für Anwendungen
bieten, können
die aufgezeichneten Protokolle einfach oder mehrfach abgespielt
werden. Derartige Werkzeuge sind beispielsweise die in der Beschreibungseinleitung
erwähnten
Werkzeuge. Ein wesentliches Anwendungsgebiet der Verwendung der
aufgezeichneten Protokolle liegt in der Simulation von Zugriffen auf
Server in Client-Server-Systemen. Eine weitere Anwendung findet
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 einer derartigen Form der Protokollierung
besteht darin, dass damit das Zeitverhalten der zu testenden Anwendungen
optimal widergespiegelt werden kann.
-
Das vorliegende Verfahren wird nachfolgend
anhand von Ausführungsbeispielen
in Verbindung mit den Zeichnungen nochmals näher erläutert. Hierbei zeigen:
-
1 ein
Beispiel für
eine Architektur eines Systems auf der Basis von CORBA, das gemäß dem vorliegenden
Verfahren modifiziert wurde; und
-
2 stark
schematisiert den Ablauf des vorliegenden Verfahrens.
-
Eine Architektur für ein System
auf der Basis von CORBA, bei dem das vorliegende Verfahren eingesetzt
wurde, ist in der 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 Ob jektimplementationen 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 abarbeitbaren
Protokolls 4 aufgezeichnet. Dieses Protokoll kann in einem
speziellen Testrahmen 5 abgearbeitet werden, um beispielsweise
gegenüber
dem Server 2 das Vorhandensein eines oder mehrerer Clients 1 zu
simulieren. Der Testrahmen 5 kommuniziert hierbei wiederum über entsprechende
IDL-Stubs 8 mit dem Server 2.
-
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 beispielsweise mit
einem geeigneten Werkzeug (Analysator 9) erfolgen kann.
Bei der Analyse wird die Funktionalität der im Paket java.lang.reflect
implementierten Methoden verwendet. Dabei werden die Schnittstellenklassen
der entfernten Objekte 2a und deren Implementationen identifiziert.
Auf der Basis der bei der Analyse extrahierten Informationen werden,
gegebenenfalls über
verfahrensabhängige
Zwischenschritte, instrumentierte Stubs (Protokoll-Stubs 3)
erzeugt. Hierbei wird ausgenutzt, dass alle Informationen über die
Beschaffenheit der IDL-Schnittstellenobjekte in den vom IDL-nach-Java-Compiler erzeugten
Client-Stubs 10 enthalten sind. Wurden 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 Durchfü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 vorliegen 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 Implementationen 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 Schnittstellenklasse, die explizit oder
implizit die in der Eigenschaft CorbaObjectRoute spezifizierte Schnittstellenklasse
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 In formationen verwendet, um die
notwendigen Protokoll-Anweisungen
zu erzeugen. Die Protokollanweisungen werden hierbei in Form von
Aspekten beschrieben, die anschließend mittels eines Aspekt-Compilers in
den Quellcode eingewebt und zu ablauffähigen Protokoll-Stubs 3 kompiliert
werden. Diese Protokoll-Stubs 3 weisen 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 modifizieren. Zusätzlich werden Protokollanweisungen
als Java-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 Protokoll-Anweisungen eingefügt werden,
die die aufgerufenen IDL-Schnittstellen-Methoden mit den aktuellen
Parametern 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önnen.
-
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.
-
-
-
-
- 1
- Java-Client
- 2
- CORBA-Server
- 2a
- Objektimplementation
- 3
- Protokoll-Stubs
- 4
- Protokoll
- 5
- Testrahmen
- 6
- IDL-Skeletons
- 7
- IIOP
- 8
- IDL-Stubs
- 9
- Analysator
- 10
- Client-Stubs
