Вы находитесь на странице: 1из 82

Java™ EE 5 Platform

Sang Shin, Sun Microsystems

JavaTechnology Architect

Java™ EE 5 Platform Sang Shin, Sun Microsystems Java ™ Technology Architect 1

Courses I Teach

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

J2EE programming (with Passion!)

Web services programming (with Passion!)

XML

All course materials (and today's presentation) are available from www.javapassion.com

Agenda

Agenda ● Java EE 5 Theme: Ease of development ● EJB 3.0 – Programming model –

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

The J2EE TM Challenge

The J2EE T M Challenge ● J2EE is enormously powerful – The industry standard for robust

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 T M EE 5 ● POJO-based programming – More freedom, fewer

EoD Improvements in Java TM 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

Annotations in Java T M EE 5 ● Making extensive use of annotations – For

Annotations in Java TM 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

Java T M EE 5 Major Features ● Simplified web services support ● More web

Java TM EE 5 Major Features

Simplified web services support

More web service standards support

Greatly simplified EJB TM development

New persistence API

Easy web applications with JavaServer TM Faces

Java EE 5 Platform

Java EE 5 Platform ● JSR 220 (EJB 3.0) ● JSR 224 (JAX-WS 2.0) ● JSR

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)

EJB 3.0

EJB 3.0 9
Primary Goal of EJB 3.0 Ease of Development! 10

Primary Goal of EJB 3.0

Ease of Development!

EJB 2.1

EJB 2.1 ● Very powerful, but complex to use – Too many classes, interfaces – Java

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

Ease of Development in EJB 3.0 ● Makes EJB technology easier to learn and use

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

Compatibility and Migration ● All existing applications continue to work ● Provides integration path for

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

EJB 3.0 Approach

EJB 3.0 Approach ● Simplification of the EJB APIs – Removal of need for EJBHomes and

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

EJB 3.0 Approach

EJB 3.0 Approach ● More work is done by container, less by developer ● Inversion of

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

Simplification of EJB Bean Types ● Elimination of requirement for EJB component interfaces – Business

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

EJB 2.1 Example // EJB 2.1 public class PayrollBean implements javax.ejb.SessionBean { SessionContext ctx; DataSource

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 ejbPassivate() {} public void ejbRemove() {} public void setBenefitsDeduction (int empId, double

public void setBenefitsDeduction (int empId, double deduction) {

Connection conn = empDB.getConnection();

}

}

// NOTE deployment descriptor needed

EJB 2.1 Example

<session>

EJB 2.1 Example <session> <ejb-name>PayrollBean</ejb-name>

<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

EJB 3.0 Example // Same example, EJB 3.0 @Stateless public class PayrollBean implements Payroll { @Resource

@Stateless public class PayrollBean implements Payroll {

@Resource DataSource empDB;

public void setBenefitsDeduction (int empId, double deduction) {

Connection conn = empDB.getConnection();

}

}

Dependency Injection ● Resources a bean depends upon are injected when bean instance is constructed

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

Dependency Injection ● Annotations – @EJB ● References to EJB business interfaces ● References to

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 ● Dynamic lookup is simplified as well ● JNDI APIs are removed from developer’s

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

Example

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

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

}

}

Simplified Client View ● Session beans have plain Java language business interface – No more

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)

EJB 2.1 Client Example // EJB 2.1 Client view of the ShoppingCart bean Context initialContext

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

EJB 3.0 Client Example // EJB 3.0 client view @EJB ShoppingCart myCart; Collection widgets =

EJB 3.0 Client Example

// EJB 3.0 client view

@EJB ShoppingCart myCart;

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

Container Services: Transactions Container-managed transaction (CMT) by default Bean-managed transaction (BMT) by

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

EJB 3.0 Transaction Example // Uses container-managed transction, REQUIRED attribute @Stateless public PayrollBean

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

}

}

EJB 3.0 Transaction Example @Stateless public PayrollBean implements Payroll { @TransactionAttribute(MANDATORY) public

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

}

}

Container Services: Security ● Security configuration typically done at deployment in enterprise environments –

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

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

}

}

Container Services: Event Notification ● Container calls bean upon lifecycle events – @PostConstruct –

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

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

EJB 3.0 Event Notification Example

@Stateful public class AccountManagementBean implements AccountManagement {

Socket cs;

@PostConstruct @PostActivate public void initRemoteConnectionToAccountSystem {

}

@PreDestroy @PrePassivate public void closeRemoteConnectionToAccountSystem {

}

Interceptors

Interceptors ● Ease of use facility for more advanced developers ● Interception of invocations of business

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 (Cont.) ● Annotations – @Interceptors, @AroundInvoke ● We debated “around” methods vs.

@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

Example

@Interceptors({

com.acme.AccountAudit.class,

com.acme.Metrics.class,

com.acme.CustomSecurity.class

com.acme.Metrics.class, com.acme.CustomSecurity.class }) @Stateless public class AccountManagementBean implements

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

}

}

}

}

