Anforderungen aus der Sicht eines -Applikationsentwicklers ...eris.prakinf.tu-ilmenau.de/edu/va/folien/VL2.pdfvon X.500/ISO 9594, der die Suche von Ressourcen außerhalb einer lokalen

78�� 78��

Anforderungen aus der Sicht eines- Applikationsentwicklers -

Netzwerkunterstützung

Leistungsfähigkeitund Geschwindigkeit

hohe Verfügbarkeit undParallelität

• bietet Dienst an einerdefinierten Schnittstelleinnerhalb einesNetzwerkes an

• nimmt Anforderungenentgegen und bearbeitet diese

• terminiert nicht undkann gleichzeitig mehrere Anforderungenbearbeiten

Robustheit• behandelt auftretende

Laufzeitfehler

• kennt die definierte Schnittstelle im Netz und nutzt den Dienst

• setzt Anforderungenab und wartet aufAntwort

• terminiert im allgemeinen nachendlicher Zeit

• behandelt auftretendeLaufzeitfehler

Client Server

7�� 7��

Probleme der Applikationsentwickler

VA zeichnen sich durch sehr hohe Komplexität aus:

• Systemumfang

• Heterogene Teilsysteme

• Kommunikation über das Netzwerk- Ausfall des Netzes

- Fehler bei der Übertragung

- Adressierung

8�� 8��

Anforderungen an verteilte Anwendungen

• Transparenz für Anwender

• Skalierbarkeit

• Offenheit

• Interoperabilität

• Hindernisse dafür:• Systemumfang

• Parallelität

� Fehlerbehandlung

� Datenschutz und Datensicherheit

� Administration

8�� 8��

Mittel zur Lösung Netzwerktransparenz

Die Kommunikation über das Netzwerk birgt Probleme, von denen abstrahiert werden soll:

• Fehleranfälligkeit:– Erkennung, Übertragungswiederholung, Reihenfolgegenauigkeit etc.� TCP

• Ortstransparenz (Adressauflösung)– Host-/ Prozessadresse dynamisch auflösen, Migration und Replikation erlauben � Namens- und Lokalisierungsdienste

• Zugriffstransparenz– Programmierung als wären alle Prozesse lokal und gäbe es keine örtliche Trennung � lokale Proxy-/ Surrogatobjekte

8�� 8��

Mittel zur LösungInteroperabilität, Kommunikation

• Interoperabilität: Verbindung heterogener Einzelsysteme bedarf:– Standardisierter Protokolle

– Externer Datendarstellung (XDR, CDR)

– Normierter Schnittstellen

• Kommunikationsmechanismen:– IPC

– RPC

– RMI

8�� 8��

RemoteProcedureCall (RPC)

• Erweiterung des Prozeduraufruf-Mechanismus von Einzel-Rechnern auf verteilte Bearbeitungsumgebungen

• Transparente Verteilung und Ausführung eines Programms (Verteilung „nicht sichtbar“ im Code des Anwendungsprogrammes)

• Für den Programmierer ist nur ein geringer Anteil von Netzprogrammierung erforderlich.

• Im Vordergrund steht die Gestaltung der Client/Server-Anwendung.

• Der Client ruft eine Prozedur auf, die der Server auf einem entfernten System bereitstellt.

8�� 8��

RemoteProcedureCall (RPC)

• „Einkleidung“ (Kapselung) von Client-Requests in einfache (entfernte) Prozeduraufrufe

• Der Server bietet ein oder mehrere Interface(s) für die Anforderung seiner Dienste (in Form von entfernten Prozeduraufrufen) an.

• Das Client-Programm benötigt keine Kenntnis über die Implementierung und Lokation des entsprechenden Server-Interface.

• Unterstützung durch RPC-Laufzeitsystem, welches zusätzlich– die Umwandlung/Übersetzung von auszutauschenden Parametern zwischen

verteilten (heterogenen) Komponenten übernimmt,

– Transferdienstbesonderheiten vor der Anwendung verdeckt (z.B. Timeouts und Retransmission)

– U.U. weitere Dienste anbietet

8�� 8��

