1

Java™ EE 5 PlatformSang Shin, Sun MicrosystemsJava™ Technology Architect

2

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

3

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

4

The J2EETM Challenge● 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!

5

EoD Improvements in JavaTM EE 5

● 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

6

Annotations in JavaTM EE 5

● 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

7

JavaTM EE 5 Major Features

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

8

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)

9

EJB 3.0

10

Primary Goal of EJB 3.0

Ease of Development!

11

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

– ...

12

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

13

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

14

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

15

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

16

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

17

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”);}

18

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

19

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>

20

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(); ...}

...}

21

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

– ...

22

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

23

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

24

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(); ...}

...}

25

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)

26

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...

27

EJB 3.0 Client Example// EJB 3.0 client view

@EJB ShoppingCart myCart;

...

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

...

28

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

29

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

}

30

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

}

31

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

32

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

}

33

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

34

EJB 3.0 Event Notification Example@Stateful public class AccountManagementBean implements AccountManagement {

Socket cs;

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

@PreDestroy @PrePassivate public void closeRemoteConnectionToAccountSystem { ... } ...}

35

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

36

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

37

Example@Interceptors({ com.acme.AccountAudit.class, com.acme.Metrics.class, com.acme.CustomSecurity.class})@Statelesspublic 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) {...} ...}

38

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; ...

39

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

40

Example// EJB 3.0 client view of 2.1 bean

...@EJB ShoppingCartHome cartHome;

Cart cart = cartHome.create();cart.addItem(...);...cart.remove();...

41

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 wellas 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

42

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();...

43

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”

44

EJB 3.0

Persistence

45

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

46

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

47

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

48

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

49

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

50

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

51

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

52

Web Services: JAX-WS, JAXB

53

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

54

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

55

Division of LaborDivision of Labor<soapenv:Envelope xmlns:soapenv=...> <soapenv:Header> <ns1:age xmlns:ns1="http://foo">33</ns1:name> </soapenv:Header> <soapenv:Body> <ans:getRecord xmlns:ans="http://echo.org/"> <first>Fred</first> <last>Jones</last> </ans:getRecord> </soapenv:Body></soapenv:Envelope>

JAXBJAX-WS

56

JAXB 2.0

57

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

58

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

59

JAX-WS 2.0

60

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

61

JAX-WS 2.0 RI

● New Architecture● Improved Data Binding● Annotations ● Java SE 6 Endpoints

62

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

63

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

64

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)

65

<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>

Customizations Example

66

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

67

Control of Mapping to WSDL/XML Schemapublic 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">...<service name="Hello_Service">...

Comes from config.xml

68

JBI 1.0: Foundation for SOA

69

Business

Architecture

Implementation

A set of services that a business wants to expose to customers and clients

An architectural style which requires a service provider, requestor and a service description

A set of architectural principles and patterns 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 such as web services

Roles

What Is SOA?

70

SOA Architectural PrinciplesCoarse Grained Business Services XML Document-based

Mostly Async Conversational

Design

Focused

71

Reliable Secure/Identity

Policy Driven Registered and Retrieved

SOA Architectural Principles Qualities

Focused

72

Standards

Focused

WSDL Described BPEL Orchestrated

SOA Architectural Principles

JBI-based

73

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

74

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

75

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

76

JBI Architecture

77

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/

78

JavaServer Faces 1.2

79

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.

80

JSF Architecture

HTML RenderKit

AppBackend

DesktopBrowser

Phone

Frontctrl

JSF Page

JSF Page

WML

HTML

Server

WML RenderKit

81

Important Basic Capabilities

● Extensible UI component model● Flexible rendering model● Event handling model● Validation framework● Basic page navigation support● Internationalization● Accessibility● Tool friendly

82

This presentation is available from www.javapassion.com!