Forschungszentrum Karlsruhe Technik und Umwelt Clemens Düpmeier, 27.03.2015 Verteilte Kommunikation oberhalb der Socket-API Datencodierung, Remote Procedure.

Forschungszentrum KarlsruheTechnik und Umwelt

Clemens Düpmeier, 11.04.23

Verteilte Kommunikation oberhalb der Socket-API

Datencodierung, Remote Procedure Calls,

Verteilte Objektkommunikation,

Namensdienste und Ortstranparenz



Zunächst mal 2 Probleme

• Kommunikation basiert auf Nachrichtenaustausch (über Sockets)

• Ein grundsätzliches Problem mit Sockets ist

– Wir müssen Encoding / Decoding der Nachrichten definieren, dass

jeder Kommunikationspartner versteht

– Nachrichten sollen dabei beliebig komplex sein können (i.e. auch

komplexe binäre Strukturen)

• 2. Problem:

– Wir brauchen einfache, aber universell funktionierende Mechanismen

an Stelle von selbst-definierten Protokollen (Abstraktion oberhalb der

Protokollebene)

• Höherwertige Kommunikationsmechanismen stellen Lösungen für diese beiden Probleme bereit



Übertragung komplexer binärer Daten



Externe Datenrepräsentation

• Höherwertige Kommunikationsmechanismen nutzen ein gemeinsames Datenformat, genannt externe Datendarstellung zur transparenten Übertragung von beliebigen (binären) Daten.

• Notwendig wegen der Heterogenität der Umgebungen

– Unterschiedliche Hardwarearchitektur

– Verschiedene Betriebssysteme

– Verschiedene Programmiersprachen

• Unter Marshalling versteht man den Prozess der Transformation strukturierter Datenelemente und elementarer Werte in eine (mit einer Nachricht übertragbaren) externe Datendarstellung

• Unter Un-Marshalling versteht man den Prozess der Erstellung elementarer Werte aus ihrer externen Datendarstellung und den Wiederaufbau der ursprünglichen Datenstrukturen.



Formen von externen Darstellungen

Sender und Empfänger sind sich über die Reihenfolge und die Typen der Datenelemente in einer Nachricht einig

• ISO: ASN.1 (Abstract Syntax Notation)

• Sun ONC (Open Network Computing)-RPC: XDR (eXternal Data Representation)

• Corba: IDL und CDR (Common Data Representation): CDR bildet IDL-Datentypen in Bytefolgen ab.

Vollständige Informationen über Reihenfolge und die Typen der Datenelemente sind in einer Nachricht enthalten

• Java: Objektserialisierung, d.h. Abflachung eines (oder mehrerer) Objektes zu einem seriellen Format inkl. Informationen über die Klassen.Deserialisierung ist die Wiederherstellung eines Objektes ohne Vorwissen über die Typen der Objekte.

Corba CDR Format

0–3

4–7

8–11

12–15

16–19

20-23

24–27

5

"Smit"

"h___"

6

"Lond"

"on__"

1934

Index in Bytefolge 4 Byte

Länge derZeichenkette“Smith”

Länge derZeichenkette“London”

unsigned int

Struct Person{ string name; string place; unsigned int year;};

Typ

Sequence

String

Array

Struct

Enumerated

Darstellung

Länge gefolgt von Elementen in der angegebenen Reihenfolge

Länge gefolgt von Zeichen in der angegebenen Reihenfolge

Array-Elemente in der angegebenen Reihenfolge

Die Reihenfolge der Deklarationen der Komponenten

Unsigned Long

Reihenfolge und Typen der Elementebei Sender und Empfänger bekannt!

SmithLondon1934

Java Objektserialisierung: vereinfacht

Person

3

1934

8-Byte Versionsnummer

int year

5 Smith

java.lang.Stringname:

6 London

h0

java.lang.Stringplace:

h1

Klassenname, Versionsnummer

Nummer, Typ und Nameder Instanzvariablen

Werte der Instanzvariablen

Das echte serialisierte Format enthält zusätzliche Typkennzeichner; h0 und h1 sind Handles, also Verweise auf serialisierte Objekte

public class Person implements Serializable{ private String name; private String place; private int year; public Person(String aName, String aPlace, int aYear) { name = aName; place = aPlace; year = aYear; } // gefolgt von Methoden für den Zugriff auf die Instanzvariablen}

Person p = new Person(„Smith“,“London“,1934);



Fazit

• Zuerst die schlechte Nachricht: das sieht alles ziemlich kompliziert zu implementieren aus, und das ist es auch!

• Die gute Nachricht: Solche externen Datendarstellungen sind schon konzipiert und implementiert

– und ihre Nutzung ist (insbesondere bei

objektorientierten Sprachen) einfach



Elementare Kommunikationsmuster



Blockierende, synchrone Interaktion

• über Anfrage-Anwort (Request-Reply) Protokoll

– Client schickt Anfrage-Nachricht an Server

– Server empfängt Nachricht und führt

zugehörige Aktion durch

– Server sendet Antwort-Nachricht an Client

zurück

• Ausführung auf dem Client blockiert nach Schicken der Anfrage-Nachricht so lange, bis Antwort-Nachricht erhalten wurde

• Beide, Client und Server, müssen zur Zeit der Interaktion verfügbar sein

– Wenn nicht, muss durch wiederholtes Senden

von Nachrichten Fehlersituation bereinigt

werden

• Typischer Weise über Verbindungs-orientierte Sockets implementiert

• Punkt-zu-Punkt Verbindung– Kommunikationspartner

müssen direkt verbunden sein (Keine Message-Router dazwischen)

• Viele mögliche Fehlersituationen



Mögliche Fehlersituationen bei Request-Reply

Client Server

1) Verlust der Auftragsnachricht

2) Verlust der Ergebnisnachricht

3) Ausfall des Servers

4) Ausfall des Clients

1)

2)

3)4)



Client Server

Tim

eout

Tim

eout

Tim

eout

Request

Reply

Request Bearbeitungdes Requests

Reply

Request Bearbeitungdes Requests

Ergebnis kannverschieden sein!

Ergebnis kannverschieden sein!

at least once Semantikat least once Semantik

Client Server

Tim

eout

Tim

eout

Tim

eout

Request

at most once Semantikat most once Semantik

Liste der RequestsListe der Requests

Reply

Request Bearbeitung des Requests;Request eintragenBearbeitung des Requests;Request eintragen

Reply

RequestListe der Requests über-prüfen; Verwerfen des 2.Requests

Liste der Requests über-prüfen; Verwerfen des 2.Requests

Acknowledge-ment

Request löschenRequest löschen



Fehlersemantiken und Eigenschaften



Weiteres zur Fehlerbehandlung

• Um zu verhindern, dass ein Service vorübergehend nicht verfügbar ist, kann

