EJB 3 (1) .0 Architecture

Enterprise
JavaBeans™ 3.0
Technology java.sun.com/javaone/sf
Work in Progress
Linda DeMichiel
EJB Specification Lead
Sun Microsystems
java.sun.com/j2ee
SM
1 | 2004 JavaOne Conference | Session TS-1861
Goal of This Talk
Learn about the new EJB™ 3.0 technology
SM
Agenda
Goals of EJB™ 3.0 Technology

Overview of the Simplified EJB™ API
Technology
Drill Down
Java™ Metadata Interface Software
Session Bean Simplifications
Access to the Environment
Entity Beans
Summary and Current Status
Where to Get More Info at JavaOneSM
Conference
SM
Primary Focus: Ease of Development
• Simplify EJB™ technology—make it easier

to use
─ Simplified set of APIs
─ Eliminate deployment descriptor from
developer’s view
─ Facilitate test-driven development
─ Improve developer productivity
• Capture broader range of developers
─ Make it simpler for average developer
─ Increase developer base, target more corporate
developers
SM
EJB™ 3.0 Technology Expert Group
Agenda
• Define “Simplified API” for EJB™

3.0 technology
• Critical examination of EJB™ technology
complexity
─ “Data-mining” of common complaints, RFEs
─ Anti-patterns, etc.
• Focus on most common cases
• Ensure EJB™ 2.0/2.1 APIs always available for
more complex scenarios
─ Simplifications/enhancements to improve use of
these APIs as well
SM
EJB™ 3.0 Technology Expert Group
Apache Software Foundation: SAP: Harald Mueller

Jeremy Boynes SAS Institute: Rob Saccoccio
BEA: Seth W hite, Cedric Beust SeeBeyond: Ugo Corda
Borland: Jishnu Mitra Sun Microsystems: Linda
E.piphany: Reza Behforooz DeMichiel
Fujitsu-Siemens: Anton Sybase: Evan Ireland
Vorsamer Tibco: Shivajee Samdarshi
IBM: Jim Knutson Tmax Soft: JaeW oong Chung,
IONA: Conrad O'Dea W oo Jin Kim
Jboss: Marc Fleury, Gavin King Individuals:
Nokia: Vic Zaroukian David Blevins
Novell: YongMin Chen Scott Crawford
Oracle: Michael Keith, Olivier Olivier Ihns
Caudron Richard Monson-Haefel
Pramati: Hemant Khandelwal Suneet Shah
SM
EJB™ 3.0 Technology Overview:
Metadata
• Leverage use of Java™ programming language

metadata (JSR 175, part of J2SE™ 1.5
technology)
─ Reduce the number of artifacts programmer
needs to produce
─ Eliminate need for developer to provide
deployment descriptor
• “Configuration by exception”
─ Specification of defaults, including for metadata
─ Reduce need to specify common, expected
behaviors and requirements on container
SM
Environment
• Simplification of access to bean’s environment

and runtime context
─ Encapsulation of environment dependencies and
JNDI access
─ Through metadata annotations
─ Dependency injection mechanisms
─ Simplification of access to other components
SM
POJO Beans
• Simplification of enterprise bean types

─ More closely resemble “POJOs”
• Elimination of requirement for EJB™
component interfaces
─ Use “POJIs” for session beans
─ No requirement for entity bean interfaces
• Elimination of requirement for Home interfaces
• Elimination of requirement for callback
interfaces
─ Allow selective implementation of callback methods
SM
EJB™ 3.0 Technology Overview: CMP
• Simplification of container-managed persistence

─ POJO/JavaBeans™ architecture approach
─ Support use of new()
─ Allow for testing outside the container
• Support for light-weight domain modeling,
including
─ Inheritance and polymorphism
─ Object-relational mapping metadata
• Elimination of need for data transfer objects and
related anti-patterns
SM
EJB™ QL
• Enhancements for EJB™ QL:

─ Bulk update and delete
─ Projection (SELECT list)
─ Subqueries
─ Explicit inner and outer join operations
─ Group by, Having
─ Additional functions
─ Dynamic queries
• + Support for native SQL queries
SM
Agenda
Goals of EJB™ 3.0 Technology

Overview of Simplified EJB™ API
Drill Down
Java™ Metadata Interface
Session Bean Simplifications
Access to the Environment
Entity Beans
Summary and Current Status
Where to Get More Info at JavaOneSM
Conference
SM
Java™ Programming Language
Metadata Interface
• Annotations on classes, methods, fields, etc.

