Prof. Dr. Oliver Haase

Verteilte SystemeVerteilte Objektorientierte Systeme II

1

Überblick

2

Verteilte Objektorientierte Systeme 1

‣ RPC

‣ verteilte objektorientierte Architekturen

‣ Java RMI

Verteilte Objektorientierte Systeme 1I

‣ CORBA

Einführung‣ Common Object Request Broker Architecture

‣ standardisiert von der Object Management Group (OMG)• Konsortium zahlreicher Firmen und Organisationen

• weiterer wichtiger Standard: UML

‣ sprachunabhängig, d.h. Server und Klienten können in unterschiedlichen Sprachen geschrieben sein.

‣ (De–)Marshalling erlaubt verschiedene Sprachen bei Sender und Empfänger

‣ außerdem betriebssystemunabhängig

3

CORBA ermöglicht das Entwickeln heterogener verteilter OO-Systeme

Object Management Architecture‣ CORBA-Architektur: Object Management Architecture

(OMA)

4

Object Request Broker

Application

Objects

Common

Facilities

Common

Object Services

Domain Objects

Object Request Broker

Application

Objects

Common

Facilities

Common

Object Services

Domain Objects

1

Object Request Broker (ORB)‣ Herzstück der OMA

‣ vermittelt (engl: to broker) Anfragen vom Klienten zum entfernten Serverobjekt.

‣ führt Marshalling und Demarshalling durch

‣ vergleichbar mit Remote-Reference–Schicht in Java RMI

‣ jeder Prozess mit CORBA-Objekten muss einen ORB besitzen

‣ORBs kommunizieren über standardisierte Protokolle miteinander

5

Object Request Broker

Application

Objects

Common

Facilities

Common

Object Services

Domain Objects

2

Common Object Services (COS)‣ Basisdienste, die

• über den Methoden–Transport hinausgehen

• für sehr viele Anwendungen interessant sind

‣ Beispiele:• Naming Service

• Trading Service → attributbasierter Namensdienst

• Event Service→ asynchrone Kommunikation

6

Object Request Broker

Application

Objects

Common

Facilities

Common

Object Services

Domain Objects

3

Common Facilities ‣ Dienste, die über die COS hinausgehen

‣ komplexer, spezieller, seltener genutzt

‣ untergliedert in die Bereiche

• Informationsmangement

• Benutzerschnittstellen

• Systemmanagement

• Taskmanagement

7

Object Request Broker

Application

Objects

Common

Facilities

Common

Object Services

Domain Objects

4

Domain Objects‣ noch spezieller auf Anwendungsbereich zugeschnitten, z.B.

Telekommunikation, Bankwesen, Medizin

‣ vertikale Segmentierung

8

Object Request Broker

Application

Objects

Common

Facilities

Common

Object Services

Domain Objects

5

Application Objects‣ eigentliche Anwendung, verteilt auf Server– und

Klientobjekte

‣ kommunizieren über ORB miteinander

‣ können COS, Common Facilities und Domain Objects verwenden

‣ nicht Teil des CORBA–Standards

9

ORB: Methodenfernaufruf

‣ Klient ruft entfernte Methode am lokalen Stub auf (wird vom IDL–Compiler aus Schnittstellen–Spezifikation erzeugt)

‣ Stub verpackt die Parameter (Marshalling)

‣ORB ist zuständig für Lokalisieren des Serverobjekts(→ hosting ORB ist in Objektreferenz kodiert)

10

Stub DII

ORB

Klient Server

DSI Skeleton

Objektadapter

ORB

GIOP

ORB: Methodenfernaufruf

‣ Server auf entferntem Rechner → ORB kommuniziert mit entferntem ORB über General Inter-ORB Protocol (GIOP)

‣ GIOP bezeichnet Familie von Protokollen, konkrete Instantiierung hängt von verwendetem Transportprotokoll ab

‣ Am häufigsten: Internet Inter-ORB Protocol (IIOP), oberhalb von TCP

11

Stub DII

ORB

Klient Server

DSI Skeleton

Objektadapter

ORB

GIOP

ORB: Methodenfernaufruf

‣ORB auf Serverrechner übergibt Anfrage an Objektadapter

