Advertisment

Flavors of Enterprise Javabeans

author-image
CIOL Bureau
Updated On
New Update

S Gokul

Advertisment

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.

Advertisment

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:

Advertisment
  • 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.

Advertisment

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.

Advertisment

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.

Advertisment

Continued...

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 ?

Advertisment

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.

tech-news