java ee ejb applications

Java EE EJB Applications

Building EJB Applications

2003 – 2013 DevelopIntelligence http://www.DevelopIntelligence.com 2

Presentation Topics

In this presentation, we will discuss:

Building the Enterprise

History of EJB Development

EJB Development Concepts

Session Beans

Message Driven Beans

Persistent Entities

Interceptors

Timer Service

Transactions

Security


Objectives

When we are done, you should be able to:

Explain benefits of EJB3 over EJB 2

Understand Java EE’s layered architecture and the functions provided in its layers

Describe three kinds of enterprise beans and their uses

Explain pros and cons of stateful vs. stateless session beans

Compare the development process under Java EE 5 versus J2EE

Building the Enterprise

The Tools of Java Enterprise Edition


Presentation Topics

In this section, we will discuss:

Overview of Java EE

Java EE Platform

Java EE Development


Objectives


Describe how Java EE and Java SE fit together

List 3 technologies found in Java EE

Describe the basic development lifecycle for a Java EE application

Overview of Java EE

A High-level Overview


What is Java EE?

A community-defined extension to the Java SE platform

An enterprise information systems platform

A standard architecture definingAn application programming modelAn application execution platform


History of Java EE

Java EE was not an “intent” of the original Java design

Java EE was more “evolutionary” than revolutionary


Motivations for Java EE

Provide an easy to use framework to build middle-ware applications

Provide a managed execution environment


Industry Support

Originally, Java EE was developed and maintained by Sun

Today, Java EE is governed by the Java Community Process (JCP)

Current focus of Java EE community is simplification

Latest release is Java EE 6 (12/2009)


Application Programming Model

Programming model adopts a “managed” modelDesign and implementation

Lifecycle

Transactions and security

Deployment

Application implementation adheres to modelBuilt around abstracted interactions with Java EE execution environment

Interactions provided through Java EE platform APIs


Application Execution Platform

Provides a “managed” execution environment Java EE compliant applications

Execution environment is a realized implementation of the Java EE APIs

Relies on the Java SE platform


Java EE Platform Diagram

Java SE Platform

Solaris Linux Windows Mac OS X

Java EE API Implementations

Java EE APIs

App

Java EE Application Server

App App App

Java EE Platform

An Application Development Perspective


Java EE Platform

Java EE Platform supports three primary application types

Web applications

EJB applications

Enterprise applications

Each application type has its own set of characteristics

Applications execute in “domain” relevant containers


Java EE Containers

Java EE defines two primary types of containers:Web containers - managed environment for web applications

EJB containers - managed environment for EJB applications

A certified Java EE application server must provide an implementation for both types of containers


Java EE Technologies

Enterprise Container Boundary


Java EE Server Technologies

WORA is a design motivation to justify use of Java EE

There are two ways to create WORA:1. Define an application programming model and its

supporting technologies

2. Define a set of services to support the programming model

Java EE defines the supporting services as “Standard Services”


Java EE Standard Services

Communication

Email

XML Processing

Transactions

Messaging

Management

Database

Naming and Directory

Security

Web Services

Legacy systems

Deployment


Container Technologies

Remaining technologies defined in Java EE specification address application development

Technologies are associated with an application-centric container

Relatively clean separation of technologies between container types

Technology sharing is at the Standard Services level

Technologies may exist as “standard” implementations or vendor implementations


Web Container Technologies

Web containers provide “robust” web application environments

A web container supports the following technologies:

Servlets

Filters

Java Server Pages (JSP)

JSP Standard Tag Library (JSTL)

Java Server Faces (JSF)


EJB Container Technologies

EJB containers provide state, workflow, and persistent application environments

An EJB container supports the following technologies:

Session Beans (SB)

Entity Beans (EB)*

Message Driven Beans (MDB)

* Deprecated in EJB3.x


Java EE Application Diagram

JSP

Servlet

JSF

JSTL

SB

MDB

EB

WSI

Standard Services

Java SE Platform

Web Container& Technologies

EJB Container& Technologies

Enterprise Container

Java EE Platform

Java EE Development


Java EE ApplicationsBuilt using components, modules, and deployment units

The Java EE application structure provides:Functional encapsulationReusabilitySimplified configurationTransportability

Modular-oriented development encouragesGood Object oriented designSeparation of functional concernSeparation of development concern

Has been considered the “struggle” of Java EE


Components and Modules

Components enable application development

Modules represent basic unit of a Java EE application


Deployment Units

Java EE applications may consist ofA Single deployment unitMultiple deployment units packaged together as a single deployment unit

Deployment units are the standard way to package and deploy Java EE applications

Java EE defines three deployment units:Web Application Archive (WAR)Java Archive (JAR) Enterprise Application Archive (EAR)


WAR – Web Module


EJB JAR – EJB Module


EAR


Java EE Development Process

Creation Assembly Deployment


Java EE Development Roles

Java EE application development process requires broad range of competencies

To simplify “jack of all trades” skill requirement, Java EE specification defines set of Platform Roles

Not all platform roles are realized within a software development organization


Java EE Platform Roles

Java EE Product Provider

Application component provider

Application assembler

Deployer

System Administrator

Tool Provider

System Component Provider

:: QUESTION ::Which of these roles exist within your organization?


Summary

Java EE platform defines an application programming model and an execution environment

Java EE platform enables WORA in middleware

Java EE is comprised of Standard Services, Web Technologies, and EJB Technologies

Java EE uses a deployment unit strategy for application packaging and deployment


Resources

WebJava EE Tutorial http://docs.oracle.com/javaee/6/tutorial/doc/

Java EE Specificationhttp://jcp.org/aboutJava/communityprocess/pfd/jsr244/

Books“Head First Servlets and JSP” : ISBN 0596005407

“Head First EJB” : ISBN 0596005717

“EJB3 in Action” : ISBN 1933988347

http://jcp.org/aboutJava/communityprocess/pfd/jsr244/

History of EJB


Objectives


Explain benefits of EJB 3 over EJB 2

Understand Java EE’s layered architecture and the functions provided in its layers

Describe three kinds of enterprise beans and their uses

Explain pros and cons of stateful vs. stateless session beans

Compare the development process under Java EE 5 versus J2EE


Motivations for EJB

Prior to EJB specification, reusable middleware was hard to create

EJB specification borrowed many concepts defined by servlets and adapted them to address middle tier


What is EJB?

An Enterprise Java Bean is:A reusable component A Java objectAn encapsulation of enterprise business logic and dataExecuted in a Containers

