An Introduction to EJB 3.

BHUPESH RAVISH
Project Engineer
CDAC, Mumbai

1
CDAC, Mumbai
Agenda

 Introduction
 Motivation for EJB 3.0
 Java 5.0 Annotations
 Types of Beans
 Container Services
 Interceptors

2
CDAC, Mumbai
Introduction
 EJB 3.0 is the next revision of the Enterprise Java Beans
specification. One of the most significant changes in EJB
3.0 is the introduction of a standard O/R mapping
specification and the move to POJO based persistence.

 One of the principal goals of EJB 3.0 is:“Simplification

of object persistence by the definition of a light-weight
object/relational mapping facility based on the direct use
of Java classes rather than persistent components.”
JSR 220: Enterprise JavaBeansTM,Version 3.0
EJB 3.0 Simplified API

3
CDAC, Mumbai
Sun Microsystems’s Definition for EJB

The Enterprise JavaBeans architecture is a

component architecture for the java development
and deployment of component based distributed
business applications. Application written using
EJB are scalable, transactional and multi-user
secure. These applications may be written once
and then can be deployed on any server platform
that supports EJB Specifications.

4
CDAC, Mumbai
Motivation
 EJB 2.1 technology very powerful, but too
complex
– Too many classes, interfaces
– Awkward environment lookups (JNDI APIs)
– Boilerplate javax.ejb interface methods
– Clumsy programming model
– Deployment descriptors

5
CDAC, Mumbai
Java 5.0 Annotations
 annotations do not directly affect program semantics
 can be inspected through source parsing or by using the
additional reflection APIs
 define custom annotations
– annotate fields, methods, classes, etc.
 used to define
– bean's business interface
– O/R mapping information (specific persistence)
– resource references
– deployment information
 EJB 3.0 makes extensive use of annotations to replace
XML

6
CDAC, Mumbai
EJB 3.0 Goals
 Make EJB easier to learn and use
• Fewer classes and interfaces
• No required container interfaces
• Dependency injection
• Simple lookups
• No required deployment descriptor
• Simplified persistence
• Standardized object/relational mapping

 Improve developer productivity

7
CDAC, Mumbai
EJB 3.0 Approach
 Simplification of the EJB APIs

• Removal of need for EJBHomes and

EJBObjects
• Removal of JNDI APIs from developer and
client view
• Removal of need for deployment descriptors

 Use advantages of Java language metadata

• Metadata designed so that the most common

cases are easiest to express
• Defaults available for expected cases
8
CDAC, Mumbai
EJB 3.0 Approach contd.
 More work is done by container, less by developer

 Contracts now benefit developer rather than container

• Bean specifies what it needs through metadata
No longer written to unneeded container interfaces
• Container interpositions and provides requested
services to bean

9
CDAC, Mumbai
Simplification of EJB Bean Types
 Business interfaces are plain Java interfaces
• No more required EJBObject/EJBLocalObject
interfaces
 Home interfaces are no longer needed
• No more required EJBHome/EJBLocalHome
interfaces
• Only need business interface, not home
 Annotations for (optional) callback methods
• No more required javax.ejb.EnterpriseBean
interfaces
 Dependency injection, simple lookup method
• No more need to use JNDI APIs

10
CDAC, Mumbai
Example // EJB 2.1

public class PayrollBean implements

javax.ejb.SessionBean {

SessionContext ctx;
DataSource empDB;

public void setSessionContext(SessionContext ctx) {

this.ctx = ctx;
}
public void ejbCreate() {
…
Context initialContext = new InitialContext();
empDB = (DataSource) initialContext.lookup (
“java:comp/env/jdbc/empDB”);
}
11
CDAC, Mumbai
// EJB 2.1 (continued)

public void ejbActivate() {}

public void ejbPassivate() {}

public void ejbRemove() {}

public void setBenefitsDeduction(int empId, double

deduction) {
…
Connection conn = empDB.getConnection();
…
}…
}
12
CDAC, Mumbai
// EJB 2.1 (continued)

public interface PayrollHome extends

javax.ejb.EJBLocalHome {

public Payroll create() throws CreateException;

…
}

public interface Payroll extends javax.ejb.EJBLocalObject {

public void setBenefitsDeduction (int empId, double

deduction);
…
}
13
CDAC, Mumbai
Deployment Descriptor

