Download as pdf or txt
Download as pdf or txt
You are on page 1of 6

12/6/2019

EJB

1 2

Enterprise JavaBeans
• A specification from JavaSoft
• Enterprise JavaBeans defines a server component
model for the development and deployment of Java
applications based on a multi-tier, distributed object
architecture
• The Enterprise JavaBeans specification defines:
– A container model
– A definition of the services the container needs to
provide to an Enterprise JavaBean, and vice versa
– How a container should manage Enterprise
JavaBeans

3 4

Enterprise JavaBeans EJB Server


Architecture
Provides a Runtime Environment
The EJB architecture specifies the
responsibilities and interactions among
The EJB Server provides system services and
EJB entities manages resources
◆ EJB Servers ◆ EJB Containers – Process and thread management
◆ Enterprise Beans ◆ EJB Clients – System resources management
– Database connection pooling and caching
Enterprise
Bean
Enterprise
Bean
– Management API

EJB Container
Clients
EJB Server
EJB Server

5 6

1
12/6/2019

EJB Container Enterprise JavaBeans


Provides a Run-time Environment
for an Enterprise Bean A specialized Java class where the real business
logic lives
• Hosts the Enterprise JavaBeans
– May be developer-written or tool-generated
• Provides services to Enterprise JavaBeans
– Naming Distributed over a network
– Life cycle management Transactional
– Persistence (state management) Secure
– Transaction Management Server vendors provide tools that automatically
– Security generate distribution, transaction and security
Likely provided by server vendor behavior Enterprise Enterprise
Bean Bean

EJB Container
EJB Container
EJB Server
EJB Server

7 8

EJB Clients JavaBeans vs Enterprise JavaBeans

• Client access is controlled by the container in which • Enterprise JavaBeans is a framework for
the enterprise Bean is deployed building and deploying server-side Java
• Clients locates an Enterprise JavaBean through components
Java Naming and Directory Interface (JNDI) • JavaBeans is a framework for client-side Java
• RMI is the standard method for accessing a bean components
over a network
• Conceptually related because both are
components
• The specifications are different
Enterprise Enterprise
Bean Bean
• The specifications do not build on each other or
EJB Container rely on each other
Clients
EJB Server

9 10

Represents Process
Session Bean
Enterprise EJB Scenario • Implements javax.ejb.SessionBean interface
Existing
Enterprise • Session Bean models the business process
EJB Application
Middleware • It does not guarantee persistency.
Clients Web Server
Server
CICS Programs • Database handling is avoided by session bean
Browser EJB Container (a) Stateful Session Bean
Credit Card (b) Stateless Session Bean
Servlet Shopping
(c) Singleton Session Bean
Databases
Cart

Inventory
Application

SAP Modules
EJB Server

11 12

2
12/6/2019

Life cycle management methods Stateful Session Bean


• The state of an object consists of the values of its
1. ejbCreate() instance variables. In a stateful session bean, the
instance variables represent the state of a unique
2. setSessionContext() client/bean session. Because the client interacts (“talks”)
3. ejbActivate() with its bean, this state is often called
the conversational state.
4. ejbPassivate()
5. ejbRemove() • The state is retained for the duration of the client/bean
session. If the client removes the bean, the session ends
and the state disappears. This transient nature of the
state is not a problem, however, because when the
conversation between the client and the bean ends,
there is no need to retain the state.

13 14

Stateful Session Bean Life Cycle of Stateful Session Bean


• In stateful session bean ejbPassivate() free the
resources by serializing the state of bean in any external
file like .scr/.db/.xml, provided that any variable of its
state is not transient or any object like connection.
• When the bean resources are full inside the container
and the new client is not getting a new bean, then the
container selects any such bean which is idle from
enough time and saves its state into a file with extension
.scr/.db/.xml, called as passivate and gives the same
bean to the new client.
• Now after some time if the passivated bean is invoked
and want its bean back, then we read from the
.scr/.db/.xml file and again recreate the bean as it was in
previous state

15 16

Note:-Stateful session bean does not guarantee Stateless Session Bean


for the persistency of data as soon as the • A stateless session bean does not maintain a
bean is closed or if the container is crashed . conversational state with the client. When a client
invokes the methods of a stateless bean, the bean’s
instance variables may contain a state specific to that
Instance pooling is not possible in client but only for the duration of the invocation. When
Stateful Bean. the method is finished, the client-specific state should
not be retained.
• Because they can support multiple clients, stateless
session beans can offer better scalability for applications
that require large numbers of clients. Typically, an
application requires fewer stateless session beans than
stateful session beans to support the same number of
clients.

17 18

3
12/6/2019

Life Cycle of Stateless Session Bean Singleton Session Bean


