EJB Architecture

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. Every EJB has three classes:
1. A home interface which acts as a factory of remote objects.
2. A remote object which is used for client interaction
3. A bean object which contains all the business logic

Remote client view:

Its specification is available only in EJB 2.0 and an enterprise bean remote client view is
location independent.
Remote interface:
It specifies the remote business methods that a client can call on an enterprise bean.
Remote home interface. It specifies the methods used by remote clients for locating, creating,
and removing instances of the enterprise bean classes.
Local client view:
Its specification is only available in EJB 2.0 and the local client view of a bean is location
dependent, unlike the remote client view.
1. Local interface:
It 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.
2. Local home interface:
The local home interface specifies the methods used by local clients for locating, creating, and
removing instances of enterprise bean classes.

EJB client JAR file:

An EJB client JAR file is an optional JAR file that can contain all the class files that a client
program needs to use the client view of the enterprise beans that are contained in the EJB JAR
file. If you decide not to create a client JAR file for an EJB module, all of the client interface
classes will be in the EJB JAR file.
EJB container:
An EJB container is a run-time environment that manages one or more enterprise beans.
It manages the life cycles of enterprise bean objects, coordinates distributed transactions and
implements object security.
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 run-time environment to
support the execution of server applications that use enterprise beans.
An EJB server provides a JNDI-accessible naming service.
It manages and coordinates the allocation of resources to client applications, provides access
to system resources and provides a transaction service.

Difference between EJB and Java beans

Java Beans:
Java beans are reusable components that can be used for customized user objects.
Java beans adhere to two methods known as setter and getter methods and one public
constructor. For example: an employee object can be used to set (setter method) and get
(getter method) employee details which are a customized object.
AWT and Swing components are based on java beans.

Enterprise Java Beans (EJB):

EJB are reusable components that are developed to comply with enterprise specification
adhering to setter and getter methods and one public constructor.
These beans are running in an EJB container of J2EE architecture.

What’s new in the EJB 2.0 specification?

Asynchronous Messaging:
It allows the development of loosely-connected systems.
These systems are typically more resilient in the event of failures, and more easily extensible
as new applications are developed.

The integration of JMS and EJB:

It allows enterprise beans to participate fully in loosely connected systems.
Through this integration, message-driven beans can receive and act upon JMS messages,
without the involvement (or existence) of an application client user interface.

Local interfaces:
They improve the efficiency of intra-container entity relationships.

Container-managed relationships:
In these, the container manages object relationships between entity beans.

Changes to EJB QL:

A query language for portable EJB finder methods. Enhancements to the interfaces of
Message-Driven Beans (MDBs), as well as to the home interfaces of remote entity beans.

Inter-Server Interoperability:
It enables heterogeneous environments.

Enterprise Bean Environment

- The enterprise bean environment is a mechanism that allows the enterprise bean’s business
logic at the time of assembling it or deploying it.
- The environment provides to the beans to refer to a value, a resource or another component.
- The values that are described in the deployment descriptor are the actual values of the
environment refers to the deployment time.
- This environment customizes the bean without accessing, changing the bean’s source code.
- The EJ environment is provided by the container to the bean through JNDI interface.
- Using JNDI the bean code access the environment.
EJB environment Entries.
EJB environment entries :
- The most important role is being played by EJB environment entries to make the beans
flexible.
- This topic is worthwhile even for the beginners. Within the EJB environment, it is possible
to create the entries, called ‘named value entries’ of the type Byte, Short, Integer, Long, Float
and String types.
- The bean deployer can use there references, to modify the business logic of the beans
without altering the underlying code.
- This is a very powerful technique when properly used / utilized / applied.
- EJB environment entries are much like a constant variables whose scope is within a
particular EJB.
- These are setup in the deployment descriptor, and can be overridden in the deployment plan.

Rules to use EJB Environment entries :

1. Deployment descriptor only must set up these references.
2. The values can overridden at deployment time, provided these values are set at assembly
time.
3. The instances of that particular bean deployment only can access these environment
entities.
4. At the time of deploying the bean for multiple times on the same server, the environment
entries can also have the same name. But there are chances of risk.
5. At runtime, the values of the environment references can not be changed.

Steps involved in accessing one enterprise bean from other.

- The accessibility of one EJB within another, there is a special mechanism is provided by the
container.
- Using the logical names called ’EJB references’, this mechanism can be referred.
- These references should be defined in the deployment descriptor which is then used by the
container in order to construct the EJB environment.
- The binding the EJB references is used in the EJB code to the homes of other EJB which is
need to access is done by the deployment descriptor.
- A local interface should be used to implement the mechanism.
- The sequence of the steps for accessing one EJB from another are as follows :
1. Specifying a local reference for a bean.
2. The deployment descriptor elements for a local reference mirror exactly the elements for a
remote reference.
3. Creating a local interface and accessing a bean through it.
- To specify the home interface and local interface , the following steps are to be followed.
1. Specifying the Home Interface:
- import "javax.ejb.EJBLocalHome" rather than "javax.ejb.EJBHome", to create the home
interface.
- The only exception that must be thrown by methods declared in this interface is:
javax.ejb.CreateException

