UNIT II

EJB ARCHITECTURE

CONTENTS

EJB Introduction

EJB Architecture

Overview of EJB software architecture

View of EJB

Conversation

Building and Deploying EJBs

Roles in EJB.

Preface
This unit introduces the core aspects of EJP concepts. It deals with EJB Architecture
and Views of EJB . This unit portrays the concepts of Building and Deploying EJBs. And
also this unit covers the roles in EJB.

Introduction
Enterprise JavaBeans (EJB) are reusable Java components that implement
business logic and enable you to develop component-based distributed business
applications. EJBs reside in an EJB container, which provides a standard set of services
such as persistence, security, transactions, and concurrency. Enterprise JavaBeans are the
standard for defining server-side components. WebLogic Server's implementation of the
Enterprise JavaBeans component architecture is based on Sun Microsystems EJB
specification.
Enterprise Java Bean:

 A server-side component technology

 Easy development and deployment of Java technology-based application that are:
 Transactional, distributed, multi-tier, portable, scalable, secure, …
● Leverages the benefits of component-model on the server side
● Separates business logic from system code
− Container provides system services
● Provides framework for portable components
− Over different J2EE-compliant servers
− Over different operational environments
● Enables deployment-time configuration
− Deployment descriptor

(((Enterprise JavaBeans (EJB) are reusable Java components that implement

business logic and enable you to develop component-based distributed business
applications. EJBs reside in an EJB container, which provides a standard set of
services such as persistence, security, transactions, and concurrency. Enterprise
JavaBeans are the standard for defining server-side components. WebLogic Server's
implementation of the Enterprise JavaBeans component architecture is based on Sun
Microsystems EJB specification.)))
Why EJB?
z EJB Architecture simplifies the development of distributed enterprise
applications.
z EJB Specification is a solution that is operating-system independent.
z Middleware Independence
z EJB defines a solution that eases the development and deployment of distributed
applications
z EJB enables the development of reusable and portable components.
z EJB has Broad Industry Support: Server Vendors and End Users.

EJB Vs JavaBeans

 JavaBeans component model defines a standard mechanism to develop portable, Java

components, such as widgets or controls.

 JavaBeans technology can be used in any visual Java technology integrated

development environment (IDE)

Java Beans

 EJB component model logically extends the JavaBeans component model to support
server components.

 EJB components cannot be manipulated by a visual Java IDE in the same way that
JavaBeans can, They are prepackaged pieces of application functionality that are
designed to run in an application server.

Characteristics of EJB:
1. Hides server-side system level issues from developers.
2. Defines a standard component architecture that enables you to build distributed
object-oriented business applications.
 3. Facilitates creating enterprise-level applications by allowing easy integrating
with other EJB components as well as with other components, such as servlets,
Java Server Pages (JSP), and Java Beans.
4. Enables you to create components and applications that are reusable across
various J2EE-compliant servers.
The server-side components deployed on the application servers can be
implemented using various technologies, such as EJB and Microsoft’s COM/DCOM.
Enterprise JavaBeans are different from JavaBeans, another similarly named Sun
Microsystems component based technology.
Examples of real-life applications where you can use the EJB component architecture are:
• Online share trading application
• Online reservation application
• Online catalog application
• Online library application

The EJB specification defines the following four types of Enterprise JavaBeans:

Stateless session. These non-persistent EJBs provide a service without storing

an interaction or conversation state between methods.

Stateful session. These non-persistent EJBs maintain state across methods and
transactions. Each instance is associated with a particular client.

Entity. These persistent EJBs represent an object view of the data, usually rows
in a database. An entity bean has a primary key as a unique identifier.

Message-driven. These EJBs are integrated with the Java Message Service
(JMS) to enable message-driven beans to act as a standard JMS message
consumer and perform asynchronous processing between the server and the JMS
message producer. The WebLogic Server container directly interacts with a
message-driven bean by creating bean instances and passing JMS messages to
those instances as necessary.
 From the EJB sub-node, of the Deployments node of the Administration Console,
you can update or configure EJBs deployed on WebLogic Server or monitor the
their performance.

Configuring EJBs

To configure an EJB for deployment to the WebLogic Server Administration

Console:

1. Start the WebLogic Server Administration Console.

2. Select the Domain in which you will be working.

3. In the left pane of the Console, click Deployments.

4. In the left pane of the Console, click EJB. A table is displayed in the right pane
of the Console showing all the deployed EJBs.

5. Select the Configure a new EJB option.

6. Locate the EAR, WAR or JAR file you would like to configure. You can also
configure an exploded application or component directory. Note that WebLogic
Server will deploy all components it finds in and below the specified directory.

7. Click [select] to the left of a directory or file to choose it and proceed to the
next step.

8. Select a Target Server from among Available Servers.

9. Enter a name for the EJB or application in the provided field.

10. Click Configure and Deploy. The Console will display the Deploy panel, which
lists deployment status and deployment activities for the EJB.

11. Using the available tabs, enter the following information:

 • Configuration—Edit the staging mode and enter the deployment
order.
• Targets—Indicate the Targets-Server for this configured EJB or
application by moving the server from the Available list to the Chosen
list.
• Deploy—Deploy the EJB or application to all or selected targets or
undeploy it from all or selected targets.
• Monitoring—Enable session monitoring for the EJB or application.
• Notes—Enter notes related to the EJB or application.

EJB Architecture

• EJB Server
• EJB Container
• EJB Client
• Enterprise Java Beans
• Auxiliary Systems - JNDI, JTA, JavaMail
DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

EJB is a server-side component architecture that simplifies the process of building

