Oracle Blog

Blog for kensaks

Wednesday Mar 12, 2008

The EJB 3.0 Simplified API made it much simpler to write a Local business interface for an EJB component. But what if you don't even need a separate interface? That's an issue we're planning to address in the EJB 3.1 Specification by making local business interfaces optional.

Let's start by looking at an example of a simple EJB 3.0 stateless session bean exposing a Local view :

1: publicinterface Hello {

2: public String hello();

3: }

4:

5: @Stateless

6: publicclass HelloBean implements Hello {

7: public String hello() { return"hello"; }

8: }

Here's a client of that bean :

1: @EJB Hello helloRef;

2: ...

3: helloRef.hello();

Pretty straightforward, but in some cases developers find it cumbersome to use a separate interface as the contract for their client. This is especially true for fine-grained components accessed locally from clients within the same module. It's one more file per component to write and keep in sync with the bean class, and one more .class to package into the application.

All public bean class methods are exposed as the client method contract. The client acquires an EJB reference the same way as before. The only difference is that the reference type is a bean class instead of a local business interface :

1: @EJB HelloBean helloRef;

2: ...

3: helloRef.hello();

It's important to note that even though there is no interface, the client still interacts with the bean through an EJB reference object. The client never directly instantiates the bean class using the new() operator or holds a direct reference to a bean instance. This makes the client programming model almost identical between the Local view and the no-interface view. All semantics regarding transaction propagation, exception handling, concurrent access, etc. stay the same.

We think the no-interface view will be one of many nice options for simplifying EJB applications going forward. What do you think? Please post comments here or send them to jsr-318-comments@jcp.org.

Monday Mar 10, 2008

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 jsr-318-comments@jcp.org

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 an ejb-jar.

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.

EJB "Lite"
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.

Singletons
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.

Simple Asynchrony
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.