Enterprise Java Beans (EJB) is a platform for building portable, reusable, and scalable business applications using the Java programming language. EJB allows application developers to focus on building business logic without having to spend time on building infrastructure code for services such as transactions, security, automated persistence, and so on. This presentation introduces EJB 3.0 concepts with code examples.

1. Enterprise Java Bean 3.0
Yet Another Introduction…
Kelum Senanayake

2. Tag-Cloud
ResourceInjection
StatelessSessionBean
EnterpriseJavaBeans
EntityBean StatefulSessionBean
MessageDrivenBean
JavaEE POJO
JavaPersistenceAPI
Annotations Transactions

3. Enterprise Java Beans

4. Enterprise Java Beans (EJB)
• A platform for building portable, reusable, and
scalable business applications.
• Allows to focus on building business logic
without having to spend time on building
infrastructure code for services such as
transactions, security, automated persistence.
• An EJB is a piece of Java code that executes in
a specialized runtime environment.

5. EJB as a component …
• A component should effectively encapsulate
application behavior.
• All we need to know is what to pass in and
what to expect back.
• Components can be reusable.
• Three types of EJB components:
– Session beans
– Message-driven beans
– Entities

6. EJB as a framework …
• EJB components live in a container.
• Together, the components, or EJBs, and the
container can be viewed as a framework.
• EJB framework provides valuable services for
enterprise application development

7. EJB History
• EJB 1.0 (1998-03-24)
– Defined the responsibilities of EJB Container provider
– Defined the distinct “EJB Roles”
• EJB 1.1 (1999-12-17)
– XML deployment descriptors
– Session Beans, Entity Beans
– Remote interface
• EJB 2.0 (2001-08-22)
– Message-Driven Beans
– Entity 2.x and EJB QL

8. EJB History …contd
• EJB 2.1 (2003-11-24)
– EJB Timer Service
– Web service support
• EJB 3.0 (2006-05-11)
– POJO, Annotations
– Dependency injection
• EJB 3.1 (2009-12-10)
– Local view without interface
– .war packaging of EJB components
– Singletons (Singleton Session Beans)
– EJB Lite: definition of a subset of EJB
– @Asynchronous for session beans

9. EJB 3.0 vs EJB 2.1
• EJB 3.0 is much faster than EJB 2
• An EJB 2.1 session bean must implement the
SessionBean interface
• EJB 3.0 session bean class includes only business
methods.
• EJB 3.0 interfaces are POJI business interfaces
and do not require home and component
interfaces.
• EJB 2.1 must have the deployment descriptor. But
optional in EJB 3.0. Annotations are added to the
language.

10. EJB 3.0 vs EJB 2.1 …contd
• EJB 3 introduced persistence API for database
access. In EJB 2 you can use Entity bean.
• An EJB 2.1 Entity EJB bean class must implement
the EntityBean interface and must provide
implementation to the ejbCreate() and
ejbPostCreate() methods.
• EJB 2.1 entity bean includes the home,
component, local home and local component
interfaces that extend the EJBHome, EJBObject,
EJBLocalHome and EJBObject interfaces
respectively.

11. EJB 3.0 vs EJB 2.1 …contd
• An EJB 2.1 bean must define resource-ref in ejb-
jar.xml to lookup resources. An EJB 3.0 bean can
use either dependency injection or JNDI lookup.
• An EJB 2.1 message-driven must implement the
javax.ejb.MessgeDrivenBean interface.
• Standardized Simplified persistence with POJO
– You couldn’t send an EJB 2 entity bean across the wire
in different tiers.
– They are permanently attached to the database.
– You have to write data transfer objects

12. Why choose EJB 3.0?
• Ease of use
– POJO programming, annotations in favor of verbose
XML, heavy use of sensible defaults & JPA
• Integrated solution stack
– EJB 3 offers a complete stack of server solutions
– Persistence, messaging, lightweight scheduling,
remoting, web services, dependency injection (DI) and
interceptors
– You won’t have to spend a lot of time looking for
third-party tools

13. Why EJB 3.0 …contd
• Open Java EE standard
– EJB is a critical part of the Java EE standard
– EJB 3 has an open, public API specification
– The open standard leads to broader vendor
support
– You don’t have to depend on a proprietary solution

14. Why EJB 3.0 …contd
• Broad vendor support
– You are not at the mercy of the ups and downs of
a particular company or group of people
– Vendors have historically competed against one
another by providing value-added nonstandard
features
• Stable, high-quality code base
– Clustering, load balancing, and failover support
with no changes to code, no third-party tool
integration, and relatively simple configuration

15. Why EJB 3.0 …contd
• Unit-testable POJO components
– All EJB 3 components are POJOs, they can easily
be executed outside the container
– It is possible to unit-test all component business
logic using testing frameworks
• Annotations and descriptors are not mutually
exclusive
– Deployment descriptor entries override
configuration values hard-coded into EJB
components

16. JavaEE Container

17. The Container
• When you build a simple Java class, you need a
Java Virtual Machine (JVM) to execute it.
• Think of the container as simply an extension of
the basic idea of a JVM.
• JVM transparently manages memory on your
behalf.
• The container transparently provides EJB
component services
– Transactions, security management
– Remoting and web services support

