Download EJB disadvantages

CASE STUDY ON EJB
Nilesh Prajapati (14IT1002)
[email protected]
Introduction
Enterprise Java Beans (EJB) is a
development architecture for building
highly scalable and robust enterprise level
applications to be deployed on J2EE
compliant Application Server such as
JBOSS, Web Logic etc.
EJB is an essential part of a J2EE platform.
J2EE platform have component based
architecture to provide multi-tiered,
distributed and highly transactional features
to enterprise level applications.
EJB provides an architecture to develop and
deploy component based enterprise
applications considering robustness, high
scalability and high performance. An EJB
application can be deployed on any of the
application server compliant with J2EE 1.3
standard specification.
EJB architecture is shown below:

mechanism, exception handling and
so on. Developer has to focus only
on business logic of the application.
EJB container manages life cycle of
EJB instances thus developer needs
not to worry about when to
create/delete EJB objects.
General Responsibilities
The EJB specification details how an
application server provides the following
responsibilities:










Transaction processing
Integration with the persistence
services offered by the Java
Persistence API (JPA)
Concurrency control
Event-driven programming using
Java Message Service and Java EE
Connector Architecture
Asynchronous method invocation
Job scheduling
Naming and directory services
(JNDI)
Inter-process Communication using
RMI-IIOP and Web services
Security (JCE and JAAS)
Deployment
of
software
components in an application server
Steps to develop EJB application
Benefits of EJB:


Simplified development of large
scale enterprise level application.
Application Server/ EJB container
provides most of the system level
services like transaction handling,
logging, load balancing, persistence
1. Start.
2. Write .java files for the BEAN,
HOME and REMOTE interfaces.
3. Write the Deployment descriptors.
4. Compile all the STEP 2 files into
.class files.
5. Using the Jar utility create an EJB
jar file containing STEP 2 & STEP
3 files.
6. Configure your EJB Server e.g. DB
connections thread pooling, etc.
Then copy the EJB Jar file.
7. Start your EJB container and
confirm that it has loaded the EJB
Jar file.
8. Connect to your EJB by writing a
test Client.java file. Compile it and
run it.
Types of Enterprise Beans
EJB are primarily of three types which are
briefly described below:
Session beans
Stateless session beans
Stateless Session Beans are business
objects that do not have state associated
with them. However, access to a single bean
instance is still limited to only one client at
a time, concurrent access to the bean is
prohibited. If concurrent access to a single
bean is attempted, the container simply
routes each request to a different instance.
This makes a stateless session bean
automatically thread-safe. Instances of
Stateless Session beans are typically
pooled. If a second client accesses a
specific bean right after a method call on it
made by a first client has finished, it might
get the same instance. The lack of overhead
to maintain a conversation with the calling
client makes them less resource-intensive
than stateful beans.
Example: Sending an e-mail to customer
support might be handled by a stateless
bean, since this is a one-off operation and
not part of a multi-step process.
Stateful session beans
Stateful Session Beans are business objects
having state: that is, they keep track of
which calling client they are dealing with
throughout a session and thus access to the
bean instance is strictly limited to only one
client at a time. If concurrent access to a
single bean is attempted anyway the
container serializes those requests, but via
the @AccessTimeout annotation the
container can instead throw an exception.
Stateful session beans' state may be
persisted (passivated) automatically by the
container to free up memory after the client
hasn't accessed the bean for some time.
Example: Checking out in a web store
might be handled by a stateful session bean
that would use its state to keep track of
where the customer is in the checkout
process, possibly holding locks on the items
the customer is purchasing (from a system
architecture's point of view, it would be less
ideal to have the client manage those locks).
Singleton session beans
Singleton Session Beans are business
objects having a global shared state within
a JVM. Concurrent access to the one and
only bean instance can be controlled by the
container
(Container-managed
concurrency, CMC) or by the bean itself
(Bean-managed concurrency, BMC).
Example: Loading a global daily price list
that will be the same for every user might
be done with a singleton session bean, since
this will prevent the application having to
do the same query to a database over and
over again.
Message driven beans
Message Driven Beans are business objects
whose execution is triggered by messages
instead of by method calls. The Message
Driven Bean is used among others to
provide a high level ease-of-use abstraction
for the lower level JMS (Java Message
Service) specification. It may subscribe to
JMS message queues or message topics,
which typically happens via the
activationConfig
attribute
of
the
@MessageDriven annotation. They were
added in EJB to allow event-driven
processing. Unlike session beans, an MDB
does
not
have
a
client
view
(Local/Remote/No-interface), i.e. clients
cannot look-up an MDB instance. An MDB
just listens for any incoming message on,
for example, a JMS queue or topic and
processes them automatically. Only JMS
support is required by the Java EE spec, but
Message Driven Beans can support other
messaging protocols.
Example: Sending a configuration update
to multiple nodes might be done by sending
a JMS message to a 'message topic' and
could be handled by a Message Driven
Bean listening to this topic (the message
paradigm is used here since the sender does
not need to know the number of consumers,
their location, or even their exact type).
select a best-of-breed solution.
EJB's universal nature offers
application developers well-defined
roles.
2. Integration with the J2EE
platform:
Since Sun introduced EJB in 1997,
a strong enterprise computing
environment has grown up around
it, including technologies such as
servlets, JMS (Java Message
Service), JSP (JavaServer Pages),
the JCA (Java Connector
Architecture), JDBC (Java
Database Connectivity), security,
and transaction management. Such
integration enhances EJB's
attractiveness as the J2EE platform
includes so much other
complementary technology.
Entity beans
It is a server-side Java EE component, that
represents persistent data maintained in a
database. An entity bean can manage its
own
persistence
(Bean
managed
persistence) or can delegate this function to
its EJB Container (Container managed
persistence). An entity bean is identified by
a primary key. If the container in which an
entity bean is hosted crashes, the entity
bean, its primary key, and any remote
references survive the crash.
EJB advantages
1. The underpinning EJB
specification:
The specification stipulates
everything for EJB, from the
various types, lifecycles, and
restrictions, right through to roles
and responsibilities. Many vendors'
application servers conform to the
specification, allowing you to
3. Almost transparent scalability:
Because you delegate so much to
the container, the vendor can scale
server-side resources to meet
fluctuations in demand.
EJB disadvantages
1. Large, complicated specification:
In defence of Sun, no widely
adopted distributed technology has
avoided this pitfall; take a look at
the CORBA specifications from
the OMG (Object Management
Group), or the architecture of
Microsoft's .Net platform.
2. Increased development time:
EJBs do take longer to develop,
and when things go wrong, they
can prove more difficult to debug,
particularly because the bug might
not be in your code but in the
application server/container itself.
Again, a difficult pitfall to avoid
since the container gives you so
much, but a disadvantage
nonetheless.
3. Added complexity compared to
straight Java classes:
At a superficial level, you require
three classes for every session
bean, four for an entity bean, and
you may additionally employ value
objects to reduce network
overhead, adding another class.
Conclusion
Thus, we have performed a case study on
what is EJB, its benefits, architecture and
types. We have also studied the steps to
develop a simple EJB application and have
known its advantages and disadvantages.