2. Specifying the Local Interface :

- import "javax.ejb.EJBLocalObject" rather than "javax.ejb.EJBObject".
3. Making the Call :
- After creating local and home interfaces and specifying the deployment descriptor settings,
the JNDI call to lookup to the references of the other EJB is the remaining process.
- For example :
- The following code snippet provides the call:

home = (ProductHome) initCtx.lookup("java:comp/env/ejb/Product");

EJB client JAR file

An EJB client JAR file is an optional JAR file that can contain all the class files that a client
program needs to use the client view of the enterprise beans that are contained in the EJB JAR
file. If you decide not to create a client JAR file for an EJB module, all of the client interface
classes will be in the EJB JAR file.
Deployment descriptor
Deployment Descriptor is an XML document with .xml extension. It basically describes the
deployment settings of an application or module or the component.
At runtime J2EE server reads the deployment descriptor and understands it and then acts upon
the component or module based the information mentioned in descriptor.
For example EJB module has a deployment descriptor ejb-jar.xml where we mention whether
it is session or entity or message driven bean and where the Bean classes located are and what
type of transaction etc.
In a simple word, without deployment descriptor the Container (EJB/Servlet/JSP container)
will not know what to do with that module.
A deployment descriptor is a file that defines the following kinds of information:
EJB structural information, such as the EJB name, class, home and remote interfaces, bean
type (session or entity), environment entries, resource factory references, EJB references,
security role references, as well as additional information based on the bean type.
Application assembly information, such as EJB references, security roles, security role
references, method permissions, and container transaction attributes.
Specifying assembly descriptor information is an optional task that an application assembler
performs

EJB Invocation
Steps to EJB invocation are:
Retrieve Home Object reference from Naming Service via JNDI.
Return Home Object reference to the client.
Create a new EJB Object through Home Object interface.
Create EJB Object from the EJB Object.
Return EJB Object reference to the client.
Invoke business method using EJB Object reference.
Delegate request to Bean (Enterprise Bean).
EJB Context?
EJBContext is an interface. This is implemented by the EJB container. This is also a part of
bean-container contract. The subclass of EJBContext called EntityContext is used by entity
beans. The bean class gets information about the container, client using the bean and the bean
itself from the EJBContext objects.

Difference between session context and entity context5

Information like the current bean status, security credentials of the user is available in the EJB
container. This information is available in one object called EJBContext object.
The information that a Session Bean needs from the EJB container is obtained using Session
Context.
The information that an Entity Bean needs from the EJB container is obtained using Entity
Context.

Remote client view in EJB 2.0?

The remote client view is location independent of a bean.
A client running as a bean instance in the same JVM uses the same API to access the bean as
another client running in a different JVM on the same or different machine.
It provides the location transparency.

Local client view in EJB 2.0

Unlike the remote client view, the local client view is location dependent of a bean.
To access an enterprise bean by local client view, it is required both the remote client and the
enterprise bean which provides the view of local client view in the same JVM.
Thus, the Local Client View does not provide location transparency provided by the remote
client view.

Difference between ejbCreate() and ejbPostCreate()

Only ejbCreate() is available to Session Bean and Message Driven Bean.
Both ejbCreate() and ejbPostCreate() are available for Entity Bean. ejbPostCreate() returns
void and has the same parameters as that of ejbCreate(). To set a relationship field to initialize
the bean instance, ejbPostCreate() is used and is not supported in the ejbCreate() method. Any
post-create processing is needed before serving the client request, the ejbPostCreate( ) method
allows this designated process.

Difference between find and select methods in EJB

select() method: 1. A persistent field of a related entity bean is returned by select() method. It
is defined in Entity Bean class.
2. A select() method can not be invoked by a client, because the method is not exposed in
local or remote interfaces.
3. It can only be invoked by the methods that are within the Entity Bean class.

finder() method:
1. A finder method can retrieve multiple entity beans for the storage persistence.
2. A finder method can return only a local or remote interface or a collection of interfaces.
3. A finder method is defined in the Entity Bean class for Bean-Managed Persistence and not
defined in the Container-Managed Persistence.

Different types of EJB – Session beans, Entity beans and

Message-driven beans.
Session Bean:
The client’s business logic is implemented by a session bean of EJB.
For example a session bean can calculate interest on deposits for a banking application.
Session beans are used as reusable components in EJB architecture that encapsulate the
business logic and can be used by other clients. These clients can optimize the use of EJB
container.
The name is derived as they are live as long as a client’s session using them.

Entity Bean:
It is a data component that persists data onto a secondary storage such as a database.
Like a simple java class, the Entity Bean has attributes and methods. Attributes are used to
store data and methods are to perform operations on the fields.
Entity beans can be viewed as a record in a database. An Entity Bean lasts as long as the data
it represents.