RPC-Anwendungsentwicklung

• Die RPC-Anwendungsentwicklung orientiert sich am Client/Server-Modell.

• Der Programmierer erhält Unterstützung durch das RPC-Entwicklungs-und Laufzeitsystem.

• Generell:– Erzeugung eines netzweiten eindeutigen Identifikators zum Zugriff des

Prozeduraufrufers (Client) auf den Prozeduranbieter (Server)– Beschreibung des Interface‘ und seiner verfügbaren Operationen

(Prozeduren)� Steht das RPC-Entwicklungs- und Laufzeitsystem zur Verfügung, so sind

alle Kommunikationsbelange für den Anwendungsentwickler erledigt.� Programmierung der Anwendung:

Client: „Haupt“ -Programm mit ProzeduraufrufServer: Prozedur

8�� 8��

Architektur des RPC‘s: lokal und verteilt

Single Process

Client Procedures

Interface

Call

Return

Client

Client Stub

Client Process

CallReturn

RPC RuntimeLibrary

Manager

Server Stub

Server Process

ReturnCall

RPC RuntimeLibraryNetwork Messages

Interface

87�� 87��

RPC-Laufzeitprozeß

Client-Stub

Client-Routinen

RPC-Laufzeitsystem

(1)

(2) (9)

(10)

Server-Stub

Server-Routinen

RPC-Laufzeitsystem

(6)

(7) (4)

(5)

(3)

(8)

88�� 88��

RPC-EntwicklungsprozeßRPC-Spezifikationsdatei

RPC-Generator/Compiler

Client-Routinen

Server-Routinen

Server-StubHeaderClient-Stub

Header HeaderClient-Stub Server-Stub

Compiler Compiler

Client-Objektdateien

Server-Objektdateien

Client-Stub(Objekt)

Server-Stub(Objekt)

RPC-Bibliothek

RPC-Bibliothek

Linker Linker

Client Server

8�� 8��

Spezielle Probleme bei verteilten AnwendungenWelche Aufgaben sind generell zu erledigen?

• Systemumfang– Programmier- und Modularisierungstechniken

• Parallelität und Nicht-Determinismus– Synchronisationsmechanismen

• Heterogenität– Befehlssätze, Datendarstellungen, Betriebsysteme, Programmiersprachen,

Kommunikationsprotokolle

• Datenschutz und Datensicherheit– Zugriff, Manipulation, Verlust

• Verwaltung verteilter Anwendungen (Dienste)– Registrierungs- und Verzeichnisdienste

• Fehlerbehandlung– Kompensation von Ausfällen durch Redundanz

• Systemadministration– Werkzeugunterstützung

��

DCE - Distributed Computing Environment“ Die Mutter aller Middleware“

• Open Software Foundation (OSF) + X/OPEN Company Ltd. � The Open Group (Februar 1996)

• Services und Tools zur Unterstützung, Nutzung und Wartung verteilter Anwendungen in einer heterogenen Rechnerumgebung

� Kohärente High-Level-Umgebung, die Heterogenität der Rechnerumgebung und Netzwerke für Anwender und Programmierer verdeckt

• Portabilität und Interoperabilität

(Umsetzungen für zahlreiche Plattformen)

� Vereinfachung der Entwicklung und des Managements verteilter Anwendungen durch in DCE integrierte Dienste

� Data Sharing zwischen allen Nutzern

� Zugang zu globalem „Computing Environment“ : Anspruch der Unterstützung von verteilten Objekten, Internet/Intranet- sowie Sicherheitskonzepten

� DCE-Funktionalität in aktuelle Betriebssysteme teilweise integriert.

��

Mechanismen zur Verteilung von Anwendungen

• Client/Server-Modell– RemoteProcedureCall (RPC)

– Data-Sharing-Modell (DSM)

� RPC– Der Client führt eine Aktion aus, die lokal wie ein Prozeduraufruf erscheint.

– Umsetzung in Netzwerkkommunikation

– Ausführung der Prozedur beim Server und Rückgabe der Ergebnisse

� DSM– Verteilung der Daten vom Datenserver nach Anforderung durch den Client

