Aufgabe 4: Erweitertes Marshalling, automatische Erzeugung von Stubs
Aufgabenbeschreibung
In der Aufgabe 3 wurden manuell Stubs für Client und Server für ein bestimmtes
Objekt erstellt. In dieser Aufgabe soll diese automatisiert werden, ausgehend
von einer Schnittstellenbeschreibung.
Zuvor soll jedoch das Marshalling um einige Funktionen erweitert werden.
Teilaufgabe a: Erweiterung des Marshallings
In dieser Teilaufgabe soll das Marshalling um eine Unterstützung für Arrays
von primitiven Datentypen und für eine Call-By-Value-Result-Semantik
erweitert werden.
Arrays mit fester Länge:
Für jeden primitiven Datentyp ist in der Klasse Message eine Methode
bool writeArray(int len, type data[]) und eine entsprechende
readArray-Methode vorzusehen. Es kann davon ausgegangen werden, dass
read/write von den Stubs
auf Client- und Serverseite mit gleicher Längenangabe aufgerufen werden.
Beim read hat der Aufrufer einen
hinreichend grossen Puffer bereitzustellen.
Call by Value-Result: Bisher werden Methodenparameter mit
Call-by-Value-Semantik zum Server übertragen. Um etwas ähnliches zu
"Call-by-Referenz" bereitzustellen, lässt sich eine Call-by-Value-Result
Semantik implementieren. Hierzu ist ein Parameter zunächst wie bei
Call-by-Value zum Server zu übertragen. Bei Rückkehr aus dem Funktionsaufruf
ist der (möglicherweise vom Server modifizierte) Parameter wieder zurück
zum Klienten zu übertragen. Erstellen Sie auch hierzu einen kleinen
Testserver mit entsprechend angepassten Stubs. Parameter, die per
Value-Result übertragen werden sollen, sind als Referenzparameter
zu deklarieren (Bsp. int16_t ¶m statt int16_t param)
Teilaufgabe b: automatische Erzeugung von Stubs und Skeletons
In der Übung haben Sie das Tool IDLflex zur
automatischen Erzeugung von Stubs und Skeletons kennengelernt.
Dieses sollen Sie als Basis einsetzen, um automatisch Stubs für Ihr
RPC-System zu erstellen. Hierzu ist eine entsprechende
XML-Steuerungsdatei für IDLflex zu erstellen.
Als Eingabe soll eine Schnittstellenbeschreibung in CORBA IDL dienen.
In CORBA IDL kann man für jeden Parameter eine Richtung angeben, in die er
transportiert werden soll (in/out/inout). Diese Angabe soll durch die
erzeugten Stubs (und Skeletons) unterstützt werden. "in" ist dabei auf
Call-by-Value abzubilden, "inout" auf Call-by-Value-Result. "out" lässt
sich wie "inout" behandeln, die Übertragung der Daten zum Server kann dabei
aber unterdrückt werden.
Alle bisher manuell erzeugten Stubs (Teilaufgabe (a) sowie vorhergegangene
Aufgabe 3) sollten sich damit nun auch automatisch generieren lassen.
Hinweise zu IDLflex (update)
Ein paar Anmerkungen:
- FAXWriter (Übungsfolien) exisitert nicht, statt dessen wie im
Beispiel unter /local/idlflex JavaWriter verwenden!
- Zeilenumbrüche in der IDLflex-Ausgabe lassen sich mit
<P/> erzeugen
- Der Dateiname bei
FILE lautet jetzt nicht mehr
fest "test", sondern wird entsprechend dem Namen des aktuellen
IDL-Elements gewählt. Auf globaler Ebene ist dies der Dateiname
ohne .idl, innerhalb eines Moduls/Interfaces/etc ist dies der
entsprechende Name.
Statt "FAX:FILE:header", aus dem ein Dateiname mit ".h" generiert
wird, kann nun ein beliebiges Suffix erzeugt werden. Beispiel
"FAX:FILE:_stub.h" erzeugt aus einer test.idl eine Datei test_stub.h
- Bei
ITERATE kann man rückwärts iterieren mit der
Angabe von ":reverse", also z.B. <ITERATE NAME="MEMBERS:revers">
Mit LOOP:index erhält man eine fortlaufende Numerieung ab 0, mit
LOOP:rindex kann man auch eine umgekehrte Numerierung erreichen.
- Etwas schlecht dokumentiert: Wie kommt man zu übergeordneten IDL-Elementen, also zum Beispiel den Namen eines Interfaces, wenn man sich innerhalb des
ITERATE über die Methoden befindet?
<GET T="IDL:name" OBJ="CONTAINER"> geht in der Struktur
der IDL-Datei ein Element nach oben (z.B. von Methode zu Interface).
Abgabe
bis 28.05.2003 12:00 Uhr
Abgabe mittels /proj/i4vs/pub/abgabe
(Abgabe in 2er oder 3er Gruppen möglich)
