EJB 3.0 (TS-7969)
Goal with EJB 3.0 is ease of deployment and configuration. Removed the need for EJBHOmes and EJBObjects. Abstracted JNDI APIs away from the developer and client view. Elimination of the need for deployment descriptors. Utilizes metadata wherever possible. Inversion fo contracts: bean specified what it needs through metadata, container interpositions to provide requested services. Elimination of EJB interfaces, so EJBs are simply plain Java objects providing the business interface. Seems like JNDI is going away...
A lot of resource management has been done through EJB lifecycle methods (i.e. ejbcreate, ejbremove), which are now being represented by metadata/annotations. Dependency injection is used to obtain things like data sources, environment entries, timer service, other beans, etc.
Dynamic lookup of EJBs is managed at the Bean class level, and resolved by the container at runtime. Remoteness of EJBs is handled under the covers, with remote exceptions being moved away from client developer unless specified otherwise. Wrapped in an EJBException that's used for both local and remote EJBs.
Container-managed transactions are used by default. Transactionality can be specified at both the class- and method-levels. Ommiting any transactionality metadata will result in all methods in the class using CMT with required transaction attributes.
Security issues are usually addressed at the time of deployment, but developers can provide guidance by specifying roles capable of invoking methods.
Event notification can be handled by specifying callback methods on lifecycle listener class instead of on the bean class. Examples of such are: post-construct, pre-destroy, pre-passivate, and post-activate. This provides for reuse since the same callback class and methods can be used for multiple bean classes.
Interceptors can be configured to wrap around methods. This allows for manipulation of arguments & results. Interceptors are configured for bean classes using annotations. Interceptors currently cannot be assigned at the method-level.
Annotations make deployment descriptors unnecessary. The defualt cases don't need to be specified, and commonly used cases can be specified easily. However, deployment descriptors are preferred by some developers and configuration managers. So, deployment descriptors can be used to override annotations specified in code. They can be sparse or full, and are backward compatible with EJB 2.1 descriptors. The bulk of the EJB 3.0 overhaul was directed at the programming model and not so much the deployment quirks.