– Replizierung des Service (Serverteils) und

automatische Lastverteilung und Relokation bei

Fehlern eingesetzt werden

• Für eine "Exactly Once"-Strategie und kompliziertere Konsistenzerhaltung von Daten benötigt man Transaktionskonzept (siehe später)



Remote Procedure Calls (RPC)

Vorläufer der Verteilten Objektkommunikationsmechanismen



Idee für einen entfernten Prozeduraufruf



Remote Procedure Calls (Sun-RPC)

• Realisieren entfernten Funktionsaufruf

– übernehmen Funktion des Anwenderprotokolls bei Socket-

orientierter Kommunikation

– At least once Semantik (d.h. entfernter Prozeduraufruf wird

mindestens 1-mal ausgeführt)

– synchrone Kommunikation

– beliebig komplexe Argument(e) und Returnwerte werden als

komplexe Datenstrukturen aufgefasst und mit XDR kodiert

übertragen bzw. dekodiert.



Synchrone Kommunikation in RPC‘s

Zeit

Server

ClientClient vor Aufruf

RPC Aufruf

Lokale Prozedur

RPC Return

Client wartet Client nach Aufruf

Lokale Funktionaufrufen



Registrierung von RPC Programmen

Client System Server System

ClientProgramm

Portmap / rpcbind

111

RPC Server

Registrierung

Lookup

RPC Call



Beispiel für RPC Server (Low Level)• Registrierung einer lokalen

Prozedur im Laufzeitsystem des Servers unter Angabe von

– Programmnummer,

Version

– Prozedurnummer

– Lokaler Funktion

– Parameterdecodierung

– Returnwertdecodierung• Starten der

Laufzeitinfrastruktur des Servers

– Laufzeitinfrastruktur

registriert Programme

und Prozeduren im

Namensdienst

#include <stdio.h>#include <rpc/rpc.h>#include <rpcsvc/rusers.h>

/* lokale Funktion, die Anzahl Benutzer feststellt */void *rusers();

main(){ if (rpc_reg(RUSERSPROG,RUSERSVERS,RUSERSPROCNUM,rusers, xdr_void, xdr_u_int, /* Welche Argument hat RPC Prozedur, * was wird zurückgegeben */ "visible") == -1) /* Tranportwege = hier alle */ { fprintf(stderr, "Couldn't register myself as RPC program\n"); exit(1); }svc_run(); /* Endlosschleife, * nur return, wenn durch Signal abgebrochen */ fprintf(stderr, "Programm wurde beendet\n"); exit(1);}



Beispiel für RPC Client (Low Level)• Aufruf der Prozedur

unter Angabe von

– Hostname,

– Programmnr.,

Version

– Prozedurnummer

– Codierer +

Parameter

– Decodierer,

Variable für

Returnwert• Ausgabe des Wertes

auf Standardausgabe

/* einige includes */main(argc, argv) int argc; char **argv;{ unsigned int nusers; enum clnt_stat cs;

if (argc != 2) { fprintf(stderr,"usage: rusers hostname\n"); exit(1); } if (cs= rpc_call(argv[1], RUSERSPROG, /* Programmnummer */ RUSERSVERS, RUSERSPROC_NUM,/* Version, Prozedur */ xdr_void, (char *)0, /* Argumente */ xdr_u_int, (char *)&nusers, /* Returnwert */ "visible") != RPC_SUCCESS) { clnt_perrno(cs); /* Gebe RPC Fehlercode auf Console aus */ exit(1); } fprintf(stdout, "%d users on %s\n", nusers, argv[1]); exit(1);}



Low Level RPC sieht wirklich hässlich aus

• Problem: sieht noch nicht wirklich wie lokaler Prozeduraufruf aus

• Lösung hierfür ist Stub- und Skeleton Generierung– Führe RPC Sprache ein, mit der RPC Aufrufe bzgl. Parameter

(welche XDR Typen gehören dazu, etc.) spezifiziert werden– RPC-Compiler generiert daraus lokale Funktionen

• XDR-Kodierungs- und Dekodierungsfunktionen• Stubs für die Clientseite (sehen wie lokale Funktionen aus)• Anwendungsprogrammierer benutzt nur die Stubs• Skeleton für die Serverseite (Skeleton ruft normale

Anwenderprozedur auf)• Anwendungsprogrammierer programmiert nur

Anwendungsprozeduren• Stubs und Skeleton kommunizieren dann miteinander über die

bereits vorgestellte Low Level RPC Schnittstelle

• Ähnliches Prinzip sehen wir gleich auch bei RMI und CORBA



