9.4 CORBA

9.4 CORBA
= Common Object Request Broker Architecture
http://www.corba.org
Standard (nicht Produkt!) der OMG – Object Management Group
Architektur:
objektorientiert/Fernaufrufe + Komponenten
IDL:
C++ -ähnlich
Dienste:
sehr reichhaltig
Anwendungen:
Dienste,
insbesondere Einbinden von Altsoftware
vs9.4
1
9.4.1 Objektmodell: Schnittstellen und Objekte
Schnittstelle:
Menge von Operations-Signaturen, beschrieben mit CORBA IDL
Objekt:
 irgendwie erzeugtes Exemplar
irgendeiner Implementierung in
irgendeiner Programmiersprache (nicht notwendig objektorientiert)
mit einer bestimmten Schnittstelle = Objekttyp,
 identifiziert durch CORBA-Objektverweis (= Fernverweis, s.u.),
 fernaufrufbar über diesen Verweis
vs9.4
2
Vererbung/Erweiterung von Schnittstellen ist möglich
! Nicht Teil des Objektmodells sind
 Implementierung, „Klassen“
 Objekterzeugung
Beachte:
Das CORBA-Objektmodell ist prinzipiell unabhängig von den
Objektmodellen der verwendeten Programmiersprachen –
sofern diese überhaupt objektorientiert sind
 beschränkte Verteilungsabstraktion !
vs9.4
3
9.4.2 Schnittstellenbeschreibung mit IDL
 Entfernte Ähnlichkeit mit C++
 Typsystem mit einfachen und zusammengesetzten Typen
 Module bilden Namensräume, auch mit Schachtelung
 Ein Modul (module) kann enthalten:
 Konstantendefinitionen
 Typdefinitionen
 Vereinbarungen von Ausnahmen (exceptions)
 Vereinbarungen von Schnittstellen (interfaces)
vs9.4
4
Typsystem:
Typ
Basistyp
(basic type)
einfach
zusammengesetzt
long
struct{fields}
char
[size]
string
...
sequence<type>
...
Verweistyp
(reference type)
Objekttyp
Object
Werttyp
valuetype
mit Vererbung
(auch Mehrfachvererbung)
vs9.4
5
Konstantendefinitionen (const)
 benennen explizit angegebene Werte,
 sind Bestandteile eines Moduls oder einer Schnittstelle
Typdefinitionen (typedef)
 benennen explizit angegebene Typen,
Ausnahmen (exception)
 werden wie Verbundtypen vereinbart
Schnittstellen (interface) enhalten
 Konstanten,
 Operationen,
 Attribute
vs9.4
6
Operationen in Schnittstellen
 können Wert liefern (oder auch nicht: void),
 können Ausnahmen melden (raises),
 kennen 3 Parametermechanismen:
in
Wertparameter
out
Ergebnisparameter
inout Wert/Ergebnisparameter
(bei Objekttypen wird Objektverweis übergeben,
bei valuetype wird Objektkopie übergeben!)
 können als asynchron vereinbart werden (oneway),
sofern ohne Ergebnis und Ausnahmen.
vs9.4
7
Semantik des Operationsaufrufs:
 synchrone bzw. asynchrone Ausführung, at-most-once
 Ausnahmen wie spezifiziert, zzgl. CORBA-Ausnahmen
Attribute in Schnittstellen (attribute)
 können als schreibgeschützt (readonly) vereinbart werden,
 sind äquivalent zu getter/setter-Operationen
