Are Plain Old WebContainers still appropriate in Java EE 5? 📎
Some projects built even own infrastructure, just to avoid the usage of EJB 2.0. However the development and runtime environment changed very much. Java EE 5 with EJB 3.0 simplified drastically the development and especially deployment model. No huge deployment descriptors are needed (actually no XML at all) - to develop a session bean just a class and an interface are needed. Actually it is hard to simplify the EJB 3.0 (suggestions are really welcome).
The funny story is: Java EE 5 webapplications without EJB 3 Session Beans are more complicated. I copied the following example from the blueprints to show the additional code which is needed:
@PersistenceContext(name="foo",
unitName="myPuName")
public class MyServlet extends HttpServlet {
@Resource UserTransaction utx;
public void doGet(HttpServletRequest req,
HttpServletResponse resp) throws throws
ServletException, IOException {
EntityManager em = (EntityManager) ic.lookup("java:comp/env/foo");
//get data from request
String name = request.getParameter("item_name");
...
//create new Item entity
Item item = new Item();
//set values of Item entity
item.setName(name);
...
utx.begin();
em.persist(item); //persist and add new Item to database
utx.commit();
...
}
Of course no one would use the EntityManager directly in the Servlet, but rather in e.g. Struts Action or JSF managed bean. But also in that cases you have to care about the lookup, thread-safety and transaction management.An introduction of simple Session Bean could drastically simplify the situation. In that particular case the container would care about the managment of the EntityManager, concurrency as well as transactions.
The servlet code would like something like:
public class MyServlet extends HttpServlet {
@EJB ItemMgr mgr;
public void doGet(HttpServletRequest req,
HttpServletResponse resp) throws throws
ServletException, IOException {
...
mgr.addItem("name of item");
The bean code is simple as well:public class ItemMgrBean{
@PersistenceContext EntityManager em;
public void addItem(String name){
Item item = new Item();
item.setName(name);
em.persist(item);
}
The code not only simpler but also cleaner. The resources are managed and injected by the container. But with the introduction of a single Session Bean the manageability and monitoring can be significantly increased. With tools like Glassfish's call flow you can monitor the performance of the whole invocation stack. The coolest story - the XML-configuration is optional. In EJB 3.1 even the local interfaces will be optional. After this step there is no more room for simplifications :-).