<session>

<ejb-name>PayrollBean</ejb-name>
<local-home>com.example.PayrollHome</local-home>
<local>com.example.Payroll</local>
<ejb-class>com.example.PayrollBean</ejb-class>
<session-type>Stateful</session-type>
<transaction-type>Container</transaction-type>
<resource-ref>
<res-ref-name>jdbc/empDB</res-ref-name>
<res-ref-type>javax.sql.DataSource</res-ref-type>
<res-auth>Container</res-auth>
</resource-ref>

</session>
…
<assembly-descriptor>
…
</assembly-descriptor>

14
CDAC, Mumbai
Same Example // EJB 3.0
@Stateful
public class PayrollBean implements Payroll {
@Resource DataSource empDB;
public void setBenefitsDeduction (int empId, double
deduction) {
Connection conn = empDB.getConnection();
…
}
}

@Remote
public interface Payroll {
public void setBenefitsDeduction (int empId, double
deduction);
}

15
CDAC, Mumbai
EJB 3.0: XML Deployment Descriptor

EJB3 takes a different approach to configuration

– Metadata annotations are used heavily

• Especially useful for mostly static configuration:

<session-type> @Stateless,
<remote> @RemoteInterface

Alleviates the disconnect between Java code and

XML configuration

– Defaults are used whenever possible

• <transaction-type> Container, etc.
16
CDAC, Mumbai
EJB 3.0: XML Deployment Descriptor contd

Partial deployment descriptors are support

– Override annotations with XML
– General rule

• Use annotations when design of code is affected

by metadata(i.e. @TransactionAttribute)

• Use XML when something is configurable per

deployment (i.e. @RolesAllowed)

17
CDAC, Mumbai
Types of Beans

 Session Beans

 Entity Beans

 Message Driven Beans

18
CDAC, Mumbai
Session Bean
 Represents TaskFlow.
 Fills gap left by Entity Beans
 Describe interaction between other Beans

 Types of Session Bean

– Stateless Session Bean
 They don’t maintain any conversational state.
– Stateful Session Bean
 They maintain a conversational and act on behalf of clients.

19
CDAC, Mumbai
Stateless Session Bean

 Does not retain any client specific data.

 Container has pool of instances of stateless
session beans and client requests are delegated to
any available beans.
 Reused by different clients.
 Typically implements a procedural service on top
of a database or legacy application.
 Ex: PayRoll that simple gets db information to
the user whose identity is given.

20
CDAC, Mumbai
Stateless Session Beans

 EJB 2.1: Requirements

– Home interface
– Remote/Local interface
– Bean class must implement javax.ejb.SessionBean
– XML Deployment descriptor

21
CDAC, Mumbai
EJB 2.1: Required Interfaces
 Homes for stateless beans unnecessary
 Remote interface must inherit from EJBObject
 Remote methods must throw RemoteException
– Dependency on RMI

public interface CalculatorHome extends

javax.ejb.EJBHome {
public Calculator create() throws CreateException;
}
public interface Calculator extends EJBObject {
public int add(int x, int y) throws RemoteException;
public int subtract(int x, int y) throws RemoteException;
}
22
CDAC, Mumbai
EJB 2.1: Bean class requirements

 Must extend verbose javax.ejb.SessionBean

 Unnecessary and verbose callback methods

public class CalculatorBean implements javax.ejb.Sessionbean {

private SessionContext ctx;
public void setSessionContext(SessionContext ctx) { this.ctx = ctx; }

public void ejbCreate() { }

public void ejbRemove() {}
public void ejbActivate() {}
public void ejbPassivate() {}

public int add(int x, int y) {

return x + y;
}

public int subtract(int x, int y) {

return x – y;
}

23
CDAC, Mumbai
EJB 2.1: XML Deployment Descriptor

<session>
<ejb-name>CalculatorBean</ejb-name>
<home>in.cdac.CalculatorHome</home>
<bean>in.cdac.CalculatorBean</bean>
<remote>in.cdac.CalculatorRemote</remote>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>

….

24
CDAC, Mumbai
EJB 3.0 interface & class