EJB Containers provide:PoolingTransaction Management SecurityNaming and DirectoryConfigurationEtc.


History of EJB

Four major releases of EJB specificationEJB 1.0 - all Java based; cumbersome

EJB 2.0 - Java based + xml; tedious

EJB 2.1 - Java based + xml; slightly easier

EJB 3.0 - Java based + xml + annotations; easier

EJB 3.1 – Java based + xml + annotations; easiest

Most applications “legacy” EJB applications are built using EJB 2.X specification


EJB 2.X Strengths

More capabilities than EJB 1.0 spec

Clean separation of business services

Persistence supports usable object/relational mapping

Message oriented middleware capabilities

Performance improvements


EJB 2.X Weaknesses

Cumbersome programming model

Complex deployment model

Mediocre object/relational mapping


EJB 3.x Strengths

Simplified programming model

Simplified deployment model

More robust persistence structure


EJB 3.x Weaknesses

Yet another new programming model

Aspect Oriented Programming and dependency injection not as robust as other frameworks

Limited vendor support


New Features in EJB3.0

Annotations instead of Deployment Descriptors

Callback Methods and Listeners

Interceptors

Dependency Injection


New Features of EJB3.1

Simplified EJB development – no interfaces

Singleton Session Beans

Enhanced Timer Service

Application Profiles


EJBs within Java EE

Java client

.NET client

Desktop

HTML client

Java client

Browser

Delphi client

.NET client

Server

Client Tier Web Container

JSP

Servlet

JSF

WS

JSTL

CTL

Beans

POJO

Beans

POJO

EJB Container

EJB

EJB

EJB

EJB

JMS

JCA

JNDI

JDBC

DB

MessageSystem

DirectoryServer

CustomSystem

EIS Tier


Summary

EJB3.x simplifies the development model

There are three kinds of EJBsSession Beans


“Entity” Beans

EJB Development Concepts


Presentation Topics


Type of Enterprise Java Beans

EJB Client Access Modes

EJB Instance Management

EJB Development Elements


Objectives


Describe the three types of EJBs

Identify the three types of client access

Understand the elements involved in building an EJB

Types of Enterprise Java Beans


Enterprise Java Beans

Designed to provide:Database abstraction

Reusable business logic components

Workflow components

Transportable implementation

Exists as APIs in javax.ejb


Types of Enterprise Java Beans

Three main categoriesBusiness logic – javax.ejb.SessionBeanWorkflow logic – javax.ejb.MessageDrivenBeanPersistence logic - JPA Entity

Classifications specified with through:Interface – 2.x style

Annotations – 3.x style


Session Beans


Can be used to manage state across client interactions

Three typesStateless (SLSB)

Stateful (SFSB)

Singleton (SSB) [3.1 or higher]*

* Similar to Jboss @Service


Message Driven Beans [MDB]

Reusable workflow logic componentsRely on Java Messaging System

Support transactions

Similar to Stateless Session BeansMDBs have no client-oriented state

No distinction across client or bean

Different from Stateless Session BeansNo direct client access

Asynchronous interactions


Entity Beans

Persistence model for EJB

Focused on automatic persistence through object model

Three primary types:Bean Managed Persistence (BMP)

Container Managed Persistence (CMP)

JPA Entities [EE 5 and higher]


Category-Related Annotations

Bean Type Annotation

Session Bean @Stateless@Stateful@Singleton*

Message Driven @MessageDriven

JPA Entities @Entity**

@EntityManager**

* EJB3.1

** Part of JPA (javax.persistence)

EJB Client Access Modes


Types of EJB Access Modes

Three client access modes: Local client-access

Remote client-access

Web service client-access

Client-access modes specified byInterface – 2.x style

Annotations – 3.x style


EJB Classifications [cont.]

Local beans are accessible Only by other EJBs in the same context (module)

All categories of beans can be local

Remote beans are accessibleBy EJBs in the same context and outside the context (modules)

By other “objects” outside of the container

Only Session Beans can be remote

Web Service end-pointsTranslate SB and MDBs into web-services

Container manages WSDL/SOAP mappings

REST/JAXB mappings


Access Mode Annotations


Session Bean @Local@Remote@LocalBean*

@WebService@Path*

Message Driven @WebService

JPA Entities N/A

* EJB3.1

EJB Instance Management


EJB Management Modes

Two management modes:Container-managed

Bean-managed

Management-modes specified by Annotations


EJB Classifications

In container-managed, container manages:Transactions

Roles

Security

Persistence and Entities (PersistenceContext)

In bean-managed, bean manages:Transactions

Persistence


Management Mode Annotations


Transactions @TransactionManagement(CONTAINER)@TransactionManagement(BEAN)

Security @RunAs()@RolesAllowed


EJB Access

EJB Instance access is controlled by container

There is no direct client access

“proxy”

EJB

Client

Container


EJB Instantiation

Instantiation of EJB is handled by container

Container determines when and “how many”

Uses standard instantiation mechanism (public no argument constructor)

Creates an EJBObect (proxy)

Creates an EJB instance (actual bean instance)


EJB Lifecycle

Lifecycle of an instance is managed by container

Lifecycle phases:Does Not exist – no bean instance in memory

Post-construct / Not-ready – bean instance exists but isn’t ready for client interaction

Ready – exists, initialized, and ready for interactions

Pre-removal – bean instance is about to be removed

Lifecycle transition notifications are handled through call-backs

EJB Development Elements

Developing an EJB


Elements of an EJB 2.x

Each EJB is implemented by:

Home interface*

Business interface

Bean Implementation

XML Filesejb-jar.xmlapp-server-xml.xml

*Deprecated in EJB3.0


Elements of an EJB 3.x

Each EJB is implemented by:

Business interface*

Bean Implementation

XML Fileejb-jar.xml*

*Optional in EJB3.1


Elements of EJB [cont.]

Each EJB is described by meta-dataTells container how to manage EJB

Annotation-based in Java code

Or, XML based*

ejb-jar.xmlserver specific xml file

Key description elementsEJB name

EJB JNDI name

EJB type

Security and transaction information

*Optional in EJB3.0


EJB Development Cycle

1. Write client2. Write EJB

1. Interfaces (depending on version)2. Implementation

3. Define configuration1. Annotate2. Or create descriptors

4. Compile5. Package 6. Generate client access classes7. Deploy8. Test9. Repeat 2 - 8 until satisfied


EJB Deployment

EJBs have their own deployment model

Each deployment executes in its own context


Summary

There are 3 types of EJBS:Session Beans

Message driven Beans

JPA Entities

