Planned Features For EJB 3.1

The EJB 3.1 expert group has made an early draft of the specification available via the JCP. The new version of EJB, targeted for released as part of the Java EE 6 specification at the end of 2008, aims to both build on the simplification work that was started for EJB 3 and to add new features that have been requested by the Java enterprise community. Significant changes include:

1. A simplified local view that provides session bean access without a separate local business interface. This provides a means by which a developer can implement a component using only a bean class.
2. A Singleton session bean component: Instantiated once per application for each JVM on which the application is started, the Singleton session bean component is intended to provide a simplified method for caching state for an application. As an EJB, the Singleton has access to the standard set of EJB middleware services - transaction management, security, remoteing, dependency injection and so on. The Singleton starts when the container invokes the newInstance method on the session bean class. By default the container is responsible for determining when to instantiate an instance, however a developer may request instantiation at start-up using an @Startup annotation or corresponding deployment descriptor entry. A Singleton may have a dependency on another Singleton (indicated via an @DependsOn annotation) where one Singleton must initialize before another. The Singleton session bean lives for the duration of the container in which it is created but state does not survive a shut-down or a crash of the JVM. Since it is intended to be shared it supports concurrent access which may be container managed or managed by the developer in the individual bean.
3. Calendar based EJB Timer expressions and automatically created timers: The Timer Service allows a timer callback schedule to be expressed using a calendar-based syntax similar to the UNIX cron facility. For example the following schedule represents "Every Monday, Wednesday and Friday at 3:15": @Schedule(minute=”15”, hour=”3”, dayOfWeek=”Mon,Wed,Fri”). The timer service also supports the automatic creation of a timer based on metadata in the bean class or deployment descriptor. Automatically created timers are created by the container on application deployment.
4. Asynchronous session bean invocations: By default a session bean invocation blocks the client for the duration of the invocation. With an asynchronous method invocation the container returns control to the client and continues processing the invocation on a separate thread. An asynchronous method can return a Future object that allows the client to retrieve a result value, check for exceptions, or attempt to cancel an in-progress invocation.
5. The definition of a lightweight subset of Enterprise JavaBeans functionality that can be provided within Java EE Profiles such as the Java EE Web Profile: This subset will support the following portions of the EJB 3.1 APIs: Stateless, stateful, and Singleton session beans, local business view and no-interface view, synchronous method invocations, interceptors, declarative security, container-managed transaction (CMT) demarcation, bean-managed transaction (BMT) demarcation, the Enterprise bean environment, Java Persistence 2.0 API, the user transaction interface of JTA 1.1, Common Annotations 1.0, and the enterprise APIs that are supported by the base Java SE 6 platform (JDBC, RMI-IIOP, JNDI, JAXP, Java IDL and JAAS). The lightweight EJB container must provide a JNDI API namespace to the enterprise bean instances. The packaging requirements have also been simplified so that EJB components can be packaged within a .war file directly - in this case the EJB resides in the WEB-INF/classes directory without the need for an ejb-jar. Its optional ejb-jar.xml deployment descriptor is placed in WEB-INF.
   

Spec lead Ken Saks has begun a blog and is providing further information on the items that the expert group are working on including support for common EJB component mapping:

"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 mapping"

The expert group are still early in the process of defining EJB 3.1 so the feature list is subject to change. It is also an excellent opportunity to get involved in shaping the next version of the spec by offering feedback to the expert group via the comments alias.