18. Container …contd
• A Java EE container is an application server
solution that supports EJB 3, a web container,
and other Java EE APIs and services.
• JPA is completely pluggable and separable.
– Persistence provider and container in an EJB 3
solution need not come from the same vendor
– You could use Hibernate inside a BEA WebLogic
container

20. Hello World !

21. HelloUser Example

22. HelloUser Example (Client)

23. Dependency injection vs. JNDI lookup
• With EJB 2, you have to write the same few lines
of boilerplate code many times to do a JNDI
lookup.
• In EJB 3, JNDI lookups have been turned into
simple configuration using metadata-based
dependency injection (DI)
• JNDI : It’s the responsibility of the client to do a
lookup and obtain a reference to the object
• You may think DI is the opposite of JNDI
– It is the responsibility of the container to inject an
object based on the dependency declaration

25. Building business logic with
Session Beans

26. Getting to know Session Beans
• So what is a Session?
– A session is a connection between a client and a
server that lasts for a finite period of time
• Session beans centers on the idea that each
request by a client to complete a distinct business
process is completed in a session.
• Recall that session beans come in two flavors:
Stateful and Stateless
• A bean may maintain its state between calls, in
which case it is stateful, or it may be a one-time
call, in which case it’s stateless.

27. @Stateless Session Bean
• No more Home interfaces!
• A POJI Business Interface
– Annotated with @Remote or @Local
• A POJO Implementation
– Annotated with @Stateless
• No more deployment descriptors! (optional)

29. @Stateful Session Bean
• No more Home interfaces!
• A POJI Business Interface
– Annotated with @Remote or @Local
• A POJO Implementation
– Annotated with @Stateful
• No more deployment descriptors! (optional)

32. Working with multiple business
interfaces
• You cannot mark the same interface with
more than one access type annotation.
• However, a business interface can extend
another interface.
• You can create a set of interfaces utilizing OO
inheritance to avoid code duplication

35. Callback methods
• @PostConstruct
• @PostActivate
• @PrePassivate
• @PreDestroy

36. @MessageDriven Bean

37. Messaging with message-driven beans

40. Diving into the Java Persistence API

41. Java Persistence API
• Separate specification document
• Produced by EJB 3.0 Expert Group (JSR-220)
• Available in & outside the Java EE container
• The API itself, defined in the javax.persistence
package
• The Java Persistence Query Language (JPQL)
• Object/relational metadata
• Gavin King (founder of Hibernate) represented
JBoss on JSR220

42. @Entity Beans
• No more Home interfaces!
• No Business Interfaces!
• A POJO Implementation
– Annotated with @Entity
• A simple deployment descriptor
• Entities need not use getter- and setter-based
properties.

46. EntityManager
• EntityManager is the bridge
between the OO and
relational worlds.
• Knows how to store a POJO
entity into the database,
read, update & delete.
• Factory for Query

48. Query
entityManager.createNativeQuery()

49. Named queries
• They improve reusability of queries.
• They improve maintainability of code
– Queries are not scattered among the business logic.
• They can enhance performance because they
are prepared once and can be efficiently reused.
• Can be defined either in the entity using
annotations, or in the XML file defining O/R
mapping metadata.

51. Transaction Management

52. Understanding transactions
• A transaction is a grouping of tasks that must be
processed as an inseparable unit.
• Every task that is part of the transaction must
succeed in order for the transaction to succeed.
All-or-nothing
• The Transaction Manager is a component that,
coordinates a transaction over multiple
distributed resources
• EJB provides through the Java Transaction API
(JTA)

53. Container-managed transactions
• In a CMT, the container starts, commits, and
rolls back a transaction on our behalf
• Can be done through annotations or the
deployment descriptor
• EJB context: accessing the runtime
environment
• The javax.ejb.EJBContext interface is
essentially your backdoor into the mystic
world of the container

56. Bean-managed transactions
• The greatest strength of CMT is also its
greatest weakness.
• CMT, you are limited to having the transaction
boundaries set at the beginning and end of
business methods and relying on the
container to determine when a transaction
starts, commits, or rolls back.
• BMT, on the other hand, allows you to specify
exactly these details programmatically

58. The pros and cons of BMT
• BMT is verbose, complex, and difficult to
maintain and some times error prone.
• With BMT, you can fine-tune your transaction
boundaries so that the data held by your code
is isolated for the shortest time possible
• BMT can never join an existing transaction.
– Existing transactions are always suspended
– Significantly limiting flexible component reuse

59. References
• [1] D. Panda, R. Rahman, and D. Lane, EJB 3 in Action, 1st
ed. Manning Publications, 2007.
• [2] “Enterprise JavaBeans - Wikipedia, the free
encyclopedia.” [Online]. Available:
http://en.wikipedia.org/wiki/Ejb. [Accessed: 10-Mar-2012].
• [3] “What I’m Learning: Differences between EJB 3.0 and
EJB 2.1.” [Online]. Available:
http://mytechnicaldocs.blogspot.com/2011/08/differences
-between-ejb-30-and-ejb-21.html. [Accessed: 10-Mar-
2012].

60. @Questions?