Howdy -- one way to look at this is to rephrase the question to:
* When would you use an entity bean?
Then *everything* else is probably going to be a session bean (or a message-driven bean, but those are more obvious).
So, it's entity beans that are the real specific case.
One high-level answer to "when should you use an entity bean?" is: - when you want an object view of an entity that lives in an underlying persistent store
However, that opens up a huge set of issues in the real world. But since you're writing in the EJB Cert forum, following the answer to the question I just gave you will help.
At Sun, we would often tell people--think of a Session bean unless you ABSOLUTELY know that you need an entity bean. You will not be able to come up with a defined list of "reasons to use session beans" because they can represent almost any type of service you can think of. Although there's a key word in there--"service".
Another way to look at the difference is that "entity beans" are often more like "nouns" (things represented often by rows in a DB), while "session beans" are more like "verbs" -- actions/services. Session beans often DO things, while entity beans often ARE things.
Does that help?
Nathaniel has a good suggestion about the J2EE tutorial...
I know the difference between session bean and entity bean. I meant, given a scenario where you can use both session and entity beans why do we prefer session bean over entity bean. somewhere i read for better performance, we use session bean over entity, but i would like to know more detailed explanation. Thanks
Oh man... this is a difficult one because there are SO many factors and opinions, so I'll try to give one based solely on the architectural principles of EJB...
There is a fundamental difference between session and entity beans, so there are tradeoffs for each. Assuming that you have decided to represent an entity from an underlying persistent store, the pros and cons (at a very high level) look something like this:
1) CMP entity beans give you automatic synchronization with the underlying persistent store. They keep the data in the object current and they keep the underlying store current with changes that have been made via the bean. This takes a lot more work to accomplish in a session bean! Plus, with CMP you get things like automatic referential integrity (via CMR) and including automatic cascading deletes... ALL of this you'd have to do "by hand" with a session bean.
2) But all this synchronization can cause a LOT of performance hits that are often unnecessary, with all the constant loading of the bean and updating the database anytime the Container thinks something happened that *might* matter, so... a session bean can be a lot more efficient.
3) But... a lot of this is dependent on how you design things. You can do things to make your entity beans perform *much* better by controlling things like transaction scope, granularity, using transfer objects, session facade, etc. to reduce the number of times the Container *thinks* it needs to update the database or refresh the bean. Plus, a lot of Containers today have optimizations for things like read-only CMP fields, lazy loading, etc.
There is a wide range of things a Container (and designer) can do to make CMP a lot more efficient. An entity bean design without any precautions for performance, and with a *stupid* Container, can be horrible. But a well-designed entity bean within a *smart* Container is often an excellent and safe system... and with a lot less coding and potential errors than if you tried to do it yourself using session beans.
Entity beans have a place, although the over-enthusiasm (and inappropriateness) with which they have been used over the last few years has led to a backlash. But under the right circumstances, entity beans can still be the best choice for a 2.0 Container.