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 Die Funktionsbibliothek
10 Threads und nebenläufige Programmierung
11 Raum und Zeit
12 Datenstrukturen und Algorithmen
13 Dateien und Datenströme
14 Die eXtensible Markup Language (XML)
15 Grafische Oberflächen mit Swing
16 Grafikprogrammierung
17 Netzwerkprogrammierung
18 Verteilte Programmierung mit RMI und Web-Services
19 JavaServer Pages und Servlets
20 Applets
21 Midlets und die Java ME
22 Datenbankmanagement mit JDBC
23 Reflection und Annotationen
24 Logging und Monitoring
25 Sicherheitskonzepte
26 Java Native Interface (JNI)
27 Dienstprogramme für die Java-Umgebung
A Die Begleit-DVD
Stichwort
Download: - ZIP, ca. 12,5 MB
Buch bestellen
Ihre Meinung?
<< zurück | Galileo Computing / <openbook> /Java-Insel | vor >>
Java ist auch eine Insel von Christian Ullenboom Programmieren mit der Java Standard Edition Version 6
Java ist auch eine Insel 7., aktualisierte Auflage geb., mit DVD (November 2007) 1.492 S., 49,90 Euro Galileo Computing ISBN 978-3-8362-1146-8 |
| 18 Verteilte Programmierung mit RMI und Web-Services
|  | 18.1 Entfernte Objekte und Methoden
|  |  | 18.1.1 Stellvertreter helfen bei entfernten Methodenaufrufen
|  |  | 18.1.2 Standards für entfernte Objekte
|  | 18.2 Java Remote Method Invocation
|  |  | 18.2.1 Zusammenspiel von Server, Registry und Client
|  |  | 18.2.2 Wie die Stellvertreter die Daten übertragen
|  |  | 18.2.3 Probleme mit entfernten Methoden
|  |  | 18.2.4 Nutzen von RMI bei Middleware-Lösungen
|  |  | 18.2.5 Zentrale Klassen und Schnittstellen
|  |  | 18.2.6 Entfernte und lokale Objekte im Vergleich
|  | 18.3 Auf der Serverseite
|  |  | 18.3.1 Entfernte Schnittstelle deklarieren
|  |  | 18.3.2 Remote-Objekt-Implementierung
|  |  | 18.3.3 Stellvertreterobjekte
|  |  | 18.3.4 Der Namensdienst (Registry)
|  |  | 18.3.5 Remote-Objekt-Implementierung exportieren und beim Namensdienst anmelden
|  |  | 18.3.6 Einfaches Logging
|  |  | 18.3.7 Aufräumen mit dem DGC
|  | 18.4 Auf der Clientseite
|  | 18.5 Entfernte Objekte übergeben und laden
|  |  | 18.5.1 Klassen vom RMI-Klassenlader nachladen
|  | 18.6 Weitere Eigenschaften von RMI
|  |  | 18.6.1 RMI und CORBA
|  |  | 18.6.2 RMI über HTTP getunnelt
|  |  | 18.6.3 Automatische Remote-Objekt-Aktivierung
|  | 18.7 Daily Soap
|  |  | 18.7.1 SOAP-Protokoll
|  |  | 18.7.2 Die technische Realisierung
|  |  | 18.7.3 SOAP-Implementierungen
|  |  | 18.7.4 @WebService in Java 6
|  |  | 18.7.5 Einen Web-Service definieren
|  |  | 18.7.6 Web-Services veröffentlichen
|  |  | 18.7.7 Einen JAX-WS-Client implementieren
|  | 18.8 Java Message Service (JMS)
|  | 18.9 Zum Weiterlesen
Ich denke, dass es einen Weltmarkt für vielleicht fünf Computer gibt. – Thomas Watson, Vorsitzender von IBM, 1943 # 18 Verteilte Programmierung mit RMI und Web-Services ## 18.1 Entfernte Objekte und Methoden Bei Funktionsaufrufen nutzen wir die Intelligenz der Methode, die zu gegebenen Eingabe-parametern Ausgangswerte liefert oder einen Systemzustand verändert. Die Methode ist in diesem Fall Anbieter einer ganz speziellen Dienstleistung. Wenn wir zu einer Eingabeanfrage eine Antwort bekommen wollen, die Implementierung dieser Intelligenz aber auf einer anderen Maschine liegt, handelt es sich um entfernte Methodenaufrufe. Wie lässt sich so etwas elegant implementieren? Der klassische Weg führt über Client-Server-Systeme. Der Client formuliert eine Anfrage, die vom Server verstanden und interpretiert wird. So sieht dies etwa in einfacher Form mit einem Datenbank-Server aus. Der Client möchte zum Beispiel den Umsatz einer Disko herausfinden. Er schickt dann eine Anfrage, und das Ergebnis wird zurückgeschickt und ausgewertet. Diese Kommunikation zwischen verteilten Prozessen muss aber aufwändig bei Client-Server-Systemen implementiert werden. Wir müssen also Parameter und Rückgabewerte verpacken, einen horchenden Server einrichten, vielleicht noch HTTP-Tunnel anlegen und so weiter. Wünschenswert ist eine Sicht auf entfernte Dienste wie auf Methoden innerhalb einer Laufzeitumgebung. Ideal wäre es, wenn ein Funktionsaufruf auf einen Server so aussähe, als ob er eine lokale Funktion wäre. ### 18.1.1 Stellvertreter helfen bei entfernten Methodenaufrufen Birrel und Nelson haben schon 1984 ein Modell vorgestellt, das entfernte Server-Funktionen wie lokale Funktionen aussehen lässt. Die Verbindung von Client und Server realisieren so genannte Stellvertreterobjekte (engl. proxies). Diese existieren auf der Client- und auf der Serverseite. Die Stellvertreterfunktion verdeckt den tatsächlichen Übertragungsvorgang, sodass der Client demnach nicht mit einem eigenen Protokoll mit dem Server kommuniziert, sondern eine Funktion aufruft, die so aussieht wie eine Serverfunktion. In Wirklichkeit nimmt die Stellvertreterfunktion nur die Parameter, verpackt sie in eine Serveranfrage und schickt sie weg. Wir wollen uns dies anhand eines Beispiels klarmachen. Nehmen wir an, der Client möchte die Funktion int add() nutzen, die in Wirklichkeit auf einem ganz anderen Rechner angeboten wird: einem, der richtig Power hat, um die hochkomplizierte mathematische Operation auszuführen. Da wir aber die Vorgabe haben, eine entfernte Funktion so aussehen zu lassen wie eine lokale, wird nun add() wie gewohnt aufgerufen:
    System.out.println( add( 47, 11 ) );