– Der Server muß den parallelen Zugriff auf Daten synchronisieren.

��

DCE-Architektur

Anwendungen

DCE DisklessSupport Service

ZukünftigeDienste

DCE Distributed File Service

DCEDistributed

Time Service

DCEDirectoryService

ZukünftigeDienste

DCE RemoteProcedureCall

DCE Threads

DCESecurityService

Management

Betriebssystem und Transferdienste

��

DCE-Struktur

Organisation der verteilten Umgebung• DCE-Cell: Gruppe von Rechnern, die als Einheit verwaltet werden• DCE-Environment: eine DCE-Cell oder eine Gruppe von mehreren

DCE-Cells, die miteinander kommunizieren können� Eine DCE-Cell wird Teil einer DCE-Environment, wenn sie Zugang zu

mindestens einem globalen Directory Service erhält.� Eine DCE-Cell muß folgende DCE-Dienste enthalten:

– Cell Directory Server– Security Server– Distributed Time Server

� Zur Basis-Konfiguration einer DCE-Cell gehören:– DCE-Nutzer-Maschinen– DCE-Administrator-Maschinen– DCE-Server-Maschinen

��

Einfache DCE-Cell

Administratorund Nutzer

Nutzer Nutzer

Nutzer

DCE Time Server

DCEDirectory Server

Nutzer

DCESecurity Server

Netzwerk

��

DCE Namensraum

• hierarchischer Aufbau/ . . . Global Root

/ . . . / X.500-Namensraum

/ . . . / DNS-Namensraum

X.500: / . . . / C=Country/ O=Organization/ OU=Organization Unit

/ . . . / C=US/ O=OSF/ OU=DCE/ sec/ pr i nci pal s/ al f

DNS:

/ . . . / pr aki nf . t u- i l menau. de/ f s/ usr / al f

• Unterscheidung der Namen in den Zellen

/ → Cell Directory Service lokaler Name

/ . . . → Global Directory Agent globaler Name

��

DCE Namensraum (Beispiel)

/ . . .

C=US

O=OSF

OU=DCE

pr aki nf . t u- i l menau. deC=DE

O=TUI

OU=Pr akI nf

pr aki nf . t u- i l menau. de

sec f s subsys Cel l Pr of i l e host s

�7�� 7��

DCE-Technologie-Komponenten

Verteilte Programmierung Verteilte Dienste

DCE RPC

DCE Threads

DCE Directory Service

DCE Distributed Time Service

DCE Security Service


( DCE Diskless Support Service )

�8�� 8��

DCE Directory Service

grundlegender Dienst zur Verwaltung von (dynamisch) verteilten Ressourcen im Netz mit drei Komponenten:

• Cell Directory Service: Verwalten von Namen und Attributen von Ressourcen (Servern) der lokalen DCE-Cell

– Mindestens ein Cell Directory Server muß pro Zelle verfügbar sein.

• Global Directory Service: verteilter, replizierter Directory Service auf der Basis von X.500/ISO 9594, der die Suche von Ressourcen außerhalb einer lokalen DCE-Cell ermöglicht;auch Interaktion mit dem Domain Name System (DNS) möglich

– Damit soll die Suche in anderen Zellen sowie die Interaktion zwischen Client und Server unterschiedlicher Zellen möglich sein.

• Global Directory Agent: Vermittler zwischen dem Cell Directory Service einer DCE-Cell und dem Rest der Welt

– Namen, die nicht in dem Cell Directory Service einer Zelle gefunden werden, übergibt der Global Directory Agent einem entfernten Global Directory Server oder einem DNS-Server.

��

Directory-Service-Struktur

GlobalDirectoryService

Cell DirectoryService

GlobalDirectory

Agent

Cell A

Cell DirectoryService

GlobalDirectory

Agent

Cell B

Der Zugriff auf den Directory Service erfolgt für den Programmierer über das X/Open Directory Service Interface (API).

��

DCE Cell Directory Service (Komponenten)

CellDirectoryServiceClerk

Host A


Host B

Network


Host Y

CellDirectory

Server

