Sang Shin, Sun Microsystems: Java™ Technology Architect
Sang Shin, Sun Microsystems: Java™ Technology Architect
1
Courses I Teach
● J2EE programming (with Passion!)
● Web services programming (with
Passion!)
● XML
● 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
6
Java EE 5 Major Features
TM
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
SessionContext ctx;
DataSource empDB;
...
}
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 {
...
}
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();
...
...
...
27
Container Services: Transactions
Container-managed transaction (CMT) by default
Bean-managed transaction (BMT) by annotation
● Container-managed transactions
29
EJB 3.0 Transaction Example
@Stateless public PayrollBean implements Payroll {
@TransactionAttribute(MANDATORY)
public void setBenefitsDeduction(int empId, double
deduction) {...}
@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
}
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
● Before/after methods
● More behavior through side-effects
39
Example
// EJB 3.0 client view of 2.1 bean
...
@EJB ShoppingCartHome cartHome;
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
EntityManagerFactory
● API for management of resource transactions
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
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>
<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
70
l i t ies
SOA Architectural Principles Qua used
Foc
Reliable Secure/Identity
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