enterprise-level, distributed applications in Java. EJB components are deployed in EJB
containers of J2EE-compliant application servers, such as J2EE 1.4, Weblogic, and
JBoss.
Various components of EJB architecture are:
• EJB Container: Provides the runtime environment for the EJB components and
services, such as life cycle management, connection pooling, and security.
• EJB Component: Java classes that follow the EJB specification to implement the
business logic of an application. EJB components are deployed in EJB container
and are accessed using the remote and home interfaces of an enterprise bean.
• EJB Object: EJB container generates an EJB object, when a client needs to
access an instance of the enterprise bean. The EJB object acts as an interface
between the client and bean instances.
• Home Object: Home objects are generated by EJB container. Clients access EJB
objects that are stored at different Java Virtual Machines (JVM), using the home
object.

An enterprise bean is a distributed server component that lives in an EJB

container and is accessed by remote clients over network via its remote interface or is
accessed by other local enterprise beans on the same server via its local interface.

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 7

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

The EJB component is a remotely executable component deployed on its server

and it is a self-descriptive component specified by its Deployment Descriptor (DD) in a
XML format.
Each EJB component has a business logic interface that clients can run the
business logic operations via this interface without knowing the detail implementation
behind the interface. We call such interface as a remote or local interface.
An instance of an EJB component is created and managed by its factory named
home interface on the EJB container. Every enterprise bean must have a home interface
and a remote (local) interface. The EJB component can be configured at the deployment
time by specifying its deployment descriptor.
The EJB classes behind home and remote (or local) interfaces are the
implementations of these two interfaces. An EJB component is a black-box
component. A client of an EJB component only knows what the component does but not
how it does. A client makes a request to an EJB component with its deployed name by
looking up at JNDI to get an Object Reference (OR) of this EJB component.
The client can then create an instance of this EJB component on the server
according to the reference. Finally, the client invokes the business methods of this EJB
instance. The EJB class may also locate and access other EJB beans at remote sites by
using EJB context information. The message driven bean is an exception which does not
have any interface like the home and remote interfaces that a classic EJB has.

Enterprise beans provide several benefits for application developers:

• They allow you to build distributed applications by combining components

developed using tools from different vendors.
• They make it easy to write applications. You do not have to deal with low-level
details of transaction and state management, multithreading, resource pooling, and
other complex low-level APIs. However, if necessary, expert programmers can
still gain direct access to the low-level APIs.
• They can be developed once and then deployed on multiple platforms without
recompilation or source code modification.

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 8

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

• The EJB specification that governs the use of enterprise beans is compatible with
other Java™ APIs and CORBA. It also provides for interoperability between
enterprise beans and non-Java applications.

Enterprise beans

An enterprise bean is a non-visual component of a distributed, transaction-

oriented enterprise application. Enterprise beans are typically deployed in EJB
containers and run on EJB servers. You can customize them by changing their
deployment descriptors and you can assemble them with other beans to create
new applications. There are three types of enterprise beans: session beans, entity
beans, and message-driven beans.
• Session beans: Session beans are non-persistent enterprise beans.
They can be stateful or stateless. A stateful session bean acts on
behalf of a single client and maintains client-specific session
information (called conversational state) across multiple method
calls and transactions. It exists for the duration of a single
client/server session. A stateless session bean, by comparison,
does not maintain any conversational state. Stateless session beans
are pooled by their container to handle multiple requests from
multiple clients.
• Entity beans: Entity beans are enterprise beans that contain
persistent data and that can be saved in various persistent data
stores. Each entity bean carries its own identity. Entity beans that
manage their own persistence are called bean-managed persistence
(BMP) entity beans. Entity beans that delegate their persistence to
their EJB container are called container-managed persistence
(CMP) entity beans.
• Message-driven beans: Message-driven beans are enterprise beans
that receive and process JMS messages. Unlike session or entity
beans, message-driven beans have no interfaces. They can be
accessed only through messaging and they do not maintain any
conversational state. Message-driven beans allow asynchronous
CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 9
DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

communication between the queue and the listener, and provide

separation between message processing and business logic.

Remote client view

The remote client view specification became available beginning with EJB 1.1.
The remote client view of an enterprise bean is location independent. A client
running in the same JVM as a bean instance uses the same API to access the bean
as a client running in a different JVM on the same or different machine.
• Remote interface: The remote interface specifies the remote business
methods that a client can call on an enterprise bean.
• Remote home interface: The remote home interface specifies the methods
used by remote clients for locating, creating, and removing instances of
enterprise bean classes.

Local client view

The local client view specification is available in EJB 2.0 or later. Unlike the
remote client view, the local client view of a bean is location dependent. Local
client view access to an enterprise bean requires both the local client and the
enterprise bean that provides the local client view to be in the same JVM. The
local client view therefore does not provide the location transparency provided by
the remote client view. Local interfaces and local home interfaces provide support
for lightweight access from enterprise bean that are local clients. Session and
entity beans can be tightly couple with their clients, allowing access without the
overhead typically associated with remote method calls.
• Local interface: The local interface is a lightweight version of the remote
interface, but for local clients. It includes business logic methods that can
be called by a local client.
• Local home interface: The local home interface specifies the methods used
by local clients for locating, creating, and removing instances of enterprise
bean classes.

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 10

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

Web service client view

In the EJB 2.1 specification, the EJB architecture introduced the support for Web
services. A client for a session bean can be a Web service client. A Web service
client can make use of the Web service client view of a stateless session bean,
which has a corresponding service endpoint interface..

Service endpoint interface

The service endpoint interface for a stateless session bean exposes the
functionality of the session bean as a Web service endpoint. The Web Service
Description Language (WSDL) document for a Web service describes the Web
service as a set of endpoints operating on messages. A WSDL document can
include the service endpoint interface of a stateless session bean as one of its
endpoints. An existing stateless session bean can be modified to include a Web
service client view, or a service endpoint interface can be mapped from an
existing WSDL to provide the correct interface.

A Web service client view is independent of location and can be accessed through
remote calls.

