1 Reply Latest reply on Jul 25, 2006 4:03 PM by kristoffer sjögren

    Problem reusing an EJB infrastructure layer

    kristoffer sjögren Newbie

      Example:

      A large organization uses ejb's to provide an infrastructure layer (messaging, persistence) to all of its products. Products which are realized as appliction ears. They might choose a buildning tool like Maven. Maven lets each project produce at most one artifact (good practice?), which could be an ejb, war, ear, jar etc. Artifacts are uploaded to a repository to be used by other projects.

      JBoss uses a server specific deployment descriptor (or annotation) element that maps the logical JNDI name as used by the module (EJB,WAR) to a global JNDI name. This descriptor is defined and packaged in the module, not in the application (EAR).

      Since the binding of global names is done in the ejb-jar module there is no way to deploy an ejb module twice in the application server.

      Reading from "Development Roles" http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Overview6.html :

      "For example, in the application component development phase, an enterprise bean software developer delivers EJB JAR files. In the application assembly role, another developer combines these EJB JAR files into a J2EE application and saves it in an EAR file. In the application deployment role, a system administrator at the customer site uses the EAR file to install the J2EE application into a J2EE server."


      The above statement cannot be true because there is no way for the "application assembly role" to _freely_ pick EJB JAR files from the "enterprise bean software developer". He will be getting global JNDI conflicts if an EJB JAR is assembled inside two EARs and deployed in the same server.

      So how can a infrastructure layer ever be realized if the "resource specifics" are bound to the module itself? Also, applications might have diffrent requirements on the infrastructure which are not relevant from the module itself.

      Why not make it possible to let the application worry about assign global resources to logical names instead?

      I think that the approach of not being required to define a global JNDI name for a SLSB is great because it allows reuse of these modules across applications.

      Cheers,
      -Kristoffer