 Homeless
 Methods don’t throw RemoteException
 No verbose interface implementations

@Remote public interface Calculator {

public int add(int x, int y);
public int subtract(int x, int y);
}
@Stateless Public class CalculatorBean implements
Calculator {
public int add(int x, int y) {
return x + y;
}
public int subtract(int x, int y) {
Return x – y;
}
} 25
CDAC, Mumbai
 LifeCycle of stateless session bean

Does Not Exist

Class.newInstance();
@PreDestroy() Injections
@PostConstrauct

Method ready Pool

Business Method
26
CDAC, Mumbai
Stateful Session Beans
 Maintains client-specific session information (called
conversational state) across multiple method calls and
transactions

 Aware of client history

 Each stateful session bean has a timeout value

 The bean instance is destroyed and the remote reference

is invalidated after the timeout period is elapsed.

27
CDAC, Mumbai
Stateful Session Beans
 Still homeless
– Created as they are looked up
 @Remove replaces EJBObject.remove
 Stateful bean is removed after method called

@Remote public interface ShoppingCart {

public void addItem(int prodId, int quantity);
public void checkout();
}

@Stateful public class ShoppingCartBean implements ShoppingCart {

@Remove
public void checkout() {
…
}
}

28
CDAC, Mumbai
EJB 3.0 Deployment Descriptor
 Believe it or not, people like XML deployment
descriptors

 Externalize configuration

 Externalize system architecture

 Although not in draft, XML DDs are optional

 Replace annotations with XML and you get pure POJOs

29
CDAC, Mumbai
Simplified Client View
 Session beans have plain Java business interface
• Looks like normal Java interface to client
• Access can be local or remote (as specified)

 Home interface not needed in client view

 Remoteness is handled transparently

• No checked RemoteExceptions (unless you
want them)
• EJBExceptions (unchecked exceptions) are
thrown instead

30
CDAC, Mumbai
Example // EJB 2.1
…
Context initialContext = new InitialContext();

ShoppingCartHome myCartHome = (ShoppingCartHome)

initialContext.lookup(“java:comp/env/ejb/cart”);

ShoppingCart myCart = myCartHome.create();

// Use the bean

Collection widgets = myCart.startToShop(“widgets”);
…

// Don’t forget to handle javax.Naming.NameNotFoundException

// Don’t forget to handle javax.ejb.CreateException
// Don’t forget deployment descriptor (ejb-refs, etc.)
}

31
CDAC, Mumbai
Example: EJB 3.0 Client View

…
@EJB ShoppingCart myCart;
…
Collection widgets = myCart.startToShop(“widgets”);

OR

Context ctx = new InitialContext();

Collection c =
(Collection)ctx.lookup(Collection.class.getName() );

32
CDAC, Mumbai
Where Did the Home Interface Go?
 Stateless Session Beans
• Home interface not needed anyway
• EJB 2.1 Home.create() didn’t really create
• Container creates or reuses pooled bean instance when business
method is invoked
• Can use new SLSB class with “legacy” Home (and no
extra code)

 Stateful Session Beans

• Container creates bean instance when business
method is invoked
• Initialization is part of application semantics
Don’t need a separate interface and ejbCreate method
for it
• Can use new SFSB class with “legacy” Home
@Init annotation denotes bean method that plays role of
ejbCreate

33
CDAC, Mumbai
Dynamic Lookup
 Dynamic lookup is simplified as well

 EJBContext.lookup method is used at runtime

 JNDI APIs are removed from developer’s view

 Annotations to specify environment

 dependencies are expressed on bean class

• Same annotations as used for injection
34
CDAC, Mumbai
Example
@Resource(name=“productDB”,
type=javax.sql.DataSource)
@Stateful public class ShoppingCartBean
implements ShoppingCart {
@Resource SessionContext ctx;
public Collection startToShop(String productName) {
…
DataSource productDB =
(DataSource)ctx.lookup(“productDB”);
Connection conn = myDB.getConnection();
…
}…
}

35
CDAC, Mumbai
 LifeCycle of a stateful session bean

Instance throws exception

Does Not Exist timeout

Class.newInstance()
timeout
@PreDestroy() Injections
@PostConstruct()

Method Ready @PrePassivate() Passive

@PostActivate()

36
CDAC, Mumbai
Entity Beans

POJO based persistence

37
CDAC, Mumbai
Goals of Entity Beans

 Same goals as session beans

– Fewer interfaces, optional XML DDs, etc.
 No required interfaces or subclassing
 Plain Java based