EJB client JAR file

An EJB client JAR file is an optional JAR file that can contain the client
interfaces that a client program needs to use the client views of the enterprise
beans that are contained in the EJB JAR file. If you decide not to create an EJB
client JAR file for an EJB module, all of the client interface classes will be in the
EJB JAR file. By default, the workbench creates EJB client JAR projects for each
corresponding EJB project.

EJB container

An EJB container is a runtime environment that manages one or more enterprise

beans. The EJB container manages the life cycles of enterprise bean objects,
coordinates distributed transactions, and implements object security. Generally,

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 11

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

each EJB container is provided by an EJB server and contains a set of enterprise
beans that run on the server.

Deployment descriptor

A deployment descriptor is an XML file packaged with the enterprise beans in an

EJB JAR file or an EAR file. It contains metadata describing the contents and
structure of the enterprise beans, and runtime transaction and security information
for the EJB container.

EJB server

An EJB server is a high-level process or application that provides a runtime

environment to support the execution of server applications that use enterprise
beans. An EJB server provides a JNDI-accessible naming service, manages and
coordinates the allocation of resources to client applications, provides access to
system resources, and provides a transaction service. An EJB server could be
provided by, for example, a database or application server.

Types of EJB

Version 1.1 of the EJB Specification [EJB1.1 4.3] defined two types of EJB: the session
EJB and the entity EJB. Version 2.0 introduces a third type, the message-driven EJB
[EJB2.0 4.3]. It is possible to envisage EJB applications where the EJBs don’t fit neatly
into any of these categories, but in practice one of these types can be adapted to suit most
jobs.

(i)Session EJBs

A session EJB is a nonpersistent object: Its lifetime is the duration of a particular

interaction between the client and the EJB. The client normally creates an EJB, calls
methods on it, and then removes it. If the client fails to remove it, the EJB container will
remove it after a certain period of inactivity. Session EJBs are subdivided into ‘stateful’
and ‘stateless’ types. A stateless session EJB is shared amongst a number of clients, while

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 12

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

a stateful session EJB is created for a specific client and not used by any others. The use
of stateless EJBs offers efficiency advantages but, of course, it is not always possible to
use them.

(ii) Entity EJBs

Entity EJBs represent persistent objects: Their lifetimes are not related to the
duration of interaction with clients. In nearly all cases, entity EJBs are synchronized with
relational databases. This is how persistence is achieved. Entity EJBs are always shared
amongst clients: A client cannot get an entity EJB to itself. Thus, entity EJBs are nearly
always used as a scheme for mapping relational databases into object-oriented
applications.

Whereas a client normally creates a session EJB and removes it after use, clients
normally look up an existing entity EJB. Creation of an entity EJB corresponds to adding
new data items to the application (e.g., adding rows to database tables).

An important feature of entity EJBs is that they have identity—that is, one can be
distinguished from another. This is implemented by assigning a primary key to each
instance of the EJB, where ‘primary key’ has the same meaning as it does for database
management. Primary keys that identify EJBs can be of any type, including programmer-
defined classes.

(iii)Message-driven EJBs

A message-driven bean acts as a consumer of asynchronous messages: It cannot

be called directly by clients, but is activated by the container when a message arrives.
Clients interact with these EJBs by sending messages to the queues or topics to which
they are listening. Although a message-driven EJB cannot be called directly by clients, it
can call other EJBs itself.

Message-driven EJBs are the only type that do not follow a strict request-response
interaction with clients.

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 13

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

Why use EJBs?

It is possible to write applications that support distribution, transaction management, and

security without using EJBs. There are many such applications in use already. So what
advantages do EJBs have to offer over other techniques?

• The EJB developer works within the EJB framework to take advantage of its
built-in support for features like transaction management and security; once
understood, little developer effort is required to make effective use of these
features. With suitable servers, EJB applications can even make use of features as
sophisticated as distributed transaction management with no coding whatsoever.
• EJB 2.0 introduces a very powerful persistence management scheme, which
supports not only persistent data, but persistent relationships between objects. It
takes a while to get used to, but once mastered, this revolutionizes the
development of persistent application objects. Again, very little coding is required
to implement such objects.
• The EJB framework presents the EJB with a managed operating environment. For
example, the framework ensures that an EJB instance is never executing in more
than one concurrent thread,3so the developer does not have to be concerned about
the effects of concurrency on data integrity. The container is also responsible for
memory and resource management, so EJB developers don't have to be concerned
with these issues.
• EJBs can make use of the full range of Java APIs and class libraries. It is
relatively straightforward to code an EJB that parses XML, sends email, and
communicates with directory and database servers via standard APIs like JDBC
and JNDI.
• EJBs isolate database implementation from the application's business logic. If we
use entity EJBs, for example, as models of the underlying data, then theuse of that
data is decoupled from its internal representation. This leads to increased ease of
maintenance and portability of code. We can also use EJBs as interfaces to legacy
systems, with similar advantages.

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 14

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

• EJBs are very accessible to Web components such as servlets and JSPs. There are
a number of products available that support these components in the same
application framework (typically called application servers). This makes it
straightforward to provide EJB applications with a Web-based user interface and,
perhaps, provide Internet access to the application.

A High Level View of an EJB Conversation.

• In the EJB architecture, the client undertakes the following tasks:

o Finding the bean
o Getting access to a bean
o Calling the bean’s methods
o Getting rid of the bean

Finding the bean

o EJB specification mentions two ways in which a client can find a bean

Using the Java Naming and Directory Interface

Using the CORBA’s Common Object Service (COS)
o JNDI API provides a uniform interface to naming and directory services.
o A naming service is a service that associates a Symbolic Name with an
object
o Domain Name Service is a commonly used naming service that is used to
transfer symbolic machine names into numeric IP addresses.
o Previous model of DNS, needed to maintain a file containing a list of
symbolic host names along with the numeric IP addresses that they should
resolve to.
o Problems in this approach:

