18.6 Weitere Eigenschaften von RMI 
18.6.1 RMI und CORBA 
Neben der reinen Java-Lösung RMI gibt es auf dem weiten Feld der Standards noch das komplexe CORBA. Die Object Management Group hatte Sun vorgeworfen, mit RMI einen zweiten Standard zu schaffen. Die Frage nach dem Sinn von RMI ist also erlaubt. Die Antwort liegt in der Einfachheit und Integration von RMI.
In den letzten Jahren hat Sun RMI an den De-facto-Standard CORBA angepasst. Die Stellvertreter-Objekte sprechen nicht nur das eigene JRMP (Java Remote Method Protocol), sondern können ihre Dienste auch über das Inter-ORB Protocol (IIOP) von CORBA anbieten; das Protokoll ist dann nicht mehr das proprietäre JRMP, sondern RMI/IIOP (»RMI über IIOP«). Damit kann jeder CORBA-Client entfernte RMI-Objekte nutzen. Sun bringt einen kleinen Mini-Server zur Kommunikation mit und ebenso Schnittstellen und Klassen für die Kommunikation mit dem ORB.
18.6.2 RMI über HTTP getunnelt
Bei der Kommunikation der beiden Partner gibt es eine direkte Verbindung über Socket-Objekte. Diesen Sockets wird ein Port zugewiesen, sodass RMI die serialisierten Daten dann über diese zugewiesenen Ports überträgt. Dies führt jedoch bei einer Firewall, die ein internes Firmennetz schützen möchte und nur genau spezifizierte Ports, Protokolle und Richtungen offen lässt, zu Problemen. Soll eine RMI-Lösung für ein abgeschottetes Netz entwickelt werden, stellt sich die Frage, welche Technik eingesetzt werden soll.
HTTP dient normalerweise zum Übertragen der Daten von Webserver und Browser. RMI bietet zum Übertragen der Daten eine Lösung über HTTP an. Ist das Internet-Protokoll installiert, so lässt die Firewall die Anfragen und Antworten der Internet-Partner passieren – üblicherweise auf Port 80. Die RMI-Lösung macht es sich zunutze, dass die Daten in spezielle HTTP-Pakete eingepackt (getunnelt) werden. Dazu nutzt das Tunneling-Protokoll veränderte POST-Kommandos. Die Transportschicht des Clients generiert dann eine POST-Anfrage, wobei hier zwei unterschiedliche Verfahren zum Einsatz kommen.
- Der Sender schickt die Anfrage direkt an den RMI-Server, der an dem Port horcht. Dieser nimmt anschließend aus dem POST-Paket die Daten heraus und interpretiert sie. Das wäre eine Lösung, wenn es hinter dem Sender eine Firewall gibt, aber nicht vor dem Empfänger. Wenn Sender und Empfänger geschützt sind, hilft ein zweites Verfahren.
- Der Transportmechanismus arbeitet vollständig über HTTP-Anweisungen. Dann antwortet auf der Serverseite der Webserver, der die Anfragen weiterleiten muss. Dazu dient ein CGI-Skript, das die Daten wiederum zum RMI-Server hochreicht.
Auf diese Weise werden die Objekte übertragen, allerdings mit einer Verzögerung, die durch das zusätzliche Verpacken und den eventuellen Aufruf des CGI-Skripts bedingt ist.
Das Schöne an dieser Lösung ist, dass der Client es gar nicht mitbekommt und nicht besonders konfiguriert werden muss. Soll das Verfahren ausdrücklich verboten werden, ist die Eigenschaft java.rmi.server.disableHttp auf true zu setzen.
18.6.3 Automatische Remote-Objekt-Aktivierung
Bisher haben wir ein entferntes Objekt erzeugt und angemeldet, sodass das Objekt später schon da ist, wenn es angesprochen wird. Sollten auf einem Objekt-Server viele Hunderte Remote-Objekte vor sich hin dämmern, ist das natürlich nicht sonderlich effektiv und kostet unnötig Ressourcen. Daher unterstützt die Bibliothek eine Technik namens Remote Object Activation (ROA), die das automatische Starten eines Dienstes ermöglicht, wenn der erste Zugriff stattfindet; das wird lazy activation genannt. Damit ROA funktioniert, müssen wir als Entwickler zwei Schritte tun:
| 1. | Wir leiten unser Remote-Objekt von der abstrakten Klasse Activatable [Wieder etwas, was auf -able endet, aber keine Schnittstelle ist. ] Activatable, Klasse ab, die wiederum von RemoteServer erbt, oder exportieren das Objekt mit Activatable.exportObject(). Damit bleiben die entfernten Objekte bis zu ihrer Aktivierung in einem Dämmerzustand. Kommt die erste Anfrage, baut das System dieses Objekt auf, sodass es Anfragen entgegennehmen kann. Wird das Objekt nach seiner Tat wiederum nicht verwendet, kann es wieder eingefroren werden; persistente Daten verwaltet ein serialisierbares MarshalledObject. Die unterschiedlichen Klassen zum Aktivieren bei Bedarf liegen alle im Paket java.rmi.activation. |
| 2. | Damit das System zur Laufzeit den entfernten Zugriff erkennt, ist der RMI Activation DaemonActivation Daemon rmidrmid, Dienstprogramm nötig. Er läuft auf der gleichen Maschine wie das aktivierbare Remote-Objekt. |
Weitere Hinweise gibt die Webseite von Sun unter http://tutego.com/go/rmiactivation.