Java™ EE 5 Platform

Sang Shin, Sun Microsystems

Java™ Technology Architect

1
Courses I Teach
● J2EE programming (with Passion!)
● Web services programming (with
Passion!)
● XML

All course materials (and today's

presentation) are available from
– www.javapassion.com
2
Agenda
● Java EE 5 Theme: Ease of development
● EJB 3.0
– Programming model
– Persistence
● JAXB 2.0
● JAX-WS 2.0(Used to be called JAX-RPC)
● JavaSever Faces 1.2
● JBI 1.0 (Java Business Integration) & SOA
– Not part of Java EE 5
3
The J2EE Challenge
TM

● J2EE is enormously powerful

– The industry standard for robust enterprise apps
● But that power sometimes gets in the way
– Too difficult to get started
– Even simple apps need boring boilerplate

● Can we keep the power, but make typical

development tasks simpler?

● YES: and that is the focus of Java EE 5! 4

EoD Improvements in Java EE 5 TM

● POJO-based programming
– More freedom, fewer requirements
● Extensive use of annotations
– Reduced need for deployment descriptors
● Resource Injection
– Inversion of control
● New APIs and frameworks

5
Annotations in Java EE 5 TM

● Making extensive use of annotations

– For defining and using web services
– To map Java classes to XML
– To greatly simplify EJB development
– To map Java classes to databases
– To specify external dependencies
– To reduce need for deployment descriptors

6
Java EE 5 Major Features
TM

● Simplified web services support

● More web service standards support
● Greatly simplified EJBTM development
● New persistence API
● Easy web applications with JavaServerTM Faces

7
Java EE 5 Platform
● JSR 220 (EJB 3.0)
● JSR 224 (JAX-WS 2.0)
● JSR 222 (JAXB 2.0)
● JSR 252 (JavaServer Faces 1.2)
● JSR 52 (JSTL 1.1)
● JSR 181 (WS Annotations)
● JSR 245 (JSP 2.1)

8
EJB 3.0

9
Primary Goal of EJB 3.0

Ease of Development!

10
EJB 2.1
● Very powerful, but complex to use
– Too many classes, interfaces
– Java Naming and Directory Interface™
(JNDI) API lookups
– javax.ejb interfaces
– Awkward programming model
– Deployment descriptors
– Entity bean anti-patterns
– ...

11
Ease of Development in EJB 3.0
● Makes EJB technology easier to learn and use
– Fewer classes and interfaces
– Dependency injection
– Simple lookups
– No required container interfaces
– No required deployment descriptor
– Simplified persistence
– Object/relational mapping
● Improves developer productivity
– Designed to draw new developers to J2EE platform
12
Compatibility and Migration
● All existing applications continue to work
● Provides integration path for preexisting
applications and components
● Allows components to be updated or replaced
(using EJB 3.0 APIs) without affecting existing
clients
● Facilitates EJB 3.0 technology adoption
with incremental migration

13
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
– Elimination of need for deployment descriptors
● Utilizes advantages of Java language metadata
– Leverages defaulting for typical cases
– Metadata designed so that the most common
cases are the easiest to express

14
EJB 3.0 Approach
● More work is done by container, less by
developer
● Inversion of contracts
– Bean specifies what it needs through metadata
● No longer written to unneeded container interfaces
– Container interpositions to provide requested
services

15
Simplification of EJB Bean Types
● Elimination of requirement for EJB component
interfaces
– Business interfaces are plain Java interfaces
● Elimination of requirements for Home interfaces
– Only need business interface, not home
● Elimination of requirements for
javax.ejb.EnterpriseBean interfaces
– Annotations for (optional) callbacks
● Elimination of need for use of JNDI API
– Use dependency injection, simple lookup method 16
EJB 2.1 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”);
}
17
 EJB 2.1 Example
// EJB 2.1 (cont.)

public void ejbActivate() {}

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

public void setBenefitsDeduction (int empId, double

deduction) {
...
Connection conn = empDB.getConnection();
...
}
...
}