EJB 3.0/2.x Technology Interoperability and Migration ● Applications written to EJB 2.1 specification and earlier

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;

EJB 3.0 Client/EJB 2.1 Component ● Beans written to new APIs can be clients of

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

Example

Example // EJB 3.0 client view of 2.1 bean @EJB ShoppingCartHome cartHome; Cart cart = cartHome.create();

// EJB 3.0 client view of 2.1 bean

@EJB ShoppingCartHome cartHome;

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

cart.remove();

EJB 2.1 Client/EJB 3.0 Component ● Older beans written to EJB 2.1 client view can

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

Example

Example // EJB 2.1 client view of 3.0 bean Context initialContext = new InitialContext(); ShoppingCartHome myCartHome

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

Annotations vs. Deployment Descriptors ● Annotations – Make deployment descriptors unnecessary – Default cases

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

EJB 3.0 Persistence 44
Persistence Goals of EJB 3.0 ● Simplify entity bean programming model ● Support for light-weight

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

Where We Are

Where We Are ● Persistence API expanded to include use outside of J2EE platform-based containers ●

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

Persistence Model in EJB 3.0 ● Entities are simple Java classes – Concrete classes—support use

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

EntityManager

EntityManager ● EntityManager serves as untyped “home” for entity operations – Methods for lifecycle operations

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

Persistence Focus: O/R Mapping ● Ease-of-use facility for Java developers mapping domain object model to

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

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

Current Status

Current Status ● Public draft released June, 2005 ● Three (3) public draft documents ● EJB

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

Web Services: JAX-WS, JAXB 52

Web Services: JAX-WS, JAXB

Java Support for Web Services ● JAX-RPC 2.0 renamed to JAX-WS 2.0 (Java API for

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

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

DDiivivissiionon ofof LaLaborbor <soapenv:Envelope xmlns:soapenv= > <soapenv:Header> <ns1:age

DDiivivissiionon ofof LaLaborbor

<soapenv:Envelope xmlns:soapenv=

>

<soapenv:Header> <ns1:age xmlns:ns1="http://foo">33</ns1:name> </soapenv:Header>

<soapenv:Body>

</soapenv:Header> <soapenv:Body> <ans:getRecord JAX-WS JAXB
</soapenv:Header> <soapenv:Body> <ans:getRecord JAX-WS JAXB

<ans:getRecord

JAX-WS

<soapenv:Body> <ans:getRecord JAX-WS JAXB xmlns:ans="http://echo.org/">

JAXB

xmlns:ans="http://echo.org/">

<first>Fred</first>

<last>Jones</last>

</ans:getRecord>

</soapenv:Body>

</soapenv:Envelope>

JAXB 2.0

JAXB 2.0 56
JAXB 2.0 Is Now Bi-Directional ● 1.0: Schema Java only – JAXB is for compiling

JAXB 2.0 Is Now Bi-Directional

1.0: Schema

JAXB 2.0 Is Now Bi-Directional ● 1.0: Schema Java only – JAXB is for compiling schema

Java only

JAXB is for compiling schema

Don’t touch the generated code

2.0: Java

schema – Don’t touch the generated code ● 2.0: Java XML + schema compiler – JAXB

XML + schema compiler

JAXB is about persisting POJOs to XML

Annotations for controlling XML representation

Modify the generated code to suit your taste

Simple Development Model ● Follow three easy steps – Compile a schema (optional) – Compile

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

JAX-WS 2.0

JAX-WS 2.0 59
JAX-RPC 1.1 RI Issues ● Supports only SOAP 1.1over HTTP ● Limited XML Schema support

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

JAX-WS 2.0 RI

New Architecture

Improved Data Binding Annotations

Java SE 6 Endpoints

JAX-WS 2.0 RI ● New Architecture ● Improved Data Binding ● Annotations ● Java SE 6
JAX-WS 2.0 New Architecture ● Multiple protocols – SOAP 1.1, SOAP 1.2, XML ● Multiple

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

Improved Data Binding ● JAX-RPC 1.1 Issues – Defines its own data binding rules –

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

Customizations in WSDL/XML Schema to Java Mapping ● JAXB customizations – XML Schema to Java

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)

Customizations Example <jaxws:bindings wsdlLocation ="http://localhost:8080/math/add?WSDL"

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

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

