New features in EJB3.1 (Part 3)

Author: Reza Rahman article source: www.theserverside.com

In the ' I ' two articles of this series, I covered a few of the earliest discussed features-optional interfaces for Ses Sion beans, Singleton beans, EJB Timer Service enhancements and simplified packaging. In this third article, I'll cover two more features then have been discussed in detail--asynchronous session Bean Invocati On and EJB Lite. Remember, none of this has been finalized yet. All of this are really just a peek into the inner workings of the JCP, so, have a chance to provide. The Early Draft is out

An early draft of the spec has been released a few weeks ago. Can take a look at the draft yourself at http://jcp.org/aboutJava/communityprocess/edr/jsr318/index.html. As you might already know, the draft covers the entire spec and not just the new features. However, it ' s not too hard to skip the parts that are unchanged from EJB 3.0. Keep in mind this changes still being discussed not are yet in the reflected. Please also keep in mind this spec needs to is written for completeness and serves as a contract of sorts for vendor I Mplementations, so it's often difficult if not impossible to focus on readability from a developer ' s perspective.

Do continue to send in your thoughtful comments on EJB 3.1 to jsr-318-comments@jcp.org. Feel free to CC me at reza@rahmannet.net too. asynchronous invocation of Session Beans

Asynchronous processing is a surprisingly common requirement for many enterprise. Some of the most obvious use cases are triggering fire-and-forget background processes, handling long-running tasks while Keeping the user interface receptive or simply increasing application throughput by utilizing the benefits of parallel pro Cessing. The easiest way of implementing asynchronous processing in Java EE applications The ' is ' using message driven. In fact, the ' the ' driven Bean example in EJB 3 in Action is used to implement asynchronous order billing. More precisely, a message driven Bean (Orderbillingmdb) Asynchronously bills the "customer after" is confirmed a D updates the order information with the results of the billing attempt once it is completed. Figure 1 shows this scenario:

Figure 1:asynchronous Order billing

While using the message driven Beans for asynchronous processing certainly works, it also forces you to deal with messaging And JMS, even for relatively lightweight functionality. This is precisely the problem asynchronous sessions bean invocation is designed to solve. With this enhancement, your can do asynchronous processing simply by annotating a sessions bean method with the @Asynchronou s annotation. Let's take a look at the re-factored EJB 3 in Action example for asynchronous billing using the feature:

