WHAT IS EJB??

Enterprise JavaBeans (EJB) is a managed, server-side component architecture for modular construction of enterprise applications.

EJB is a server-side model that encapsulates the business logic of an application.

The EJB specification was originally developed in 1997 by IBM and later adopted by Sun Microsystems (EJB 1.0 and 1.1) in 1999.

The EJB architecture.

An EJB component is a reusable

WORA.

The EJB architecture makes

enterprise application (transaction

management, security management,

multithreading management)

The EJB architecture also supports

WORA and portable solution.

manages the EJB component

lifecycle.

enterprise bean is a distributed

lives in an EJB container

accessed by remote clients

enterprise beans on the same

server

a remotely executable component

deployed on its server and it is

self-descriptive

Remote interface

Home interface

Client class

Server class

Deployment descriptor

JNDI(java naming and directory

interface)

The bean developer is responsible for declaring the bean class' persistent fields as either Java primitive or serializable types.

public class Address implements Serializable{ public String street; public String city; public String state; public String zip; }

Bean developer responsible for declaring the persistent fields in the bean class.

On an RDBMS primitive types(String, integer etc) map easily to their corresponding types

Tell the container through the deployment descriptor (DD). The <cmp-field> tags identify such fields.

Generally container tools allow you to map.

There is no standard way of mapping serializable objects to a relational database. Although the Address class has its own set of fields, the XML deployment descriptor doesn't provide a mechanism for mapping those fields to the database. In most cases it was expected that serializable objects such as Address would be persisted as a binary type, which is sometimes called a blob type, to a database table.

That problem is make worse as the entity bean's data schema grows in complexity.

For entity beans with a large schema problem grows. As an entity bean may have many dependent objects which in turn have dependent objects forming complex graphs.

Entity bean to Entity bean relationship support not adequate. Since it always uses the other EB’s primary key as a link. Relationships are not always based on the primary key.

New in EJB 2

1. Container managed Persistence

2. EJB Query Language

3. Message-Driven Beans

4. Local client view

5. Improved interoperability

i. The most important changes in the specification are those

made to container-managed persistence (CMP) and the

introduction of a completely new bean type, the

MessageDrivenBean.

ii. When the bean is deployed, you will use persistent

manager tools to generate a concrete implementation of the

abstract bean class and its dependent object classes based

on the XML deployment descriptor and the bean class. The

concrete implementations will include the data access code

that will actually read and write the bean's state to the

database at runtime. At runtime, the container uses the

subclasses generated by the persistence manager tools

instead of the abstract classes defined by the bean

provider.

Container Managed

Persistence

• Allows you to define complex bean-to bean, bean to

dependent object and dependent to dependent object

relationships.

• Done with the help of new “PERSISTENCE MGR”

• Contract between container and Persistence Mgr.

• Contract known as Abstract Schema has two parts

Additional XML tags in DD

Code idioms (Rules for coding the bean )

• The bean class is declared abstract and all persistent and

relationship fields are accessed using abstract accessor

and mutator methods whose signatures map to special

elements in the DD

