Introduction to
Enterprise JavaBeans
Distributed Object
Architecture
Distributed Object
Architecture
DCOM Distributed RMI
Applications
[Microsoft’s [Sun’s approach]
Approach]
Common Object request
Broker
Architecture(CORBA)
RMI Architecture
RMI Application consists of
* Server
* Client
RMI defines two types of objects
* Stubs
* Skeletons
Marshalling - process of converting data or
objects into a byte-stream .
Unmarshalling - reverse process of
converting the byte-stream back to the original
RMI Architecture
Java Virtual Machine Java Virtual Machine
Client Object Server Object ‘S’
Object ‘S’ Stub Object ‘S’ Skeleton
Remote Reference Remote Reference
Layer Layer
TransportLayer TCP TransportLayer
RMI Layers
Stub and the Skeleton Layer
The stub forwards the request from
the client to the remote reference
layer and then to the skeleton
through transport layer.
Remote Reference Layer
Responsible for unicast point-to-point
method invocation.
Transport Layer
Uses TCP/IP for communication.
RMI workflow
Client Virtual Machine Server Virtual Machine
Client 7 Remote Object 1
6
5 Stub Skeleton Server
3 4
Remote Object
Registered
6.
1.
2.
3.
4.
5.
7. Stub
Server
Registry
Client
talks
requests
invokes
SkeletonCreates
Registers
returns
to skeleton
stub
invokesobject
Remote
from
method
remoteregistry
reference
object.method
object
object with RMI Registry Virtual Machine
registry interface
through
Java Naming and Directory
Interface
Java Naming and Directory Interface
provides the naming and directory
functionality to Java applications.
Provides a standard interface to
locate the components,
users,networks, and services placed
across the network.
Bridges the gap between directory
services and makes it possible for the
developer to write portable naming
The JNDI Architecture
Client
JNDI
Service Provider
Interface
CORBA LDAP Service NDS Service RMI
Application Provider Provider Application
Steps in JNDI Programming
Importing the JNDI classes Creating the Initial Context
Catching the Naming Exception Looking up the Component/Object
Compiling the Program Running the program
Steps in JNDI Programming
import java.naming.*
…
try {
….
System.setProperty("java.naming.factory.initial",
"org.jnp.interfaces.NamingContextFactory");
System.setProperty("java.naming.provider.url",
“<host>:1099");
Context ctx = new InitialContext();
Object obj= ctx.lookup(JNDIName);
….
}
catch(Exception e){….}
EJB
EJB stands for "Enterprise JavaBeans“.
EJB is a server side component that performs a
certain business logic.
Run any Application server support EJB
container
I.B.M. Web Sphere
BEA Web Logic
Sun Java System Application Server
Jboss
…
EJB is a framework for writing distrubuted
programs.
When to use EJB
The application must be scalable
and distributable.
Transactions will be required to
ensure data integrity.
the application will have a variety
of clients.
If you don't need platform
independence.
Advantages of EJB
Various vendor application servers
confirms to the specification, allowing
one to select a best-of-breed solution.
To meet the requirement of fluctuations
in demand, the vendor can scale server-
side resources
It provides you free access and usage of
complex resources namely transaction
and security management, resource
pooling, JNDI (Java Naming and Directory
Interface), component lifecycle
management, etc.
Disadvanatges of EJB
They have a large and complicated
Specification .
EJBs take longer to develop, and when
things go wrong, they can be more
difficult to debug, because there can be
a possibility that the bug may not be in
your code but in the application
server/container itself.
No sooner have you deployed your EJB
application, you see a new specification
with newer features, rendering your
application obsolete before it gets online.
This situation, however, is unavoidable.
New Features in EJB 2.0
Container-Managed Persistence
Container-Managed Relationships
Message-Driven Beans
Local Interface
Additional Methods on the Home-
Interface
New Query Language (EJB QL)
EJB Overview
Parties Involved in EJB
Deployment
Parties in EJB
Deployment
Provides reusable
components Monitors functioning
Bean Provider System
Administrator
Deploys prewritten
Provides low-level components
execution EJ
environment B
Container Provider The Deployer Cont/
Server
Supplies Application server Puts together
Application
logic Server Provider components
Assembler
and applications
EJB Roles
The EJB Container
The container which resides
insides the server acts as a
BUFFER between the the beans
and the outside world.
Provides the environment in which
a bean executes
Generates Home Object
Generates EJB Object
Managing Life-cycle of a Bean
The EJB Container
EJB Architecture
EJB Flow Chart
Using JNDI to lookup Home
Objects EJB Container/Server
3. Creates an EJB Object
Client Home
Object
5. Return Object reference
1. Retrieve 4. Create EJB Object
Home
Object
6. Invokes business methods
EJB Enterprise
JNDI Object beans
7. Delegates request to bean
2. Returns reference
to the home object
Naming
Service
Enterprise Beans
The Enterprise Java Bean is a server-side component that is employed on
a distributed multi-tier environment.
Enterprise Bean
Session Bean Message Entity Bean
Driven Beans
Stateful Stateles
Bean s Bean BMP CMP
Life Cycle of a Session
Bean
A session bean may last as long as the
client session.
Will not survive if the application
server changes or crashes.
They are objects which are present in-
memory which die along with the
surrounding environment and are not
persisted in a database.
Stateless Session Beans
Provide a single use service.
They do not maintain state in class
level variables. they are called as
"Stateless“.
Since they do not have any states,
they need not be passivated.
They are fastest and most
efficient.
Life Cycle of Stateless
Session Bean
Stateful Session Beans
They do maintain state in class
level variables.
They need to handle Activation
and Passivation
Each client is provided a different
and specific Stateful Session bean.
they can be persisted, they are
also called Persistent Session
Beans
Life Cycle of Stateful
Session Bean
Entity Bean
They are a representation of
persistent data.
They can survive a crash.
Has a Primary key like in a
Database record.
Bean-Managed Persistence
Entity Beans (BMP)
BMP bean's persistence has to be
managed by the EJB itself.
It gives more control to the EJB
developer to save and retrieve
data.
Use of BMP beans would be to
retrieve and save data from non-
database data sources like XML
files, JMS resources etc.
Life Cycle of BMP Entity
Bean
Container-Managed
Persistence Entity Beans
CMP bean's persistence is managed by
the EJB container.
the EJB container is responsible for
saving the Bean's state.
The container-managed fields need to
be specified in the Deployment
Descriptor and the persistence is
automatically handled by the container.
CMP beans are easier to develop and
work well with database access.
Life Cycle of CMP Entity
Bean
BMP vs CMP
CMP is more
BMP offers a
strategic
tactical approach. Vendor takes care
The developer of everything by
takes care of using O-R or OODB
handling mappings using
persistence. metadata.
BMP uses hard
A developer cannot
optimize
coded queries so
performance as the
we can optimize vendor takes care
Message-Driven Beans
Allows JMS applications to receive messages
asynchronously (the sender is independent of
the receiver receiving and processing the
messages).
Includes business logic, which may include
operations such as:
* Performing computation on received data
* Initiating a step or condition in a workflow
* Storing data
* Sending a message
Uses of Message-Driven
Beans
Asynchronous messaging.
Integrating two applications in a
loosely coupled but reliable
manner.
Mere message delivery or message
content should drive other events
in the system.
Create message selectors which
are designed to consume only
