What is the client of the EJB?
As you might recall, Session Beans are the only EJB components that are invoked directly by
clients. A client can be anything such as a web application component (Servlet, JSP, JSF and so on), a
command line application or a Swing GUI desktop application. A client can even be a .NET
application using Web Services access.
What is the session in EJB?
The theory behind Session Beans centers on the idea that each request by a client to complete a
distinct business process is completed in a session. So what is a session? If you have ever used UNIX
server then you may have used telnet to connect to the server from a PC-client. Telnet allows you to
establish a login session with the UNIX server for a finite amount of time. During this session you
may execute several commands in the server. Simply put a session is a connection between a client and
a server that lasts for a finite period of time.
A session may either be very short-lived like a HTTP request or span a long time like a login
session when you telnet or ftp into a UNIX server. Similar to a typical telnet session a bean may
maintain its state between calls, in which case it is stateful,, or it may be a one time call, in which case
it’s stateless.
A particular business process may involve more than one Session Bean method call. During these
method calls, the Session Bean may or may not maintain a conversational state. This terminology will
make more sense if you think of each Session Bean method call as a “conversation” or “exchange of
information” between the client and the bean. A bean that maintains conversational state
“remembers” the results of previous exchanges, and is a Stateful Session Bean. In Java terms, this
means that the bean will store data from a method call into instance variables and use the cached data
to process the next method call. Stateless Session Beans do not maintain any state. In general, Stateful
Session Beans tend to model multi-step workflows, while Stateless Session Beans tend to model
general-purpose, utility services used by the client.
The classic example of maintaining conversational state is the eCommerce website shopping cart.
When the client adds, removes, modifies or checks out items from the shopping cart, the shopping
cart is expected to store all of the items that were put into it while the client was shopping. As you
can imagine, except for the most complex business processes in an application, most Session Bean
interactions do not require a conversational state. Putting in a bid at ActionBazaar, leaving Buyer or
Seller feedback, viewing a particular item on bid are all examples of stateless business processes.