Architektur des CORBA-Komponentenmodells

Terminänderung Termine der mündl. Prüfung: 20. 7., 24.9.(neu), 28.9.(war 29. 9.), 1.10.(war 30. 9.),

Aufbauend auf einer Einführung der Common Object Request Broker Architecture (CORBA) und des C++-Mappings für IDL wird das CORBA-Komponenten-Modell (CCM) vorgestellt. Dazu werden die relevantent technischen Standards studiert und mit den tatsächlich verfügbaren Implementierungen verglichen.

Als aktuelle Entwicklung auf dem Gebiet von Softwarekomponenten wird ebenfalls Microsofts Shared Source Common Language Infrastructure (SSCLI) und die Integration der Programmiersprache C# in diese Plattform untersucht. Auch hier werden die relevanten ECMA-Standards mit den Implementierungen verglichen.

Schwerpunkte der Vorlesung sind:

die Architektur des CORBA-Komponentenmodells
die Architektur von .NET SSCLI
das C++-Mapping für CCM
Implementierungsstrategien für CCM-Container und -Komponenten

Literatur

M. Henning and S. Vinoski. Advanced CORBA Programming with C++. Addison-Wesley, 1999.
G. Brose, A. Vogel, K. Duddy. Java Programming with CORBA. Advanced Techniques for Building Distributed Applications. OMG Press, 2001
OMG. CORBA 3.0.3.
OMG. CORBA Component Model, v.3.0
OMG. C++ Language Mapping.
ECMA. Standard ECMA-335. Common Language Infrastructure.
Security Service
Microsft Developer Network Library

CORBA-Implementierungen für C++

Vorlesungen

Übungsaufgaben

Aufgabe 1: Java-Sprach-Abbildung

Abgabetermin: 6. Mai

Höchstpunktzahl: 10P

Gegeben sei die IDL-Datei time.idl. Vergleichen Sie die Ausgabe des IDL-zu-Java-Compilers mit der Mapping-Spezifikation (formal/02-08-05)

Geben Sie für jede Ausgabe-Datei an, ob sie für die Klienten-Seite oder die Server-Seite benötigt wird.
Geben Sie für jede Ausgabe-Datei an, ob die darin definierten Klassen und Schnittstellen durch die Java-Sprachabbildung vorgegeben sind oder zur Implementierungsstrategie des CORBA-Laufzeitsystems gehören.
Geben Sie für die aus der Schnittstelle CosTime::TimeService generierten Klassen und Schnittstellen an, welche Definitionen sich aus dem Sprachabbildung ergeben, welche zur Implementierungsstrategie gehören, und welche der von der Sprachabbildung vorgegebenen Konstrukte vom IDL-Compiler nicht oder falsch generiert werden. (Hinweis: Sie können diese Klassifizierung beispielsweise durch farbliche Markierung der Quellen in HTML-Form vornehmen).

(Englisch)

Aufgabe 2: Klientenimplementierung in C++

Abgabetermin: 21. Mai

Höchstpunktzahl: 10P

Gegeben sei die IDL-Datei aufgabe2.idl sowie die Objektreferenz, die durch den IOR

IOR:000000000000001849444C3A41756667616265322F5365727665723A312E30
00000000010000000000000060000102000000001C63636D312E63636D2E687069
2E756E692D706F747364616D2E646500162E000000000008617566676162653200
000001000000010000002000000000000100200000000100010001000101090000
00020501000100010100

definiert wird (corbaloc::141.89.225.148:5678/aufgabe2). Implementieren Sie einen Klienten in C++.

Aufgabe 3: Serverimplementierung in C++

Abgabetermin: 3. Juni

Höchstpunktzahl: 10P

Implementieren Sie einen Server für die Schnittstelle aus Augabe 2. Beim Start des Servers soll sich dieser in den Namensdienst unter /<id> eintragen, wobei <id> Ihre Unix-Account-Kennung ist. Passen Sie Ihren Klienten derart an, den Server an dieser Stelle zu finden.

Im CORBA-Labor können Sie als Namensdienst corbaloc::ccm1/NameService verwenden.

Aufgabe 4: Komponentenimplementierung in C++

Abgabetermin: 17. Juni

Höchstpunktzahl: 10P

Implementieren Sie eine Komponente eines Auktionshauses, wie sie in auktion.idl definiert ist. Wählen Sie dabei eine der folgenden Teilaufgaben:

Auktionshaus: Erzeugt auf Verkäufer-Anfrage neue Auktionen, leitet Gebote (einschließlich Initialgebot) an alle Bieter weiter, erteilt nach einer Weile Zuschlag.
Verkäufer: Bietet in unregelmäßigen Abständen neue Gegenstände zum Verkauf.
Bieter: Empfängt Gebote, entscheidet sich gelegentlich, aktuelles Gebot zu überbieten.
Filter: Meldet sich anstelle der Bieter beim Auktionshaus, und filtert Gebote. Falls mehrere Bieter den gleichen Filter benötigen, sollte sich der nur einmal beim Autionshaus anmelden.

Ein möglicher Ablauf dieser Anwendung ist in einem Ablaufdiagramm dargestellt.

Bitte geben Sie die gewählte Teilaufgabe bis zum 10.6. per Email bekannt.

Alle Komponenten sollten mit Mico im CCM-Pool abgearbeitet werden können. Zur Ablaufverfolgung reicht es, wenn die Komponenten-Homes als separate Serverprozesse laufen und den Ablauf auf der Standardausgabe protokollieren.

Folgende Test-Dienste stehen im CCM-Pool zur Verfügung:

Der Namensdienst, unter corbaloc::ccm1/NameService
Ein Welt-Objekt, unter corbaname::ccm1/loewis/Welt
Ein VerkaeuferHome, unter corbaname::ccm1/loewis/Verkaeufer
Ein BieterHome, unter corbaname::ccm1/loewis/Bieter

Obige Binaries wurden für Mico 2.3.10 übersetzt. Für Mico 2.3.11 stehen separate Binaries zur Verfügung. Zum Debugging empfiehlt es sich, die Komponenten separat zu starten, da sie auf ihre Standardausgabe Diagnosemeldungen ausgeben. Der Bieter überbietet jedes eingehende Gebot, und das Auktionshaus gibt einem zufälligen Bieter den Zuschlag.

Aufgabe 5: Komponententest

Abgabetermin: 24. Juni

Höchstpunktzahl: 5P

Testen Sie Ihre Komponente, und liefern Sie eine eventuell überarbeitete Komponente ab.

Falls beim Test die Mico-Komponenten einzufrieren scheinen, so liegt das u.U. an der Größe der Thread-Pools. Diese Probleme kann man vermeiden, wenn man in .micorc -ORBThreadPerRequest einfügt.

Aufgabe 6: Wahlaufgabe

Abgabetermin: 8. Juli

Höchstpunktzahl: 10P

Lösen Sie eine der folgenden Teilaufgaben:

Finden Sie 10 Inkompatibilitäten in MICOs Implementierung des CORBA-Komponentenmodells. Führen Sie dabei unter Angabe der Kapitel/Abschnittsnummer des CORBA3/CCM-Standards an, ob es sich um ein nicht realisiertes oder ein falsch realisiertes Feature handelt; in letzterem Fall auch, worin der Fehler besteht.

Implementieren Sie mittels .NET oder Rotor Klienten und Server für folgende Schnittstelle:

	namespace ReverseAPI
	{
	    public interface Reverser
	    {
	        string reverse(string arg);
	    }
	}