Message-Driven Bean:
A Message-Driven Bean is an enterprise bean that is used to manage messages
asynchronously. It acts as a listener to receive messages. The message can be sent by using
any J2EE component-application client, another enterprise bean, a web component or by a
JMS application.

Clients do not access the message driven beans through interfaces. Message Driven Beans are
primarily focused on JMS. It is possible to get messages by multiple parties.

Explain types of session beans – stateless, stateful.

Stateless session bean:
The stateless session bean does not hold a conversational state of the client.
When a client invokes a method of this bean, the bean’s instance variables may contain a
state, but only for the invocation period.
When the method execution is completed, the state will be lost.

Stateful session bean :

Stateful session bean is associated with a single client.
The EJB container always uses the same stateful session bean instance to service a given
client.
The stateful session bean retains the data retrieved by the client from the database.

Types of Entity beans – Container-managed persistence (CMP)

and Bean-managed persistence (BMP).
Container-Managed Persistence:
When the entity object represents the persistence services, the Container-Managed
Persistence (CMP) occurs.
The persistence state of the bean is transparently and implicitly managed by the EJB container
with the CMP.
There is no deed to hardcode in order to access the database within the enterprise bean class.

Bean-Managed Persistence:
Compared to CMP, Bean-Managed Persistence is complicated.
The reason behind is to hardcode to persistence logic in the bean class.
In order to hardcode the persistence logic, the enterprise developer need to know the type of
database and also the way of the bean class fields maps to that of the database.
BMP provides more flexibility in managing the state between bean class fields to the
database.

Relationship between local interfaces and container-managed?

In case of Container-Managed Relationship is the target of an entity bean, there is a
mandatory need of local interfaces. The direction of the relationship determines the target of
a bean.
The relationships can be one-to-one, one-to-many and many to many.
The EJB container capable of managing these relationships with the help of referential
integrity.
These relationships are defined between local interfaces, which means a relationship cannot
be created between two entities in separate applications, even in the same application server.
The Container-Managed Relationship must reside in the same EJB JAR file because the
access / interface to the beans is local.
With this locality, increased performance is an advantage, because the access to local calls is
faster that the remote calls.

When should I adopt BMP and when I should use CMP

Adopting BMP:
BMP should be used when the associations are complex between database tables. BMP is
very useful when the entity beans require the synchronization with flat files.BMP would only
be the right way, if entity beans synchronization is applied to multiple types of stores.
Adopting CMP:
CMP can be used in order to support only relational database. CMP is used when there is a
need of special-beans, such as multi-tables, which cannot be completely realized with a single
bean.
Apart from the normal persistence, where the performance is an issue, use CMP instead of
BMP

Roles of EJB specification that are involved in the development

and deployment of EJB application.
Each or all roles can be performed at once or at different levels by an individual or an
organization
Bean Provider:
A bean provider is an EJB developer ( provides beans by developing) who has to be familiar
with the business logic for an enterprise application.
Application Assembler:
In an EJB application, several beans are developed by the bean developers. The role of an
application assembler is to assemble all the beans that are developed by the application
assemblers. He also writes the deployment descriptor.
Deployed:
The deployed is one whose responsibility is to deploy the EJB application in a particular EJB
container(s). His inputs are enterprise beans and deployment descriptors from bean developers
and application assemblers. He needs to be expertise the functionality of the EJB container.

System Administrator:
The system administrator is responsible to maintain the deployed EJB applications very
frequently. He has to see that the EJBs run 24x7 environment without any interruption
including the restart of a server in case of its crash. In addition to these, he is also responsible
to maintain the security of the users.
EJB Server Provider:
The EJB Server Provider provides the EJB server that hosts the EJB container. Most of the
EJB containers are packaged with the EJB Servers.
EJB Container Provider:
The EJB container provider provides the resources to write an EJB container and conforms
that the software is on par to the EJB specifications. He should also provide the required
softwares and tools to the administrator in order to administer the EJB applications.

What are the advantages of EJB model?

1. The development of EJB applications is easy as the business logic is separated by the
application developer and at the same time the developer can utilize the services of the EJB
container.
2. EJB are components, where the EJB vendors vend these components which encapsulate the
functionality according to the need. Application development made easy as the EJB
specification ensures the usability of beans developed by others can also be used in a specific
application.
3. The isolation of labor in developing, deploying, administering, providers made it faster to
develop an EJB application.
4. The major operations of managing transactions, state, multithreading, connection pooling
etc. will be managed by the EJB container. The security is also provided by the EJB container.
5. The EJB architecture is compatible with other APIs like servlets and JSPs.

Limitations of EJB models

1. The no file I/O is a security concern. By loading files using Class.getResource() and
bundling non-EJB config files with EJB-jar.

