EJB 3[1].0 Architecture

java.sun.com/javaone/sf

| 2004 JavaOneSM Conference | Session TS-1861 1

Enterprise JavaBeans™ 3.0 Technology Work in Progress

Linda DeMichielEJB Specification LeadSun Microsystemsjava.sun.com/j2ee


Goal of This Talk

Learn about the new EJB™ 3.0 technology


Agenda

Goals of EJB™ 3.0 TechnologyOverview of the Simplified EJB™ API

TechnologyDrill Down

Java™ Metadata Interface SoftwareSession Bean SimplificationsAccess to the EnvironmentEntity Beans

Summary and Current StatusWhere to Get More Info at JavaOneSM

Conference


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


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


EJB™ 3.0 Technology Expert Group

Apache Software Foundation: Jeremy Boynes

BEA: Seth White, Cedric BeustBorland: Jishnu MitraE.piphany: Reza BehforoozFujitsu-Siemens: Anton

VorsamerIBM: Jim KnutsonIONA: Conrad O'DeaJboss: Marc Fleury, Gavin KingNokia: Vic ZaroukianNovell: YongMin ChenOracle: Michael Keith, Olivier

CaudronPramati: Hemant Khandelwal

SAP: Harald MuellerSAS Institute: Rob SaccoccioSeeBeyond: Ugo CordaSun Microsystems: Linda

DeMichielSybase: Evan IrelandTibco: Shivajee SamdarshiTmax Soft: JaeWoong Chung,

Woo Jin KimIndividuals: David Blevins Scott Crawford Olivier Ihns Richard Monson-Haefel Suneet Shah


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


EJB™ 3.0 Technology Overview: 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


EJB™ 3.0 Technology Overview: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


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


EJB™ 3.0 Technology Overview: 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


Agenda

Goals of EJB™ 3.0 TechnologyOverview of Simplified EJB™ APIDrill Down

Java™ Metadata InterfaceSession Bean SimplificationsAccess to the EnvironmentEntity Beans

Summary and Current StatusWhere to Get More Info at JavaOneSM

Conference


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.


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


Session Beans

• “Hello World” entry experienceinto EJB™ technology─ Therefore our starting point for simplification….


EJB™ 2.1 TechnologyStateless 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;}


EJB™ 2.1 TechnologyStateless 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;

}}


EJB™ 2.1 Technology 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> ... ... ...


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.


Same Example: EJB™ 3.0 Technology

@Stateless public class CalculatorBean implements Calculator {

public int add (int a, int b) { return a + b;}


}}public interface Calculator { int add (int a, int b); int subtract (int a, int b);}


Same Example With Generated Interface

@Stateless public class CalculatorBean {



}}


Same Example With Remote Access

@Stateless @Remote public class CalculatorBean {



}}


Deployment Descriptor


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


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.


Stateful Session Beans

• Don’t need Home or Componentinterfaces 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


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

}}


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


Simplified Access to Bean’s Environment

• Get JNDI APIs out of developer’s view─ Not at all a good “hello world” experience

• Techniques/mechanisms1) Declarative expression of dependencies

in metadata2) Container injection of resource entries, etc.3) Simple programmatic lookup mechanisms

• Different usages, both have their place1) Very simple; facilitates testability (especially setter

injection techniques)2) More flexible; dynamic


Example

@Stateless public class MySessionBean {

@Resource(name=”myDB”) public DataSource customerDB;public void myMethod (String myString){ try { Connection conn = customerDB.getConnection(); ... } catch (Exception ex)

{...} }}


With Setter Injection

@Stateless public class MySessionBean {

private DataSource customerDB;@Resource(name=”myDB”) public void setDataSource(DataSource myDB) { customerDB = myDB;}public void myMethod (String myString){ ... Connection conn = customerDB.getConnection(); ... }}


@Inject

@Stateless public class MySessionBean { private DataSource customerDB;@Inject public void setCustomerDB(DataSource customerDB) { this.customerDB = customerDB;}public void myMethod (String myString){ ... Connection conn = customerDB.getConnection(); ... }}


Injection

• Container can initialize instance variablesat 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.


Dynamic Lookup

• Adding lookup() method to ejbContext• Can use injection to get ejbContext• Useful for stateful session beans

...@Injectprivate void setSessionContext(SessionContext ctx)

{ this.ctx = ctx; }...myShoppingCart = (ShoppingCart)ctx.lookup

(“shoppingCart”);


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


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


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


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.


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


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


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.


Example: EJB™ 3.0 TechnologyEntity 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;

}...


Example: EJB™ 3.0 TechnologyEntity 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.}


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}


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


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


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


• 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

Summary and Status


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

| 2004 JavaOneSM Conference | Session TS-186150

Q&A

java.sun.com/javaone/sf


Enterprise JavaBeans™ 3.0Work in Progress

Linda DeMichielEJB Specification LeadSun Microsystemsjava.sun.com/j2ee

EJB 3[1].0 Architecture

Documents

Transcript of EJB 3[1].0 Architecture