1 Reply Latest reply on Apr 15, 2012 2:49 AM by jaikiran

    Remote client needs to much information to invoke EJB

    armihu

      For remote clients, AS 7.1.1 supports a very nice ejb: JNDI namespace for EJB access. However, I think that the system requires that the client knows too much.

      Currently, in order to invoke an EJB, the client has to know "everything":

       

      • the name of the EAR where the EJB is deployed
      • the name of the JAR where the EJB is deployed
      • the bean name of the EJB
      • the exact business interface class of the EJB

       

      There are, of course, several reasons when all that information is really required, and as such the format and capabilities of the ejb: namespace is fine.

       

      However, I believe that the common case is that a single bean is usually deployed exactly once in a JBoss server instance. This means that in many cases the bean name or even the business interface (or its superinterface) alone uniquely identifies a bean instance on the server.

       

      So it would be great if the ejb: namespace could be used to look up EJB instances with only the bean name, or only with the business interface, or even a superinteface of the business interface.

       

      For example:

       

      • Search by bean name only: ejb:///beanName
      • Search by application and bean name only: ejb:myApp///beanName
      • Search by interface: ejb:///!example.interface.Name

       

      If several remote beans are found with those parameters, then a naming exception would occur.

        • 1. Re: Remote client needs to much information to invoke EJB
          jaikiran

          Arto Huusko wrote:

           

           

          • the name of the EAR where the EJB is deployed

          This isn't exactly the ear name. It's the application name which defaults to ear name. Java EE6 spec allows you to configure the application name in application.xml. So you can name it anything.

           

           

          Arto Huusko wrote:

           

          • the name of the JAR where the EJB is deployed

          Again, the module name isn't always the jar name. It just defaults to the jar name. The spec allows you to configure the name in the ejb-jar.xml or web.xml (for EJBs deployed in war files). So here too you can name it anything.

           

           

          Arto Huusko wrote:

           

          • the bean name of the EJB
          • the exact business interface class of the EJB

           

          These two are obviously required. The bean name by the way can be controlled via annotations or deployment descriptors, both of which are allowed by spec.

           

           

          Arto Huusko wrote:

           

           

          However, I believe that the common case is that a single bean is usually deployed exactly once in a JBoss server instance. This means that in many cases the bean name or even the business interface (or its superinterface) alone uniquely identifies a bean instance on the server.

          I don't think that's really a common case. And even if it was, assuming that and introducing that as a feature within the EJB client API implementation isn't really the right thing. Ultimately a bean is identified by the app name, module name, distinct name and bean name combination.

           

           

          Arto Huusko wrote:

           

           

          So it would be great if the ejb: namespace could be used to look up EJB instances with only the bean name, or only with the business interface, or even a superinteface of the business interface.

           

          For example:

           

          • Search by bean name only: ejb:///beanName
          • Search by application and bean name only: ejb:myApp///beanName
          • Search by interface: ejb:///!example.interface.Name

           

          If several remote beans are found with those parameters, then a naming exception would occur.

          Consider a case where you deploy your application on a server and your client is coded to something like ejb:///beanName!interfacename since the client application assumed that's the only application on that server. One fine day the admin on the server deploys another application which also has the same name bean and interface. Your client application will start seeing naming exceptions and in order to fix that you'll have to change you application code and ultimately come back to the appname/modulename/distinctname/beanName!interface combination. So it really doesn't help trying to "optimize" this.