2. While mapping a CMP bean with SQL Server database, a field of float type need to be
mapped with database column of type FLOAT only, not for REAL.
3. A table which has a multi-column primary key and one or more foreign keys which share
any one of the primary key columns, then the foreign keys must contain columns which are
not of primary key or exactly the same primary key columns.
4. For Example: the two columns that comprises a primary key are A and B. Then the
columns that comprises a foreign key are column A and column B or column C and column
D, but certainly not column A and column D or column B and column C or column A and
column C or column B and D.
5.While using root-leaf approach in order to map inheritance, the foreign-key constraints are
to be removed from the database for avoiding referential integrity related issues. The same
process is to be followed while using secondary maps with multiple tables.

Session beans and types of session beans.

Session Bean:
The client’s business logic is implemented by a session bean of EJB. For example a session
bean can calculate interest on deposits for a banking application. Session beans are used as
reusable components in EJB architecture that encapsulate the business logic and can be used
by other clients. These clients can optimize the use of EJB container. The name is derived as
they are live as long as a client’s session using them.
There are two types of session beans:
1. Stateless session beans
2. Stateful session beans.

1. Stateless session bean :

The stateless session bean does not hold a conversational state of the client. When a client
invokes a method of this bean, the bean’s instance variables may contain a state, but only for
the invocation period. When the method execution is completed, the state will be lost.

2. Stateful session bean :

Stateful session bean is associated with a single client. The EJB container always uses the
same stateful session bean instance to service a given client. The stateful session bean retains
the data retrieved by the client from the database.

Steps involved in developing a stateless session bean?

1. Defining Home Interface
2. Defining Remote Interface
3. Developing the EJB class
4. Authoring deployment descriptors
5. Package the application
6. Deploy the application in the EJB container
7. Test the application

Describe the lifecycle of stateless session beans.

The life cycle of the stateless session bean starts when the client first obtains the reference of
the session bean. Before invoking the annotated @PreConstruct method, the container
performs the dependency injection. After this process, the bean allows the client to invoke its
methods.
At the end of the life cycle of the session bean the container calls the annotated
@PreConstruct method, followed by the garbage collection of the bean.

Steps involved in developing a stateful session beans?

The following are the steps involved in developing the Stateful Session Bean:
1. Defining Home Interface
2. Defining Remote Interface
3. Developing the EJB class
4. Authoring deployment descriptors
5. Package the application
6. Deploy the application in the EJB container
7. Test the application

Lifecycle of stateful session beans.

First the client gets the reference of a stateful session bean. Then the stateful session bean
starts its life cycle. The container performs dependency injection before invoking the
annotated method @PostConstruct. Then the bean is ready. The bean may be deactivated
while in the ready state by the container.
The bean moves from memory to secondary memory in the passivate mechanism. Then the
annotated method @PostPassivate is invoked by the container before passivating the bean.
The container invokes the annotated @PostActivate method, if a client invokes a business
method on the passivated bean.
The client invokes the annotated @Remove method just before ending the life cycle of this
bean.
Following this action, the container invokes the annotated @PreDestroy method. This results
in making the bean ready for garbage collection.

Steps involved in deploying a session bean.

Installing an Enterprise JavaBeans Server.
2. Specifying the Enterprise JavaBeans Remote Interface.
3. Specifying the Home Interface.
4. Authoring the Enterprise Java Bean Class.
5. Creation of the ejb-jar File.
6. Deployment of the Session Bean in Enterprise JavaBeans container.
7. Authoring the Enterprise Java Bean Client.
8. Running the Client.

Entity bean
Entity beans are objects that represents a persistence storage mechanism. The objects can be a
customer, product, account etc. Each entity bean has underlying table in a relational database
and each row in the table represents the instance of the bean.
Need of entity beans:
1. When it is needed by multiple clients.
2. When any action from the database side.
3. When a transaction is to be performed from the client.
4. When the enforcement of accuracy and integrity is needed.

Types of Entity bean and their uses.

There are two types of entity beans.:
1. Container Managed Persistence (CMP)
2. Bean Managed Persistence (BMP)
CMP can be used when:
No code for database code is needed(by placing the specific accessibility is provided by
XMLfile). The code reusability is needed. The speed of development by creation of the
database access code by the developers.

BMP can be used when:

Synchronizing the state of the database directly by the container. To provide the flexibility for
the bean developer to perform the persistence operations. The needs of the query exceeds the
capabilities of EJB QL. The persistent storage is a non-database system or is a legacy
database system that does not supports for CMP.

Steps involved in developing Entity beans.

1. Select which bean is to be used – BMP or CMP entity bean
2. Create the required entity bean.
3. Author the source code for the entity bean, which involves developing the following:

a. The component interface(s)

b. The home interface(s)

c. The bean class

d. Any helper classes required by the entity bean
4. Develop the deployment descriptors for the beans.
5. Create the database tables. (If your database tables already exist, you can omit this step)
6. Establish the Object Relation mapping.
7. Compile and archive all the EJB components into a JAR file.
8. Archive the complete application into an EAR file.
9. Make the deployment of the application onto the J2EE engine.
10. Start the application.