– Allow new()
 Providefull Object/Relational mapping
 Supports Inheritance
 Expanded EJBQL
– Fully featured
– Parallel SQL
– Polymorphic Queries

38
CDAC, Mumbai
Defining Entity Beans

 O/R Mapping Metadata as annotations

– Table mappings, @Table, @SecondaryTable
– Column mappings, @Column, @JoinColumn
– Relationships, @ManyToOne, @OneToOne,
@OneToMany, @ManyToMany
– Multi-Table mappings, @SecondaryTable
– Embedded objects, @Dependent
– Inheritance, @Inheritance,
@DiscriminatorColumn
– Identifier + Version properties, @Id, @Version

39
CDAC, Mumbai
Entity Annotations
@Entity
@Table(name=“AUCTION_ITEM”)
public class Item {

private long id;

private String description;
private String productName;

@Id(generate=GeneratorType.AUTO)
@Column(name=“ITEM_ID”)
public long getId() {
return id;
}

public void setId(long id) {

this.id = id;
}

40
CDAC, Mumbai
 Entity Annotations

@Entity
@Table(name=“AUCTION_ITEM”) create table AUCTION_ITEM
public class Item { (
private long id; ITEM_ID Number,
private String description; DESC varchar(255),
private String productName; ProductName varchar(255),
private User seller; USER_ID Number
);
@Id(generate=GeneratorType.AUTO)
@Column(name=“ITEM_ID”)
public long getId() {
return id;
}
public void setId(long id) {
this.id = id;

41
CDAC, Mumbai
 Entity Annotations

@Entity
@Table(name=“AUCTION_ITEM”) create table AUCTION_ITEM
public class Item { (
private long id; ITEM_ID Number,
private String description; DESC varchar(255),
private String productName; ProductName varchar(255),
private User seller; USER_ID Number
);
@Id(generate=GeneratorType.AUTO)
@Column(name=“ITEM_ID”)
public long getId() {
return id;
}
public void setId(long id) {
this.id = id;

42
CDAC, Mumbai
 Entity Annotations

@Column(name=“DESC”,
nullable=false, length=500) create table AUCTION_ITEM
public String getDescription() { (
return description; ITEM_ID Number,
} DESC varchar(500),
public void setDescription(String ProductName varchar(255),
desc) { OWNER_ID Number
this.description = desc; );
}
public String getProductName() {
return productName;
}
protected void
setProductName(String name) {
this.productName = name;
}

43
CDAC, Mumbai
Relationships
 Relationships
– @ManyToOne, @OneToOne, @OneToMany,
@ManyToMany
– Supports lazy and eager loading of
relationships
– Cascades: delete, create, and merge
– No CMR: You must manage the
relationships somewhat.

44
CDAC, Mumbai
Entity Relationships
@OneToOne(fetch=LAZY)
@Column(name=“OWNER_ID”)
public Owner getOwner() {
return owner;
}

protected void setOwner(Owner owner) {

this.owner = owner;
}

@OneToMany(cascade=ALL)
@JoinColumn(name=“ITEM_ID”)
protected Set<Bid> getBids() {
return bids;
}
protected void setBids(Set<Bid> bids) {
this.bids = bids;
}
45
CDAC, Mumbai
 Entity Relationships

@OneToOne(fetch=LAZY)
@Column(name=“OWNER_ID”) create table AUCTION_ITEM
(
public Owner getOwner() {
ITEM_ID Number,
return owner; DESC varchar(255),
} ProductName varchar(255),
protected void setOwner(Owner OWNER_ID Number
user) { );
this.owner = owner;
} @OneToMany(cascade=ALL) create table BID
@JoinColumn(name=“ITEM_ID”) (
…
protected Set<Bid> getBids() {
ITEM_ID Number
return bids; …
} );
protected void setBids(Set<Bid>
bids) {
this.bids = bids;
}
46
CDAC, Mumbai
Multi-Table

 Multi-Table Mappings,
– Entity can be stored in one or
more tables
– @SecondaryTables,
@SecondaryTable

47
CDAC, Mumbai
 Multi-table Mappings
@Entity
@Table(name=“OWNER”)
@SecondaryTable(name=“ADDRESS” create table OWNER
join={@JoinColumn(name=“ADDR_ID”) (
}) OWNER_ID Number,
public class Owner { NAME varchar(255),
private long id; );
private String name;
private String street; create table ADDRESS
private String city; (
private String state; ADDR_ID Number,
@Id(generate=GeneratorType.AUTO) STREET varchar(255),
@Column(name=“OWNER_ID”) CITY varchar(255),
public long getId() { STATE varchar(255)
return id; );
}
public void setId(long id) {
this.id = id;
} 48
CDAC, Mumbai
 Multi-table Mappings
…
@Column(name=“STREET”,
secondaryTable=“ADDRESS”) create table OWNER
public String getStreet() { (
return street; OWNER_ID Number,
} NAME varchar(255),
public void setStreet(String street) { );
this.street = street;
} create table ADDRESS
(
@Column(name=“CITY”, ADDR_ID Number,
secondaryTable=“ADDRESS”) STREET varchar(255),
public String getCity() { CITY varchar(255),
return city; STATE varchar(255)
} );
protected void setCity(String city) {
this.city = city;
}
49
CDAC, Mumbai
Interacting With Entity Bean

 Plain Java Objects

50
CDAC, Mumbai
Entity Manager
EntityManager is the central service for all persistence actions.

Entities are plain java objects that are allocated just like any other
Java object. They do not become persistent until your code
explicitly interacts with the EntityManager to make them persistent.

The EntityManager manages the O/R mapping between a fixed

set of entity classes and an underlying data source. It provides API’s
for creating queries, finding objects, synchronizing objects, and
inserting objects into the database.

EntityManager also can provide caching and manage the interaction

between an entity and transactional services in a Java EE environent
such as JTA.

51
CDAC, Mumbai
Entity Manager
 All entities persisted by the EntityManager service
– All access through this service
– Creation, retrieval, removal, and merging
– Analogous to Hibernate Session

 Entity manager manages persistence contexts .

 The entity manager tracks all entity objects within a persistence

context for changes and updates made, and flushes these changes
to the database using the flush mode rules.

 Once the object is detached from a persistence context, it can no

longer be managed by an entity manager, and any state changes
to this object instance will not be synchronized with the database.

 Injected with dependency injection

52
CDAC, Mumbai
EntityManager
@Stateless public class ItemImpl implements ItemRemote {

@PersistenceContext(unit name=“item”)
EntityManager entityManager;

public long create(Item item) {

em.create(item);
return item.getId();
}

public Item findById(long id) {

return (Item) em.find(Item.class, id);
}

public void merge(Item item) {

em.merge(item);
}
}

53
CDAC, Mumbai
Persistence Context
 A persistence context is a set of managed entity object
instances.
There are two types of persistence contexts:
4. Transaction-scoped persistence context
5. Extended persistence context

Transaction-scoped persistence context :

Persistence context may live as long as a transaction and be closed

when a transaction completes. This is called a transaction-scoped
persistence context.

When the transaction completes, the transaction-scoped persistence

context will be destroyed and all managed entity object instances
will become detached.

54
CDAC, Mumbai
Persistence Context contd.

Application server managed persistence contexts can be transction-

scoped. In other words, only Entity Manager instances injected
with the @PersistenceContext annotation or its XML equivalent may
be transaction-scoped.

@PersistenceContext(unit name=“titan”)
EntityManager entityManager;

@TransactionAttribute(REQUIRED)
public Customer someMethod() {
Customer cust = entityManager.find(Customer.class,1);
cust.setName(“new name”);
return cust;
}

55
CDAC, Mumbai
Persistence Context contd.

Extended Persistence Context

Persistence contexts may also be configured to live longer than a

transaction. This is called an extended persistence context.

Entity object instances that are attached to an extended context

remain managed even after a transaction is complete.

This feature is extremely useful in situations where you want to

have a conversation with your database but not keep a long-
running transaction, as transactions hold valuable resources
like JDBC connections and database locks.

56
CDAC, Mumbai
Persistence Context contd.

@PersistenceContext(unitName=“titan”,
type=PersistenceContextType.Extended)
private EntityManager extendedManager;
….
Customer cust = null;
transaction.begin(); //start tranasaction 1
cust = extendedManager.find(Customer.class,1);
tranasction.commit(); // tranasaction 1 ends

transaction.begin(); // start transaction 2

cust.setName(“bill”);
extendedManager.flush();
tranasaction.commit(); // cust instance remains managed and changes
// are flushed

57
CDAC, Mumbai
Create the objects

 Create the entities like you would any other object

 Allocate entire object graph like any other Java code

Item item = new Item();

item.setDescription(“O’reilly’s EJB 4th Edition”);
item.setProductName(“EJB 2.1 Book”);
…
Owner bill = new Owner();
bill.setName(“Bill”);
item.setOwner(bill);
Bid bid = new Bid();
…
HashSet<Bid> bids = new HashSet();
bids.add(bid);
item.setBids(bids);

58
CDAC, Mumbai
Packaging a Persistence Unit
An example of persistence.xml fle :

<persistence>

<persistence-unit name=“item”>
<jta-data-source>java:/OracleDS</jta-data-source>
<properties>
<property name=“org.hibernate.hbm2ddl”>update</property>
</properties>
</persistence-unit>
</persistence>

The JAR file of the persistence unit may also optionally contain a
mapping XML DD called orm.xml in the META-INF directory of
the deployment. This file used to define the mapping between the
classes container in the persistence
unit and the database to which they map.

59
CDAC, Mumbai
EntityManagerFactory
In Java SE, entity managers are created using
javax.pesistence.EntityManagerFactory.

public interface EntityManagerFactory {

EntityManager createEntityManager();
EntityManager createEntityManager(java.util.Map map);
void close();
boolean isOpen();
}

The createEntityManager() methods return EntityManager

instances that manage a distinct extended persistence
context.

60
CDAC, Mumbai
Interacting with an EntityManager
The EntityManager API has methods to insert and remove entities
from a database as well as merge, updates from detached enity
instances.
public interface EntityManager {
public void persist(Object entity); // from new to managed
public <T> T merge(T entity); // from detached to managed
public void remove(Object entity); // from managed to removed
public Object find(String entityName,
Object primaryKey); // find by primary key
public <T> T find(Class entityClass,
Object primaryKey); // --´´--
public void flush(); // sync to database
public Query createQuery(String ejbqlString); // create EJB-QL query
public Query createNamedQuery(String name); // named queries
public Query createNativeQuery(String sqlString); // create SQL query (not
portable)
public void refresh(Object entity); // sync from database
...
}

61
CDAC, Mumbai
Inheritance

 This feature was completely absent in EJB 2.1

 Persistence mapping supports inheritance

– Single table per hierarchy – SINGLE_TABLE
– Join table per subclass – JOINED
– Distinct table per subclass – UNION

 Queries on class hierarchy are polymorphic

62
CDAC, Mumbai
Inheritance – SINGLE_TABLE
@Entity
@Table(name="Animal") create table Animal
@Inheritance(strategy=InheritanceType. (
SINGLE_TABLE) ID Number,
@DiscriminatorColumn(name="TYPE") TYPE varchar(255),
public class Animal {
@Id private int id; AVG_WEIGHT Number,
@Column(name="AVG_WEIGHT") BREED varchar(255)
private int averageWeight; );
...
}

@Entity
@Inheritance(strategy=InheritanceType.
SINGLE_TABLE)
public class Dog extends Animal{
@Column(name="BREED")
private String breed;
...
}
63
CDAC, Mumbai
 Inheritance – JOINED
@Entity
@Inheritance(strategy=InheritanceType.JOINED) create table Animal
@Table(name="Animal") (
public class Animal{ ID Number,
@Id private int id; TYPE varchar(255),
@Column(name="AVG_WEIGHT") AVG_WEIGHT Number
private int averageWeight; );
...
}
create table Doggy
@Entity (
@InheritanceJoinColumn(name="DOGY_ID") DOGGY_ID Number,
@Table(name="Doggy") BREED varchar(255)
public class Dog extends Animal{ );
@Column(name="BREED")
private String breed;
...
}

64
CDAC, Mumbai
 Inheritance – UNION
@Entity
@Inheritance(strategy=InheritanceType.TABLE_P create table Animal
ER_CLASS) (
@Table(name="Animal") ID Number,
public class Animal{ TYPE varchar(255),
@Id private int id; AVG_WEIGHT Number
@Column(name="AVG_WEIGHT")
private int averageWeight; );
...
} create table Doggy
(
@Entity DOGGY_ID Number,
@InheritanceJoinColumn(name="DOGY_ID") BREED varchar(255)
@Table(name="Doggy") );
public class Dog extends Animal{
@Column(name="BREED")
private String breed;
...
}

65
CDAC, Mumbai
Query API
 Java interface that is obtained at runtime from Entity Manager
 Queries may be expressed as EJBQL strings
– Embedded in code
– Externalized to metadata (named queries)
 Invoke via Query interface
– Named parameter binding
– Pagination control

@Session public class ItemImpl {

…
public List findByDescription(String description, int page) {
return em.createQuery(“from Item i where i.description like :d”)
.setParameter(“d”, description)
.setMaxResults(50)
.setFirstResult(page*50)
.listResults();
}

66
CDAC, Mumbai
EJB QL 3.0

 EJBQL 3.0 is very similar to HQL (Hibernate Query

Language)
 Aggregation, projection
– select max(b.amount) from Bid b where
b.item = :id
– select new Name(c.first, c.last) from
Customer c
 Fetching
– from Item i left join fetch i.bids
 Subselects
– from Item i join i.bids bid where
bid.amount = (select max(b.amount) from
i.bids b)
 Group By, Having, Joins
67
CDAC, Mumbai
Entity Life-cycle

68
CDAC, Mumbai
Entity Callbacks & Listeners
 PrePersist
 PostPersist
 PostLoad
 PreUpdate
 PostUpdate
 PreRemove
 PostRemove

Entity Listeners are classes that can generically intercept

entity callback events. You can assign methods on an
entity listeners class to intercept a particular life cycle
event.

69
CDAC, Mumbai
Message-driven Beans

 A message driven bean is an enterprise bean that allows

J2EE applications to process messages asynchronously.

 It acts as a JMS listener, which is similar to an event

listener except that it receives messages instead of events.

 The messages can be sent by any J2EE component: an

application client, another enterprise bean, or a web
component, or a non-J2EE system using JMS.

 Retain no data or conversational state.

70
CDAC, Mumbai
Message-driven Beans

 Message-driven beans were already the simplest

component in EJB 2.1

 Message-driven beans in EJB 3.0

• Bean class implements message listener interface or
designates with @MessageListener
• No requirement to implement MessageDrivenBean,
etc.

71
CDAC, Mumbai
JMS Messaging Models

Topic

Publisher Topic

Topic

Publish-and-Subscribe ( 1 -> many )

72
CDAC, Mumbai
JMS Messaging Models

Potential
Reciever

Sender Queue

Potential
Reciever

Point-to-Point ( 1 -> 1 )

73
CDAC, Mumbai
Basics of JMS

 ConnectionFactory & Topic

 Connection & Session

 Message Producer

 Message Consumer

 Message Type

74
CDAC, Mumbai
 JMS Programming Model
Connection Factory
creates

Connection
creates

Session creates
creates
creates
Message Consumer Message Consumer
Sends to Sends to
Msg

Destination Destination
75
CDAC, Mumbai
Example

Just implements MessageListener

 XML turns to annotations

@MessageDriven( activationConfig={
@ActivationConfigProperty(
propertyName=“destinationType”,
propertyValue=“javax.jms.queue”)})

public class EmailBean implements MessageListener {

void onMessage(Message msg) { }

public int add(int x, int y) {
return x + y;
}
}
76
CDAC, Mumbai
Life Cycle

Does Not Exist

Class.newInstance()
@PreDestroy() Injections
@postConstruct

Method-Ready
Pool
Business
methods

77
CDAC, Mumbai
Timer Service

 The Timer Service is a facility of the EJB Container system that

provides a timed event API, which can be used to schedule timers
for specific dates, periods and intervals.

 To use Timer Service, your beans must implement the

javax.ejb.TimedObject interface.

 Or put @Timeout annotation on your desired method.

@Timeout
Public void maintainence(javax.ejb.Timer timer){
…..
}

78
CDAC, Mumbai
Container Services: Transactions

 What is a Transaction ?
– Unit of Work.
– Set of Activities.
 Must be having ACID properties, viz. Atomic,
Consistent, Isolated, Durable
 In EJB 3.0 we have Declarative Transaction
Management.
 Transaction management
• Container-managed transaction (CMT) by default
• Bean-managed transaction (BMT) by annotation

79
CDAC, Mumbai
Transactions contd.

 Container-managed transactions
• REQUIRED transaction attribute by default
• Any transaction attribute by annotation
Specified at class level => applies to all business
methods of the class
Specified at method level => applies to method
(overriding any class-level specification)
• Typical case (CMT + REQUIRED) is default

80
CDAC, Mumbai
Example
@Stateless public class PayrollBean implements Payroll {

@TransactionAttribute(REQUIRED)
public void setBenefitsDeduction (int empId, double
deduction) {…}

public double getBenefitsDeduction(int empId) {…}

public double getSalary(int empId) {…}

@TransactionAttribute(REQUIREDNEW)
public void setSalary(int empId, double salary) {…}
…
}

81
CDAC, Mumbai
Container Services: Security
 Security configuration typically done at deployment
• Developer can provide guidance
 Security attributes
• If not specified => set on deployment or
“unchecked”
• Method permissions by annotation
 Specified at class level => applies to all business
method of class
 Specified at method level => applies to method
(overriding any class-level specification)
 @PermitAll, @RolesAllowed
 Use caller principal by default
• Run-as principal by annotation
82
CDAC, Mumbai
Example
// Security view
@Stateless public class PayrollBean implements Payroll
{
public void setBenefitsDeduction (int empId, double
deduction) {…}

public double getBenefitsDeduction(int empId) {…}

public double getSalary(int empId) {…}

// salary setting is intended to be more restricted

@RolesAllowed(“HR_PayrollAdministrator”)
public void setSalary(int empId, double salary) {…}
…
}
83
CDAC, Mumbai
Container Services: Event Notification
 Container calls bean upon lifecycle events
• @PostConstruct
• @PreDestroy
• @PrePassivate
• @PostActivate
 Bean specifies events it needs to know about
• Removes boilerplate code, “magic methods”
ejbCreate, ejbRemove, etc
 Callback methods can be specified on separate
interceptor class or on bean class
 PostConstruct and PreDestroy annotations
adopted into JSR-250 (“Common Annotations”)

84
CDAC, Mumbai
Example
@Stateful public class AccountManagementBean
implements AccountManagement {
Socket cs;
@PostConstruct
@PostActivate
private void initRemoteConnectionToAccountSystem ()
{
…
}
@PreDestroy
@PrePassivate
private void closeRemoteConnectionToAccountSystem
() {
…
}
}
85
CDAC, Mumbai
Interceptors
 Powerful facility for more advanced developers.

 Interception of invocations of business methods, message

listener methods.

 Invocation model: “around” methods

• Wrapped around business method invocations
• Interceptor has control over invocation of “next
method”
• Can manipulate arguments and results
• Context data can be carried across interceptor
invocation chain
• Can use deployment descriptor to override order or
to add interceptors

86
CDAC, Mumbai
Interceptors contd.
 Default interceptors
• Specified in deployment descriptor
Lack of application-level metadata annotation facility
Apply to all business methods of components in ejb-jar
 Class-level interceptors
• Apply to all business method of bean class
 Method-level interceptors
• Apply to specific business method only
 High degree of control available
• Can specify exactly which interceptors in hierarchy
get invoked for a given class or method
• Ability to exclude default interceptors and/or classlevel
interceptors
87
CDAC, Mumbai
Example
@Interceptors({
in.cdac.AccountAudit.class,
in.cdac.Metrics.class,
in.cdac.CustomSecurity.class
})
@Stateless public class AccountManagementBean
implements AccountManagement {
…
public void createAccount (int accountId, Details details)
{…}
public void deleteAccount (int accountId) {…}
public void activateAccount (int accountId) {…}
public void deactivateAccount (int accountId) {…}
…
}
88
CDAC, Mumbai
Example
public class AccountAudit{
@AroundInvoke
public Object auditAccount (InvocationContext inv)
throws Exception{
try {
Object result = inv.proceed();

return result;
} catch (Exception ex) {
throw ex;
}
……
}
}

89
CDAC, Mumbai
Summary
 Major simplification of EJB for developers
• Bean is plain Java class with plain Java
business interface
• Injection model for services and resources
• Removal of boilerplate code
• Elimination of need for deployment descriptors
 EJB 3.0 components interoperate with existing

applications
 Gives developer simple-to-use and powerful

capability

90
CDAC, Mumbai
 Questions

91
CDAC, Mumbai
 bhupesh@cdacmumbai.in

ravishbhupesh@gmail.com

92
CDAC, Mumbai