Control of Mapping to WSDL/ XML Schema public interface BrokerIF extends Remote { public float

Control of Mapping to WSDL/ XML Schema

public interface BrokerIF extends Remote { public float getStockQuote(String tickerSymbol) throws RemoteException;

(String tickerSymbol ) throws RemoteException; } <complexType name=" getStockQuote ">
(String tickerSymbol ) throws RemoteException; } <complexType name=" getStockQuote ">
(String tickerSymbol ) throws RemoteException; } <complexType name=" getStockQuote ">
(String tickerSymbol ) throws RemoteException; } <complexType name=" getStockQuote ">

}

<complexType name="getStockQuote"> <sequence> <element name="String_1" type="string"/></sequence> </complexType>

</complexType> <portType name=" BrokerIF "> <operation
</complexType> <portType name=" BrokerIF "> <operation
</complexType> <portType name=" BrokerIF "> <operation

<portType name="BrokerIF">

<operation name="getStockQuote">

<operation name=" getStockQuote "> Comes from config.xml <service name=" Hello_Service

Comes from config.xml

<service name="Hello_Service">

JBI 1.0: Foundation for SOA 68

JBI 1.0: Foundation for SOA

What Is SOA?

What Is SOA? Roles A set of services that a business wants to expose to customers
Roles A set of services that a business wants to expose to customers and clients
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
which address characteristics such as
modularity, encapsulation, loose coupling,
separation of concerns, reuse, composable
and single implementation
Architecture
A programming model complete with standards, tools, methods and technologies such as web services Implementation
A programming model complete with
standards, tools, methods and technologies
such as web services
Implementation

Design

Focused

D e s i g n Focused SOA Architectural Principles Coarse Grained Business Services M o

SOA Architectural Principles

Coarse Grained Business Services

Architectural Principles Coarse Grained Business Services M o s t l y A s y n

Mostly Async

Grained Business Services M o s t l y A s y n c X M

XML Document-based

Business Services M o s t l y A s y n c X M L

Conversational

Business Services M o s t l y A s y n c X M L

70

Qualities

Focused

Qualities Focused SOA Architectural Principles Reliable Policy Driven Secure/Identity Registered and Retrieved 71

SOA Architectural Principles

Reliable

Qualities Focused SOA Architectural Principles Reliable Policy Driven Secure/Identity Registered and Retrieved 71

Policy Driven

Qualities Focused SOA Architectural Principles Reliable Policy Driven Secure/Identity Registered and Retrieved 71

Secure/Identity

Qualities Focused SOA Architectural Principles Reliable Policy Driven Secure/Identity Registered and Retrieved 71

Registered and Retrieved

Qualities Focused SOA Architectural Principles Reliable Policy Driven Secure/Identity Registered and Retrieved 71

71

Standards

Focused

Standards Focused SOA Architectural Principles WSDL Described BPEL Orchestrated JBI-based 72

SOA Architectural Principles

WSDL Described

Standards Focused SOA Architectural Principles WSDL Described BPEL Orchestrated JBI-based 72

BPEL Orchestrated

Standards Focused SOA Architectural Principles WSDL Described BPEL Orchestrated JBI-based 72

JBI-based

Standards Focused SOA Architectural Principles WSDL Described BPEL Orchestrated JBI-based 72

72

What is JBI (JSR-208)?

What is JBI (JSR-208)? ● JBI does for application integration what J2EE did for application development

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

Why JBI?

Standard framework

Why JBI? ● Standard framework – Solves M * M adaptors (connectors) problem for application integration

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

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

JBI Architecture

JBI Architecture 76
JBI Architecture 76
Current Status ● JBI specification finalized (2005) ● JBI SDK 1.0 is available now –

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/

JavaServer Faces 1.2 78

JavaServer Faces 1.2

JavaServer ™ Faces (JSF) Framework Is… A server side user interface (UI) component framework for

JavaServer Faces (JSF) Framework Is…

JavaServer ™ Faces (JSF) Framework Is… A server side user interface (UI) component framework for Java™

A server side user interface (UI) component framework for Java™ technology-based web applications.

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

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

JSF Architecture

Server

JSF Page HTML Desktop HTML Browser RenderKit Front App ctrl Backend JSF Page WML RenderKit
JSF Page
HTML
Desktop
HTML
Browser
RenderKit
Front
App
ctrl
Backend
JSF Page
WML
RenderKit
Phone
WML

80

Important Basic Capabilities ● Extensible UI component model ● Flexible rendering model ● Event handling

Important Basic Capabilities

Extensible UI component model

Flexible rendering model

Event handling model

Validation framework

Basic page navigation support

Internationalization

Accessibility

Tool friendly

This presentation is available from www.javapassion.com!

This presentation is available from www.javapassion.com! 82