Steps involved in deployment of CMP and BMP entity beans.

The purpose of deployment of entity bean is to make them available for the client
applications.
Requirements before deploying:

1. Author and compile the various entity beans that are to be deployed. This includes bean
class, remote interfaces, home interfaces, and the primary key class, if required.
2. Get the mapping done for the entity beans for the appropriate database tables and save the
mapping information that is a deployable XML file.
3. Assemble the entity beans into a .jar or .ear file

Steps involved in deployment of entity beans:

There are three steps in deploying the entity beans.

1. Configuration:
Specifying the number of properties for the bean. The usage of persistence mechanism and
the needed information to do so.
2. Code generation:

The information from the configuration phase is used by the different tools to generate the
classes for the required beans. This process may include helper classes related to transactions,
persistence, and security.The implementations of EJBHome and EJBObject, and the stubs and
skeletons required for RMI-IIOP.

3. Installation:
The EJB server is started and make the beans available to the client’s applications.

Lifecycle of the entity beans.

The time when the entity bean starts instantiating and till it takes the time for garbage
collection is the life cycle of an entity bean.
The life cycle has three states, namely
1. Does not exist state
2. Pooled state
3. Ready state

1. Does not Exist State:

- The life of a bean’s instance starts with a set of files. These files include remote interface,
interface, deployment descriptor, primary key and the needed files at the time of deployment.
- In this state, no instances of the bean exists.

2. Pooled State:

- At the time of starting the EJB server,with the help of the method Class.newInstance() , all
the instances are created and placed in a pool. The default values of the persistent fields are
set. The bean class should never contain the constructor. Therefore the default no-argument
must be available in the container.

- Before placing the instances in the pool, an instance EntityContext is assigned by the
container which assigns and implements the setEntityContext() method by the bean class,
followed by entering into the instance pool.

- Now the bean instance is available for the client requests and become active soon after
receiving the requests. The bean container provides different levels of access at every stage of
the bean’s life cycle.

3. The Ready State:

- Once the bean reaches this state, it can accept the requests from the client. The state of a
beans instance reaches to ready state once the container assigns it to an EJB object.

- This assignment occurs in two different circumstances:

1. When the new entity bean is being created.

2. When the container is activating an entity bean.

4. End of the Life Cycle :

- The life of a bean’s instance comes to an end when the container decides to remove it from
the pool and allows it to be garbage collected.
- This may happen when the container decides to reduce the number of instances from the
pool in order to conserve the resources. So that the highest performance can be achieved.

Advantages of EJB 2.0 container-managed persistence over

bean-managed persistence.
- The main advantage of CMP over BMP is that with CMP, is the developers hardly need to
author the code for data access. Considering less code implies very less chances of getting
wrong results and supporting less problems if there are multiple databases.

- The sorting mechanism is not supported in EJB QL. Reason is EJB QL does not support
ORDER BY clause. The sorting can be done after retrieving data and can be simplified by
using the Java collections framework (sort() method ).

- To be simple and clear, the CMP is being performed by the container which needs almost no
hard coding.

- While implementing the beans the complexity is reduced and all the finder methods are
implemented by the container.

Types and role of abstract methods in EJB 2.0 persistence.

- In EJB 2.0 a CMP bean is defined as abstract. The CMPs persistence fields are not directly
defined in the bean class.
- Instead, a schema named ‘abstracted persistent schema’ has developed. This schema lets the
bean provider declare the relationships and the persistent fields indirectly.
- The deployment descriptor contains the container-managed fields and relationships declared
in the abstract persistence schema.
- The logic for the BMP beans that access the database based on object-to-relational mapping
information is provided by the bean developer.
- The following are two declarations of the inheritance hierarchy of a bean class:
1. Bean Developer’s Abstract Class implements javax.ejb.EntityBean.
2. Persistence Manager’s Concrete Bean Class extends Bean Developer’s Abstract Class.

EJB query language.

- EJB query language is used to perform the database operations using finder and select
methods of entity beans.
- The EJB QL, is used to define queries for CMP beans.
- The Bean Provider specifies the finder methods by the EJB QL in a portable way.
- The responsibility for the execution of finder queries that are need to be shifted to the native
query language facilities which the persistent store, RDBMS provides.
- The queries for the finder and select methods of entity beans are defined by EJB Query
Language with Container-Managed Persistence of entity beans.
- EJB QL queries find data using the "abstract schema" of the enterprise beans in your
application.

Callback methods in Entity beans

- In order to notify the events of a bean in the lifecycle, a bean class implements a set of
methods, called callback methods.
- The entity bean implements the callback methods which are defined in the
javax.ejb.EntityBean interface of EJB API.
- These methods are as follows:

public void setEntityContext() :