‣Objektadapter startet ggf. Server

‣Objektadapter übergibt Anfrage an Skeleton (generiert von IDL–Compiler)

‣ Skeleton entpackt Parameter (Demarshalling) → Server

12

Stub DII

ORB

Klient Server

DSI Skeleton

Objektadapter

ORB

GIOP

Dynamische Methodenaufrufe

‣ dynamischer Methodenaufruf wird erst zur Laufzeit zusammengesetzt:

‣ Vorteil: Erlaubt Methodenaufrufe, die zur Compilierzeit nicht nicht bekannt sind.

13

// vereinfachter Pseudocodeinvoke(object, method, in_params, out_params);

Dynamische Methodenaufrufe

‣ Dynamic Invocation Interface (DII) erlaubt Klienten, Server–Schnittstelle dynamisch zu erfragen und entsprechende Methodenaufrufe zu konstruieren (vgl. Java–Introspektion)

‣ Dynamic Skeleton Interface (DSI) nimmt solche Aufrufe serverseitig entgegen

14

Stub DII

ORB

Klient Server

DSI Skeleton

Objektadapter

ORB

GIOP

Interface Definition Language‣ Die Implementierung von Applikationsobjekten kann in

verschiedenen Sprachen erfolgen

‣ Die Schnittstellenbeschreibung muss jedoch einheitlich erfolgen, damit • jeder Nutzer weiß, wie er ein Objekt ansprechen kann;

• Client-Stubs und Server-Skeleton daraus erzeugt werden können.

15

CORBA IDL (Interface Definition Language) ist eine programmiersprachenunabhängige

Spezifikationssprache zu diesem Zweck.

Interface Definition Language‣ IDL beschreibt Signaturen (Prototypen) und benötigte

Datentypen, keine Implementierung!

‣ Syntax orientiert sich an C++

16

C-Klient

Java-Klient

C

Klienten

Stub Java

Klienten

Stub

C++

Klienten

Stub

IDL

Compiler

C++-Server

Stub

Methoden-

spezifikation

in IDL

C++-Server C++-Klient

generiert

automatisch

Netzwerk

Kommunikation

IDL-Sprach-Mappings

‣ für jede unterstützte Sprache gibt es ein Mapping, derzeit: ADA, C, C++, COBOL, Java, Lisp, PL/I, Python, Smalltalk und XML.

‣ Abbildung von IDL auf Java nicht trivial, da IDL mächtiger als Java:• mehr Typkonstruktoren (Strukturen, Unions, …)

• IDL erlaubt, den Parameter–Übergabemechanismus zu spezifizieren

17

IDL-Syntax

‣ Modul: zusammengehörende Definitionen einer Anwendung, enthält:• Datentypen (ähnlich wie in C++, d.h. Klassen, Strukturen,

Enums, Unions, …)→ werden auf (spezielle) Java-Klassen abgebildet

• Schnittstellen, bestehend aus- Methoden

- öffentlichen Instanzvariablen → werden auf Getters/Setters abgebildet

• Ausnahmen

18

IDL-Syntax

‣ Methoden: Pro Parameter wird Übergabemechanismus spezifiziert: in, out oder inout.

‣ Problem: Java kennt nur Call-by-Value, d.h. in.

‣ Lösung: Abbildung von out- und inout-Params auf Behälterklassen.

19

IDL-Syntax‣ Beispiel:

20

module QueueApp { struct Person { string firstname; string lastname; unsigned short age; }; exception EmptyQueueException { string message; }; interface Queue { boolean enqueue(in Person person); Person dequeue() raises (EmptyQueueException); boolean isEmpty(); };};

CORBA Naming Service

‣ Common Object Service zum Beziehen entfernter Objekt-referenzen

‣ Naming Service ist selbst ein CORBA–Objekt

‣ Für Bootstrapping gibt es 2 ORB-Operationen, die COS-Dienste liefern• list_initial_references: liefert alle am lokalen ORB

verfügbaren COS–Dienste, u.a. Naming Service• resolve_initial_references: liefert Referenz auf Dienst mit

gegebenem Namen

‣ liefert Referenz auf einen Naming Context

21

