EJB (Enterprise Java Beans)

What are java beans?

JavaBeans are reusable software components for Java. Practically, they are
classes written in the Java programming language conforming to a particular
convention. They are used to encapsulate many objects into a single object (the
bean), so that they can be passed around as a single bean object instead of as
multiple individual objects.
Advantages
A Bean obtains all of the benefits of Java's "write once, run anywhere"(WORA)
paradigm.
The properties, events, and methods of a Bean that are exposed to another
application can be controlled.
Auxiliary software can be provided to help configure a Bean.
The configuration settings of a Bean can be saved in a persistent storage and can
be restored at a later time.
A Bean may register to receive events from other objects and can generate
events that are sent to it.

Disadvantages
A class with a nullary constructor is subject to being instantiated in an invalid
state. If such a class is instantiated manually by a developer (rather than
automatically by some kind of framework), the developer might not realize that
the class has been improperly instantiated. The compiler can’t detect such a
problem, and even if it’s documented, there’s no guarantee that the developer
will see the documentation.

Q:What is Enterprise Java bean ?Explain any four benefits of ejb

Enterprise JavaBeans (EJB)
Enterprise JavaBeans (EJB) is an architecture for setting up program
components, written in the Java programming language, that run in the server
parts of a computer network that uses the client/server model. Enterprise
JavaBeans is built on the JavaBeans technology for distributing program
components (which are called Beans, using the coffee metaphor) to clients in a
network. Enterprise JavaBeans offers enterprises the advantage of being able
to control change at the server rather than having to update each individual
computer with a client whenever a new program component is changed or
added. EJB components have the advantage of being reusable in multiple
applications. To deploy an EJB Bean or component, it must be part of a specific
application, which is called a container.
Originated by Sun Microsystems, Enterprise JavaBeans is roughly equivalent to
Microsoft's Component Object Model/Distributed Component Object Model
architecture, but, like all Java-based architectures, programs can be deployed
across all major operating systems, not just

Windows. EJB's program components are generally known as servlets (little

server programs). The application or container that runs the servlets is
sometimes called an application server. A typical use of servlets is to replace
Web programs that use the common gateway interface (CGI) and a Practical
Extraction and Reporting Language script. Another general use is provide an
interface between Web users and a legacy application mainframe application
and its database. In Enterprise JavaBeans, there are two types of beans: session
beans and entity beans.

Explain:-Enterprise bean architecture

An enterprises bean are server side component that encapsulate with business
logic of an application. We can also say that enterprises beans are J2EE
component that that implement Enterprises Java Bean (EJB) Technology.

Basically enterprise beans are run in the EJB container.

In the definition of enterprise bean we use word business logic that fulfills the
purpose of the application.
Enterprises bean architecture contains the client and server. Figure shows the
relationship between client and server interaction and also shows that how both
 of them are benefitted. On the server side J2EE server provide the common
service provide to the enterprises architecture.
J2EE technology address the following enterprises component types;
1. Application client 2. Applet
3. Servlet and JSP 4. EJB
EJB Component : The model used to develop and deploy the reusable java
server component called EJB component.

EJB Server : It contains the container consist of necessary service required by

the EJB component.

EJB Client: Provide user interface logic on the client machine.

EJB container : Container gives the platform by which more than one EJB can
perform their execution
Benefits of EJB
The bean developer can concentrate on solving business problems. The EJB
container (not the bean developer) is used for system level services like
transaction management, security authorization etc.
According to the definition enterprise beans contains the business logic, the
client developers can focus on the presentation of the client. Client are thinner ,
hence they run on small devices.
Enterprises beans are portable hence the application assembler can build new
application from existing beans.

Q:State the difference between Java beans and EJB

Can be either visible or Are decidedly Non-Visible, remote objects
non-visible

Intended to be local to a single Remotely executable components deployed on the server

process on the client side
Uses the BeanInfo classes, Uses the Deployment Descriptor to describe itself.
Property Editors &
Customizers to describe itself
Can also be deployed as an Cannot be deployed as an ActiveX control since OCXs run on
ActiveX control the desktop

● Types of EJB
Enterprise Bean Type Purpose

Session Performs a task for a client

Entity Represents a business entity object that exists in persistent storage

Message-Driven Acts as a listener for the Java Message Service API, processing messages
asynchronously

What is a Session bean

