Systemarchitekturen für Verteilte Anwendungen - Implementierungsvarianten- 25.10., 26.10. und 30.11.2014 Institut für Betriebssysteme und ...
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Systemarchitekturen für
Verteilte Anwendungen
– Implementierungsvarianten –
25.10., 26.10. und 30.11.2014
Institut für Betriebssysteme und
Rechnerverbund
TU Braunschweig
PD Dr. Christian Werner
1-2 Interprozess-Kommunikation
Anwendungsprogramme „leben“ in Prozessen.
Ein Prozess ist ein Objekt des Betriebssystems, durch das
Anwendungen sicheren Zugriff auf die Ressourcen des
Computers erhalten. Einzelne Prozesse sind dazu
gegeneinander isoliert.
Damit zwei Prozesse Informationen austauschen können,
müssen sie Interprozesskommunikation (interprocess
communication, IPC) einsetzen.
IPC basiert auf dem Austausch von Nachrichten (=
Bitfolgen)
Eine Nachricht wird von dem einem Prozess geschickt (dem
Sender).
Sie wird von einem anderen Prozess empfangen (dem Empfänger).1-3 Synchroner vs. Asynchroner IPC
Synchron: Asynchron:
Sender und Empfänger Das „Senden“ findet nicht-
blockieren beim Senden bzw. blockierend statt, d.h., der
Empfangen, d.h., wenn ein Prozess kann nach dem
„Senden“ ausgeführt wird, Senden der Nachricht sofort
kann der Prozess nur weiterarbeiten.
weiterarbeiten, nachdem das Empfangen kann blockierend
zugehörige „Empfangen“ im oder nicht-blockierend sein.
anderen Prozess ausgeführt
wurde.
Etwas komplizierter zu
Wenn ein „Empfangen“ implementieren
ausgeführt wird, wartet der (Warteschlangen), aber
Prozess so lange, bis eine effizienter.
Nachricht empfangen wurde.
Weniger effizient, aber leicht zu
implementieren
(Synchronisation beim
Ressourcenzugriff wird gleich
miterledigt).1-4 Implementierungsvarianten Verteilter Anwendungen
Anwendung
Standard-
Dienste
(FTP, Email,
Middleware vor allem WWW)
TCP/UDP über IP1-5 Überblick
Sockets
UDP/IP
TCP/IP
Middleware
CORBA
Java RMI
Web Services1-6 TCP/IP Protocol Stack
Web browser,
e-mail, ... Other user
applications User
Applications space
Application protocols:
HTTP, SMTP, FTP, ...
Application Programming Interface (API)
TCP UDP
Transport
OS
IGMP ICMP RIP OSPF kernel
IP
Network
RARP ARP
LAN DL WAN DL
technology technology Data Link1-7 Das Modell von IP
Datagramme
Einzelne, unabhängig voneinander weitergeleitete Pakete, die
sich ihren Weg zum Ziel suchen
Routing-Tabellen
geben den Ausgang zu R2 R5
einem Ziel an
yx R3 yx
„Best effort“-Dienst R1 R6
x yx yx R4 yx yx y
Keine Garantie für
Auslieferung eines DA,SA data
Pakets Routing tables
Korrekte Reihenfolge Router R1 Router R3 Router R6
DA Next hop DA Next hop DA Next hop
y R3, R4 y R6 y -
... ... ... ... ... ...1-8 IPv4-Adressen
32 bits
Binäre und dezimale Darstellung
31 23 15 7 0
Binary: 11010100 01111110 11010000 10000111
Dotted decimal: 212 . 126 . 208 . 135
Hierarchische Adressierung
Netzwerk-Nummer + Netzmaske (Classless Interdomain Routing
(CIDR), RFC 1519).
Netzangabe: 134.169.0.0/255.255.0.0 oder alternativ
134.169.0.0/16 (16 = Länge der Netzmaske)
Bildung von Netzhierarchien:
IBR-Netz: 134.169.34.0/23
CIP-Pool im IBR-Netz: 134.169.34.192/261-9 Transportschicht: TCP und UDP
Aufgabe der Transportschicht: Datentransport von
einem Prozess auf einem Rechner zu einem (oder
mehreren) anderen Prozessen auf anderen
Rechnern im Internet
Zwei Möglichkeiten
Der grundlegende unzuverlässige Internetdienst genügt,
dann verwende UDP.
Er genügt nicht, dann verwende TCP.1-10 Eigenschaften von TCP und UDP
TCP setzt einen zuverlässigen Dienst auf IP auf:
Paketauslieferung ist garantiert (bzw. der Sender erhält
zumindest eine Fehlermeldung)
Die Reihenfolge der eingehenden Pakete entspricht der
Sendereihenfolge
UDP garantiert dies nicht, ist aber dafür wesentlich
schneller.
Anwendungen für beide Protokolle?1-11 Umsetzung von TCP
TCP setzt vor allem die folgenden
Protokollmechanismen ein, um die Effekte erzielen
zu können
Daten sind numeriert, so dass fehlende Daten schnell
festgestellt werden können
Mittels ACKnowledgements teilt der Empfänger den
korrekten Empfang von Daten mit
Mittels Timern stellt der Sender das Ausbleiben von
ACKs fest1-12 Das TCP/UDP API: Sockets
Das Internet-API über der Transportschicht wird als
Sockets bezeichnet.
Ein Socket kann als Endpunkt einer
Kommunikationsbeziehung betrachtet werden.
Daten werden in Sockets abgelegt und durch Sockets
empfangen.
Es gibt in der Socket-Schnittstelle zwei grundlegende
Typen von Sockets:
Ein Socket, der wie das Ende einer Telefonverbindung funktioniert
Ein Socket, der wie ein Briefkasten funktioniert
Was bedeutet das?
Sockets sind mehr oder weniger in jeder
Programmiersprache erhältlich, u.a. in Java.1-13 Sockets und TCP/UDP-Ports
Ein Socket wird vor der Kommunikation mit einer TCP/UDP-Portnummer
und einer IP-Adresse assoziiert.
Dadurch kann ein bestimmter Prozess auf einem Rechner identifiziert
werden.
agreed port
socket any port socket
message
client server
other ports
Internet address = 138.37.94.248 Internet address = 138.37.88.2491-14 Beispiel: Telnet-Server und Clients
neptun.elc.ro hugo.int.fr zola.int.fr
141.85.43.8 139.29.100.11 139.29.35.18
HTTP HTTP HTTP HTTP HTTP
client connection server connection client
telnet
port: 3135 port: 80 port: 5768
TCP TCP connection TCP TCP connection TCP
141.85.43.8 : 3135, 139.29.35.18 : 5768,
139.29.100.11: 80 139.29.100.11: 80
IP IP IP
IP datagrams IP datagrams1-15 Datagram Sockets
Eine Nachricht, die durch einen UDP-Socket
geschickt wird, wird nicht bestätigt bzw. bei Verlust
automatisch erneut geschickt.
Paketfehler können deshalb zum Verlust der
Nachricht führen, ohne dass es die Anwendung
bemerkt.
Maximale Größe der Nachricht: 65.535 Bytes;
größere Nachrichten müssen in der Anwendung
segmentiert bzw. re-assembliert werden!
UDP-Sockets verwenden nicht-blockierendes
Senden und blockierendes Empfangen.1-16 Java API für UDP-Sockets
Zwei wichtige Klassen:
DatagramPacket
DatagramSocket
DatagramPacket enthält die zu sendende Information.
DatagramSocket besitzt vor allem die Methoden
send(DatagramPacket)
receive(DatagramPacket)
mit der offensichtlichen Funktionalität.
Mehr Informationen finden sich in der API-Beschreibung
unter http://docs.oracle.com/javase/7/docs/api/
im java.net-Package.1-17 Typische Struktur von UDP-Programmen
Client Server
create UDP socket create UDP socket
create datagram create datagram buffer
send datagram
receive datagram
create datagram buffer
create and send datagram
receive datagram1-18 Ein UDP-Client
import java.net.*;
import java.io.*;
public class UDPClient{
public static void main(String args[]){
try {
DatagramSocket aSocket = new DatagramSocket();
byte [] m = args[0].getBytes();
InetAddress aHost = InetAddress.getByName(args[1]);
int serverPort = 6789;
DatagramPacket request = new DatagramPacket(m, args[0].length(),
aHost, serverPort);
aSocket.send(request);
byte[] buffer = new byte[1000];
DatagramPacket reply = new DatagramPacket(buffer, buffer.length);
aSocket.receive(reply);
System.out.println("Reply: " + new String(reply.getData()));
aSocket.close();
}catch (SocketException e){System.out.println("Socket: " + e.getMessage());
}catch (IOException e){System.out.println("IO: " + e.getMessage());}
}
}1-19 Ein UDP-Server
import java.net.*;
import java.io.*;
public class UDPServer{
public static void main(String args[]){
try{
DatagramSocket aSocket = new DatagramSocket(6789);
byte[] buffer = new byte[1000];
while(true){
DatagramPacket request = new DatagramPacket(buffer, buffer.length);
aSocket.receive(request);
DatagramPacket reply = new DatagramPacket(request.getData(),
request.getLength(), request.getAddress(), request.getPort());
aSocket.send(reply);
}
}catch (SocketException e){System.out.println("Socket: " + e.getMessage());
}catch (IOException e) {System.out.println("IO: " + e.getMessage());}
}
}1-20 Stream Sockets
TCP-Sockets gestatten eine Datenstrom-orientierte
Kommunikation.
Daten werden in einem Strom geschrieben, der vom
Partner in derselben Reihenfolge empfangen wird.
Paketverluste werden von TCP abgefangen, d.h.,
Anwendungen erhalten Daten erst, wenn Sie wirklich
korrekt (in der Reihenfolge) sind.
Vor dem eigentlichen Datenaustausch muss zunächst eine
Verbindung zwischen Client und Server aufgebaut werden.
Verbindungen werden über die Port/IP-Adressinformation
identifiziert.1-21 Das TCP-Socket-API in Java
Zwei wichtige Klassen:
ServerSocket
Socket
Ein ServerSocket ist passiv und wartet nach dem Aufruf
der accept-Methode auf Verbindungsaufbauwünsche von
Clients.
Ein Socket wird vom Client genutzt. Mittels des
Konstruktors wird implizit eine Verbindung zu einem Server
aufgebaut.
Bei beiden Klassen kann man sich eine Referenz auf den
Ein- bzw. Augabedatenstrom geben lassen. Datenströme
können dann nach dem ganz normalen Java-Schema
genutzt werden.1-22 Typische Struktur von TCP-Programmen
Client Server
create Stream socket create Server socket
connect
wait for connection
write data on stream
read data from stream
write data on stream
read data from stream1-23 Ein TCP-Client
import java.net.*;
import java.io.*;
public class TCPClient {
public static void main (String args[]) {
try{
int serverPort = 7896;
Socket s = new Socket(args[1], serverPort);
DataInputStream in = new DataInputStream( s.getInputStream());
DataOutputStream out =
new DataOutputStream( s.getOutputStream());
out.writeUTF(args[0]);
String data = in.readUTF();
System.out.println("Received: "+ data) ;
s.close();
}catch (UnknownHostException e){
System.out.println("Sock:"+e.getMessage());
}catch (EOFException e){System.out.println("EOF:"+e.getMessage());
}catch (IOException e){System.out.println("IO:"+e.getMessage());
}
}
}1-24 Ein TCP-Server
import java.net.*;
import java.io.*;
public class TCPServer {
public static void main (String args[]) {
try{
int serverPort = 7896;
ServerSocket listenSocket = new ServerSocket(serverPort);
while(true) {
Socket clientSocket = listenSocket.accept();
Connection c = new Connection(clientSocket);
}
} catch(IOException e) {System.out.println("Listen :"
+e.getMessage());}
}
}1-25 TCP Server (Forts.)
class Connection extends Thread {
DataInputStream in;
DataOutputStream out;
Socket clientSocket;
public Connection (Socket aClientSocket) {
try {
clientSocket = aClientSocket;
in = new DataInputStream( clientSocket.getInputStream());
out =new DataOutputStream( clientSocket.getOutputStream());
this.start();
} catch(IOException e) {System.out.println("Connection:“
+e.getMessage());}
}
public void run(){
try { // an echo server
String data = in.readUTF();
out.writeUTF(data);
clientSocket.close();
} catch(EOFException e) {System.out.println("EOF:"+e.getMessage());
} catch(IOException e) {System.out.println("IO:"+e.getMessage());}
}
}1-26 Weitere Aufgaben des Programmierers
Sockets stellen nur die grundlegenden Mechanismen zur
Verfügung, es bleibt noch einiges zu tun:
Implementierung komplexerer Systemmodelle wie Request-Reply
(bei Client-Server) oder Gruppenkommunikation
Vor allem aber die Notwendigkeit der homogenen
Datenrepräsentation in heterogenen Umgebungen
Dies sind die grundlegenden Techniken für komplexere
Middleware wie
RPC
Java RMI
CORBA1-27 Datenrepräsentation und Marshalling
Die meisten Anwendungen bzw. Middleware-Ansätze
nutzen ein gemeinsames Datenformat.
Notwendig wegen der Heterogenität der Umgebungen
Unterschiedliche Hardwarearchitektur
Verschiedene Betriebssysteme
Verschiedene Programmiersprachen
Unter „Marshalling“ versteht man den Prozess der
Transformation einer beliebigen Datenstruktur in eine
übertragbare Nachricht:
„planieren“ der Datenstruktur (in eine zusammenhängende
Nachricht)
Übersetzung in das gemeinsame Format1-28 Abbildung von Datenstrukturen auf Nachrichten
Ein Nachricht steht zusammenhängend im
Speicher und kann so übertragen werden.
F I S C H E R \0 1 5 C A M P U S U 1
Eine Datenstruktur kann über den Speicher verteilt
sein und so nicht übertragen werden.
F I S C H E R \0 1 5
•
C A M P U S U 11-29 Datenrepräsentation
Es gibt eine Reihe bekannter Ansätze für ein
gemeinsames Netzdatenformat.
Idee:
Definiere eine Menge von abstrakten Datentypen und eine
Kodierung (ein genaues Bit-Format) für jeden dieser Typen
Stelle Werkzeuge zur Verfügung, die die abstrakten Datentypen in
Datentypen der verwendeten Programmiersprache übersetzen
Stelle Prozeduren zur Verfügung, die die lokalen Darstellungen der
Datentypen in das kodierte Format übersetzen
Zur Laufzeit: wenn ein bestimmter Datentyp übertragen werden
soll, rufe die Kodierfunktion auf und übertarge das Ergebnis
Auf der Empfängerseite: dekodiere den Bit-String und erzeuge eine
neue lokale Repräsentation des empfangenen Typs1-30 Abbildungsfunktionen
Abstrakte Datentypen
Übersetzung in Übersetzung in
Sprache X Sprache Y
Kommunikation?
Programm in Sprache X Programm in Sprache Y
Kodiere Nachricht Dekodiere Nachricht
Nachricht in kodiertem Format1-31 Bekannte Formate
ASN.1 (ISO OSI)
XDR (Internet RPC)
CDR (CORBA)
Java object serialization
XML
Zwei unterschiedliche Ansätze:
Übertragung in binärer Form
Übertragung als Text
Beispiel ASN.1:
5 65 12 61 “This is the content”
Tag: Typ Länge der Wert: kann selbst wieder strukturiert sein
ID Daten1-32 Die Realität
Zuerst die schlechte Nachricht: das sieht alles
ziemlich kompliziert aus, und es ist es auch. Als
Socket-Programmierer muss man sich um diese
Dinge selbst kümmern.
Die gute Nachricht: die Aufgabe einer Middleware
ist es, genau diese komplizierten Mechanismen
automatisch zu erledigen. Der
Anwendungsprogrammierer sieht davon nichts
mehr.
Mehr dazu im nächsten Kapitel.1-33 Middleware in Form verteilter Objektsysteme
Lokales Objektsystem Verteiltes Objektsystem
Rechner Prozess Objekt1-34 Das Objekt-Modell
System = Sammlung miteinander interagierender Objekte,
von denen jedes aus einer Menge von Daten und einer
Menge von Methoden besteht
Wichtige Begriffe:
Objektreferenz: die „Adresse“ eines Objekt
Schnittstellen: Definition der Zugangspunkte eines Objekts;
definiert durch die Signatur der Methoden
Aktionen: initiiert durch ein Objekt, das eine Methode eines
anderen Objekts aufruft; resultiert in der Zustandsänderung von
Objekten
Exceptions: eine Möglichkeit, Fehler in einem Programm auf
saubere Art und Weise zu behandeln
Garbage Collection: Freigabe nicht mehr benutzten Speichers1-35 Das verteilte Objektmodell
Interagierende Objekte sind auf mehr als einen
Prozess verteilt
Begriffe:
Entfernte Objektreferenz: die Adresse eines Objekts im
ganzen verteilten System; muss eindeutig sein
Entfernte Schnittstellen: die Schnittstelle eines
entfernten Objekts, oft beschrieben in einer formalen
IDL (interface definition language)
Aktionen: Methodenaufrufe anderer Objekte können
Prozessgrenzen überschreiten
Exceptions: verteilte Ausführung des Systems erweitert
das Spektrum möglicher Fehler1-36 Entfernte und lokale Methodenaufrufe
remote local C
E
invocation invocation local
remote
invocation invocation F
B local
A
invocation D
Objekt
Rechner Prozess1-37 Schnittstellen entfernter Objekte
Die entfernte Schnittstelle gibt an, wie auf
entfernte Objekte zugegriffen wird.
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 Middleware besitzt eine eigene Sprache, um
solche Schnittstellen zu beschreiben, die IDL.1-38 Entferntes Objekt und Schnittstelle
remoteobject
Data
remote
interface
m1 m4
{
implementation m5
m2
of methods m6
m31-39 CORBA: Inhaltsübersicht
Was ist CORBA?
Einsatzgebiete von CORBA
Verteilte Objektsysteme
Architektur von CORBA
Kommunikation zwischen Objekten
CORBA IDL
Entwicklung von CORBA-Anwendungen
CORBA in Enterprise Applications
CORBA-fähige Tools
CORBA-Unterstützung in Java1-40 Was ist CORBA?
CORBA = Common Object Request Broker
Architecture
Zunächst einmal eine Spezifikation, keine
Implementierung
erstellt von der OMG (Object Management Group,
http://www.omg.org), einem Konsortium von
zahlreichen Firmen und Organisationen
Ziel: Standard für verteilte Objektsysteme,
Interoperabilität versch. Implementierungen1-41 Einsatzgebiete
Vollständige verteilte Systemimplementierungen
Service-Implementierungen, die von anderen
Anwendungen netzweit genutzt werden können
Erstellen von standardisierten Dienstschnittstellen
für Legacy-Anwendungen, z.B. R/3, DB2, Oracle
etc.1-42 CORBA-Eigenschaften
CORBA erlaubt das Schreiben von Anwendungen,
die aus einer Sammlung
heterogener
verteilter
miteinander kooperierender Objekte
bestehen.
Heterogen bedeutet hier, die Objekte können
in versch. Programmiersprachen implementiert sein
unter versch. Betriebssystemen laufen
von unterschiedlichen Organisationen betreut werden1-43 Architektur von CORBA
Common Horiz. And Vert. Facilities Application Objects
Distrib.
Informat. Systems
Docu-
Managem. Managem.
……..
ments
Object Request Broker
Naming
Event
Trader
Persi-
Security ……..
Service stence
Common Object Services1-44 Object Request Broker
Zentrale Komponente von CORBA
Hauptaufgabe:
ermöglicht die für die Anwendung transparente
Kommunikation von Objekten über das Netz
lokale und entfernte Methodenaufrufe sehen praktisch
identisch aus
ORB sucht das Objekt für den Aufrufer
Jeder Prozess mit CORBA-Objekten muss einen
ORB besitzen.
ORBs kommunizieren miteinander über das
standardisierte GIOP bzw. IIOP im Internet.1-45 Realisierung des ORB
AO AO AO
ORB ORB
GIOP/IIOP
ORB ORB
AO Dienst Dienst1-46 Application Objects
Dies sind die eigentlichen Anwendungsobjekte.
Sie werden vom Anwendungsentwickler
geschrieben.
AOs nutzen die ORBs, um miteinander zu
kommunizieren und um die verschiedenen
CORBA-Dienste zu anzusprechen.
Erstellung von AOs behandeln wir etwas später.1-47 CORBA-Dienste und Facilities
CORBA definiert eine Reihe von Standarddiensten, die von
Anwendungen verwendet werden können.
Dadurch ergibt sich eine erhebliche Einsparung bei der
Anwendungsentwicklung.
Beispiele:
Persistence Service: erlaubt das Speichern und Laden von
Objekten auf nichtflüchtigem Speicher
Naming Service: Finden von Objekten aufgrund des Namens
Transaction Service: erlaubt das Durchführen von Transaktionen
(„alle Aktionen oder keine“)
Trader Service: „Gelbe Seiten“, Finden von AOs aufgrund von
Eigenschaften
Event Service: Entkopplung von Client und Server; asynchrone
Kommunikation1-48 Kommunikation zwischen Objekten
Client X
ruft Objekt Y
Methode M von Y Methode M
auf
Object Request Broker (Core)1-49 Virtuelle und tatsächliche Kommunikation
Objektreferenz
Client
Server
Stub Skeleton
durch den ORB
durchgeführt1-50 CORBA IDL
Die Implementierung von Objekten kann in verschiedenen
Sprachen erfolgen.
Die Schnittstelle muss jedoch auf standardisierte Weise
erfolgen, damit jeder Nutzer eines Objekts weiß, wie er es
ansprechen kann.
Zu diesem Zweck wird in CORBA die Interface Definition
Language (IDL) verwendet.
Sie erlaubt die Beschreibung der
Signaturen der Methoden eines Objekts sowie
evtl. dazu benötigter Datentypen1-51 IDL Syntax
IDL-Beschreibung enthalten die folgenden
Elemente
Module: zusammengehörige Definitionen einer
Anwendung, Schlüsselwort module
Datentypen: Definition ähnlich wie in C
Schnittstelle eines oder mehrerer Objekte:
Schlüsselwort: interface
innerhalb einer Schnittstellenbeschreibung: Methoden
und Instanzvariablen, falls diese öffentlich sein sollen1-52 Beispiel
module QueueApp {
struct PersonenInfo {
string firstname;
string lastname;
int age;
}
interface Queue {
boolean enqueue(in PersonenInfo pi);
PersonenInfo dequeue();
boolean isEmpty();
}
}1-53 IDL Compiler
Großer Vorteil einer standardisierten formalen
Beschreibung einer Objektschnittstelle: sie ist
automatisch behandelbar!
Zum Beispiel lässt sich automatisch Code für eine
Programmiersprache ableiten.
Damit wird ein wesentlicher Schritt bei der
Umsetzung des Designs in eine Implementierung
automatisiert.
Es gibt heute für sehr viele Programmiersprachen
schon IDL-Compiler.1-54 Ausgaben des IDL-Compilers
Ein typischer IDL-Compiler erzeugt
die Stubs und Skeletons
die leeren Prozeduren (die Köpfe) auf der Server-Seite
ein Serverprogramm, das Client-Anfragen entgegen
nimmt und die entsprechenden Prozeduren aufruft
ein einfaches Client-Programm zum Testen
Der Programmierer muss dann nur noch
die Prozedurrümpfe auf der Server-Seite ausfüllen
das Client-Programm entsprechend der gewünschten
Anwendung modifizieren1-55 Gemeinsames Format
IDL-Compiler IDL definition IDL-Compiler
translate IDL translate IDL
into X into Y
communication?
Program in language X Program in language Y
translate message translate message
into CDR into Y
Message in CDR format
Stub Skeleton1-56 IDL Stubs und Skeletons
Stubs und Skeletons werden aus der IDL
generiert.
Ein Stub ist die Verbindung zwischen Client und
ORB, ein Skeleton die zwischen Server und ORB.
Nach oben (Client bzw. Server) wird die
Schnittstelle des Objekts übersetzt in die
verwendete Programmiersprache angeboten.
Zum ORB hin wird eine Nachrichtenschnittstelle
angeboten.
Stubs und Skeletons übersetzen demnach das
eine Format in das andere.1-57 Entwicklung von CORBA-Anwendungen
Client developer Server developer
IDL
IDL IDL
compiler compiler
Sourcen
Client Server
ausführbare
Programme1-58 CORBA in Enterprise Applications
CORBA-Objekte können die
komplette Business-Logik-
Ebene einnehmen.
Presentation-Implemen-
tierungen werden dann oft als
WWW-Anwendungen realisiert.
Servlet Servlet
Häufige Variante: Servlets als Web Server
Front-End, die den Kontakt zu
den CORBA-Objekten
herstellen
Oft für Legacy-Anwendungen Object
Object Object
CORBA Object Server
Später dazu mehr1-59 JAVA RMI als Alternative: Grundlagen
Definiert ein Rahmenwerk für die Kommunikation
von Java-Objekten unabhängig von ihrem Ort
Eine reine Java-Lösung
Alle entfernten Objekte müssen ein entferntes
Interface besitzen
Es sind Werkzeuge vorhanden für die
Generierung von Stubs und Skeletons.
JDK stellt eine Implementierung des Naming
Service zur Verfügung, die RMIregistry.
Ein RMI-Dämon erlaubt einen flexible (on-
demand)-Instanziierung von Objekten.1-60 Schnittstellen-Definition
Schnittstellen werden definiert
Mit Hilfe des Java interface Konstrukts
Indem sie die Eigenschaften des Remote interface erben
Und indem sie RemoteExceptions auslösen können.
Ansonsten können alle Java-Typen verwendet werden.
Neue Klassen können definiert und als Parameter von
Methoden verwendet werden.
import java.rmi.*;
import java.util.Date;
public interface DateServer extends Remote {
public Date getDate() throws RemoteException;
}1-61 Vergleich: CORBA vs. RMI
RMI ist eine reine Java-Variante, aber ähnlich zu
CORBA
+ Die Programmierung ist einfacher als bei CORBA
+ Komplexe Objekte können übergeben werden
− Nur für Java
Zusammenfassung:
Gute Alternative für reine Java-Lösungen
Die Übertragung von aktiven Objekten wird selten
genutzt (z.B. für mobile Agenten)1-62 Web Services
Idee: Verbinde die Einfachheit von Java RMI mit
der Plattformunabhängigkeit von CORBA
Web Services:
WSDL (Dienstbeschreibung)
SOAP (Nachrichtenaustausch)
UDDI (Dienstverzeichnis)
Das Zusammenspiel dieser Technologien wird im
sog. „Web-Service-Rollenmodell“ beschrieben1-63 Web-Service-Rollenmodell
WSD
Dienst-
register
Finden Veröffentlichen
SOAP (über HTTP)
WSDL
WSD
Dienst- Dienst-
nutzer anbieter
Interagieren1-64 Warum XML?
„Verbindet alles mit
jedem!“
Web Services als
universelle Middleware-
Technologie
Grundlage: XML
Daher: beseitigt Probleme mit
inkompatiblen Datentypen,
Zeichen-codierungen,
Byteorders usw.
Hinweis: Performance
schlechter als bei binären
Protokollen!
Vor allem deutlich höheres
Datenaufkommen!1-65 Intuitiver Lösungsansatz: Textkompression
POST /axis/services/calculator HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.1
Host: localhost
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: ""
Accept-Encoding:
Content-Length: 348 gzip
Content-Encoding: gzip
[
?鲠3̐ F©Ҩ¤+¡tʓ>nᄆ� ¤A yJ ȕª `ÑUº
[…]
[…]1-66 Ergebnis: marginale Verbesserung
120.000
100.000 SOAP
Datenaufkommen [Bytes]
Corba
80.000
RMI
60.000 SOAP (gzip)
40.000
20.000
0
1 5 10 15 20 25 30 35 40 45 50
Anzahl ausgetauschter Nachrichten (n)1-67 Netzprogrammierung vs. Middleware
Direkte Middleware
Netzprogrammierung Sehr bequemer Weg zur
Direkte Kontrolle aller Entwicklung von
Transportparameter Anwendungen
größere Flexibilität bei der Datenrepräsentation,
Entwicklung neuer Objektlokalisierung etc.
Protokolle muss nicht von der
Kann in vielen Fällen Anwendung gemacht
bessere Performance werden
bringen Oft viel Overhead
Grosses Problem:
Datenrepräsentation1-68 Diskussion
Sie können auch lesen