public abstract EmployeeBean implements javax.ejb.EntityBean { // instance fields

EntityContext ejbContext;

// container-managed persistent fieldspublic abstract void setIdentity(int identity); public abstract int getIdentity(); public abstract void setFirstName(String firstName); public abstract String getFirstName(); public abstract void setLastName(String lastName); public abstract String getLastName();

// container-managed relationship fieldspublic abstract void setContactInfo(ContactInfoinfo); public abstract ContactInfo getContactInfo(); ... }

• They form relationships with entity beans

• live and die along with the entity bean

• only visible to the bean class and not the client

• Bean class must have additional methods to expose

dependent objects to the client since they are not suitable

remote arguments.

A dependent object ( class)………..

public abstract class ContactInfo { // home address info public abstract void setStreet(String street); public abstract String getStreet(); public abstract void setState(String state); public abstract String getState(); public abstract void setZip(String zip); public abstract String getZip(); public abstract void setHomePhone(String phone); public abstract String getHomePhone();

// work address info public abstract void setWorkPhone(String phone); public abstract String getWorkPhone(); public abstract void setEMail(String email); public abstract String getEMail(); ... }

Formerly developer provided a description of what

the finder methods should do . Deployer provided

the actual query according to the target Application

Server. Advantages of EJB QL

◦ Query need be developed and tested only once (

not at each new environment)

◦ Developer can do it .More suited for the purpose.

Integration of EJB with Java Message Service (JMS). Container on arrival of a JMS message invokes a “message-driven bean”. Need not create a separate front-end for messages.

The Message Driven Bean is used among others to provide a high level ease-of-use abstraction for the lower level JMS (Java Message Service) specification

Message Driven Beans can support other messaging protocols.Suchprotocols may be asynchronous but can also be synchronous.

Examples

Sending a configuration update to multiple nodes might be done by sending a JMS message to a 'message topic' and could be handled by a Message Driven Bean

Submitting a job to a work cluster might be done by sending a JMS message to a 'message queue' and could also be handled by a Message Driven Bean,

the Quartz scheduler can be handled by a Message Driven Bean; when a Quartz trigger fires, the MDB is automatically invoked.

An MDB component works in the following way:

1. The container registers this MDB component with

JMS.

2. The JMS registers all JMS destinations (Topic for

broadcasting or Queue for PTP) with Java Naming

and Directory Interface(JNDI).

3. The EJB container instantiates this MDB component.

4. The client looks up the destination with the MDB.

5. The client sends a message to the destination.

6. The EJB container selects the corresponding MDB to

consume the message.

WORKING:

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.

Local interfaces and local home interfaces provide support for lightweight access from enterprise beans that are local clients. Session and entity beans can be tightly coupled with their clients, allowing access without the overhead typically associated with remote method calls. The local client view consists of two interfaces:

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.

protocol based on RMI/IIOP and

CORBA to allow J2EE applications on

different app servers to interact

without bean developer intervention

The standard component architecture for building distributedobject-oriented business applications in Java.

Make it possible to build distributed applications by combining components developed using tools from different vendors.

Make it easy to write (enterprise) applications: Application developers will not have to understand low-level transaction and state management details, multi-threading, connection pooling, and other complex low-level APIs.

Will follow the "Write Once, Run Anywhere" philosophy of Java.

Address the development, deployment, and runtime aspects of an enterprise application’s life cycle.

Define the contracts that enable tools from multiple vendors to develop and deploy components that can interoperate at runtime.

Compatible with existing server platforms

Compatible with other Java APIs.

Compatible with the CORBA protocols (RMI-IIOP).

Complex schemas involving relationships among entity beans and dependent objects can be depicted with the help of persistence manager.Closer to intuition and better database design and use.

Business methods in the home interface provide option for better design by isolating business logic completely within the entity.

Entity beans can communicate using JMS at the business logic level itself --one more for better design .

New EJB QL makes standardized query possible and relives deployer.Helps in correct creation of finder method queries.

Tightened some unresolved issues of 1.1

Implement a lot of artifacts such as home interfaces , callback methods, remote interfaces

Use only one business interface per EJB bean

Follow a lot of conventions when building enterprise beans such as using RMI conventions, using specific base interfaces

Abide to a different scheme when developing EJBs compared to developing regular Java classes and interfaces

Configure beans and applications with giant XML based deployment descriptors

Introduce dependencies to the environment

Deal with the complexities of persistence

Manually introduce tracing, logging and other homegrown

methods to test components

Manually locate and use beans as clients

Use Meta-Data

Use Dependency Injection

Reducing the number of artifacts developersmust provide

Configuration by exception

Reducing environmental dependencies

Simplification of EJB types

Getting rid of many interfaces

Simplification of persistence

Improved testing outside of the container

Using POJOs (Plain Old Java Object) and POJIs (Plain Old Java

Interface)

Business Interface as Java interface

No more home interface

Using metadata annotations for configuration of EJB Type, Local/Remote,

Transactions, Security

Minimize the bean-specific configuration requirements

The deployment descriptor can also be used to specify a bean as

message-driven.

The bean class now serves as the main programming artifact

Home interfaces have disappeared

@Stateful public class ShoppingCartBean

implements ShoppingCart

{

public int add(long item){…}

public void remove(int id){…}

}

public interface ShoppingCart {

public int add(long item);

public void remove(int id);

}

Bean class methods may throw application exceptions

They should not throw java.rmi.RemoteException

• Implement plain Java business interfaces

Do not provide a homeinterface

• Comprise an implementation class annotated with@Stateless

• Callbacks defined @PostConstruct, @PreDestroy andexecuted in unspecified

security, transaction context

• Interceptors might be applied

• Dependency Injection before first business method execution

Empowers developers due to more possibilities

Increases productivity by reducing required

artifacts, configuration by

exception, dependency injection, annotations

Much easier to handle through POJOs and POJIs

Developers might use deployment descriptor or

annotations or both

Extensibility of container using callback concept

EJB 1.0 provides the basic functionality of Enterprise beans but has

some flaws to cover up those flaws EJB 2 was introduced

Enterprise Java Bean 2.0 embodies some fantastic changes from

the previous specification. The new CMP model is far more flexible

than the previous model, allowing entities to model complex object

graphs while providing for more portability across containers and

the new MessageDrivenBean

EJB 2 had many dependences like home interface must implement

EJBHome in order to provide services in order to reduce

dependency EJB 3 was introduced.