Clearinghouse

CDSNamespace

Browser

CDSControlProgram

DirectoryEntries

Directories

��

DCE Global Directory Service (Komponenten)

Application

X/Open DirectoryService API

DirectoryUser Agent

DirectorySystem Agent

GDSDB

DirectorySystem Agent

GDSDB

GDS Client

GDS Server

GDS Server

DirectoryAccess

Protocol

DirectorySystemProtocol

DirectoryUser Agent

Cache

��

DCE Distributed Time Service

• Synchronisation der Systemuhren in den Netzwerkknoten des verteilten Systems

• Komponenten:– Time Clerk: Client-Seite des Distributed Time Service‘ ; veranlaßt die

Synchronisierung

– Time Server Synchronisation• Local Time Server

• Global Time Server

• Courier Time Server

• Backup Courier Time Server

– Distributed Time Service API

– Time Provider Interface (zu externen Quellen)

– Time Format

• auch Interaktion mit den Server-Komponenten für das Network Time Protocol möglich

Wenn Courier TimeService nicht verfügbar

��

Distributed-Time-Service-Struktur

TimeClerk

LocalTimeServer

LocalTimeServer

CourierTimeServer

TimeClerk

GlobalTimeServer

TimeClerk

LocalTimeServer

LocalTimeServer

CourierTimeServer

TimeClerk

LAN ALAN B

��

DCE Security Service

• Zugriffskontrolle auf Ressourcen in verteilter Umgebung

• Komponenten:– Authentication Service

netzwerkweite Identitätsvergabe und Überwachung

– Privilege ServiceZugriffsrechte auf Dienste; Überprüfung, ob Nutzer (in Authentication Service vermerkt) autorisiert ist auf Dienste zuzugreifen

– Registry ServiceVerwaltung der Security Service DatabaseDie Datenbank enthält für jeden zu überwachenden Nutzer oder Dienst einen Eintrag, genannt principal.

– Access Control List FacilityListe der Nutzer, die auf eine Ressource, zu der die Access Control List gehört, zugreifen dürfen

– Login Facilityinitialisiert die DCE Security Environment eines Nutzers(Password-Vergabeund Authentication)

��

Security Interactions

Administrator

SecurityDB

RegistryServer

AuthenticationServer

PrivilegeServer

Security Server

User

WithPrivilegeAttributeCertificate

WithTicket

CreateUser

Login

Ticket

Authorize Me

Privilege Attribut

Certificat (PAC)

ApplicationClient

Start Client

ApplicationServer

With PAC

AuthenticatedRPC (API)

Access Control List

sp_data_acl

/.../C=DE/O=...

user:alf:rw

��


• gemeinsame Nutzung von Informationen in einem sehr großen (weltweiten) System mit effizienter Nutzung spezieller Verwaltungsfunktionalität

• Verwaltung der Informationen in Form eines File Systems

• Unterteilung von kleinster bis zur größten Organisationseinheit- Files und Directories

• Directoriesorganisieren Files und weitere Directories in hierarchischer Form.

- File Sets• Verwaltungseinheit, die einen Unterbaum von Files und Directories darstellt (einer

Disk oder Partition einer Disk)

- Aggregates• eine Einheit des Disk-Speichers, die aus einem oder mehreren File Sets besteht

��7�� 7��

Einige Distributed-File-Service-Komponenten

• Cache Manager– agiert als Client

– Bei der Anforderung eines Files schaut der Manager in einen Cache um zu sehen, ob sich das File schon im lokalen System befindet. Wenn nicht, veranlaßt er ein Request zum File Server und „cached“ die entsprechende Datei.

• File Exporter– agiert als Server

– Der File Exporter bedient Requests auf sein lokales File System.

• DCE Local File System– verwaltet physikalisches File System analog zu Unix File System

• Token Manager– synchronisiert den Zugriff von mehreren Clients auf Files

• ...

��8�� 8��

DCE RemoteProcedureCall (RPC)

• (Bekanntes) Modell zur Implementierung von Client/Server-Architekturen

• Interaktion zwischen Client und Server durch Aufruf einer entfernten Prozedur (wie eine lokale Prozedur)

