verteilte objektorientierte systeme iihaase/lehre/versy/slides/v10verteilte… · ada, c, c++,...
TRANSCRIPT
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