corba

Client/Server-Systeme
Prof. Dr.-Ing. Wilhelm Spruth
SS 2004
Teil 14
CORBA
cs 1000 ww6
wgs 05-97
Wiederverwendbarkeit von Code
Vorbild: Entwurf/Bau einer Brücke im Bauingenieurwesen
Objekttechnologie ermöglicht Code Blöcke mit fest definierter Funktionalität,
die in Klassen gekapselt werden. Ein Objekt als Instanz einer Klasse stellt sich
dem Entwickler als Black Box mit einer öffentlichen Schnittstelle dar.
Wird nur in einer einzigen Sprache mit identischem Compiler entwickelt ist die
Wiederverwendbarkeit von Klassen am leichtesten erreichbar. Beim Einsatz
mehrerer Programmiersprachen muß die Objektphilosophie der
Programmiersprache beachtet werden. Z.B. unterstützt C++ die
Mehrfachvererbung, Java aber nur die Einfach-vererbung.
Um objektorientierte Bibliotheken mit unterschiedlichen Sprachen und
Compilern zu realisieren, ergeben sich eine Reihe von Problemenbereichen:
• Sprachunabhängigkeit: Smalltalk- und C++-Objekte verstehen einander nicht
• Compilerunabhängigkeit: Objekte zweier Compiler (z.B. Watcom und GNU
C++) können nicht miteinander kommunizieren, weil die Verwaltung interner
Informationen nicht standardisiert ist
• starre Kopplung zwischen Objekten: Wenn sich die Implementierung einer
Klasse ändert, müssen alle Teile, die diese Klasse in irgendeiner Form
nutzen, neu kompiliert werden. Beispiel: C++ Compiler benutzen Konstanten
beim Zugriff auf Daten und Methoden
• Beschränkung auf einen Prozeßraum (Objekte können nicht über
Prozeßgrenzen hinweg kommunizieren)
Zielsetzung: Unterschiedliche objektorientierte Klienten-Implementierungen,
die auf unterschiedlichen Plattformen (z.B. HP-UX, AIX, Solaris, Linux, NT,
OS/400, OS/390) laufen, sollen mit unterschiedlichen objektorientierten ServerImplementierungen (ebenfalls unterschiedliche Plattformen) in Binärform
kompatibel zusammen arbeiten.
Klienten sollen maximal portierbar sein, und ohne -Änderungen auf
Rechnern/Betriebssystemen unterschiedlicher Hersteller lauffähig sein.
Klienten sollen keine Kenntnis benötigen wie ein Objekt auf einem Server
implementiert ist
cs 1107 ww6
wgs 06-98
Anforderung (Request)
Client 1
Objekt 1
Client 2
Objekt 2
Client 3
Objekt 3
Client 4
Objekte
bieten Operationen an, durch deren Aufruf
sie zu bestimmten Aktionen veranlaßt
werden können
Klient
Eine Software-Einheit, die eine Operation
eines Objektes aufruft
css1114 ww6
wgs 06-97
NT
GNU C++
Object
COBOL
Apple
Java
HP-UX
HP C++
SUN
Symatec
AIX
Smalltalk
NT
GNU C++
Object
COBOL
Apple
Java
HP-UX
HP C++
SUN
Symatec
AIX
Smalltalk
ORB
In unterschiedlichen Programmiersprachen entwickelte
binäre Objekte können plattformunabhängig miteinander
kommunizieren.
cs 1032 ww6
wgs 03-00
Object Request Broker
ORB
Ein ORB (Object Request Broker) ist eine Komponente eines
Betriebssystems. Er ermöglicht es, daß Objekte, die in
unterschiedlichen Programmiersprachen entwickelt wurden, in
binärer Form miteinander zusammenarbeiten. Dies kann über
Prozeß- und physische Rechnergrenzen hinweg geschehen.
Hierfür stellt der ORB ein einheitliches Klassenmodell sowie
Standards für die Organisation von Klassen-bibliotheken und die
Kommunikation zwischen Objekten zur Verfügung.
Es existieren mehrere Alternativen einen ORB zu implementieren:
• CORBA
Standard der OMG
• Remote Method Invocation (RMI),
Teil des JDK 1.1 der Fa. SUN
• COM+ / DCOM / Activex / SNA / DotNet
der Fa. Microsoft
In eine ähnliche Richtung geht die Internet orientierte
SOAP / UDDI / WSDL Initiative.
cs1104 ww6
wgs 05-97
DCOM - CORBA Integration
Das Gegenstück zum CORBA ORB ist der Microsoft DCOM ORB. Er
ist CORBA-inkompatibel.
Ziel: Vermittlung von Methodenaufrufen zwischen binären Objekten
Brücke
DCOM
Corba
DCOM - Corba Brücke
z.B. Visigenic VisiBridge
ORB
DCOM
CORBA
Schnittstelle
CIOP
Corba
IIOP
DCE RPC
Transport
css1145 ww6
beliebig
TCP/IP
wgs 06-97
CORBA
Common Object Broker Architecture
Standard der OMG (Open Management Group)
cs 1112 ww6
wgs 06-98
Begriffe
Object Management Group (OMG)
1989 gegründeter, internationaler, nicht profit-orientierter
Zusammenschluß von zunächst 8 (Anfang 1996: Ca. 600)
Softwareentwicklern, Netzbetreibern, Hardwareproduzenten
und kommerziellen Anwendern von Computersystemen (ohne
Microsoft).
Object Management Architecture (OMA)
Von OMG spezifizierte Architektur, die das Zusammenwirken
von Anwendungen verschiedener Hersteller unabhängig von
Betriebssystem, Programmiersprache und Hardware
ermöglichen soll.
Common ORB Architecture (CORBA)
Universelles Kommunikationsmedium für beliebig geartete
Objekte in verteilten heterogenen Systemen, Kernstück der
OMA, 1991 von OMG in Version 1.1 spezifiziert, aktuelle
Version 3.0 (Sommer 1999).
Literatur
R. Orfali, D. Harkey: „Client/Server Programming with Java and
Corba“. John Wiley, 2nd edition, 1998.
cs 1160 ww6
wgs 06-01
CORBA Implementierungen
Verfügbare ORB’s:
DEC
IBM
IONA
HP
SunSoft
Inprise
andere
ObjectBroker
Component Broker
Orbix
ORB Plus
Solaris NEO
Visigenic Object Broker
Unterstützte Sprachen:
C++
Smalltalk
COBOL
Java
ADA
Implementierungsbeispiele und Download Code sind zu
finden unter:
http://www.wifo.uni-mannheim.de/iiop
http://www.cs.wustl.edu/~schmidt/corba.html
cs 1113 ww6
wgs 06-97
Client
Server
Sockets oder
RPC
Sockets oder
RPC
Transport, z.B. TCP
Mit Prozeduren arbeitendes
Client/Server-System
Client
Server
CORBA Schnittstelle
CORBA Schnittstelle
ORB
Sockets oder
RPC
Sockets oder
RPC
Beispiele:
IIOP,
CIOP
Transport, z.B. TCP
Objektorientiertes Client/Server-System
css1117 ww6
wgs 05-97
Klient
Objekt
Klient
Objekt
Stub
Skel
Stub
Skel
ORB Nr. 1
ORB Nr. 2
IIOP
TCP/IP
ORB stellt eine Schnittstelle zwischen Client und Server dar, die
ähnlich der Socket- oder RPC-Schnittstelle arbeitet, aber
• auf einer höheren Ebene arbeitet (und deshalb evtl. Sockets
oder RPC für die eigentliche Kommunikation verwendet)
• objektorientiert arbeitet
• für die Kommunikation das IIOP Protokoll verwendet
(andere)
Klienten und Server Objekte kommunizieren mit ihrem ORB über
Stubs und Skeletons. Sie können transparent
auf dem gleichen oder auf entfernten Rechnern arbeiten
Eine eindeutige Objekt Referenz (IOR) wird dem Objekt bei der
Entstehung zugeordnet. Der Client nimmt die Dienste eines
Objektes in Anspruch, indem er einen Methodenaufruf ausführt. Der
Methodenaufruf enthält:
•
•
•
•
IOR
Methodennamen
Parameter
Kontext (enthält Information über die Position des Aufrufers und
nimmt Fehlermeldungen entgegen)
cs 1161 ww6
wgs 06-98
Wichtige Schnittstellen des ORB zum Client
und zur Objekt-Implementation
Interface
Repository
Client
Implementation
Repository
Objekt-Implementation
IDL
Stubs
IDL
Skeletons
Object
Adapter
ORB-Kern
Standardisierte Schnittstelle (identisch für alle ORBs)
Mehrere, jeweils auf einen Objekttyp spezialisierte
Schnittstellen
Es kann mehrere Object Adapter geben
ORB-spezifische Schnittstelle
IDL Stubs
IDL Skeletons
cs 1129 ww6
Objektspezifische Schnittstellen, werden von IDLCompiler generiert
wgs 05-98
Interface Repository
Bestandteil des ORB, Run-Time verteilte Datenbank.
Enthält Schnittstellen Beschreibungen aller registrierten verteilten Objekte.
Dies schließt Beschreibungen der
Methode
Parameter
der Objekte ein.
Die Schnittstellen Beschreibungen können als Maschinen-lesbare Versionen
der in IDL definierten Schnittstellen betrachtet werden. CORBA bezeichnet dise
Beschreibungen als „Methoden Signaturen“. Beim Aufruf (Invocation) eines
Objektes ermöglicht die Signatur eine Typen Überprüfung
Interface Repositories können lokal verwaltet werden, oder als Department
oder unternehmensweite Ressourcen eingesetzt werden.
Der genaue Aufbau des Interface Repository ist ORB-spezifisch gelöst (wird
nicht von der OMG definiert).
Implementation Repository
Bestandteil des ORB.
Enthält Run-Time Informationen, die der Auffindung eines (anhand einer
Objekt-Referenz identifizierten) Objekts im Netz ermöglichen. Macht damit
Objekt-Lokationen für Clienten transparent.
Enthält Information über die Klassen, die ein Server unterstützt, die aktivierten
Objekte und deren ID´s. Speichert zusätzliche administrative Daten wie Trace
Information, Audit Trails und relevante Daten für die Sicherheit.
Kann auch mehrere Lokationen für ein und dasselbe Objekt (d.h. dieselbe
Referenz) bereitstellen: Etwa zur Lastverteilung auf mehrere Server oder als
Vorkehrung für den Ausfall eines Servers. Für den Client stellen sich dabei
sämtliche Objekt-Implementierungen als ein einziges Objekt dar.
Enthält weiterhin die Interface-Beschreibungen der vorhandenen Objekte. Wird
deshalb auch genutzt, um DII und DSI die erforderlichen Informationen
bereitzustellen.
Der genaue Aufbau des Implementation Repository ist ORB-spezifisch gelöst
(wird nicht von OMG definiert).
cs 1179 ww6
wgs 06-98
Aufbau eines Servers
Server
allgemeine
Behandlungsroutine
Dynamic
Skeleton
(DSI)
Objecte A1, A2, A3
Interface A
Objekte B1, B2
Interface B
Methode A1
Methode A2
Methode A3
Methode B1
Methode B2
Methode B3
Methode B4
private Daten
private Daten
Skeleton für
Interface A
Skeleton für
Interface B
Object
Adapter
(OA)
Request für
unbekanntes
Interface
Request für A
ORB-Kern
Request für B
CORBA unterscheidet zwischen Server und Objekt.
Server beinhaltet typischerweise mehrere Objekte.
Je 1 Skeleton für Objekte mit identischer Interface.
Zuweisung der Requests an Skeletons (bzw. DSI)
erfolgt durch ORB und Object Adapter.
css1134 ww6
wgs 06-97
Objekt
Menge von Daten, die nur über wohldefinierte Operationen
(Methoden) zugänglich sind
Objekt-Klasse (Objekt-Typ)
spezifiziert Operationen und Datenstrukturen für gleichartige Objekte
Typ
Abstrakte Spezifikation der Funktionalität
Klasse
Implementierung dieser Funktionalität
Objekt-Instanz, Objekt-Exemplar
Ausprägung eines Objektes, welches zu einer (vorher
definierten) Klasse gehört
css1103 ww6
wgs 05-97
CORBA Server
Objekt
A
Objekt
B
Objekt
C
Object
X
Objekt
Y
Prozess
Prozess
Skeleton 1
Skeleton 2
Basic Object Adapter , Portable Object Adapter
CORBA Unterscheidet zwischen Server und Objekt
Objekt implementiert Schnittstelle
Server beinhaltet typischerweise mehrfache Objekte
(shared server), z.B. alle von der gleichen Klasse
Der Server wird erstmalig aktiviert, wenn ein Request für
eines seiner Objekte eintrifft. Weitere Requests werden auf
einer „first come, first serve“ Basis abgearbeitet.
Typischerweise 1 Thread pro Objekt.
(Ein „Persistent Server“ ist ein shared Server, der die
ganze Zeit aktiv ist, z.B. für Transaktionsverarbeitung.)
cs 1133 ww6
wgs 06-97
Schnittstellen des ORB zum Client
und zur Objekt-Implementation
Interface
Repository
Implementation
Repository
Client
DII
IDL
Stubs
Objekt-Implementation
ORB
Interface
DSI
IDL
Skeletons
Object
Adapter
ORB-Kern
Standardisierte Schnittstelle (identisch für alle ORBs)
Mehrere, jeweils auf einen Objekttyp spezialisierte
Schnittstellen
Es kann mehrere Object Adapter geben
ORB-spezifische Schnittstelle
DII: Dynamic Invocation Interface
DSI: Dynamic Skeleton Interface
IDL Stubs
IDL Skeletons
cs 1130 ww6
Gehören mit Object
Adapter und ORB-Kern
zur CORBA-Plattform
Objektspezifische Schnittstellen, werden von IDLCompiler generiert
wgs 05-98
IDL (Interface Definition Language
Client
Objekt
Server
Objekt
Steckverbindung
Die Idee ist:
Über ein (binäres) Server Object ist nicht bekannt
wie es implementiert ist
in welcher Sprache es implementiert ist
Nur die Schnittstellen des Server Objektes werden veröffentlicht
Methoden
Parameter
Um die Programmiersprachenunabhängigkeit zu erreichen, wird die
Schnittstellenbeschreibung von der binären (Maschinencode)
Implementierung der Klienten- und Serveranwendung getrennt
Die Beschreibung der Schnittstelen erfolgt in einer einheitlichen
Sprache: IDL . Damit entsteht eine Programmiersprachenunabhängige Class Description. Die „Language Mappings“ der
OMG definieren die Umsetzung
Wenn der Programmierer die Schnittstellenbeschreibung des
Server Objektes kennt, kann er sie benutzen um eine
Klientenanwendung zu schreiben
Die Compilierung der IDL Schnittstellenbeschreibung erzeugt auf
der Klienten- und Serverseite ORB spezifische Skeletons und Stubs
Der Skeleton und Stub Code muß Sprachen-spezifisch sein, um mit
der Klienten - und Serveranwendung in deren Sprache zurecht zu
kommen
cs 1034a ww6
wgs 03-00
IDL Beschreibung
IDL nach
IDL nach
IDL nach
Java
Cobol
C++
Compiler
Compiler
Skeleton
Stub
Skeleton
Stub
andere
Compiler
Skeleton
Stub
Language Mappings:
• Werden für verschiedene Programmiersprachen spezifiziert.
• Legen die den IDL-Konstrukten äquivalenten Konstrukte der
jeweiligen Programmiersprache fest. Dazu gehören:
• Einfache und zusammengesetzte Datentypen, Konstanten,
Objekte,
• Operationsaufrufe incl. Parameterübergabe,
• Setzen und Abfragen von Attributen,
• Auslösen und Behandeln von Exceptions.
• Garantieren die Zugriffsmöglichkeit auf Objekte unabhängig von
der bei der Entwicklung der Client- und Server-Programme
benutzten Programmiersprache.
• Sind zum Teil von OMG standardisiert (für C, C++, COBOL, Ada,
Java und Smalltalk). Weitere Standards sind z.Z. in Arbeit (für
Fortran und PL/1).
cs 1035 ww6
wgs 03-00
IDL
Interface Definition Language
Beschreibt die Schnittstelle, welche von Client-Objekten
aufgerufen wird, und die von einer Objekt-Implementierung
zur Verfügung gestellt wird.
Angelehnt an ANSI C++:
• Preprocessing im C++ - Stil,
• Lexikalische
wörtern),
Regeln
(mit
zusätzlichen
Schlüssel-
• Syntax ist Untermenge der C++ - Syntax (Konstanten-,
Typ-, Operationsdeklarationen).
Aber auch mit Unterschieden zu C++, z.B.:
• Rückkehrtyp
werden,
von
Funktionen
muß
angegeben
• Alle formalen Parameter in Operationsdeklarationen
müssen einen Namen haben,
• ...
css1130 ww6
wgs 06-97
OMG IDL
Erstellung von Client und Objekt-Implementation
mittels IDL-Compiler
IDL-File
ORB-spezifischer
IDL-Compiler
Stub
Code
Skeleton
Code
Client
Code
Obj. Impl.
Code
Compiler, Linker
Client
Object Implementation
Stub
Skeleton
ORB
css1131 ww6
wgs 06-97
Erstellen eines CORBA Programms
1. Definition der Server Schnittstelle unter Benutzung der
Interface Definition Language (IDL)
2. Interface Definition in das Interface Repository binden
3. Idl Definition mit Hilfe des IDL Precompilers übersetzen
4. Code für die Server Implementierung schreiben
5. Server Code kompilieren
6. Run-Time Objekte mit dem Implementation Directory
registrieren
7. Zur Start-up Zeit Objekte auf dem Server instanziieren
8. Code für die Client Implementierung schreiben
9. Client Code übersetzen
10. Run
cs 1135 ww6
wgs 11-98
Klient
Server
clock1 = cpuclock
call increment ( 1000 mal )
clock2 = cpuclock
time = clock2 - clock1
sum = 0
increment (sum)
CORBA ORB
CORBA Beispiel (1)
Implementierung des Beispiels in Java (Klient und Server)
Klient und Server Code werden in einem CORBA Module (einer
Java Package) mit dem Namen „Counter“ zusammengefaßt.
Die Schnittstelle zwischen Klient und Server erhält den Namen
„Count“. Dies ist gleichzeitig die Bezeichnung der Klienten und
Server Klassen der CORBA Module Counter.
Der Name des serverseitigen Objektes ist „MyCount“ .
Orfali, Chapter 4, S. 69
cs 1140 ww6
wgs 04-99
Vorgehensweise
Es sind 4 Dateien zu erstellen:
count.idl
CountClient.java
CountImpl.java
CountServer. java
Sie konstituieren gemeinsam das Corba Module ( = Java Package)
counter
Es werden die folgenden Referenzen benutzt:
count.idl
interface
method
Count
increment
CountImpl.java
lokale Variable
sum
CountServer.java
globaler Objektname
lokale Objektbezeichnung
„MyCount“
count
CountClient.java
Count“
globaler Objektname
lokale Objektbezeichnung
„My
counter
Der IDL Compiler erzeugt aus count.idl sechs Java Programme
(Hilfsdateien, u.a. Stub und Skeleton), welche die Schnittstelle Count
verwenden. Je drei von ihnen werden von CountClient.java bzw. von
CountServer.java und CountImpl.java benutzt. Sie müssen alle
gemeinsam in Klassen übersetzt werden.
cs1175 ww6
wgs 05-01
Interoperable Object Reference
IOR
Zeichenkette, die ein Objekt innerhalb eines verteilten CORBA
Systems eindeutig kennzeichnet.
Vergleich:
Internet
CORBA
134.2.2.102
Object Reference
informatik.uni-tuebingen.de
String (Name)
CORBA ORB´s unterschiedlicher Hersteller übermitteln Object
References nach dem IOR (Interoperable Object Reference)
Standard.
Anwendungen verwenden String Namen. Es ist die Aufgabe eines
Name Servers, String Namen in Object References zu übersetzen.
cs1150 ww6
wgs 05-97
Inter Operable Reference (IOR) Format
TCP/IP
SNA
IPX
• OMG Standard
• IOR´s sind unique (eindeutig).
• IOR ethält u.A. ein Feld für jedes benutzbare Transport
Protokoll.
• Für IIOP (TCP/IP) schließt dies die Internet Adresse, eine
Portnummer und eine intern vom ORB erzeugte und
verwendete Objektidentifikation ein. Die Netzwerk
Adresse bezeichnet die zuletzt bekannte Lokation des
Objekt ORB`s.
Wurde das Objekt zwischenzeitlivh verlagert, verweist der
ursprüngliche ORB auf den neuen ORB mit einer
"location_forward" IIOP Nachricht.
cs 1030z ww6
wgs 05-97
cs 1039 ww6
wgs 05-02
Objekte
Zugriff auf die Objekte
mit Hilfe von
Objekt Referenzen
Objekte
Objekt
Instanz
Objekt
Instanz
Objekt
Implementierung
Objekt
Implementierung
Corba Client
Corba Server
Kernel
Betriebssystem Kernel
IIOP
Corba ORB
Corba ORB
Corba Begriffe
Objekt Referenz : Zeiger auf ein Objekt, das irgendwo im Netzwerk
existiert
Corba Client : Programm, das eine Objekt aufruft
Objekt Implementierung : Programm Code, der das Verhalten des
Objekts definiert
Objekt Instanz : Ausprägung eines bestimmten Objektes
Corba Server : Prozess, der eine oder mehrere Objekt
Implementierungen bereitstellt
cs 1038 ww6
wgs 03-00
OMG CORBA Namensdienst
Mechanismus, mit dem Objekte auf dem ORB andere
Objekte lokalisieren
Ein „Name-Binding“ ist eine Zuordnung Name - Objekt.
Verwendet hierarchische Struktur. Basiert auf
transparenter Kapselung existierender Namensdienste wie
LDAP, X.500, DNS oder Sun NIS.
Bildet den Namen eines Objektes auf eine eindeutige,
maschinenlesbare Objekt Referenz ab.
Es kann mit absoluten Namen oder mit Namen innerhalb
ihres Context gearbeitet werden. spruth, informatik, unituebingen und de könnten Komponenten eines CORBA
Namens sein.
Eine Komponente besteht aus 2 Attributen: identifier, kind.
Das Attribute kind kann eine Beschreibung der
Komponente enthalten, z.B. file-typ.
Einige ORB Herstelller, z.B. Inprise, Orbix, bieten zusätzlich
eigene, proprietäre Namendienste an, die Broadcasts
verwenden und nur innerhalb des gleichen IP Subnetzes
arbeiteten.
cs 1158 ww6
wgs 06-98
Name
Obj.
Reference
.....
.....
4711
.....
.....
MyCount
Corba
Namensdienst
Server
2 Anfrage
MyCount
3 Antwort
MyCount,
Referenz= 4711
1 Registrierung
„MyCount, 4711“
4711
Corba
Klient
4
invoke Methode,
Objekt Referenz
= 4711
Corba
Server
Corba Namensdienst
Corba Object Refererence : Zeiger auf ein Objekt zurLaufzeit
Die vom Programmierer verwendete Repräsentation (Namen) einer
Objekt Referenz ist nicht mit der vom ORB verwendeten
Repräsentation identisch
cs 1185 ww6
wgs 05-01
Client Process
Server Process
OSAgent
CountImpl
sum
increment
„My Count“
„My Count
counter
Proxy Object
count
Object
hat die
Methodenaufrufe
counter.sum
counter.increment
Name Service
CountServer
1. Registrierung
„My Count“, Obj. Ref.
2. Anfrage: „My Count“ ???
3. Antwort: „My Count“, Obj. Ref.
Der interne „state“ des Objektes „My Count“ wird durch 1 Variable
( int sum) dargestellt.
Counter Beispiel
cs1173x ww6
wgs o6-99
IDL (Interface Definition Language
Client
Objekt
Server
Objekt
Steckverbindung
Die Idee ist:
Über ein Server Object ist nicht bekannt
wie es implementiert ist
in welcher Sprache es implementiert ist
interface „Count“
Nur die Schnittstellen des Server Objektes werden veröffentlicht
Methoden “increment()“
Parameter “sum“
Um die Programmiersprachenunabhängigkeit zu erreichen, wird die
Schnittstellenbeschreibung von der binären (Maschinencode)
Implementierung der Klienten- und Serveranwendung getrennt
Die Beschreibung der Schnittstelen erfolgt in einer einheitlichen
Sprache: IDL . Damit entsteht eine Programmiersprachenunabhängige Class Description. Die „Language Mappings“ der
OMG definieren die Umsetzung
Wenn der Programmierer die Schnittstellenbeschreibung des
Server Objektes kennt, kann er sie benutzen um eine
Klientenanwendung zu schreiben
Die Compilierung der IDL Schnittstellenbeschreibung erzeugt auf
der Klienten- und Serverseite ORB spezifische Skeletons und Stubs
Der Skeleton und Stub Code muß Sprachen-spezifisch sein, um mit
der Klienten - und Serveranwendung in deren Sprache zurecht zu
kommen
cs 1037 ww6
wgs 03-00
// Count.idl
module Counter
{
interface Count
{ attribute long sum;
long increment();
};
};
IDL Schnittstellen Definition der Count Schnittstelle
Der IDL Precompiler erzeugt aus der Schnittstellen Definition Java
Programme für
Client Stub
Server Skeleton,
weitere Hilfsprogramme
und lädt die Schnittstelllen Beschreibung in das Interface
Repository.
cs 1142 ww6
wgs 03-99
mögliche
Instanzen von
CountImpl
CountServer
His Count
Your Count
My Count
Count Server Implementierung
Die Server Seite von Count besteht aus 2 Programmen.
CountServer initialisiert ORB, BOA und erzeugt die Count Objekte
(die Instanzen der Klasse Count).
Im vorliegenden Beispiel ist dies nur 1 Objekt mit der Bezeichnung
„My Count“. In der Regel werden mehrere Instanzen erstellt.
CountImpl enthält den Code für das Server Objekt, welches vom
Klienten aufgerufen wird.
cs 1146
wgs 03-99
// CountImpl.java: The Count Implementation
class CountImpl extends Counter._CountImplBase
// „extends“ establishes inheritance from Counter._CountImplBase
{
private int sum;
// Constructor, calls ist super, the CORBA skeleton class
CountImpl(String name)
{ super(name);
System.out.println("Count Object Created");
sum = 0;
}
// get sum
public int sum()
{ return sum;
}
// set sum
public void sum(int val)
{ sum = val;
}
// increment method
public int increment()
{ sum++;
return sum;
}
}
CountImpl
Count Server Implementierung
cs 1143 ww6
wgs 03-99
// CountServer.java: The Count Server main program
class CountServer
{ static public void main(String[] args)
{ try
{ // Initialize the ORB
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,
null);
// Initialize the BOA
org.omg.CORBA.BOA boa = orb.BOA_init();
// Create the Count object
CountImpl count = new CountImpl("My Count");
// Export to the ORB the newly created object
boa.obj_is_ready(count);
// Ready to service requests
boa.impl_is_ready();
}
catch(org.omg.CORBA.SystemException e)
{ System.err.println(e);
}
}
}
CountServer
Count Main Server Programm
Initialisierung des ORB, BOA und des Count Objektes.
Die beiden Befehle CountImpl ... und boa.obj .... erstellen und
exportieren eine einzige Objekt Instanz („count“, „My Count“).
cs 1145
wgs 03-99
// CountClient.java Static Client, VisiBroker for Java
class CountClient
{ public static void main(String args [ ] )
{ try
{ // Initialize the ORB
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,
null);
// Bind to the Count Object
Counter.Count counter = Counter.CountHelper.bind(orb, "My
Count");
// Set sum to initial value of 0
counter.sum((int)0);
// Calculate Start time
long startTime = System.currentTimeMillis( );
// Increment 1000 times
for (int i = 0 ; i < 1000 ; i++ )
{ counter.increment();
}
// Calculate stop time
long stopTime = System.currentTimeMillis( );
//print statistics
System.out.println("Avg Ping = "
+ ((stopTime - startTime)/1000f) + " msecs");
System.out.println("Sum = " + counter.sum( ));
}
// handle exceptions
catch(org.omg.CORBA.SystemException e)
{ System.err.println("System Exception");
System.err.println(e);
}
}
}
Count Client Programm
cs 1144 ww6
wgs 03-99
Schritte zur Programmausführung
1.
2.
Erstellung der Dateien
Count.idl
CountClient.java
CountServer.java
CountImpl.java
idl2java
Count.Idl
Programmieren der
CORBA Anwendung
Aufruf des IDL Compilers
Es werden die
Schnittstellen
Beschreibungen in Java
erzeugt
3.
javac
javac
javac
CountClient.java
CountServer.java
CountImpl.java
compiliert die *.java
Programme, erzeugt
*.class Programme
4.
start
osagent
startet den Name Server
5.
start java CountServer
6.
java
Programm
CountClient
startet den Server
ruft das Klienten
auf.
cs 1147
wgs 03-99
cs 1182 ww6
wgs 06-98
<h1>Count Client Applet</h1>
<hr>
<center>
<APPLET CODE=CountClientApplet.class WIDTH=300 HEIGHT=60
CODEBASE=classes>
<param name=org.omg.CORBA.ORBClass
value=com.visigenic.vbroker.orb.ORB>
</APPLET>
</center>
<hr>
HTML Code für den Count Client Applet Aufruf
cs 1155 ww6
orfali p.88 03-99
Common Object Services (COS)
Common Object Services sind modulare zusätzliche
CORBA System-Dienstleistungen, welche die Funktionalität
des ORB ergänzen. Sie stellen Bausteine für die
Anwendungsentwicklung dar. Es existieren
Spezifikationen der OMG für:
• Naming Service
• Persistence Service
Speicherung von Objekten in relationalen oder
Objekt Datenbanken oder einfachen Dateien
• Concurrency
Lock Manager Dienste für Transaktionen oder
Threads
• Transaction Service
Two-Phase Commit Koordination für flache oder
nested Transactions
sowie weitere Dienste wie Security, Message, Time, Event,
Trader, ....
cs 1135 ww6
wgs 06-97
Persistenz
Persistente Objekte existieren permanent außerhalb des
Gültigkeitsbereichs des Programms, das sie erzeugt hat.
Persistenz wird implementiert, indem der Status (die Attribute)
eines Objekts zwischen den einzelnen Programmausführungen
gespeichert wird. Wenn das Objekt erneut benötigt wird, wird es
aus seiner gespeicherten Form wieder hergestellt. Der
Herstellungsprozeß erzeugt ein neues Objekt, das mit dem
ursprünglichen identisch ist. Das wiederhergestellte Objekt ist zwar
nicht das selbe Objekt, aber sein Status und sein Verhalten sind
identisch.
Das Objektmodell macht zunächst keine Annahmen über die
permanente Speicherung der Objekte. Konzeptuell können Objekte
in einer Objektdatenbank (z.B. POET) gespeichert werden.
In der Praxis werden SQL (oder IMS oder VSAM) Daten als Objekte
gekapselt; der Zugriff erfolgt z.B. über eine JDBC (Java Data Base
Connectivity) Schnittstelle.
Bei der Persistenz werden den gespeicherten Daten alle
Objektattribute (etwa Klassenname, Feldname und ZugriffsModifier) zugeordnet, so daß verhindert wird, daß die Daten
versehentlich mit einem falschen Objekttyp abgelegt werden.
cs1171 ww6
wgs 11-98