– Definition eines Interfaces und einer Prozedur, die dieses Interface implementiert

– Aufruf der Prozedur mit Argumenten

– Rückgabe von Ergebniswerten

• einheitlich für unterschiedliche Hardware, Betriebssysteme, Transportschicht-Protokolle und Programmiersprachen

– Fragmentierung und Reassemblierung von Nachrichten

– Behandlung unterschiedlicher Datenformate

– Nutzung des Directory Service

– Nutzung des Security Service

��

DCE-RPC-Komponenten

• Interface Definition Language (IDL) und IDL Compiler– Beschreibung eines Interfaces in IDL und dessen Übersetzung in eine Zielsprache für Client

und Server

• Universal Unique Identifier (UUID) Generator– Erzeugung eines global eindeutigen Namens für Interfaces und andere Ressourcen

• RPC Runtime Library– client- und server-seitigeFunktionalität für die Kommunikation

• RPC Daemon– RPC-spezifischer Name Service auf jeder Server-Maschine

• Name Service Independent API– Kontrolle des Bindings durch den Programmierer

• Authenticated RPC– Integration des DCE Security Service

• RPC Control Program– Administration des RPC Daemon und Zugriff auf den Cell Directory Service

��

Anwendungsentwicklung

UUID Generator Editor

IDL File

ClientStub Header

IDL Compiler

Client File

Editor

C-Compiler

RPCLibrary

Linker

Client

Header

ServerStub

ClientStub

ClientObject

Server Files

Editor

C-Compiler

RPCLibrary

Linker

Server

Header

ServerStub

ServerObjects

��

Implementierung des DCE-RPC´s

[ uui d( ) ]

i nt er f ace name {conststypedefsprocedures

}

IDL

Client Stub Header File Server Stub

RPC Runtime Client Appl. Server Appl. RPC Runtime

Erzeugung desIDL-Rahmens mitUUID-Kennung

Definition desInterfaces in IDL

Link Link

Client Server

IDL Compiler

Programmierungder Anwendung

��

A Simple Interface Definition

/* FILE NAME: arithmetic.idl *//* This Interface Definition Language file represents *//* a basic procedure that remote procedure call can use */[uui d( C985A380- 255B- 11C9- A50B- 08002B0ECEF1) ,ver si on( 1. 0)]i nt er f ace ar i t hmet i c /* interface name */{

const l ong ARRAY_SI ZE = 10;

t ypedef l ong l ong_ar r ay[ ARRAY_SI ZE] ;

voi d sum_ar r ays([ i n] l ong_ar r ay a, [ i n] l ong_ar r ay b,[ out ] l ong_ar r ay c

) ;}

��

RPC-Runtime-Prozeß

Client

2. AufrufProzedur

15. EntgegennahmeErgebnis

Client Stub 4. VerpackenAufruf nachRPC-Protokoll

3. FindenServer über CDSund RPC-Daemon

14. EntpackenDaten nachRPC-Protokoll

RPC Runtime

5. ÜbertragungDaten zuPartner-RPC-Runtime-Instanz

13. Warten undEntgegennahmevon Daten fürClient

Server 9. AusführenProzedur

8. ÜbernahmeProzeduranforderung

Server Stub 11. VerpackenErgebnis nachRPC-Protokoll

1. AnmeldenServer bei CDSund RPC-Daemon

7. EntpackenDaten nachRPC-Protokoll

RPC Runtime

12. ÜbertragungDaten zuPartner-RPC-Runtime-Instanz

6. Warten undEntgegennahmevon Daten fürServer

10. ÜbergabeErgebnis

��

Binding

Client

Knoten A

Knoten Z

Cell DirectoryServer

Knoten X

RPCDaemon

Port y

„Server?“

„Am Knoten X“

„Server?“

„AmPort y“

„Request“

Server

Anmelden

Server

Port *

* well known

��

Weiterentwicklung von DCEDCE 1.0 (1991) � DCE 1.1 (1994)

• Verbesserung und Weiterentwicklung der Tools und Technologie-Komponenten