// NOTE deployment descriptor needed

18
EJB 2.1 Example
<session>
<ejb-name>PayrollBean</ejb-name>
<local-home>PayrollHome</local-home>
<local>Payroll</local>
<ejb-class>com.example.PayrollBean</ejb-class>
<session-type>Stateless</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>
19
EJB 3.0 Example
// Same example, EJB 3.0

@Stateless public class PayrollBean

implements Payroll {

@Resource DataSource empDB;

public void setBenefitsDeduction (int empId, double

deduction) {
...
Connection conn = empDB.getConnection();
...
}

...
}
20
Dependency Injection
● Resources a bean depends upon are injected
when bean instance is constructed
● References to:
– EJBContext
– DataSources
– UserTransaction
– Environment entries
– EntityManager
– TimerService
– Other EJB beans
– ... 21
Dependency Injection
● Annotations
– @EJB
● References to EJB business interfaces
● References to Home interfaces (when accessing
EJB 2.1 components)
– @Resource
● Almost everything else
– Number of annotations is simplified from EJB 3
specification early draft
● Injection can also be specified using deployment
descriptor elements 22
Dynamic Lookup
● Dynamic lookup is simplified as well
● JNDI APIs are removed from developer’s view
● Dependencies are expressed at level of
bean class
● EJBContext.lookup method is used at runtime

23
Example
@Resource(name=”myDB”, type=javax.sql.DataSource)
@Stateful public class ShoppingCartBean
implements ShoppingCart {

@Resource SessionContext ctx;

public Collection startToShop (String productName) {

...
DataSource productDB =
(DataSource)ctx.lookup(“myDB”);
Connection conn = myDB.getConnection();
...
}

...
}
24
Simplified Client View
● Session beans have plain Java language business
interface
– No more EJB(Local)Home interface
– No more EJB(Local)Object interface
● Bean class implements interface
– Looks like normal Java class to bean developer
● Looks like normal Java language interface
to client (POJI)

25
EJB 2.1 Client Example
// EJB 2.1 Client view of the ShoppingCart bean

...
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 code to handle javax.ejb.CreateException

...
26
EJB 3.0 Client Example
// EJB 3.0 client view

@EJB ShoppingCart myCart;

...

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

...

27
Container Services: Transactions
Container-managed transaction (CMT) by default
Bean-managed transaction (BMT) by annotation
● 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
28
EJB 3.0 Transaction Example
// Uses container-managed transction, REQUIRED attribute

@Stateless public PayrollBean implements Payroll {

public void setBenefitsDeduction(int empId, double

deduction) {...}

public double getBenefitsDeduction(int empId) {...}

public double getSalary(int empId) {...}

public void setSalary(int empId, double salary) {...}

29
EJB 3.0 Transaction Example
@Stateless public PayrollBean implements Payroll {

@TransactionAttribute(MANDATORY)
public void setBenefitsDeduction(int empId, double
deduction) {...}

public double getBenefitsDeduction(int empId) {...}

public double getSalary(int empid) {...}

@TransactionAttribute(MANDATORY)
public void setSalary(int empId, double salary) {...}

30
Container Services: Security
● Security configuration typically done at
deployment in enterprise environments
– 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
methods of the class
● Specified at method level => applies to method
(overriding any class-level specification)
● @Unchecked, @RolesAllowed 31
EJB 3.0 Security Example
// Security view

@Stateless public 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) {...}

}
32
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... just become special cases
● Callback methods can be specified on lifecycle
listener class instead of on bean class
33
EJB 3.0 Event Notification Example
@Stateful public class AccountManagementBean
implements AccountManagement {

Socket cs;

@PostConstruct
@PostActivate
public void initRemoteConnectionToAccountSystem {
...
}

@PreDestroy
@PrePassivate
public void closeRemoteConnectionToAccountSystem {
...
}
...
} 34
Interceptors
● Ease of use facility for more advanced developers
● Interception of invocations of business methods
and/or 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 invocation chain
– Execute in specified order
– Can use deployment descriptor to override order
or add interceptors 35
Interceptors (Cont.)
● Annotations
– @Interceptors, @AroundInvoke
● We debated “around” methods vs. “before/after”
methods
● Around methods
● More powerful control model

