wood burning stoves 2.0*
The moose likes EJB and other Java EE Technologies and the fly likes Basic Design Ques - Which EJB Type to use? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Basic Design Ques - Which EJB Type to use?" Watch "Basic Design Ques - Which EJB Type to use?" New topic
Author

Basic Design Ques - Which EJB Type to use?

Jimmy Ho
Ranch Hand

Joined: Jul 31, 2007
Posts: 61
I've been assigned to write an EJB for work. It's serving as a relay between an WebSphereMQ queue and a database. Basically, a message comes in through the queue via JMS, the EJB would do some minor business logic, and then query/update the database via JDBC, and then (for queries) send back a response through MQ.

The prior programmers before me used EJB, but I'm not even sure if I should. This isn't mission critical, must-be-100%-fault-tolerant sort of interaction like the prior coding efforts.

Question 1: Should I use EJBs, or just a plain old Java object?

Question 2: Assuming I had to use an EJB (say, because my boss told me so) what type of EJB? Message-driven EJB? Message driven layered over an entity bean? Just an entity bean by itself? Do message driven beans even exist for EJB 2.0?

This bean would be running on a WebSphere Application Server 5.1 cluster, which supports J2EE 1.3 (i.e. EJB 2.0).

Thanks,
Jimmy
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638


Question 1: Should I use EJBs, or just a plain old Java object?

In this case you definetly need EJBs for a simple reason that this process should be transactional i.e. if for any reason you were not able to write to the DB then you should not acknowledge the message from the queue. Also, EJBs are required for scalability(remote access). So, i think you should definetly use EJBs here. Needless to say that you can do all this without EJBs but you will be re-inventing the wheel in that case.


Question 2: Assuming I had to use an EJB (say, because my boss told me so) what type of EJB? Message-driven EJB? Message driven layered over an entity bean? Just an entity bean by itself? Do message driven beans even exist for EJB 2.0?

(Your boss says so because he probably has an experience making such systems)
You will have to use a message driven bean that in turn calls an entity bean.
Yeah message driven bean exists in EJB 2.0


apigee, a better way to API!
Jimmy Ho
Ranch Hand

Joined: Jul 31, 2007
Posts: 61
Forgive my lack of EJB expertise, but what would the difference be if I just used a message-driven bean with some JDBC code embedded, as opposed to wrapping a message-driven around an entity bean that then calls some JDBC code? What would I gain by doing it the latter way?
sammaiah kyatham
Ranch Hand

Joined: Aug 03, 2003
Posts: 104
Jimmy,
There will not be any problem if you want to replace entity beans with your own jdbc code but you'll lose the advantages of entity beans interms of transactions/reusability/pooling/container managed persistance.

If you don't like to use Entity beans use DAO objects for your database operations that would clearly separates your JDBC code.

I would suggest you to use Entity beans only.

Thanks,
Sam
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638

Hey Jimmy,

In addition to what sammaiah told, there is one big advantage of EJBs and i.e. scalability. Tomorrow, you may put your message driven beans in one app server and entity bean in another, or they may be different nodes in a cluster.
If you use JDBC code to do that, you will loose this flexibility and hence your MDB and JDBC code will be tightly coupled.
[ August 02, 2007: Message edited by: Nitesh Kant ]
Jimmy Ho
Ranch Hand

Joined: Jul 31, 2007
Posts: 61
Thanks everyone for the insights. I think I'll just do a message-driven bean that runs straight JDBC. I'll abstract the JDBC calls in a way so they can be easily transformed into an entity bean in the future.

At this point, the beans are just a service layer/interface to the database from an MQ queue, and just relay info back and forth. Thus, the idea of a message-driven bean calling an entity bean, possibly from different app servers, sounds inefficient.

Also, since the database updates involving inserting a few rows into one table, there's not a huge complexity (for now) that makes it worth the persistence and transaction handling that I get from the entity bean.

Thanks again for the advice. Even if I didn't follow it exactly, I at least know better why I went down the path I did
[ August 07, 2007: Message edited by: Jimmy Ho ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Basic Design Ques - Which EJB Type to use?
 
Similar Threads
My Study Notes
How to use these EJB's?
287 Pre-assessment test questions - Please answer
Weblogic 7.0 certification mock test question
is transaction mess the result?