I'm happy to announce that the Enterprise JavaBeansTM
(EJB) 3.1 Early Draft is now available
The Expert Group has been working hard since we launched JSR 318
last August and we're looking forward to your feedback. Please send comments to email@example.com
The EJB 3.1 Specification has two main goals. The first is a continued focus on ease-of-use. The EJB 3.0 Specification made a huge improvement in this area with the introduction of the EJB Simplified API but we can do much more. The second goal is to add many of the new features that have been requested from the community for some time.
Here is a brief overview of the topics being considered. I'll be following up with more detailed posts on each topic. Just a reminder that we're still relatively early in the process so the exact feature set is subject to change.
.war packaging of EJB components
The EJB 3.0 Specification made it simpler to develop EJB components by reducing the number of necessary classes and .xml files. However, EJB components are still required to be packaged within their own ejb-jar file, which complicates the development of applications that make use of both web and EJB functionality. This enhancement will allow EJB components to be packaged and deployed directly within a .war file, without
Optional Local Business Interfaces
Although the EJB 3.0 Local view has proven to be a significant improvement over its predecessor, there are cases where developers would prefer to avoid using a separate interface altogether. Making the local business interface optional will allow a bean developer to implement a component using only a bean class.
The Java EE 6 Specification will be introducing Java EE platform Profiles. Profiles will reference the Java EE platform, as defined by the JCP process, and may include a subset of Java EE platform technologies, additional JCP technologies not part of the base Java EE platform, or both. EJB "Lite" defines a small portion of the EJB 3.1 API for use in these subset EE profiles. This will give vendors the flexibility to provide EJB support across a wide variety of EE profiles.
Portable EJB Global JNDI Names
One common source of frustration for developers is the non-portability of the mapping information (e.g. global JNDI names) used to resolve and lookup EJB references. We'll investigate ways to standardize this information so that applications can be deployed without the need for vendor-specific EJB component mappings.
A common problem encountered by developers is how to portably share state between the EJB components in an application. In contrast, the web container has always provided this capability via properties on the ServletContext. A new Singleton bean type will allow for easy sharing of state within the entire application.
Application Initialization and Shutdown Events
EJB applications often need to perform tasks at the point that the application is initializing and/or shutting down. These lifecycle callbacks are supported in the web tier but have never been available directly within the EJB component model.
EJB Timer Service Enhancements
The two most commonly requested new EJB Timer Service features are calendar-based timer expressions and the ability to have an EJB timer created automatically as a result of deployment.
The main option available to EJB developers who are interested in adding asynchrony to their applications is the JMS API. The combination of JMS messages and message-driven beans is commonly used both as a form of communication between components in collocated applications and as a way to achieve parallelism for local task processing. This approach is cumbersome due to the associated configuration requirements and relative complexity of a messaging API. We plan to address this by integrating simple and lightweight asynchronous capability into the session bean component model.