- It provides the bean with an interface to the EntityContext container.
- The EntityContext interface is used to obtain security information about the caller, to
determine the status of the transaction or to force the transaction to rollback.
unsetEntityContext() :
- Used at the end of the life cycle of the bean and before the instance is evicted from the
memory in order to perform the last minute clean-up.
ejbStore() and ejbUnload() :
- To know the entity bean’s state at the time synchronizing with the database.
ejbPassivate() and ejbActivate() :
- These both methods are invoked for the bean by the container just before the bean is
passivated and after bean is activated respectively.
- Passivation specifies that the disassociation of the bean instance with its remote reference, so
that the container evict it from memory or reuse it ejbRemove(); will be invoked just before
the bean destroys the bean’s instance.
 Explain the structure of EJB query language (EJB QL)
Structure of EJB QL:
- The EJB QL structure comprises of the following:
1. SELECT clause
- SELECT clause returns the values to the EJB QL. The value can be an entity bean, attribute
or a simple java object.

1. FROM clause:
- FROM clause specifies the scope of the query. The scope is a the identification variables.
- In order to a valid query every query must contain the FROM clause. There are two
components in the FROM clause :
FROM {AbstractSchemaName entityBeanVariable}
AbstractSchemaName is the specification of an alias name for an entity bean using the tag
<abstract-schema-name> in the ejb-jar.xml file.
Using IN : The IN keyword designate a set of data collection for the preceding identifier to
evaluate.
Using AND: The AND clause is used to combine logical expressions in the query.
Using AS: The AS clause is used to designate an identifier as the rest of the query.
3. WHERE clause:
- WHERE clause specifies the conditional selection for the query which results in restricted
values in the query. This clause is optional.

Explain the role that callbacks play in developing Entity beans

with container-managed persistence.
- The following are EJB callbacks along with pros and cons:
Magic callbacks :
- The container defined method is same.
For example: public void ejbPassivate();
- Template code, base class, interface dependency are not available and very lightweight.
Won’t express the container dependency and easily breakable such as the typos by the
developers.
Interface:
- The expression is clearly depended and no breakages.
- Coding template is a lot.
Base class:
- Template code availability in base class. Extendibility by the developers.

- No template code, not breakable.

- Single inheritance in java makes this base class.
Annotations :
- Method annotations as callback.
- Non code template , not breakable (annotations can be supported in IDE/compile), any
name.
EntityManager callbacks as opposed to POJO callbacks.
- Absence of POJO class interference.
- Well-known event listener process exploitation.
- Very lightweight only called if specific class/life cycle event happens.
- Can be "aspect oriented".
- Absence of object-orientation.

Explain the role that callbacks play in developing Entity beans

with container-managed persistence.
- The following are EJB callbacks along with pros and cons:
Magic callbacks :
- The container defined method is same.
- For example: public void ejbPassivate();

- Template code, base class, interface dependency are not available and very lightweight.
Won’t express the container dependency and easily breakable such as the typos by the
developers.
Interface:
- The expression is clearly depended and no breakages.
- Coding template is a lot.
Base class:
- Template code availability in base class. Extendibility by the developers.
- No template code, not breakable.
- Single inheritance in java makes this base class.

Annotations:

- Method annotations as callback.

- Non code template , not breakable (annotations can be supported in IDE/compile), any
name.
EntityManager callbacks as opposed to POJO callbacks.
- Absence of POJO class interference.
- Well-known event listener process exploitation.
- Very lightweight only called if specific class/life cycle event happens.
- Can be "aspect oriented".
- Absence of object-orientation.

Use of local interfaces while modeling business objects.

- Local interfaces are communication interfaces, that are used between all the same machine
resident EJBs.

- Remote methods overhead will be eliminated that is needed at the time of existence of EJBs
in different clients and servers.
Local interfaces versus Dependent value objects.
Local interfaces:
- An interface that establishes the communications between EJBs of the same machine.
- The overhead of using remote methods can be eliminated by remote methods that are needed
when the EJBs of separate clients and servers.
- Local interfaces are BMP constructs.
Dependent value objects:

- Dependent value objects leverage CMP constructs.

- Dependent value objects are persistent objects whose life cycle is managed by an entity
bean.
- The assignment of a dependent value is done by set accessor method that copies to the target
cmp-field.
- The serialization of the dependent value class is mandatory.
- The structure is not described in the deployment descriptor.

Message-driven bean
- A MDB is one of the enterprise bean that allows an EJB application to perform messages
asynchronously.
- It is a message listener similar to event listener that receives messages instead of events.
- It is similar to JMS message listener.
- Unlike a session bean or entity bean, a message driven bean has only a bean class.
- The message process starts when the container calls the message-driven bean’s onMessage
method soon after a message arrives.

Need for Asynchronous Communication.

