Why EJB?

Discussions

General J2EE: Why EJB?

  1. Why EJB? (2 messages)

    Hi PPl,

    I've been looking through alot of J2EE material but I have a couple of questions:

    Why would anyone want to use EJBs?

    Ive read all the "blurb" that says only use EJBs when you need them etc (Gartner, etc..) But I can't figure out a REAL reason to use them. Aren't all the "services" that the EJB contianer provides available in any good Servlet container and a decent web application framework?

    For example:

    1. Transactions: can be done using JNDI lookups for the UserTransaction in the Servlet. Which can used across different/multiple transactional resources/managers (hope my terminology is correct :~]) Agreed, the Servlet contaner doesn't allow for declarative transactions so I guess thats one advantage of EJBs. But apart from that I see no other benefit when it cones to using transactions. Please give any other examples if there are any...?

    2. Security can be handled by the Servlet container in a "portable" way using JAAS and the deployment descriptor. So why use EJB authentication?

    3. Scalability: People on this forum and others argue that EJB apps are implicitly (by their nature) more scaleable than Servlet and JSP (only) applications. Why is this the case? I know that EJBs are pooled, etc but if the EJBs are accessed via servlets, (as is the case in most situations), and the sevlet container is "not" considered to be scaleabe isn't this always going to be a bottleneck? So What difference would it make?

    4. Asynchronous messaging: On server startup a Servlet can be configured to be run its init() method via the deployment descriptor. In this method it can set up any helper classes (That implement the MessageListener interface) and subscribe to any Queues/Topics. So a servlet CAN act as an asynchronous message listener. Why is it better (or is it better) to use MDBs instead? What advantages do MDBs provide over this Servlet approach?

    5. Preserving state: The HttpSession can be used to preserve state. Why would anyone want to use a SSB instead?

    6. CMP: Admittedly the servlet container doesn't provide CMP. but is CMP actually viable for large scale systems? (I don't know thats why Im asking... :-]). And with all the complaints I've heared about Entity beans (heavy weight on the server etc) why would anyone want to go down that route? We could just use JDO instead (it not mature etc... but it works! :~]). Also for batch data access... a DAO, some sort of factory, DTO collection and JDBC could be used!

    7. Cacheing: a relatively difficult problem anyway... i.e. data consistency between multiple nodes/JVMs etc .And until the JSR that "specifies" multiple node caching is finished (if it ever is...!) I dont know if Entity bean cacheing solves this problem? Does it?

    I agree that using EJBs gives you the advantages of remoting (although this is now discouraged and LocalInterfaces are prefered for performance reasons), ability so serve multiple kinds of clients (fat and web), declarative transactions. BUT if any of these things are not required ... WHY USE EJBs? Are there any other compelling reasons to use them?

    Thanks in advance for your replies... :~]

    Smythe

    Threaded Messages (2)

  2. Why EJB?[ Go to top ]

    So look here:
    http://www.theserverside.com/discussion/thread.jsp?thread_id=13664

    Regards, Scar.
  3. Why EJB?[ Go to top ]

    1. Transactions: ...


    you don't need more arguments than you cited

    > 3. Scalability: People on this forum and others argue that EJB apps are implicitly (by their nature) more scaleable than Servlet and JSP (only) applications. Why is this the case?

    it's not the case, obviously. Servlets are as scalabale as Statless Session EJBs or MDBs. The other beans are useless.

    > 4. Asynchronous messaging: On server startup a Servlet can be configured to be run its init() method via the deployment descriptor. In this method it can set up any helper classes (That implement the MessageListener interface) and subscribe to any Queues/Topics. So a servlet CAN act as an asynchronous message listener. Why is it better (or is it better) to use MDBs instead? What advantages do MDBs provide over this Servlet approach?

    MDBs are the best beans in J2EE. They are very scalabale, and easy to deploy. use them. with servlets as you describe, you have to manage the pool of listeners, write your own configuration code and so on.

    > 5. Preserving state: The HttpSession can be used to preserve state. Why would anyone want to use a SSB instead?

    don't use SSB, unless you boss insists

    >6. CMP: Admittedly the servlet container doesn't provide CMP. but is CMP actually viable for large scale systems? (I don't know thats why Im asking... :-]). And with all the complaints I've heared about Entity beans (heavy weight on the server etc) why would anyone want to go down that route? We could just use JDO instead (it not mature etc... but it works! :~]). Also for batch data access... a DAO, some sort of factory, DTO collection and JDBC could be used!

    JDO is NOT ready for a prime time. e.g. it doesn't support Oracle sequences. it has the same problems with data cashed in instances etc. generally, JDO is as bad as CMP. the claim of CMP/JDO is that your life becomes easier because you don't have to deal with JDBC/SQL. wrong assumption. why? there's no way to isolate yourself from SQL. your legacy data is there. you should know SQL. period. instead, you are forced to learn several mappings, ODMG, CMP, JDO, OQL, JDOQL, EJBQL.... enldless list of mapping buzz words. It's easier to learn SQL, and all tx stuff with RDBMS is well known. anyway you MUST know how RDBMS works, what's SQL and so on.

    > 7. Cacheing: a relatively difficult problem anyway... i.e. data consistency between multiple nodes/JVMs etc .And until the JSR that "specifies" multiple node caching is finished (if it ever is...!) I dont know if Entity bean cacheing solves this problem? Does it?

    It doesn't.

    > I agree that using EJBs gives you the advantages of remoting (although this is now discouraged and LocalInterfaces are prefered for performance reasons), ability so serve multiple kinds of clients (fat and web), declarative transactions. BUT if any of these things are not required ... WHY USE EJBs? Are there any other compelling reasons to use them?


    reasons:
    it's a standard
    it's a componentized development, which is good.
    it can be scalabale if you don't follow so called 'patterns' blindly, e.g. stateless EJBs + JDBC is a very good combination.
    it's a good skill, easier to find a job with than with VB