«

Hello,

Browsing the web & newsgroups, it looks like this problem doesn't
have any kind of easy solution, but let's see if someone knows different.

I want to have a RMI client behind a firewall and a RMI server
behind another firewall. I don't have any control over the firewalls.
I know port 80 will be open for http traffic, but that's it.
The web server on either side isn't the same as the machine running
the RMI client or server.

I want the client to be able to call methods on server objects
and also to enable callbacks from the server to the client.

What can be done in this case? I've read the RMI docs at Sun,
browsed through a few dozen webpages & news messages, and the
situation looks pretty dark, actually. Maybe someone has cause
for optimism here. Thanks for any information.

Robert Dodier

On 13 Sep 2004 12:50:21 -0700, (Robert Dodier)
wrote:

>Hello,
>
>Browsing the web & newsgroups, it looks like this problem doesn't
>have any kind of easy solution, but let's see if someone knows different.
>
>I want to have a RMI client behind a firewall and a RMI server
>behind another firewall. I don't have any control over the firewalls.
>I know port 80 will be open for http traffic, but that's it.
>The web server on either side isn't the same as the machine running
>the RMI client or server.
>
>I want the client to be able to call methods on server objects
>and also to enable callbacks from the server to the client.
>
>What can be done in this case? I've read the RMI docs at Sun,
>browsed through a few dozen webpages & news messages, and the
>situation looks pretty dark, actually. Maybe someone has cause
>for optimism here. Thanks for any information.
>
>Robert Dodier

I believe it can be done through HTTP tunnelling. Do a web search on
that. You need a servlet to forward the requests. (Can you run
servlets in your web server?) I think Sun provides one but you might
need to change it if the RMI server is on a different machine from the
web server.

You can define sockets for the stub and the skeleton (Class
RMISocketFactory).
---schnipp---
public class HelloImpl implements Hello{
public HelloImpl() throws RemoteException{
UnicastRemoteObject.export(this, 80, new MyClientFactory(), new
MyServerFactory());
}
---schnapp---
If you need a complete example, write me.
RMI is written for use in an Intranet. A better way is to use Webservices
to solve your problem (e.g. AXIS).

Andres

On 13 Sep 2004 12:50:21 -0700, Robert Dodier <>
wrote:

> Hello,
>
> Browsing the web & newsgroups, it looks like this problem doesn't
> have any kind of easy solution, but let's see if someone knows different.
>
> I want to have a RMI client behind a firewall and a RMI server
> behind another firewall. I don't have any control over the firewalls.
> I know port 80 will be open for http traffic, but that's it.
> The web server on either side isn't the same as the machine running
> the RMI client or server.
>
> I want the client to be able to call methods on server objects
> and also to enable callbacks from the server to the client.
>
> What can be done in this case? I've read the RMI docs at Sun,
> browsed through a few dozen webpages & news messages, and the
> situation looks pretty dark, actually. Maybe someone has cause
> for optimism here. Thanks for any information.
>
> Robert Dodier



--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

Matthias Kraft wrote:
> You can define sockets for the stub and the skeleton (Class
> RMISocketFactory).
> ---schnipp---
> public class HelloImpl implements Hello{
> public HelloImpl() throws RemoteException{
> UnicastRemoteObject.export(this, 80, new MyClientFactory(), new
> MyServerFactory());
> }
> ---schnapp---
> If you need a complete example, write me.
> RMI is written for use in an Intranet. A better way is to use
> Webservices to solve your problem (e.g. AXIS).

To the OP: You've had two good replies here. I must admit that I was
thinking Web Services simply because of portability issues. But the
proxy approach is mature and enjoys wide support.
IOW, you'd be well served by either solution.
Good luck!

If you have no control over the firewalls at all, then there is no solution.
However, if you can negotiate opening of a few ports with the admin, then
the solution does exist. If the latter is the case, let me know and I will
walk you through the setup.

Alex Molochnikov
Gestalt Corporation
www.gestalt.com

"Robert Dodier" <> wrote in message
news: om...
> Hello,
>
> Browsing the web & newsgroups, it looks like this problem doesn't
> have any kind of easy solution, but let's see if someone knows different.
>
> I want to have a RMI client behind a firewall and a RMI server
> behind another firewall. I don't have any control over the firewalls.
> I know port 80 will be open for http traffic, but that's it.
> The web server on either side isn't the same as the machine running
> the RMI client or server.
>
> I want the client to be able to call methods on server objects
> and also to enable callbacks from the server to the client.
>
> What can be done in this case? I've read the RMI docs at Sun,
> browsed through a few dozen webpages & news messages, and the
> situation looks pretty dark, actually. Maybe someone has cause
> for optimism here. Thanks for any information.
>
> Robert Dodier

"Alexander Ames" <> wrote in message
news:...
> I believe it can be done through HTTP tunnelling.

The OP wanted to do callbacks to the client. The HTTP tunnelling will not
allow that.

On Tue, 14 Sep 2004 00:10:04 -0400, Sudsy <> wrote:

> Matthias Kraft wrote:
>> You can define sockets for the stub and the skeleton (Class
>> RMISocketFactory).
>> ---schnipp---
>> public class HelloImpl implements Hello{
>> public HelloImpl() throws RemoteException{
>> UnicastRemoteObject.export(this, 80, new MyClientFactory(),
>> new MyServerFactory());
>> }
>> ---schnapp---
>> If you need a complete example, write me.
>> RMI is written for use in an Intranet. A better way is to use
>> Webservices to solve your problem (e.g. AXIS).
>
> To the OP: You've had two good replies here. I must admit that I was
> thinking Web Services simply because of portability issues. But the
> proxy approach is mature and enjoys wide support.
> IOW, you'd be well served by either solution.
> Good luck!
>

Thanks. I will try to keep this quality and improve my english.



--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/