Hi Amol,
Let me put the concept in layman terms.
Let us take example of software industry. There are Programmers and analysts and domain experts.
Programmers - Good with programming languages.
Analyst / Domain Experts - Good in domain knowledge and aware about programming concepts.
Stateless Session beans -
These beans are more of like Programmers. Programmers code for some specific project. Once the project is done, they can work on any other project. The domain the project is based on is not important for Programmers. The programmers mostly deal with programming related problems. (That is why we have bench time) If programmer is not allotted to a project, he/she will be on bench. The project that is looking for more programmers will hire one from the bench.
Notice here that the domain related understanding is not important. Secondly programmer is ready to work on any project that involves programming.
MAPPING THIS CONCEPT TO STATELESS SESSION BEAN
1. Stateless session bean are not bound to one client (Project does not matter if it requires programming services.)
2. Stateless session bean does not store the state. (No need to remember domain related details from past projects. New project with new domain is still ok)
3. Created by app server and are kept in pool. (Programmers are on bench. Who ever needs one will pick from the bench)
4. All stateless session beans created by same Home will always return true to isIdentical
test (Does not matter who the programmer is, for all PMs, programmer is just a resource in msp

)
Stateful Session Beans -
The Analyst and Domain experts are important and core people in any project. These people are involved for short durations, but the knowledge shared by these people is very crucial for project.
These guys are not always involved in project, but they are mostly allotted to project. These guys will not be pushed on bench, as they are not required for 1 to 2 month. They will only stop actively getting involved in day-to-day activities. But if there is a requirement or design level problem, then the project team calls for domain expert�s help.
So to put is in a simple way, these guys (domain experts no hard feeling here ok

) are mostly sleeping, and when there is a problem, PM goes to them and wakes them up.
MAPPING THIS CONCEPT TO STATEFUL SESSION BEAN
1. Are bound to one client (Domain expert work on one project)
2. Store state for client (Has domain knowledge that is required by project)
3. No pooling but it is simulated through passivation (sleeping) and activation (waking up). (When no work then domain expert goes back to his/her cubicle and takes a nap or read Dilbert. If there is a requirement to provide domain related services then PM goes and asks him/her to wakeup)
4. Statefull session beans might return true or false to isIdentical test.
I guess this shall explain most of pooling and passivation/activation concepts.
Guys correct me if I am wrong