CORBA Naming Service

‣ Naming Context kann enthalten:• weitere Naming Contexts, und

• Name Bindings: Name → Objektreferenz

‣ erlaubt Aufbau hierarchischer Namensräume pro ORB-eigenem Naming Service

‣ Interoperable Naming Service (INS) erlaubt die Nutzung eines Naming Services von einem entfernten ORB aus• entfernter Naming Service muss beim Start des eigenen

ORBs in URL-ähnlicher Form konfiguriert werden.

22

CORBA aus Server-Sicht

‣ Erstellen und Starten eines CORBA–Serverobjekts besteht aus folgenden Schritten:

1) Erstellen einer IDL–Spezifikation

2) Implementieren des Serverobjekts

3) Erzeugen einer CORBA–Referenz

4) Starten des Serverobjekts

23

1) Erstellen einer IDL-Spezifikation‣ Zum Beispiel in einer Datei hello.idl wie folgt:

24

module HelloApp { interface Hello { string sayHello(in string name); };};

‣ Durch Aufruf von

$idlj -fserver hello.idl

erzeugt der Java-SDK-eigene IDL-Java-Compiler die serverseitigen Generate (z.B. Server-Skeleton)

2) Implementieren des Server-Objekts

‣ Implementierung HelloImpl muss den generierten portablen Objektadapter HelloPOA erweitern:

25

class HelloImpl extends HelloPOA { public String sayHello(String name) { return (name.equals(“”)) ? “Hello!” : “Hello, “ + name + “!”; }}

‣ Beachte: Strings sind Basistyp in IDL → kein null–Werte möglich!

3) Erzeugen einer CORBA-Referenz

26

‣ORB initialisieren

• dabei zu verwendende ORB-Implementierung angeben

‣ Referenz auf Root POA besorgen

‣ Root POA aktivieren

‣ Referenz auf Naming Service (Naming Context) besorgen

‣ Serverobjekt instantiieren, CORBA-Referenz erzeugen

‣ CORBA-Referenz an Naming Service binden

‣ORB starten

• hält den Server-Prozess am Leben

3) Erzeugen einer CORBA-Referenz

27

class HelloServer { public static void main(String args []) throws Exception { ORB orb = ORB.init(args, null); POA rootpoa = POAHelper.narrow( orb.resolve_initial_references(”RootPOA”)); rootpoa.thePOAManager().activate(); NamingContextExt nameService = NamingContextExtHelper.narrow( orb.resolve_initial_references(”NameService”)); org.omg.CORBA.Object ref = rootpoa.servant_to_reference( new HelloImpl()); Hello server = HelloHelper.narrow(ref); nameService.rebind(nameService.to_name(”HelloServer”), server); orb.run(); }}

4) Starten des Serverobjekts

‣ Starten des Naming Service

• horcht defaultmäßig auf Port 900 → darf auf Unix-System nur von Systemapplikation verwendet werden

‣ Starten des Serverapplikationsobjekts

28

$tnameserv -ORBInitialPort 1050

$java HelloServer -ORBInitialPort 1050

CORBA aus Client-Sicht

‣ Umgang mit CORBA besteht auf Client-Seite aus drei Schritten:

1) Beschaffen einer entfernten Referenz

2) Aufruf entfernter Servermethoden

3) Starten des Klientenapplikationsobjekts

29

‣ Durch Aufruf von

$idlj -fclient hello.idl

erzeugt der Java-SDK-eigene IDL-Java-Compiler die clientseitigen Generate (z.B. Client-Stub)

Schritte 1) & 2)

30

class HelloClient { public static void main(String args []) throws Exception { ORB orb = ORB.init(args, null); NamingContextExt nameService = NamingContextExtHelper.narrow( orb.resolve_initial_references(”NameService”)); Hello server = HelloHelper.narrow( nameService.resolve_str(”HelloServer”)); String name = JOptionPane.showInputDialog( ”Who do you want to greet?”); if (name == null) { name = ””; } System.out.println(server.sayHello(name)); }}

3) Starten des Clientobjekts

31

‣ Analog zum Starten des Clientapplikationsobjekts

$java HelloClient -ORBInitialPort 1050