Common Object Request Broker anhand eines Beispiels

1
Common Object Request Brokeranhand 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.

2
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

3
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

4
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)

5
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.

6

• 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

7

• 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.

8

• 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

9
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
10
unsigne short short
long int
unisigned long int
long long long
unsigned long long long
float float
double double
fixed java.Math.BigDecimal
11
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
12
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.

13
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.

14
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)

15
Diese Referenz wird als Interoperable Object
Reference IOR bezeichnet. Danach wartet der
Server auf Anforderungen.
16
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)

17
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.
18
CORBAUtil.java

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

19
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.

20
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.