Michael - evolution of EJB to 3.0
Cool talk on the EJB 3.0 stuff. Sounds like its going to be good.
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.
- 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
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
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?)
- 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
- 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