● Cleaner exception handling

● Before/after methods
● More behavior through side-effects

● Under consideration: method-level interceptors

36
Example
@Interceptors({
com.acme.AccountAudit.class,
com.acme.Metrics.class,
com.acme.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) {...}
...
}
37
EJB 3.0/2.x Technology
Interoperability and Migration
● Applications written to EJB 2.1 specification and
earlier work unchanged in EJB 3.0 containers
● Migration path to EJB 3.0 APIs
– New applications can be clients of older beans
● Made easier than with EJB 2.1 client view model
– Older clients can be clients of new EJB 3.0
components
● Without change to preexisting client view
● Many EJB 3.0 ease-of-use features available for
components written to EJB 2.1 view
– Injection; interceptors; transaction and security
annotations; defaults; callback annotations; ...
38
EJB 3.0 Client/EJB 2.1 Component
● Beans written to new APIs can be clients
of older beans
– Reuse existing components in new applications
– Allows piecemeal migration of applications
– Injection of Homes simplifies client view

39
Example
// EJB 3.0 client view of 2.1 bean

...
@EJB ShoppingCartHome cartHome;

Cart cart = cartHome.create();

cart.addItem(...);
...
cart.remove();
...

40
EJB 2.1 Client/EJB 3.0 Component
● Older beans written to EJB 2.1 client view
can talk to new components
– Allows server components to be updated or
replaced without affecting existing clients
– New beans can support EJB 3.0 clients as well
as earlier clients
– Home and component interfaces are mapped to
EJB 3.0 bean class
– New EJB 3.0 components can support both
EJB 2.1 clients and EJB 3.0 clients
41
Example
// EJB 2.1 client view of 3.0 bean

...
Context initialContext = new InitialContext();
ShoppingCartHome myCartHome = (ShoppingCartHome)
initialContext.lookup(“java:comp/env/ejb/cart”);
ShoppingCart cart= myCartHome.create();
cart.addItem(...);
...
cart.remove();
...

42
Annotations vs.
Deployment Descriptors
● Annotations
– Make deployment descriptors unnecessary
– Default cases don’t need to be specified
– Commonly used cases can be specified easily
● Deployment descriptors remain available
as alternative
– Some developers prefer descriptors
– Descriptors can be used to externalize metadata
– Can be used to override metadata annotations
● Descriptors can be “sparse” or “full” 43
EJB 3.0

Persistence

44
Persistence Goals of EJB 3.0
● Simplify entity bean programming model
● Support for light-weight domain modeling,
including:
– Inheritance and polymorphism
● Complete query capabilities
● Support for object/relational mapping
specification
● Make entity instances usable outside the EJB
container
– Remove need for DTOs and similar antipatterns 45
Where We Are
● Persistence API expanded to include use
outside of J2EE platform-based containers
● Evolution into “common” Java persistence API
– Merger of expertise from Hibernate, Java Data
Objects, TopLink, EJB technology vendors and
individuals
– API draws from all of these sources
● Support for pluggable third-party persistence
providers

46
Persistence Model in EJB 3.0
● Entities are simple Java classes
– Concrete classes—support use of new
– Getter/setter “property” methods or persistent
instance variables
– No required bean interfaces
– No required callback interfaces
● Usable as “detached” objects in other
application tiers
– No more need for DTOs

47
EntityManager
● EntityManager serves as untyped “home”
for entity operations
– Methods for lifecycle operations
● Persist, remove, merge, flush, refresh, etc.
– Similar in functionality to Hibernate Session,
JDO PersistenceManager, etc.
– Manages persistence context
● Both transaction-scoped and extended persistence
contexts

