Anforderungen aus der Sicht eines -Applikationsentwicklers...
Transcript of Anforderungen aus der Sicht eines -Applikationsentwicklers...
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 Distributed File 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
CellDirectoryServiceClerk
Host B
Network
CellDirectoryServiceClerk
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
������������ ������������������������� ����������
DCE Distributed File Service
• 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)