Common Object Request Broker anhand eines Beispiels

Common Object Request Broker
anhand eines Beispiels
• Aufgabestellung (www.hanser.de):
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 IDLCompiler 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 IDLCompiler übersetzt.
• Es werden Schnittstellen sowohl für die ServerSeite 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{
OMG-IDL-Syntax
• Eine IDL-Datei kann Module enthalten. Für
jede module-Definition wird ein JavaPackage 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
boolean
char
wchar
octet
string
wstring
short
JAVA
boolean
char
char
byte
java.lang.String
java.lang.String
short
unsigne
short
long
unisigned
long
long long
unsigned
long long
float
short
double
fixed
double
java.Math.BigDecimal
int
int
long
long
float
Für die unterschiedlichen Datentypen gibt es
vordefinierte Holder-Klassen
short
long
long long
octet
float
double
char,wchar
boolean
Fixed
org.omg.CORBA.ShortHolder
org.omg.CORBA.IntHolder
org.omg.CORBA.LongHolder
org.omg.CORBA.ByteHolder
org.omg.CORBA.FloatHolder
org.omg.CORBA.DoubleHolder
org.omg.CORBA.CharHolder
org.omg.CORBA.BooleanHolder
Java.math.BigDecimal
Prinzipielles Vorgehen
• Aus dem Vertrag zwischen Client und
Server (Bank1.idl)generiert der IDLCompiler 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 OMGStandard 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.