─ Embedded in source code
─ Compiled into class files
─ Available at runtime
• Annotations can be simple or complex
(i.e., structured)
• Annotations can use defaults
• Annotation processors
─ Can: generate new files/classes
─ Cannot: alter source files or class files, inject base
classes, interfaces, alter bytecodes, etc.
SM
Java™ Programming Language
Metadata Interface
• Great enabling technology for EJB™ software

─ Generation of interface files
─ Elimination of deployment descriptors
─ Demarcation of injection and interpositioning points
for container behavior
• Leverage defaulting in conjunction
with metadata
─ Default values for annotation members
─ Metadata itself used for non-default cases
• Gives developer very simple-to-use and yet
powerful capability
SM
Session Beans
• “Hello World” entry experience

into EJB™ technology
─ Therefore our starting point for simplification….
SM
EJB™ 2.1 Technology
Stateless Session Bean
public interface Calculator extends EJBObject {

int add (int a, int b)
throws RemoteException;
int subtract (int a, int b)
throws RemoteException;
}
public interface CalculatorHome extends EJBHome {

Calculator create()
throws CreateException, RemoteException;
}
SM
Stateless Session Bean Class
public class CalculatorBean

implements SessionBean {
private SessionContext ctx;
public void setSessionContext(SessionContext s)
{ctx = s;}
public void ejbCreate() {}
public void ejbActivate () {}
public void ejbPassivate () {}
public void ejbRemove () {}
public int add (int a, int b) {

return a + b;
}
public int subtract (int a, int b) {
return a – b;
}
} SM
Deployment Descriptor
<session>
<ejb-name>CalculatorEJB</ejb-name>
<home>com.example.CalculatorHome</home>
<remote>com.example.Calculator</remote>
<ejb-class>com.example.CalculatorBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
...
...
...
SM
What’s Wrong With This Example?
• Heavy-weight programmer view:

─ 3 classes + deployment descriptor
• Interfaces get in the way
─ Create doesn’t create
─ Remove doesn’t remove
─ javax.ejb.SessionBean methods all unneeded here
─ Add to code clutter
• Deployment descriptor
─ Awkward to produce
─ Contains redundant information
─ Structure doesn’t conform to that of bean classes
─ Etc.
SM
Same Example: EJB™ 3.0 Technology
@Stateless public class CalculatorBean

implements Calculator {

return a + b;
}

return a – b;
}
}
public interface Calculator {

int add (int a, int b);
int subtract (int a, int b);
}
SM
Same Example With Generated Interface
@Stateless public class CalculatorBean {

return a + b;
}

return a – b;
}
}
SM
Same Example With Remote Access
@Stateless @Remote public class CalculatorBean {

return a + b;
}

return a – b;
}
}
SM
Deployment Descriptor
SM
Some Simplifications We Have Made
• Eliminated requirement for Home Interface

─ Not needed for session beans
• Business interface is a POJI
─ Bean can implement it or it can be generated
─ Bean can have more than one business interface
─ Can support remote access
─ EJB(Local)Object removed from client view
─ RemoteExceptions are removed from programmer
and client view
• Eliminated requirement for unnecessary
callback methods
─ Removed requirement to implement
javax.ejb.SessionBean
SM
Simplification Through Use of Defaulting
• Minimize use of metadata

─ Defaulting of interface generation
─ Defaulting of names
─ Defaulting use of transaction management types
─ Defaulting of transaction attributes
─ Default use of unchecked methods
─ Default use of caller identity
─ Etc.
SM
Stateful Session Beans
• Don’t need Home or Component

interfaces either
• Stateful Session Bean create is really
initialization from programmer's point of view
• Stateful Session Bean remove is important
─ However, metadata can be used instead
SM
Stateful Session Bean Example
@Stateful public class MyShoppingCartBean {
private String customer;
public void startToShop (String customer){

this.customer = customer;
...
}
public void addToCart (Item item) {

...
}
@Remove public void finishShopping () {

...
}
} SM
Under Evaluation
• @Service bean type

─ Stateless Session beans and Message-driven beans
have much in common
• Single interface subsuming
remote/local usages
─ Looked good initially, but simplification of
persistence model may mean it won’t be simpler
• GenericSessionBean, GenericEntityBean,
GenericMessageDrivenBean abstract clases
─ Have convenience methods
─ Have callback methods stubbed out
─ More useful for beans written to “classic” API
SM
Simplified Access to
Bean’s Environment
• Get JNDI APIs out of developer’s view

