corba in java applets using http tunnel?
h_cl...@yahoo.com
I have the problem that a java applet needs to communicate with the
webserver, which delivered the applet, through corba. To allow the
applet to work across every firewall, communication needs to happen on
port 80. I found posts that mention this is possible using tunneling,
but how do I actually combine corba and tools like www.nocrew.org/software/httptunnel.html
(or others)?
Can I find an example anywhere which explains how to use corba through
tunneling? It's ok, if the example uses another port and tunnel
software, for example openssh. But I have no idea, where to start.
The next question is probably more on-topic in other groups, but maybe
you can also give a short answer: if the java applet really
communicates through a port 80 tunnel, do I have to expect any
interference with the standard http protocol while the webpage is
transferred, which embeds the java applet?
Thanks
Clemens
Thomas Richter
Probably not a direct answer, but some experiences for share:
I'm doing CORBA in applets here, and in addition to the firewall
problem, the applet needs to be signed to communicate to the outside,
which might open another problem. In the long run, my impression from
Corba is that it is, by the time, pretty much dead, and we're about to
move the communication from Corba to a different technology which can
archive similar.
Sorry that I cannot help with a direct answer, but if you still have a
choice picking the technology, I would check for other options besides
Corba as well.
So long,
Thomas
Rob Ratcliff
> Hello,
> I have the problem that a java applet needs to communicate with the
> webserver, which delivered the applet, through corba. To allow the
> applet to work across every firewall, communication needs to happen on
> port 80. I found posts that mention this is possible using tunneling,
> but how do I actually combine corba and tools like www.nocrew.org/software/httptunnel.html
> (or others)?
>
port. (Please people chime in if this is not your experience.) I have
seen some large companies use an HTTP proxy server to handle all
outbound traffic, which would force you to use HTTP in your applet if
you are concerned about that situations. Some companies also have SOCKS
proxies as well as HTTP proxies that are configured in the web browser
so CORBA should work in that case.
For the HTTP proxy case, I've seen some code in the TAO ORB that
implements a custom IIOP/HTTP protocol called HTIOP. I imagine that
idea could be extended to JacORB for instance if you had the time and
the interest (or funding for one of the open source CORBA support
vendors like PrismTech to implement it).
> Can I find an example anywhere which explains how to use corba through
> tunneling? It's ok, if the example uses another port and tunnel
> software, for example openssh. But I have no idea, where to start.
>
It is too bad that this hasn't been addressed aggressively by the OMG.
Basically, everybody is forced to use lowest-common-denominator HTTP
solutions now if you want to communicate across all firewalls, which is
too bad. RMI has a solution where it will switch to JRMP over HTTP when
it can't communicate directly. Then there is a proxy on the server-side
that will convert the encoded binary blob in the HTTP request to a local
RMI call. Sun has an external program that will do that and a servlet
solution as well. CORBA could do the same thing if somebody was inclined
and had the time.
BTW, I noticed this apache project where they seem to be creating a
CORBA binding using WSDL for Celtix.
http://cwiki.apache.org/YOKO/module-overview.html
It is possible that there is a SOAP/CORBA adapter that could be used for
HTTP proxy cases.
> The next question is probably more on-topic in other groups, but maybe
> you can also give a short answer: if the java applet really
> communicates through a port 80 tunnel, do I have to expect any
> interference with the standard http protocol while the webpage is
> transferred, which embeds the java applet?
>
Well, without signing the applet, there is this security restriction
that applets can only communicate with the same host from which they
were downloaded. If your web server is listening on port 80, then your
CORBA server couldn't be listening on port 80 as well on the same host
without some fancy redirector based on protocol (similar to Sun's
RMI/HTTP solution.)
Now, if you want to do callbacks to your applet from the server, then
you're also going to run into other problems. JacORB for instance
supports bidirectional GIOP where the outgoing connection from the
applet to the server is reused by the server when making a connection
back to the client to issue an asynchronous callback so that should
solve the cases without HTTP proxies. If you have a HTTP proxy impeding
your way, then you'll have to resort to a polling solution to get your
data.
mesn...@ociweb.com
On Mar 26, 8:52 pm, Rob Ratcliff <rrr6...@futuretek.com> wrote:
> h_clem...@yahoo.com wrote:
> > Hello,
> > I have the problem that a java applet needs to communicate with the
> > webserver, which delivered the applet, through corba. To allow the
> > applet to work across every firewall, communication needs to happen on
> > port 80. I found posts that mention this is possible using tunneling,
> > but how do I actually combine corba and tools likewww.nocrew.org/software/httptunnel.html
> > (or others)?
httptunnel appears to be implemented as a pair of stand-alone
processes, one each for the client and server side. If you are
delivering a service as an applet, you would also have to convince
your user to install the htc service inside their firewall. Good luck
with that. :-)
The best you can do is something from within your applet. As Rob and
Thomas have pointed out, communicating from an applet is intrinsically
restricted. You mentioned connecting back to the originating host, so
that certainly avoids the restriction.
However, given that you are using an applet, I presume you wish to use
the Java ORB for managing CORBA. This ORB is severely restricted in
terms of capabilities. However, in these broadband days, adding a
third-party ORB, such as JacORB, is not too difficult. JacORB would be
a good option.
Before moving on, I would have to say that I agree with Thomas, that
perhaps some higher level analysis is worth while, to see if there is
a way to remove the need for CORBA from the applet. However, I must
say that (to paraphrase Mark Twain) rumors of CORBA's death are
greatly exagerated. Its just gone the way of other robust, stable
systems, out of the limelight.
>
> I think the majority of firewalls allow outgoing connections on any
> port. (Please people chime in if this is not your experience.) I have
> seen some large companies use an HTTP proxy server to handle all
> outbound traffic, which would force you to use HTTP in your applet if
> you are concerned about that situations. Some companies also have SOCKS
> proxies as well as HTTP proxies that are configured in the web browser
> so CORBA should work in that case.
>
> For the HTTP proxy case, I've seen some code in the TAO ORB that
> implements a custom IIOP/HTTP protocol called HTIOP. I imagine that
> idea could be extended to JacORB for instance if you had the time and
> the interest (or funding for one of the open source CORBA support
> vendors like PrismTech to implement it).
>
Or OCI, since we originally authored HTIOP for TAO. :-)
Rob is exactly correct to suggest that many firewalls simply allow
outgoing connections on any port. However, if you require tunneling,
HTIOP combines the behavior of the HTTP tunnel with the ORB
application so that no additional services are required. We currently
only have HTIOP implemented for TAO, but it is indeed possible to
provide an implementation for JacORB. We have received some interest
in making this happen, but no one is willing to fund this. Please feel
free to contact me directly if you would be willing to do so.
> > Can I find an example anywhere which explains how to use corba through
> > tunneling? It's ok, if the example uses another port and tunnel
> > software, for example openssh. But I have no idea, where to start.
>
As with other applications tunneling through proxies, care must be
taken to establish aliases for remote hosts/ports, so that the
application peers are able to connect without knowledge of the proxy.
This requires some administrative effort, at least for configuring the
proxy, and often within the application to set up aliases.
Many CORBA implementations, including JacORB and TAO, directly
implement messaging over SSL or other transports. That simplifies the
administration burden since you now no longer have to set up proxies
on both sides of a secure connection.
> It is too bad that this hasn't been addressed aggressively by the OMG.
> Basically, everybody is forced to use lowest-common-denominator HTTP
> solutions now if you want to communicate across all firewalls, which is
> too bad. RMI has a solution where it will switch to JRMP over HTTP when
> it can't communicate directly. Then there is a proxy on the server-side
> that will convert the encoded binary blob in the HTTP request to a local
> RMI call. Sun has an external program that will do that and a servlet
> solution as well. CORBA could do the same thing if somebody was inclined
> and had the time.
>
There have been various attempts at this over time. The most recent
effort is a tool produced by a collaboration of OCI and Open Messaging
and Collaboration (OMC, 42tools.com). This will soon be released as a
GPL implementation known as Lorica. This tool works as a proxy for
GIOP messages. Coupled with HTIOP, this could serve as a common access
point for many services beind a firewall to be accessed by clients
suffering various access restrictions.
Regards,
Phil