/* einige includes */main(argc, argv) int argc; char **argv;{ unsigned int nusers;

if (argc != 2) { fprintf(stderr,"usage: rusers hostname\n"); exit(1); } nusers=rusers(argv[1]); // Aufruf Stub fprintf(stdout, "%d users on %s\n", nusers, argv[1]); exit(1);}

int rusers(char *hostnname) { if (cs= rpc_call(hostname, RUSERSPROG, /* Programmnummer */ RUSERSVERS, RUSERSPROC_NUM,/* Version, Prozedur */ xdr_void, (char *)0, /* Argumente */ xdr_u_int, (char *)&nusers, /* Returnwert */ "visible") != RPC_SUCCESS) return -1;else return cs;}

Stub-oder Proxy

Aufruf von Stub

Bedeutung vonStubs



Wo wird RPC eingesetzt?

• RPC Einsatz findet sich an vielen Stellen bei Linux und Windows Betriebssystemen

• Beispiele Unix / Linux

– NFS - Network File Sytem

– YP - YP / NIS Verzeichnisdienst

– Mount Daemon für das Mounten von Netzwerklaufwerken

– ...

• Windows - alles an Diensten, was abhängig vom RPC Dienst ist

– COM+ Ereignissystem (COM+ Kommunikation allgemein)

– Dateireplikation

– Distributed Transaction Dienst

– Druckerdienst

– ... RPC Schnittstellen stellen oftmals unbekannte Sicherheitslücken im Netz dar



Verteilte Objektkommunikation



Entfernte und lokale Methodenaufrufe

entfernterAufruf entfernter

AufruflokalerAufruf

lokalerAufruf

lokalerAufruf

• Jeder Prozess hat Objekte, einige, die entfernte Aufrufe erhalten können - entfernte Objekte genannt -, einige, die nur lokale Aufrufe erhalten können

• Objekte müssen die entfernte Objektreferenz eines Objektes in einem anderen Prozess kennen, um dessen Methoden aufrufen zu können. Wo bekommen sie diese Referenz her ?

• Die entfernte Schnittstelle spezifiziert, welche Methoden entfernt aufgerufen werden können



Eigenschaften Verteilter Objekte

• Interagierende Objekte sind auf mehr als einen Prozess verteilt

• Wichtige Begriffe (Auswahl, vereinfacht):

– Entfernte Objektreferenz: die „Adresse“/eindeutige Identität eines Objekts im

ganzen verteilten System

– Entfernte Schnittstellen: die Schnittstelle eines entfernten Objekts (interface

definition language, IDL)

– Ereignisse/Aktionen: Ereignisse/Aktionen von Objekten können

Prozessgrenzen überschreiten

– Exceptions/Ausnahmen: verteilte Ausführung des Systems erweitert das

Spektrum möglicher Fehler

– Garbage Collection: Freigabe nicht mehr benutzten Speichers wird im

verteilten System schwieriger

Entfernte Objektreferenzen

• Über Raum und Zeit garantiert eindeutig!

• Bestehen aus

– Internetadresse: gibt den Rechner an

– Port-Nummer und Zeit: Identifizieren eindeutig den Prozess

– Objektnummer: Identifiziert das Objekt

– Schnittstelle: beschreibt die entfernte Schnittstelle des Objekts

• Werden erzeugt von einem speziellen Modul - dem entfernten Referenzmodul - wenn eine lokale Referenz als Argument an einen anderen Prozess übergeben wird und in dem korrespondierenden Proxy gespeichert.

Achtung: Diese Art der Referenz erlaubt kein Verschieben des Objektes in einen anderen Prozess zur Laufzeit!

Internetadresse Port-Nummer Zeit Objektnummer Schnittstelle desentfernten Objektes

32 bits 32 bits 32 bits 32 bits



Entfernte Schnittstellen

• Die entfernte Schnittstelle gibt an, wie auf entfernte Objekte zugegriffen wird (Signatur der Methodenmenge).

• Ihre Beschreibung enthält– Den Namen der Schnittstelle– Möglicherweise Datentypdefinitionen– Die Signatur aller entfernt verfügbaren Methoden, bestehend

aus• Dem Methodennamen• Ihrer Ein- und Ausgabeparameter• Ihrem Rückgabewert

• Jede Verteilte Objektkommunikationstechnologie besitzt eine eigene Sprache, um solche Schnittstellen zu beschreiben.

Enternte Schnittstelle: Beispiel CORBA IDL

struct Person {string name; string place;long year;

} ;interface PersonList {

readonly attribute string listname;void addPerson(in Person p) ;void getPerson(in string name, out Person p);long number();

}; Parameter sind in, out oder inout

Signatur: Definitionder Methoden

CORBA hat Strukturen, Java hat Klassen entfernte Schnittstelle

entfernteSchnittstelle lokaler

Aufrufm1m2m3

m4m5m6

Daten

Implementierungder Methodenentfernter

Aufruf



Proxy Design Pattern

+request()

<<interface>>Subject

+request()

RealSubject

+request()

Proxy

realSubject



Bedeutung von Schnittstellen

Client Server

Gewünschte Schnittstelle

im Client

Implementierungim Server

Proxy Object (Stub)

Netzwerk

Skeleton

Kommunikationsschnittstelle



Teile einer Implementierung

• Kommunikationsschnittstelle: zuständig für das Request-/Reply

(Anfrage-Antwort) Protokoll

• Entferntes Referenzmodul: Übersetzt zwischen entfernten und lokalen

Objektreferenzen; besitzt meist eine entfernte Objekt-Tabelle, in der

diese Zuordnung eingetragen wird. Beim ersten Aufruf wird die

entfernte Objektreferenz von diesem Modul erzeugt.

• Proxies und Skeletons

– Proxies (auch Stubs) genannt stellen Client Schnittstelle zur

Verfügung

– Skeletons rufen serverseitige Objektimplementierung auf

Rolle von Proxy und Skeleton

Objekt A

EntferntesReferenzmodul

Kom

munikations-

schnittstelle

Client

Proxy B

EntferntesReferenzmodul

Kom

munikations-

schnittstelle

Server

Objekt BDispatcher B Skeleton BRequest

Reply

Ausführung desRequest/Reply Protokolls

Ausführung desRequest/Reply Protokolls

Übersetzung zwischenlokalen und entfernten

Objektreferenzen

Übersetzung zwischenlokalen und entfernten

Objektreferenzen

Proxy: schafft Transparenz für Client.Proxy implementiert entfernte Schnittstelle.Marshals Request und unmarshals Reply.Leitet Request weiter.

Proxy: schafft Transparenz für Client.Proxy implementiert entfernte Schnittstelle.Marshals Request und unmarshals Reply.Leitet Request weiter.

Skeleton: implementiert Methoden derentfernten Schnittstelle. UnmarshalsRequest und Marshals Reply. Ruft Methode in entferntem Objekt auf.

Skeleton: implementiert Methoden derentfernten Schnittstelle. UnmarshalsRequest und Marshals Reply. Ruft Methode in entferntem Objekt auf.

Dispatcher: wähltMethode im Skeletonaus.

Dispatcher: wähltMethode im Skeletonaus.



Parameterübergabe: Referenz- und Kopiersemantik

• Entfernte Methodenaufrufe sollten Parameterübergabe-Semantik der verwendeten Programmiersprache respektieren:

– In Java Übergabe von Werten per Kopie, Übergabe von Objekten per

Referenz

– In C++ freie Wahl der Übergabeart

• Probleme:

– Entfernte Referenzen auf Werte prinzipiell nicht möglich

– Entfernte Referenzen auf Objekte nur möglich, wenn entsprechende

Stubs und Skeletons existieren

– Empfänger benötigt Implementierungsklasse für erhaltenes Objekt

(Kopiersemantik) bzw. Stub (Referenzsemantik)

Beispiel für Parameterübergabe

Betrachte folgende Objektklasse:

import B;public interface A extends Remote { public void setB(B b) throws Throwable; public B getB() throws Throwable;}}

public class AServant extends UnicastRemoteObject implements A {

private B b; public void setB(B b) { this.b = b; } public B getB() { return this.b; }}

AServant

B

ASkeleton



Parameterübergabe: Kopiersemantik (1)

Adressraum 1Adressraum 1

Klienten-objekt

AStub


AServant

B

ASkeleton"getB"

1. Clientobjekt hältReferenz auf Instanzvon A, ruft daraufMethode getB() auf.

2. Stub übermitteltMethodenaufruf anSkeleton

3. Skeleton delegiertMethodenaufruf anServant

4. Servant übergibtReferenz auf Instanzvon B an Skeleton



Parameterübergabe: Kopiersemantik (2)


AStubKlienten-objekt


AServant

B

ASkeletoncodierter Zustand

von B

B.jarB.jar

B

5. Skeleton kodiertZustand von Instanzgemäß Wire Protocol

6. Kodierter Zustandwird an Stubübertragen

7. Stub lädt Klasse B,dekodiert Zustandund erzeugt damitneue Instanz von B

