Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Sprachbeschreibung
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Mathematisches
6 Eigene Klassen schreiben
7 Angewandte Objektorientierung
8 Exceptions
9 Generics, innere Klassen
10 Die Klassenbibliothek
11 Threads und nebenläufige Programmierung
12 Datenstrukturen und Algorithmen
13 Raum und Zeit
14 Dateien und Datenströme
15 Die eXtensible Markup Language (XML)
16 Grafische Oberflächen mit Swing
17 Grafikprogrammierung
18 Netzwerkprogrammierung
19 Verteilte Programmierung mit RMI und Web–Services
20 JavaServer Pages und Servlets
21 Applets
22 Midlets und die Java ME
23 Datenbankmanagement mit JDBC
24 Reflection und Annotationen
25 Logging und Monitoring
26 Sicherheitskonzepte
27 Java Native Interface (JNI)
28 Dienstprogramme für die Java-Umgebung
Stichwort

Download:
- ZIP, ca. 14,1 MB
Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Java ist auch eine Insel (8. Auflage) von Christian Ullenboom
Programmieren mit der Java Standard Edition Version 6
Buch: Java ist auch eine Insel (8. Auflage)

Java ist auch eine Insel (8. Aufl.)
8., aktual. Auflage, geb., mit DVD
1.475 S., 49,90 Euro
Galileo Computing
ISBN 978-3-8362-1371-4
Pfeil 19 Verteilte Programmierung mit RMI und Web–Services
Pfeil 19.1 Entfernte Objekte und Methoden
Pfeil 19.1.1 Stellvertreter helfen bei entfernten Methodenaufrufen
Pfeil 19.1.2 Standards für entfernte Objekte
Pfeil 19.2 Java Remote Method Invocation
Pfeil 19.2.1 Zusammenspiel von Server, Registry und Client
Pfeil 19.2.2 Wie die Stellvertreter die Daten übertragen
Pfeil 19.2.3 Probleme mit entfernten Methoden
Pfeil 19.2.4 Nutzen von RMI bei Middleware-Lösungen
Pfeil 19.2.5 Zentrale Klassen und Schnittstellen
Pfeil 19.2.6 Entfernte und lokale Objekte im Vergleich
Pfeil 19.3 Auf der Serverseite
Pfeil 19.3.1 Entfernte Schnittstelle deklarieren
Pfeil 19.3.2 Remote-Objekt-Implementierung
Pfeil 19.3.3 Stellvertreterobjekte
Pfeil 19.3.4 Der Namensdienst (RegistryRegistry)
Pfeil 19.3.5 Remote-Objekt-Implementierung exportieren und beim Namensdienst anmelden
Pfeil 19.3.6 Einfaches Logging
Pfeil 19.3.7 Aufräumen mit dem DGC
Pfeil 19.4 Auf der Clientseite
Pfeil 19.5 Entfernte Objekte übergeben und laden
Pfeil 19.5.1 Klassen vom RMI-Klassenlader nachladen
Pfeil 19.6 Weitere Eigenschaften von RMI
Pfeil 19.6.1 RMI und CORBA
Pfeil 19.6.2 RMI über HTTP getunnelt
Pfeil 19.6.3 Automatische Remote-Objekt-Aktivierung
Pfeil 19.7 Daily Soap
Pfeil 19.7.1 SOAP-Protokoll
Pfeil 19.7.2 Die technische Realisierung
Pfeil 19.7.3 SOAP-Implementierungen
Pfeil 19.7.4 @WebService in Java 6
Pfeil 19.7.5 Einen Web-Service definieren
Pfeil 19.7.6 Web-Services veröffentlichen
Pfeil 19.7.7 Einen JAX-WS-Client implementieren
Pfeil 19.8 Java Message Service (JMSJMS)
Pfeil 19.9 Zum Weiterlesen


Galileo Computing - Zum Seitenanfang

19.2 Java Remote Method Invocation Zur nächsten ÜberschriftZur vorigen Überschrift

RMI macht es möglich, auf hohem Abstraktionsniveau zu arbeiten und entfernte Methodenaufrufe zu realisieren. Automatisch generierte Stellvertreter nehmen die Daten entgegen und übertragen sie zum Server. Nach der Antwort präsentiert der Stellvertreter das Ergebnis.


Galileo Computing - Zum Seitenanfang

19.2.1 Zusammenspiel von Server, Registry und Client Zur nächsten ÜberschriftZur vorigen Überschrift

Damit RMI funktioniert, sind drei Teile mit der Kommunikation beschäftigt:

