4 Replies Latest reply on Nov 23, 2011 5:04 AM by dastraub

    Support for remote invocation - Question about JNDI names

    dastraub

      Thanks for resolving this issue !

      I read your announcement (http://community.jboss.org/thread/175081?tstart=0)

      and the description in https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+client+using+JNDI.

       

      The JNDI Name (what is used by the lookup) use the following pattern :

       

        "ejb:" + appName + "/" + moduleName + "/" + distinctName + "/" + beanName + "!" + viewClassName

       

      This is impractial because the client has to know a lot of (private) informations and implementation details of the remote application :

       

      • the appName/moduleName (name of the ear or jar file) contains often a version number or other extensions (like SNAPSHOT) - that means this part isn't constant. The client needs update with every new version ...
      • the beanName is the name of the implementation class, so in your code sample the client has a dependency to this internal detail of the app ! Don't refactor ...
      • viewClassName : that's the only thing what the client really know !

       

      We had this meaningless pattern also whith the previous JBoss version (where we have to add "remote" oder "local"), but there was way to define the JNDI name in the jboss.xml or use a JBoss specific annotiations.

      Hopefully this feature will come back !

        • 1. Re: Support for remote invocation - Question about JNDI names
          jaikiran

          Daniel Straub wrote:

           

           

          • the appName/moduleName (name of the ear or jar file) contains often a version number or other extensions (like SNAPSHOT) - that means this part isn't constant. The client needs update with every new version ...

          This can be overriden to a name of your choice in the application.xml (for application names) and ejb-jar.xml/web.xml (for module names).

           

           

          Daniel Straub wrote:

           

          • the beanName is the name of the implementation class, so in your code sample the client has a dependency to this internal detail of the app ! Don't refactor ...

          Again, this can be overriden to whatever name you want to give, either via the "name" attribute of @Stateless/@Stateful annotation or via ejb-jar.xml

           

           

          Having said that, we are definitely going to think whether this can improved. Thanks for the feeback!

          1 of 1 people found this helpful
          • 2. Re: Support for remote invocation - Question about JNDI names
            dastraub

            Thats makes the picture clearer - particulary the correlation between the different names and where to redefined this !

             

            Another question to the "jboss-ejb-client.properties" file.

            This looks like what mod_cluster resolved for web applications comes now back for remote ejb-calls (worker.properties ...)

            In the past we uses only two standard properties : Context.PROVIDER_URL and CONTEXT.INITIAL_CONTEXT_FACTORY to define a remote connection. Now we need an additional property file.

            It is not possible for a ContextFactory to initialize the remoting stuff with defaults and other given properties ?

             

            In the past we had also the following options :

            - ejb3-interceptors-aop.xml to define or fine tuning the client and server side interceptor stack. We used this also very often to add some 'vertical behavior' to applications at system level

            - clustering : failover for stateless, replication for stateful sessionbeans

             

            Where are this features now ?

            • 3. Re: Support for remote invocation - Question about JNDI names
              jaikiran

              Daniel Straub wrote:

               

              Thats makes the picture clearer - particulary the correlation between the different names and where to redefined this !

              Yeah, I actually have already described these details in that chapter https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+client+using+JNDI. You probably missed it (but that's OK).

               

              Daniel Straub wrote:

               

              Another question to the "jboss-ejb-client.properties" file.

              This looks like what mod_cluster resolved for web applications comes now back for remote ejb-calls (worker.properties ...)

              It might look similar but mod_cluster wasn't what we had in mind when we came up with that file But yeah, I see what you mean. That properties file is a way to configure your client to point to server targets.

               

              Daniel Straub wrote:

               

              In the past we uses only two standard properties : Context.PROVIDER_URL and CONTEXT.INITIAL_CONTEXT_FACTORY to define a remote connection. Now we need an additional property file.

              It is not possible for a ContextFactory to initialize the remoting stuff with defaults and other given properties ?

               

              The jboss-ejb-client.properties isn't just meant for JNDI lookups. Although the JNDI lookups do by default use that information for communicating with the server. That's one of the reasons why we did not add these details to the jndi.properties. As for guessing some default values - I think the only thing that we could guess is the host property for a connection and default it to localhost and the port property and default it to 4447. But that really won't be useful for real applications because:

               

              1) For real applications, the host isn't really a localhost since it's a remote client

              2) For establishing a connection, we need to authenticate with the server which means that the client has to configure the authentication information. This is something we cannot and shouldn't really guess.

               

              That's just some of the reasons that I can think of now, for not defaulting to some values for establishing a connection. Ultimately the client would have to configure the properties file for the application (where or not we default some of those values).

               

              Daniel Straub wrote:

               

              In the past we had also the following options :

              - ejb3-interceptors-aop.xml to define or fine tuning the client and server side interceptor stack. We used this also very often to add some 'vertical behavior' to applications at system level

              AS7 no longer relies on AOP for interceptors. Neither on the client side nor on the server side. We do have a way to allow client interceptors, but I think I'll have to look at it a bit to see if we can improve the implementation and allow for a deterministic ordering of the client interceptors. I'll take a look at this, during this week. But the real question is, what kind of logic do you expect in your client interceptors? Can you explain that "vertical behaviour" use case and other use cases where you used these interceptors?

               

              - clustering : failover for stateless, replication for stateful sessionbeans

              That's something we haven't yet implemented for EJBs. There's a discussion on the AS7 dev mailing list on how it might be implemented, but right now it's not ready.

              1 of 1 people found this helpful
              • 4. Re: Support for remote invocation - Question about JNDI names
                dastraub

                Can you explain that "vertical behaviour" use case and other use cases where you used these interceptors?

                 

                Some examples :

                • in a large distributed application (with 2-4 server hops) we add a unique ID (in fact we use the HTTP session id) to follow a call trough different servers (logs). That means, the first client add his ID in the invocation metadata and by the following servers in a interceptor we put this in  the log4j NDC or in a thread local
                • same idea : in a financial application we had the requirement to log the ip-adresses of the caller, at caller side we add this to the transport and reuse it at receiver side
                • in a application where we use some kind of "time shifting" we initialize some variables in a interceptor
                • and so on

                 

                As you can see, we use it for logging purpose, transfering additional data or use the interceptor for global initializing.