8. Stub übergibtVerweis auf neueInstanz an Aufrufer



Parameterübergabe: Referenzsemantik (1)


Klienten-objekt

AStub


AServantASkeleton

B

"getB"

1. Clientobjekt hältReferenz auf Instanzvon A, ruft daraufMethode getB() auf.

2. Stub übermitteltMethodenaufruf anSkeleton

3. Skeleton delegiertMethodenaufruf anServant

4. Servant übergibtReferenz auf Instanzvon B an Skeleton



Parameterübergabe: Referenzsemantik (2)


AServant

B

ASkeleton


AStubKlienten-objekt

B.jarB.jar

BSkeleton

(hostname, port)

BStub

5. A-Skeleton erzeugtneues Skeleton für B,falls nicht bereitsvorhanden

6. A-Skeleton sendetNetzwerkadresse vonB-Skeleton an A-Stub

7. A-Stub erzeugtneuen B-Stub, derNetzwerkadresse vonB-Skeleton enthält

8. A-Stub übergibtVerweis auf B-Stuban Aufrufer



Weitere Aspekte der Objektübergabe

• Festlegung der Übergabesemantik i.A. durch Typ des formalen Parameters:

– Referenzen und keine Referenzen sind zunächst alles Werte! Die Übergabesemantik

regelt die Art der Interpretation.

– Referenzübergabe, wenn formaler Parameter bestimmtes Interface (in Java RMI z.B.

java.rmi.Remote) implementiert

– Wertübergabe sonst

• Bei Wertübergabe Komplikationen möglich:

– Wenn übergebenes Objekt direkt oder indirekt andere Objekte referenziert, müssen diese

ebenfalls übergeben werden (mit welcher Übergabesemantik?)

– Sharing von Objekten muss auf der Clientseite rekonstruiert werden

– Wenn übergebenes Objekt echter Untertyp des formalen Parameters ist, ist u.U. Upcast

erforderlich

• Was ist mit Garbage Collection von Serverobjekt, wenn Client Referenz darauf hat (siehe nächste Folie)?



Weitere Implementierungsaspekte

• Namensdienst, der Clients Objektreferenzen zunächst unabhängig von ihrer Lage vermitteln kann

• Parallele Abarbeitung: Um zu verhindern, dass ein entfernter Aufruf einen anderen Aufruf verzögert, weisen Server der Ausführung jeden entfernten Aufrufs einen eigenen Thread zu!

• Aktivierung: Automatische Erzeugung einer Instanz und Initialisierung der Instanzvariablen.

• Persistenter Objektspeicher: Verwaltet persistente Objekte, also Objekte, die zwischen Aktivierungen weiterbestehen.

• Verteiltes garbage collection: Stellt sicher, dass in einem verteilten System garbage collection durchgeführt wird. Problem: Referenzen, die nur in Nachrichten vorhanden sind.



Fallbeispiel(e)

Am Beispiel von Java



Beispiel RMI



RMI – Remote Method Invocation

• Definiert Verteilte Objektkommunikation von Java-Objekten unabhängig von ihrem Ort

• Eine reine Java-Lösung

• Callback Funktionalität und dynamisches Laden von Code

• Alle entfernten Objekte müssen eine entfernte Schnittstelle definiert als Java Interface abgeleitet von java.rmi.Remote besitzen

• Es sind Werkzeuge für die Generierung von Stubs und Skeletons vorhanden.

• JDK stellt eine Implementierung eines Naming-Service zur Verfügung: die RMIregistry.

• Ein RMI-Dämon erlaubt eine flexible (on-demand)-Instanziierung (Aktivierung) von Objekten.



RMI Architektur

Server Programm

Skeleton/Reflection

Remote Reference Layer

Transport Layer

Stubs

Remote Reference Layer

Transport Layer

Netzwerk

Server Client

RMIKomponenten

Client ProgrammInterface

Gemeinsames



Remote Reference Layer (RRL)

• Stub benutzt RRL-API, um Methodenaufrufe auf die Serverseite zu übertragen

• RRL auf Serverseite benutzt Reflection oder Skeleton Objekte, um auf Serverobjekt zuzugreifen

• RRL unterstützt unicast Punkt-zu-Punkt Objektverbindungen und aktivierbare Objekte

• Andere Formen (Multicast) sind denkbar



Transportlayer

• Stellt eigentliche Verbindung zwischen JVM's her– spricht JRMP (Java Remote Method Protocol) als

stream-basiertes Protokoll oberhalb von TCP/IP

• RMI ab JDK 1.3 spricht zusätzlich das RMI-IIOP Transportprotokoll basierend auf IIOP (Internet Inter-ORB Protocol)

– ermöglicht Kommunikation zwischen CORBA und

RMI Objekten

• enthält Fähigkeiten, RMI Verkehr über andere Verbindungen zu tunneln (z.B. über HTTP)



Beispiel: Interfacebeschreibung eines RMI Objektes (entfernten Objektes)

• Interface von Remote ableiten

• Jeder Methode throws java.rmi.RemoteException hinzufügen

• Objekte, die so ein "Remote" Interface implementieren, sind entfernte Objekte

public interface Compute extends Remote {<T> T executeTask(Task<T> t)

throws RemoteException;}



Verwendet "normales" Objekt mit Interface Task

• Nicht-Remote Objektparameter von entfernten Methoden müssen serialisierbar sein

– Implementierungen müssen also sagen: implements Serializable• Ein Task ist für uns ein beliebiges Objekt, dass eine execute() Methode zur

Ausführung einer Berechnung besitzt und irgendein Ergebnis zurückgibt• Objekte, die Task implementieren, sind lokale Objekte

import java.io.Serializable;

public interface Task<T> {T execute();

}



RMI Parameterübergabe

• Entfernte Objekte werden als Proxy (Stub) an den Client übergeben (Referenzsemantik)

– Bei Benutzung sind sowohl Methoden wie auch Daten des

Objektes entfernt

• Andere (lokale Objekte) werden Call by Value (Kopiersemantik) übergeben

– Beim Kommunikationspartner wird dabei eine Kopie des

Objektes angelegt• Die Objekte müssen hierfür serialisierbar sein, um übertragen

werden zu können

• Der Code muss beim Kommunikationspartner verfügbar sein oder dynamisch geladen werden



Implementierung des entfernten Objektes

• Implementierungsklasse wurde von UnicastRemoteObject abgeleitet; dies macht aus Objekt in Konstruktor von UnicastRemoteObject einen Server

• Konstruktor registriert Remote Objekt gleichzeitig in RMI Laufzeitinfrastruktur und macht Objekt so von aussen referenzierbar

public class ComputeEngine extends UnicastRemoteObject implements Compute

