Have you looked at SOAP over http?
On Tue, 6 Mar 2001, David Mease wrote:
> RMI through HTTP proxyI'm desperate to get HTTP tunneling working in JBoss.
> It works very well in Weblogic and Orion but I have a client that wants to
> use JBoss with tunneling. I don't have any insight into how to get it
> working but I'm just showing support to have it added to JBoss.
>
> FYI, in Weblogic to use HTTP tunneling you add the following properties to
> the weblogic.properties file:
> weblogic.httpd.tunnelingenabled =true
> weblogic.httpd.requireAuthentication=false
>
> and replace the t3 protocol with http when initializing the context.
>
> In Orion you just add http:// when initializing the context.
>
> Thanks,
> David Mease
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Marko �trukelj
> Sent: Thursday, March 01, 2001 9:18 AM
> To: '[EMAIL PROTECTED]'
> Subject: [jBoss-User] RMI through HTTP proxy
>
>
>
>
> Hi,
>
> I've been playing with the possibility of doing rmi on beans deployed in
> jboss through HTTP proxy and there are some things that are very funny, so
> if someone can clarify things it would be great.
>
> Ok. When there is a code like this in the client:
>
> InitialContext ctx=new InitialContext();
> BeanHome home=(BeanHome) ctx.lookup("MyBean");
> Bean remote=(Bean) home.findByPrimaryKey("1");
> String something=remote.getSomething();
>
>
>
> A network connection is opened when lookup is done. Connections to port
> 1099, 5555 and 4444 are opened.
>
> Port 1099 is used by jnp - it uses it's own protocol and doesn't allow for
> HTTP proxy tunneling.
> Port 5555 also seems to be used by jnp, without client being allowd to
> connect out to that port, ctx.lookup can not succeed.
>
>
>
> I suspect it doesn't allow for HTTP Proxy tunneling.
>
>
>
> 4444 is a standard rmi port - I guess it uses jrmp and should work like
> the rmi specification claims and in case we disable port 4444 attempt a
> proxy. How does java know on which host:port to look for proxy? Seems it
> doesn't. You can find on varous chat forums how you could tell that to jdk
> 1.1.x :
>
> You could supposedly put these on your command line:
>
> -DproxySet=true -DproxyHost=myproxyhost -DproxyPort=8080
>
> But the truth is, this doesn't work with jdk1.3
> rmi doesn't make any attempt to any port other that 4444. It doesn't try
> direct connection to port 80, it doesn't try a proxy server, it just
> doesn't. This is what I find very funny, since there is whole chapters in
> rmi specification dedicated to proxy tunnelling and there is even a servlet
> as a replacement for .cgi to be used for proxy-ing RMI via HTTP.
>
> It seems to me that if I wanted a client to talk to an EJB server (either
> jboss or some other), without making any change in the existing code, then
> what I would have to do would be:
>
> Write my own jndi implementation, replace
>
> -Djava.naming.factory.initial=org.jnp.interfaces.NamingContextFact
> ory
>
> with something like
>
> -Djava.naming.factory.initial=com.mine.NamingContextFactory.
>
> This implementation would allow for configuring the proxy host and proxy
> port and would wrap all lookup requests in HTTP POST messages, send them to
> machine B where HTTP proxy is located and that would forward it to machine C
> where jboss and my naming service implementation is located. My naming
> service would act as a proxy to jnp. It could be written so that there would
> be no need to explicitly bind names to it, whatever requests it got it would
> just attempt them on jboss. It would wrap the results and send them back.
>
> But! If we just wrapped the results we would still have proxies on the
> client that would attempt to communicate through jrmp - which won't work. So
> what we need to, we need to manage what jboss returns on the server side and
> send our implementation of proxy objects and stubs to the client side, so
> all rmi calls will be marhalled into HTTP POST request, unmarshalled and
> forwarded thoru remote calls on objects that jboss returned, then the
> results marhalled into HTTP responses and sent back.
>
> Thus far it looks like a real mess.
>
> Is there any other way that would be EJB server independent?
>
> I know there is zoap, but you have to make remote calls in completely
> different way, also you have bunch of complications deploying your beans.
> Because you had to code your client differently you can not go back to
> direct rmi in environments that allow that.
>
>
>
> Thanks for any comments,
>
>
>
> Marko.
>
>
--
Dan Christopherson (danch)
nVisia Technical Architect (www.nvisia.com)
Opinions expressed are mine and do not neccessarily reflect any
position or opinion of nVISIA.
---------------------------------------------------------------------------
If you're a capitalist and you have the best goods and they're
free, you don't have to proselytize, you just have to wait.
-Eben Moglen
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