1. Der ServerServer stellt das entfernte Objekt mit der Methodenimplementierung bereit. Die Methode läuft im eigenen Adressraum, und der Server leitet eingehende Anfragen vom Netzwerk an diese Methode weiter.
2. Der NamensdienstNamensdienst (RegistryRegistry) ist ein Anfragedienst, der Objekte und ihre Methoden mit einem eindeutigen Namen verbindet. Der Server meldet Objekte mit ihren Methoden bei diesem Namensdienst an.
3. Der ClientClient ist der Nutzer des Dienstes und ruft die Methode auf einem entfernten Objekt auf. Auch er hat einen eigenen Adressraum. Möchte der Client eine Methode nutzen, so fragt er beim Namensdienst an, um Zugriff zu bekommen.

Galileo Computing - Zum Seitenanfang

19.2.2 Wie die Stellvertreter die Daten übertragen Zur nächsten ÜberschriftZur vorigen Überschrift

Für RMI gibt es wie bei TCP/IP ein Schichtenmodell, das aus mehreren Ebenen besteht. Die oberste Ebene mit dem höchsten Abstraktionsgrad nutzt einen Transportdienst der darunterliegenden Ebene. Dessen Aufgabe ist es, die Daten wirklich zu übermitteln, und die Stellvertreter realisieren es, die Parameter irgendwie von einem Ort zum anderen zu bewegen. Sie setzen also die Transportschicht um.

Eine Implementierung über Sockets

Wir können uns vorstellen, dass die Stellvertreter eine Socket-Verbindung nutzen. Der Server horcht dann in accept() auf einkommende Anfragen, und der Stellvertreter vom Client baut anschließend die Verbindung auf. Sind die Argumente der Methode primitive Werte, können sie in unterschiedliche write()- und read()-Methoden umgesetzt werden. Doch auch bei komplexen Objekten wie Listen hat Java keine Probleme, da es ja eine Serialisierung gibt. Objekte werden dann einfach plattgeklopft, übertragen und auf der anderen Seite wieder ausgepackt. Bei entfernten Methodenaufrufen wird neben der Serialisierung auch der Begriff Marshalling verwendet. Somit ist das Verhalten wie bei lokalen Methoden fast abgebildet, insbesondere der synchrone Charakter. Die lokale Methode blockiert so lange, bis das Ergebnis der entfernten Methoden ankommt.

RMI Wire Protocol

Das für die Übertragung zuständige Protokoll heißt RMI Wire Protocol. Die Übertragung mittels Sockets und TCP ist nur eine Möglichkeit. Neben den Sockets implementiert Java-RMI für Firewalls auch die Übermittlung über HTTP-Anfragen. Wir werden in einem späteren Kapitel darauf zurückkommen. Über eine eigene RMI-Transportschicht könnten auch andere Protokolle genutzt werden, etwa über UPD oder gesicherte Verbindungen mit SSL. Verschlüsselte RMI-Verbindungen über SSL sind nicht schwer, wie es ein Beispiel von Sun unter http://tutego.com/go/jssesamples zeigt.


Galileo Computing - Zum Seitenanfang

19.2.3 Probleme mit entfernten Methoden Zur nächsten ÜberschriftZur vorigen Überschrift

Das Konzept scheint entfernte Methoden abzubilden wie lokale. Doch es gibt einige feine Unterschiede, sodass wir nicht anfangen müssen, alle lokal deklarierten Methoden verteilt zu nutzen, weil gerade mal ein entfernter Rechner schön schnell ist.

  • Zunächst müssen wir ein Kommunikationssystem voraussetzen. Damit fangen aber die bekannten Probleme bei Clients beziehungsweise Servern an. Was geschieht, wenn das Kommunikationssystem zusammenbricht? Was passiert mit verstümmelten Daten?
  • Da beide Rechner eigene Lebenszyklen haben, ist nicht immer klar, ob beide Partner miteinander kommunizieren können. Wenn der Server nicht ansprechbar ist, muss der Client darauf reagieren. Hier bleibt nichts anderes übrig, als über einen Zeitablauf (Timeout) zu gehen.
  • Da Client und Server über das Kommunikationssystem miteinander sprechen, ist die Zeit für die Abarbeitung eines Auftrags um ein Vielfaches höher als bei lokalen Methodenaufrufen. Zu den Kommunikationskosten über das Rechennetzwerk kommen die Kosten für die zeitaufwändige Serialisierung hinzu, die besonders in den ersten Versionen des JDKs hoch waren.

Parameterübergabe bei getrenntem Speicher