{public ComputeEngine() throws RemoteException() {

super();}public <T> T executeTask(Task<T> t) {

return t.execute();

}}



Alternative Implementierung

• Manuelles Registrieren des engine-Objektes in der RMI-Laufzeitinfrastruktur

• Laufzeitinfrastruktur liefert dabei Stub (Proxyobjekt) zurück

public class ComputeEngine implements Compute {

public <T> T executeTask(Task<T> t) {

return t.execute();

} }// und später bei InstanzierungComputeEngine engine = new ComputeEngine();Compute engineStub =(Compute)UnicastRemoteObject.exportObject(engine,0);



Namensauflösung bei RMI

Client System Server System

ClientProgramm

rmiregistry

1099

RMI Server

registry.rebind(...)

registry.lookup(liefert Stub)

Stub rufe remote Methodedurch Stub auf



Registry Klassejava.rmi.Registry

static void rebind(String name, Remote obj) // registriere // obj im Namensdienst // mit Name name

...static Remote lookup(String name) // hole Stub zu Name

// unter Anfrage beim// Namensdienst

…

Wie sieht RMI Name aus?

//hostname[:port]/Objektname



Basisstruktur RMI Server (1. Version)

• Security Manager setzen = Schutz vor Clientcode

• Namen für das Serverobjekt definieren

• Serverobjekt erzeugen; hier Version mit extends UnicastRemoteObject

• Mit Namen im rmiregistry registrieren

if (System.getSecurityManager() == null) System.setSecurityManager(new

RMISecurityManager());String name="//hostname/Compute";

try { Compute engineStub=new ComputeEngine(); Registry registry = LocateRegistry.getRegistry(); registry.rebind(name, engineStub);

} catch (Exception e) { }



Basisstruktur RMI Server (2. Version)

• Manuelle Registrierung in der Laufzeitinfrastruktur mit exportObject()

• Man beachte: das zurückgegebene Stubobjekt und nicht engine wird im Namensdienst registriert



try { ComputeEngine engine=new ComputeEngine(); Compute engineStub = UnicastRemoteObject.exportObject(engine,0) Registry registry = LocateRegistry.getRegistry(); registry.rebind(name, engineStub);

} catch (Exception e) { }



Basisstruktur RMI Client

• Security Manager setzen = Schutz vor Servercode

• Lookup des Serverobjektes im Registry

• Verwendung der Methoden des Remote Objektes



try { Registry registry = LocateRegistry.getRegistry(args[0]); Compute engine=(Compute)registry.lookup(name);

// Methoden des Remote Objektes verwenden} catch ....



Basisstruktur RMI Client (2)

• Client berechnet die Zahl PI über den Server

• Hierzu muss es eine Implementierung des Task-Interfaces geben, die innerhalb ihrer execute()-Methode PI berechnet und den Wert als BigDecimal zurückgibt

...

try { Registry registry = LocateRegistry.getRegistry(args[0]); Compute engine=(Compute)registry.lookup(name); Pi task = new Pi(Integer.parseInt(args[1])); BigDecimal pi = engine.executeTask(task); System.out.println(pi);} catch ....



Implementierung der PI-Berechnungsklasse

• zu lang für Folie

• siehe aber Java Tutorial

– enthält die komplette Implementierung des

Beispiels unter

– http://java.sun.com/docs/books/tutorial/rmi/cli

ent.html

http://java.sun.com/docs/books/tutorial/rmi/client.html

http://java.sun.com/docs/books/tutorial/rmi/client.html



Wie kommt der Server zum Code der Klasse PI?

• Der jar-File mit dem Code des Servers muss nicht notwendigerweise die Klasse PI enthalten

• Wie kommt dann aber der Klassencode der Klasse PI zum Server, wenn das PI-Berechnungsobjekt zum Server übertragen und dort ausgeführt wird?

– Java kann Code dynamisch über Netz laden!

– Hierfür muss der Code von PI irgendwo zum Download für den

Server bereitgestellt werden

– Und die Infrastruktur so aufgesetzt werden, dass sie weiss,

woher der Code geladen werden soll



Zusammenfassung: RMI Anwendung schreiben

1. Definiere die entfernte Schnittstelle

2. Implementiere die entfernte Schnittstelle durch eine Klasse (z.B. abgeleitet von UnicastRemoteObject)

3. Generiere Stubs und Skeletons mit rmic

4. Schreibe einen Server und Client

5. Starte den Namensdienst mit rmiregistry

6. Starte den Server auf der Maschine, wo das rmiregistry läuft

7. Starte den Client



RMI-Beispiel ablaufen lassen

• Vollständiger Code und Beschreibung im Java Tutorial von Sun• Achtung: Beim Starten der Applikation (Client + Server) muss der

Klassenlader richtig aufgesetzt werden (siehe Beschreibung im Tutorial), z.B.

java -Djava.rmi.server.codebase=http://myhost/Compute/classes/ \

-Djava.rmi.server.hostname=zaphod.east.sun.com - \

-Djava.security.policy=java.policy \

ComputeEngine

da sonst die Klassen, die über Netz gehen (z.B. das Stubobjekt vom Server, die Interfaces oder die Client Task Klasse), nicht geladen werden können

• Außerdem muss die Security-Policy Datei (wir schützen unsere Programme von fremder Code durch SecurityManger) richtig aufgesetzt werden



Verteilte Objekttechnologien

Common Object Request Broker Architecture(CORBA)



Object Management Group (OMG)

Distributed Component Object Model (DCOM)

• Gründung: April 1989

• Ziele:

– Interoperabilität

– Anwendungsintegration

– Portabilität

• Mitglieder:

– über 800 Mitglieder

– darunter: Apple, AT&T, DEC, HP, IBM, Microsoft, SUN,...

• Entwicklungsprozeß: Request for Proposal (RFP)

in heterogenen Umgebungenauf der Basis eines Objektmodells



Object Management Architecture (OMA)• Application Objects

– spezifische Anwendungsgebiete

– gehören nicht zur Infrastruktur

• Common Facilities

– allgemein nützliche Dienste (Drucken, E-Mail,

Datenbanken)

– nicht notw. Teil aller Infrastrukturen

• Object Request Broker (Objektbus)

– Infrastruktur für Kommunikation

– garantiert Interoperabilität

• Common Object Services

– allg. Funktionen zum Erstellen u. Unterhalten von

Objekten

ApplicationObjects

CommonFacilities

Common Object Services

ORB



ORB Aufgabe

Einbettung von Objekt-Implementationen ("Server-Objekte")

Vergabe von Objektreferenzen

Entgegennehmen von Aufrufen vom Client

Transport der Aufrufe zum Server

ggf. Aktivierung eines Server-Objektes

Übergabe des Aufrufs zum Server-Objekt

Entgegennehmen von Ergebnissen und Transport / Rückgabe zum Client

Unterstützung von Sicherheits- und Abrechnungsfunktionen

ApplicationObjects

CommonFacilities


ORB



CORBA Protokolle: GIOP und IIOP

• Mit CORBA 2.0 wurde GIOP = General Inter-Orb Protocol als netzwerkunabhängiges Wire Protocol spezifiziert

• Die (meist verwendete) TCP/IP-Variante heißt IIOP = Internet Inter-Orb Protocol

• GIOP spezifiziert

– Nachrichtentypen (Requests, Resultate, Ping, ...)

– Datenaustauschformat ("Common Data Representation")

– Interoperable Objektreferenzen (IORs)

– Service-Kontexte (Request-Anhängsel, mit denen Dienste

transparent Informationen übermitteln können)



Aufbau eines CORBA Servers

• POA (Portable Objekt Adapter) dient als zentrale Zugriffsschnittstelle auf Objektimplementierungen

– erzeugt eindeutige

Objektreferenzen

– hat Objekt Map

– nimmt Requests für

Objekte vom ORB

entgegen

Netzwerk

ORB-Kern

EventLoop

MarshallingEngine

Request Interceptorsfür verschiedene

Services (optional)

ORB-Schnittstelle

Portable Object AdapterFabrik für

Objektreferenzen

1 2 ... ... n ...

Active ObjectMap

DefaultServant

ServantActivator

Applikationscode

main (String args[]) { ORB orb = ORB.init(args); orb.connect ( new AServant() ); orb.connect( new BServant() ); orb.run();}

main (String args[]) { ORB orb = ORB.init(args); orb.connect ( new AServant() ); orb.connect( new BServant() ); orb.run();}

Haupt-programm

ServantActivator

ii

DefaultServant

aktive Servants

statisch(mit Skeleton)

...

dynamisch(ohne Skeleton)



Ablauf eines Methodenaufrufs

ClientAnwendung

IDL Stub IDL Skeletton

Object Adapter

ObjektImplementierung

ImplementationRepository

1) Aufruf

