Common Object Request Broker anhand eines Beispiels Aufgabestellung ( Ein Konto wird von einem Server verwaltet. Der Stand des Kontos wird nur solange gespeichert, wie ein Server läuft. Dabei ergibt sich bei jeder Aktivierung des Servers der gleiche Kontostand, nämlich der Anfangszustand. Es gibt nur eine Methode, zum Einzahlen von Beiträgen. Diese Methode akzeptiert jeden Betrag, also auch negative Einzahlungen, ohne Widerspruch. Sie gibt als Ergebnis den neuen Kontostand nach dem Einzahlen des angegebenen Betrags zurück. Die Clients nehmen Verbindung zum Server auf und zahlen einen oder mehrere Beiträge ein.

Lösung in CORBA Anwender des Java des JDK 1.3 brauchen keine zusätzliche Hilfsmittel Für JDK-1.2 wird zusätzlich der IDL- Compiler benötigt

Der Vertrag in IDL In CORBA werden Verträge zwischen Client und Server in der OMG-IDL-Sprache zur Definition von Schnittstellen formuliert Aus der IDL-Definition werden mit einem IDL-Compiler die Schnittstellen für Client und Server generiert

Bank1.idl Die Spezifikation der Schnittstelle wird in einer IDL-Datei abgelegt. Diese wird mit einem IDL- Compiler übersetzt. Es werden Schnittstellen sowohl für die Server- Seite als auch auf der Client-Seite generiert. Die Anbindung auf der Client-Seite wird als (Client-) Stub, die auf der Server-Seite als (Server-)Skeleton realisiert. Bank1.idl module Bank1 { Interface IKonto{ double einzahlen (in double betrag); };

OMG-IDL-Syntax Eine IDL-Datei kann Module enthalten. Für jede module-Definition wird ein Java- Package generiert. Geschachtelte Module sind erlaubt. Sie liefern in Java ineinander enthaltene Packages. Schnittstellen können ineinander von Modulen definiert werden.

Für jede interface-Definition (z.B. interface Ikonto...) Werden im entsprechenden Package die angegebenen Klassen erzeugt. Dazu gehören auch die Helper- und HolderKlassen: IKontoHelper, IKontoHolder Die Helper-Klasse hat Hilfsfunktionen, z. B. die narrow()-Methode zum Einengen der allgemeinen CORBA-Objectreferenz org.omg.CORBA.Object auf ein vom Anwender definiertes Objekt

Die Holder-Klasse wird für die Übergabe von Parametern mit Rückgabe-Semantik (inout bzw. out) verwendet, und bietet Methoden für die Behandlung von Ein- und Ausgabe-Streams.

CORBA kennt Programmausnahmen auf System- (SYSTEM) und auf Anwenderebene (User) Die CORBA-APIs im CORBA Modul sind auch über IDL definiert (Pseudo IDL (PIDL)). Die Funktionalität ist aber nicht über Dienste realisiert, sondern als Aufrufe an die jeweiligen ORBs. Kommentare beginnen mit /*und enden mit*/ oder beginnen mit // und enden mit dem zugehörigen Zeilenende

Einfache und Zusammengesetzte Datentypen in CORBA CORBA JAVA boolean char wcharchar octetbyte stringjava.lang.String wstringjava.lang.String short

unsigne short longint unisigned long int long unsigned long long long float double fixedjava.Math.BigDecimal

Für die unterschiedlichen Datentypen gibt es vordefinierte Holder-Klassen shortorg.omg.CORBA.ShortHolder longorg.omg.CORBA.IntHolder long org.omg.CORBA.LongHolder octetorg.omg.CORBA.ByteHolder floatorg.omg.CORBA.FloatHolder doubleorg.omg.CORBA.DoubleHolder char,wcharorg.omg.CORBA.CharHolder booleanorg.omg.CORBA.BooleanHolder FixedJava.math.BigDecimal

Prinzipielles Vorgehen Aus dem Vertrag zwischen Client und Server (Bank1.idl)generiert der IDL- Compiler die Schnittstelle Konto1.java im Package Bank1. Sie ist von der Wurzel aller CORBA-Instanzen in Java, der Schnittstelle org.omg.CORBA.Object, abgeleitet.

SERVANT IKonto1Impl.java Das ist der Programmcode, der die Implementierung übernimmt. Er muss im Endeffekt die in der Schnittstelle vereinbarte Funktionalität implementieren. Nach dem OMG- Standard sind aber noch weitere Methoden wie type_ids zu implementieren. Diese Methode wird vom IDL-Compiler in die Datei Bank1/_IKontoImplBase.java generiert, sodass man die Implementierung der Schnittstelle im Endeffekt von der Klasse Bank1/_IKonto1ImplBase abzuleiten hat.

Der Server ServerSun.java Der Server muß eine Intanz des Servants ablegen: IKonto1Impl konto = new IKontoImpl (); Daneben muß diese Implementierung publiziert werden. Dies geschieht hier dadurch, dass die Referenz auf das Objekt mit dem Aufruf an einen Object Request Broker (orb.object_to_string(…)) in Text umgewandelt und in einer Datei abgelegt wird. CORBAUtil.writeIOR (orb, konto, IKonto1);

Diese Referenz wird als Interoperable Object Reference IOR bezeichnet. Danach wartet der Server auf Anforderungen.

Ein Client in Java Client.java Der Client kann die sog. IOR lesen und sich mit dem Aufruf orb.string_to_object (…) eine Referenz auf ein allgemeines CORBA-Object verschaffen. Diese allgemeine Schnittstelle kann mit einem Aufruf an eines der vom IDL-Compiler generierten Programme in eine spezielle Schnittstelle eingeengt werden: konto= IKonto1Helper.narrow(allgemeines CORBA-Objekt);

Die Methoden der Schnittstelle IKonto1 können also im Client wie übliche Java-Methoden aufgerufen werden. Der ORB sorgt in Zusammenarbeit mit dem lokalen Stub, dem entfernten Skeleton sowie mit Servant (die eigentliche Implementierung) und Server für den Ablauf.

CORBAUtil.java Diese Datei enthält Routinen, die die Umwandlung von und nach Text beinhalten.

Abläufe Die Programme werden übersetzt: Erstmal wird Bank1.idl vom IDL-Compiler übersetzt: idlj Bank1.idl Danach werden die Client- und die ServerSun-Dateien compiliert.

Weitere Abläufe Client und Server laufen als eigene Prozesse. Der Server schreibt dann eine IOR-Datei in das aktuelle Verzeichnis. Danach kann der Client mit dem Aufruf java Client gestartet werden. Das aktuelle Verzeichnis des Clients muss die IOR enthalten.