5 Replies Latest reply on Apr 30, 2003 8:42 AM by Jon Barnett

    Modularity and EJB

    morten andersen Newbie

      I'm developing an application, which I would like to use some components from another application (Which I'm also developing). I would like to keep the modular approach, where the two applications are connected only by the one calling the other.
      I considered doing that by making local references from one application to the other, but I don't know whether thats a good idea.
      I wan't to be able to update one of the applications without the need for a redeployment of the other, so if the two applications are located in seperate jars, directly deployed to jboss, it would probably be good.
      This approach gives me problems with the local-references linking (I'm currently using JBoss 3.0.4).
      Is this "two seperate jars" approach the right way of implementing the modularity?
      If yes: Where can I find an example or some other help in how to do that?
      If no: How should it be done?

      Regards

      Morten Andersen

        • 1. Re: Modularity and EJB
          Jon Barnett Master

          You've pretty much got the right approach. Not only do you want modularity, but you want a single point for accessing common data. It's re-use and reduced maintenance.

          You can package them in separate jars or in the same jar - in a sense, your deployment and maintenance is a separate issue from your architecture.

          For ejb-jar.xml you do the following to refer to external resources:
          <?xml version="1.0"?>
          <!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/j2ee/dtds/ejb-jar_2_0.dtd">
          <ejb-jar>
          Items
          <enterprise-beans>

          <display-name>Items</display-name>
          Items
          <ejb-name>Items</ejb-name>
          com.amity.items.ItemsHome
          com.amity.items.Items
          <ejb-class>com.amity.items.ItemsBean</ejb-class>
          <session-type>Stateless</session-type>
          <transaction-type>Bean</transaction-type>
          <ejb-ref>
          <ejb-ref-name>EventLogger</ejb-ref-name>
          <ejb-ref-type>Session</ejb-ref-type>
          EventLoggerHome
          EventLogger
          </ejb-ref>
          <resource-ref>
          AmityPool
          <res-ref-name>AmityPool</res-ref-name>
          <jndi-name>java:/AmityPool</jndi-name>
          <res-type>javax.sql.DataSource</res-type>
          <res-auth>Application</res-auth>
          </resource-ref>
          <resource-ref>
          TablePool
          <res-ref-name>TablePool</res-ref-name>
          <jndi-name>java:/TablePool</jndi-name>
          <res-type>com.amity.objectpool.ObjectPool</res-type>
          <res-auth>Application</res-auth>
          </resource-ref>

          </enterprise-beans>
          </ejb-jar>

          So I'm referencing a stateless session bean called eventlogger, a database pool called AmityPool, and a custom resource called TablePool.

          Now, JBoss needs a bit more to sort out referencing issues. So, you'll need to provide jboss.xml. This goes in the META-INF directory with ejb-jar.xml.

          <?xml version="1.0"?>


          <resource-managers>
          <resource-manager>
          <res-name>EventLogger</res-name>
          <res-jndi-name>EventLogger</res-jndi-name>
          </resource-manager>
          <resource-manager res-class="org.jboss.ejb.deployment.JDBCResource">
          <res-name>AmityPool</res-name>
          <res-jndi-name>AmityPool</res-jndi-name>
          </resource-manager>
          <resource-manager>
          <res-name>TablePool</res-name>
          <res-jndi-name>TablePool</res-jndi-name>
          </resource-manager>
          </resource-managers>
          <enterprise-beans>

          <ejb-name>Items</ejb-name>
          <jndi-name>Items</jndi-name>
          <configuration-name>Standard Stateless SessionBean</configuration-name>
          <ejb-ref>
          <ejb-ref-name>EventLogger</ejb-ref-name>
          <jndi-name>EventLogger</jndi-name>
          </ejb-ref>
          <resource-ref>
          <res-ref-name>AmityPool</res-ref-name>
          <resource-name>AmityPool</resource-name>
          </resource-ref>
          <resource-ref>
          <res-ref-name>TablePool</res-ref-name>
          <resource-name>TablePool</resource-name>
          </resource-ref>

          false
          </enterprise-beans>


          I've removed the container configurations section that we normally include in our deployment file. It shouldn't effect you, but you can put in the section based on the standardjboss.xml supplied with JBoss. Of course, the bean will need to connect to the resources as if it were a normal client so you'll need to have that code in place.

          Hope that gets you on your way.

          • 2. Re: Modularity and EJB
            morten Matras Newbie

            Does this approach also work with Local references?

            I would like a Sessionbean from one application to talk to an Entity bean from the other application locally.

            This way I can use the first application as my model plus the standard features, and then as I discover new areas this model can be used in, I simply deploy a new Jar with some session-beans that implements these features using the old model.

            I've read somewhere, that the jars must be in the same ear. Is that correct?
            Is there any changes in your deployment-code, that is needed to make this Local-approach work?

            • 3. Re: Modularity and EJB
              Jon Barnett Master

              I'm not sure what you mean by locally. If you mean that they are in the same container then yes this is what this is the purpose for these reference declarations. You create a blank initial context in the calling bean, do what you would normally do to connect to the bean so if bean A is calling bean B, bean A is really no different to a remote client.

              See this for more information:
              http://www.objectweb.org/jonas/doc/howto/jboss2_4-to-jonas2_4/html/x105.html

              My example works for beans in different jars. As the document points out, if they are in the same jar, you need to include an <ejb-link> tag in ejb-jar.xml. Note that the <ejb-link> tag is container dependent.

              This article covers some more about linked EJBs.

              http://www.ejbtut.com/LinkedEjbs.jsp

              Hope that clarifies things.

              • 4. Re: Modularity and EJB
                morten Matras Newbie

                With locally I mean by using Local Objects. I don't know how much the extra time is for a call to a bean by its remote interface compared with a call to its local object, but it gives me the advantage that I from my Session bean of my application 2, that calls the "model"-application can use the components of the "model"-application directly, without implementing anything in that "model"-application.
                In my model application I only implement the getXXX()/setXXX(..) methods in the LocalObject-interfaces in my CMP-based beans.

                • 5. Re: Modularity and EJB
                  Jon Barnett Master

                  OK. I see where you are going with this. In CMP 2.0 you can make a CMP Bean only accessible intracontainer. The local home and local interfaces cannot be accessed from outside the container.

                  See the following tutorial:
                  http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/J2eeTutorialTOC.html

                  You pretty much follow the same process for declaring the resource in your xml.

                  Try this for a fairly straightforward tutorial.

                  http://otn.oracle.com/tech/java/oc4j/htdocs/how-to-ejb-local-interfaces.html

                  Now, I haven't tried this yet but I vaguely remember seeing the coding for JBoss and it looked pretty much compliant with the tutorial. The jboss.xml will still need the JNDI binding much as for standard remote calls. I think the only time saving you will have is not having to work with a remote portable object.