9 Replies Latest reply on Jul 29, 2008 12:16 PM by alrubinger

    @RemoteBindings and clientBindUrl - JNDI binding question

    jaikiran

      As part of a test case for EJBTHREE-1423, i am testing that the @RemoteBindings on a bean is being honoured. I am not completely clear about how the clientBindUrl works:

      @Stateless
      @RemoteBindings (
       {
       @RemoteBinding (jndiBinding=MyStatelessBeanWithMultipleRemoteBindings.REMOTE_JNDI_NAME),
       @RemoteBinding (jndiBinding=MyStatelessBeanWithMultipleRemoteBindings.ANOTHER_REMOTE_JNDI_NAME, clientBindUrl=MyStatelessBeanWithMultipleRemoteBindings.CUSTOM_CLIENT_BIND_URL)
       }
      
      )
      @Remote (MyStatelessRemote.class)
      public class MyStatelessBeanWithMultipleRemoteBindings implements MyStatelessRemote
      {
      
       /**
       * Remote jndi name
       */
       public static final String REMOTE_JNDI_NAME = "SomeJndiName";
      
       /**
       * Another remote jndi name
       */
       public static final String ANOTHER_REMOTE_JNDI_NAME = "AnotherJndiName";
      
       /**
       * Client bind url
       */
       public static final String CUSTOM_CLIENT_BIND_URL = "0.0.0.0:3333";
      
      ...
      }


      Based on my understanding, i expect the bean to be bound to "SomeJndiName" (communication happens through default port 3873) and also "AnotherJndiName" (communication happens through custom port 3333). Is this correct? Right now, in my test case i see that the bean is never bound to the "AnotherJndiName" and instead its bound only to "SomeJndiName"



        • 1. Re: @RemoteBindings and clientBindUrl - JNDI binding questio
          jaikiran

          Btw, this is the -beans.xml, i use for the test case:

          <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="urn:jboss:bean-deployer:2.0 bean-deployer_2_0.xsd"
           xmlns="urn:jboss:bean-deployer:2.0">
          
          .....
           <!-- Remoting Connector -->
           <bean name="Connector"
           class="org.jboss.remoting.transport.Connector">
           <property name="invokerLocator">socket://0.0.0.0:3873</property>
           <property name="serverConfiguration">
           <inject bean="ServerConfiguration" />
           </property>
           </bean>
          
           <bean name="AnotherConnector"
           class="org.jboss.remoting.transport.Connector">
           <property name="invokerLocator">socket://0.0.0.0:3333</property>
           <property name="serverConfiguration">
           <inject bean="ServerConfiguration" />
           </property>
           </bean>
          
          </deployment>
          


          • 2. Re: @RemoteBindings and clientBindUrl - JNDI binding questio
            wolfc

            There are two problems in the design itself:

            1. The transport should be independent of the jndi binding. So depending on which transport I use to connect to jndi (for example https) I should get another client binding. This is an AS issue.
            2. The relationship between remote business interfaces and remote bindings is as of yet not properly specified.

            Let's focus on number 2, because #1 takes more than a simple fix.

            The goal is to give the bean developer the ability to specify a client bind url per remote business interface. Now in your example you have 2 bindings and 1 interface.
            In my mind clientBindUrl is an attribute of the remote business interface. But this doesn't allow for multiple bindings per interface.

            I'm open for any suggestions, but it should not lead to an API change.

            • 3. Re: @RemoteBindings and clientBindUrl - JNDI binding questio
              jaikiran

               

              "wolfc" wrote:


              The goal is to give the bean developer the ability to specify a client bind url per remote business interface. Now in your example you have 2 bindings and 1 interface.


              I started off with this test based on what i read here http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/transport.html#d0e786. The example there is similar, in the sense that it has a single remote interface but with 2 RemoteBinding. Has that behaviour changed?

              Currently I don't see a way where i can associate a remote business interface (rather than a remote jndi binding) with a client bind url? To make it more clear:


              @RemoteBindings (
               {
               @RemoteBinding (jndiBinding=MyStatelessBeanWithMultipleRemoteBindings.REMOTE_JNDI_NAME),
               @RemoteBinding (jndiBinding=MyStatelessBeanWithMultipleRemoteBindings.ANOTHER_REMOTE_JNDI_NAME, clientBindUrl=MyStatelessBeanWithMultipleRemoteBindings.CUSTOM_CLIENT_BIND_URL)
               }
              
              public class MyStatelessBeanWithMultipleRemoteBindings implements MyStatelessRemote, AnotherRemote
              


              Currently, I can't specify that the @RemoteBinding with a CUSTOM_CLIENT_BIND_URL is for the "AnotherRemote" business interface.

              "wolfc" wrote:

              In my mind clientBindUrl is an attribute of the remote business interface.


              Since the intention is to allow the bean developer to specify a client bind url per remote business interface, shouldn't the @RemoteBinding have a provision where the beanInterface can be mentioned. Maybe a "beanInterface" property to the @RemoteBinding annotation?. Just a thought, maybe there's a better way to handle this. In terms of API changes, not sure how big this change would be.


              • 4. Re: @RemoteBindings and clientBindUrl - JNDI binding questio
                alrubinger

                 

                "wolfc" wrote:
                2. The relationship between remote business interfaces and remote bindings is as of yet not properly specified.


                True statement.

                "wolfc" wrote:
                The goal is to give the bean developer the ability to specify a client bind url per remote business interface


                Did you make that up just now? Where is this defined? :) Kinda goes against the idea of @RemoteBinding(s) at the class-level.

                Historically, we've only made available one type of Proxy in JNDI (for each local and remote), which supported EJB2.x Interfaces, EJB2.x Home Interfaces, and EJB3 Business Interfaces. Now we have:

                * Eliminated the binding of EJB2.x Proxies entirely (they may only be obtained via Home.create())
                * An EJB3.0 Business Default Business Proxy (the most widely-used client lookup target, which supports each of the business interfaces bound)
                * An EJB3.0 Business Interface-Specific Proxy (one per bound business interface, these are used as injection/ENC lookup targets and are loaded with the stuff that gives getInvokedBusinessInterface() contextual information).
                * An EJB2.x Home Proxy, which may be bound to the same Proxy as the EJB3 Default Business Interface.

                So I read many @RemoteBindings as targeted to expose any N number of bindings for the Default Business Interface Proxy.

                So if we have:

                @RemoteBinding(jndiBinding="Busi1")
                public interface MyBusinessInterface1{...}
                
                @RemoteBinding(jndiBinding="Busi2")
                public interface MyBusinessInterface2{...}
                
                public interface MyBusinessInterface3{...}
                
                @Stateless
                @RemoteBindings({
                 @RemoteBinding(jndiBinding="MyBean")
                 @RemoteBinding(jndiBinding="MySSLBean", clientBindUrl="sslsocket://0.0.0.0:3843")
                })
                public class MyBean implements MyBusinessInterface1, MyBusinessInterface2, MyBusinessInterface3{...}


                ..then we've defined @RemoteBindings at both the interface and EJB level. As a user I'd expect to find in the JNDI Tree:

                + Busi1 (Proxy implements MyBusinessInterface1)
                + Busi2 (Proxy implements MyBusinessInterface2)
                + MyBean (Proxy implements MyBusinessInterface1, MyBusinessInterface2, MyBusinessInterface3)
                + MySSLBean ((Proxy implements MyBusinessInterface1, MyBusinessInterface2, MyBusinessInterface3) < Exposes SSL Transport


                This way, an interface-targeted JNDI Binding is specified at the interface level, and any @RemoteBinding(s) on the class level apply to all Remote Business Interfaces. And it'd require no API changes.

                S,
                ALR

                • 5. Re: @RemoteBindings and clientBindUrl - JNDI binding questio
                  alrubinger

                   

                  "jaikiran" wrote:
                  Currently, I can't specify that the @RemoteBinding with a CUSTOM_CLIENT_BIND_URL is for the "AnotherRemote" business interface


                  Sure, see my last post; put it on the interface itself, not on the class.

                  A more sticky subject here is HTF do we support this in jboss-xml? ;) For that we *would* need a "target-interface"-type element.

                  S,
                  ALR

                  • 6. Re: @RemoteBindings and clientBindUrl - JNDI binding questio
                    jaikiran

                     

                    "ALRubinger" wrote:
                    "jaikiran" wrote:
                    Currently, I can't specify that the @RemoteBinding with a CUSTOM_CLIENT_BIND_URL is for the "AnotherRemote" business interface


                    Sure, see my last post; put it on the interface itself, not on the class.



                    Oops, i had missed that point.

                    • 7. Re: @RemoteBindings and clientBindUrl - JNDI binding questio
                      jaikiran

                       

                      So I read many @RemoteBindings as targeted to expose any N number of bindings for the Default Business Interface Proxy.


                      So if the @RemoteBindings is just a way to specify multiple bindings, can the clientBindUrl for these N number of bindings can be same or should they differ? I mean can there be 2 different bindings on the same clientBindUrl and the user can expect the proxy to be bound to both these jndi names :


                      @Stateless
                      @RemoteBindings({
                       @RemoteBinding(jndiBinding="MyBean")
                       @RemoteBinding(jndiBinding="AgainMyBean") --> same default clientBindUrl
                      })
                      public class MyBean implements MyBusinessInterface1, MyBusinessInterface2, MyBusinessInterface3{...}
                      


                      Just wanted to understand whether the clientBindUrl is just another property of the @RemoteBinding or is it the deciding factor on the number of bindings for the default business proxy.




                      • 8. Re: @RemoteBindings and clientBindUrl - JNDI binding questio
                        jaikiran

                         

                        "jaikiran" wrote:
                        I mean can there be 2 different bindings on the same clientBindUrl and the user can expect the proxy to be bound to both these jndi names


                        Just revisited Andrew's example. It answers my question.



                        • 9. Re: @RemoteBindings and clientBindUrl - JNDI binding questio
                          alrubinger

                           

                          "jaikiran" wrote:
                          Just revisited Andrew's example. It answers my question.


                          My example is more a proposal for re-fitting @RemoteBinding into the changes we've made to which proxies are bound where. Let's get some consensus first. ;)

                          S,
                          ALR