There are 3 client access modesRemote

Local

Local no interface

EJBs are implemented using:Business interface

Bean implementation

EJBs are configured using meta-data


LAB: Setup Environment

In this lab, you will:

Setup your development environment:Install JBoss

Install Eclipse

Configure EclipseAdd JBoss as an app server

Create an EJB Project

Session Beans

Enterprise Business Logic


Presentation Topics


Session Bean Concepts

Developing a Session Bean

Developing a Session Bean Client


Objectives


Describe the 3 types of session beans

Implement a simple stateless session bean

Package and deploy a simple session bean

Implement a simple stateful session bean

Package and deploy a simple stateful bean

Explain pros and cons of stateful vs. stateless vs. singleton session beans

Session Bean Concepts


Review of Session Beans Concepts


Can be used to manage state across client interactions

Three typesStateless (SLSB)

Stateful (SFSB)

Singleton (SSB)


Choosing a Session Bean

Use a Session bean if:Only one client has access to bean at any given time

State of bean is not persistent

Bean represents a web service

Use a Stateful Session bean if:Bean state represents client interaction

Bean needs to hold client data across interactions

Bean acts as a client mediator to other beans

Need thread-safe interactions


Choosing a Session Bean

Use a Stateless Session bean if:Concerned about performance

No distinction across client or interaction

Need synchronous or asynchronous interactions

Use a Singleton Session bean if:You need only a single instance of the bean in memory

Want to maintain consistency across all client interactions

Need to support concurrent client-access


Session Bean Cardinality

@Stateless @Stateful @Singleton

Remote Client Access ✔ ✔ ✔

Local Client Access ✔ ✔ ✔

Concurrent client access

✖ ✖ ✔

Unique per client ✖ ✔ ✖

Client-bean instances Pooled 1:1 Many:1



Steps to create a session bean

1. Define business logic interface

2. Annotate the business interface

3. Create the session bean, implementing the interface

4. Annotate class defining type

5. Compile, deploy and debug as discussed above


Developing Business Interface

Similar to standard Java interfacepublic interface SomeInterfacepublic int getSomeProperty();

Annotated with client-access mode@Local – local (in context of application only)

@LocalBean – local (no interface bean)

@Remote – remote (inside and outside of context)


Local Interface


Remote Interface



Class requirements similar to JavaBeans:

Must be a top level class

Must be defined as publicCan not be final or abstractMust have a public no-argument constructor that takes no parameters.

Must not define the finalize method

Must implement the methods of the business interface


Requirements [cont.]

Similar to implementing a POJOImplement business interface

Define variables and other “internal” methods

Annotate bean with session bean type@Stateless@Stateful@Singleton


Local Stateless Bean


Remote Stateful Bean Implementation


LocalBean Singleton Bean Implementation


Summary

There are three types of session beans:Stateless - @StatelessStateful - @StatefulSingleton - @Singleton

Every session bean has:Business interface

Implementation class

Deployment descriptor information

:: QUESTION ::What is the business interface of a LocalBean?


LAB

Implement the Three versions of the Calculator

Accessing Session Beans


Section Topics


Client EJB Interactions

Using JDNI to Access EJBs

Using DI to Access EJBs

Hiding EJBs through a Session Facade


Objectives


Be able to write three common types of clients for the various types of session beans

Understand how and when a session bean instance is created

Use JNDI and DI to access a bean

Client-EJB Interactions


Quick Review of EJB interactions

EJB instance is created and managed by container

Physical EJB instance is “hidden” to client

Client interactions are performed through a proxy (sometimes called the EJBObject)


Client -> EJB Interactions

“proxy”

EJB

Client

Container


Client -> EJB Interactions [cont.]

A client for an EJB can be:A Java EE Application Client

A Java EE component (JSP, Servlet, JSF, EJB)

Any Java object

A Java application

Client finds a proxy to interact with an EJB using:

Java Naming and Directory Interfaces (JNDI)

Dependency Injection (DI)


Steps for Interacting with an EJB

3 Step Plan:

1. Declare a reference for the EJB’s interface

2. Get the EJB “instance” Using JNDI for remote clients or legacy EJBs

Using DI for local clients or application clients

3. Invoke methods on the interface

Using JNDI to Access EJBs


JNDI

Java Naming and Directory Interface is part of Java SEStandard API to interact with naming and directory servicesProvide the ability to look things up in a “registry”Used in enterprise solutions to locate resources such as EJBs, JMS queues or Web Services

JNDI resources are organized in a tree structureAnalogous to the folder structure of a computer’s file system Supports events, lookups, and complex searching against structure

JND

IDS

JND

I IMP

l

App


Key JNDI Concepts

Finding an EJB with JNDI uses four key concepts

Context

Initial Context

Path & Name

Search


JNDI Contexts

JNDI supports multiple contexts . . .. . . each containing different resources

Local context - an application can obtain access to its resources—EJBs, DataSources, etc.

Remote context - an application can also obtain access to a remote application server’s resources – remote EJBs, etc.


javax.naming.Context

Contexts contain name-to-object bindings

Interface representing a naming contextProvides methods for binding, removing, finding, etc.

Also supports environment properties


javax.naming.InitialContext

Represents the starting point for naming operations

Could be “root node”

Or, “sub node” in tree

Is an implementation of Context


Configuring the InitialContext

Use a default configuration:Context c = new InitialContext();

