application packaging

[wlwa4us]

To the expert in J2EE/JBoss,

I am writing a not so simple application that involves the use of Web and EJBs. In this application has some session beans as follow; SessionBeanA, SessionBeanB, and SessionBeanC, and entity beans as follow; EntityBeanA, EntityBeanB and EntityBeanC.
All of the entity beans are declared as local, but some of the session beans are declared as local and some are declared as remote. The session beans are referenced by servlets in the web component. The session beans reference the entity beans.
My questions are following;
I. Can I separate Entiy beans and Session beans to indivitual jar file.
1) Package all entity beans in a module (EntityBeanModule.jar) that contains its own ejb-jar.xml and jboss.xml and all session beans in a module (SessionBeanModule.jar) that contains its own ejb-jar.xml and jboss.xml.
2) The application directory structure looks the following:
Application.ear
META-INF/
META-INF/MANIFEST.MF
META-INF/application.xml
EntityBeanModule.jar
SessionBeanModule.jar
WebModule.war
lib/
lib/ejb-client.jar //contain remote interfaces for servlets
3) What is the benefit for doing this? It seems to create a lot more of works in the looking up of the entity beans. Would the invocation of the entity bean be local or remote?
II. Can I put all Entity beans and Session beans to one jar file.
1) Package all entity beans and session beans in a jar file (EJBsModule.jar) that contains its own ejb-jar.xml and jboss.xml.
2) The application directory structure looks the following:
Application.ear
META-INF/
META-INF/MANIFEST.MF
META-INF/application.xml
EJBsModule.jar
WebModule.war
lib/
lib/ejb-client.jar //contain remote interfaces for servlets
3) What is the benefit for doing this? It saves a lot of works compare to the option I. I can see there is a potential problem for maintenance when the number EJB beans increase to more then 100. What happen when the entity beans need to run on a separate application server?

Thank you in advance,
Kam

[jonlee]

I'm not an expert so you have to make your own judgement. The J2EE cycle was designed so that there could be a task split between development and production. The application engineer develops the application and creates all the necessary parts for the application. The deployment engineer works out the necessary packaging for production deployment. Both should work together to determine the best packaging architecture for installation and maintenance.

During development for large projects, you don't really want to tightly bundle too many things together as it slows the deployment and testing cycle. Particularly at the formative stage, if you follow an agile development approach, your application universe is going to be in a state of flux as you work out how your base units fit together in operation (as opposed to how they were supposed to work on the drawing board).

As the development progresses, some areas will become very stable and you can package them up. Others may continue to shift right up to production. We tend to leave things unbundled until the product is ready for release but we like the flexibility to go back and tweak things for performance.

The way you bundle things up is going to be a matter of taste. Some people bundle by the type of beans, as you have indicated. Some people like to bundle all the beans together. You might have CMP beans with different commit strategies and bundle them together based on that. We tend to bundle them into architectural units as it gives you leeway to upgrade certain areas and marks the boundaries as well as dependencies within the overall architecture. ECperf, for example, bundles the EJBs based on the area of operations - manufacturing, supply, customer and so on.

The other thing that you will need is a development environment that allows you to distinguish between building for development as opposed to bundling for production. Unfortunately, a lot of the IDEs seem to be designed by IDG - J2EE deployment for dummies. Every development iteration feels like a production deployment. It's fine for small projects but large ones can become annoying as all heck - even when deployment is as fast as JBoss.

Hope that helps.

[wlwa4us]

Thank you for replying to my message. My question is following. If we do seperate the enterprise beans into multilple jar files, then would a bean (BeanA) packaged in A_EBJsModule.jar references to an entiy bean or session bean that was packaged outside of A_EBJsModule.jar file, but still within the application.ear, consider to be a remote invocation? For a bean to be referenced by other beans outside of its jar file, it must declared a JNDI name in the jboss.xml. Would this be a lot of works to maintain when a project has 10 or 20 of xxxEJBsModules.jar


Thank you in advance,
Kam

[jonlee]

The local/remote interfaces refer to local to the VM or remote to the VM. So whether or not the EJBs are separated by packaging, as long as they can find a reference to the local home (bean factory) and they reside in the same VM, they can use the local interface. In fact, the embedded Tomcat/Jetty can also use the local interfaces of EJBs, allowing pass by reference. Yes, you will need a declared JNDI name but I think it is worth it for the flexibility. You can use xDoclet to ease deployment descriptor generation headaches.