A session bean is the enterprise bean that directly interacts with the user and
contains the business logic of the enterprise application.
A session bean represents a single client accessing the enterprise application
deployed on the server by invoking its method. An application may contain
multiple sessions depending upon the number of users accessing to the
application.

A session bean makes an interactive session only for a single client and shields
that client from complexities just by executing the business task on server side.
For example, whenever a client wants to perform any of these actions such as
making a reservation or validating a credit card, a session bean should be used.
The session bean decides what data is to be modified.
Typically, the session bean uses an entity bean to access or modify data. They
implement business logic, business rules, algorithms, and work flows.
Session beans are relatively short-lived components. The EJB container may
destroy a session bean if its client times out.
Session beans are divided into two parts.
1. Stateless Session Beans
2. Stateful Session Beans

Q:Explain the life cycle of stateless session bean

Stateless Session Beans:
A stateless session bean does not maintain a conversational state with the client.
When a client invokes the methods of a stateless bean, the instance of bean
variables may contain a state specific to that client only for the duration of a
method invocation.
Once the method is finished, the client-specific state should not be retained i.e.
the EJB container destroys a stateless session bean.
Stateless session beans can support multiple clients, they provide the better
scalability for applications that require large numbers of clients.

Life Cycle of a Stateless Session Bean:

Since the Stateless session bean does not passivates across method calls
therefore a stateless session bean includes only two stages. Whether it does not
exist or ready for method invocation. A stateless session bean starts its life cycle
when the client first obtains the reference of the session bean. For this, the
container performs the dependency injection before invoking the annotated
@PreConstructmethod if any exists. After invoking the annotated
@PreConstructmethod the bean will be ready to invoke its method by the
client

The container calls the annotated @PreDestroymethod while ending the life
cycle of the session bean. After this, the bean is ready for garbage collection.

Q:Explain the life cycle of statefulsessionbean

Stateful Session Beans:
These types of beans use the instance variables that allows the data persistent
across method invocation because the instance variables allow persistence of
data across method invocation.
The client sets the data to these variables which he wants to persist.
A stateful session bean retains its state across multiple method invocations made
by the same client. If the stateful session bean's state is changed during a
method invocation, then that state will be available to the same client on the
following invocation. The state of a client bean is retained for the duration of
the client-bean session. Once the client removes the bean or terminates, the
session ends and the state disappears.
Because the client interacts with its bean, this state is often called the
conversational state.

For example, consider a customer using a debit card at an ATM machine. The
ATM could perform various operations like checking an account balance,
transferring funds, or making a withdrawal. These operations could be
performed one by one, by the same customer. So the bean needs to keep track its
state for each of these operations to the same client. Thus Stateful session beans
has the extra overhead for the server to maintain the state than the stateless
session bean.
Life Cycle of a Stateful Session Bean:
A Stateful session bean starts its life cycle when the client first gets the
reference of a stateful session bean. Before invoking the method annotated
@PostConstructthe container performs any dependency injection after this the
bean is ready.
The container may deactivate a bean while in ready state (Generally the
container uses the least recently use algorithm to passivates a bean). In the
passivate mechanism the bean moves from memory to secondary memory.
The container invokes the annotated @PrePassivatemethod before passivating
the bean.
If a client invokes a business method on the passivated bean then the container
invokes the annotated @PostActivatemethod to let come the bean in the ready
state.
\

While ending the life cycle of the bean, the client calls the annotated @Remove
method after this the container calls the annotated @PreDestroymethod which
results in the bean to be ready for the garbage collection. When to use session
beans: Generally session beans are used in the following circumstances:
When there is only one client is accessing the beans instance at a given time.
When the bean is not persistent that means the bean is going to exist no longer.
The bean is implementing the web services.
Q:Differentiate between stateless and stateful session bean
Statefulsession beans are useful in the following circumstances:
What the bean wants to holds information about the client across method
invocation.
When the bean works as the mediator between the client and the other
component of the application.
When the bean have to manage the work flow of several other enterprise beans.

Stateless session beans are appropriate in the circumstances illustrated below:

If the bean does not contain the data for a specific client.
If there is only one method invocation among all the clients to perform the
generic task.

Singleton Session Beans

A Singleton Session Bean maintains the state of the bean for the
complete lifecycle of the application.
Singleton Session Beans are similar to Stateless Session Beans but only
one instance of the Singleton Session Bean is created in the whole
application and does not terminates until the application is shut down.
The single instance of the bean is shared between multiple clients and
can be concurrently accessed.