@Stateless public class Orderbillingservicebean implements Orderbillingservice {... @Asynchronous public void Billord ER (order) {try {//attempt to charge the order. Bill/Send Email notification of billing success. Notify Billingsuccess (order); Order.setstatus (Orderstatus.complete); catch (Billingexception Be) {//Send email notification of billing failure. Notifybillingfailure (is, order); order.sets Tatus (orderstatus.billing_failed); Finally {update (order);}} ... }

Because of the @Asynchronous annotation, when the client invokes the Orderbillingservice.billorder method, the call would r Eturn immediately instead of blocking until the Billorder method finishes executing. The EJB container'll make sure the method gets executed asynchronously (probably using messaging under the hood). As you can, the return type of the asynchronous method is void. This'll probably is the case for a vast majority of asynchronous session bean methods. However, EJB 3.1 can also support a return type of java.util.concurrent.future<v>, where V represents the resultant Value of an asynchronous invocation. In case for your are unfamiliar with it, the Future<v> interface allows your to do things like cancelling a asynchronous Invocation, checking if an invocation was complete, check for exceptions and getting the results of asynchronous Ion. Check out of the documentation for the Future<v> interface here:http://java.sun.com/javase/6/docs/api/java/uTil/concurrent/future.html. Let's take a quick look on the example using the Future<v> return type. In the previous example, we set the status of the ' order ' according to the outcome of the ' billing at Tempt and updated the order. Let's assume that's invoker updates the order themselves and wants to know what the status of the billing attempt is. We could do this by refactoring the Billorder as follows:

@Stateless public class Orderbillingservicebean implements Orderbillingservice {... @Asynchronous public future< Orderstatus> Billorder (order) {try {//attempt to charge the order. Bill (order);/Send Email notification of Billing success. Notifybillingsuccess (order); return new asyncresult<orderstatus> (Orderstatus.complete); catch (Billingexception Be) {//Send email notification of billing failure. Notifybillingfailure (is, order); Asyncresult<orderstatus> (orderstatus.billing_failed); } } ... }

The Javax.ejb.asyncresult<v> object is a convenience implementation of the Future<v> interface. It takes the result of the asynchronous invocation as a constructor argument. There ' s nothing stopping to the from using your own implementation of future<v>. Asynchronous invocation supports a few other neat features-like delivery and guarantees send transacted. For details, check out the spec draft.

What Do you have the asynchronous session Bean invocation feature? I personally it ' s pretty cool. Can You do you have any other features that could to be added? EJB Lite is here

One of the major complaints many people have had of EJB and Java EE in general are that it is a kitchen sink solution th At tries to is everything to everyone in the same time. Although it's important to appreciate the fact of Java EE is a standard and must of aim to being comprehensive, this criticism is justified. Java EE 6 Profiles are a reflection of this fact. Roberto Chinnici, the Co-spec leads for the Java EE 6 spec has blogged about Java EE 6 Profiles HERE:HTTP://WEBLOGS.JAVA.N Et/blog/robc/archive/2008/02/profiles_in_the_1.html. In short, Profiles define subsets the Java EE suited to a particular purpose. For example, the minimal web profiles are geared towards very simple Web applications.

Focusing on EJB in particular, the typical Web project are probably very unlikely to use remoting, the EJB Timer service or message driven beans. In fact, a vast majority of EJBS applications probably simply utilize injection, persistence management, stateless session Beans and declarative transactions. EJB Lite is a attempt to follow this observation and pare down EJB features as much as possible. On one hand, this is allows for very simple, lightweight implementations. On the other hand, this means learning EJB Lite could consist of leaning just a small handful of annotations and almost no Configuration. The next generation of lightweight Java EE application servers'll probably implement EJB Lite instead of the entire EJB 3.1 specification. For example, a very tantalizing possibility this opens the is creating a implementation to EJB Lite on top of Spring going A step further down the lines of the Pitchfork project.

The following is the current list of features proposed for EJB lite:stateless, Stateful, and Singleton sessions beans only Local EJB interfaces or no interfaces no support for asynchronous invocation (should this is included?) Interceptors declarative security declarative and programmatic transactions

What are your thoughts on this list? Should It is pared down further? Should it be expanded? What do you are important for your application? For reference, this is a table comparing major EJB and EJB Lite features:

Feature	EJB Lite	EJB
Stateless beans
Stateful Beans
Singleton Beans
Message driven beans
No interfaces
Local interfaces
Remote interfaces
Web Service Interfaces
asynchronous invocation
Interceptors
Declarative security
Declarative transactions
Programmatic transactions
Timer Service
EJB 2.x support
CORBA Interoperability

Table 1:ejb and EJB Lite Feature Comparison Features still on the Table

In this series so far, I ' ve covered Singleton beans, optional interfaces to session beans, Timer service features, SIM Plified EJB Packaging, session bean asynchronous invocation and EJB Lite. There are still a number of features that are being discussed from the group and are in various stages of INCOMPLETENESS:SU Pport for stateful Web services via stateful session Bean Web service endpoints. The standardization of JNDI mapping instead of keeping it for vendors to decide. Support for-using EJB 3.1 in Java SE environments. This is primarily geared towards the unit testing.

What are your thoughts on this features? If you are they are important, voice your opinion by emailing the expert group. Are there any other features do you have would like to? As the state of those features become clearer, I ' ll write about them in this series. As many folks have requested, I ' ll also cover EJB and Webbeans integration as as-some of the enhanced DI features off Ered by Webbeans. Until Then, Adios amigos! References JSR 316:java EE 6, http://jcp.org/en/jsr/detail?id=316. JSR 318:enterprise JavaBeans 3.1, http://jcp.org/en/jsr/detail?id=318. JSR 299:web Beans, http://jcp.org/en/jsr/detail?id=299. Spring Pitchfork Project, http://static.interface21.com/projects/pitchfork/files/m4/docs/reference/html_single/.