EJB design: What are the advantages of EJB compared to Servlets

  1. When we can do everything using Servlets, Why and when should,one go for EJB.
  2. I am new to j2ee but from what I have read and developed I believe that EJB's offer more advanced scalability features (object passivation/activation for beans, caching for entity (data) beans, etc). They also offer transaction & security features with out a need to program to any specific API (such as JTA). Data access can be easier using Entity Beans vs using jdbc.
    A question I would like answered is has any body out there compared the scalablilty of an application that uses stateful sesion beans versus a servlet that holds it's state in a regular java object stored in an httpSession. I would think that Session beans would scale better, but maybe they don't because of all the transaction/security overhead. Any comments from anyone?
  3. if you look at the discussion below for stateless vs helper class i found it useful

  4. EJB and sevlets cannot be compared. They are altogether for different purpose. infact both servlets and ejb can coexist.
    (object passivation/activation for beans, caching for entity (data) beans, etc)
  5. I have looked at that post but I still do not see any particular answer to this question. Hari you say that the two cannot be compared. Yet both can can access client specific state, both can store persistent state, and both can perform server specific application functionality. There are those out there that have complete distributed system architectures based solely on JSP/Servlet/jdbc architecture!
    So again if anybody out there can answer these questions it would I would really apreciate it.
    1)Are stateless sesion beans a better alternative to running logic that does not need to hold client specific state than servlet helper classes. If so , then in what scenario? I have mentioned that perhaps a class/bean that requires a great deal of initialization would be beter modeled as session bean because these can be shared by the server. Is this accurate, or am I missing something here.

    2)Will a stateful session bean be more scalable than a regular object stored in the session of a servlet. As I have mentioned previously I believe yes, but can someone confirm this? Or are the benefits of a stateful session bean tied to its automatic transaction and security capabilities.
  6. This is the same question as "What is the benefit of Microsoft Transaction Server (MTS) compared to ASP or regular COM?"

    I blieve the benefit of MTS over straight ASP and regular COM components is object pooling and built-in transaction control. It is the same with EJB. If you don't have a high traffic site and don't have to worry to much about data concurrency and distributed transactions (TX spanning multiple databses on mutiple platforms), EJB is an overkill and worse can add overhead and latency, just like using MTS.

    EJB can simplify data access, if you use CMP; otherwise it is more complex than servlets/JDBC if BMP is used.

    Other thoughts:
    1. Stateless EJB vs. Java Helper Class: the former allows object pooling;
    2. Stateful EJb vs. Java Class in servlet/JSP session: in the former business logic is closer to the data and you don't have to overburden the web server;
    3. Entity EJB vs. Stateful EJB + JDBC: The former takes care of the transaction (ACID properties) for you, whereas you need to do your own synchronization with the later.

    Bottomline: to EJB or not to EJB? Can't say for sure. Prototype both and stress test you application and decide one way or the other. Also taken into consideration the transaction and security control aspects.