Singleton session beans maintain their state between client invocations but are not
required to maintain their state across server crashes or shutdowns.

Applications that use a singleton session bean may specify that the singleton should
be instantiated upon application startup, which allows the singleton to perform
initialization tasks for the application. The singleton may perform cleanup tasks on
application shutdown as well, because the singleton will operate throughout the
lifecycle of the application.

Q:What is Message Listener?Also explain onMessage() method.

Driven Beans
Message driven beans are the light weight components used for communication.
In message driven beans the messaging service is in asynchronous mode
because the user is not intended to get the instant result.
Message driven bean:
Message driven beans are the special type of components that can receive the
JMS as well as other type of messages.
Message driven bean can also be used to receive the messages other than JMS.
When a message is reached at the destination then the EJB container invokes the
message driven bean. A message driven bean is decoupled with the client that
sends the message. A client is not allowed to access the message driven bean
through a business interface. The client can interact with the message driven
bean only through the messaging system.
To interact with the message driven bean use the message provider specific API
such as JMS.

The Life Cycle of a Message-Driven Bean

The EJB container usually creates a pool of message-driven bean instances. For
each instance, the EJB container instantiates the bean and performs these tasks:
1. It calls the setMessageDrivenContext method to pass the context object to the
instance.
2. It calls the instance's ejbCreate method.

Like a stateless session bean, a message-driven bean is never passivated, and it

has only two states: nonexistent and ready to receive messages.
At theend of the life cycle, the container calls the ejbRemove method. The
bean's instance is then ready for garbage collection.

Java Message Services (JMS):

JMS API is an enterprise tool developed by Sun Microsystems used to develop
the enterprise applications.
JMS API supports to a framework that allows the development of portable and
message based applications.
JMS communicates in synchronous or in asynchronous mode by using
point-to-point and the publish-subscribe models respectively.
JMS has become vendor specific and many vendors such as IBM, Oracle,
Hewlett-Packard, BEA Systems and Macromedia are providing the JMS
implementation.

Packaging Beans
As we assembling the requirement for the Java 2 platform packaging
applications that use EJB 3.0 beans is similar concept.
In the modules components are packaged and further modules are packaged into
application enterprise archive (EAR) files. These components and modules are
describing the metadata provided into XML deployment descriptor.
The EJB 3.0 specification has provisions additional methods to describing
metadata and for packaging persistence units.
The EAR file is a package file is used to packing beans which has format
similar to a .zip or .tar file format.
Enterprise Edition (Java EE) module files, which can include the following:
oJAR files for EJB modules.
oWeb application archive (WAR) files for Web modules.
oResource application archive (RAR) files and other types of modules.
Sr. No Message Driven Session Bean
Bean
1. Client do not access Client access through
message driven bean interface.
through interface, it
has only a bean class
2. They execute upon the At a given time, only
receipt of a single one client has access
client message. to the bean instance.
3 They are relatively The state of the bean
short live. is not persistence,
existing only for a
 short period (perhaps
a few hours)
4. Message Driven bean Session bean access
do not have interface the client access due
that define client to its interface.
access.
5. To receive message A session bean allows
asynchronously us to sent JMS
message driven beans message and to
are used. receive them
synchronously but not
asynchronously.

Entity Beans
An entity bean represents a business object (customer, order and product) in a
persistence storage mechanism. Entity beans are persistent, allowed shared
access, have primary keys and can participate in relationships with other entity
beans hence they differ from session beans.
● Entity Beans always have states.
● Can 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 storage.
● Passivation and Activation apply to both Session and Entity Beans
● Persistence in Entity Beans is of two types. They are:
● Container-managed persistence:
Here, the EJB container is responsible for saving the Bean's state. Hence
the implementation is independent of the data source.
● Bean-managed persistence:
Entity bean directly responsible for saving its own state. Implementation
less adaptable than the previous one.
Q:Write the difference between Entity bean and session bean
rs

Q:What are the various ways of passing parameters in EJB

DEFINING CLIENT ACCESS WITH INTERFACES

