Technologies the constitutes J2EE

tukwilagleefulInternet and Web Development

Oct 31, 2013 (4 years and 7 months ago)


Learning J2EE

Introduction on Java based Enterprises Systems (Building Legacy/Enterprises

Logical layers of software


Presentation manager


Presentation logic


Application logic


Business logic


Database logic and


Database manager

An autonomous

isolated due to its importance and intensive operation known
as tire.

1 tire

All 6 layers in single software

2 tire

6 Layers separated as client and server (
divided into autonomous processes)

Below are the models that are available

tion manager” or “Presentation manager and Presentation logic” or
“Presentation manager, Presentation logic and application logic” as client and
the other layers act as a server.

3 tire

Here we have one additional process identified that can be segregat
ed to
improve the system. Its know as
middleware and consists of “presentation logic,
application logic and business logic” or business logic alone.

Technologies the constitutes J2EE

Component (Servlets, JSP, EJB)

Service (JDBC, JMS, JTA, JavaMail, JAF,


Integration (JAXP, JCA, IDL)

Communication (RMI, IIOP)

15 elements constitute J2EE (Servlets, JSP, EJB, JDBC, JMS, JTA, JavaMail, JAF,

The J2EE architecture (Different Containers)

application client


for hosting standard Java client

applet container

for hosting Java applets.

web container

for hosting Servlets and JSP pages.

EJB container

for hosting Enterprise JavaBeans.

Normally 4 tire for J2EE Architecture.

nt tire

Web tire

Business logic tire

Enterprise information system tire


A container is a runtime environment for application components

Container contains one or more application components.

The container itself is divided into four parts:

ntainer contract

Container services API

Declarative services

Other container services

J2EE (EJB) Application Development

Enterprise bean provider.

The role that develops EJB components.

The application assembler.

The role that combines EJB components

with other softeware (e.g. web
components) in order to make a complete application.


The role that takes the application and install it on an application server,
resolving any references to existing resources in the target environment.

tion server /EJB container vendor.

The role that provides the application server on which the application is

System administrator

The role that manages the application after it has been deployed in a target

Servlets are network e
nabled by default, but EJB are not. The EJB Containers will
serve EJB over network. All EJB’s will have home interface, remote interface and
bean class.

Servlets by themselves are http enabled.

EJB (Enterprise Java Beans)

Entity Beans

Session Beans

Driven Bean (JMS)

Entity Beans

Entity Beans always have states. Each Entity Bean may however be shared by
multiple EJB Clients. Their states can be persisted and stored across multiple
invocations. Hence they can survive System Shutdowns.

EJB servers
have a right to manage their working set. Passivation is the process by
which the state of a Bean is saved to persistent storage and then is swapped out.
Activation is the process by which the state of a Bean is restored by swapping it in
from persistent s
torage. Passivation and Activation apply to both Session and Entity

Persistence in Entity Beans is of two types. They are:

managed persistence:

managed persistence:

managed persistence
: Here, the EJB container is respons
ible for saving
the state of the Entity Bean. Since it is container
managed, the implementation is
independent of the data source. However, all container
managed fields need to be
specified in the Deployment Descriptor for the persistence to be automatical
handled by the container.

managed persistence
: Here, the Entity Bean is directly responsible for
saving its own state and the container does not need to generate any database calls.
Consequently, this implementation is less adaptable than the previ
ous one as the
persistence needs to be hard
coded into the Bean.

Every Entity Bean has the following characteristics:

Entity beans can share access from multiple users.

They can participate in transactions.

Entity beans represent data in a domain model.

They are persistent. They live as long as the data lives in the domain model.

Entity beans can survive EJB server crashes. Any EJB server crash is always
transparent to the client.

Entity beans have a persistent object reference. The object reference
ncapsulates the Persistent key for this Bean.

Session Beans

There are two types of Session Beans. They are

Stateless Session Beans and

Stateful Session Beans

Stateless Session Beans:

These types of EJBs have no internal state. Since they do not have
any states, they
need not be passivated. Because of the fact that they are stateless, they can be
pooled in to service multiple clients (remember MTS components?)

Stateful Session Beans:

These types of EJBs possess internal states. Hence they need to hand
le Activation
and Passivation. However, there can be only one Stateful Session Bean per EJB
Client. Since they can be persisted, they are also called Persistent Session Beans.
These types of EJBs can be saved and restored across client sessions. To save, a

to the bean's getHandle() method returns a handle object. To restore, call the handle
object's getEJBObject() method.

ACID Properties

Atomicity Consistency Isolation Durability

All transactions subscribe to the following "ACID" properties:


Write once run anywhere/anytime

What Is a Message
Driven Bean?

A message
driven bean is an enterprise bean that allows J2EE applications to process
messages asynchronously (Not occurring or existing at the same time or having the
same period or phase)
. It acts as a JMS message listener, which is similar to an
event listener except that it receives messages instead of events. The messages may
be sent by any J2EE component
an application client, another enterprise bean, or a
Web component
or by a JMS a
pplication or system that does not use J2EE

driven beans currently process only JMS messages, but in the future they
may be used to process other kinds of messages.

What Makes Message
Driven Beans Different from Session and Entity

The most visible difference between message
driven beans and session and entity
beans is that clients do not access message
driven beans through interfaces.
Interfaces are described in the section Defining Client Access with Interfaces. Unlike
a sess
ion or entity bean, a message
driven bean has only a bean class.

In several respects, a message
driven bean resembles a stateless session bean.

* A message
driven bean's instances retain no data or conversational state for a
specific client.

* Al
l instances of a message
driven bean are equivalent, allowing the EJB
container to assign a message to any message
driven bean instance. The container
can pool these instances to allow streams of messages to be processed concurrently.

* A single messag
driven bean can process messages from multiple clients.

The instance variables of the message
driven bean instance can contain some state
across the handling of client messages
for example, a JMS API connection, an open
database connection, or an objec
t reference to an enterprise bean object.

When a message arrives, the container calls the message
driven bean's onMessage
method to process the message. The onMessage method normally casts the message
to one of the five JMS message types and handles it in

accordance with the
application's business logic. The onMessage method may call helper methods, or it
may invoke a session or entity bean to process the information in the message or to
store it in a database.

A message may be delivered to a message
en bean within a transaction context,
so that all operations within the onMessage method are part of a single transaction.
If message processing is rolled back, the message will be redelivered.

When to Use Message
Driven Beans

Session beans and entity be
ans allow you to send JMS messages and to receive
them synchronously, but not asynchronously. To avoid tying up server resources,
you may prefer not to use blocking synchronous receives in a server
component. To receive messages asynchronously, use a
driven bean.

Best free J2EE Application Server: Jboss (
) or

EJB Example

Jboss Tutorial


Read J2EE Patterns at ml