48
Persistence Focus: O/R Mapping
● Ease-of-use facility for Java developers
mapping domain object model to a relational
database
● Developer is aware of mapping between
DB schema and domain object model
– Developer is in control of mapping
– Developer can rely on mapping and its semantics
● Mappings may be expressed using metadata
annotations or XML
– Default mappings provided
49
Persistence Beyond the
EJB 3.0 Architecture
● Persistence technology now usable in
J2SE platform-based environments
– Container-managed environments
● Leverage container services for simplification

and ease of use

– Application-managed environments
● Explicit control over EntityManager,

EntityManagerFactory
● API for management of resource transactions

– APIs for application-managed EntityManagers

can also be used in EJB containers
50
Current Status
● Public draft released June, 2005
● Three (3) public draft documents
● EJB Simplified API
● Java Persistence API
● EJB Core Contracts and Requirements
● Several “preview” releases now available

51
Web Services: JAX-WS, JAXB

52
Java Support for Web Services
● JAX-RPC 2.0 renamed to JAX-WS 2.0 (Java API for
XML Web Services)
● Implements new WS stack
– JAX-WS 2.0 and JAXB 2.0
– Designed for growth (JAX-WSA, others)
● Heavy use of annotations
– Ease-of-development
– Portability
● Supports Fast Infoset
– Better Performance 53
JAX-WS and JAXB Integration
● JAX-WS delegates all data binding to JAXB
● Development time
– JAXB generates Java types from a WSDL’s schemas
– JAXB generates the WSDL’s schema from Java types
● Runtime
– JAX-WS un/marshalls the message (soap:envelope)
– JAXB un/marshalls the payload (soap:body child,
soap:header and soapfault elements)
– StAX based parser is the handoff
54
 Division of Labor
<soapenv:Envelope xmlns:soapenv=...>
<soapenv:Header>
<ns1:age xmlns:ns1="http://foo">33</ns1:name>
</soapenv:Header>
<soapenv:Body>
<ans:getRecord
JAX-WS xmlns:ans="http://echo.org/"> JAXB
<first>Fred</first>
<last>Jones</last>
</ans:getRecord>
</soapenv:Body>
</soapenv:Envelope>

55
JAXB 2.0

56
JAXB 2.0 Is Now Bi-Directional
● 1.0: Schema Java only
– JAXB is for compiling schema
– Don’t touch the generated code

● 2.0: Java XML + schema compiler

– JAXB is about persisting POJOs to XML
– Annotations for controlling XML representation
– Modify the generated code to suit your taste

57
Simple Development Model
● Follow three easy steps
– Compile a schema (optional)
– Compile your code by javac
– Ship your app and run it
● No post-processing of byte code
● No deployment step

58
JAX-WS 2.0

59
JAX-RPC 1.1 RI Issues
● Supports only SOAP 1.1over HTTP
● Limited XML Schema support
● Little Control of Mapping Java and WSDL/
XML Schema
● Large non-portable applications
● Large runtime
● Web Service development is too complex
● Servlet container is required
60
JAX-WS 2.0 RI
● New Architecture
● Improved Data Binding
● Annotations
● Java SE 6 Endpoints

61
JAX-WS 2.0 New Architecture
● Multiple protocols
– SOAP 1.1, SOAP 1.2, XML
● Multiple encodings
– XML, MTOM/XOP, FAST Infoset (Binary XML)
● Multiple transports
– HTTP
– Others to be added in future releases

62
Improved Data Binding
● JAX-RPC 1.1 Issues
– Defines its own data binding rules
– Only a portion of XML Schema supported
– javax.xml.soap.SOAPElement (DOM)
– No control of the generated Java SEI
● JAX-WS 2.0
– Uses JAXB 2.0 for data binding (100% XML Schema)
– Very few DOM-like mappings
– Customizations to control the generated SEI
63
Customizations in WSDL/XML
Schema to Java Mapping
● JAXB customizations
– XML Schema to Java
● JAX-WS customizations
– Similar to JAXB customizations
– WSDL to Java
● Can live
– In-lined in the WSDL as WSDL extension
– As external file (pass to JAX-WS tools)

