Mike Keith – oracle guy on the expert group

 

EG is trying to solve the problem that lots of people are using EJB but not a lot are happy about it.

 

Life before EJB?

1)    solving the problem over and over again, there was no way to capture business logic on the server

2)    Community started to get behind the idea of component model for the server side

EJB started in April 1997 (yikes has it really been that long) first release in March of 1998. (I can?t believe it has been this long, I was at InLine at the time and we were playing with the spec before it was real).

 

Lots of hype of the original spec.

 

Original goals

• Allow components developed separately to be deployed together an interoperate in the server
• Define development  and deploy contracts
• Lessen the knowledge required to develop components
• Provide access to the lower level stuff for advanced developers
• ?write once, run on any EJB container?
• Interoperable with CORBA

 

Time line – not getting all it but June 1999 is where the J2SE and J2EE names happened

 

Discussion of the roles – cool graphic

 

Discussion of the contract between the component and the container

 

Discussion of the client and the container

1)    Each entity has an identity

2)    Container makes the home available under jndi

 

EJB allowed declarative transactions, very cool stuff because it makes us not have to worry about it any more, even distributed (from EJB1.0)

 

Bad news – everything was remote even in the same VM the RMI machinery was invoked. Some containers over rode this and provided ?local? entities for the same VM.

 

EJB 1.1 is where the xml deployment descriptor was first released.

 

Bean references – bit of code and a discussion of the reference stuff. Basically crufty.

Transactions – removed tx_bean_managed because of transaction isolation problems

 

Now on to EJB 2.0

1)    Finally got EJB QL and finders – portability not possible before

2)    Internal ejbSelects

3)    Relationships – finally!

4)    Local homes/interfaces

5)    Entities now abstract (3.0 will go back, yikes)

 

Discussion of EJB QL

 

Home methods – like a static method on a bean, without regard for identity, typically uses an ejbSelect

 

EJB 2.1 – timers, coarse-grained business process/workflow events, not real-time

 

EJB 3.0

1)    extensive use of annotations

2)    remove xml deployment descriptor requirements

3)    configuration by exception use defaults to avoid unnecessary declarations

4)    eliminate requirement for home interfaces use and EntityManager

5)    inversion of control techniques (dependency injection)

6)    eliminate requirement for component interfaces

7)    optionally allow entity to implement interfaces

8)    entity is pojo-like concrete class – now you can make your objects persistent

9)    callback (life cycle) methods no longer required

10) detached execution model, side-step the DTO pattern

11) support for entity inheritance and polymorphism – groovy!

12) many ejb ql enhancements

13) support for native sql queries – of course don?t use this if you want to be portable

14) dynamic query api

15) scrapped remote entity model

16) standard for object-relational mapping metadata

 

Entities are required to

1)    define a no arg constructor

2)    attributes should be protected or private (access internally but not externally)

 

@Entity says is an entity, @Id says that attribute is the identifier

 

EJB QL enhancements – bulk update, projection lists, added outer join, return different object types (even not persistent)

 

SELECT new OrderInfo(o.id, item.product.name, item.cost) FROM Order o JOIN o.lineItems item WHERE o.totalCost > :amount

 

Named parameters!

 

GROUP BY and HAVING added as well

 

Subselects – select employees that have spouses:

 

SELECT DISTINCT emp from Employee emp WHERE EXISTS(SELECT spouseEmp from EMP?)

 

 

O-R Metadata

• Direct and relationship mapping types
• multi-table mappings
• support for id generation tables
• schema definition/generation
• cascading operations across relationships
• egger/lazy loading
• optimistic locking fields
• inheritance
• dependent or aggregated

 

Defaults are reasonable, if you want to over ride simply do so

 

@Column(name=?SHIP_ADDR?) overrides the default

 

getShippingAddress, the default would be SHIPPINGADDRESS