Programmatically control the configurationHashtable env = new Hashtable(); env.put("java.naming.factory.Initial",”…"); env.put("java.naming.provider.url",”…); Context c = new InitialContext(env);

Externalize the configuration in jndi.properties


JBoss Context Properties

Hashtable env = new Hashtable();

env.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");

env.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");

env.put("java.naming.provider.url", "localhost:1099");

Context ctx = new InitialContext(env);


Finding EJB References

Traditionally, EJB containers defined their own “naming” scheme

Varied by app server vendor

Path and entry name could be overridden in xml deployment descriptor

EJB3.1 has global JNDI Naming conventions:

qualified class namejava:global[/<app-name>]/<module-name>/<bean-name>java:app[/<module-name>]/<bean-name> java:module/<bean-name>


Global JNDI in JBoss AS

java:global/Working-with-EJB3-Tutorials/EJB3/HelloWorld!com.developintelligence.tutorials.ejb3.HelloWorld

java:global/Working-with-EJB3-Tutorials/EJB3/HelloWorld

java:app/EJB3/HelloWorld!com.developintelligence.tutorials.ejb3.HelloWorld

java:app/EJB3/HelloWorld

java:module/HelloWorld!com.developintelligence.tutorials.ejb3.HelloWorld

java:module/HelloWorld


Simple JNDI Client Example

Example represents a “stand alone” Java application

Java application uses JNDI to find a remote bean

Uses the remote reference to invoke operations


Viewing JNDI Tree in JBoss 5

http://localhost:8080/jmx-console

Click on:• Service=JNDIView


JNDIView

Click on “Invoke”


JMX MBean Operation View

Scroll down until you see …


Naming View in Jboss 7

http://localhost:9990/console/App.html#naming

http://localhost:9990/console/App.html%23naming


Simple JNDI Lookup [Glassfish]


Simple JNDI Lookup [JBoss]


Making the Stand Alone Client Work

There’s some magic to make the client work:

1. Need to bundle the “remote” interfaces of EJB in a Jar (commonly called the ejb-client-jar)

2. Need to define the JNDI properties

3. Need to bundle Java EE jars for things like UserTransaction

: : NOTE : :Some app servers provides an appserver-client.jar

to simplify #2 & #3


Simple Servlet JNDI Example

Example represents a servlet “controller”

Java application uses JNDI to find an EJB

Uses the local reference to invoke operations


Simple JNDI Servlet [Glassfish]


Simple JNDI Servlet [JBoss]


LAB: JDNI Client Labs

In this lab you will:

Write a stand-alone client

A Servlet / JSP client


Problems with JNDI

Keeping track of:

JNDI path

Bean name

Using DI to Access EJBs



Java EE 5 introduced support for dependency injection (DI)

Container can automatically “inject” references

Used commonly in context of JNDI

Based on annotations

Dependency injectionSimplifies programming

Makes access to JNDI largely transparent


Working with DI

Removes JNDI lookups; DI can be used to inject:@EJB

@Resource, @PersistenceContext, @EntityManager

Container “inserts” references based on defaultsDefault naming schemes, typing, mappingsDefaults can be over-ridden using annotation attributes

DI is supported within:Enterprise Java Beans

Servlets / JSPs / Filters / ManagedBeans

Application Client Container Clients


Key DI Annotations

@EJBUsed for DI of an EJB

Can specify additional information such as EJB’s name or beanName or lookup

@ResourceUsed for DI of non-EJBs

Specify things like SessionContext or DataSource


Working with EJB Injection

Need to understand defaultsDI attempts to inject based on context

Attempts to resolve EJB reference based type of interface

Can only have one bean bound with that type

Beyond defaultsDI attempts to inject based on context

Attempts to resolve EJB reference based on name


In-Container DI [EJB -> Servlet DI]

Hiding EJBs through a Session Facade

137

Façade Pattern Description

Intent: Provide a unified interface to a set of interfaces in

a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

Motivation: Structuring a system into subsystems helps

reduce complexity. A common design goal is to minimize the communication and dependencies between subsystems. A façade provides a single, simplified interface to the more general facilities of a subsystem.

138

Façade Real World Example

The Facade defines a unified, higher level interface to a subsystem, that makes it easier to use.

Consumers encounter a Facade when ordering from a catalog. The consumer calls one number and speaks with a customer service representative. The customer service representative acts as a Facade, providing an interface to the order fulfillment department, the billing department, and the shipping department.

139

Session Façade

Implementation of the Façade patternApplied to Enterprise JavaBeans

Façade is implemented as a Session Bean

Commonly implemented to create:Single point of entry into complex systems

Hide / abstract functionality

Web service endpoint

Session Façade could be implemented as @Local or @Remote


Session Façade Structure


Implementing a Session Facade

Simple steps to create a session façade

Create Façade interfaceExposes a limited number of methods

Potentially hides exception and data dependencies

Create Bean implementationAccesses / relies on other beans to perform operations

Generally multiple dependent operations are performed in a single interface method

Translate results / exceptions in client-neutral way


Session Façade Implementation


Façade Delegate


Summary

EJB’s are located using JNDI or DI

JNDI relies on Context, InitialContext, and lookups

DI relies on @EJB annotation


LAB: Convert JNDI Client to DI

Advanced Session Bean Concepts


Section Topics


Session Bean Identity

Session Bean Lifecycle

Implementing Lifecycle Listeners

Advanced Singleton Concepts


Objectives


Understand when and how a session bean is created

Understand uniqueness constraints of each bean type

Describe the lifecycle phases for Stateless, Stateful, and Singleton beans

Implement lifecycle call-back handlers



Can test session bean references using equals method or hashCode method

Stateless session bean identity - references of the same interface type, for the same stateless session bean, have the same object identity

@EJB MyBean bean1;@EJB MyBean bean2;

if(bean1.equals(bean1)) // trueif(bean1.equals(bean2)) //true



Stateful session bean identity – stateful beans have a unique identity that is assigned by the container at the time the object is created.


if(bean1.equals(bean1)) // trueif(bean1.equals(bean2)) //false



Singleton session bean identity – all references of the same type, for the same singleton session bean, have the same object identity


if(bean1.equals(bean1)) // trueif(bean1.equals(bean2)) //true


Session Bean Creation

Session bean instances are created and managed by container

No way for client to directly instantiate a bean

Physical EJB object creation is “hidden” from client

Session beans are created as a result of some other action

Stateless – first client lookup

Stateful – on every client lookup

Singleton – on application load


Session Bean Destruction

Session bean instance is destroyed by container

Session bean “destruction” is result of some other action

Stateless – pool clean up or inactivity

Stateful – client inactivity or remove

Singleton – application shutdown

Certain exceptions can cause beans to be destroyed (on initialization)



In between creation and destruction, a bean has a lifecycle

Lifecycles are slightly different for each type

Lifecycle allows container and developer to initialize / un-initialize bean at key times


5 Key Lifecycle Phases

@PostConstruct - after object is created

@PreDestroy – before object is removed from container

@PrePassivate – before object’s states are preserved

@PostActivate – after object’s states are resurrected

@Remove – after client signals object removal

: : NOTE : : NOT ALL SESSION BEANS GO THROUGH ALL PHASES


Stateless Session Beans

Stateless Session Bean Lifecycle

Create instance

@PostConstruct – perform initialization

Process business methods

@PreDestroy – undo initialization


Stateful Session Beans

Stateful Session Bean Lifecycle

Create instance


Process business methods@PrePassivate – prepare for serialization

@PostActivate – recover from serialization

@Remove – remove ejb from container



Stateful Session Bean Lifecycle


Singleton Session Beans

Singleton Session Bean Lifecycle

Create instance


Process business methods


Implementing Lifecycle Callback Listeners


Lifecycle Callbacks

As an EJB developer, you can receive notification as a bean transitions through each phases

Notification is done through use of a callback method

Callback methods are annotated with the appropriate lifecycle callback annotation


Implementing Callback Methods

Annotations are used to identify a callback method

A single method can handle multiple callbacks

Methods can be defined using any access modifier

Callback methods can throw runtime exceptions, but not application exceptions


Lifecycle Example


LAB: Implement Lifecycle Listeners

1. Add the remaining lifecycle methods to the Stateful bean1. @PrePassivate / @PostActivate2. Make the add method @Remove

2. Add the lifecycle methods to the Singleton and the other stateless bean

Advanced Singleton Concepts


Singleton Initialization Strategies

Two types of initialization strategies for Singletons:

Lazy – container chooses when to instantiate bean

Eager Explicitly tell container to create instance at application load

Over-rides default behavior

Implemented using the @Startup annotation


@Startup Singleton


Ordered Instantiation

Singleton bean instantiation can depend on other beans

Dependencies can be determined by container

Or, explicitly defined by developer

Uses @DependsOn annotation

:: QUESTION ::Which singleton is create first?


Summary

Each session bean has a distinct lifecycle

There are 5 lifecycle annotations@PostConstruct@PreDestroy@PrePassivate@PostActivate@Remove

Beans can receive notification of lifecycle transitions through callbacks


LAB

Implement two singletons and prove out the @Startup and @DependsOn annotation

Java Message Service

An overview of JMS


Section Topics


Introduction to Java Messaging Service (JMS)

Working with JMS

Developing a Message Producer


Objectives


Understand the advantages of using a messaging system

Describe the 5 key concepts found in messaging systems

Create a message

Publish a message to a queue

Introduction to Java Messaging Service


Overview of Messaging Systems

Function as intermediary between end-points of a system

Creates a loosely coupled system

Participants can function independent from one another

Solutions built using message are commonly referred to as MOM (message-oriented-middleware)


Key Messaging Concepts

Message – encapsulates data passed during communication

Message Producer – creator of the message

Messaging System – responsible for routing and delivery of message

Destination – delivery endpoint for message

Message Consumer – end recipient of message


What is a “Message?”

A collection of data passed in a one way (e.g., queued) communication

A message contains:Header fields: priority, timestamp, etc.

Optional message body

Optional properties


What is Java Message Service?

A Java-based messaging system

Robust messaging support:Asynchronous sending and receiving of messages

Decoupled communication between sender, receiver

Robust and transparent delivery mechanisms

Defined as an API - javax.jmsUsed by developers interacting with messaging systems

Implemented by Java EE server vendors


Destination Types

Queue TopicPoint-to-point communication Multipoint communication

Publishers emit messages to topics

Subscribers monitor topics of interest

One message is received per message sent

One published message can result in zero to many messages received

Useful for queuing some data that needs to be processed exactly once

Useful when an unknown number of observers may need to monitor the same events

Working with JMS

Creating a Message Producer


What is a Message Producer?

Message producers create messages

“Send” messages to destination through messaging system

Can be just about anything:Stand alone Java application

Java Object

Java EE Component

Legacy Systems


Key JMS API Concepts

To create a message producer, you need:

Destination

Connection

Session

MessageProducer

Message


JMS Destination

javax.jms.Destination General description of a JMS endpoint

Represents provider-specific address

javax.jms.QueueConsidered a DestinationGeneral description of a JMS Queue

javax.jms.TopicConsidered a DestinationGeneral description of a JMS Topic


Accessing a JMS Destination

Two choices to access a destination:JNDI Lookup


Dependency Injection examples:@Resource(mappedName="jms/Queue") private Queue queue;

@Resource(mappedName="jms/Topic") private Topic topic;

@Resource(mappedName="jms/Queue") private Destination topic;


JMS Connection

javax.jms.Connection - physical connection to the underlying JMS implementation

Connections are retrieved through a javax.jms.ConnectionFactory

Two types of connection factories:javax.jms.QueueConnectionFactoryjavax.jms.TopicConnectionFactory


Getting a JMS Connection

Get ConnectionFactory 1st @Resource(mappedName="jms/ConnectionFactory") private ConnectionFactory conFactory;

Get connection from factoryConnection con = conFactory.createConnection();

Close connection when donecon.close();


JMS Session

A javax.jms.Session

Describes interactions between message producer/consumer and messaging system

Is single-thread context for producing/consuming messages

Created through a Connection

Session session = con.createSession(. . .);


Session Configuration

Sessions are configured as part of creation:

createSession(txn-support, acknowledgement)

Sessions support transactionsTransacted (true): messages are not sent until the session closes

Not transacted (false): messages are sent immediately

Session support acknowledgementAUTO_ACKNOWLEDGECLIENT_ACKNOWLEDGEDUPS_OK_ACKNOWLEDGE


MessageProducer

javax.jms.MessageProducerAssociated with a specific Destination

Created from SessionMessageProducer producer = session.createProducer(destination);

MessageProducer producer = session.createProducer(queue);

MessageProducer producer = session.createProducer(topic);

Used to send messages to a Destinationproducer.send(message);


Message

javax.jms.Message described by:

Header – name-value pairs used by messaging system and message consumer

Properties – name-value pairs to specify additional information

Body – payload of the message

Type - of message being transported


Common Message Header Fields

Filed Name Set By

JMSDestination send or publish method

JMSDeliveryMode send or publish method

JMSExpiration send or publish method

JMSPriority send or publish method

JMSMessageID send or publish method

JMSTimestamp send or publish method

JMSCorrelationID Client

JMSReplyTo Client

JMSType Client

JMSRedelivered JMS provider


Message Types

Message Type Contents of Body

TextMessage String

MapMessage Name-value-pairs

ByteMessage Stream of bytes

StreamMessage Stream of Java “primitives”

ObjectMessage Serializable object

TextMessage message = session.createTextMessage(); message.setText(“Hello Messaging World”); producer.send(message);

Developing a Message Producer


Creating a Message Producer

Steps to create a Message Producer

1. Create Destination in Messaging System

2. Create Client1. Get Destination2. Create Connection3. Create Session4. Create MessageProducer5. Create Message6. Send Message7. Close Session8. Close Connection


Message Producer [Glassfish]


Message Producer [cont.]


JMS in JBoss

Connection factory Single connection factory

Can use with default destinations

Or, user created destinations

Accessed using JNDI key ConnectionFactory

DestinationsCreate using admin-console

Specify type (template), name, and JNDI path


Message Producing in JBoss

Connection Factory is:

@Resource(mappedName="ConnectionFactory”)ConnectionFactory conFactory;

Queue is:

@Resource(mappedName="HelloWorldQueue”)Queue queue;


Summary

6 Key Concepts in JMS Solutions

Message Producer

Message System

Message Consumer

Message

Destination

Session


LAB

Modify the Bean:

For every lifecycle transition that occurs:Send a text message the Queue

Specify in the message a property called “operation”

With a value “lifecycle”

For every other operation:Send a text message the Queue

Specify in the message a property called “operation”

With a value with the name of the operation


Section Topics

In this section, we will cover:

Developing a Message Driven Bean

Configuring a MDB

Message Handling


Objectives


Identify two ways to implement an MDB

Provide the appropriate configuration for an MDB using a Queue

Filter out messages using a Selector

Developing a Message Driven Bean


Message Driven Beans [MDB]

Reusable workflow logic componentsRely on Java Messaging System

Support transactions

Similar to Stateless Session BeansMDBs have no client state data

No distinction across client or bean

Different from Stateless Session BeansNo direct client access

Invoked through message notification

Asynchronous interactions


MDB Lifecyle

Very simple lifecycleCreate

@PostConstruct, @PreDestroyonMessage – when a message is delivered


Developing an MDB

Set up messaging in Java EE application server

Develop the MDB class

Configure the MDB

Process the Message

Compile, deploy and debug as discussed above


Develop the MDB

Two ways to implement an MDB

1. Inheritence-based1. MessageListener interface

2. implement onMessage method

2. Annotation-based1. Flexible implementation

2. Declare with method handles the message


Inheritance Based Example

import javax.ejb.*;import javax.jms.*;

@MessageDrivenpublic class MyMDB implements MessageListener {

public void onMessage(Message msg) { System.out.println("Got message!"); }

}


Annotation Based Example

import javax.ejb.*;import javax.jms.*;

@MessageDriven(messageListenerInterface= javax.jms.MessageListener.class)

public class MyMDB { public void onMessage(Message inMessage) { System.out.println("Got message!"); }}

Configuring a MDB


MDB Configuration

Creating an MDB with @MessageDriven is not enough

Need to configure the MDB with:Destination information

Message acknowledgement

Message selection


Destination Configuration

Simple configuration@MessageDriven(mappedName = "jms/HelloMDBQueue”)

Complete configuration@MessageDriven(activationConfig ={ @ActivationConfigProperty (propertyName="destination", propertyValue = "jms/HelloMDBQueue"), @ActivationConfigProperty (propertyName="destinationType”, propertyValue = "javax.jms.Queue") } )


Simple MDB Configuration Example


Traditional MDB Configuration Example


LAB

Build a MDBAssociate it with the HelloWorldQueue

Implement the onMessage method

Print off each message that’s received

Run the “test” servlet

Message Handling


Message Filtering

MDBs are not associated with a specific type of Message

Can receive message sent to associated DestinationNeed to filter out unwanted messages

Simple filtering performed using instanceof


Advanced Filtering

Advanced, delivery-time filtering can be performed by container

Only “matching” messages will be delivered to MDB

Matching based on headers and properties, not JMS Message type

Matching criteria defined as a Message SelectorDefined in the activationConfig attribute of @MessageDrivenDefined as an @ActivationConfigProperty named messageSelector


MDB Message Selector Example


Message Selectors

Defined as part of the activation configuration information

Use SQL-like syntax to specify criteriaWork with message headers

And developer created properties

Defined in terms of:Identifiers – part of expression being compared

Literals – hard-coded expression values

Comparison operators – comparison logic


Message Selector Identifiers

Potential identifiers for a message selector

JMS HeadersJMSDeliveryModeJMSPriorityJMSMessageIDJMSTimestampJMSCorrelationIDJMSType

JMS PropertiessetStringProperty, setBooleanPropertysetIntProperty, etc.


Message Selector Literals

Define literal values

String Enclosed in single-quotes

Apostrophe are delimited with a single-quote ‘DevelopIntelligence’’s’

Booleans – true or false

NumericsWhole numbers: 700, -743

Real number: 3.145, 9.82

Scientific: 3.5E6


Message Selector Comparison Operators

Common comparison operators:Algebraic comparison operatorsLIKE operatorBETWEEN operatorIN operatorNOT operatorIS NULL operator


Message Selector Examples

Only “add” operationsActivationConfigProperty(propertyName="messageSelector",

propertyValue = "Operation = 'add’”)}

Only “multiply” operations with a result equal to 100ActivationConfigProperty(propertyName="messageSelector",

propertyValue = "Operation = ’multiply’ AND Result = 100”)}

Only “multiply” or “add” operations with a result greater than 100ActivationConfigProperty(propertyName="messageSelector",

propertyValue = "Operation IN(’multiply’,’add’) AND Result >

100”)}


MDB Message Selector Example II


Message Acknowledgement Configuration

Default – AUTO_ACKNOWLEDGE

Non-Default Example:@MessageDriven( activationConfig={ @ActivationConfigProperty( propertyName=”acknowledgeMode”, propertyValue=“Dups-ok-acknowledge) } )


Summary

Message Driven Beans have a distinct lifecycle

Simplest way to implement an MDB@MessageDriven(mappedName=“queue/Example”)implements MessageListeneronMessage(Message m)


LAB:

Modify the MDB to only handle lifecycle messages

Advanced EJB Development


Section Topics

In this section, we will cover:

Managing Singleton Concurrency

Aspect-Oriented Programming with Interceptors

EJB Transactions

EJB Security

Web Service Development using EJBs


Objectives

When we’re done, you should be able to:

Understand how to manage concurrency in a Singleton EJB

Apply AOP to EJBs using interceptors

Identify the two types of transaction strategies

Identify a security mechanism supported in EJB

Indentify how to transform an EJB into a Web Service

Singleton Concurrency Management


Concurrent Access in Singletons

Singletons support concurrent access

Unprotected concurrent access can cause corruption

Concurrency can be managed by:CONTAINER – default

BEAN – explicit (developer)

@ConcurrencyManagement(ConcurrencyMangagementType.BEAN)


Controlling Concurrency with Locks

Container uses an Object-locking strategy Sometimes referred to as an object monitor

Conceptually similar to java.util.Lock mechanism

Default behavior is to lock object for all method operations

Obtaining a lock can be expensive

Can cause unnecessary “waiting” in caller

By default, bean access isn’t really concurrent

Can over-ride default behavior using @Lock


@Lock

Used to define method-level locking strategiesBean can have a concurrent-safe methods

Or, concurrent unsafe methods

Or, a mixture of the two

Locking strategy is applied using:@LOCK(LockType.READ) – supports concurrency

@LOCK(LockType.WRITE) – does not support concurrency

Locking strategy can be applied to:Class – defines general locking strategy for all methods

Method – defines specific locking strategy for method


Singleton Concurrency Example


Controlling Dead Lock

Deadlock - is a situation where in two or more competing actions are each waiting for the other to finish, and thus neither ever does

Deadlock can occur in every concurrent system

In singletons, may be caused by long-running operations

Manage “wait-times” using


Lab: Apply Locking to a Singleton

Aspect-Oriented Programming with Interceptors


Aspect Oriented Programming

Definition: is a programming paradigm which aims to increase modularity by allowing the separation of cross-cutting concerns

Common cross-cutting concerns:Logging, Security

Validation, Transformation

Advantages of AOPReusability

Separation of Concern

Consistency


What is an Interceptor?

Interceptor functionality enables Aspect-oriented programming within Java EE

Interceptors can be associated with methods or an entire class

Interceptors “intercept” interactions with beanCan forward the call to the bean

Can process the call directly

Can process and forward the call


Interceptor

“proxy”

EJB

Client

Container


Interceptor Characteristics

Interceptors have:

Same lifecycle as the associated bean

Their own context, known as an InvocationContext


Types of EJB Interceptors

3 Types of Interceptors

1. Business Method level interceptorsApply to a single method in a class

Or, apply to all methods in a call

2. Lifecycle Callback Interceptors

3. Timer Timeout Interceptors


Implementing a Business Method Interceptor [in EJB]

You can implement an interceptor method within an EJB

Simplest way to setup AOP in EJB

But, the concern is no longer reusable

And, you can only have one per class

@AroundInvokepublic Object anyMethodName(InvocationContext ic) throws Exception


Refactoring to an Interceptor

If every method in an EJB has code that performs same concern. . .

Consider refactoring to an internal interceptorMakes code cleaner

Potentially easier to maintain

Higher consistency of execution


Redundant Concern


Refactored Concern


Refactored Concern [cont.]


Externalizing the Concern

Better approach is to externalize the concern

Create a class that is an InterceptorDeclare a Java technology class

Include a public no-arg constructor

Declare an interceptor method class@AroundInvoke public Object methName(InvocationContext ic) throws Exception { . . }

Invokes the InvocationContext object’s proceed return ic.proceed();

Associate interceptor with EJB


Associating an Interceptor

With a class:@Stateless @Interceptors(MyInterceptor.class) public class MyBean { . . . }

With a specific method@Stateless public class MyBean { @Interceptors(MyInterceptor.class)

public void someMeth() { . . . }}


EJB with Interceptor Example


Interceptor Class


Implementing Other Interceptors

Lifecycle Interceptors

Timeout Interceptors

throws Exception {}


Interceptor Chaining

More than one inceptor can be applied to a bean or a method

This creates an interceptors chain

Class-level interceptors are executed first, then method level interceptors


Default Interceptors

May want to configure cross-cutting concerns at application level

More flexibility

Externalized from code

Default interceptors are configured in ejb-jar.xmlCan bind an interceptor to all beans or a single bean

Can specify ordering and override other interceptors


ejb-jar.xml Example


LogInterceptor Example


LAB

Create a log interceptor, defining it as a default interceptor for all ejbs deployed in the application

Transactions


Overview of Transactions

Purpose of transactions:Treat multiple operations as if they were one

All succeed together or fail together

ACID of transactions:Automicity – all operations succeed or none do

Consistency – system will be consistent before and after request

Isolation – txns are not seen outside of their scope until completed

Durability – once a txn successfully completes, client must commit to its changes


Transactions and Java EE

Two primary types of transaction management:

Container managedContainer responsible for creating, committing, and rolling back txns

Completely hidden from developer

Bean managedDeveloper responsible for creating, committing, and rolling back txns

Developer must have good understanding of Transaction API


Java EE Transaction Management

Transaction management configuration performed using either:

Annotations

XML file

Annotation-based @TransactionManagementApplied to the bean class

Default is container-managed

Strategy defined by TransactionManagementType

@TransactionManagement(TransactionManagementType.BEAN)@TransactionManagement(TransactionManagementType.CONTAINER)


CMT Transactional EJB

@TransactionManagement(CONTAINER)public class MyEJB implements MyI { . . . public void doSomething(){ . . . } . . . }


BMT Transactional EJB

@TransactionManagement(BEAN)public class MyEJB implements MyI { . . . public void doSomething(){ . . . } . . . }


Transaction Management Attributes

6 different settings relating to transaction needs:

NOT_SUPPORTED – method can not operate correctly within a txn; container possibly suspends current txn when performing operation

SUPPORTS – method can operate correctly within a txn

REQUIRED – method requires txn, but doesn’t need to be new


Transaction Management Attributes

6 different settings relating to transaction needs:

REQUIRES_NEW – method requires txn, creates new txn, possibly suspending current txn until operation completes

MANDATORY – method can only operate within txn; if method is invoked without txn, an exception is generated

NEVER – method can not operate within txn; if method is invoked within txn, an exception is generated


TransactionAttributes

Defined in TransactionAttributes

Inform container about a bean’s transaction requirements

Can be applied to an entire bean or a set of methods or both


EJB Attribute Support

Attribute Stateless Stateful Singleton MDB

NOT_SUPPORTED ✔ ✔ ✔ ✔

REQUIRED ✔ ✔ ✔ ✔

REQUIRES_NEW ✔ ✔ ✔ ✖

SUPPORTS ✔ ✔ ✔ ✖

MANDATORY ✔ ✔ ✔ ✖

NEVER ✔ ✔ ✔ ✖



All methods – REQUIRED

@TransactionAttribute(REQUIRED)public class MyEJB implements MyI { . . . public void doSomething() { . . . } . . . }



Single method – REQUIRED

public class MyEJB implements MyI { . . . @TransactionAttribute(REQUIRED) public void doSomething() { . . . } . . . }


Managing Transactions

Only BMT bean’s have direct access to txn

Hidden from CMT beansCMT can flag a txn for rollback using EJBContext’s setRollbackOnly method

Or determine if txn is going to be rolled-back using getRollbackOnly

Applications can be configured to roll back a txn automatically


LAB

Add transaction REQUIRED TransactionAttribute annotation to sayHello remote bean

Run servletShould fail

Security


Security Terms

Identity – who you are

Authentication – validating you are you who say you are

Authorization – validating you have permission to take action


Java EE & Security

Identity – can be specified as security credential

Authentication – handled by server or 3rd party

Authorization – focus of EJB security support


JSR250 Security Annotations


Configuring Authorization

Declares roles that could interact with bean@DeclareRoles( . . . )public class MyBean implements MyI { . . . }

Identify roles are allowed to interact with bean@RolesAllowed(ADMIN)public class MyBean implements MyI { . . . }

Or identify roles allowed to interact with method@RolesAllowed(ADMIN)public void doSomethingDangerous() { . . . }


Working with Roles

Can determine if caller belongs to a rolecontext.isCallerInRole(ADMIN)

Can change the role a bean operates under@RunAs(ADMIN)public class MyBean implements MyI { . . . }

EJB Web Services


EJB Web Services Support

EJB supports three types of web services:

JAX-RPCCreates Web Service Endpoints defined by WSDL

Uses SOAP as “transport” mechanism

JAX-WS“New” version of JAX-RPC

Better support for more modern web service development

JAX-RSREST-based web services

Simple to implement and use


Web Service Development

Two ways to develop web services

Manually assemble web serviceWSDL

Java Interface

Bindings

AutomaticallyTranslate an EJB into a Web Service

Annotation driven


JAX-WS Web Service Annotations

@WebServicejavax.jws.WebServiceApply to EJB class

Exposes all public methods

@WebMethodjavax.jws.WebMethodApply to specific methods to expose within bean

SOAP Configuration annotations@SOAPBinding@WebParam@WebResult


Simple Example


JAX-RS Annotations

@Path – entry point for REST service

HTTP request methods@Get@Post@Put@Delete

@Produces / @Consumes – data transfers@Produces(“application/xml”)@Consumes(“application/xml”)@Produces(“application/json”)@Consumes(“application/json”)@Produces(“text/plain”)@Consumes(“text/plain”)


Simple REST EJB


Summary

AOP can be applied using Interceptors

Transactions can be managed by the container or the bean

Java EE is focused on authorization, not authentication

Stateless and MDBs can be converted to web services with the @WebService annotation

EJB Timer Service

Timers


Section Topics

In this section, we’ll cover:

Introduction to the Timer Service

Key Steps to Developing Timed Executions

Handling Timeouts


Objectives

When we’re done, you should be able to:

Identify the corrector timer given a set of requirements

Implement a timer callback

Manage a timer

Introduction to Timer Service


Java EE Timer Service

Timers in Javajava.util.Timer javax.swing.Timerjavax.management.timer.Timerjavax.ejb.Timer & javax.ejb.TimerServices

TimerService introduced as part of EJB 2.1Considered a core service

Provides scheduled, automatic execution

No real-time scheduling


javax.ejb.TimerService

Container provided timer serviceCan be used with Session and Message driven beans

Modeled after long-lived processes (survivability after crashes)

Supports three types of TimersNon-Interval (ie: in 5 minutes)

Interval (ie: every 5 minutes)

Scheduled (ie: every 5 minutes on Mondays)

Timer notificationStructured around a timeout callback

Callback invoked when Timer times-out

Key Steps to Developing Timed Executions


Steps to Building Timed Execution

1. Access the Timer Service

2. Schedule Timer

3. Process timeout expiration

4. Manage lifecycle of timer


Accessing the TimerService

Can use either JNDI or DI

@Resource private TimerService ts;


Schedule a Timer

Create a Timer

Single Action Timer – occurs 1 time onlyts.createTimer(delay,object);

Interval-based Timer – executes on intervalsts.createTimer(delay,interval, object);

Calendar-based timer using a schedulets.createCalendarTimer(schedule);


Process Timeout Expiration

Handle timeout (version 1)@Timeout public void listOrders(Timer timer) { String name = timer.getInfo(); // do something fancy}

Handle timeout (version 2)@Timeout public void listOrders() { // do something fancy}


Process Timeout Expiration

Handle timeout (version 3)EJB2.1 style

Implement javax.ejb.TimedObjectMust implement ejbTimeout method

:: QUESTION ::Which approach should you use, and why?


Simple Timer Example

Automatic Timers


Scheduled Timers

Timer Service supports UNIX cron-job like schedules

Defined through a ScheduleExpression

ScheduleExpression schedule = new ScheduleExpression();//define schedule . . .timerService.createCalendarTimer(schedule);


Defining Schedules

Schedules consist of 7 attributes:

Time componentssecond – [0,59]minute – [0,59]hour – [0,23]

Calendar components: dayOfMonth – [1,31],”Last”, “Sun”, “Mon”, “Tue”, etc.

month – [1,12], “Jan”, “Feb”, “Mar”, etc.

dayOfWeek – [0,7], “Mon”, “Tue”, etc.

year – [2001]


Schedule Examples

Every Tuesday at MidnightScheduleExpression schedule = new ScheduleExpression();schedule.setDayOfWeek(“Tue”);schedule.setHour(“0”);

Every Weekday at 3:15 AMScheduleExpression schedule = new ScheduleExpression();schedule.setDayOfWeek(“Mon-Fri”);schedule.setHour(“3”);schedule.setMinute(“15”);

Every 15 minutes of Every Hour Every DayScheduleExpression schedule = new ScheduleExpression();schedule.setHour(“*”);schedule.setMinute(“*/15”);


Automatic Creation of Timers

@Schedule annotation is interpreted by container

Automatically creates a ScheduleExpressionRegisters ScheduleExpression with TimerService

Apply @Schedule to a method in an EJBCan have multiple per Bean

Method functions as timeout callback

@Schedule(dayOfWeek=“Mon”)public void listOrders(Timer timer) { // do something fancy}

Working with Timers


Persistent Timers

Survive crash of JVM / Application Server

Can configure timers to be non-persistent

Must explicitly define a timer as non-persistentProgrammatically using TimerConfigAutomatically using @Schedule


Timer Management

Timers references can be:Stored as a result of a create call

Retrieved from the TimerServiceRetrieved from the callback

Timer management is performed on the TimergetInfogetHandlegetNextTimeoutgetTimeRemainingcancel


Summary

Timers can be used to execute automated tasks

The functionality of a method or a bean can be augmented through an interceptor


Lab: Create an Automatic Timer

java ee ejb applications

Technology

java ee containers java

history of java ee java

use of java ee

original java design

java ee ejb applications

java ee platform apis

programming model java

java ees