2) Parameter einpackenund Aufruf weiterleiten

4a) Ermitteln derImplementierung

4b) Aktivieren5) Auspacken undAufruf

4) Weiterleiten anSchnittstelle

Object Request Broker Core

3) Transport über den ORB mit GIOP (IIOP)



Object Services

Object Services NamingEventSecurityTransactionsTradingLifecycleTime

(= Systemfunktionen)LicensingPropertiesRelationshipsNotificationPersistenceConcurrency ControlExternalisation

Nur Spezifikation der Schnittstellen und grundlegender Funktionsprinzipien!

Nur Spezifikation der Schnittstellen und grundlegender Funktionsprinzipien!

ApplicationObjects

CommonFacilities


ORB



Common Facilities

• Höherwertige Dienste für ein breites Spektrum an Anwendungsbereichen

• Bereitstellung allgemein interessanter Funktionalität(analog zu großen Klassenbibliotheken)

• Horizontale Common Facilities (Basisfunktionalität allgemein)

– User Interface

– Information Management (Speicherung komplexer Strukturen, Formatkonvertierung)

– Task Management (Workflow, lange Transaktionen)

– Internationalisierung („Sprachenübersetzung“)

• Vertikale Common Facilities (Basisfunktionalität speziell)

– für Marktsegemente, z.B. Banken, Gesundheitswesen, Finanzdienste

– vgl. „application frameworks“, „business objects“

ApplicationObjects

CommonFacilities


ORB

Application Objects(Business Objekte)

• Business-Objekte (M, Server)

– kapseln Speicher, Metadaten, Parallelität u. Regeln

einer aktiven Business-Einheit

– legt fest, wie auf Änderungen in View/Modell

reagiert wird

• Business-Prozeßobjekte (C, Server)

– kapseln Business-Logik

– Verwaltung vorwiegend langlebiger Prozesse

(Workflow, Transaktion)

• Präsentationsobjekte (V, Client)

– grafische Darstellung des Objektes

– unterschiedliche Präsentationen möglichAndere

Business-Objekte Dokument Server

Business-Objekt

Business-Prozeß-Objekt

Präsentations-Objekt

Komponenten eines Business-

Objektes

Andere Schnittstellen

MVCMVCMVCMVC

ApplicationObjects

CommonFacilities


ORB



IDL (Interface Definition Language)

• Basismechanismus zur Definition von Schnittstellen (Standard)

• Unabhängig von spezieller Sprache (dekla-rativ, d.h. ohne algorithmische Teile, d.h. ohne Implementierungsdetails)

• Sprachbindung für verschiedene Sprachen

• IDL-Grammatik ist Teilmenge von C++; zusätzlich Mittel für Verteilungskonzepte

• Beinhaltet Mehrfachvererbung

• Schnittstellenverzeichnis (Interface Repository), damit selbstbeschreibend

• IDL ist Kontrakt, der alle und alles zusammenbringt

C

C++

Smalltalk

Ada

COBOL

Java

IDL

IDL

IDL

IDL

IDL

IDL

ORB



Beispiel für eine IDL Datei (1)module Bank {

typedef sequence<string> StringArray;struct Person {

string name;string vorname;

};// hier fehlt noch exception Definitioninterface Konto {

readonly attribute float kontostand;readonly attribute long geheimzahl;readonly attribute long kontonummer;

void einzahlen(in float betrag);void abheben(in float betrag);void unlock(); // Sperre freigeben

};// hier geht es weiter mit dem KontoManager

};



Beispiel IDL Datei (2)module Bank {

typedef sequence<string> StringArray;struct Person {

string name;string vorname;

};exception KontoException {

string begruendung;};// hier war interface Konto definiertinterface KontoManager {

Konto anmelden(in long kontonr, in long geheimzahl)raises (KontoException);

Konto oeffnen(in Person daten);void aufloesen(in Konto konto);StringArray holeKontenInfos();

};};



Feature der IDL (1)

• Mehrere Interface Beschreibungen können in einer Modulbeschreibung zusammengefasst werden

• Es gibt die von anderen Sprachen bekannten Standardtypen (Gleitkomma, Integer, Zeichen-, bool, Byte und deren Subtypen)

• Es gibt Konstrukte zum Aufbau von struct's und union's

• Template Typen sequence und string sowie Arrays

• Neue Typen können mit typedef deklariert werden

• interface Definitionen entsprechen neu definierten Objekttypen (Klassen)

• Es gibt den Begriff Attribut mit name() und name(value) Zugriffsfunktionen



Feature der IDL (2)

• Es gibt Enumerations (Aufzählungstypen)

• Man kann Konstanten deklarieren

• Weiter gibt es Exception Deklarationen für Ausnahmezustände

• Parameter von Methoden lassen sich als in, out oder inout Parameter definieren

