Hi,
I have been doing projects using Model-View-Controller approach wtih Servlets, Java Beans, and Jsps. Now how does Enterprise Java Beans fit into this scenario. I mean that for a web-based project involving databases, what kind of design to adopt if you are eager to use EJBs?
Why should I use Entity Beans if i can accomplish the task with JDBC?
If the state is maintained by httpsession, why use Stateful Session Bean?
And why dont use a simple class file (we can make it static) instead of a Stateless Session Bean?

Thanks in advance

Nauman

First of all EJB is not a solution to all.
It works very well in many case but it also is a over kill in many.
It depends upon what ur project is about and what u want to achieve.
Now for a web based project as u mentioned.....
1. Who developed the transaction framework(if any).
2. Who developed the security framework(if any).
3. Do you need an application based on distributed component architecture....
4. As regards the SFSB...
  think of a scenario where the client(not necessarily a GUI) is also another application..where will the state be maintained..if it has to be(can be done in DB but i would not do that).
  Even if the client is Web based(as is urs) and what if the session to be maintained is huge..The problems that arise from session replication in an clustered environment..

As I said earlier .. EJB is evil but a necessary evil in many cases... :-)
If you are happy with current application in all respects
DO NOT CHANGE IT....

3. Do you need an application based on distributed component architecture....

--- I think this is the most important question, and I am gonna ask a more provocative question - in what case would the answer to the original question be "Yes".

My take is, the idea of "distributed component" is so far a failure. The proof? There are tens of thousands ISV selling windows controls when OLE came out. You don't see that happens with EJBs. No matter how popular EJB are these days. They are popular for wrong reasons - at least most people don't use them the way it was designed for (i.e. distributed component). If I want remotability, I will do messaging. If I want to persistence service , plenty of the ORM tools are available.
I will bet, not my life saving but maybe 20 bucks :-), EJB will be a fad eventually. Sommon sense java class using JDO or other OR mapping will prevail. As to the situation of communicating remote system, Web service will take care of that.

Thomas

Sorry, can't agree that location transparency is the most important question. I agree with you that most systems do not employ distributed objects. That's why EJB now has a 'local' interface. Even the EJB standards community has realised that most systems run within one JVM.

For me the most important reasons to select EJB are the first 2 in Neeraj's reply i.e. transparency. Do I really want to write a transaction, security or lifecycle (resource management) framework? If I need any of the above (OK lifecycle I might live with), I'll seriously consider EJB. If I don't, then I'll just design for JSP/Servlet/Javabeans/JDBC.

The important this to realise is that there are horses for courses. EJB is NOT a one size fits all solution, nor is it being promoted as such; unlike Web Services.

One day all e-commerce will be handled by Web Services - Yeah Right.

With respect to Neeraj's reply,
"Even if the client is Web based(as is urs) and what if the session to be maintained is huge..The problems that arise from session replication in an clustered environment.. "

As we are currently consideirng clustering, can you elaborate the issues due to session replication etc.. in clustered environment.

Thanks,

Sushil