14.6Weitere Eigenschaften von RMI 
14.6.1RMI 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 damals 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.
Mittlerweile ist 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. Oracle bringt einen kleinen Miniserver zur Kommunikation mit und ebenso Schnittstellen und Klassen für die Kommunikation mit dem ORB.
14.6.2RMI ü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 zwischen Webserver und Browser. RMI bietet zum Übertragen der Daten eine Lösung über HTTP an. Ist das Internetprotokoll installiert, so lässt die Firewall die Anfragen und Antworten der Internetpartner 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.
14.6.3Automatische 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 Objektserver 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:
Wir leiten unser Remote-Objekt von der abstrakten Klasse Activatable ab, die wiederum von RemoteServer erbt, oder wir exportieren das Objekt mit Activatable.exportObject(Remote, …). 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.
Damit das System zur Laufzeit den entfernten Zugriff erkennt, ist der RMI Activation Daemon rmid nötig. Er läuft auf der gleichen Maschine wie das aktivierbare Remote-Objekt.
Weitere Hinweise gibt die Webseite unter http://tutego.de/go/rmiactivation.