Message-driven beans do not have interfaces that define client access. A client
can access a session bean only through the methods defined in the bean’s
business interface. The business interface defines the client’s view of a bean. All
other aspects of the bean are hidden from the client. Well-designed interfaces
simplify the development and maintenance of Java EE applications. Not only
clean interfaces shield clients from any complexities in the EJB tier but also
allow the beans to change internally without affecting the clients. For example –
if you change a session bean from a stateless to stateful session bean , you wont
have to alter the client code. But if you were to change the method definitions in
the interfaces, then you might have to modify the client code as well. Therefore
, it is important that you design the interfaces carefully to isolate your clients
from possible changes in the beans. Session beans can have more than one
business interface. Session beans should, but are not required to, implement
their business interface or interfaces. When you design a Java EE Application,
one of the first decisions you make is the type of client access allowed by the
enterprise beans: remote, local, or web service.
REMOTE ACCESS
A remote client or remote access of an enterprise bean has the following traits
(characteristics)- It can run on a different machine and a different Java Virtual
Machine (JVM) than the enterprise bean it accesses. (it is not required to run on
a different JVM) It can be a web component, an application client, or another
enterprise bean. To a remote client, the location of the enterprise bean is
transparent. To create an enterprise bean that allows remote access, you must do
one of the following:- Decorate the business interface of the enterprise bean
with the @Remote annotation:

@Remote
Public interface InterfaceName{…….} Decorate the bean class with @Remote,
specifying the business interface or interfaces:
@Remote([Link]) Public class BeanName implements
InterfaceName{……..} The remote interface defines the business and lifecycle
methods that are specific to the bean. For example- the remote interface of a
bean named BankAccountBean might have business methods named deposit
and credit.

LOCAL ACCESS
A local client or local access has following characteristics:- It must run in the
same JVM as the enterprise bean it accesses. It can be a web component or
another enterprise bean. To the local client, the location of the enterprise bean
it accesses is not transparent. The local business interface defines the bean’s
business and lifecycle methods. If the bean’s business interface is not
decorated with @Local or @Remote , and the bean class does not specify the
interface using @Local or @Remote, the business interface is by default a local
interface. To build an enterprise bean that allows only local access, you may,
but are not required to do the following:- Annotate the business interface of
the enterprise bean as a @Local interface. For example: @Local public
Interface InterfaceName{……..} Specify the interface by decorating the bean
class with @Local and specify the interface name. for example:-
@Local([Link]) Public class BeanName implements
InterfaceName{……..}

Q:What are the factors considered for Remote access and Local access
DECIDING ON LOCAL OR REMOTE ACCESS
Whether to allow local or remote access depends on the following factors:-
TIGHT OR LOOSE COUPLING OF RELATED BEANS: - Tightly coupled
beans depend on one another. For example, if a session bean that processes sales
orders calls a session bean that emails a confirmation message to the customer,
these beans are tightly coupled. Tightly coupled beans are good candidates for
local access because they fit together as a logical unit. They typically call each
other often and would benefit from the increased performance that is possible
with local access.
TYPE OF CLIENT: - If the enterprise bean is accessed by application clients,
then it should allow remote access. In a production environment, these clients
almost always run on different machines than the application server. If an
enterprise bean’s clients are web components or other enterprise beans,then the
type of access depends on how you want to distribute your component.
COMPONENT DISTRIBUTION:- Java EE Applications are scalable because
their server-side components can be distributed across multiple machines. In a
distributed application, for example, the web components may run on a different
server than do the enterprise beans they access. In this distribution scenario, the
enterprise should allow remote access.
PERFORMANCE: - Due to factors such as network latency, remote calls may
be slower than local calls. On the other hand, if you distribute components
among different servers, you may improve the application’s overall
performance. Both of these statements are generalizations; actual performance
can vary in different operational environments. Nevertheless, you should keep
in mind how your application design might affect performance.
If you aren’t sure which type of access an enterprise bean should have choose
remote access. This decision gives you more flexibility. In the future you can
distribute your components to accommodate the growing demands on your
application.
Although it is uncommon, it is possible for an enterprise bean to allow both
remote and local access. If this is the case, either the business interface of the
bean must explicitly designated as business interface by being decorated with
the @Remote or @Local annotations, or the bean class must explicitly
designate the business interfaces by using the @Remote and @Local
annotations. The same business interface cannot be both a local and remote
business interface.

Deciding on Remote or Local access

It depends on the following factors;
Tight or Loose Coupling of related beans
Container- managed Relationships
Type of the client
Component Distribution
Performance