• Verbesserung und Weiterentwicklung der Administration– entfernte Administration aller Services, Überwachung der Message-

Generierung und des Routings

– Hierarchisierung der Cells und Einführung von Cell-Aliasing

• Verbesserung der Sicherheit– Anzeigen von aufgetretenen Sicherheits-Ereignissen beim Administrator

– Extended Generic Security Service API, Extended Registry Attributes, Extended Registry Attributes, ACL Manager Library

• Internationalisierung aller Ausgaben für den Nutzer

• IDL Compiler mit kompakterem Code und Durchsatzoptimierung für RPC (Belastungsspitzen und breitbandige Übertragungsmedien)

• ...

��

Weiterentwicklung von DCEDCE 1.1 (1994) � DCE 1.2 (1996)

• IDL-Unterstützung für C++– z.B. Vererbung und Objektreferenzen

• Integration anderer Umgebungen– ONC Co-existence, Netware Co-existence (Filesystem)

• Verbesserungen am Administrationstool• Security

– Public Key Support (z.B. RSA), MIT Kerberos Version 5 Support, Global Groups, User-to-User Authentication, bessere Skalierbarkeit

• Distributed File System– Weiterentwicklung von Token Manager, Replikationen, Backup, ...– Einführung von Protected RPC, Multi-Home Support, 64-Bit Filesystem

Support

• ...

��7�� 7��

DCE-Zusammenfassung

• Kommunikation in DCE auf der Basis interagierender Prozesse

+ transparente Interoperabilität in heterogener Umgebung auf Basis von RPC

+ gute Skalierbarkeit durch das Cell-Konzept und die Implementierung einzelner Dienste, wie zum Beispiel Cell (Global) Directory Service

+ zahlreiche Werkzeuge und Dienste, beispielsweise ein konzeptionell ausgefeilter und umfangreich implementierter Security Service

+ indirekte Ortsunabhängigkeit durch Cell Directory Service

- DCE als praxisnahe Entwicklung nur bedingt an Standards orientiert

- bei der Programmierung recht starke Anlehnung an C und C++

� subjektiv: CORBA hat als eine wichtige Entwicklung im Bereich der standardisierten Plattformen für offene verteilte Systeme und Anwendungen eine größere Verbreitung gefunden. (Und Webservices sind bald einfach hipper…)

��8�� 8��

RemoteMethod Invocation (RMI)

• RemoteMethod Invocation dient der Realisierung verteilter Java-Applikationen, wobei die Methoden eines Java-Objektes von einer anderen virtuellen Maschine aus aufgerufen werden können.

– Abstraktion von den Sockets

– vergleichbar mit RemoteProcedureCall aber als RemoteMethodInvocation für die objektorientierte Programmierung spezialisiert

– speziell für die Java-Umgebung umgesetzt

��

RMI - Entwicklungsziele

• Vereinfachung der Entwicklung verteilter Applikationen

• Kommunikation zwischen Objekten innerhalb unterschiedlicher virtueller Maschinen

• Callbacksvon Server zu Applet

• Integration des Distributed Object Model in die Java-Umgebung

• Nutzung der Sicherheitskonzepte der Java-Laufzeitumgebung (SecurityManager, ClassLoader)

• verteiltes GarbageCollection

• unterschiedliche Referenz-Semantiken, zum Beispiel persistente Referenzen, Laufzeitreferenzen

• unterschiedliche Aufrufmechanismen, zum Beispiel ein Objekt auf einer bestimmten Maschine, replizierte Objekte auf mehreren Maschinen

• Unterstützung unterschiedlicher Transportprotokolle

��

RMI – Umsetzung

• Der Client einer Distributed Object Application arbeitet mit Referenzen auf entfernte Objekte.

• Ein Java-Programm kann die Referenz auf ein entferntes Objekt– über den bootstrap-naming servicevon RMI oder

– als Argument beziehungsweise Rückgabe eines Methodenaufrufes

� erhalten.

• Die Kommunikation zwischen Client und Server stellen Surrogat-Objekte (Stubs und Skeletons) sicher.