(bzw. nur getter, wenn schreibgeschützt)
vs9.4
8
// file example.idl
module example { // no nesting used, only one module
typedef
string Name;
exception NameClash {Name clashing;};
exception Overflow
{unsigned long capacity;};
interface Phones { // private phone book
long lookup(in Name s);
void enter (in Name s, in
long n)
raises(NameClash, Overflow);
void delete(in Name s);
readonly attribute long capacity;
};
};
vs9.4
9
Vordefiniert ist
module CORBA {
interface ORB {
.... // Schnittstelle eines Pseudoobjekts mit
};
// objektunabhängigen Standardoperationen
interface Object {
.... // Standardoperationen für Objekte
};
.......
};
Qualifizierte Namen: z.B. example::Phones, CORBA::ORB
Jede Schnittstelle erbt implizit von
CORBA::Object,
d.h. jeder Objekttyp ist verträglich mit CORBA::Object
vs9.4
10
9.4.3 Umgang mit Verweisen
ist unabhängig von Programmiersprachen und deren Verweisen !
interface Object { // Operationen auf Verweisen
Object
duplicate();
// liefert Kopie des Objektverweises
boolean is_equivalent(in Object other);
// bezeichnet other dasselbe Objekt?
boolean is_nil();
// bezeichnet der Verweis ein gültiges Objekt?
...
};
Alle diese Operationen werden lokal ausgeführt.
vs9.4
11
Umwandlung von Verweisen in Zeichenketten (und zurück):
interface ORB {
string object_to_string(in Object o);
Object string_to_object(in string s);
...
};
Diese Zeichenketten – stringified object references dienen lediglich als externe Repräsentation für Objektverweise.
Sie sehen kryptisch aus, und man kann aus ihnen die identifizierenden Informationen für das Objekt nicht direkt ablesen.
vs9.4
12
9.4.4 CORBA-Infrastruktur
ORB (Object Request Broker):
eigentliche Middleware: verteilte Laufzeitunterstützung zwischen
Betriebssystem einerseits und Anwendungscode und Vertretercode
andererseits, zuständig für Fernaufrufe und lokale Basisdienste
(ORB, Object)
IOR (interoperable object reference):
Objektverweis in standardisiertem Format
POA (portable object adapter)
Verwalter der lokal vorhandenen, fernaufrufbaren Objekte
Servant (≈ Treiber + Implementierung)
Implementierung eines fernaufrufbaren Objekts (z.B. ein Java-Objekt)
vs9.4
13
Interface Repository:
verwaltet IDL-Schnittstellenbeschreibungen
Implementation Repository:
verwaltet zugehörige Implementierungen
CORBA Services:
breite Palette von Standarddiensten wie z.B.
Naming Service, Notification Service, Transaction Service, ...
CORBA Facilities:
weitere Spezifikationen, z.B.
Data Interchange, Systems Management, …
vs9.4
14
9.4.5 Sprachanbindung
(language mapping)
definiert die Beziehungen zwischen dem CORBA-Objektmodell
und Syntax und Semantik einer bestimmten Programmiersprache
 setzt die Typsysteme zueinander in Beziehung,
 regelt die Nachbildung nicht verfügbarer Parametermechanismen,
 stellt Bibliotheksroutinen für die CORBA-Standarddienste
zur Verfügung (ORB, Object),
 stellt einen Vertreter-Generator – IDL Compiler – zur Verfügung;
der Vertreter heißt stub, der Treiber heißt skeleton.
vs9.4
15
Vertreter-Erzeugung am Beispiel Java:
> idl2java example.idl
erzeugt für jedes Modul ein Java Package,
hier also ein einziges Package example.
Das Package umfasst die folgenden Dateien:
PhonesOperations.java Schnittstelle entsprechend Phones
Phones.java
Schnittstelle, die PhonesOperations und
org.omg.CORBA.Object zusammenfaßt
PhonesStub.java
Vertreter-Klasse PhonesStub
PhonesHelper.java Hilfsklasse PhonesHelper (s.u.)
PhonesPOA.java
Treiber-Klasse PhonesPOA (für Vererbung)
PhonesPOATie.java Treiber-Klasse
PhonesPOATie
vs9.4
16
Automatische Erzeugung von IDL-Text .idl
für bereits vorliegenden Server-Code ist möglich,
wenn sich daraus eine Schnittstelle ableiten läßt,
z.B. für eine Java-Klasse
import java.rmi.*;
public class PhonesImpl implements Remote {...}
(nach Übersetzung) wie folgt:
> rmic –idl PhonesImpl
(SUN) oder
> java2idl PhonesImpl
(VisiBroker u.a.)
vs9.4
17
9.4.6 Programmierbeispiel in Java
Schnittstelle ist example.idl (9.4.2 )
Anbieter besteht aus eigentlichem Objekt – genannt Servant –
und dem Server-Prozess, der als Träger des Objekts fungiert:
// servant class
import org.omg.CORBA.*;
public class PhonesImpl extends PhonesPOA {
// skeleton as superclass !
...
public int lookup(String n) {...}
...
}
Beachte: Klassenname irrelevant, kein interface erforderlich
– aber Schnittstelle muss zu example.Phones passen!
vs9.4
18
// server main program
import org.omg.CORBA.*; // has class for CORBA::ORB (& others)
import org.omg.PortableServer.*;
// has interface for PortableServer::POA (& others)
public class Server {
public static void main(String[] arg) {
PhonesImpl ph = new PhonesImpl(); // Java object
.....
ORB orb = ORB.init();
// initialize ORB
POA poa = ...
//
and POA
.....
org.omg.CORBA.Object obj =
// CORBA object!
poa.servant_to_reference(ph);
.....
// e.g., publish obj via Naming Service
orb.run();
// wait for invocations
}
}
... zuzüglich Ausnahmebehandlung
vs9.4
19
Klient:
import org.omg.CORBA.*;
.....
ORB orb = ORB.init();
// initialize ORB
org.omg.CORBA.Object obj = ...
// get CORBA object, e.g.,
// through Naming Service
Phones p = PhonesHelper.narrow(obj);// get Java object
if(p == null) ...
// type error
int number = p.lookup("Robert");
.....
// remote invocation
... zuzüglich Ausnahmebehandlung
vs9.4
20
9.4.7 Portable Object Adapter (POA)
erlaubt Vielzahl unterschiedlicher Strategien zur Gestaltung
der Beziehungen zwischen CORBA-Objekt, Servant und Server
 Lebensdauer eines CORBA-Objekts und des implementierenden