- Any application process will be continued while the communication is being processed,
using asynchronous communication. The receipt of the message may not be immediate for the
application that directs the message.
- The messages can be sent to various applications which are care to listen.
- We can use asynchronous communication which are platform independent that supports
Java technologies such as IBM’s MQ Series, JMS.
- It is possible to convert one of the applications from COBOL to Java, which does not need
any changes to other senders and receivers of the messages.
JMS messaging
- The JMS is an API that makes the different applications components which are JSE,JEE
based.
- The JMS messaging standard allows the messages to create, send, receive and read
messages.
- The characteristics of JMS messaging are – loosely coupled, reliable and asynchronous.
- The JEE enterprise computing problems can be solved by using the JMS API powerful tool.
- The JMS API improves the productivity of messaging concepts, strategies of programming
which are supported by all JMS compliant messaging services.

JavaMail API and how it is used to compose and dispatch a

mail.
- Java Mail is a protocol independent, platform independent mailing and messaging services
for Java based applications.
- The present protocols like PostOfficeProtocol, SimpleMailTransferProtocol can be used to
send a mail.
- The use of Java mail is not to adhere to any protocol over a network.
- The javax.mail.internet.MimeMessage objects are used to represent an E-mail using Java
Mail.
- The following are the methods that correspond message objects.
1. setSubject() – Used to specify the subject of the message
2. setContent ()– Used to specify the content of the message
3. setRecipients() – Used to specify the address of the recipient
4. addFrom() Used to add the addresses to the existing "From" attribute.
- The InternetAddress class represents the e-mail address.

Procedure:
- Pass the session object as the parameter to the constructor of MimeMessage object. This
creates an initially empty message.
- Add the necessary content to the message using the methods
setSubject(),setContent(),setReceipients(),addForm() .
- Send the message using send() method

EJB security model.

Declarative model security :
- In the earlier EJB architecture, security model of EJB is a declarative model.
- In this model the avoidance of the security code in the business model is implemented.
- Later the encouraging for bean provider to implement the enterprise bean security model is
encouraged by the EJB architecture without hard coding these methods in the business
methods.
- The EJB encourages the configuration at the deployment time for the security policies of the
EJB application.
- In the enterprise environment this is one of the most appropriate approach.
- The ejb-jar elements for a security role are:

<security-role> :
- The definition of the security role is specified in this element.

<role-name> :
- The name of the role for the security is mentioned in this element. The name can be Admin,
Architect,Owner.

<description> :
- The description about the security model is given in the tag which is optional.
Custom Security :
- Custom security encourages the bean provider to specify a mechanism for the security.
- The needs the business method to implement the security logic.
- The methods that support custom security at bean level are:

- java.security.Principal getCallerPrincipal()
- boolean isCallerInRole(java.lang.String roleName)
- Any security validation type can be customised along with these methods.

EJB-specific issues in security management

Authentication :- This is the security management issue that is handled by the EJB container.
- This security level is used to identify the verification of the user.

Authorization : - This ensures that the accessibility to the private resources only by the
authorized user. To have the accessibility, the user is mandatory to authorized first.

Secure Communication :

- The secure communication is ensured by the following guidelines:

1. The boundaries specified in the server must be observed strictly.
2. It is mandatory to use only the authorised API to communicate between the customer and
the EJB application.
3. The roles for the users and users group should be appropriate that they use the right and
relevant applications.

Ways to authenticate a client before it contacts the server

- To authenticate a client container, first it is needed to authenticate which application server
ensures that all the user roles will have the same name as corresponding the application server
groups.
- The next step is to define the group with the appropriate name with one or more associated
users.
- Every EJB application client authenticated by using Interoperable Object Reference, which
was created for CORBA.
- All java EE compliant containers are supported by IOR.
- It is needed to specify the invoked EJB, a bean in the deployment descriptor.
- The following elements are to be scripted in ejb-jar.xml file:
1. <as-context> - To indicates that the IOR authentication service. The authentication
mechanism specifies here.
2. The authentication method is specified by the <auth-method> tag.
3. This is set to USERNAME_PASSWORD which is the only value for an application client.
4. The client authenticated realm is specified by the <realm> tag.
5. The <required> element specifies whether the above authentication method is required to
be used for client authentication.

Steps involved in security design for EJB application.

1. Specify the web-tier security by specifying access control and authorised users.
2. Specify the EJB-tier security by specifying method permissions,programmatic security and
unprotected web resources.
3. Specify the application-client security with various permissions for the client.

Implementing a distributed system using in EJB

- The following are the advantages of the distributed systems in EJB:
- Geographically separate users can use the application. It is useful for corporations whose business scope is spa
across the countries wide data.
- Performance and scalability can be improved for multiple machines because a client-server system is distribut
several machines and countries.
- Heterogeneous systems can use the best tools for each task.
- Different components of an application can run on different hardware to optimize a distinguished tasks.
- Maintenance costs can be reduced by the distributed systems.

Implementation of a distributed system using EJB.

The disadvantages of the distributed systems using EJB are:
1. Available of software is limited.
2. Network bandwidth and reliability problems.
3. Security management in distributed system is complex.
4. Increased development time: To implement one session bean, one needs to write three classes.
5. Understandability is more complex to develop and deploy distributed applications.
6. Complexity is added compared to normal java class.
7. The code may be obsolete when implementing new EJB containers.

