Common Object Request Brokeranhand eines Beispiels

• Aufgabestellung (www.hanser.de):Ein Konto wird von einem Server verwaltet. Der Stand desKontos wird nur solange gespeichert, wie ein Server läuft.Dabei ergibt sich bei jeder Aktivierung des Servers dergleiche Kontostand, nämlich der Anfangszustand. Es gibt nureine Methode, zum Einzahlen von Beiträgen. Diese Methodeakzeptiert jeden Betrag, also auch negative Einzahlungen,ohne Widerspruch. Sie gibt als Ergebnis den neuenKontostand nach dem Einzahlen des angegebenen Betragszurück. Die Clients nehmen Verbindung zum Server auf undzahlen 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.idlmodule 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 boolean

char char

wchar char

octet byte

string java.lang.String

wstring java.lang.String

short short

unsigne

short

short

long int

unisigned long

int

long long long

unsigned long long

long

float float

double double

fixed java.Math.BigDecimal

Für die unterschiedlichen Datentypen gibt es vordefinierte Holder-Klassen

short org.omg.CORBA.ShortHolder

long org.omg.CORBA.IntHolder

long long org.omg.CORBA.LongHolder

octet org.omg.CORBA.ByteHolder

float org.omg.CORBA.FloatHolder

double org.omg.CORBA.DoubleHolder

char,wchar org.omg.CORBA.CharHolder

boolean org.omg.CORBA.BooleanHolder

Fixed Java.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.

SERVANTIKonto1Impl.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 ServerServerSun.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 JavaClient.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.