• A singleton session bean is instantiated once per
application and exists for the lifecycle of the application.
Singleton session beans are designed for circumstances
in which a single enterprise bean instance is shared
across and concurrently accessed by clients.
• Singleton session beans offer similar functionality to
stateless session beans but differ from them in that there
is only one singleton session bean per application, as
opposed to a pool of stateless session beans, any of
which may respond to a client request. Like stateless
session beans, singleton session beans can implement
web service endpoints.
• Singleton session beans maintain their state between
Note:-A stateless session bean can implement a web service, client invocations but are not required to maintain their
but a stateful session bean cannot state across server crashes or shutdowns.

19 20

Represents Data
Entity Bean Life Cycle of Entity Bean
• Implements javax.ejb.EntityBean interface
• Accessed by multiple clients at a time i.e. sharable.
• Persistent and Serializable
• Entity beans follows O-R mapping, so that in all maximum
cases, entity bean synchronized with RDBMS and by this it
achieves persistency.
• Each instance of an entity bean is one row of data
• Each instance of an entity bean is uniquely identified by a
primary key
• The container loads and stores the entity beans in the D/B
• In entity bean we have finder() along with the create() method
in home interface.
• create() always create a new row in database.
• finder() finds from the existing rows

21 22

Life cycle management methods Entity Bean


• An Entity Bean expresses the entity, and as a prerequisite,
1. ejbCreate() must be stored (persisted) in the database. As a result, even
when the client exits, the state of the Entity Bean continues to
2. ejbPostCreate() exist in the database. The lifecycle of this Enterprise Bean is
3. ejbLoad() longer as compared to that of a Session Bean.
4. ejbStore() • The following two management models are defined in the EJB
specifications:
5. ejbHome()
1. Container Managed Persistency (CMP)
6. ejbFind() ▪ the container controls when the bean is read from or written to
7. ejbActivate() the database

8. ejbPassivate() 2. Bean Managed Persistency (BMP)


▪ the bean’s implementation performs all of the sql operations
9. ejbRemove() that loads, stores, and updates the bean’s data to or from the
10.setEntityContext() database.
▪ Bean is responsible for connection allocation to the database
11.unsetEntityContext()

23 24

4
12/6/2019

Container Managed Persistency (CMP) Bean Managed Persistency (BMP)

• The EJB container is responsible for • The entity bean is responsible for its persistent behavior
persistence • EJB developer must implement database access
• The container provides tools that generate code – ejbCreate(…), ejbLoad(), ejbStore(), ejbRemove()
in the EJB class that maps methods in the bean • Not automated, developer manually creates mapping
through JDBC calls
to a result set
• Not as reusable
– Can map to a table, view, join or stored procedure in
a database – Hard-code database access within class
– Server provides automated mapping to convert • Advanced features like connection pooling and caching
relational data to bean instances are difficult to support because of reliance on hand
written code
• Advanced features like connection pooling and
caching are easily supported
• High reuse

25 26

BMP vs CMP Session Beans vs Entity Beans


A BMP either writes the data The CMP uses EJB query Mandatory for EJB 1.0 Optional for EJB 1.0
code in EJB, or in DAO format. language

BMP offers a tactical approach CMP offers a more strategic Represents a specific client Represents underlying data
approach (1 instance per client) object or context
need a less sophisticated need a more sophisticated (clients share instance)
application server application server Short-lived Long-lived
developer handles everything vendor takes care of everything Transient Persistent
a BMP developer will have the For a CMP bean developer, there Can be any Java class Can be a class that maps to
responsibility of the is no need to worry about JDBC
persistent data
transactions and all databases. code and transactions, as all
databases are automatically
(e.g., database)
handled by the container May be transactional Always transactional
Business Logic Beans Beans which represent data

27 28

Message Driven Bean


• Message Driven Bean implements MessageListner
• A message driven bean is like stateless session bean that
encapsulates the business logic and doesn't maintain state.
• MDB asynchronously receives the message and processes it.
• A message driven bean receives message from queue or topic
• Message-driven beans have the following characteristics.
– They execute upon receipt of a single client message.
– They are invoked asynchronously.
– They are relatively short-lived.
– They do not represent directly shared data in the database,
but they can access and update this data.
– They can be transaction-aware.
– They are stateless.

29 30

5
12/6/2019

A complete example application consist:


• home and remote interface code
• the bean implementation code
• the deployment descriptor
• client-side code
Basically by declaring the @Local @Remote interfaces you specify which
methods should be available for the remote clients and which for the local
beans in the same JVM. Home interface is used to allow a remote client to
create, find, and remove EJB objects.
•Home Interface
As required by the EJB specification, you must declare that any home
interface create() method throws the
javax.ejb.CreateException and java.rmi.RemoteException exceptions.
•Remote Interface
•The remote interface declares that the bean can throw
a RemoteException (required by the specification), and
a java.sql.SQLException, which is particular to this bean

31

You might also like