Der Stellvertreter auf der Clientseite übernimmt nun das Protokoll, kümmert sich also um das Verpacken der zu transportierenden Werte, Verschlüsselung, Authentifizierung, Kompression und um alles, was noch so gewünscht sein kann. Kurz skizziert:
    int add( int a, int b )
    {
      // Verbindung aufbauen (etwa über Sockets)
      // a und b zum Server schicken (write())
      // Auf das Ergebnis vom Server warten (read())
      // return ergebnis;
    }
Intern steckt das klassische Client-Server-Konzept dahinter, das wir schon von Sockets kennen. Der Client mit dem Funktionsaufruf initiiert die Anfrage, und der Server wartet, bis ein williger Kunde eintrifft. Der Server nimmt die Anfragen des Clients entgegen, entnimmt aus dem Anforderungspaket die Daten und ruft die lokale Funktion auf, die auf dem Server nun so implementiert sein kann:
    int add( int a, int b )
      return a + b;
    }
Zusätzlich kann es auf der Serverseite auch einen Stellvertreter geben, doch reicht auch ein Server aus, der zunächst auf eingehende Anfragen wartet und dann die entsprechenden Funktionen ohne eigenen Stellvertreter aufruft. Hier klicken, um das Bild zu vergrößern An der Aufrufsyntax ist nicht abzulesen, ob der Client an einen Stellvertreter geht, der die Daten weiterleitet, und der Server merkt nicht, dass er in Wirklichkeit nicht mit lokalen Daten gefüttert wird. ### 18.1.2 Standards für entfernte Objekte Rund um diese Frage, haben sich in den letzten 10 Jahren diverse Standards gebildet, um mitunter auch über Betriebssystemgrenzen hinweg entfernte Dienste nutzen zu können: Eine der ersten populären Implementierungen in der prozeduralen Welt stammt von Sun und ist das RPC-Protokoll (Remote Procedure Call). Es geht auf die RFC 707 aus dem Jahre 1976 zurück. RMI (Remote Method Invocation) ist der Mechanismus in Java, um entfernte Objekte und deren Angebote zu nutzen. RMI ist fester Bestandteil der Java-Bibliothek seit der Version 1.1, also offiziell seit Februar 1997 Im Gegensatz zu RMI definiert CORBA (Common Object Request Broker Architecture) ein großes Framework für verteilte Software-Komponenten und unterschiedliche Programmiersprachen. Die Definition von CORBA geht auf das Jahr 1991 zurück, also vor RMI, und wird von der OMG (Object Management Group) gesteuert. Das Distributed Component Object Model (DCOM) ist eine Microsoft-Erfindung, um COM-Objekte über das Netz zugänglich zu machen. Später als ActiveX getarnt, hat Microsoft 2002 die .NET Remoting API veröffentlicht, die in das .NET Framework einzog. ### Ihr Kommentar Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.
Name |
E-Mail |
Ihr Kommentar |
<< zurück | <top> | vor >>

Copyright © Galileo Press 2008
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