─ Not at all a good “hello world” experience
• Techniques/mechanisms
1) Declarative expression of dependencies
in metadata
2) Container injection of resource entries, etc.
3) Simple programmatic lookup mechanisms
• Different usages, both have their place
1) Very simple; facilitates testability (especially setter
injection techniques)
2) More flexible; dynamic
SM
Example
@Stateless public class MySessionBean {
@Resource(name=”myDB”)
public DataSource customerDB;
public void myMethod (String myString){

try
{
Connection conn = customerDB.getConnection();
...
}
catch (Exception ex)
{...}
}
}
SM
With Setter Injection
private DataSource customerDB;
@Resource(name=”myDB”)
public void setDataSource(DataSource myDB) {
customerDB = myDB;
}

...
...
}
}
SM
@Inject
private DataSource customerDB;
@Inject
public void setCustomerDB(DataSource
customerDB) {
this.customerDB = customerDB;
}

...
...
}
} SM
Injection
• Container can initialize instance variables

at time bean is made available
─ “setEJBContext time”
• Setter injection is better technique
─ Also happens at “setEJBContext time”
─ Better testability
─ Considered constructor injection, but found it not as
simple/flexible
• These techniques can be used to inject
ejbContext, EntityManager, resources, session
beans, etc.
SM
Dynamic Lookup
• Adding lookup() method to ejbContext

• Can use injection to get ejbContext
• Useful for stateful session beans
...
@Inject
private void setSessionContext(SessionContext ctx)
{
this.ctx = ctx;
}
...
myShoppingCart = (ShoppingCart)ctx.lookup
(“shoppingCart”);
SM
Client View
• Homes eliminated
─ With metadata, injection, easy lookup(), etc.,
Homes not needed for session beans (either
stateless or stateful)
─ Stateless SessionBean homes not very
useful anyway
• Stateful SessionBean homes have useful create
methods
─ But: shifting functionality to “initialization” business
method enables home to be eliminated
─ @Remove annotation completes the picture
SM
Entity Beans: Goals
• Simplify programming model

• Improve modeling capabilities
─ Inheritance and polymorphism; O/R mapping
• Make instances usable outside the container
• Facilitate testability
• Remove need for data transfer objects (DTOs)
• BMP currently a non-goal
─ Will probably get minor improvements: use of
metadata, etc.
• Resulted in some important changes
SM
Process We Went Through
• Looked at options and technologies

• Sorted out priorities
• Identified items that most need fixed
─ Complexity
─ Lack of testability outside the container
─ Need for improved modelingand querying capabilities
─ DTO issues
• Identified what we needed to preserve
─ EJB™ QL + enhancement of it
─ Container's ability to interpose and manage
─ Tx/security/caching/faulting control,...
SM
Process We Went Through (Cont.)
• Converged on self-consistent set of functionality

─ Serious exercise in prioritization
─ Meant removing a few things we liked
• Kept focus centered onobject/relational
mapping
─ Non-relational databases, etc. a non-issue
─ Relational-db-centric
─ Follows direction of established object/relational
mapping technologies such as Hibernate,
Toplink, etc.
SM
POJO Entity Beans
• Concrete classes (no longer abstract)

• No required interfaces
─ No required business interfaces
─ No required callback interfaces
• Support new()
• getter/setter methods
─ can contain logic (e.g., for validation, etc.)
• No exposure of instance variables outside bean class
• Use Collection interfaces for relationships
• Usable outside the EJB™ container
─ Means we needed to sacrifice CMRs
SM
Lifecycle Operations
• EntityManager serves as untyped “home”