Der tatsächliche Unterschied zwischen lokalen und entfernten Methoden ist jedoch das Fehlen des gemeinsamen Kontexts. Die involvierten Rechner führen ihr eigenes Leben mit ihren eigenen Speicherbereichen. Stehen auf einer Maschine zum Beispiel statische Variablen jedem zur Verfügung, ist dies bei entfernten Maschinen nicht der Fall. Ebenso gilt dies für Objekte, die von mehreren Partnern geteilt werden. Die Daten auf einer Maschine müssen erst übertragen werden, also arbeitet der Server mit einer Kopie der Daten. Bei primitiven Daten ist das kein Thema, schwierig wird es erst bei Objektreferenzen. Mit der Referenz auf ein Objekt kann der andere Partner nichts anfangen. Mit der Übertragung der Objekte handeln wir uns jedoch zwei weitere Probleme ein:

  • Erstens muss der Zugriff exklusiv erfolgen, weil andere Teilnehmer den Objektzustand ja unter Umständen ändern können. Wenn wir also eine Referenz übergeben, und das Objekt wird serialisiert, könnte der lokale Teilnehmer Änderungen vornehmen, die beim Zurückspielen vom Server eventuell verloren gehen könnten.
  • Damit haben wir zweitens den Nachteil, dass »einfach eine Referenz« nicht ausreicht. Große Objekte müssen immer wieder vollständig serialisiert werden. Und mit dem Mechanismus des Serialisierens handeln wir uns ein Problem ein: Nicht alle Objekte sind per se serialisierbar. Gerade die Systemklassen lassen sich nicht so einfach übertragen. Bei einer Trennung von Datenbank und Applikation wird das deutlich. Eine hübsche Lösung wäre etwa, ein RMI-Programm für die Datenbankanbindung einzusetzen sowie eine Applikation, die mit dem RMI-Programm spricht, um unabhängig von der Datenbank zu sein; RMI nimmt hier die Stelle einer so genannten Middleware ein. Bedauerlicherweise implementiert keine der Klassen im Paket java.sql die Schnittstelle Serializable. Die Ergebnisse müssen in einem neuen Objekt verpackt und verschickt werden oder in einem RowSet, das es seit JDBC 2.0 gibt.

Wenn die Daten übertragen werden, müssen sich die Partner zudem über das Austauschformat geeinigt haben. Beide müssen die Daten verstehen. Traditionell bieten sich zwei Verfahren an:

  • Zunächst ein symmetrisches Verfahren. Alle Argumente werden in einem festen Format übertragen. Auch wenn Client und Server die Daten gleich darstellen, werden sie in ein neutrales Übertragungsformat konvertiert.
  • Dem gegenüber steht das asymmetrische Verfahren. Hier schickt jeder Client die Daten in einem eigenen Format, und der Server hat verschiedene Konvertierungsmethoden, um die Daten zu erkennen.

Da wir uns innerhalb von Java und den Konventionen bewegen, müssen wir uns über das Datenformat keine Gedanken machen. Java konvertiert die Daten unterschiedlichster Plattformen immer gleich. Daher handelt es sich um ein symmetrisches Übertragungsprotokoll.


Galileo Computing - Zum Seitenanfang

19.2.4 Nutzen von RMI bei Middleware-Lösungen Zur nächsten ÜberschriftZur vorigen Überschrift

Der Begriff Middleware ist im vorhergehenden Abschnitt schon einmal gefallen. Ganz einfach gesagt, handelt es sich dabei um eine Schicht, die zwischen zwei Prozessen liegt. Die Middleware ist sozusagen der Server für den Client und der Client für einen Server, vergleichbar mit einem Proxy. Das Großartige an Middleware-Lösungen ist die Tatsache, dass sie eine starke Kopplung von Systemen entzerren und eine bessere Erweiterung ermöglichen. Sprach vorher etwa eine Applikation direkt mit dem Server, würde durch den Einsatz der Middleware die Applikation mit der Zwischenschicht reden und diese dann mit dem Server. Die Applikation weiß dann vom Server rein gar nichts.

