WebSphere Application Server - HTTP tunneling (RMI over HTTP)

Author

HTTP tunneling (RMI over HTTP)

Bob Coret

2004-04-05, 5:34 pm

Due to our strict firewall policies our web container one server A can't
talk to the EJB container on server B using RMI over IIOP. This is due to
the fact that, besides the JNDI port, CORBA wants to open ports dynamically
for the "data transfer". Also the firewall between the two server does
Network Address Translation.

An obvious solution (besides changing the security policy) is RMI over HTTP.
In our WebSphere 5.0.2 console (on server A) there's (under Server > ORB
services) a nice selection box where you can select ALWAYS for HTTP
Tunneling and you can enter the HTTP Tunnel Agent. This agent is a servlet
(for server B) which you have to incorporate on the EJB container. It's the
standard com.ibm.CORBA.services.IIOPTunnelServlet. Of course it's easier
said than done. Due to the lack of documentation it's trial and error....
and no working situation yet.

Has anyone got this RMI over HTTP working under WebSphere 5.0.2?

Thanks,
Bob

Barney

2004-04-11, 3:06 pm

We've had it working under WAS 5.1 in a PoC. We found the InfoCentre to be
next to useless, and ended up raising a PMR to get it working.

On the assumption that you've got a working client and server communicating
using IIOP (not tunnelled), make the following changes:
On the client we set the following ORB properties:
com.ibm.CORBA.ForceTunnel=ALWAYS
com.ibm.CORBA.TunnelAgentURL=<the location of the tunnel servlet - specified
in a minute>
com.ibm.CORBA.FragmentSize=0

On the server specify the following ORB properties:
com.ibm.CORBA.FragmentSize=0

Also, add the tunnel servlet to your server application. We added this into
a new Web Application. The class of the tunnel servlet is
"com.ibm.CORBA.services.IIOPTunnelServlet". Ensure the context root of the
web app, and the servlet mapping correspond to the URL of the TunnelAgentURL
on the client side.

Also note that the client side connection settings i.e. the iiop:// URL or
corbaloc should remain as if you weren't tunnelling. The client ORB will
handle it.

Oh, and finally, this assumes you're using an IBM JDK client side ;-)

Personally, I find it amazing that this isn't more commonly used, and I'd be
interested in hearing what people do in production environments to enable
IIOP through firewalls. Obviously, one option is that you could specifiy the
IIOP connection port rather than allow it to change on every connection.

As another aside, we ran some comparisons of the WebSphere implementation of
JAX-RPC against RMI/IIOP and RMI/IIOP tunnelled through HTTP, and got some
suprising results. The IIOP implementation isn't as compact as you might
think, and the only way we could get the network traffic down so that
RMI/IIOP load was less than our webservices load, was to cache the bean
instances. Even then, Web Services wasn't too far behind. Add HTTP
compression and the WebServices approach won hands down, even after adding
compression to the RMI/IIOP over Http messages. Obviously Web Services also
adds a CPU overhead of the parsing, but not actually too much. The IBM
implementation is quite good. My point here is don't dismiss Web Services as
being too slow, or too network bloaty. Try it, test it, and decide for
yourselves. ... and no, I don't work for IBM - I was just very impressed
with their server implementation of Web Services.

"Bob Coret" <b.coret@HAALWEG.planet.nl> wrote in message
news:c4shsd$4pk$1@reader11.wxs.nl...
> Due to our strict firewall policies our web container one server A can't
> talk to the EJB container on server B using RMI over IIOP. This is due to
> the fact that, besides the JNDI port, CORBA wants to open ports
dynamically
> for the "data transfer". Also the firewall between the two server does
> Network Address Translation.
>
> An obvious solution (besides changing the security policy) is RMI over
HTTP.
> In our WebSphere 5.0.2 console (on server A) there's (under Server > ORB
> services) a nice selection box where you can select ALWAYS for HTTP
> Tunneling and you can enter the HTTP Tunnel Agent. This agent is a servlet
> (for server B) which you have to incorporate on the EJB container. It's
the
> standard com.ibm.CORBA.services.IIOPTunnelServlet. Of course it's easier
> said than done. Due to the lack of documentation it's trial and error....
> and no working situation yet.
>
> Has anyone got this RMI over HTTP working under WebSphere 5.0.2?
>
> Thanks,
> Bob
>
>

Paul Ilechko

2004-04-11, 3:06 pm

Barney wrote:

> We've had it working under WAS 5.1 in a PoC. We found the InfoCentre to be
> next to useless, and ended up raising a PMR to get it working.

Hope you also opened a PMR to fix the doc, so that the next person
trying to use it is more successful ;-)

Marat

2004-05-29, 11:35 pm

There is a thin ~100 KB client runtime, App Server independent solution that
tunnels all J2EE APIs over HTTP(S). Check them out: www.jproxy.com

Regards,
Marat

"Bob Coret" <b.coret@HAALWEG.planet.nl> wrote in message
news:c4shsd$4pk$1@reader11.wxs.nl...
> Due to our strict firewall policies our web container one server A can't
> talk to the EJB container on server B using RMI over IIOP. This is due to
> the fact that, besides the JNDI port, CORBA wants to open ports
dynamically
> for the "data transfer". Also the firewall between the two server does
> Network Address Translation.
>
> An obvious solution (besides changing the security policy) is RMI over
HTTP.
> In our WebSphere 5.0.2 console (on server A) there's (under Server > ORB
> services) a nice selection box where you can select ALWAYS for HTTP
> Tunneling and you can enter the HTTP Tunnel Agent. This agent is a servlet
> (for server B) which you have to incorporate on the EJB container. It's
the
> standard com.ibm.CORBA.services.IIOPTunnelServlet. Of course it's easier
> said than done. Due to the lack of documentation it's trial and error....
> and no working situation yet.
>
> Has anyone got this RMI over HTTP working under WebSphere 5.0.2?
>
> Thanks,
> Bob
>
>

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---