How to avoid large data transfer using EJBs.

- Avoid using entity beans to access the large data.
- Use session to contain complex interactions and reduce calls using RMI.
- Avoid the transaction that may span across multiple instances of the server.
- Address translation policies can be avoided using DNS names.
- Direct interaction with entities should be avoided.

Explain how to tune the performance when deploying EJBs.

- Make all the remote method calls into a single call and transfer the data needed by one
transfer.
- By reducing the number of JNDI lookups.
- Use a mechanism / technique to return multiple data rows from a single entity bean instead
of returning one row at a time.
- For any database batch of operation, it is suggested to use session beans.
- Use container-managed persistence (CMP) rather than bean-managed persistence (BMP).
- Implement the lowest transaction level which is consistent while maintaining the data
coherency.

How to improve the performance of EJB applications.

- By changing the default time out for transaction configuration time out which will effect the
EJB transactions. This time out is specified to rollback or commit the transaction.
- For CMP, some of the parameters configuration are:
call-timeout : applies for entity and sessionbeans. Set the exact time for the specific beans.
do-select-before-insert : set to false, default value is true.
exclusive-write-access : force it to false, if locking is optimistic and not used for clustering.

validity-timeout : is used when exclusive-write-access=true and locking- mode=read-only.

For BMP:
locking-mode : must be optimistic for BMP.
max-tx-retries : Recommended value is 0, default value is 3.
For Session beans:
cache-timeout : applies for stateless session beans,default value is 60 seconds. If it is zero or
negative, the cache-timeout is disabled.
Timeout : applies for stateful session beans, default is 30 seconds.

EJB container
An EJB container will provide the runtime environment for EJB applications within the
application server.
- It is responsible for all the operations of the EJB applications.
- The container acts as an intermediary action between the business logic of the bean and the
rest of the world of the enterprise application.
- One or more EJB modules can be installed within a single EJB container.
- The role of EJB container is to perform transactional actions such as,
1. Starting a transaction.
2. Rollback a transaction or commit a transaction.
3. Managing various connection pools for the database resources.
4. Bean’s instance variables with corresponding data items which are stored in a database will
be synchronized.

Services that the EJB container offers to the application

developer.
There are four types of services offered by the EJB container, described as follows:
1. Life Cycle Management:
JRun is an application server that works for building and deploying server-side Java
applications. It automatically increases and reduces the number of available bean instances so
that there is not much load on the current server.
2. Security:
- EJB support authentication and role-driven access control thus providing security.
3. Session Management:
The Server JRun maintains state for stateful session beans and entity beans. The state for
session bean is maintained through passivation and activation callback methods, while for the
entity beans it is maintained by entity-bean callback methods.

4. Transaction:
EJB provides 2 types of transactions:
1. Container-managed transactions
2. Bean-managed transactions

Four types of container that J2EE supports.

EJB Container:
- An EJB container will provide the runtime environment for EJB applications within the
application server.
- It is responsible for all the operations of the EJB applications.
- The container acts as an intermediary action between the business logic of the bean and the
rest of the world of the enterprise application.

- One or more EJB modules can be installed within a single EJB container. The role of EJB
container is to perform transactional actions such as,

1. Starting a transaction.
2. Rollback a transaction or commit a transaction.
3. Managing various connection pools for the database resources.
4. Bean’s instance variables with corresponding data items which are stored in a database will
be synchronized.

Web Container:

- A web container implements a web component such as servlet container.

- A servlet container supports the operations of a servlet.
- It supports the web server operations and the client java operations such as JRE,maps the
URL specific requests into servlet requests.
- The servlet cotainers have the ability to dynamically add or remove servlets from the
system.
- Individual servlets will get registered by the servlet container.
- The servlet API is provided by different vendors for a specific servlet standard.

Application Client Container:

- An application client container includes set of java classes, libraries and the set of files that
are needed and distributed among various java client applications which executes on their
own JVMs.
- The ACC is responsible for managing the applications execution by providing all the system
services that are needed for the execution of java client programs.
- It is light-weighted and communicates with different application servers.

Applet client container:

- Like application client container, applet container executes the client applications.
- The difference is an applet executes the application in a separate browser.
- They execute on their own JVMs.
- It supports the applet programming model.
- JEE client may use java plug-in to provide the required environment that executes the
applet.

Developer classes vs. container classes.

- The developer classes are the classes that are authored by the developers
- The container classes are the classes which supports the container to manage the container
specific functionality.

Difference between servers and containers.

- The server receives the requests from client and sends the responses to the client.
- If it is a web server or EJB server, the request will be sent to the web container or to the EJB
container.

- A web server responds requests over the web.

- The container creates the required objects pertaining to the requests and responses, and
invokes the appropriate service methods.
- Containers also provide the communication support, life cycle management, multithreading
support and declarative security.
- A container runs inside the web or application server which could produce dynamic content.