-
1. Re: Naming over Remoting 3
starksm64 Nov 20, 2009 2:20 PM (in response to ron_sigal)"DML" wrote:
One observation that's neither here nor there - ALR has been kicking around
a "back to basics" simple invocation mechanism that should work for all
Things That Call Remote Methods Via a Proxy (tm), for EJB3 and whatever
else it may apply to, which opens the possibility to come up with a
standard Remoting 3 invocation service of some sort.
It looks pretty good to me so far. It lives here:
http://anonsvn.jboss.org/repos/common/invokablecontainer/trunk/api/
Granted realistically this is going to apply more to what we stick *in*
JNDI, than how JNDI is itself implemented (which, afaict, -could- just be a
straight-up Remoting 3 service type, though that'd be a more significant
departure from the current implementation from what I understand of it,
than sticking with something more RMI-like). -
2. Re: Naming over Remoting 3
starksm64 Nov 20, 2009 2:21 PM (in response to ron_sigal)"Carlo" wrote:
Whether it will be ATTCTMVP (tm) or something else ( for example
http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/remoting2/src/main/java/org/jboss/ejb3/remoting/endpoint/RemotableEndpoint.java
) remains to be seen. I like
http://anonsvn.jboss.org/repos/common/invokablecontainer/trunk/api/src/main/java/org/jboss/ejb3/container/api/Invocation.java
with the exception that target is not a first class citizen.
AOPRemotingInvocationHandler & Dispatcher definitely need to go. The
first, because remoting is not an aspect, the second because it's a
singleton with weird SPI (
http://fisheye.jboss.org/browse/JBossAS/trunk/ejb3/src/main/org/jboss/ejb3/session/ClassProxyHack.java?r=69926
).
Now if you put JNDI, Remoting and proxies in one sentence one
requirement is the most important:
- all proxies must be transport unaware.
So if I bind an EJB into JNDI it doesn't matter whether I lookup through
an HTTP(S), IIOP or whatever to get a proxy tied to the connection with
which I'm communicating with AS.
The same goes for clustering, that is just a virtual connection to a
virtual host (/ real cluster). -
3. Re: Naming over Remoting 3
brian.stansberry Nov 20, 2009 2:27 PM (in response to ron_sigal)"Carlo" wrote:
Now if you put JNDI, Remoting and proxies in one sentence one
requirement is the most important:
- all proxies must be transport unaware.
So if I bind an EJB into JNDI it doesn't matter whether I lookup through
an HTTP(S), IIOP or whatever to get a proxy tied to the connection with
which I'm communicating with AS.
The same goes for clustering, that is just a virtual connection to a
virtual host (/ real cluster).
So are you saying that if the JNDI lookup is done over HTTPS, the EJB invocations should therefore also come over HTTPS? -
4. Re: Naming over Remoting 3
starksm64 Nov 20, 2009 2:31 PM (in response to ron_sigal)My main desire is to have consistent transport configuration across all layers including the naming bootstrap. In addition, the java RMI bootstrap does have configuration problems in that it requires the java.rmi.server.hostname system property, has a separate class loading mechanism, no control over the connection thread pool, etc.
-
5. Re: Naming over Remoting 3
ron_sigal Nov 20, 2009 5:25 PM (in response to ron_sigal)"brian" wrote:
"carlo" wrote:
Now if you put JNDI, Remoting and proxies in one sentence one
requirement is the most important:
- all proxies must be transport unaware.
So if I bind an EJB into JNDI it doesn't matter whether I lookup through
an HTTP(S), IIOP or whatever to get a proxy tied to the connection with
which I'm communicating with AS.
The same goes for clustering, that is just a virtual connection to a
virtual host (/ real cluster).
So are you saying that if the JNDI lookup is done over HTTPS, the EJB invocations should therefore also come over HTTPS?
I was wondering the same. Also, by "tied to the connection" do you mean (1) using the same connection with which you are communicating with AS, or (2) using some connection with the same transport that you are using to communicate with AS? -
6. Re: Naming over Remoting 3
wolfc Nov 23, 2009 4:23 AM (in response to ron_sigal)The most important bit herein is that the proxy itself should not contain any transport information. Whatever we put into JNDI is not fully aware of the network topology. Take for example a NAT firewall. In that case only the client knows how to communicate to AS. Although we could inform the server somehow, it is really outside of its scope.
-
7. Re: Naming over Remoting 3
dmlloyd Nov 23, 2009 10:40 AM (in response to ron_sigal)"wolfc" wrote:
The most important bit herein is that the proxy itself should not contain any transport information. Whatever we put into JNDI is not fully aware of the network topology. Take for example a NAT firewall. In that case only the client knows how to communicate to AS. Although we could inform the server somehow, it is really outside of its scope.
The proxy would have to know some transport information. If it does not, there is no way for the client (or whoever reads the proxy from JNDI) to know where it's connecting back to, or how.
That said, the connection information (at least, as pertains to Remoting 3) could amount to "whatever connection this proxy came in on", and that'd probably be OK.
However, I don't see any sensible way we can get around having separate proxy implementations for IIOP/JRMP/Remoting/whatever. -
8. Re: Naming over Remoting 3
brian.stansberry Nov 23, 2009 11:04 AM (in response to ron_sigal)"david.lloyd@jboss.com" wrote:
"wolfc" wrote:
The most important bit herein is that the proxy itself should not contain any transport information. Whatever we put into JNDI is not fully aware of the network topology. Take for example a NAT firewall. In that case only the client knows how to communicate to AS. Although we could inform the server somehow, it is really outside of its scope.
The proxy would have to know some transport information. If it does not, there is no way for the client (or whoever reads the proxy from JNDI) to know where it's connecting back to, or how.
For a cluster it's more tricky. The client might know how it connected to the JNDI server but it won't have any idea how to connect to the other nodes in the cluster."david.lloyd@jboss.com" wrote:
However, I don't see any sensible way we can get around having separate proxy implementations for IIOP/JRMP/Remoting/whatever.
Are we finally going to get rid of JRMPInvoker in AS 6? -
9. Re: Naming over Remoting 3
ron_sigal Nov 23, 2009 2:59 PM (in response to ron_sigal)Update.
I've got a version of Naming running over Remoting 3.
On the server side, there's an org.jnp.server.remoting.NamingServerRequestListener, an invocation handler, that just wraps an instance of org.jnp.server.NamingServer.
On the client side, there's an org.jnp.interfaces.remoting.NamingProxyFactory, which creates a Remoting 3 client connected to a Remoting 3 server and returns a proxy that wraps the client and implements org.jnp.interfaces.Naming. org.jnp.interfaces.NamingContext.getServer() then calls NamingProxyFactory.getNamingProxy() instead of the current bootstrap process. Everything else stays the same.
Right now the Remoting 3 client is sending its requests in instances of org.jboss.invocation.MarshalledInvocation, since invokablecontainer was complaining that my version of maven was too new, but I guess it wouldn't be too hard to replace MarshalledInvocation with invokablecontainer's version. -
10. Re: Naming over Remoting 3
ron_sigal Nov 23, 2009 3:18 PM (in response to ron_sigal)"david.lloyd@jboss.com" wrote:
The proxy would have to know some transport information. If it does not, there is no way for the client (or whoever reads the proxy from JNDI) to know where it's connecting back to, or how.
A URL, or a set of URLs in the case of clustering, would be transport independent, yet sufficient information to contact the server (at least for some transports)."david.lloyd@jboss.com" wrote:
That said, the connection information (at least, as pertains to Remoting 3) could amount to "whatever connection this proxy came in on", and that'd probably be OK.
I've started thread "Remoting 3 protocol SPI" on the Remoting design forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267127#4267127) for related Remoting specific discussion."david.lloyd@jboss.com" wrote:
However, I don't see any sensible way we can get around having separate proxy implementations for IIOP/JRMP/Remoting/whatever.
To a certain extent, there could be a general purpose "client" API that let's you just plug in a URL. Something likeinterface ProtocolBuilder { static Protocol getProtocol(String protocol); } interface Protocol { static getClient(URL url, Map config); } interface Client { Object invoke(Object invocation, Map metadata); void close(); }
You'd have to register each protocol with ProtocolBuilder. I don't know enough about IIOP to know if it would work there, but I'm pretty sure it's general enough for, say, Remoting 2 and Remoting 3. And isn't that the whole world? :) -
11. Re: Naming over Remoting 3
brian.stansberry Nov 23, 2009 3:38 PM (in response to ron_sigal)"ron.sigal@jboss.com" wrote:
On the client side, there's an org.jnp.interfaces.remoting.NamingProxyFactory, which creates a Remoting 3 client connected to a Remoting 3 server and returns a proxy that wraps the client and implements org.jnp.interfaces.Naming. org.jnp.interfaces.NamingContext.getServer() then calls NamingProxyFactory.getNamingProxy() instead of the current bootstrap process. Everything else stays the same.
Will there be step where the server controls creation of the proxy used for the actual lookup? With what you describe above, the creation of the proxy is completely driven by the client. Which is fine for the initial connection to the server, but removes the ability for the server to customize the proxy. -
12. Re: Naming over Remoting 3
dmlloyd Nov 23, 2009 3:50 PM (in response to ron_sigal)Also, please realize that if you've gotten something out of JNDI over the naming service, you should already have a connection to the server (or as Brian points out, at least one of the cluster). Or the server may have a connection to you. Getting or creating the proxy should not necessarily cause the creation of a connection, in my opinion. We need to figure out a way to decouple the creation of connections from the service (they even have separate URI schemes), otherwise the whole idea of multiple clients sharing a connection is defeated.
-
13. Re: Naming over Remoting 3
ron_sigal Nov 23, 2009 5:21 PM (in response to ron_sigal)"bstansberry@jboss.com" wrote:
Will there be step where the server controls creation of the proxy used for the actual lookup? With what you describe above, the creation of the proxy is completely driven by the client. Which is fine for the initial connection to the server, but removes the ability for the server to customize the proxy.
Actually, the proxy returned by NamingProxyFactory is the proxy that does the actual lookup. Hmmm. Are you referring, perhaps, to using JRMPProxyFactory to add interceptors to a proxy? I didn't think of that, probably since there don't seem to be any actual examples in the out-of-the-box configurations. OK, I'll work on that. -
14. Re: Naming over Remoting 3
ron_sigal Nov 23, 2009 5:34 PM (in response to ron_sigal)"david.lloyd@jboss.com" wrote:
Also, please realize that if you've gotten something out of JNDI over the naming service, you should already have a connection to the server (or as Brian points out, at least one of the cluster). Or the server may have a connection to you. Getting or creating the proxy should not necessarily cause the creation of a connection, in my opinion. We need to figure out a way to decouple the creation of connections from the service (they even have separate URI schemes), otherwise the whole idea of multiple clients sharing a connection is defeated.
In Remoting 2, there is a level of indirection between user facing Client objects and network facing invokers. If an app creates two Clients with the same InvokerLocators and the same config maps, they will share the same invoker, which, depending on the transport, typically means sharing the same connection pool. In other words, creating a Client does not necessarily imply creating a new connection.
What about doing the same thing in R3 Endpoint.connect()? I.e., keep a repository of reusable connections, keyed on URI and OptionMap?