Ein oft genanntes Einsatzgebiet für Middleware sind Applikationen, die mit Datenbanken arbeiten. Systeme der ersten Generation verbanden sich direkt mit der Datenbank, lasen Ergebnisse und modifizierten die Tabellen. Der Nachteil ist offensichtlich: Das Programm ist unflexibel bei Änderungen, und diese Änderungen müssten bei einer groß angelegten, verbreiteten Version allen Kunden zugänglich gemacht werden. Erschwerend kommt ein Sicherheitsproblem hinzu. Wenn das Programm mit der Datenbank direkt spricht, etwa in Form von JDBC, dann gelangen Informationen über die internen Tabellen über die Abfragen leicht nach außen. Bei unsachgemäßer Programmierung kann auch ein Bösewicht das Programm decompilieren und die Tabellen vielleicht mit unsinnigen Werten füllen – denkbar schlecht für den kommerziellen Dauerbetrieb. Die Antwort auf das Problem ist der Einsatz einer Middleware. Dann verbindet sich die Applikation mit der Zwischenschicht, die dann die Daten besorgt, zum Beispiel von der Datenbank. Im Programm sind dann nur noch verteilte Anfragen, und JDBC ist nicht mehr zu entdecken. Als Applikationsentwickler können wir ruhigen Gewissens die Datenbank verändern, und wir müssen »nur« die Middleware anpassen. Der Kunde mit der Applikation sieht davon nichts. Das Sicherheitsproblem ist damit auch vom Tisch. Die Middleware kann zur Performance-Steigerung auch noch mehrgleisig fahren und die schnellste Datenbank nutzen. Lastenverteilung kann nachträglich implementiert werden, und die Software beim Client bleibt schlank.


Galileo Computing - Zum Seitenanfang

19.2.5 Zentrale Klassen und Schnittstellen Zur nächsten ÜberschriftZur vorigen Überschrift

Für RMI-Aufrufe stehen uns folgende Klassen und Schnittstellen zur Verfügung:

  • java.rmi.Remote. Eine Schnittstelle, die alle entfernten Objekte implementieren müssen.
  • java.rmi.RemoteException. Eine Unterklasse von IOException, deren Exemplare uns im Fall von Übertragungsproblemen begegnen.
  • java.rmi.server.RemoteObject. Die Klasse implementiert Verhalten von java. lang.Object (also toString(), hashCode() und equals()) für entfernte Objekte.
  • java.rmi.server.UnicastRemoteObject. Unterklasse von RemoteObject zum Aufbau und Exportieren (Anmelden) der Remote-Objekte.
  • java.rmi.server.RMIClassLoader. Ermöglicht das Laden von Klassenbeschreibungen vom Server, wenn diese von einem Remote-Objekt benötigt werden.
  • java.rmi.RMISecurityManager. Der Sicherheitsmanager bestimmt die Möglichkeiten der von RMIClassLoader geladenen Klassen. Ohne Sicherheitsmanager lädt der RMIClassLoader keine Klassen.
  • Naming. Eine Klasse für den Zugriff auf den Namensserver.
  • java.io.Serializable. Parameter und Rückgaben implementieren die Schnittstelle, wenn sie per Kopie übergeben werden sollen.
  • java.rmi.server.RemoteServer. Oberklasse für Server-Implementierungen. Zum Setzen eines Loggers interessant.

Die Spezifikation zu RMI unter http://tutego.com/go/rmispec stellt alle Typen genauer vor.


Galileo Computing - Zum Seitenanfang

19.2.6 Entfernte und lokale Objekte im Vergleich topZur vorigen Überschrift

Vergleichen wir entfernte Objekte und ihre Methoden, fallen Gemeinsamkeiten ins Auge: Die Referenzen auf entfernte Objekte lassen sich wie gewohnt nutzen, etwa als Argumente einer Methode oder als Rückgabewert. Dabei ist es egal, ob die Methode mit den Argumenten oder Rückgabewerten lokal oder entfernt ist. Die Unterschiede zu lokalen Objekten sind aber deutlicher: Da ein Client immer über eine entfernte Schnittstelle das Objekt repräsentiert, hat es nichts mit der tatsächlichen Implementierung zu tun; daher ist auch eine Typumwandlung unmöglich. Die einzige Umwandlung von einer entfernten Schnittstelle wäre Remote. Damit ist auch deutlich, dass instanceof auch nur testen kann, ob das Objekt entfernt ist oder nicht; die echte Vererbung auf der Serverseite bleibt verborgen.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






<< zurück
  Zum Katalog
Zum Katalog: Java ist auch eine Insel





Java ist auch eine Insel
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Tipp
Zum Katalog: Coding for Fun





 Coding for Fun


 Buchempfehlungen
Zum Katalog: Objektorientierte Programmierung





 Objektorientierte
 Programmierung


Zum Katalog: Einstieg in Eclipse 3.4






 Einstieg in
 Eclipse 3.4


Zum Katalog: Java 6 lernen mit Eclipse






 Java 6 lernen
 mit Eclipse


Zum Katalog: NetBeans Platform 6






 NetBeans
 Platform 6


Zum Katalog: Java und XML






 Java und XML


Zum Katalog: Visual C# 2008






 Visual C# 2008


Zum Katalog: IT-Handbuch für Fachinformatiker






 IT-Handbuch für
 Fachinformatiker


Zum Katalog: C++ von A bis Z






 C++ von A bis Z


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2009
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de