EJB 3.1 - Async Bean Or Message Driven Bean

Here's my first post of Year 2011, Happy New Year to Everyone. I'm doing some real hands on with EJB 3.1 and trying to work on different bean types from JEE 6 spec. One of bean types is Asynchronous Bean. what's the scope of Async bean and where you can use this? Does it add any extra value to pre-exisitng pattern(Message Driven Bean). Since most popular(in my opinion) open source framework (spring) provides Async bean type functionality with MDP (Message driver POJO). I'm not talking about MDP here, but if you are interested please follow this link:

JMS with Spring Framework After doing some POC and examples it seems like Async bean might gain adoption as enterprises move to newer version of JEE.

Lets dive in here, while using 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 session bean invocation is designed to solve. With this enhancement, you can do asynchronous processing simply by annotating a session bean method with the@Asynchronous annotation.Let's take a look at the re-factored EJB 3 in Action example for asynchronous billing using the feature

@Stateless

public class MovieServiceBean implements MovieService {

  ...



  @Asynchronous

  public void rentMovie(Movie movie) {

      try {

          // Attempt to charge the Movie rent.

          Rent(movie);

          // Send email notification of Renting Movie success.

          notifyRentSuccess(movie);

          movie.setStatus(MovieStatus.COMPLETE);

      } catch (BillingException be) {

          // Send email notification of Rent Movie failure.

          notifyBillingFailure(be, movie);

          movie.setStatus(MovieStatus.BILLING_FAILED);

      } finally {

          update(movie);

      }

  }



  ...

}

Because of the @Asynchronous annotation, when the client invokes the MovieService.rentMovie method, the call will return immediately instead of blocking until the rentMovie method finishes executing. The EJB container will make sure the method gets executed asynchronously (I think might be using messaging under the hood). As you can see, the return type of the asynchronous method is void. This will probably be the case for a vast majority of asynchronous Session bean methods. However, EJB 3.1 can also support a return type ofjava.util.concurrent.Future, where V represents the resultant value of an asynchronous invocation. In case you are unfamiliar with it, the Future interface allows you to do things like cancelling an asynchronous invocation, checking if an invocation is complete, check for exceptions and getting the results of an asynchronous invocation. Check out the documentation for the Future interface here:http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html. Let's take a quick look at an example using the Future return type. In the rent method in the previous example, we set the status of the movie according to the outcome of the billing attempt and updated the movie. Let's assume that the invoker updates the movie themselves and wants to know what the status of the billing attempt was. We could do this by refactoring the rentMovie method as follows:

@Stateless

public class MovieServiceBean implements MovieService {

  ...



  @Asynchronous

  public Future<MovieStatus> rentMovie(Movie movie) {

      try {

          // Attempt to charge the movie rent.

          Rent(movie);

          // Send email notification of renting movie success.

	    notifyRentSuccess(movie);

          return new AsyncResult<MovieStatus>(rentMovie.COMPLETE);

      } catch (BillingException be) {

          // Send email notification of renting movie failure.

          notifyBillingFailure(be, movie);

          return new AsyncResult<MovieStatus>

              (MovieStatus.BILLING_FAILED);

      }

  }



  ...

}

The javax.ejb.AsyncResult object is a convenience implementation of the Futureinterface. It takes the result of the asynchronous invocation as a constructor argument. There's nothing stopping you from using your own implementation of Future however. Asynchronous invocation supports a few other neat features like delivery guarantees and transacted send semantics. For details, check out the spec and have fun