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