─ Use to save, remove entity instances
─ Factory for queries
• Lifecycle operations
─ new()
─ create()
─ remove()
─ Detached instances
─ instances that exist outside of original
transaction context
─ serialized to other tiers
─ merge() merges them back
SM
Example: What I Predicted a Year Ago
public @entity abstract class CustomerBean {
public abstract String getName();

public abstract void setName (String name);
public abstract Account getAccount();
...
public String ejbCreate(String name)
throws CreateException {
setName(name);
return null;
}
...
}
// Home and Component IF definitions, etc.
SM
Example: EJB™ 3.0 Technology
Entity Bean Today
@Entity public class Customer {

private Long id;
private String name;
private Address address;
private HashSet orders = new HashSet();
@Id(generate=AUTO) public Long getID() {

return id;
}
protected void setID (Long id) {

this.id = id;
}
...
SM
Example: EJB™ 3.0 Technology
Entity Bean Today (Cont.)
...
@OneToMany(cascade=ALL)
public Set<Order> getOrders() {
return orders;
}
public void setOrders(Set<Order> orders) {

this.orders = orders;
}
// other business methods, etc.
SM
Client View
@Stateless public class OrderEntryBean {

private EntityManager em;
@Inject void setEntityManager(EntityManager em)

{
this.em = em;
}
public void enterOrder(int custID, Order

newOrder){
Customer c = em.find(“Customer”, custID);
c.getOrders().add(newOrder);
newOrder.setCustomer(c);
}
// other business methods

} SM
EJB™ QL Enhancements
• Bulk update and delete operations

• Projection list (SELECT clause)
• Group by, Having
• Subqueries (correlated and not)
• Additional SQL functions
─ UPPER, LOWER, TRIM, CURRENT_DATE, ...
• Dynamic queries
• Polymorphic queries
SM
EJB™ 2.1 Technology View
Contractual view of components

• Container specifies contracts
─ Interfaces
─ Callbacks
─ Deployment descriptor contract
• Beans written to contracts
─ Whether they need them or not
This is a very static viewpoint
─ It has a significant negative impact on application
complexity
SM
EJB™ 3.0 Technology and Its Implications
for EJB™ Technology Evolution
• View of the container as a service

injection facility
─ Injection points specified through metadata
─ View of the container “disappears”
• View of “component” changes:
─ Classes that require/request services
─ Pick and choose what they need
• Contractual view becomes inverted
─ Bean does not implement predefined set of APIs
─ Instead, bean specifies what it needs
• More extensible architecture => our view of
“container” evolves
SM
Summary and Status
• POJO-centric view of all enterprise beans

• POJIs required for session beans only
• Simplification of environment access
• Simplification of entity beans
─ Clear O/R mapping orientation
─ Improvement of query language capabilities
• Metadata is major enabling technology
• Interesting implications for the future
• Specification Early Draft is now available
SM
For More Information
• TS-2836
─ EJB 3.0: Simplifying and Enhancing the
Persistence Model
─ TS-2836 will also cover the new
query language features we’ve added
• BOF-1864
─ Enterprise JavaBeans™ 3.0 Technology Community
Discussion
─ Come and meet members of the EJB™ 3.0
Technology Expert Group
SM
Q&A
SM
Enterprise
JavaBeans™ 3.0 java.sun.com/javaone/sf
Work in Progress
Linda DeMichiel
EJB Specification Lead
Sun Microsystems
java.sun.com/j2ee
SM

EJB 3 (1) .0 Architecture

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

EJB 3 (1) .0 Architecture

Загружено:

Авторское право:

Доступные форматы

Enterprise

Learn about the new EJB™ 3.0 technology

Goals of EJB™ 3.0 Technology

• Simplify EJB™ technology—make it easier

• Define “Simplified API” for EJB™

Apache Software Foundation: SAP: Harald Mueller

• Leverage use of Java™ programming language

• Simplification of access to bean’s environment

• Simplification of enterprise bean types

• Simplification of container-managed persistence

• Enhancements for EJB™ QL:

Goals of EJB™ 3.0 Technology

• Annotations on classes, methods, fields, etc.

• Great enabling technology for EJB™ software

• “Hello World” entry experience

public interface Calculator extends EJBObject {

public interface CalculatorHome extends EJBHome {

public class CalculatorBean

public int add (int a, int b) {

• Heavy-weight programmer view:

@Stateless public class CalculatorBean

public int add (int a, int b) {

public int subtract (int a, int b) {

public interface Calculator {

@Stateless public class CalculatorBean {

public int add (int a, int b) {

public int subtract (int a, int b) {

@Stateless @Remote public class CalculatorBean {

public int add (int a, int b) {

public int subtract (int a, int b) {

• Eliminated requirement for Home Interface

• Minimize use of metadata

• Don’t need Home or Component

@Stateful public class MyShoppingCartBean {

private String customer;

public void startToShop (String customer){

public void addToCart (Item item) {

@Remove public void finishShopping () {

• @Service bean type

• Get JNDI APIs out of developer’s view

@Stateless public class MySessionBean {

public void myMethod (String myString){

@Stateless public class MySessionBean {

private DataSource customerDB;

public void myMethod (String myString){

@Stateless public class MySessionBean {

private DataSource customerDB;

public void myMethod (String myString){

• Container can initialize instance variables

• Adding lookup() method to ejbContext

• Simplify programming model

• Looked at options and technologies

• Converged on self-consistent set of functionality

• Concrete classes (no longer abstract)

• EntityManager serves as untyped “home”

public @entity abstract class CustomerBean {

public abstract String getName();

// Home and Component IF definitions, etc.

@Entity public class Customer {

@Id(generate=AUTO) public Long getID() {

protected void setID (Long id) {

public void setOrders(Set<Order> orders) {