If the /etc/hosts/file developed errors, couldn’t resolve symbolic
names.

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 15

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

Needed to maintain the change of addresses when new machines

were added.

If a machine did not appear in the /etc/hosts file, need to know its
numeric IP address to connect to it.
o Using DNS approach allows you to avoid many of these annoyances. It
works as follows:

A client makes a query to a DNS server

If the DNS server knows how to resolve the address, it returns the
address.

If the DNS server does not know how to resolve the address, it
provides the query to another DNS server

Once the server is able to resolve the name, it returns the address to
the client. Typically, it also caches the result so that, if the request
is made again, it can be handled immediately.
o JNDI provides a uniform interface to naming services.
o JNDI client uses the Server’s SPI (Server Provider Interface) to access its
services.
o A Java client can use JNDI to lookup an EJB component.
o The JNDI call returns a reference to an object implementing the EJB
component’s “home” interface, which can then be used to gain access to
the EJB object itself.
o The other way to find an EJB component is to use CORBA’s Common
Object Services (COS) naming service.
o COS refers to a group of Services, including naming, that is provided as
part of the CORBA services specification.
o In addition to suing COS naming directly, can make use it via JNDI.

Getting access to a bean

o The result of the naming lookup is a reference to an object implementing

the EJB components home interface

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 16

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

o A client uses the home interface to look up existing EJB instances, or to

create new ones.
o This lookup result in a reference to an object that implements the EJB
object’s remote interface.
o The client uses the remote interface to interact with the EJB objects on the
server.

Calling the bean’s methods

o After the client has a reference to an object implementing the object’s

remote interface, it can then invoke the methods that the EJB object makes
public in the remote interface.

Getting rid of the bean

o When the client has finished with an EJB object, it can call the remove()
method on the home interface or on the object’s remote interface.
o Usually remove() is called on a stateful session bean when it is no longer
needed, so that the container can discard it and use the space for other
beans.
o remove() method on the stateless bean can be invoked, but generally has
no effect; the server simply returns the instance to a pool.
o remove() on entity beans, would remove the underlying object from
persistent storage.

(Ex: when the customer bean is removed, the data will be deleted
from the underlying database.)

o Clients can interact with EJB either through CORBA or through RMI.

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 17

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

Overview of the EJB Building and Deploying Process

Building and deploying EJBs in the WebLogic Enterprise environment requires careful
planning to define how to locate these EJBs in the WLE distributed environment.

After the Bean Provider has implemented an EJB's business logic and has produced an
initial deployment descriptor, the process for building and deploying that EJB in the
WLE environment includes the following steps:

• Step 1: Obtain the EJB JAR file from the bean provider.
• Step 2: Modify the deployment descriptor.
• Step 3: Create the WebLogic EJB extensions to the deployment descriptor DTD.
• Step 4: Produce the deployable EJB JAR file.
• Step 5: Configure the EJB application.
• Step 6: Specify the module initializer object in the WebLogic EJB extensions to
the deployment descriptor DTD.

When you build the EJB that has been produced by the Bean Provider, the end result is an
EJB JAR file. The WLE system allows you to build two kinds of EJB JAR files:

Standard EJB An EJB that has been built, but lacks the specific deployment
JAR file information on any specific system. You typically build a standard EJB
with the goal of being able to distribute that EJB to a variety of
deployment environments. If you are only creating a standard EJB JAR
file, you only need to perform steps 1 and 2 in this topic.

Deployable An EJB that has been built with deployment descriptor information
EJB JAR file specific to a particular deployment environment. The steps described in
this chapter for building a deployable EJB JAR file specifically create an
EJB that can be deployed on a WLE system, and require you to perform

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 18

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

steps 1 through 4 in this topic.

The remainder of this topic discusses each of these steps in detail.

Steps for Building and Deploying EJBs

This section describes the steps for building and deploying EJBs in the WLE
environment and also provides the following sections:

• Scaling an EJB Application

• For More Information

Step 1: Obtain the EJB JAR file from the bean provider.
The first step in deploying an EJB is to obtain the EJB JAR file from the Bean Provider.
In addition to the class files contained in the EJB JAR file, the EJB JAR file also has a
deployment descriptor for each bean in that file. The steps for producing the Bean
Provider's EJB JAR file are described in the section Development Steps.

Because multiple EJBs can be joined together in a single, deployable unit, part of the
assembly process is joining the EJB JAR files for each of the beans.

Step 2: Modify the deployment descriptor.

As stated in Designing and Developing Enterprise JavaBeans for the WLE System, the
deployment descriptor ties together the different classes and interfaces, and is used to
build the code-generated class files. It also allows you to specify some aspects of the
EJB's deployment at run time.

The Bean Provider specifies some initial deployment information in the deployment
descriptor. The deployer typically needs to add to or modify that information, such as
shown in the following table:

The EJB's name You may change the enterprise bean's name defined in the ejb-name

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 19

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

element.

Values of You may change existing values or define new values for the
environment environment properties.
entries

Description fields You may change existing or create new description elements.

Binding of You may link an enterprise bean reference to another enterprise

enterprise bean bean in the EJB JAR file. You create the link by adding the ejb-link
references element to the referencing bean.

Security roles You may define one or more security roles. The security roles
define the recommended security roles for the clients of the
enterprise beans. You define the security roles using the security-
role elements. For more information about EJB security, see Using
Security in the WebLogic Enterprise online documentation.

Method You may define method permissions, which are binary relationships
permissions between the security roles and the methods of the remote and home
interfaces of the EJBs. You define method permissions using the
method-permission elements.

Linking of If you define security roles in the deployment descriptor, you must
security role link the security role references declared by the Bean Provider to
references the security roles. You define these links using the role-link
element. For more information about EJB security, see Using
Security in the WebLogic Enterprise online documentation.

