4
1 Enterprise JavaBeans 3.0 to be released in 2006 Jacek Ratzinger Distributed Systems Group Vienna University of Technology Outline Rational for Change Concepts Annotations Dependency Injection EJB types and their specifics EJB-QL standardize Hibernate? Client Programming Model Pros and Cons Rational for Change EJB 2.x has become overly complex to many artifacts for developers to many interfaces in EJB 2.x (home, ejb) unnecessary exceptions, callback methods no standard way to define a primary key EJB 3.0 makes another attempt promise reducing EJB's complexity for developers simpler domain models with Plain Old Java Objects (POJOs) Drive for EJB 3.0 decrease number of artefacts home interfaces and deployment descriptors program annotations introduced in Java 5 light-weight domain modelling including inheritance and polymorphism configuration by exception dependency injection reduction of checked exceptions testing outside the container Java 5.0 Annotations annotations do not directly affect program semantics can be inspected through source parsing or by using the additional reflection APIs define custom annotations annotate fields, methods, classes, etc. used to define bean's business interface O/R mapping information (specific persistence) resource references deployment information Dependency Injection beans may gain references to resources by having the container supply it with those bean instance variables or setter methods are annotated as targets standard way = annotations alternatively, lookup method of javax.ejb.EJBContext or the JNDI APIs container responsibility: before use

ejb 3.0 pdf

Embed Size (px)

Citation preview

Page 1: ejb 3.0 pdf

1

Enterprise JavaBeans 3.0to be released in 2006

Jacek Ratzinger

Distributed Systems GroupVienna University of Technology

Outline

● Rational for Change● Concepts

– Annotations– Dependency Injection

● EJB types and their specifics● EJB-QL

– standardize Hibernate?● Client Programming Model● Pros and Cons

Rational for Change

● EJB 2.x has become overly complex● to many artifacts for developers● to many interfaces in EJB 2.x (home, ejb)● unnecessary exceptions, callback methods● no standard way to define a primary key

● EJB 3.0 makes another attempt promise reducing EJB's complexity for developers

● simpler domain models with Plain Old Java Objects (POJOs)

Drive for EJB 3.0

● decrease number of artefacts– home interfaces and deployment descriptors

● program annotations introduced in Java 5● light-weight domain modelling

– including inheritance and polymorphism● configuration by exception● dependency injection● reduction of checked exceptions● testing outside the container

Java 5.0 Annotations

● annotations do not directly affect program semantics

● can be inspected through source parsing or by using the additional reflection APIs

● define custom annotations– annotate fields, methods, classes, etc.

● used to define– bean's business interface– O/R mapping information (specific persistence)– resource references– deployment information

Dependency Injection

● beans may gain references to resources by having the container supply it with those

● bean instance variables or setter methods are annotated as targets

● standard way = annotations● alternatively, lookup method of

javax.ejb.EJBContext or the JNDI APIs● container responsibility: before use

Page 2: ejb 3.0 pdf

2

Dependency Injection

● annotation of instance variables@Resource(name="myDB") //type inferredpublic DataSource customerDB;

● setter injectionpublic DataSource customerDB;

@Resource(name=” myDB”)public void setDataSource(DataSource myDB

this. customerDB = myDB;}

Specifics of EJB 3.0

● Exceptions– interface may declare arbitrary exceptions– should not throw java.rmi.RemoteException– EJBException thrown by the container

● Callbacks and Callback Listener Classes– no callbacks (e.g. ejbCreate(), ejbPassivate) for

life cycle events required– method annotations for callbacks– callback listener class may be used instead of

callback methods

Entity Beans

● POJOs with annotation @Entity● all fields persistent not marked with

@Transient (configuration by exception)● persistent once it is associated with an

EntityManager (em.persist(entity))

● approach: refer with annotations to concrete tables/columns instead of the abstract persistence schema

Entity Beans

● unidirectional and bidirectional relationships attributes of annotations– one-to-one– one-to-many– many-to-one– many-to-many

● owning side responsible for propagating relationship changes to database

Sample Entity Bean

@Entity public class Employee {

@Id(generate=GeneratorType.TABLE)public Long getId() { return id;}

public Address getAddress() {return address;}

@OneToMany(mappedBy=“leader”)public List<Employee> getTeamMembers() {

return this.colleagues;}

@Transient private void getFullName() {return getFirstName() + getLastName()}

EJB QL

● EntitiyManager API similar to Hibernate and Toplink– persist(entity), find(Entity.class, id)– createQuery(ejbqlString),

createNativeQuery(sqlString)

● EJB QL Examples– FROM Order order– SELECT DISTINCT order.address.state FROM Order

order WHERE order.customer.name LIKE ?– SELECT order FROM Order order INNER JOIN FETCH

order.customer

Page 3: ejb 3.0 pdf

3

Enhancements to EJB QL

● explicit inner and outer join● fetch join for eager loading (default=lazy)● bulk update and delete● subqueries● group-by● support for native SQL queries● dynamic query capability

Stateless Session Beans

● plain Java object with a class-level annotation of @Stateless

● can implement the javax.ejb.SessionBean interface, but is not required to

● may implement a business interface– If no business interface implemented, generated

using all the public methods● @BusinessMethod by default local

– @Remote indicates a remote interface

Sample Stateless Session Bean

import javax.ejb.*;

@Stateless@Remotepublic class HelloWorldBean {

public String sayHello() {return "Hello World";

}}

Web Services Session Beans

● JSR-181● a session bean that serves as a web service

endpoint is annotated with @WebService● @WebMethod used to identify methods that

are exposed as web service● other annotations

– @WebParam, @WebResult, @OneWay, @SOAPBinding, @SOAPMessageHandler, @HandlerChain, @InitParam

Stateful Session Beans

● similar to Stateless● lifecycle event callbacks

– @PostConstruct: after dependency injection– @PreDestroy: after method with @Remove– @PostActivate: equal to ejbActivate()– @PrePassivate: equal to ejbPassivate()

● a callback listener class (@CallbackListener) may be used instead of callback methods

Sample Stateful Session Bean

@Statefulpublic class AccountManagementBean {

@EJB (name="mySessionBean") //dependency injectionprivate MySessionI myBean;private Socket socket;

@PostConstruct@PostActivatepublic void initRemoteConnectionToAccountSystem() {

try {this.socket = new Socket, PORT);}

catch (Exception ex) {throw new EJBException(ex);}}...

Page 4: ejb 3.0 pdf

4

Message-driven Beans

● to a client, a message-driven bean is a message consumer

● message-listener business interface determined by the messaging type in use

● javax.jms.MessageListener for JMS

Bean Interfaces

● session beans and message-driven beans require a business interface

● interfaces automatically generated from implementation, if no interface implemented

● interface name derived from class name● if several interfaces implemented, annotation

required to define „the“ business interface● interfaces assumed local unless annotated

Client Programming Model

● EJB 3.0 remote or local clients access beans through their business interface

● business interfaces are ordinary Java interfaces

● references to business interfaces through– injection mechanism– javax.ejb.EJBContext.lookup()– JNDI API

Pros and Cons

● less artefacts for developers● enterprise services for Java core (e.g.JBoss)

– EJB 3.0 compliant desktop application?

● contrary to annotations provide deployment descriptors a holistic view to EJB modules

● vendor specific annotations defeats the goal of portability

● don’t forget about configuration by exception● entity beans: owning side defined by

dependent side=> less complexity?