The Reference Implementation for EJB 3.1 is being developed as part of the Glassfish project. A preview implementation of two new ease-of-use enhancements (simplified packaging and the "no-interface" view) is now available. See Mahesh's blog for the details. Give it a try and let us know your feedback.
Tuesday May 06, 2008
Friday Mar 14, 2008
The EJB 3.0 Specification simplified many aspects of EJB component development. It reduced the number of required classes and interfaces, established intelligent defaults, and made the ejb-jar.xml file optional, to name just a few.
However, the specification still requires that all EJB components be packaged within an ejb-jar file. In many cases this restriction adds undue complexity to Java EE development. To remedy that, we're planning to allow EJB components to be packaged directly within a .war file, without the need for an ejb-jar.
Let's look at an example. Assume we have a simple Stateless Session Bean that exposes a no-interface view :
1: package com.acme;
2:
3: @Stateless
4: public class FooBean {
5: public void foo() { ... }
6: }
Normally, accessing this bean from a Servlet would require one .war, one ejb-jar, and an .ear file to wrap the two modules together. With the new packaging alternative, everything fits into a single .war :
$ jar tf foo.war WEB-INF/classes/com/acme/FooBean.class WEB-INF/classes/com/acme/FooServlet.class WEB-INF/web.xml
It's important to point out that the goal here is to remove an artificial packaging restriction, not to create a new flavor of EJB component that uses web container APIs. From an EJB component's perspective it still lives within the same managed runtime environment as before. This is important, as it keeps the programming model independent of packaging decisions.
Here are some more details about how the new packaging approach would likely be defined :
- EJB component classes are packaged within WEB-INF/classes and/or in WEB-INF/lib.
- EJB components share the same classloader as other classes in WEB-INF/classes and WEB-INF/lib.
- EJB components share the .war's module-level component environment. For example, a resource-ref defined within web.xml would be visible to any EJB components in the .war.
- EJB components have visibility to any persistence units defined within the .war.
- ejb-jar.xml is optional. If needed, it is placed in WEB-INF/.
- There are no special restrictions placed on a .war just because it contains EJB components. It can be deployed as a stand-alone .war or included within an .ear along with any number of other .wars or ejb-jars.
- The full EJB feature set is available. For example, it would be possible to define a message-driven bean by placing a bean class annotated with @MessageDriven within WEB-INF/classes.
That's a quick overview of a new simplified alternative to EJB component packaging. Please post comments here or send them to our EJB 3.1 feedback alias.
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 :
Here's a client of that bean :
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. Here's how a corresponding EJB 3.1 component using a "no-interface view" might look :
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 :
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.
1: public interface Hello {
2: public String hello();
3: }
4:
5: @Stateless
6: public class 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. Here's how a corresponding EJB 3.1 component using a "no-interface view" might look :
1: @Stateless
2: public class HelloBean {
3: public String hello() { return "hello"; }
4: }
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.
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.
This blog copyright 2008 by Ken Saks
