Now that we’ve seen all the basic elements of implementing, deploying, and using an EJB, let’s move on and talk about the specifics of implementing session beans (we’ll get to entity beans and message-passing beans after that). A session bean serves as a functional extension of the client that uses it, running within an EJB server. A client acquires a reference to a session bean, and asks it to perform services by calling methods on the bean. These method calls might retrieve or update data in a remote database, interact with an external enterprise system of some kind, filter or otherwise process a set of data, or perform some other useful task.
A session bean doesn’t live beyond the lifetime of its server -- in other words, it is not persistent. If an EJB client has a reference to a session bean and the host EJB server restarts, that session bean reference is no longer valid. You can reacquire a session bean of the same type from the same server after the restart, but it’s not guaranteed to be in the same state as the bean you had before the server restart (unless, of course, you explicitly alter its state to exactly match the state of its ancestor). An EJB container also has the option of destroying a session bean after some timeout period if the bean is in an inactive state on the server (e.g., if there are no client references to the session bean for a period that exceeds the session timeout for the bean).
Session beans implement the