Tuesday, January 25, 2011

SOA Patterns Book Review

Recently I spent lot of time reading this book SOA Patterns. I like the problem and solution approach from this book. With this approach, users know what problem or scenario they are trying to solve with SOA architecture. This book will help enterprise to promote and build SOA solutions. This book is excellent for beginners and for advanced developers also. It actually provides very in-depth details about SOA architecture.
This book really targets practical problem and how to resolve them by adopting SOA. Chapter three and four are my favorites as they talk about pattern for performance, scalability and availability and most important aspect of SOA security.
I’m going to spread words about this book in my enterprise. I hope this review will help.

Saturday, January 22, 2011

Spring Integration - Enterprise Integration Pattern

As always, recently spring provided Enterprise Integration Pattern solution with the introduction of Spring Integration. It extends the Spring programming model into the messaging domain and builds upon Spring's existing enterprise integration support to provide an even higher level of abstraction. It supports message-driven architectures where inversion of control applies to runtime concerns, such as when certain business logic should execute and where the response should be sent. It supports routing and transformation of messages so that different transports and different data formats can be integrated without impacting testability. In other words, the messaging and integration concerns are handled by the framework, so business components are further isolated from the infrastructure and developers are relieved of complex integration responsibilities.
Spring Integration provides functionality with diffrent types of adapters, router, filter, spiltter and transformer as described in Enterprise integration Pattern. I think the real compatitor for Spring Integration is apache Camel project, Which provides similar functionality. if you are ready to use ESB, In my view these two are great option out of the box for enterprise integration pattern. which can solve lots of non complex scenrio. But if an app needed more complex routing and some advanced ESB features then an open source ESB like WSO2 or Mule might be right choice.

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