3 - J (suc3)

ein Mechanismus in Java, mit welchem entfernte Objekte bzw. deren Angebote genutzt werden können

ein einfaches Framework für die Entwicklung von verteilten Anwendungen in Java

werden Details der Netzwerkkommunikation "ausgeblendet"

wird die Verteilung von Objekten durch einen Namensdienst (RMI-Registry) ermöglicht

wird das dynamische Laden vom Code ermöglicht$

Entfernte Objekte (Server) sind "multithreaded"

RMI bietet (von Haus aus) eine synchrone Kommunikation zwischen Client und Server (entferntes Objekt)

RMI basiert ausschliesslich auf OO-Konzepten der Sprache Java

die Integration mit anderen Verteilungstechniken, insbesondere mit anderen Programmiersprachen, sehr schwierig und an sich nur über IIOP möglich

RMI verwendet den Namensdienst

Die Synchronisation bei konkurrierenden Zugriffen
wird nicht von RMI realisiert

Client:

nimmt Dienste von entferntem Objekten in Anspruch

fragt dazu beim Namensdienst nach, ob ein passendes Objekt für den gewünschten Dienst registriert wurde

ruft Methoden des Entfernten Objekts auf

Server:

erzeugt das entfernte Objekt und meldet es beim Namensdienst an (Registrierung)

meldet das entfernte Objekt beim Namensdienst ab, wenn es nicht mehr benötigt wird (De- Registrierung)

werden durch rmic aus der Klasse erzeugt, welche das entfernte Objekt implementiert

kümmern sich um die Übertragung von Daten über das Netzwerk

Das Ver- und Entpacken von Nachrichten (Marshalling und Unmarshalling) wird automatisch von Stub und Skeleton erledigt

das Registrieren von EO zu ermöglichen (binding)

das Finden des EO zu ermöglichen (lookup)

Namensdienst wird auf dem Host-System (Server) ausgeführt

Der Server kann das EO bei dem Namensdienst registrieren

Der Client kann beim Namensdienst nachfragen, ob ein passendes EO für den gewünschten Dienst zur Verfügung steht bzw. registriert wurde

bild

bild

public interface Adder extends Remote {  

  int add(int x, int y) throws RemoteException;
 }

}

public class AdderImpl extends UnicastRemoteObject implements Adder {

alle Methoden: throws Remoteexception

=> standardkonstruktor mit RemoteException

den SecurityManger installieren, um sich von "bösartigen" Stubs zu schützen

den Namensdienst mit Hilfe der Klasse java.rmi.Naming finden

beim Namensdienst nachfragen, ob das gewünschte entfernte Objekt vorhanden ist und eine Referenz auf dieses Objekt erhalten (Methode lookup)

den Typ der erhaltenen Referenz auf den Typ der entfernten Schnittstelle casten (Methode lookup liefet java.rmi.Remote-Typ zurück)

Nachdem alle Klassen erstellt und kompiliert wurden, müssen diese verteilt werden

Auf der Server-Seite müssen folgende Klassen im CLASSPATH zu finden sein:

entfernte Schnittstelle (Adder.class)

entfernte Klasse (AdderImpl.class)

Server-Klasse (die Methode 'main' enthält)

Auf der Client-Seite müssen folgende Klassen im CLASSPATH zu finden sein:

entfernte Schnittstelle (Adder.class)

die Client-Klasse (die Methode 'main' enthält)

die adder.policy im ROOT-Verzeichnis

Primitive Datentypen (int, long, …) werden by value übertragen

Lokale Objekte

werden by value übertragen (echte Kopien)

Müssen serialisiert (Stub), übertragen und deserialisiert (Skeleton) werden

Entfernte Objekte werden by reference übertragen.

Das bedeutet, dass nur der Stub des entfernten Objekts übertragen wird und nicht die echte Kopie des entfernten Objekts.

Die Stub-Klasse wird vom RMI-Namensdienst dem RMI-Client nach seiner Anfrage zugestellt

Konsequenz:

Falls gewöhnliche Objekte als Parameter zu entfernten Methoden oder Rückgabewerte von entfernten Methoden übertragen werden müssen, müssen sie vom Typ java.io.Serializable sein. => extends UnicastRemoteObject

im Internet verfügbare Dienste, die von Clients über URLs angesprochen werden können  

Komponenten, die bestimmte Funktionalitäten über wohldefinierte Schnittstellen zur Verfügung stellen

Web Services dienen "als Unterstützung zur Zusammenarbeit zwischen verschiedenen Anwendungsprogrammen, die auf unterschiedlichen Plattformen und/oder Frameworks betrieben werden"

basieren auf offenen Protokollen

sind "selbstbeschreibend" (WSDL) und

können registriert und gefunden werden (UDDI)

Die Basisplattform für Web Services: XML + HTTP

SOAP (Simple Object Access Protocol)

UDDI (Universal Description, Discovery und Integration)

WSDL (Web Service Description Language)

ist ein leichtgewichtiger Kommunikationsprotokoll für den Austauch von Daten in einer dezentralisierten, verteilten Umgebung

basiert auf XML und wurde für die Kommunikation im Internet entwickelt

plattform- und programmierspracheunabhängig

wird in Kombination mit HTTP als Übertragungsprotokoll von Firewalls "durchgelassen"

definiert die Struktur der zu übertragenden Nachricht (Syntax, Regeln)

ermöglicht die Kommunikation zwischen Anwendungen im Internet, unabhängig von benutzten Plattformen

Envelope (Umschlag)
=> markiert XML als SOAP, enthält Namensraumangaben 

Header (Header-Informationen)
=> optional, Authentifizierung, Zahlungsdaten...

Body (Anfrage- und Antwort-Informationen)
=> mandatory, enthält die Nutzdaten

Fault (Informationen zu den Fehlern)

ist eine XML-basierte Sprache für die Beschreibung von Web Services

wie der Web Service zu finden ist (URL) und

welche Operationen (Methoden) der Service zur Verfügung stellt

Types: datentypen

Messages: Daten von einzelnen Operationen (Parameter)

Ports: Endpunkte

Bindings: Nachrichtenformat + Protokoll für jeden Port

ist ein plattformunabhängiger Verzeichnisdienst, sehr mächtig

UDDI ermöglicht:

das Beschreiben von Web Services

die Registrierung (Anmeldung, Publizierung) von Web Services

die Suche nach Web Services

Code First oder WSDL First?

Schritt 1: Interface definieren

Schritt 2: Implementierende Klasse erstellen

Schritt 3: WebService publizieren

Schritt 4: WSDL anzeigen

Schritt 5: Client-Artefakte generieren

Schritt 6: Client implementieren

Oneway

WebMethod

WebParam

WebResult

WebService

Übertragung von
primitiven und
komplexen Datentypen (Objekten) möglich  

Asynchrone Aufrufe auch möglich (Pooling & Callback)