Servants sind unabhängig.
 POA unterstützt persistente Objekte, deren Lebensdauer die des POA
(d.h. des Server-Prozesss) übertrifft.
 Objekt wird aktiviert (incarnated) durch Verbindung mit einem Servant,
und wird deaktiviert (etherealized) durch Lösen dieser Verbindung.
 POA verwaltet seine Objekte in Objekttabelle (active object map),
in der die jeweils zugehörigen Servants verzeichnet sind;
für deaktivierte Objekte übernimmt ein Default Servant die
Aufrufbehandlung.
vs9.4
21
Ferner:
- Strategien sind programmgesteuert wählbar
- Standard-Strategie: transiente Objekte
- Persistenz wird unterstützt durch Implementation Repository
und ORB Daemon, der bei Bedarf Server-Prozess startet
- Weitere POA-Exemplare – z.B. mit unterschiedlichen
Strategien – können programmgesteuert erzeugt werden
- usw. usf.
vs9.4
22
9.4.8 Naming Service
= Namensdienst mit hierarchisch strukturiertem Namensraum
Context enthält
- reguläre Einträge,
- subcontexts
module CosNaming { // Cos = CORBA Service
...
typedef sequence<NameComponent> Name;
};
interface NamingContext {
void rebind(in Name n, in Object o);
void rebind_context(in Name n,
in NamingContext c);
Object resolve(in Name n);
...
};
… zuzüglich Ausnahmen
vs9.4
23
Benutzung in Java-Client:
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
.....
org.omg.CORBA.Object obj =
orb.resolve_initial_references("NameService");
NamingContextExt root =
NamingContextExtHelper.narrow(obj);
id[.kind]
Name name = root.to_name("mycontext/myserver.ext");
org.omg.CORBA.Object x = root.resolve(name);
.....
vs9.4
24
Benutzung in Java-Server:
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
.....
org.omg.CORBA.Object obj =
orb.resolve_initial_references("NameService");
NamingContextExt root =
NamingContextExtHelper.narrow(obj);
NamingContext ctx =
NamingContextExtHelper.narrow(root.new_context());
root.rebind_context(root.to_name("mycontext"), ctx);
root.rebind(root.to_name(
"mycontext/myserver.ext",
vs9.4 myserver);
25
9.4.9 Interoperabilität
zwischen verschiedenen CORBA-Implementierungen
General Inter-ORB Protocol (GIOP)
(Transfersyntax + Nachrichtenformate)
Internet Inter-ORB Protocol (IIOP)
andere
(+ Realisierung über TCP/IP)
Objektbezugnahme über Interoperable Object Reference (IOR)
vs9.4
26
Ferner: Environment-Specific Inter-ORB Protocols (ESIOPs)
statt GIOP/IIOP, falls auf bereits vorhandener
Middleware aufgesetzt werden soll. Beispiel:
DCE Common Inter-ORB Protocol (DCE-CIOP)
ist ein ESIOP auf Basis des DCE RPC.
vs9.4
27
Interoperabilität RMI – CORBA durch
„RMI over IIOP“ (statt über JRMP – Java Remote Method Protocol)
Klient/Anbieter programmiert in Java RMI, Vertreter-Erzeugung mit
rmic –iiop
Client
Server
CORBA
RMI
(Java  IDL )
RMI
CORBA
(erfordert Java Interface!)
Einige Programmierunterschiede zu Java RMI:
- Java Naming and Directory Interface (JNDI) statt Registry
- keine verteilte Speicherbereinigung
- ...
vs9.4
28
9.4.10 Replikation
Für Fehlertoleranz:
CORBA-Spezifikation: Fault-Tolerant CORBA (OMG 2000)
Implementierung:
Eternal System (Moser et al. 1998-2000),
basiert auf Totem-Protokoll für zuverlässige
Gruppenkommunikation mit vollständig
geordneten Rundrufen
Replikationsabstraktion!
 Objektgruppe bleibt vor Klienten verborgen
 Klient verwendet IOGR genauso wie IOR
 Verschiedene Replikationstechniken stehen zur Auswahl
vs9.4
29
Für Effizienz:
Keine CORBA-Spezifikation
Implementierung:
Cascade System (Chockler et al. 2000),
realisiert Caching
mit unterschiedlichen Konsistenzeigenschaften
Replikationsabstraktion – wenngleich etwas eingeschränkt durch
die Möglichkeit, die Konsistenz zu wählen
vs9.4
30
9.4.11 JacORB
= Open Source Java ORB
(Gerald Brose u.a., FU Berlin 1996-.....)
http://jacorb.inf.fu-berlin.de
Buch zu CORBA mit Java:
Brose, Vogel, Duddy: Java Programming with CORBA. Wiley 2001
vs9.4
31