Leena Priscilla Paul
Last Update: 03 April ‘06
Objective # 1 - EJB Overview
1.1. Identify the use, benefits, and characteristics of Enterprise JavaBeans
technology, for version 2.0 of the EJB specification.
1.2 Identify EJB 2.0 container requirements.
1.3 Identify correct and incorrect statements or examples about EJB programming
1.4 Match EJB roles with the corresponding description of the role’s responsibilities,
where the description may include deployment descriptor information.
1.5 Given a list, identify which are requirements for an EJB-jar file.
1. EJB Architechture. How does it work?
2. Types of Enterprise Java Beans.
3. Difference between EJB Server and EJB container
4. Sample Programming of the beans
5. Difference between J2EE and EJB
6. Difference between regular JavaBeans and Enterprise JavaBeans.
1.1. Use, Benefits, and Characteristics EJB 2.0.
What are EJBs?
EJB – the abbreviated version for Enterprise Java Beans.
Enterprise JavaBeans is the architecture of the business tier in the J2EE application.
Bean is an alias for Component. Enterprise Beans are components.
Component is a reusable piece of code,
• Written according to some standard.
• Customized during deploy time.
• Is a component written in Java.
• Performs business logic
• Resides in the business tires of J2ee architecture.
So, Enterprise Beans is the Component and Enterprise Java Beans is the Architecture to which the
Bean or the Component conform.
Uses of EJBs.
EJB Components are reusable so that a Bean can be assembled and reassembled in to various applications.
Using the same headphone for radio, walkman and your electronic keyboard. Just plug-out and plug-in!!
With EJB architecture, the reusable components can be configured during the deployment time, without
changing the business code, by changing the Deployment Descriptors.
Deployment Descriptors hold the information of how a bean uses the underlying services.
Benefits of EJB’s
The exam objective asks you to identify the benefits of EJB.
But there’s nothing technical here. The objective is to identify the business benefits and not technical
The following are the Business benefits of EJBs.
Reduced time to market:
EJB application servers take care of a bunch of services, so that an EJB developer need not code for them.
The following are such services.
• Transaction Management
• Resource Management
• Deploy time Customization
(The EJB developer need not code them, as the server takes care of these underlying services but he can
tell the application server how these needs to be done through the Deployment Descriptor.)
So obviously, there’s a reduction in development time since the developer can worry only about the
implementation of the business logic. This obviously leads to the reduced time to market and indirectly to
the cost effectiveness for the client.
Using EJB Technology to implement business logic implies reduction in development cost as,
• Reduction in Development time.
• EJB Components are portable. They can be written once and deployed anywhere, in any vendor
platform, with different application servers with only changes in the deployment descriptor and not
any code changes. This also leads to cost reduction.
Robustness and Reliability:
Since the underlying infrastructural services are taken care by the well tested application server, there’s a
very little chance that the applications are unreliable.
Since EJB technology provides a distributed environment, fault tolerance can be done by replication (using a
back up server), thus increasing reliability. For load balancing and fault tolerance, multiple servers can be
Using multiple server implies:
• Scalability: Increase in the number of clients.
• Fault Tolerance: When one server is down, the other in the cluster can handle the load.(Round the
Characteristics of EJB’s
• Customized during deploy time by tweaking the Deployment Descriptor.
• Instances are created by the container during runtime.
Cannot run on its own (because there’s not main() method)
Created, Managed and served by the EJB container of the application server in which its deployed.
Container acts as a mediator between the client and bean.
WODA (Write Once Deploy Anywhere):
Here comes the portability feature that EJB technology inherited from the Java characteristics.
An EJB component when written as per the specification can be written for one application server and still
can be deployed in a different application server without changing the code.
Reusing EJB component is not like reusing the same piece of code, but it’s using a big chunk of
functionality across different applications. For example, using a Customer bean that performs enquiry
operation in Online Shopping application or in a Technical support application, or in an inventory/stock
1.2. EJB 2.0 requirements.
The following are the requirements to build EJB Components:
• Java 2 Platform, Standard Edition, v1.3 (J2SE) APIs (not J2SE 1.4)
• EJB 2.0 Standard Extension
• JDBC 2.0 Standard Extension (support for row sets only)
• JNDI 1.2 Standard Extension
• JTA 1.0.1 Standard Extension (the User Transaction interface only)
• JMS 1.0.2 Standard Extension
• Java Mail 1.1 Standard Extension (for sending mail only)
• JAXP 1.0
So an EJB container in an application server that supports EJB deployment must satisfy the above
1.3. Correct and Incorrect statements or examples about EJB
EJB components follow the WODA (Write Once, Deploy Anywhere) principle, but that does not mean WADA(
Write Anything, Deploy Anywhere.)
There are some program restrictions on the business methods that need to be adhered to when developing
an EJB Component.
In a distributed Environment:
• A static variable in a bean class should be final. It should be read-only.
• Thread synchronization should not be used in bean classes to implements synchronization among
different bean instances.
Both these two restriction is not adhered to will cause problems when multiple instances are distributed in
To prevent Security holes:
• Reading / Writing to a file descriptor from inside a bean class should not be done. (must not use the
java.io package to access files and directory system.)
• Security Information (Username/Password of database or application server), any confidential
information about the source code (like Physical location of the code) of should not be obtained
(from container) from inside a bean class code.
• ‘this’ should not be passed as an argument to any method or as a return value from a method.
Instead the object interface has to be used as Session.getEJBObject (), Session.getEJBLocalObject
(), or EntityContext.getEJBLocalObject (). Using ‘this’ is like giving the client the full control of the
bean, but its not the usual way of communicating with the bean as it is managed by container and
communicates with the client through the EJBObject.
Bean is not a Server:
• Bean should not be coded to do any server activities.(listening to sockets, accepting connections on
a socket, multicasting on a socket) which violates the EJB architechture.
• Bean can use socket as a client.
Bean is not a Container:
By doing a container’s job bean loses portability and robustness.
• Never create access or modify ClassLoader.
• Never create or set security Manager.
• Never indulge in killing the JVM process.
• Never Change I/O or error streams.
• Never try to set the Server – Socket (stream handler).
• Never implement thread management activities like start, stop, suspend, change priority, change
• Never load a native library.
• If a package access is denied to Enterprise beans by Java, it should be attempted to access.
• Defining a class in a package is the job of a container.
• Never access security configuration objects like Identity, Signer, Provider, Policy, and Security.
Never get input from input devices
Never write output to GUI (using AWT. Doing is violation of J2EE architechture.).
Never try to access files and directories directly. (Using this will lead to Machine dependency).
Note: These restrictions do not mean the code will not compile or run. But in order to preserve the
Characteristics, standards and specifications of J2EE and EJB these restrictions need to be adhered to.
1.4. EJB roles, responsibilities and Deployment Descriptors.
There are six distinct roles in a Enterprise JavaBeans Architechture.
• Enterprise Bean Provider
• Application Assembler
• Bean Deployer
• EJB Server Provider
• EJB Container Provider
• System Administrator
The Responsibilities of each role are described below.
Enterprise Bean Provider:
• Developer who codes the Bean is the Enterprise bean Provider.
• Implements the business logic of the enterprise bean.
• Develops the Javaclasses, Java Interfaces, XML Deployment Descriptor.
• With one or more bean and corresponding ejb-jar.xml file, compiles a jar file.
• The jar file is the EJB module or the component that can be deployed in a server (standalone) or can
be assembled, integrated in to a bigger J2EE application.
• Deliverable is one or more JAR files that includes the classes, interfaces and deployment descriptors.
• An EJB module developed by the Enterprise bean provide could be the only functionality of the whole
project or it could be a part of a big J2EE application, with different EJB modules, each provided by
the same or different Enterprise bean providers.
• An application assembler assembles or integrates the different EJB modules provided in different jar
files in to a single J2EE application.
• Application Assembler can opt to leave the beans in separate ejb-jar files or can create a single ejb-
jar files that contains all the beans being assembled.
• As per the requirement, Application assembler combines the components from other tier (like
• Application assembly instructions are added in to descriptor files.
• Deliverable is one or more JAR files that includes the bean and application descriptors.
Note: Same programmer may perform the roles Bean Provider and Application Assembler.
• Since EJB components are not capable of executing on their own, they need a operational
environment called EJB container.
• Application Assembler provides the Bean Deployer with the jar file.
• Bean Deployer, before deploying the bean ,
• Resolves the external dependencies (like Database connectivity) specified in the Deployment
• Creates the Container Specific files (classes, interfaces, xml files) which the container uses to
manage the beans.
• Installs the JAR and other files in the correct place in the server environment.
• Deliverable is a customized bean in the specific server environment.
Note: Bean Provider can sometimes perform the role of Bean deployer when customizing the bean’s
business logic and generating the container-specific classes.
EJB Server Provider:
• The EJB Server Provider is the Vendor.
• Provides an environment for the EJB Container Provider to run.
• EJB Server Provides the System level services like multiple processing and load balancing.
• EJB architechture assumes that the same vendor performs both EJB Server provider and EJB
container Provider roles.
• As EJB architechture does not provide any specification for any interface between EJB server and
EJB container, the vendor is free to decide on which service to be implemented in the EJB server and
• Deliverable is a EJB server compliant with EJB Specification.
EJB Container Provider:
• Container provider role is played by the Vendor.
• Container Implements the runtime support for the deployed EJB Components.
• Provide tools for deployment and other configuration activities.
• Runtime support Services like Transaction-Management, Security-Management, and Resource-
• This role needs to know system level programming and application domain knowledge.
• Deliverable is a Secure, Scalable, and Transaction-enabled EJB Container compliant with EJB
Note: Same Vendor may perform the roles of EJB Server Provider and EJB container Provider.
Difference between EJB Container and EJB Server
• The responsibility of this role is to execute and monitor the application which has been developed,
assembled and deployed.
• Configures and manages the network infrastructure. (including EJB Container)
• Configure the EJB Server and makes it available to other network services.
• Makes the Server available to users.
• Ensures the Start/Stop and proper running of the server.
• Deliverable is Configuration and monitoring of EJB Server.
1.5. Requirements for an EJB-jar file.
The ejb-jar file MUST CONTAIN, either by inclusion or by reference (Class-Path attribute in the Manifest file),
the class files of each enterprise bean as follows:
• The enterprise bean class.
• The enterprise bean home and component interfaces.
• The primary key class if the bean is an entity bean.
• All the classes and interfaces that each enterprise bean class and the home and component
interfaces depend on, except J2EE and J2SE classes.
The Application Assembler MUST NOT pack the stubs of the EJBHome and EJBObject interfaces in the ejb-jar
Programming the beans.
------------------------------------------END OF OBJECTIVE------------------------------------------------------
1. EJB Architechture. How does it work?
A diagram depicting the EJB architechture can be see below.
• Enterprise Java beans reside in the container in the server.
• Server/container takes care of all the underlying services.
• Server steps in every time there’s a call to the bean’s business logic functionality.
• Client can be a java application, a JSP page, Another Enterprise bean, or a mobile device.
• Client cannot communicate directly to the bean.
• Makes the call to the business interface of the bean.
• The EJB object intercepts the call.
• Now the server steps in and takes the call to an available bean instances.
• Business logic is executed and required Database transactions are done.
2. Types of Enterprise Java Beans.
The different types of Enterprise beans are
1. Session Beans
• Session Beans represent a process.
• Session bean ‘does’ something.
• The two types of Session Beans are,
o Stateless Session Beans
o Stateful Session Beans.
2. Entity Beans
• Entity Beans represent an entity.
• Entity Bean ‘is’ something.
• Entity Bean always represent something in database. An instance of an entity bean
represents a row in a table.
• There are two types of Entity Beans,
o Container Managed Persistence Beans
o Bean Managed Persistence Beans.
3. Message Driven Beans.
• Message Driver beans are used only when a JMS consumer (Asynchronous) is
• Clients send messages to the Java Messaging Service.
• On receiving a message, Message Driven Bean instances act accordingly.
• EJBObject is not present for a Message Driven Bean.
• Server gets the message directly from the client through a messaging service.
3. Difference between EJB Server and EJB Container
Sl.no EJB Server EJB Container
1. Server offers infra-structure Container offers services that
level services. are immediately related to the
2. Example: thread management, Example: transaction-
load balancing. management, security-
4. Programming the beans.
The six steps to build a bean are,
1. Create the Bean class
2. Create the Remote interface
3. Create the Home Interface.
4. Create the Deployment Descriptor XML.
5. Compile the JAR file.
6. Deploy the Bean.
Creating the bean class: (Stateless Session Bean Example)
• Bean class imports java.ejb.*; package.
• Bean class implements SessionBean interface.
• Implement the ejbActivate (), ejbPassivate (), ejbRemove (), setSessionContext (---), from the
SessionBean interface are implemented.
• ejbCreate () method is added.
• Business method is added.
Creating the Remote Interface: (Component Interface or Business Interface)
• Interface imports javax.ejb.* and java.rmi.RemoteException.
• Interface extends javax.ejb. EJBObject.
• Business method declaration is added corresponding to the method in bean class.
- 10 -
Creating the Home Interface:
• Interface imports javax.ejb.* and java.rmi.RemoteException.
• Interface extends javax.ejb. EJBHome.
• There should be a create () method declaration that must return the Component Interface type that
throws a CreateException.
Creating the XML: (Deployment Descriptor – ejb-jar.xml)
• The Deployment Descriptor describes the structure of the bean.
• DD describes how the three files are related to each other.
• Helps the server to know which is the Home, which is the component, and which is the bean class.
Sample ejb-jar.xml (Deployment Descriptor)
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN'
Compiling the JAR file:
To compile the JAR file, the components of the JAR file(bean class,home interface,remote interface and
Deployment Descriptor) have to arranged in specific location. The picture below explains the JAR file
compilation for the structure in the XML file given above.
- 11 -
After arranging and assembling the components of a bean, at the command prompt at the given jar file
level, a JAR file can be created by the following command.
Prompt:/>jar –cvf samplejar.jar *.*
Deploying the JAR file:
JAR file deployment can be done with the help of deploy tool that usually comes along with the EJB
5.Difference between J2EE and EJB
Sl.no J2EE EJB
1. J2EE architechture contains EJB EJB is the subset of J2EE
2. J2EE server must contain EJB -
- 12 -
5. Difference between regular JavaBeans and Enterprise JavaBeans.
Sl.no Regular Java Beans Enterprise Java Beans
1. Java bean is a reusable Enterprise Java Bean is also a
component. reusable component which
requires an EJB container to
2. GUI Components, JINI Servlets -
(pre-built reusable components)
are examples of javabeans.
************************END OF CHAPTER 1*********************************
- 13 -