S Gokul
Why different types of EJBs?
Enterprise Javabeans are scalable, distributed server side Java components that
encapsulate business logic in a J2EE platform based enterprise environment.
Interestingly, for the developers and architects of J2EE applications, EJBs are
available in different flavors.
EJBs are supposed to be self contained components that are capable of
performing a set of well defined business tasks. So, initially, EJBs were
structured to embody all core business mechanisms involved with the task at hand
— they typically accepted the input data from various clients, applied the
mechanisms over the data — and generated the desired results.
But as the infrastructure and scope of EJBs grew, a need was felt to
standardize the logic that dealt with manipulating data to and from the
database. Typically, developers were constructing their own Data Objects or
Javabeans to deal with database access and wrote their own codes for
synchronization and transaction. To standardize these tasks, another set of EJBs
were introduced.
It will be interesting to note that the types of EJBs are growing even now,
with a new breed of EJBs to deal with asynchronous messaging set for launch with
the latest release of J2EE specification.
Various types of EJBs
With J2EE 1.2, three types of EJBs are currently in place. They are:
- Stateless Session Beans — meant for business processing without
maintaining the states of the client. - Stateful Session Beans — meant for business processing while maintaining
the states of the client. - Entity beans — for dealing with database transactions.
We will take a closer look at them, in the following paragraphs.
Stateless session beans
Stateless session beans are meant for performing predefined business tasks
without maintaining the state of the client. By drawing an analogy, we can
easily understand this concept.
Take the case of a simple shopping mall. The shopkeeper issues a bill for
what you purchase and collects the money. He doesn’t bother about whom you are
and what you are purchasing. He renders this service consistently for all
customers without any difference. Next time when you visit the shop, neither the
shopkeeper remembers you nor do you remember him.
Stateless bean is functionally very similar to this scenario. It does a set
of well defined, often related business tasks on behalf of clients and responds
with the result. Technically, we say that stateless beans do not remember the
‘state’ (i.e. attributes, in OOP sense) of the clients.
We can also claim that two different session bean instances are not different
from one another. This means, all stateless beans render similar types of
service and at any point of time, the client can fetch any one instance and
request to render the service. Thus, the scope of stateless bean in a service
life cycle is limited. It just renders the requested service and retires back to
the pool.
Stateless beans can be successfully developed to embody many business logic
rules in an enterprise. Since they are independent of client state, they are
much less resource-hungry than the stateful beans. J2EE architects encourage the
usage of stateless beans as far as possible. Even from the developers’ point
of view, constructing a stateless bean is relatively easy.
Stateful session beans
Stateful session beans also perform business tasks on behalf of clients, but
they also maintain the state of the client, while doing so. Let us continue the
same analogy further, to include the scope for stateful beans.
In the shopping mall, supposing that you are a frequent customer, the
shopkeeper may offer you some accounting facility so that you can pay for all
your purchases at the end of the month. In this case, the shopkeeper maintains a
record of your purchase every time you visit and make purchase. In other words,
he maintains your ‘state’ of purchase and bill settlement at any point of
time. This relationship between you and shopkeeper is unique and is not
comparable to his services to any others.
Similarly, stateful beans maintain the state of the clients, right from the
moment it breaths to life throughout its period of existence. By state, we
simply mean one or more attributes of the client that are very unique to it. A
stateful bean can serve only one client — at any point of time - because it is
tied to the client by means of attributes. Thus, every time a client request
comes in, a new stateful bean has to be instantiated in the environment.
Needless to say that in this process, stateful beans become much more resource
intensive.
This maintenance of client attributes by stateful beans is purely temporary.
Sooner or later, if the attributes are to be preserved, then they should be
recorded in the database before the bean dies. (For persistent maintenance of
attributes, a better choice is entity beans).
Why do we need such a temporary storage ?
Take the case of an online shopping cart. You want to remember the items a
user is adding to his cart. But you don’t want to touch the database until the
user confirms his order. So, in between order placing and order conformation,
the state of the client has to be maintained.
Entity beans
Entity beans represent an object view of records in a table, stored in a
persistent storage like the database. Each entity bean represents one row of
data — and the columns are represented as attributes of the bean. Whenever
these attributes are modified during the course of the application, the changes
are automatically updated in the database.
Thus, the data available in the entity bean is persistent with the database.
This persistence can either be achieved either manually (by coding within the
bean) or automatically (by instructing the EJB container appropriately). The
former is called Bean managed persistence and the latter, Container managed
persistence. The advantage of container managed bean is that there need not be a
single line within the bean to access the database and yet, the database is
automatically updated by the container.
The tables have primary keys — so do entity beans — by means of Primary
Key class. As in the case of database, a Primary Key class is very unique for a
given entity bean. This Primary Key class is usually bundled along with the bean
during deployment.
Entity beans can be shared by more than one client — just as a single
record in a database table can be accessed by more than one person.