pdf 6.600kB - Persönliche Webseiten der Informatik

Verteilte Systeme
Interprozesskommunikation Teil 2
1
Interprozesskommunikation
Applikationen, Dienste
Dieser Teil
der
Vorlesung
RemoteMethodInvocation und RemoteProcedureCall
Anforderung/Antwort-Protokoll (request-reply protocol)
Middlewareschichten
Marshalling und externe Datendarstellung
UniversalDatagramProtocol und TransmissionControlProtocol
2
Übersetzung
‹
R emote
‹
entfernt, rechnerfern, entlegen
‹
P rocedure
besser wäre: extern
‹
Prozedur, Funktion, Verfahren
‹
C all
Aufruf, Anruf, Ruf
Entfernter
Entfernter
Prozeduraufruf
Prozeduraufruf
R emote
M ethod
Methode, Prozedur, Operation,
Verfahren
‹
I nvocation
Anrufung, Beschwörung,
Anfrage, Aufruf
Entfernter
Entfernter
Methodenaufruf
Methodenaufruf
3
Verteiltes Objektsystem
Lokal
Lokal
Entfernt
Entfernt
vv
ee
rr
ss
uu
ss
Rechner
Prozess
Objekt
Interaktion
4
Das Objektmodell
‹
‹
System: Sammlung miteinander interagierender Objekte, von
denen jedes aus einer Menge von Daten und einer Menge von
Methoden besteht
Wichtige Begriffe (Auswahl, vereinfacht):
– Objektreferenz: die „Adresse“/eindeutige Identität eines Objekt
– Schnittstellen: Definition der Zugangspunkte eines Objekts;
definiert durch die Signatur der Methoden
– Ereignisse/Aktionen: initiiert durch ein Objekt, das eine
Methode eines anderen Objekts aufruft; resultiert in der
Zustandsänderung von Objekten oder/und weiteren
Ereignissen/Aktionen
– Exceptions/Ausnahmen: eine Möglichkeit, Fehler in einem
Programm auf saubere Art und Weise zu behandeln
– Garbage Collection: Freigabe nicht mehr benutzten Speichers
5
Das verteilte Objektmodell
‹
‹
Verteiltes System: 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
6
Entfernte und lokale Methodenaufrufe
entfernter
Aufruf
‹
‹
‹
lokaler
Aufruf
lokaler
Aufruf
lokaler
Aufruf
entfernter
Aufruf
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
7
Entfernte Objektreferenz
‹
‹
‹
Ü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.
32 bits
32 bits
Internetadresse Port-Nummer
32 bits
Zeit
32 bits
Objektnummer
Schnittstelle des
entfernten Objektes
Achtung: Diese Art der Refernz erlaubt kein Verschieben des Objektes in
einen anderen Prozess!
8
Schnittstellen entfernter Objekte
‹
‹
‹
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
W Dem Methodennamen
W Ihrer Ein- und Ausgabeparameter
W Ihrem Rückgabewert
Jede Middleware besitzt eine eigene Sprache, um solche
Schnittstellen zu beschreiben.
9
Schnittstellen entfernter Objekte:
Beispiel Corba IDL
struct Person {
string name;
CORBA hat Strukturen,
string place;
entfernte Schnittstelle
Java hat Klassen
long year;
};
interface PersonList {
Signatur: Definition
readonly attribute string listname;
der Methoden
void addPerson(in Person p) ;
void getPerson(in string name, out Person p);
long number();
Parameter sind in, out oder inout
};
entfernte
Schnittstelle
entfernter
Aufruf
m1
m2
m3
Daten
Implementierung
der Methoden
lokaler
m4 Aufruf
m5
m6
10
Entwurfsprobleme
‹
Lokale Aufrufe werden genau einmal ausgeführt. Dies kann
für entfernte Aufrufe nicht immer der Fall sein. Was sind die
Alternativen ?
Führt zur Definition einer Fehlersemantik
‹
Was ist der Transparenzgrad der entfernten Aufrufe ?
Was ist gegeben, was muß der Programmierer selber
sicherstellen ?
11
Aufrufsemantik
Ein lokaler Aufruf wird genau einmal
durchgeführt. Ein entfernter Aufruf
erreicht diese Qualität zunächst
nicht. Warum nicht ?
Client
1) Verlust der Auftragsnachricht
Server
1)
2) Verlust der Ergebnisnachricht
3) Ausfall des Servers
3)
4)
2)
4) Ausfall des Clients
12
Fehlersemantik
at
atleast
leastonce
onceSemantik
Semantik
Client
Server
at
atmost
mostonce
onceSemantik
Semantik
Client
Server
Reply
Bearbeitung
des Requests
Ergebnis
Ergebniskann
kann
verschieden
verschiedensein!
sein!
Timeout
Request
Reply
Bearbeitung
des Requests
Timeout
Timeout
Request
Request
Request
Timeout
Timeout
Request
Timeout
Liste
Liste der
der Requests
Requests
Request
Reply
Bearbeitung
Bearbeitung des
des Requests;
Requests;
Request
Request eintragen
eintragen
Liste
Liste der
der Requests
Requests überüberprüfen;
prüfen; Verwerfen
Verwerfen des
des 2.
2.
Reply Requests
Requests
Acknowledge- Request löschen
Request löschen
ment
13
Fehlersemantik
Fehlersemantik
Fehlerfreier
Ablauf
Nachrichtenverluste
Ausfall des
Servers
Maybe
Ausführung: 1
Ergebnis: 1
Ausführung: 0/1
Ergebnis: 0
Ausführung: 0/1
Ergebnis: 0
At-least-once
Ausführung: 1
Ergebnis: 1
Ausführung: >= 1
Ergebnis: >= 1
Ausführung: >=1
Ergebnis: >=1
At-most-once
Ausführung: 1
Ergebnis: 1
Ausführung: 1
Ergebnis: 1
Ausführung: 0/1
Ergebnis: 0
Exactly-once
Ausführung: 1
Ergebnis: 1
Ausführung: 1
Ergebnis: 1
Ausführung: 1
Ergebnis: 1
14
Transparenz
Zugriffstransparenz ermöglicht den Zugriff auf lokale und entfernte Ressourcen unter
Verwendung identischer Operationen.
Ist realisiert: die Operationen sind identisch, die Syntax evtl. unterschiedlich.
Positionstransparenz (Ortstransparenz) erlaubt den Zugriff auf die Ressourcen, ohne
dass man ihre Position/ihren Ort kennen muss.
Ist realisiert.
Nebenläufigkeitstransparenz erlaubt, dass mehrere Prozesse gleichzeitig mit
denselben gemeinsam genutzten Ressourcen arbeiten, ohne sich gegenseitig zu stören.
Ist nicht realisiert.
Replikationstransparenz erlaubt, dass mehrere Instanzen von Ressourcen verwendet
werden, um die Zuverlässigkeit und die Leistung zu verbessern, ohne dass die Benutzer oder
Applikationsprogrammierer wissen, dass Repliken verwendet werden.
Ist manchmal realisiert.
15
Transparenz
Fehlertransparenz erlaubt das Verbergen von Fehlern, so dass Benutzer und
Applikationsprogrammierer ihre Aufgaben erledigen können, auch wenn Hardware- oder
Softwarekomponenten ausgefallen sind.
Ist teilweise realisert (siehe Fehlersemantik)
Mobilitätstransparenz erlaubt das Verschieben von Ressourcen und Clients innerhalb
eines Systems, ohne dass die Arbeit von Benutzern oder Programmen dadurch beeinträchtigt
wird.
Mittels Namensdienst realisiert.
Leistungstransparenz erlaubt, dass das System neu konfiguriert wird, um die Leistung zu
verbessern, wenn die Last variiert.
Ist nicht realisiert.
Skalierungstransparenz erlaubt, dass sich System und Applikationen vergrößern, ohne
dass die Systemstruktur oder die Applikationsalgorithmen geändert werden müssen.
Ist durch die Objektorientiertheit bereits gegeben.
16
Implementierung
‹
‹
Kommunikationsmodul: zuständig für das Request-/ReplyProtokoll
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.
17
Rolle von Proxy und Skeleton
Proxy:
Proxy:macht
machtRMI
RMItransparent
transparentfür
fürClient.
Client.
Klasse
implementiert
entfernte
Schnittstelle.
Klasse implementiert entfernte Schnittstelle.
Marshals
MarshalsRequest
Requestund
undunmarshals
unmarshalsReply.
Reply.
Leitet
LeitetRequest
Requestweiter.
weiter.
Ausführungdes
des
Ausführung
Request/ReplyProtokolls
Protokolls
Request/Reply
Client
Entferntes
Referenzmodul
Übersetzungzwischen
zwischen
Übersetzung
lokalenund
undentfernten
entfernten
lokalen
Objektreferenzen
Objektreferenzen
Request
Reply
Kommunikationsmodul
Proxy B
Kommunikationsmodul
Objekt A
Server
Dispatcher:
Dispatcher:wählt
wählt
Methode
Methodeim
imSkeleton
Skeleton
aus.
aus.
Dispatcher B
Objekt B
Skeleton B
Entferntes
Referenzmodul
Skeleton:
Skeleton:implementiert
implementiertMethoden
Methodender
der
entfernten
entferntenSchnittstelle.
Schnittstelle.Unmarshals
Unmarshals
Request
Requestund
undMarshals
MarshalsReply.
Reply.Ruft
Ruft
Methode
Methodeininentferntem
entferntemObjekt
Objektauf.
auf.
18
Verteilungstransparenz:
Referenz- und Kopiersemantik
‹
‹
Entfernte Methodenaufrufe sollten ParameterübergabeSemantik 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)
19
Beispiel für Objektü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; }}
ASkeleton AServant
B
20
Beispiel für Objektübergabe: Kopiersemantik
1. Clientobjekt hält
Referenz auf Instanz
von A, ruft darauf
Methode getB() auf.
2. Stub übermittelt
Methodenaufruf an
Skeleton
3. Skeleton delegiert
Methodenaufruf an
Servant
4. Servant übergibt
Referenz auf Instanz
von B an Skeleton
"getB"
Klienten- AStub
objekt
ASkeleton AServant
B
Adressraum
Adressraum 11
Adressraum
Adressraum 22
21
Beispiel für Objektübergabe: Kopiersemantik
8. Stub übergibt
Verweis auf neue
Instanz an Aufrufer
7. Stub lädt Klasse B,
dekodiert Zustand
und erzeugt damit
neue Instanz von B
Klienten- AStub
objekt
6. Kodierter Zustand
wird an Stub
übertragen
codierter Zustand
von B
B
Adressraum
Adressraum 11
5. Skeleton kodiert
Zustand von Instanz
gemäß Wire Protocol
ASkeleton AServant
B
B.jar
B.jar
Adressraum
Adressraum 22
22
Beispiel für Objektübergabe: Referenzsemantik
1. Clientobjekt hält
Referenz auf Instanz
von A, ruft darauf
Methode getB() auf.
2. Stub übermittelt
Methodenaufruf an
Skeleton
3. Skeleton delegiert
Methodenaufruf an
Servant
4. Servant übergibt
Referenz auf Instanz
von B an Skeleton
"getB"
Klienten- AStub
objekt
ASkeleton AServant
B
Adressraum
Adressraum 11
Adressraum
Adressraum 22
23
Beispiel für Objektübergabe: Referenzsemantik
8. A-Stub übergibt
Verweis auf B-Stub
an Aufrufer
7. A-Stub erzeugt
neuen B-Stub, der
Netzwerkadresse von
B-Skeleton enthält
6. A-Skeleton sendet
Netzwerkadresse von
B-Skeleton an A-Stub
5. A-Skeleton erzeugt
neues Skeleton für B,
falls nicht bereits
vorhanden
(hostname, port)
Klienten- AStub
objekt
ASkeleton AServant
BStub
Adressraum
Adressraum 11
BSkeleton B
B.jar
B.jar
Adressraum
Adressraum 22
24
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 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
25
Implementierung
RMI-Software: Softwareschicht zwischen Objekten und
Kommunikations- und entfernten Referenzmodulen.
– Schnittstellen-Compiler erzeugt automatisch Klassen für
Dispatcher, Skeleton und Proxy
– Server-Programm enthält Klassen für Dispatcher, Skeleton
und alle davon unterstützten entfernten Objekte (ServantKlassen) sowie einen Initialisierungsabschnitt
– Client-Programm enthält Klassen für Proxies aller
entfernten Objekte.
– Factory-Methode: Ersetzen Konstruktoren in den
entfernten Schnittstellen, d.h. sind normale Methoden, die
entfernte Objekte erzeugen können.
26
Implementierung
‹
‹
‹
‹
‹
Binder: Namensdienst, der Clients Objektreferenzen vermitteln kann
Server-Thread: Um zu verhindern, dass ein entfernter Aufruf einen anderen
Aufruf verzögert, weisen Server der Ausführung jeden entfernten Aufrufs einen
eignen Thread zu!
Aktivierung: 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.
27
Beispiel: Java-RMI
‹
‹
‹
‹
‹
‹
Definiert ein Rahmenwerk für die Kommunikation von JavaObjekten unabhängig von ihrem Ort
Eine reine Java-Lösung
Alle entfernten Objekte müssen eine entfernte Schnittstelle
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.
28
Java-RMI: Schnittstellen-Definitionen
‹
‹
Schnittstellen werden definiert
– Mit Hilfe des Java interface Konstrukts
– Indem sie die Eigenschaften der remote Schnittstelle 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.
29
Java-RMI: Das entfernte Objekt
‹
‹
Um den von der Schnittstelle „versprochenen“ Dienst zu
erbringen, muss es ein entferntes Objekt geben, das die
Methoden der Schnittstelle implementiert.
Gewöhnlich erweitert es die Klasse UnicastRemoteObject
was aus dem Objekt einen nichtreplizierten Server macht, der
über TCP kommuniziert.
Object
Remote
RemoteObject
RemoteStub
RemoteServer
UnicastRemoteObject
30
Java-RMI: Der RMI-Compiler
‹
‹
‹
Basierend auf der Implementierung des Objekts mit seinen
Methoden kann man nun automatisch Stubs und Skeletons
implementieren.
JDK stellt ein Werkzeug namens rmic für diesen Zweck zur
Verfügung.
Folgender Aufruf
> rmic DatumImpl
Erzeugt zwei Dateien:
– DatumImpl_Stub.class
– DatumImpl_Skel.class
31
Java-RMI: Die RMI-Registry
‹
‹
‹
‹
Die RMI-Registry, implementiert durch das Programm
rmiregistry, ist der Namensdienst für Java RMI.
Server registrieren entfernte Objekte unter einem Namen.
Clients fragen die Datenbank ab, um die Referenz für einen
entfernten Dienst zu erhalten.
Namensdienste behandeln wir noch ausführlich.
32
Java-RMI: Die Klasse Naming
void rebind (String name, Remote obj)
This method is used by a server to register the identifier of a remote object
by name.
void bind (String name, Remote obj)
This method can alternatively be used by a server to register a remote
object by name, but if the name is already bound to a remote object
reference an exception is thrown.
void unbind (String name, Remote obj)
This method removes a binding.
Remote lookup(String name)
This method is used by clients to look up a remote object by name. A
remote object reference is returned.
String [] list()
This method returns an array of Strings containing the names bound in
the registry.
//ComputerName:Port/ObjectName
This is the name used in the namingservice
33
Java-RMI: Erzeugen einer Anwendung
1. Definiere die entfente Schnittstelle
2. Implementiere die entfernte Schnittstelle durch ein entferntes Objekt
3. Generiere Stubs und Skeletons mit rmic
4. Schreibe einen Client
5. Starte den Namensdienst mit rmiregistry
6. Starte den Server
7. Starte den Client
34
Beispiel: Datumsabfrage
‹
‹
Das Beispiel implementiert einen RMI-Server, der das
aktuelle Datum seiner Maschine zurückgibt.
Wir müssen selbst die folgenden Dateien schreiben:
– Datum.java die Schnittstelle
– DatumImpl.java das entfernte Objekt
– DateServer.java der Server
– DateClient.java der Client
35
Beispiel: Datumsabfrage
Suffix
Bedeutung
kein (z.B. Datum)
Eine entfernte Schnittstelle
Impl (z.B. DatumImpl)
Eine Serverklasse, die diese Schnittstelle implementiert
Server (z.B. DatumServer)
Ein Serverprogramm, das Serverobjekte erzeugt
Client (z.B. DatumClient)
Ein Clientprogramm, das entfernte Methoden aufruft
_Stub (z.B. DatumImpl_Stub)
Eine Stub-Klasse, automatisch mit rmic erzeugt
_Skel (z.B. DatumImpl_Skel)
Eine Skel-Klasse, automatisch mit rmic erzeugt
(nur für < JDK 1.1)
36
Beispiel: Datum.java
import java.rmi.*;
import java.util.Date;
interface Datum
extends Remote {
public Date getDate() throws java.rmi.RemoteException;
}
••Verwendet
Verwendetvon
vonClient
Clientund
undServer
Server
••Muss
Musssich
sichauf
aufdem
demClientrechner
Clientrechner und
und
dem
demServerrechner
Serverrechnerbefinden!
befinden!
37
Beispiel: DatumImpl.java
import java.rmi.*;
import java.rmi.server.*;
import java.util.Date;
class DatumImpl extends UnicastRemoteObject implements Datum
{
public DatumImpl() throws RemoteException
{ super(); }
public Date getDate() throws java.rmi.RemoteException
{ return new Date(); } }
••Implementiert
Implementiertdie
dieentfernten
entferntenObjekte
Objekte
••Muss
Musssich
sichauch
auchnur
nurauf
aufdem
demServerrechner
Serverrechnerbefinden!
befinden!
••Mittels
Mittelsrmic
rmic DatumImpl
DatumImpl werden
werdenStub
Stubund
undSkeleton
Skeletonerzeugt
erzeugt
38
Beispiel: DatumServer.java
import java.rmi.*;
import java.rmi.server.*;
import java.util.Date;
public class DatumServer {
public static void main(String[] args) {
try { DatumImpl dateServer = new DatumImpl();
Naming.bind("DateServer", dateServer);
} catch (Exception e) {
System.out.println("DatumServer: Exception:");
System.out.println(e.getMessage()); } } }
••Implementiert
Implementiertdie
dieServerfunktionalität
Serverfunktionalität(z.B.
(z.B.Erzeugen
Erzeugender
derObjekte)
Objekte)
••Muss
Musssich
sichauch
auchnur
nurauf
aufdem
demServerrechner
Serverrechnerbefinden!
befinden!
39
Beispiel: DateClient.java
import java.rmi.*;
import java.util.Date;
Adresse der
public class DatumClient {
RMIRegistry
public static void main(String[] args) {
try { Datum dateServer =
(Datum) Naming.lookup("//:1099/DateServer");
Date when = dateServer.getDate();
System.out.println(when);
} catch (Exception e) {
System.out.println("DatumClient: Exception.");
System.out.println(e.getMessage()); } } }
••Implementiert
Implementiertden
denClient
Client
••Muss
Musssich
sichauch
auchnur
nurauf
aufdem
demClientrechner
Clientrechnerbefinden!
befinden!
40
Java-RMI: Automatische Objektaktivierung
‹
‹
‹
‹
In großen Systemen mit Tausenden von Objekten ist es
unrealistisch, immer alle Objekte im Speicher aktiv zu haben.
Mit Hilfe des Java-Aktivierungsmechanismus können Objekte
persistent gemacht und erst bei Bedarf wieder instanziiert
werden.
Dieses Objektmanagement wird durch den Dämon rmid
realisiert.
Jini basiert weitgehend auf diesem Aktivierungsmechanismus.
41
Middleware
Applikationen, Dienste
Middleware
Verteilungsplattform:
Transparenz der
•Heterogenität existierender
Hardware und Betriebssysteme
•Verteilung
Betriebssystem
Plattform
Computer- und Netzwerkhardware
42
Definition von Middleware
‹
‹
"Middleware is the intersection of the stuff that
network engineers don't want to do with the stuff that
applications developers don't want to do.“
"Middleware today encompasses everything to the right of the
clients and to the left of the legacy systems. It resides above
the OS and below the application logic.“
‹
"Middleware: the slash in client / server.“
‹
“… some think of the Web as the ultimate in middleware.“
43
Arten von Middleware
‹
Generisch
–
–
–
–
‹
Object Request Broker
Remote Procedure Call (RPC)
Message Passing
Virtual Shared Memory
Objektzugriff übers Netz
Aufruf einer entfernten Prozedur
Send/Receive–Kommunikation
Zugriff auf virtuell gemeinsamen
Speicher
Speziell
–
–
–
–
–
Dateitransfer
Datenbankzugriff
Transaktionsverarbeitung
Groupware
Workflow
Fernzugriff auf gemeinsame Dateien
Datenzugriff auf entfernte DB
Koordination verteilter Transaktionen
Zusammenarbeit verteilter Gruppen
Organisation arbeitsteiliger Prozesse
44
Standardisierung von Middleware
‹
‹
‹
‹
(Offizielle) Internationale Standardisierung
– ISO – International Standardisation Organisation
– ITU – International Telecommunication Union
– DIN, ANSI, BSI, AFNOR, ...
Semi-offizielle Internationale Standardisierung
– OpenGroup (früher X/OPEN bzw. OSF)
– IEEE – Institute of Electrical and Electronic Engineers
– IETF – Internet Engineering Taskforce
– W3C – World Wide Web Consortium
Konsortien
– OSF – Open Software Foundation (heute: OpenGroup)
– OMG – Object Management Group
"Industriestandards"
45
Object Management Group (OMG)
‹
Gründung: April 1989
‹
Ziele:
– Interoperabilität
– Anwendungsintegration
– Portabilität
‹
Mitglieder:
in heterogenen Umgebungen
auf der Basis des Objektmodells
Distributed Component
Object Model (DCOM)
– über 800 Mitglieder
– darunter: Apple, AT&T, DEC, HP, IBM, Microsoft, SUN,...
‹
Entwicklungsprozeß: Request for Proposal (RFP)
46
Object Management Architecture (OMA)
Application
Objects
Common
Facilities
‹
‹
ORB
‹
‹
Common Object Services
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
47
Application
Objects
Common
Facilities
Application Objects: z.B. Business-Objekte
ORB
Andere Schnittstellen
Common Object Services
‹
PräsentationsObjekt
Komponenten
eines BusinessObjektes
– kapseln Speicher, Metadaten,
Parallelität u. Regeln einer aktiven
Business-Einheit
– legt fest, wie auf Änderungen in
View/Modell reagiert wird
MVC
MVC
‹
BusinessProzeßObjekt
Business-Prozeßobjekte (C, Server)
– kapseln Business-Logik
– Verwaltung vorwiegend langlebiger
Prozesse (Workflow, Transaktion)
BusinessObjekt
‹
Andere
Business-Objekte
Business-Objekte (M, Server)
Präsentationsobjekte (V, Client)
– grafische Darstellung des Objektes
– unterschiedliche Präsentationen möglich
Dokument
Server
48
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)
49
CORBA Interoperabilität
Systemgrenze
Stub
A (Client)
Skeleton
A‘
ORB von A
B‘ B (Server)
IIOP
ORB von B
ORB
50
CORBA Objekte
‹
Client
‹
‹
Request
Result
‹
Schnittstelle
Op1 Op2 Op3 Op4
‹
Objekt
‹
Objekt besteht aus Zustand und
Operationen
Schnittstelle beschreibt Menge von
Operationen für die Clients
Operation entspricht angebotenem
Service und hat Signatur
Signatur ist eine Spezifikation von
Argument- und Ergebnisparametern,
Exceptions, Kontext
Vererbung kann benutzt werden, um
neue Schnittstellen aus anderen
Schnittstellen zusammenzusetzen
kann überall im Netz existieren
51
Interface Definition Language
IDL
C
IDL
C++
IDL
COBOL
IDL
‹
‹
Client/Server
Ada
‹
ORB
‹
‹
Java
IDL
Smalltalk
IDL
‹
‹
Basismechanismus zur Definition von
Schnittstellen (Standard)
Unabhängig von spezieller Sprache (deklarativ, 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
52
Struktur einer CORBA-IDL-Datei
module <identifier>
{ <type declarations>;
<constant declarations>;
<exception declaration>;
interface <identifier> [:<inheritance>]
{ <type declarations>;
<constant declarations>;
<attribute declarations>;
<exception declaration>;
[op_type]<identifiere>(<parameters>)
[raises exception][context];
...
[op_type]<identifiere>(<parameters>)
[raises exception][context];
...
}
interface <identifier> [:<inheritance>]
...}
Definiert einen
Namenskontext
Definiert eine
CORBA-Klasse
Definiert eine
Methode
53
Struktur eines CORBA-2.*-ORB‘s I
Object
Implementation
Client
Implementation
Repository
Interface
Repository
Dynamic Skeleton
Static
Object
Invocation
Adapter Skeletons
ORB
Interface
Client IDL
Stubs
Dynamic
Invocation
Object Request Broker Core (IIOP)
54
Aufbau eines CORBA-Servers
Applikationscode
aktive Servants
Hauptprogramm
Servant
Activator
main (String args[]) {
mainorb
(String args[]) {
ORB
orb
=ORB
ORB.init(args);
= ORB.init(args);
orb.connect
(
orb.connect
(
new
AServant()
); new AServant()
);
orb.connect(
orb.connect(
new
BServant()
); new BServant()
);
orb.run();
} orb.run();
}
Default
statisch
Servant (mit Skeleton)
ii
ORBSchnittstelle
dynamisch
(ohne Skeleton)
...
1 2 ... ... n ...
Servant Default
Active Object
Activator
Servant
Map
Fabrik für
Portable Object Adapter
Objektreferenzen
Request Interceptors
für verschiedene
Event Marshalling Services (optional)
Loop
Engine
ORB-Kern
Netzwerk
55
Struktur eines CORBA-2.*-ORB‘s: Client
‹
IDL-Stub‘s (Client)
–
–
–
–
‹
Schnittstelle zu Objektdiensten (Proxy)
Generierung durch IDL-Compiler
Enthält Code für De-/Kodierung der Operationen u. Partameter
Enthält Header-Dateien für Hochsprachen
Dynamic Invocation Interface (DII)
– Finden von aufrufbaren Methoden zur Laufzeit
– Standard API‘s für Suche in Metadaten, Parametergenerierung, Remote-Aufruf
‹
Interface Repository API
– Lesen u. Modifizieren von allen (registrierten) Komponentenschnittstellen
– „dynamische Metadatenbank“ für ORB‘s
‹
ORB Interface
– API-FUnktionen für lokale Dienste
– z.B. Konvertierung Objektreferenz in Zeichenkette u. zurück
56
Struktur eines CORBA-2.*-ORB‘s: Server
‹
IDL-Stubs (Server)
– statische Schnittstelle (Skeletons) der angebotenen Dienste
– werden vom IDL Compiler erzeugt
‹
Dynamic Skeleton Interface (DSI)
–
–
–
–
‹
Object Adapter
–
–
–
–
‹
Laufzeit-Verknüpfungsmechanismus
für Methodenaufrufe von Komponenten, die keine IDL-basierte Stubs haben
z.B. für generische Bridges zwischen verschiedenen ORB‘s
z.B. dynamische Objektimplementierung
Laufzeitumgebung für Instanzen von Server-Objekten
übergibt ihnen die Anfragen und weist ihnen Objekt-ID‘s (Objektreferenzen) zu
registriert unterstützte Klassen u. Laufzeitinstanzen im Implementation Repository
Standard Adapter: Portable Object Adapter (POA), ehemals Basic Object Adapter
(BOA)
Implementation Repository
– Laufzeitverzeichnis über unterstützte Klassen, Objektinstanzen, Objekt-ID‘s
– (gemeinsamer) Speicher für zusätzliche Informationen, z.B. Prüfprotokolle,
Sicherheit, Trace-Informationen
57
Methodenaufruf über CORBA
Client
Anwendung
1) Aufruf
IDL Stub
2) Parameter einpacken
und Aufruf weiterleiten
Objekt
Implementierung
5) Auspacken und
Aufruf
IDL Skeletton
4) Weiterleiten an
Schnittstelle
Object Adapter
4b) Aktivieren
Implementation
Repository
4a) Ermitteln der
Implementierung
Object Request Broker Core
3)Transport über den ORB
58
Client- und serverseitige IDL-Implementierung
Schnittstellendesigner
interfaces.idl
interfaces.idl
Programmierer
Anwendungsentwickler
IDL-Java
IDL-Java
Compiler
Compiler
client.jar
client.jar
stubs.jar
stubs.jar
Client
IDL-C++
IDL-C++
Compiler
Compiler
types.hh
types.hh
stubs.cc
stubs.cc
skels.cc
skels.cc
servants.cc
servants.cc
Server
59
Von der IDL zu Schnittstellen-Stubs I
1
Schreibe Deine IDL Definitionen
2
Precompiler
Skeletons
Füge dem Skeleton den Server
Implementierungscode zu
3
7
4
Compiler
Instanziiere
5
Interface
Repository
Objekt
Adapter
6
Client IDL
Stubs
Client
Server IDL
Skeletons
Objekt
Implementierung
Implementation
Repository
Server
60
Von der IDL zu Schnittstellen-Stubs II
‹
Definiere die Objektklassen mit Hilfe der IDL: 1
Welche Operationen eines Objektes sind verfügbar und wie werden sie aufgerufen ?
‹
Lasse die IDL-Datei durch einen Sprachen-Precompiler laufen:
Generierung der IDL-Dateien und der Sprach-Skeletons.
‹
Füge dem Skeleton den Implementierungscode zu:
Erzeugung der Server-Klassen.
‹
2
3
Kompiliere den Code:
4
Importdateien für Schnittstellenverzeichnis, Client-Stubs und Server-Skeletons
Binde die Klassendefinitionen mit den Schnittstellenverzeichnissen 5
‹6 Lasse die Laufzeitobjekte im Implementierungsverzeichnis registrieren
‹
Erzeuge für die Objekte auf dem Server Instanzen 7
‹
Im folgenden wird ein einfaches Beispiel unter JDK 1.4.1 gezeigt.
61
Schritt 1: Bank1.idl
Definiert den
Namenskontext
Definiert die
CORBA-Klasse
IKonto1
module Bank1 {
interface IKonto1 {
Definiert die
Methoden
double einzahlen (in double betrag);
einzahlen und
double abfragen ();
abfragen
};
};
62
Schritt 2: IDL-Compiler
Zuordnung
Schnittstelleohne
ohne
Zuordnung
Schnittstelle
Referenz--Klasse
Klasse
Vererbungshierarchie(Tie)
(Tie)
Referenz
Vererbungshierarchie
Verwaltung
Verwaltung
Vondem
demCompiler
Compiler
out/inout-Argumente
Von
out/inout-Argumente
idlj erzeugt
erzeugt
idlj
63
Schritt 2: IDL-Compiler
‹
ab dem JDK 1.3 ist der IDL-Compiler idlj enthalten. Hier JDK 1.4.1
‹
Grundsätzlich sind (auf der Seite des Servers) zwei Modelle vorgesehen:
– Inheritance Model (Klassen-Vererbung)
– Tie Delegation Model (Schnittstellen-Vererbung)
Da Java keine mehrfache Klassenvererbung erlaubt, kann es bei
vorhandenem Code nötig sein, dieses Modell zu wählen.
‹
‹
Parameter -oldImplBase: Existiert aus Gründen der Kompatibilität zu älteren
Versionen. Vererbungsstruktur wie folgt:
IKonto1Impl
_IKonto1ImplBase
IKonto1
CORBA.Object
Parameter -oldImplBase: Die Tie-Anbindung des Servants ermöglicht die
Implementation über die Schnittstelle _IKonto1Operations, die in keine
Vererbungshierarchie eingebunden ist.
64
Schritt 3: Implementierung IKonto1Impl.java
import Bank1.*;
public class IKonto1Impl extends _IKonto1ImplBase {
double kontostand;
public static boolean debug = true;
public void IKontoImpl () {
kontostand = 0.0;
}
public double einzahlen (double betrag) {
double k = kontostand;
k += betrag;
return kontostand = k;
}
public double abfragen () {
double k = kontostand;
return kontostand = k;
}
}
65
Schritt 3: Implementierung SunServer.java
import java.io.*;
import java.util.*;
import org.omg.CORBA.*;
import org.omg.CosNaming.*;
//Importiere Server-Skeleton
import Bank1.*;
public class ServerSun {
public static void main (String args[]) {
try { Properties props = new Properties();
props.put("org.omg.CORBA.ORBInitialPort", "1050");
props.put("org.omg.CORBA.ORBInitialHost", "localhost");
ORB orb = ORB.init (args, props);
// NamingContext besorgen
NamingContextExt ctx =
NamingContextExtHelper.narrow(
orb.resolve_initial_references("NameService"));
// Weiter auf nächster Folie
66
Schritt 3: Implementierung SunServer.java
// Neue Instanz der Implementierung
IKonto1Impl konto = new IKonto1Impl ();
// Namen für neue Instanz vergeben und
// Referenz beim Namingservice anmelden
NameComponent name[] = ctx.to_name("Konto");
ctx.rebind(name, konto);
// Do nothing and run...
java.lang.Object sync = new java.lang.Object ();
synchronized (sync) {
try { sync.wait();
} catch (InterruptedException e) {
System.out.println (e); } }
} catch (Exception ex) {
System.err.println (ex);
System.exit (1); } } }
67
Schritt 3: Client.java
import java.io.*;
import java.util.*;
import org.omg.CORBA.*;
import org.omg.CosNaming.*;
//Importiere den Client-Stub
import Bank1.*;
public class Client {
public static void demo (IKonto1 konto) {
System.out.println ("Kontostand alt " + konto.abfragen());
System.out.println ("Kontostand " + konto.einzahlen(50.0));
}
// Weiter auf nächtser Folie
68
Schritt 3: Client.java
public static void main (String args[]) {
try {Properties props = new Properties();
props.put("org.omg.CORBA.ORBInitialPort", "1050");
props.put("org.omg.CORBA.ORBInitialHost", "localhost");
ORB orb = ORB.init(args, props);
// NamingContext besorgen
NamingContextExt nc =
NamingContextExtHelper.narrow(
orb.resolve_initial_references("NameService"));
// Objektreferenz mit Namen "Konto" besorgen
org.omg.CORBA.Object obj = nc.resolve_str("Konto");
// Narrow-Cast und aufrufen
IKonto1 konto = IKonto1Helper.narrow (obj);
demo(konto);
} catch (Exception ex) {
System.err.println (ex);
System.exit(1); } } }
69
Abschluss: Starten des Servers
‹
‹
Der CORBA-Namingservice wird gestartet mit orbd
Mit Hilfe des Parameters –ORBInitialPort kann der Port
für den Service vorgegeben werden.
70
Abschluss: Starten des Clients
71
Prozeß eines dynamischen Aufrufs
‹
Name der Schnittstelle verschaffen:
get_interface()
‹
Methodenbeschreibung verschaffen:
lookup_name(); describe();
‹
Argumentenliste erzeugen:
create_list();
add_item() ... add_item() ... add_item();
‹
Anfrage erzeugen:
create_request(Object Reference, Method, Argument List);
‹
Entfernte Objektmethode aufrufen:
– RPC verwenden: invoke();
– Send/Receive: send_deferred(); get_response();
– Datagramm: send_oneway();
72
CORBA 3.0
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
‹
Messaging (MOM) (asynchroner Methodenaufruf)
Server Portability (Portable Object Adapter & Server
Framework Adapter)
Multiple Interface & Versioning
Business Objects Framework (BOF)
Java Bindings
Pass-by-value
Mobile Agents
CORBA Components (CCM)
Real Time CORBA
CORBA Firewall
Minimum CORBA („CORBA für eingebettete Systeme“)
73
Idee: Komponenten
‹
‹
‹
‹
Komponente = höhere Abstraktionsform von Objekten
– Bestehen aus einem oder mehreren Objekten, welche in einen
Container gepackt werden
Komponenten interagieren u. kooperieren über verschiedene BSplattformen, Sprachen, etc. hinweg
– Bausteine für multitiered Anwendungen
Anwendungen bestehen aus (dynamischen) Mengen interagierender
Komponenten (monolithische Anwendungen aufbrechen)
Dieses Modell hat enorme Konsequenzen bzgl.
–
–
–
–
–
‹
Entwurf von Software („Lego-Bausteine“)
Vertrieb von Software („add-on Komponenten“, „late customizing“)
Pflege von Software (Wiederverwendung, Varianten)
Funktionalität (aktive, ggf. mobile Objekte)
Marketing (Komponenten-Markt)
Erfordert Standards und Infrastrukturservices
– für die Interaktion der Komponenten
– für die Komponenten selbst (Versionskontrolle, Konfiguration)
74
Häufigkeit der
Wiederverwendung
Motivation
Klassen
Framework
Komponente
Vorfabrizierte
Anwendung
Einsparung
75
J2EE Komponentenplattform
Die Java 2 Enterprise Edition (J2EE) ist eine Plattform für die
komponentenorientierte Entwicklung von Anwendungen.
Sie besteht aus:
‹ Einer Spezifikation / Guidelines / Testsuite
‹ Java Komponenten
– Java Beans (clientseitig)
– Java Server Pages und Servlets
– Enterprise Java Beans (serverseitig)
‹ Verschiedene Container: Application, Web, EJB
‹ Java Naming and Directory Interface (JNDI)
76
EJB Introduction
„An Enterprise JavaBeans (EJB ) component, or enterprise bean, is a body
of code having fields and methods to implement modules of business
logic. You can think of an enterprise bean as a building block that can be
used alone or with other enterprise beans to execute business logic on the
J2EE server.“
(J2EE Tutorial: http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Overview7.html#wp86355)
‹
‹
‹
EJB 2.0 ist Bestandteil der J2EE 1.4 Spezifikation
EJB 3.0 wird Bestandteil der J2EE 5.0 Spezifikation
EJB Container bildet die Laufzeitumgebung (Runtime
Environment)
77
EJB / J2EE Architektur
78
EJB Container
“Manages the execution of enterprise beans for J2EE applications. Enterprise
beans and their container run on the J2EE server. “
(J2EE Tutorial: http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Overview3.html#wp79828)
‹
Bietet folgende Dienste für EJBs
– Security Modelle
– Unterstützung für Transaktionen
– Naming Services (JNDI registry & lookup)
– Initiiert und kontrolliert den Lebenszyklus der Beans
– Datenpersistenz
– Datenbankverbindungen
– Ressourcen-Pooling
79
EJB Einsatz (Deployment)
‹
‹
Enterprise JAR Archiv enthält:
– Deployment Descriptor:
XML file (persistence type, transaction
attributes…)
– Interfaces (Remote und Home
Interfaces für den Komponentenzugriff)
– EJB classes (Implementierungen der
Interfaces)
– Helper classes (… was man sonst
braucht)
EJB-JAR Module können
zusammengefasst werden in einem
Enterprise Application Archive (EAR).
Siehe http://java.sun.com/xml/ns/j2ee/ für Details über deployment descriptors.
80
EJB-JAR.XML
<ejb-jar>
<display-name>
MailApplicationEJB
</display-name>
<enterprise-beans>
<session>
<ejb-name>
MailReader
</ejb-name>
<home>
. . .MailReaderSessionHome
</home>
<remote>
. . .MailReaderSession
</remote>
<ejb-class>
. . .MailReaderSessionBean
</ejb-class>
<session-type>
Stateful
</session-type>
<transaction-type>
Container
</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>
81
EJB Typen
‹
‹
‹
1
Session Bean – wird für einen einzelnen Client ausgeführt
– An die Lebenszeit einer Session gebunden
Entity Bean – repräsentiert objektorientierte Sicht auf Daten
(z.B. aus einer Datenbank)
– Kann von mehreren Clients gleichzeitig angesprochen
werden
– Überdauert Client Session und Serverneustarts.
Message-Driven Bean – reagiert auf JMS1 Nachrichten
– zustandslos, kommuniziert asynchron
Java Message Service - http://java.sun.com/products/jms/
82
Session Beans
‹
‹
Session Bean Eigenschaften:
– Verbergen Komplexität der Business Logic
– Nicht persistent
– Repräsentieren eine (interaktive) Session für einen Client
– Können nicht zwischen Clients geteilt werden
– Beenden mit dem Client
Session Bean Modi:
– Stateless Session Beans:
Variablenzustände leben nur während Methodenaufrufen
– Stateful Session Beans:
Variablenzustände bestehen während der Clientsitzung
83
Entity Beans
‹
‹
Entity Bean Eigenschaften:
– Erlauben geteilten Zugriff auf persistente Datenspeicher
(z.B. relationale Datenbank)
– Können auch transiente Attribute besitzen
– Besitzen unique object identifier (primary key)
– Können in Relation zu anderen Entity Beans stehen
Persistenzarten:
– Bean-managed:
Bean verwaltet Zustände selbst, z.B. DB-Zugriffe
– Container-managed:
Container organisiert Datenzugriff (Portabilität!), hierzu
EJB Query language (EJB QL)
84
Message-Driven Beans
‹
Message-Driven Bean Eigenschaften:
– Asynchrone Prozessierung eingehender Messages
– Empfängt JMS Messages von Clients
– Verarbeitet Messages einzeln.
– Wird asynchron erzeugt
– Lebt gewöhnlich nur kurz.
– Repräsentiert keine persistenten Daten (zustandslos),
kann aber auf persistente Daten zugreifen.
– Kann transaktionsorientiert arbeiten.
– Message-Driven Beans haben keine eigenen Interface
Definitionen, werden also nicht direkt von Clients
angesprochen
85
Lebenszyklus von EJBs
Stateful Session Bean
Stateless Session Bean
Entity Bean
Message-Driven Bean
86
Zugriff auf Beans
‹
‹
Remote Zugriff
– Ort des Beans ist für den Client transparent
– Zugriff über JVMs hinweg möglich
– Zu implementierende Schnittstellen:
W Home Interface
W Remote Interface
Lokaler Zugriff
– Ort des Beans ist für den Client nicht transparent
– Bean und Client müssen in der gleichen JVM liegen
– Zu implementierende Schnittstellen:
W LocalHome Interface
W Local Interface
87
Remote Interface (Session-, Entity-Beans)
‹
‹
‹
‹
Namenskonvention: classname
Erweitert EJBObject Interface
Beschreibt die Schnittstellen der Anwendungslogik (Business
logic) des Beans
Beispiel:
public interface MailReaderSession extends EJBObject {
public String getVersion() throws RemoteException;
public String getUserName() throws RemoteException;
// mehr Business Logic ...
}
88
Home Interface (Session-, Entity-Beans)
Namenskonvention: classnameHome
‹ Erweitert EJBHome Interface
‹ LifeCylce Methoden (create, remove)
‹ Finder Methoden (Entity Beans)
‹ Das Bean muss für jede create(…)-Methode des Interfaces
eine entsprechende ejbCreate(…)-Methode implementieren
Beispiel:
‹
public interface MailReaderSessionHome extends EJBHome {
public MailReaderSession create() throws RemoteException,
CreateException;
// evt. weitere create(…) Methoden
}
89
Local Interface
‹
‹
‹
‹
Namenskonvention: classnameLocal
Erweitert EJBLocalObject
Beschreibt die Schnittstellen der Anwendungslogik (Business
logic) des Beans
Beispiel:
public interface MailReaderSessionLocal extends EJBLocalObject
{
public String getVersion() throws RemoteException;
public String getUserName() throws RemoteException;
// mehr Business Logic ...
}
90
LocalHome Interface
Namenskonvention: classnameLocalHome
‹
Erweitert EJBLocalHome Interface
‹
LifeCylce Methoden (create, remove)
‹
Finder Methoden (Entity Beans)
‹
Das Bean muss für jede create(…)-Methode des Interfaces eine
entsprechende ejbCreate(…)-Methode implementieren
Beispiel:
‹
public interface MailReaderSessionLocalHome extends EJBLocalHome {
public MailReaderSession create() throws RemoteException,
CreateException;
// evt. weitere create(…) Methoden o. find... Methoden
}
91
(Enterprise) Bean Klasse
‹
Namenskonvention: classname
‹
Implementiert SessionBean, EntityBean oder MessageDrivenBean
‹
‹
Konkrete Implementierung der Schnittstellen des Home- und des RemoteInterfaces
Enthält Methoden die während des Bean Lifecycles vom EJB Kontainer
aufgerufen werden (abhängig vom Typ des Beans) z.B.:
– ejbCreate (analog zu den create(…)-Methoden des Home Interfaces)
– ejbActivate()
– ejbPassivate()
92
Bean Implementierung
(SessionBean, Stateful)
public class MailReaderSessionBean implements SessionBean {
private String username = null;
private String password = null;
public void ejbCreate() throws CreateException{ }
public void ejbCreate(String login, String password) throws CreateException {
this.username = login;
this.password = password;
}
public void setSessionContext(SessionContext context) throws EJBException,
RemoteException { }
public void ejbRemove() throws EJBException, RemoteException { }
public void ejbActivate() throws EJBException, RemoteException { }
public void ejbPassivate() throws EJBException, RemoteException { }
public String getVersion() { return "Version 0.1"; }
public String getUserName() { return this.username; }
}
93
Bean Client
import
import
import
import
import
java.util.Hashtable;
javax.naming.Context;
javax.naming.InitialContext;
javax.naming.NamingException;
javax.rmi.PortableRemoteObject;
import sample.mailapp.beans.MailReaderSession;
import sample.mailapp.beans.MailReaderSessionHome;
public class MailCient {
public static void main(String[] args) {
String version = "no version";
InitialContext jndiContext = null;
try {
jndiContext = new InitialContext(); // initial context properties are read
from the jndi.properties file
}
catch (NamingException e) {
e.printStackTrace();
}
… continue on next slide
94
Bean Client (cont.)
…
// Retrieve the home object.
MailReaderSession mailSession = null;
try {
Object obj = jndiContext.lookup("MailReader");
MailReaderSessionHome home = (MailReaderSessionHome)
PortableRemoteObject.narrow(obj, MailReaderSessionHome.class);
mailSession = home.create("me","123");
version = mailSession.getVersion();
System.out.println("Is vesion (" + version + ")");
System.out.println("User ("+ mailSession.getUserName()+")");
}
catch (Exception e1) {
e1.printStackTrace();
}
}
95
Message Driven Beans
‹
‹
‹
‹
Im Gegensatz zu Entity o. Sessions Beans keine Local, Home
o. Remote Interfaces
Werden an eine Message-Queue des EJB Kontainers
gebunden
Muss MessageListener Interface implementieren
(onMessage(Message aMessage) Methode behandelt
eingehende Nachrichten)
Jeweils genau eine ejbCreate und ejbRemove Methode
96
Web Services
‹
‹
‹
Grundidee: unvereinbare Welten miteinander zu verknüpfen und
kommunizieren lassen.
Web Services sind Dienste (Softwarekomponenten), die im Web zur
Verfügung stehen und miteinander kommunizieren.
Offene und Hersteller unabhängige Standards:
– Eindeutige Identifizierung eines Dienstes (URI)
– Autonome Dienste, d.h. die Verarbeitung einer Nachricht eines Dienstes
kann von außen nicht beeinflusst werden.
– Einheitliche „mark up“ Sprache für die Kommunikation (XML) mittels
Internetprotokollen (z.B. HTTP, SMTP)
– Einheitliches Nachrichtenformat zum Informationsaustausch (SOAP)
– Einheitliches Format für die Schnittstellen-/Servicebeschreibung
(WSDL)
– Gemeinsames Verzeichnis, um Services auffindbar zu machen (UDDI)
97
Begriffe
Web
Service
Universal
UDDI
Description
Discovery and
XML
Integration
Web
Service
WSDL
Description
Language
XML
Simple
Object
Access
SOAP
Protocol
1. Namensdienst
(optional)
2. Schnittstellen
definitionssprache
(optional)
3. Nachrichtenformat
XML
98
Rollen
99
Struktur eines Web Service
100
SOAP
‹
‹
‹
‹
‹
SOAP Envelope (XML): strukturiertes und typisiertes XML-Dokument,
zusätzliche Kontroll-Daten, z.B. bzgl. Transaktionssemantik, Sicherheit,
Zuverlässigkeit
SOAP Transport Binding: Für Kommunikation genutztes Netzwerkprotokoll
(Standard: HTTP, möglich u.a. IIOP)
SOAP Encoding Rules: Definition, wie (komplexe) Parameter und
Ergebniswerte serialisiert werden
SOAP RPC Mechanismus: Vorgänger ist XML/RPC
SOAP Intermediaries: Bearbeiten ggf. die Nachricht auf dem Weg vom
Sender zum Empfänger (z.B. Protokollierung, Abrechnung)
101
Typische SOAP
Transaktion:
RPC via HTTP
102
SOAP über HTTP: Anfrage
103
SOAP über HTTP: Antwort
104
SOAP Programming: Bean Service
public MyBean scramble(MyBean bean){
//create return value
MyBean retVal = new MyBean();
//write text backwards (scramble text value)
String text = "";
for(int i =bean.getText().length();i>0;i--)
text+=bean.getText().substring(i-1,i);
//set new text value
retVal.setText(text);
//return scrambled object
return(retVal);
}
105
SOAP Programming: Bean Client
…
bean = new MyBean();
call = (Call)service.createCall();
//create bean
//create call
//create qualified name for attachment type (DataHandler).
QName qname = new QName("http://myBean.org","MyBean",“my");
//add (de-)serializer for bean
call.registerTypeMapping(MyBean.class, qname, BeanSerializerFactory.class, BeanDeserializerFactory.class);
call.addParameter("bean", qname, ParameterMode.IN);
//register (passed) parameter for bean
call.setReturnType(qname);
//specify expected return type of web service method
call.setOperationName(new QName("scramble"));
//specify web service method
call.setTargetEndpointAddress(HOST + SERVICE_PATH);
//specify web service URI
Object ret = call.invoke(new Object[] {bean});
} catch (Exception ex) {
//invoke web service with passing bean as parameter.
106
WSDL
‹
‹
‹
‹
‹
Beschreibt abstrakt, d.h. unabhängig vom Nachrichtenformat
oder Netzwerkprotokoll, Web Services als eine Menge von
Zugriffsendpunkten, die untereinander Nachrichten auf
prozedur- oder dokumentenorientierter Weise austauschen
WSDL ist eine XML-Grammatik
Beschreibung beinhaltet Informationen über:
– Funktionsweisen eines Web Services
Was
– zulässigen Datenformate (types)
Wie
– Form der Operationsaufrufe (PortType)
Wie
– Ort des Web Services (service)
Wo
WSDL ist ein Rezept, das dazu dient, die Details der
Kommunikation zwischen Anwendungen zu automatisieren.
Version 2.0 – W3C Candidate Recommendation (2006)
107
WSDL Beispiel (V1.1)
Datentypen und
Nachrichten
<types> </types>
<message name="getLastTradePriceRequest">
<part name="companyName type="xsd:string”/>
</message>
<message name="getLastTradePriceResponse">
<part name="price" type="xsd:float"/>
</message>
<portType name="StockQuotePortType">
<operation name="getLastTradePrice">
<input
message="myns:getLastTradePriceRequest"/>
<output message="myns:getLastTradePriceResponse"/>
</operation>
</ portType>
Aufrufbare
Methoden
108
WSDL Beispiel (V1.1)
Client –Server
Kommunikation
<binding name="StockQuoteSoapBinding„
type="tns:StockQuotePortType">
<soap:binding style=“rpc" transport=“http"/>
<operation name=“GetLastTradePrice">
Soap-spezifische Einstellungen...
</operation>
</binding>
<service name="StockQuoteService">
<port name="StockQuotePort"
binding="tns:StockQuoteBinding">
<soap:address
location=“http://www.stockquoteserver.com/stockquote"/>
</port>
Ort des
</service>
Web Services
109
UDDI
‹
‹
‹
‹
‹
‹
Es gab bisher keinen allgemeinen Standard, zum Auffinden
von Diensten. Yahoo und Google sind unzureichend.
Plattformunabhängiger universeller Rahmen (UNIVERSAL),
– um Services zu beschreiben (DESCRIPTION),
– Unternehmen zu finden (DISCOVERY)
– und die Services zu integrieren (INTEGRATION)
Globaler Verzeichnisdienst
Entspricht einer verteilten Datenbank (UBR: UDDI Business
Registry)
UDDI Kommunikation mittels SOAP
UDDI API aus XML Elementen
110
Informationen
White
Pages
Adresse, Kontaktinformationen,
Ansprechpartner
Yellow
Pages
Branchenverzeichnis, Kategorisierung
nach Unternehmen: Einordnung des
Unternehmens gemäß Geschäftsbereich
Green
Pages
technische Informationen zu angebotenen
Dienstleistungen und Verweise zu
genauen Spezifikationen
111
Policies
‹
‹
‹
‹
Zur Beschreibung von Qualitätseigenschaften eines
Dienstes, wie etwa Transaktionsunterstützung, Sicherheit,
oder geschäftlich relevanten Informationen, wie etwa
Kosten, Zahlungsart.
Grundelemente: Assertion. Assertion für Sicherheit geben
z.B. Verschlüsselungsverfahren vor. Mittels Operatoren und
Assertions können komplexere Policy-Ausdrücke formuliert
werden.
Zuordnung mittels Attachments (Referenzierung der Policy in
einem Attachment). Zuordnung zu einzelnen Web Services,
einzelnen Operationen eines Dienstes oder einzelnen
Nachrichten möglich.
Effektive Policy eines Elementes setzt sich aus den Policies
der „übergeordneten“ Policies und der eignen zusammen.
112
Policies
<Policy …
xmlns:f1=„http://frank.com/p
olicies“>
Stammkunden und Laufkundschaft
<ExactlyOne>
werden unterschiedlich
<All Id=„StammKunde“>
behandelt:
<f1:MonatlicheZahlung/>
Stammkunden zahlen monatlich
<f1:DatenGeheimhaltung/>
und deren Daten werden geheim
</All>
gehalten.
<All Id=„Laufkundschaft“>
Laufkundschaft zahlt für jede
<f1:ZahlungProNutzung/>
einzelne Nutzung mit Kreditkarte
<f1:Kreditkarte/>
und deren Daten werden
<f1:DatenWeitergabe/>
weitergegeben.
</All>
f1 ist der Namensraum des
</ExactlyOne>
Anwenders.
</Policy>
113