• Weiter gibt es die Möglichkeit Methoden als vom Typ oneway (d.h. kein Returnwert erwartet) zu deklarieren, was eine nicht-blockierende Bearbeitung bedeutet (der Client wartet hier nicht auf den Server)

Ablauf einer CORBA Entwicklung

IDL-C++Compiler

IDL-C++Compiler

Schnittstellendesigner

interfaces.idlinterfaces.idl

types.hhtypes.hh stubs.ccstubs.cc skels.ccskels.cc

Programmierer

servants.ccservants.cc

Server

IDL-JavaCompiler

IDL-JavaCompiler

stubs.jarstubs.jar

Anwendungsentwickler

client.jarclient.jar

Client



RMI-IIOP

Corba Objekte mit RMI



Beispiel-Interface

• Ganz normales RMI Interface

//HelloInterface.javaimport java.rmi.Remote;

public interface HelloInterface extends java.rmi.Remote { public void sayHello( String from )

throws java.rmi.RemoteException;}



Implementierung des Interfaces

• Leitet von PortableRemoteObject ab!

//HelloImpl.javaimport javax.rmi.PortableRemoteObject;

public class HelloImpl extends PortableRemoteObject implements HelloInterface {

public HelloImpl() throws java.rmi.RemoteException { super(); // invoke rmi linking and remote object initialization }

public void sayHello( String from ) throws java.rmi.RemoteException { System.out.println( "Hello from " + from + "!!" ); System.out.flush(); }}



RMI-IIOP Serverprogramm

//HelloServer.javaimport javax.naming.InitialContext;import javax.naming.Context;

public class HelloServer { public static void main(String[] args) { try {

HelloImpl helloRef = new HelloImpl();

// Step 2: Publish the reference using JNDI API Context initialNamingContext = new InitialContext(); initialNamingContext.rebind("HelloService", helloRef );

} catch (Exception e) { e.printStackTrace(); } }}



RMI-IIOP Clientprogramm

public class HelloClient { public static void main( String args[] ) { Context ic; Object objref; HelloInterface hi;

try { ic = new InitialContext(); hi = (HelloInterface)ic.lookup("HelloService");

hi.sayHello( " MARS " );

} catch( Exception e ) {} }}



Aufruf RMI-IIOP Beispiel

// start des Nameserversstart orbd -ORBInitialPort 1050

// start des Serversjava -classpath . -Djava.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory -Djava.naming.provider.url=iiop://localhost:1050 HelloServer

// start des Clients java -classpath . -Djava.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory -Djava.naming.provider.url=iiop://localhost:1050 HelloClient



Was ist InitialContext()?

• Zugriff auf einen initialen Namenskontext (Context) eines Namensdienstes über die JNDI-API

– Java Native Directory Interface (JNDI)

• Ein JNDI Namenskontext ist eine Menge von JNDI-Namen-zu-Objekt Mappings

– Jeder Kontext kann weitere Kontexte enthalten

(Hierarchische Struktur von Kontexten möglich)



Context Interface

javax.naming.Context

void bind(Name name, Object object) void bind(String name, Object object) …Context createSubContext(Name name)Context createSubContext(String name)…Object lookup(Name name)Object lookup(String name)

void rebind(Name name, Object object)void rebind(String name, Object object)

…



Wie bekomme ich initialen Context?

• Factory-Klasse definiert "Art des Namensdienstes", auf den zugegriffen werden soll

• PROVIDER_URL die URL zum Zugriff

Context ctx = new InitialContext()// falls INITIAL_CONTEXT_FACTORY und PROVIDER_URL bereits definiert// z.B. durch Setzen von java.naming.* Properties

// oder

Hashtable env=new Hashtable();env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.cosnaming.CNCtxFactory");env.put(Context.PROVIDER_URL, "iiop://localhost:1050");

Context ctx=new InitialContext(env)



Zugriff auf JNDI-Namensdienste

• CORBA konformer Namensdienst

– Factory: com.sun.jndi.cosnaming.CNCtxFactory

– URL: iiop://localhost:1050

Context ctx = new InitialContext()

• LDAP Directory Server

– Factory: com.sun.jndi.ldap.LdapCtxFactory

– URL: ldap://localhost:389/o=MyOrg

DirContext ctx=new InitialDirContext()



RMI-IIOP / JNDI / EJB

• EJB (Enterprise Java Beans) können RMI-IIOP basierte entfernte Schnittstelle anbieten

• Zugriff von Clientseite erfolgt dabei typischer Weise über JNDI

Context ctx = new InitialContext();

Object ref=ctx.lookup("Calculator/remote");

CalculatorRemote rechner=(CalculatorRemote)PortableRemoteObject.narrow(ref, CalculatorRemote.class);

System.out.println("2 + 5 =" + rechner.add(2,5));



Namens- und Verzeichnisdienste



Namensdienst

• Ein Namensdienst (Naming Service) bildet Namen auf Zugriffsinformationen (Adressen) zum Zugriff auf Ressourcen ab

– Den Vorgang der Zuordnung eines Namens zur Zugriffsinformation

nennt man Binden (bind)

P

lookup("name")

Adresse /Zugriffsinform.

Resource

bind (Name, Zugriffsinf.)

Adresse /Zugriffsinform.

Zugriff auf Resource



Warum Namensdienste

• Entkoppelung des Zugriffs auf eine Resource von den Adressierungsdetails

– erhöht die Konfigurierbarkeit (Adressdetails nicht hardcodiert in

Client)

– schafft Ortstransparenz – d.h. Resourcen können relokiert

werden

– ermöglicht Lastverteilung

– Es können administrative Entscheidungen zum Resource-

Management getroffen werden, ohne die Clients neu

compilieren zu müssen



Was ist ein Name

• Namen können verschiedene äquivalente Formen haben

– Im Programmierkontext häufig strukturierte Objekte,

• i.e. Array von NamingComponent Objekten in Corba oder

CompoundName, CompositeName in JNDI

– lassen sich typischer Weise äquivalent auch durch Strings

beschreiben, z.B. als

"cn=HomeDir,cn=John,ou=Marketing,ou=East" oder

"ejb/Calculator/Remote" oder [email protected]

• Benötigen zur Interpretation einen Kontext, in dem die Namensauflösung stattfindet



Was ist die Adresse (Zugriffsinformation)

• definiert alle für den Zugriff auf die Resource notwendigen Informationen

• Je nach Kontext und Anwendungssituation nahezu beliebig

– Kann physikalische Adresse sein: IP-Adresse

– Kann Name bzgl. eines anderen Namensdienstes oder Auflösungssystem sein

– Oder Kombination von beiden

– Oder Objektreferenz

• In objektorientierten Systemen häufig wieder in Form von Objekten gekapselt

– z.B. DataSource-Objekte zum Zugriff auf Datenbanken

– Oder entfernte Objektreferenz oder direkt serialisiertes Proxyobjekt



Kontext

• Der Kontext eines Namensdienstes definiert bzw. enthält

– Die Menge der erlaubten Namen (Namensraum)

– Die Menge der Bindings, die Namen an zugehörige

Resourcen bindet

• Er hat typischer Weise wieder einen Namen

– und kann als Resource innerhalb eines

übergeordneten Kontextes beschrieben sein



Hierarchische Kontexte

• Namen können hierarchisch strukturiert sein

• Jede Teilkomponente des Namens wird über eigenen Kontext aufgelöst

• Kontexte können mit gleichen Namensräumen oder vollständig unterschiedlichen Namensräumen arbeiten

Kontext "Root oder InitialContext"

Kontext "Kunde"

Kontext "Privatkunde" Kontext "Geschäftskunde"

zugehöriger Name:

Kunde/Privatkunde/"Peter Meier"



Zusammenspiel mehrerer Namensdienste (Federation)

• Namen können als zusammengesetzte Namen Komponenten haben, die über verschiedene Namensräume definiert sind

• Zur Auflösung müssen verschiedene Dienste oder Kontext-Provider zusammenspielen (Federation)

DNS-Service

Benutzerverwaltung

zugehöriger Name:

[email protected]

Nutzername Domainname



Beispiele für Namensdienste / -räume

• DNS (Domain Name Service)-Dienst

– mailhost.iai.fzk.de

• User-Namen-, Gruppennamenauflösung in Rechnern

– typischer Weise über Verzeichnisdienste, siehe später, wie

YP, NIS oder LDAP

• Email-Adressen

– mailto:[email protected]

• RPC-registry, RMI-registry, CORBA-Namensdienst

– rmi://servername/objektname



Verzeichnisdienste

• Ein Verzeichnisdienst ist ein Namensdienst, der

– Resourcen neben den physikalischen Adressen weitere beschreibende Metadaten zuordnet

– oder auch nur beschreibende Metadaten für eine Resource bereitstellt (Metadatendienst oder Metaverzeichnis)



Typische Verzeichnisdienste

• YP (Yellow Page)-Dienst, NIS (Network Informationsdienst) für Betriebssysteme

– lösen Anfragen nach Rechnern, Usern, Zugriffsrechten, Druckern,

Netzwerkdateisystemen, etc. auf

• LDAP (Leigweight Directory Service Access Protocol) Services

– dieselben Informationen wir bei YP, NIS

– darüberhinaus Organisationsdaten

• Organsiation, Unterorganisation, Mitarbeiter inklusiver Telefonnummer,

etc.

– beliebige weitere Objekte, insbesondere häufig als Verzeichnisdienst

für entfernte Objekte, Datenbankresourcen, etc. eingesetzt

• UDDI-Verzeichnisse für Web-Services



Beispiel LDAP-Server

• Lightweight Directory Access Protocol (LDAP)

• Spezifiziert in RFC 2251

• Protokoll zum Zugriff auf Verzeichnisdienste, die auf Basis von OSI X.500 arbeiten (ASN.1 codierte Daten)

• Namensbeschreibung hierarchisch in der Gestalt "cn=HomeDir,cn=John,ou=Marketing,ou=East"

• Unter Namen können beliebige LDAP-Objekte (beschrieben durch Attributname-Value Paare) gespeichert werden

– flexibles Typsystem erlaubt hier beliebige Typen für Attribute

– eigene Erweiterungen der Schema für LDAP-Objektklassen über Schemabeschreibungssprache möglich

• Definiert Security-Interfaces, etc und weitere Infrastrukturdienste



binäres Bild



Review – Was ist JNDI?

• Universelle Client-seitige Java-Schnittstelle zum Zugriff auf Namensdienste

– unterstützt alle möglichen Arten

– u.a. DNS, etc.

– LDAP-Verzeichnisdienste

– Namens- und Verzeichnisdienste von Business-Obektservern

• besitzt eine Art von Treiberschnittstelle zum Zugriff auf konkrete Dienste

– siehe Folie: wie bekomme ich einen Initial-Kontext



Zentrale Schnittstelle: Context Interface

javax.naming.Context

void bind(Name name, Object object) void bind(String name, Object object) …Context createSubContext(Name name)Context createSubContext(String name)…Object lookup(Name name)Object lookup(String name)

void rebind(Name name, Object object)void rebind(String name, Object object)

…



Wie bekomme ich nochmal einen Root-Kontext?

• Factory-Klasse definiert "Art des Namensdienstes", auf den zugegriffen werden soll

• PROVIDER_URL die URL zum Zugriff

Context ctx = new InitialContext()// falls INITIAL_CONTEXT_FACTORY und PROVIDER_URL bereits definiert// z.B. durch Setzen von java.naming.* Properties

// oder

Hashtable env=new Hashtable();env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.cosnaming.CNCtxFactory");env.put(Context.PROVIDER_URL, "iiop://localhost:1050");

Context ctx=new InitialContext(env)



Und wie frage ich eine Resource ab?

• JNDI-Verzeichnisse können (je nach Art) eine Vielzahl von Resourcen zurückliefern

• Datenbanken stellen solche Resourcen da

• Man kann den Zugriff auf eine Datenbank durch DataSource-Objekte kapseln (Verbindungsdetails)

• Und diese in Verzeichnissen bereitstellen


DataSource ds= (DataSource)ctx.lookup("jdbc/mondialDB");

Connection con = ds.getConnection();



Und wie war das nochmal mit Entfernten Objekten?

• EJB (Enterprise Java Beans) können RMI-IIOP basierte entfernte Schnittstelle anbieten

• Zugriff von Clientseite erfolgt dabei typischer Weise über JNDI


CalculatorRemote rechner=(CalculatorRemote)ctx.lookup(" Calculator/remote ");

System.out.println("2 + 5 =" + rechner.add(2,5));



Zusammenfassung

• Namensdienste eignen sich herorragend dazu, um Resourcen von

ihren Clients zu entkoppeln

– Resourcen können logisch benannt werden

– Applikationen werden dadurch ortstransparent

– Mit Namensdiensten kann man Lastverteilung / Skalierbarkeit

erreichen

– Client muss Adressdetails nicht kennen und diese können

konfigurierbar gehalten werden

– Der Client wird von Implementierungsdetails entkoppelt

– Durch Anwendung des Proxy-Design-Patterns kann man Server-

seitige Resourcemanagement Funktionalitäten integrieren und

rekonfigurieren, ohne die Clients neu übersetzen zu müssen

Forschungszentrum Karlsruhe Technik und Umwelt Clemens Düpmeier, 27.03.2015 Verteilte Kommunikation oberhalb der Socket-API Datencodierung, Remote Procedure.

Documents