Thursday, January 13, 2011

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


Saturday, December 18, 2010

SOA Governance

As you can see from the title of this post "Governance", i'm going to provide some inside about SOA Governance, SOA architectural world has defined governance in two category.


Design time governance
Runtime governance

Now lets talk about Design time governance-

Design time service governance, as the name implies, typically provides an integrated registry/repository that attempts to manage a service from its design to its deployment, but typically not during runtime execution of the services, albeit some do. Key components of design time service governance include

-A registry and/or repository for tracking service design, management, policy, security, and testing artifacts

-Design tools,including service modeling,dependency tracking,policy creation and management, and other tools that assist in the design of services

-Deployment tools, including service deployment, typically through binding with external development environments

-Links to testing tool sand services,providing the developer/designerthe ability to create a test plan and testing scenarios and then to leverage service-testing technology

In essence, design time service governance works up from the data to the services, gathering key information as it goes. You typically begin by defining the underlying data schema and turning that into metadata and perhaps an abstraction of the data. Then, working up from there, you further define the services that interact with the data, data services, and then transactional ser- vices on top of that. You can further define that into processes or orchestra- tion. All this occurs with design time information managed within the design time service governance system.


Runtime service governance - works and plays in the world of service man- agement and should be linked with design time service governance, but often is not. Design time is all about defining the policies around the use of services. Therefore, runtime governance is the process of enforcing and implementing those policies at service runtime, but it may do other things as well.

Runtime service governance, like design time service governance, comes in many flavors because of the number of vendors in that space and how it is defined by that vendor. There are no de facto standards as to what runtime ser- vice governance needs to be, but certain patterns are emerging.

Runtime service governance typically includes

Service discovery

Service delivery

Security

Setting and maintaining appropriate service levels

Managing errors and exceptions

Enabling online upgrades and versioning

Service validation

Auditing and logging


I hope this will provide some details about SOA governance.