Galileo Computing < openbook >
Galileo Computing - Professionelle Buecher. Auch fuer Einsteiger.
Galileo Computing - Professionelle Buecher. Auch fuer Einsteiger.


Java ist auch eine Insel von Christian Ullenboom
Buch: Java ist auch eine Insel (Galileo Computing)
gp Kapitel 18 Verteilte Programmierung mit RMI und SOAP
gp 18.1 Entfernte Methoden
gp 18.1.1 Wie entfernte Methoden arbeiten
gp 18.1.2 Stellvertreter (Proxy)
gp 18.1.3 RMI
gp 18.1.4 Wie die Stellvertreter die Daten übertragen
gp 18.1.5 Probleme mit entfernten Methoden
gp 18.2 Nutzen von RMI bei Middleware-Lösungen
gp 18.3 Die Lösung für Java ist RMI
gp 18.3.1 Entfernte Objekte programmieren
gp 18.3.2 Entfernte und lokale Objekte im Vergleich
gp 18.4 Definition einer entfernten Schnittstelle
gp 18.5 Das entfernte Objekt
gp 18.5.1 Der Bauplan für entfernte Objekte
gp 18.5.2 Der Konstruktor
gp 18.5.3 Implementierung der entfernten Methoden
gp 18.6 Stellvertreterobjekte erzeugen
gp 18.6.1 Das Dienstprogramm rmic
gp 18.7 Der Namensdienst (Registry)
gp 18.7.1 Der Port
gp 18.8 Der Server: entfernte Objekte beim Namensdienst anmelden
gp 18.8.1 Automatisches Anmelden bei Bedarf
gp 18.9 Einen Client programmieren
gp 18.9.1 Einfaches Logging
gp 18.10 Aufräumen mit dem DGC
gp 18.11 Entfernte Objekte übergeben und laden
gp 18.11.1 Klassen vom RMI-Klassenlader nachladen
gp 18.11.2 Sicherheitsmanager
gp 18.12 Registry wird vom Server gestartet
gp 18.13 RMI über die Firewall
gp 18.13.1 RMI über HTTP getunnelt
gp 18.14 RMI und CORBA
gp 18.15 UnicastRemoteObject, RemoteServer und RemoteObject
gp 18.16 Daily Soap
gp 18.16.1 SOAP-Implementierung der Apache-Gruppe
gp 18.16.2 Einen Client mit der Apache-Bibliothek implementieren
gp 18.16.3 Der Seifen-Server
gp 18.17 Java-API für XML Messaging (JAXM)
gp 18.18 Java Message Service (JMS)
gp 18.18.1 OpenJMS
gp 18.18.2 Beispiel mit Konsument und Produzent im Publish-Subscribe-Modell


Galileo Computing

18.2 Nutzen von RMI bei Middleware-Lösungentoptop

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 bei Middleware-Lösungen ist die Tatsache, dass es eine starke Kopplung von Systemen entzerrt und eine bessere Erweiterung ermöglicht. Sprach vorher etwa eine Applikation direkt mit dem Server, so würde durch den Einsatz der Middleware die Applikation mit der Zwischenschicht reden und diese dann mit dem Server. Die Applikation weiß dann gar nichts vom Server.

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.





Copyright (c) Galileo Press GmbH 2004
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 GmbH, Gartenstraße 24, 53229 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de