Changing The deployer can change the type of persistent storage used by a

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 20

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

persistent storage bean. If the persistentStoreType is file , the serialized files are
information, if created in this directory. The default file is / pstore/ bean_name .dat
necessary , where the directory pstore represents the directory from which the
WLE application was started, and bean_name is the fully qualified
name of the EJB with underscores (_ ) replacing the periods (. ) in
the name.

If the persistentStoreType is jdbc , the container looks for additional

values to determine the appropriate values for the JDBC
connection. Note that if the bean's persistence is stored in a
database via a JDBC connection, the system administrator needs to
add this information to the UBBCONFIG file as well. For more
information, see Using the JDBC Drivers in the WebLogic
Enterprise online documentation.

Note that persistence information is specified in the WebLogic EJB

extensions to the deployment descriptor DTD file, as described in
the section Specifying Persistence Information.

To modify a deployment descriptor, you can use either of the following two methods:

• The WebLogic EJB Deployer

• The manual modification of the deployment descriptor in a text editor

The type of deployment descriptor you produce depends on whether you are creating a
standard EJB JAR file or a deployable EJB JAR file.

Creating a Standard EJB JAR File

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 21

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

If you are creating a standard EJB JAR file, you only need to modify the single
deployment descriptor contained in the EJB JAR file produced by the Bean Provider.
When modifying this deployment descriptor, use the syntax described in the EJB 1.1
Specification produced by Sun Microsystems, Inc.

If you are creating a standard EJB JAR file:

1. Make the appropriate modifications to the bean's deployment descriptor file.

2. Run the ejbc command, specifying the -nodeploy option.

For more information about the ejbc command, see the Command Reference in the
WebLogic Enterprise online documentation.

Creating a Deployable EJB JAR File

If you are creating a deployable EJB JAR file, you need to do the following:

• Modify the deployment descriptor, as described in the section Creating a Standard

EJB JAR File.
• Create a WebLogic Enterprise extended deployment descriptor file, which is also
created as an XML file, and which specifies the information described in the
section Step 3: Create the WebLogic EJB extensions to the deployment descriptor
DTD..

Step 3: Create the WebLogic EJB extensions to the deployment descriptor DTD.
For an EJB application to be deployable in the WLE environment, you need to create a
file containing the WebLogic EJB extensions to the deployment descriptor DTD. This
file specifies the following run time and configuration information for the EJB
application:

• Custom application startup and shutdown properties

• Registration of the application's home interfaces
• Persistence information

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 22

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

Specifying the WebLogic EJB Extensions DTD

The file that includes the WebLogic EJB extensions to the deployment descriptor DTD
must specify the following DTD reference at the beginning:

<!DOCTYPE weblogic-ejb-extensions SYSTEM "weblogic-ejb-extensions.dtd" >

Specifying the Module Initializer Class

Server application startup and shutdown can be handled automatically by the EJB
container. However, if you have special server initialization or shutdown requirements,
use the module-initializer-class-name element in the WebLogic EJB extensions to the
deployment descriptor DTD to specify the name of the module initializer object.

The syntax for specifying a module initializer object for handling the initialize and
release methods is similar to that for CORBA and RMI. However, with the CORBA and
RMI models, the startup and shutdown information is specified in an XML file and is
serialized by the buildjavaserver command. For EJB deployment, XML elements for
startup and shutdown procedures are specified together with the other elements in the
WebLogic EJB extensions to the deployment descriptor DTD, and you process them
using the ejbc command. The WLE EJB container parses the XML at run time and
performs the startup and shutdown processing. See the section Step 5: Configure the EJB
application. for a complete description of startup and shutdown handling in WLE.

XML DTD Syntax

<!ELEMENT module-initializer-class (module-initializer-class-name*))>

