1 2 3 4 Previous Next 46 Replies Latest reply on Jan 20, 2010 12:13 AM by ron_sigal

    Naming over Remoting 3

    ron_sigal

      We're starting to look at adapting the Naming system to run over Remoting 3, so I'm opening this thread for any related discussion.

      One issue has arisen in the context of JBAS-3151 "Convert HA-JNDI stubs to Remoting":

      "ron" wrote:

      ...
      Is there anything wrong with HARMIClient and HARMIServer, other than the fact that they depend on RMI?
      ---


      "brian" wrote:

      Not particularly, no. I think the main issues are 1) we want to unify as much as possible on a single remote invocation mechanism 2) get rid of myriad sockets opened by different services. I suppose the latter goes beyond the description of this JIRA as it involve converting HANamingService to use a Remoting connector instead of directly listening on port 1101.


      "ron" wrote:

      It looks like there are two kinds of Naming listeners:

      1. the "bootstrap" listeners in org.jnp.server.Main and org.jboss.ha.jndi.HANamingService, and

      2. the actual service listeners: org.jnp.server.NamingServer and org.jboss.ha.framework.server.HARMIServerImpl

      So, we'd like to replace them all with handlers on a single Remoting connector (or, actually, the Remoting 3 version of of handlers and connectors).


      "brian" wrote:

      The bootstrap listener part probably bears discussion on the jboss-dev list since it much more directly impacts stuff like end-user configuration (i.e. jndi.properties or other ways of setting the properties passed to new InitialContext()). The service listeners are more straightforward.


      Any comments?

        • 1. Re: Naming over Remoting 3
          starksm64


          "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

             

            "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

               

              "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

                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

                   

                  "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

                    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

                       

                      "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

                         

                        "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

                          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

                             

                            "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 like

                            interface 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

                               

                              "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

                                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

                                   

                                  "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

                                     

                                    "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?

                                    1 2 3 4 Previous Next