Help with EJBs and Servlets

[Simon Harvey]

Hi everyone,
I know that servlets are very different, but I cant understand why. I know this is probably very simple, but could someone quickly point out the difference for me.
Heres what I dont get. Lets say I want to get a connection to a database - I could do that in an EJB, or I could do it in the servlet. Which should I use and why?
Thanks everyone
Kind regards
Simon

[Lasse Koskela]

You could do it (getting a database connection) anywhere, including a servlet or an EJB.
Perhaps the most common way is the Data Access Object pattern.

[Simon Harvey]

Hi,
I know i can do it in either! I want to know why I should choose one or the other - whats the difference.
What do ejbs do that servlets don't and vice versa?
Many thanks
Simon

[Nagendra Prasad]

In general, I would second the thought that you ought to look into the respective patterns for this purpose.
Servlets are generally used for handling the view control i.e presentation logic. the actual database operations are more or less handled in the model tier, i.e the ejb/data access objects layer.
It is more a question of usage of better pattern and design philosophy as opposed to what is possible and what is not.

[Lasse Koskela]

Ahem. Sorry, I read your question a bit too quickly...

What do ejbs do that servlets don't and vice versa?

It's not about what EJBs/servlets have that the other doesn't. It's about responsibility-driven design.
If you put the database connection stuff inside a servlet and later on encounter a need to do the same thing in a different context, you'll have to either do some refactoring or copy-paste the data access code... It's generally easier to put the data access into a context-independent, plain old Java object, which can be used by both an EJB and a servlet.

[Philip Shanks]

I guess in this context the key difference is the way the application is intended to be accessed. I think servlets are designed for access by http clients, while EJB's are designed to be accessed by other Java applications (which may be servlets).
So, while your app can establish a database connection from either a servlet or an EJB, I think that the real question is, what do you intend to do with it once you've got it?

[Simon Harvey]

Hi everyone,
Well, thanks. Those were some great answers. I'm just going to drag this out a little bit more though
I know the difference between Entity and Session beans (I think), so I'm not so interested in that. But, heres what i know dont get:
What is the difference between Session beans and the session that Servlets and JSP pages can already provide via cookies and rewriting etc.
And also, with entity beans, say i made one tha represented a person. Would I then somehow load that representation into the session bean for storage.
I am kinda getting there but I still have a few grey areas. This what I think is going on:
A request comes in and the servlet sees if there is a session bean ready made for this client (how does it know though?)
If not, a session bean is made.
The session bean can be loaded with other beans so that it can remember details about the client.
But what happens if say the session bean is destroyed? How does the container know to make a new bean for each client when needed
THANKS to everyone who is helping me !
You're all very kind. I think this is a troublesome area where it really doesnt need to be. I'm trying to get as much information into this thread not just for my sake but so that other people can hear a newbie get brought up to speed!
Thanks again
Simon

[Lasse Koskela]

What is the difference between Session beans and the session that Servlets and JSP pages can already provide via cookies and rewriting etc.

The session object provided by a web container, an instance of javax.servlet.http.HttpSession, is per-client while the session object provided by a SessionBean (e.g. an instance of com.mystuff.Calculator) is many-per-client. By this I mean that the HttpSession is created for you by the web container but you must create your own SessionBeans as needed. The word "SessionBean" was a mishap on behalf of the EJB specification expert group -- it's misleading people new to EJBs to regard it as something like HttpSession. IMO, a better name would have been for example "ServiceBean"...

And also, with entity beans, say i made one tha represented a person. Would I then somehow load that representation into the session bean for storage.

Because a SessionBean is not intended to be used as "storage area", you don't really "load" anything into it. You create a SessionBean and get a reference to it, then you make method calls and the SessionBean maintains its internal state between those method calls. Period. Once you lose the reference, your SessionBean is up for GC.

A request comes in and the servlet sees if there is a session bean ready made for this client (how does it know though?)
If not, a session bean is made.
The session bean can be loaded with other beans so that it can remember details about the client.

Your servlet code needs to check for the existence of the SessionBean and create the SessionBean if necessary. For example, your servlet could store a javax.ejb.Handle in the HttpSession. In the beginning of a request that is supposed to do something with that SessionBean, the servlet would read the handle from the HttpSession, obtain the EJB reference through the handle (or create a new SessionBean if there was no handle), and invoke methods on the EJB.

But what happens if say the session bean is destroyed? How does the container know to make a new bean for each client when needed

The same answer again -- the container doesn't decide when to create/destroy the SessionBeans, you do.
You really should check out the EJB part of Sun's J2EE Tutorial.