64
Customizations Example
<jaxws:bindings
wsdlLocation="http://localhost:8080/math/add?WSDL"
xmlns:jaxws="http://java.sun.com/xml/ns/jaxws"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

<jaxws:bindings node="wsdl:definitions">
<!-- generate artifacts in math.client package -->
<jaxws:package name="math.client"/>
</jaxws:bindings>

<!-- rename SEI class name -->

<jaxws:bindings node="wsdl:definitions/wsdl:portType
[@name='AddNumbersImpl']">
<jaxws:class name="MathUtil"/>
</jaxws:bindings>
</jaxws:bindings> 65
Annotations for Web Services
Development
● More Control of mapping to WSDL/XML Schema
● Dynamic Runtime
– No more Stubs/Ties
– No more serialiers/deserializers
– Smaller and faster applications
– Portability
● Simplifies Web Service development
– No config.xml and simpler command line tools
– No more wsdeploy
66
Control of Mapping to WSDL/
XML Schema
public interface BrokerIF extends Remote {
public float getStockQuote(String tickerSymbol)
throws RemoteException;
}

<complexType name="getStockQuote">
<sequence>
<element name="String_1" type="string"/></sequence>
</complexType>
...
<portType name="BrokerIF">
...
<operation name="getStockQuote">
... Comes from config.xml
<service name="Hello_Service">
... 67
JBI 1.0: Foundation for SOA

68
 What Is SOA?
Roles
A set of services that a business wants to
expose to customers and clients
Business

An architectural style which requires a

service provider, requestor and a
service description
A set of architectural principles and patterns Architecture
which address characteristics such as
modularity, encapsulation, loose coupling,
separation of concerns, reuse, composable
and single implementation

A programming model complete with

standards, tools, methods and technologies Implementation
such as web services
69
 s i gn
De used
SOA Architectural Principles Foc
Coarse Grained Business Services XML Document-based

Mostly Async Conversational

70
 l i t ies
SOA Architectural Principles Qua used
Foc
Reliable Secure/Identity

Policy Driven Registered and Retrieved

71
 a r ds
nd sed
SOA Architectural Principles t a
S cu
Fo
WSDL Described BPEL Orchestrated

JBI-based

72
What is JBI (JSR-208)?
● JBI does for application integration what J2EE
did for application development
– One of the biggest motivation for SOA is to reduce
the cost of application integration
● Open, pluggable infrastructure for integrating
applications
● Standards-based way to build an Enterprise
Service Bus (ESB) for the Java platform

73
Why JBI?

● Standard framework
– Solves M * M adaptors (connectors) problem for
application integration
● Vendor independent integration framework
– Integration components from multiple vendors can
be plugged-in
– Portability with innovation in implementation
● Standard service description via WSDL
– Abstract, technology-neutral model of services
– De-coupling of interface from implementation 74
Scope of JBI Specification
● Standard framework for pluggable
– Service Engines (SE's)
– Binding Components (BC's)
● Defining abstract communication protocol-neutral
Normalized Message Service (NMS)
● Standard mechanism for Normalized Messages to
flow between Binding Components and Process
Engines
● Standard for the packaging and deployment of
SE's and BC's
75
JBI Architecture

76
Current Status
● JBI specification finalized (2005)
● JBI SDK 1.0 is available now
– java.sun.com/integration
● How to build service component tutorial
– java.sun.com/integration/reference/techart/

77
JavaServer Faces 1.2

78
JavaServer™ Faces (JSF)
Framework Is…
A server side user interface (UI)
component framework for Java™
technology-based web
applications.

Drag-and-drop UI components to
build a web Application.

79
JSF Architecture
Server
JSF Page
HTML
Desktop
HTML
Browser RenderKit

Front App
ctrl JSF Page Backend

WML
RenderKit
Phone
WML

80
Important Basic Capabilities
● Extensible UI component model
● Flexible rendering model
● Event handling model
● Validation framework
● Basic page navigation support
● Internationalization
● Accessibility
● Tool friendly
81
This presentation is available
from www.javapassion.com!

82