• RMI benutzt Object Serialization für das „Einpacken“ (Marshal) und die Übergabe bzw. das „Auspacken“ (Unmarshal) der Parameter.

��

Java Distributed Object Model

• Eine verteilte Applikation besteht aus Interfaces und Klassen. Die Interfaces definieren Methoden und die Klassen implementieren diese Methoden und gegebenenfalls weitere Methoden.

• Remote Object: Objekt, von dem Methoden aus einer anderen virtuellen Maschine heraus aufgerufen werden können

• Ein Objekt dieses Typs wird durch Remote Interfaces in Form von Java-Interfaces beschrieben. Diese Java-Interfaces definieren die entfernten Methoden des Objekts.

• RemoteMethod Invocation: Aufruf einer Methode eines entfernten Interface bereitgestellt durch ein entferntes Objekt

��

Java Distributed Object Model: Eigenschaften

• Die Referenz auf ein entferntes Objekt kann als Parameter oder Rückgabewert im Zusammenhang mit einer Methode auftauchen.

• Entfernte Objektewerden ausschließlich als Referenz übergeben.

• Andere Parameter und Rückgabewerte werden nicht als Referenz sondern als Wert (Kopie) übergeben.

• Auch bei verteilten Objekten können explizite Type Cast durchgeführt werden, vorausgesetzt die entsprechenden Interfaces werden durch die Implementierung unterstützt.

• Der i nst anceof -Operator kann verwendet werden, um die Schnittstellen eines entfernten Objektes zu prüfen.

• Clients interagieren nur mit den entfernten Interfaces, nicht mit der Implementierung.

• Einige Methoden der Klasse Obj ect sind für entfernte Objekte spezialisiert.

• Die Fehlerbehandlung stützt sich auf speziell erweiterte Exception-Klassen.

��

Java Distributed Object Model:Ausgewählte Interfaces und Klassen

• Packages: j ava. r mi und j ava. r mi . ser ver

Remote RemoteObject

RemoteServer

UnicastRemoteObject

IOException

RemoteException

Interface Klassen

Spezialisierung (extension)

Implementierung

...

... ...

��

RMI-System-Architektur

• Stubs und Skeltons: Abbildung der Objektreferenzen, Marshal

• Remote ReferenceLayer: Semantik der Methodenaufrufe, zum Beispiel ein Objekt oder mehrere Verbindungen, ständig laufender Server oder zu startender Server

• Transport Layer: Management der Verbindung

Client

Stub

RemoteReferenceLayer

Transport

Server

Skeleton

RemoteReferenceLayer

Transport

��

RMI: Entwicklungsprozeß

i. Design und Implementierung der verteilten Applikation- Definition des Remote Interface

- Implementierung der RemoteObject Class

- Implementierung des Client

ii. Übersetzen der Quellen (j avac) und Generieren von Stubs und Skeletons (r mi c)

iii. Start der Applikation inklusive Registry, Server und Client

��

Remote Interface

• Jedes Remote Interface erweitert das Interface j ava. r mi . Remot e.

• Jede entfernte Methode muß die Exceptionj ava. r mi . Remot eExcept i on im t hr ows-Statement deklarieren. Diese wird generiert, wenn der Aufruf einer entfernten Methode fehlschlägt.

• Jedes entfernte Objekt, das als Parameter oder Rückgabewert übergeben wird, muß als das Remote Interface deklariert werden, nicht als die Implementierungsklasse.

publ i c i nt er f ace Hel l o ext ends j ava. r mi . Remot e {

St r i ng sayHel l oTo( St r i ng me)t hr ows j ava. r mi . Remot eExcept i on;

}

��7�� 7��

Implementierung eines Interface

• Eine Klasse zur Implementierung eines Remote Interface erweitert in der Regel j ava. r mi . ser ver . Uni cast Remot eObj ect und erbt dabei von der Klasse j ava. r mi . ser ver . Remot eObj ect undj ava. r mi . ser ver . Remot eSer ver .

• Eine Klasse, die ein Remote Interface implementiert kann– mehrerer Interfaces implementieren und eine andere Klasse erweitern, die