<!ELEMENT module-initializer-class-name (#PCDATA)>

Example

<weblogic-ejb-extensions>
. . .
<module-initializer-class>
<moduleinitializer-class-name>ServerImpl

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 23

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

</moduleinitializer-class-name>
</module-initializer-class>
</weblogic-ejb-extensions>

Registering Names for the EJB Home Classes

A name for the EJB home class must be registered in the global WLE JNDI namespace.
This allows Java clients to perform a lookup on the JNDI name for the EJB home and
gain access to the object. The name for the EJB home class can be different than the <ejb-
name> element specified in the standard EJB XML. The <ejb-name> in the standard
deployment descriptor must be unique only among the names of the EJBs in the same
EJB JAR file. However, the JNDI name must be unique among all global home or factory
names in a WLE domain; this includes EJB homes, CORBA factories, and RMI named
objects.

XML DTD Syntax

<!ELEMENT jndi-name (#PCDATA)>

Example

<weblogic-ejb-extensions>
<weblogic-version>
WebLogic Enterprise Server 5.0
</weblogic-version>
<weblogic-enterprise-bean>
<ejb-name>
oracle
</ejb-name>
<weblogic-deployment-params>

<max-beans-in-free-pool>
20
</max-beans-in-free-pool>

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 24

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

<max-beans-in-cache>
1000
</max-beans-in-cache>
<idle-timeout-seconds>
5
</idle-timeout-seconds>
<!-- JNDI name that is associated with this EJB;
used for lookup -->
<jndi-name>
oracle.OracleHome
</jndi-name>
.
.
.
</weblogic-ejb-extensions>

Specifying Persistence Information

The WLE EJB container provides container-managed persistence. The code for
implementing the persistence is generated by the ejbc command based on the deployment
descriptors. The persistence store can be a flat file or it can be a database managed with a
JDBC connection pool. For the EJB state to fully cooperate in a WLE global transaction,
configure the EJB to use the JDBC-managed database store provided in WLE. Use file-
based persistence only during development and prototyping.

The standard deployment descriptor created by the Bean Provider normally specifies:

• The fields in the EJB that are to be persistent, via the cmp-field element
• Information about the primary key

However, you, as the deployer, need to specify additional information for mapping an
EJB to its persistent store via the WebLogic EJB extensions to the deployment descriptor
DTD.

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 25

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

File-based Persistence
The following code shows the WebLogic EJB extensions to the deployment descriptor
DTD for specifying file-based persistence:

<!--
Persistence store descriptor. Specifies what type of persistence store
EJB container should use to store state of bean.
-->
<!ELEMENT persistence-store-descriptor (description?,
(persistence-store-file |
persistence-store-jdbc)?)>
<!--
Persistence store using file. Bean is serialized to a file.
Mainly used to store state of Stateful Session Beans.
-->
<!ELEMENT persistence-store-file (description?,
persistence-store-directory-root
?)>
<!--
Root directory on File system for storing files per bean.
-->
<!ELEMENT persistence-store-directory-root (#PCDATA)>
The information supplied for the persistence-store-directory-root element is used by the
EJB container to store all instances of the EJB, with the ejb-name element converted to a
directory name.

Database-stored Persistence
The following code shows the WebLogic EJB extensions to the deployment descriptor
DTD for specifying a JDBC connection for database-stored persistence:

<!--
Persistence store is any RDBMS. JDBC driver is used to talk to database.

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 26

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

Required for CMP.

-->
<!ELEMENT persistence-store-jdbc (description?, pool-name, user?, password?,
driver-url?, driver-class-name?, table-name, attribute-map,
finder-descriptor*)>

<!-- Required for CMP -->

<!ELEMENT pool-name (#PCDATA)>

<!-- Ignored in WebLogic Enterprise Server as this is part of connection

pool
setup at startup -->
<!ELEMENT user (#PCDATA)>

<!-- Ignored in WebLogic Enterprise Server as this is part of connection

pool
setup at startup -->
<!ELEMENT password (#PCDATA)>

<!-- Ignored in WebLogic Enterprise Server as this is part of connection

pool
setup at startup -->
<!ELEMENT driver-url (#PCDATA)>

<!-- Ignored in WebLogic Enterprise Server as this is part of connection

pool
setup at startup -->
<!ELEMENT driver-class-name (#PCDATA)>

<!-- Required for CMP -->

<!ELEMENT table-name (#PCDATA)>

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 27

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

<!-- Required for CMP -->

<!ELEMENT attribute-map (description?, attribute-map-entry+)>

<!-- Required for CMP -->

<!ELEMENT attribute-map-entry (bean-field-name, table-column-name)>

<!-- Required for CMP -->

<!ELEMENT bean-field-name (#PCDATA)>

<!-- Required for CMP -->

<!ELEMENT table-column-name (#PCDATA)>

<!-- Required for CMP -->

<!ELEMENT finder-descriptor (description?, method?, query-grammar?)>

<!-- Required for CMP -->

<!ELEMENT query-grammar (#PCDATA)>
The EJB instances are stored in a database that has been previously set up with a JDBC
connection pool, which is identified by the pool-name element. The table-name and
attribute-map elements map the EJB fields to the appropriate table columns in the
database.

Finder descriptors are the WLE implementation of the EJB find methods. The finder-
descriptor elements are pairs of method signatures and expressions. You specify a
method signature in the EJBHome interface, and you specify the method's expression in
the deployment descriptor via the query-grammar element. The finder methods return an
enumeration of EJBs. For more information about specifying finder descriptors, see the
EJB XML Reference in the WebLogic Enterprise online documentation.

Example

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 28

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

The following WebLogic EJB extensions to the deployment descriptor DTD fragment
specify automatic saving using JDBC persistence of two fields of an entity bean
(accountId and salary ) to a database table (emp ) using a connection pool (pool1 ),
shown in boldface type:

<weblogic-ejb-extensions>
<weblogic-version>
WebLogic Enterprise Server 5.0
</weblogic-version>
<weblogic-enterprise-bean>
<ejb-name>
oracle
</ejb-name>
<weblogic-deployment-params>

<max-beans-in-free-pool>
20
</max-beans-in-free-pool>
<max-beans-in-cache>
1000
</max-beans-in-cache>
<idle-timeout-seconds>
5
</idle-timeout-seconds>
<!-- JNDI name that is associated with this EJB;used for lookup -->
<jndi-name>
oracle.OracleHome
</jndi-name>

<!-- This is CMP EJB. Specify persistence information -->

<persistence-store-descriptor>

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 29

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

<persistence-store-jdbc>
<!-- Pool name is looked up by the EJB source -->
<pool-name>
jdbc/pool1
</pool-name>
<!-- *** DATABASE INFORMATION SPECIFIC TO
INSTALLATION SITE *** -->
<!-- Default user URL is for Oracle 8i-->
<user>
scott
</user>

<!-- Default password URL is for Oracle 8i-->

<password>
tiger
</password>
<!-- Default driver URL is for Oracle 8i,
and default instance Beq-Local is used
-->
<driver-url>
jdbc:weblogic:oracle:Beq-Local
</driver-url>
<table-name>
emp
</table-name>

<!-- CMP Fields and database table column mapping-->

<attribute-map>
<attribute-map-entry>
<bean-field-name>
accountId

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 30

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

</bean-field-name>
<table-column-name>
empno
</table-column-name>
</attribute-map-entry>
<attribute-map-entry>
<bean-field-name>
salary
</bean-field-name>
<table-column-name>
sal
</table-column-name>
</attribute-map-entry>
</attribute-map>

<!-- Finder Specifications -->

<finder-descriptor>
<method>
<ejb-name>
oracle
</ejb-name>
<method-name>
findAccount(double salaryEqual)
</method-name>
</method>
<query-grammar>
(= salary $salaryEqual)
</query-grammar>
</finder-descriptor>
</persistence-store-jdbc>
</persistence-store-descriptor>

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 31

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

</weblogic-deployment-params>
</weblogic-enterprise-bean>
</weblogic-ejb-extensions>
For more information about JDBC connections, see Using the JDBC Drivers in the
WebLogic Enterprise online documentation.

Step 4: Produce the deployable EJB JAR file.

In this step, you package the deployment descriptor, the compiled files for the EJB
classes, the WLE extensions to the deployment descriptor DTD, and any additional
required classes into a deployable EJB JAR file. You can do this using the ejbc
command, as in the following example:

java com.beasys.ejb.utils.ejbc -validate -i DDfile -x WLEXfile archive-file

The ejbc command performs the following steps:

1. Parses the standard EJB deployment descriptor and WebLogic Enterprise

extended deployment descriptor XML files, which are represented, respectively,
as DDfile and WLEXfile in the preceding command.
2. Checks the deployment descriptors for semantic consistency, and writes any
inconsistencies to standard output.
3. Generates the wrapper Java classes and compiles them. This is performed for each
EJB in the deployment descriptor.
4. Packages the XML deployment descriptors and the generated class files into a
deployable EJB JAR file. The command-line argument archive-files specifies the
files that are archived into the EJB JAR file.

If you have multiple bean packages meant to be assembled as a deployable unit, the bean
packages must be specified in a single deployment descriptor. For more information
about the ejbc command, see the Command Reference in the WebLogic Enterprise online
documentation.

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 32

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

Step 5: Configure the EJB application.

In the SERVERS section of the UBBCONFIG file, the administrator uses the
MODULES keyword to identify the deployed EJB JAR files. Optionally, a related set of
startup arguments can be specified for each EJB JAR file. For information about
configuring the EJB container, configuring the WLE EJB server process, and specifying
values in the UBBCONFIG file, see Creating a Configuration File in the WebLogic
Enterprise online documentation.

Step 6: Specify the module initializer object in the WebLogic EJB extensions to the
deployment descriptor DTD.
Server application startup and shutdown can be handled automatically by the EJB
container. However, if you have special server initialization or shutdown requirements,
you need to implement an application entity called the module initializer object.

The module initializer object implements operations that execute the following tasks:

• Performing basic module initialization (or EJB JAR file deployment) operations,
which may include allocating resources needed by the EJB JAR file.
• Performing basic server application initialization operations, which may include
registering homes or factories managed by the server application and allocating
resources needed by the server application.
• Performing server process shutdown and cleanup procedures when the server
application has finished servicing requests.

Note: For EJBs, the scope of the module initializer object is at the EJB JAR file
level and not of the entire server application, as with the Server object and WLE
CORBA applications.

EJB Roles

An interesting feature of the EJB Specification is that its requirements are largely
divided into different 'roles.' When reading the Specification, it is therefore quite clear to
whom the various requirements correspond.
CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 33
DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

 Component provider

The component provider [EJB2.0 25.1] is a software developer who authors

EJBs. These EJBs may be destined for a particular application, or they may be general-
purpose or part of a software library. The EJB author may not know the names of the
EJBs with which it is to interact although, of course, their method specifications must be
known. Similarly, the EJB author may not know the names of external resources like
databases.

The Specification indicates how the component provider uses the XML deployment
descriptor to indicate that these EJBs and resources are required, and the names by which
it has referenced them.

 Application assembler

The application assembler [EJB2.0 25.2] is someone who builds an application

out of component EJBs. The same person or people may be operating in this role as are
fulfilling the component provider role, but the Specification is quite clear that the two are
distinct jobs. The application assembler resolves references between EJBs, unifies the

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 34

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

references to external resources, and packages the components into a single file ready for
deployment.

It is slightly confusing for the newcomer to EJB development that most of the
graphical tools used for building EJB applications don't distinguish between what they
are doing in the provider role versus in the assembler role. It often appears that the
developer is supplying redundant information or information that is duplicated; this is
because the deployment descriptor being built does support the notion of a separate
provider and assembler, even if they are in practice the same person.

 Deployer

The deployer [EJB2.0 25.3] takes a file from the application assembler that
contains the EJBs and other components required for the application and installs it on the
server, making appropriate customizations for the site.

These customizations include replacing database references with real database

information, mapping the security roles in the application onto real users and groups in
the organization, and supplying values for other configuration parameters.

 Server vendor

The server vendor supplies EJB server products. An EJB developer should not
assume that the sections in the EJB Specification that deal with the responsibilities of the
server vendor are not of interest. On the contrary: The server sets the operating
environment of the EJB, and this section of the EJB Specification gives the developer an
insight into what environment the EJB can expect.

 Administrator

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 35

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

An administrator [EJB2.0 25.4] is a person responsible for the maintenance and

performance tuning of an application.

 Tool provider

A tool provider authors EJB packaging and deployment tools.

2 Marks Questions & Answers

1. What is an Enterprise JavaBean?
An enterprise bean or Enterprise JavaBean (EJB) is a self-contained,
reusable component that has data members, properties, and methods.
2. What is the logical architecture of an EJB?
An EJB system is logically a three-tier system. The three tiers are:
a) The client
b) The EJB server
c) The database(or other persistent store)
This structure is a logical architecture because the three tiers don’t necessarily
have to reside on three different machines.
3. Mention the role of EJB in each tier.
EJB’s role in each of these tiers is:
a) A program on the client side makes calls to remote EJBs
# The client needs to know how to find the EJB server and how to interact
with the objects that reside on the EJB server.
b) The EJB components live in the middle tier
# The EJB objects reside inside an EJB container, which in turn resides in
an EJB server.
c) The underlying database resides in the third tier
# EJB beans can access the database themselves, via Java Database
Connectivity (JDBC).
4. What are the key features of the EJB architecture?

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 36

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

It illustrates several key features of the EJB Architecture:

 The EJB bean exists within the container
 The client never communicates directly with the EJB bean
 The EJB server does not take part in the logical conversation
between client and EJB bean

5. Define EJB server.

The EJB server is a “container” – it contains the EJB container. This
server is responsible for providing the container with lower-level services such as
network connectivity.
6. What is the role of an EJB container?
An EJB container is an environment in which Enterprise JavaBeans
Execute. Its primary role is to server as a buffer between an EJB and the outside
world.
7. What are the services provided by an EJB container?
The container is also responsible for providing the beans with services, so
that the bean can remain blissfully unaware of the underlying mechanisms used in
implementing these services. These services are:
 Support for transactions
 Support for persistence
 Support for management of multiple instances
 Support for security
8. List out the modes of transaction management.
EJB provides six modes of transaction management
 TX_NOT_SUPPRTED
 TX_BEAN_MANAGED
 TX_REQUIRED
 TX_SUPPORTS
 TX_REQUIRES_NEW

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 37

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

 TX_MANDATORY
9. What are the various tasks performed by server?
a) Instance passivation
b) Instance pooling
c) Database connection pooling
d) Pre-cached instances
e) Optimized method invocations

10. Define Instance passivation.

It is the temporary swapping of an EJB bean out to storage. If a container
needs resources, it may choose to temporarily swap out a bean. Both session bean
and entity bean can be passivated.
11. Define instance pooling.
It means that the container shares instances of EJB beans among multiple
clients. It allows the EJB container to initiate fewer copies of a given bean to
service requests.
12. What is database connection pooling?
When a component wishes t o access a database, it does not create a new
database connection; in stead, it simply grabs a connection from a pool of
available connections.
13. List out the benefits of database connection pooling.
 It avoids the overhead of stabling a new database connection.
 Maintaining an open database connect ion consumes resources
on the database. Connection pooling allows a system manager to
provide an application with the resources it needs, without
crating unnecessary overhead on the database.
14. Define pre-cached instances.
It may be used when an EJB needs to load some state information from a
database when it is created.
15. What is an optimized method invocation?

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 38

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

They are employed to prevent overhead costs associated with remote

invocation. Whether the client of an EJB is a remote client or another EJB in the
same container, the APIs used to gain access to it are always the same.
16. Define persistence.
Persistence means that the state of an object is saved to some sort of
permanent storage (a file or a database), allowing the object to be read in and used
at later time instead of being recreated each time.

17. What is an ACL?

The main mechanism used in EJB security is the Access Control List
(ACL). An ACL is a list of persons or groups that are allowed to access particular
pieces of functionality. A deployer can specify ACLs for a bean as a whole as
well as for any of the bean’s methods.
18. What are the difference between Enterprise JavaBeans and JavaBeans?
Enterprise JavaBeans:
 EJBs need a container
 EJBs are deployable components
 EJBs are assembled to form a complete Application
 EJBs are base don RMI IIOP and JNDI technologies
JavaBeans:
 JBs don not need a container
 JBs are development components
 JBs are classes with no argument constructor
 JBs have a get and a set method on them
19. When to use EJB?
If any of these requirements hold for your application
 The application must be scalable and distributable
 Transactions will be required to ensure data integrity
 The application will have a variety of clients.
20. What are the benefits of EJB?

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 39

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

Benefits of using EJBs are as follows:

 Independence from database schema
 Transaction management
 Platform independence
 Scalable environment
 Secure access
 Multi tier architecture

21. What are the characteristics of EJB?

 Hides server-side system level issues from developers
 Defines a standard component architecture that enables you to
build distributed object-oriented business applications
 Facilitates creating enterprise-level applications by allowing easy
integrating with other EJB components as well as with other
components, such as servlets, Java Server Pages (JSP), and Java
Beans
 Enables you to create components and applications that are
reusable across various J2EE-compliant servers

22. What are the various APIs provided by the EJB container?
Various APIs provided by the EJB container are:
 Java Platform, Standard Edition, (J2SE) APIs
 EJB Standard Extension
 JDBC Standard Extension
 JNDI Standard Extension
 JMS Standard Extension
 JavaMail Standard Extension (for sending mail only)
 JAXP
 JTA Standard Extension (Only User Transaction interface)

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 40

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

23. What are the roles and responsibilities of EJB?

 Bean provider
 Application assembler
 EJB deployer
 EJB server provider
 EJB container provider
 System administrator

24. What are the various components of EJB architecture?

Various components of EJB architecture are:
 EJB Container: Provides the runtime environment for the EJB
components and services, such as life cycle management,
connection pooling, and security.
 EJB Component: Java classes that follow the EJB specification
to implement the business logic of an application. EJB
components are deployed in EJB container and are accessed
using the remote and home interfaces of an enterprise bean.
 EJB Object: EJB container generates an EJB object, when a
client needs to access an instance of the enterprise bean. The EJB
object acts as an interface between the client and bean instances.
 Home Object: Home objects are generated by EJB container.
Clients access EJB objects that are stored at different Java
Virtual Machines (JVM), using the home object.
 Home Interface: It declares the various life cycle methods that
involve operations, such as creating, finding, and removing
enterprise beans
 Local Interfaces: These are used when the enterprise bean and
the client are stored in the same JVM

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 41

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

25. What are the types of EJB?

 Session beans
 Entity beans
 Message-driven beans

26. Draw the diagram for EJB architecture.

27. Draw diagram for various EJB roles and their interaction.

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 42

DEPT OF MCA / MC503/ MIDDLEWARE TECHNOLOGIES/ UNIT – 2

CHETTINAD COLLEGE OF ENGG AND TECHNOLOGY 43