Jak schovat RMI server za firewall
Kdyz si prohlédnete nějaký RMI příklad, najdete v něm pravděpodobně něco podobného:
LocateRegistry.createRegistry(myPort);
Kde myPort je port, na kterém spouštíte RMI registry. Jiný port v příkladech nepotkáte. Na první pohled se tedy zdá, že stačí na firewallu povolit příslušný myPort, vytvořit nějaký tunel nebo proxy na server do vnitřní sítě a aplikace bude fungovat.
Což ovšem není pravda. První na co narazíte je, že se po připojení k registry a vyžádání remote interface k vašemu vyexportovanému objektu pokusí klient připojit přímo do vnitřní sítě. Tomu se vyhneme snadno, spustíme náš server s parametrem "-Djava.rmi.server.hostname=adresa.firewallu.cz".
Další problém je ošemetnější. Klient se připojí k registru, vyžádá si remote interface ... a nic se nestane. Klient neukončí svůj běh, neobjeví se žádná výjimka, server nezahlásí žádný problém. Prostě se nestane nic (tedy nelze vyloučit, že po dlouhé době dojde k někde timeoutu).
Zakopaného psa najdeme v exportu našich vzdáleně přístupných objektů. Buď jsme pouze podědili UnicastRemoteObject a víc se o nic nestarali, nebo jsme použili metodu UnicastRemoteObject.exportObject(Remote obj).
V obou případech se pro export použil anonymní port. Přesnou definici neznám (ani nevím, jestli takový termín existuje) v praxi je to nějaký vysoký volný port. Teď už je myslím pes zcela vykopán. Klient dostal od registru instrukce kde najde vyexportovaný objekt a pokusil se na daný stroj a port připojit. Firewall pokus o připojení zahodil, klient ani server se nedozvěděli nic a tak oba čekají.
Řešení je již také zřejmé — místo anonymního portu použijeme port, který si sami zvolíme a ten také povolíme na firewallu. Pokud jsme dědili UnicastRemoteObject, závoláme v našem konstruktoru explicitně rodičovský konstruktor: "super(dalsiPort);", pokud exporujeme objekt "ručně", použijeme metodu UnicastRemoteObject.exportObject(Remote obj, int port).
K dalšímu studiu doporučím tutoriál Using a Custom RMI Socket Factory, který se sice tímto tématem přímo nezabývá, ale je zdrojem zábavy i poučení.
K výsledkům zde prezentovaným jsem se dobral šamanským postupem "pokus, omyl, Google", neváhejte mě doplnit či upřesnit.
JBoss 4.0 konečně na scéně
Po dlouhé době konečně vyšla ostrá verze J2EE aplikačního serveru JBoss ve verzi 4.0. V prvé řadě je třeba zmínit, že se jedná o verzi oficiálně vyhovující standardu J2EE 1.4. Srdcem serveru je JMX mikrojádro a vlastní JBossím AOP framework. Díky tomuto přístupu a integraci Hibernate má notně našlápnuto i k nedávno prezentovanému standardu EJB 3.0.
Mimochodem EJB 3.0, kterou má implementovat chystaná verze JBoss 4.2, můžeme podle JBoss Roadmap očekávat v prvním čtvrtletí roku 2005.
Odkazy:
P.S. včera taky vyšly Struts 1.2.4, ale uznejme, že to není až tak zajímavá informace