ein Remote Interface implementiert,– Methoden implementieren, die nicht Bestandteil eines Remote Interface

sind (diese sind aber nur lokal verfügbar),– von einer anderen Klasse als RemoteObject abgeleitet werden, muß dann

aber für die Methoden hashCode, equal s und t oSt r i ng die entfernte Semantik implementieren.

��8�� 8��

Implementierung eines Interface: Beispiel

i mpor t j ava. r mi . Remot eExcept i on;i mpor t j ava. r mi . ser ver . Uni cast Remot eObj ect ;

publ i c c l ass Hel l oI mplext ends Uni cast Remot eObj ect i mpl ement s Hel l o {

publ i c Hel l oI mpl ( ) t hr ows Remot eExcept i on {super ( ) ;

}

publ i c St r i ng sayHel l oTo( St r i ng you)t hr ows Remot eExcept i on {

r et ur n( “ Hel l o “ + you + “ ! “ ) ;}. . .

}

��

Stubs, Parameterübergabe, Exception Handling und überschriebene Methoden

• Der Client kommuniziert mit dem Server-Stub (Proxy), der die gleichen Interfaces wie der zugehörige Server zur Verfügung stellt.

• Stubs werden über den r mi c - Compiler erzeugt.• Als Parameter oder Rückgabewerte kommen alle Werte

beziehungsweise Objekte in Frage, die serialisierbar sind. Darunter fallen alle Basis-Datentypen sowie Objekte, die das Interface j ava. i o. Ser i al i zabl e implementieren.

• Der Client muß entsprechende Vorkehrungen zum Abfangen der j ava. r mi . Remot eExcept i on treffen.

• Die Klasse j ava. r mi . ser ver . Remot eObj ect überschreibt die Methoden equal s, hashCode sowie t oSt r i ng von Obj ectund stellt eine Methode cl one (als Ersatz für das InterfaceCl oneabl e) zur Verfügung.

��

Lokalisierung von entfernten Objekten

• Eine entfernte Objektreferenz kann mit Hilfe von URL-basierten Methoden der Klasse j ava. r mi . Nami ng verwaltet werden.

• Das RMI-System stellt einen einfachen Name Server zur Ermittlung von Objektreferenzen auf einer Maschine bereit.

• Beispiel:St r i ng ur l = " / / ei nst ei n: 8329/ Hel l oSer ver " ;t r y {

Hel l oI mpl obj = new Hel l oI mpl ( ) ;j ava. r mi . Nami ng. r ebi nd( ur l , obj ) ;

} cat ch ( Except i on e) { . . . }

St r i ng ur l = " / / ei nst ei n: 8329/ Hel l oSer ver " ;t r y {

Hel l o obj Ref = ( Hel l o) j ava. r mi . Nami ng. l ookup( ur l ) ;} cat ch ( Except i on e) { . . . }

Server

Client

��

Sicherheitsmechanismen für den entfernten Zugriff

• Alle Programme, die RMI benutzen, müssen einen Security Managerinstallieren. Dieser steuert das Laden von Code über das Netz und den Zugriff auf Ressourcen.

• Zum Beispiel:i f ( Syst em. get Secur i t yManager ( ) == nul l ) {

Syst em. set Secur i t yManager ( new RMI Secur i t yManager ( ) ) ;}

Ab JDK 1.2 müssen in einem Security Policy File die Rechte für den Zugriff auf Ressourcen vereinbart werden.Zum Beispiel:

gr ant {per mi ssi on j ava. net . Socket Per mi ssi on “ * : 1024- 65535“ ,

“ connect , accept “ ;per mi ssi on j ava. net . Socket Per mi ssi on “ * : 80“ ,

“ connect “ ;} ;

��

RMI: Registry, Server und Client

Client

HTTP-Server

Server

HTTP-Server

Registry

RMI

Protocol (URL)

Documents

Anforderungen aus der Sicht eines -Applikationsentwicklers ...eris.prakinf.tu-ilmenau.de/edu/va/folien/VL2.pdfvon X.500/ISO 9594, der die Suche von Ressourcen außerhalb einer lokalen