Discussions

EJB programming & troubleshooting: Why EJB?

  1. Why EJB? (4 messages)

    Hi PPl,

    I've been looking through alot of EJB 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 (4)

  2. Why EJB?[ Go to top ]

    agree with you very much. for EAI, web service will be more suitable than EJB.
  3. Why EJB?[ Go to top ]

    Hi Smythe,
    I'm not an EJB guru but I'm using these technologies for a while (about 2 years), so I've got my opinion...

    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...?

    I think that you pointed out the real interest of the EJB management of of transactions, declarative one, while
    using transactions from servlets implies a lot of coding...
    You can adjust the speed/secure level of your application
    just with XMl files .... No more coding headaches....
    I think that transaction management is a hard subject so I prefer keep my code simple & delegates this task to core developpers with huge experience of such domain...
    That 's one of the KEY points while using EJB technology , concentrate on your business logic & leave hard technology tasks to specialists....
    Transactions like persistence are not simple subjects...
    EJB containers provide you services developped by experts, why not using them?
    I think that you can fetch the example of the 1 vs (n+1) requests to guess what optimizations containers could provide (1 single select) while the same request (require n+1 select) while hard coded (in a BMP using JDBC for example).

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

    Some containers use the JAAS framework (JBoss)..So I think this is the good way (smart, elegant)...
    I prefer using authentification at the HTTP level & leave my business logic simple & generic....

    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?

    I guess that some gurus could argue with load balancing & clustering, the same application server could be used by several HTTP servers (servlet engines).
    I never put clustering in pratice so I can't develop ...

    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?

    Oops, I never saw interest of the Statefull session beans , I find them heavy & useless..Because most of the J2EE apps use an HTTP facade & Http Sessions are very lighweight (just dependant from the amount of data put).
    I guess that statefull beans are a good way for preserving a certain beauty to your business beans but this aspect is too heavy in resources for me...

    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! :~]).
    nothing to append.. I think you put the whole actors, I can risk big projects with emergeant technologies.

    Also for batch data access... a DAO, some sort of factory, DTO collection and JDBC could be used!

    Don't you think that this kind of design is a good of way for the 10000th wheel ? :)

    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?

    pluggable components ? You can plug into your containers different CMP layers , such solution can be a nice one for boosting poor performances. I've made such tests with Jboss & the CMP layer (persistence manager I think)..
    portable code from one AS to another one ? I use middlegen for this job...(middlegen.sourceforge.net)

    Very good questions for I hope not so bad responses (or experiences)
    Sorry for my poor english written
    Jerome
  4. Why EJB?[ Go to top ]

    I use stateless session ejb's because it allows me to have a remote java object, in an easy way (the stubs are generated automatically by the container). That's the main reason to use ejb's.

    Doing so, i can load balance by distributing components over different containers at different machines, like you distribute databases over different machines.

    I can "publish" a java api for a central point, somewhere remote, for example a users database. I can lookup that api and access my database from any web application anywhere.

    I think a stateless session ejb is really a server, but one with a java api, in stead of a http api (get, post).

    Don't know much about statefull session ejb's and entity ejbs, i prefer programming stateless, and using a jdo.
  5. Why EJB?[ Go to top ]

    Smythe,

    Very good questions. I ask them too, usually to try and convince people to NOT use them. Here's when someone might want to use EJB's with good reason:

    1. they wanted to provide reusable server side components. For example, an integration team in a large company might want to front the legacy systems with some very carefully crafted EJB api's. They could then provide data to webservices, servlets, and other clients through that layer. I've never been in such a group, but I assume there are some out there.

    2. they wanted to combine several data sources into a seamless api. Most applications access a single DB, but I suppose there are times when clients access multiple RDBMS, some legacy green screen apps, maybe an IBM RPG program, etc. That would be a great place to use EJB.

    3. they want to take advantage of CMP, i.e., java object to RDBM mapping. This one could be handled by other technologies like JDO and all the other things, and it assumes that the data model is fairly simple. Never happens in my experience. We always end up writing some SQL, and that's why I prefer DAO. Then if someone insists we

    Someday, I hope I can be in a group doing #1 or #2, but I haven't had the chance. In my current project we are using them as a way to get RDBM data. Just a bunch of session beans that bring back collections of java objects. The api is ad hoc, built as needed by view developers. Here are ways to use EJB that I don't support:

    - no role specialization, each developer creates EJBs as needed during development. This is not what Sun had in mind, I'm sure of that.

    - when the EJB layer isn't treated as a "product", built and deployed seperately from the web tier during development.

    - when there will never ever be any other client tier besides a web tier. If it's just a web tier JDBC will usually do the trick. EJBs written ad hoc to meet view concerns are usually to tied to a particular view to be used by fat clients anyway. Example: I've seen EJB session beans that return XML for use in style sheets.

    - when we just want to get "Message Driven Beans" on our resume. There are really some great advantages and features to EJB, but the situation should needs to be right.

    Taylor