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.


Tuesday, November 30, 2010

Java EE 6

Lets talk about some of the major new features from JEE6, like profile, pruning, extensibility and ease of development. Web profile is targeted bundle of technology or other words stack of technology, profile can be sub set, super set or overlapping. here's stack from first web profile under JEE 6.

Servlet 3.0
JSP2.2
EL2.2
JSP Tag Library 1.2
JSF 2.0
EJB 3.1
Common Annotation for Java 1.1
Java Transaction API 1.1
JPA 2.0

While JEE6 provide you some new features, they are taking out some out dated feature sets, like JAX-RPC, EJB - Entity Bean and JAX-R.

Under Extensibility, JEE6 embrace Open Source Library and frameworks. Also, servlet, servlet filter and context get discovered and register for you. Provide zero configuration and scripting language can be used in some cases.
And of course, java CDI is answer for Spring DI and provide similar functionality to developers.

Overall JEE6 looks interesting and you might want to take a look at full stack from Sun, oops from Oracle :-)

Friday, November 19, 2010

What's new in Spring 3.1 - Part II

As you can see from my previous post, that I love talking about Spring Framework and recently in Spring 2GX, they have announced how Spring 3.1 will lay out. It surely looking promising as Spring team puts lots of thought behind each Spring framework milestone. Here are most of the features that you are going to see in Spring 3.1 world.

Scheduler Enhancement - you can schedule cron job to call from java bean, similar to timer bean..
Improve and support JEE6 - Continue to provide more feature enhancement for JEE6
Environment profiles for bean- I think this will be widlt used as this allow to have a profile for different environment, like development, test and production. In other words grouping bean definition for activation in specific environments.
Java based application configuration- I think this will help developers who does not want to deal with XML configuration and want to configure using annotation in java class.

@Configuration
Public class applicationConfiguration
{
@AutoWired
private DataSource ds;
@bean
public OrderDetail OrderDetail(){
return new OrderDetailImpl(ds);
....

}

}

Cache Abstraction- provide support for distributed caching that is specially useful for caching solution in cloud . Also will have common adopter for cache solution provider like EHCache. they have support for convenient caching annotation "@Cacheable", they have cache manager API for EHCacheCacheManager, GemFireCacheManager

Conversation Management - provide abstraction for conversational sessions, you should be able to identify conversational state by may be passing around ID for conversational states, I think you might be able to externalize session information and use as distributed caching. Also this theme will provide foundation for Web Flow 3.0

Servlet 3.0, JSF 2.0, Groovy - Automatic deployment of framework listeners. which I think might have drawback as you don't want to deploy everything (as you might be using all ths listeners), they will have support for JSF2.0 and will have more support. They might have template classes for Groovy support.


Friday, October 29, 2010

Keys concept for Building Internal Cloud

Here are some important Key Ingredients for Building an Internal Cloud:


1.Shared Infrastructure. IT needs to understand how to configure the underlying storage and networking so that when it is brought together it can be shared across all of the enterprise’s different workloads. They also need to determine where in that shared infrastructure they should delineate between different users on that infrastructure. And also they need to fully understand their current infrastructure in order to re-use some of tis capabilities. Some keys area to consider like DB or Queue provision on their infrastructure.


2.Self-Service Automated Portal. It is essential to make sure that the compute cloud can be consumed in an easy form by both developers and IT professionals. There is a need for self- service capabilities, and for highly automated provisioning portals that provide the ability to add workloads without having to go through all of the many different steps of provisioning with the network and underlying storage.


3.Scalable. An effective cloud solution has to be scalable. IT organizations should think about boundary conditions in a more creative way, instead using the traditional models of scalability. As a new workload request comes up, they must determine where to provision that specific workload.


4.Rich Application Container. Clouds need to have a richer application container that will show the different interdependencies between components of the application, specifically those that take place between different virtual machines. This information help create the correct network subnets so that the storage will work well together and not be isolated from one another.


5.Programmatic Control. It is very common for a compute cloud to have programmatic control. Some of the more popular compute clouds on the market today have made good use of an API called REST. REST is a very simple HTTP- based protocol that provides the ability to manipulate stateful objects in a clear way. It's better to have organization which have Service Oriented Architecture (SOA), which provided you interoperability and easy to use services, and provide re-use and loose coupling between different applications within an enterprise.


6.100% Virtual Hardware Abstraction. Clouds need 100% hardware abstraction. This can include servers or other physical devices like storage. In a cloud environment, the user should be able to interact with the virtual machines and other devices through the user interface, verses actually changing physical infrastructure.


7.Strong Multi-Tenancy. Strong multi-tenancy involves extensive use of VLANs to isolate network traffic between different zones in the cloud. This is obviously critical in an external cloud, but also a common requirement in internal clouds, to make sure that authorized users have access to certain applications.


8.Chargeback. This may not be 100 % true when you are building internal cloud within organization, but its to have this practice as IT organizations must be able to create effective and accurate chargeback capabilities. For internal clouds, even if funds aren’t literally exchanged,, the ability to create transparency in costs and services can help justify expenses.



Saturday, October 16, 2010

What's new in Spring 3.1?

With all of the good stuff in Spring 3.0, it's hard to imagine what could possibly follow in Spring 3.1.

I just got this news from Spring2GX event side that they are introducing a number of often-requested configuration features. Need a standalone datasource in dev, but one from JNDI in production? Environment-Specific Bean Definitions are a first-class approach to solving this very common kind of problem. Love code-based configuration, but need the power and concision of Spring XML namespaces?


I'm guessing they will have support or integration for other languages like Scala, Groovy etc....well this event is one week away and will update more as i get more info about this...


Just to see what we have so far from spring, here are some points from Spring 3.0 enhancements


Full-scale REST support in Spring MVC, including Spring MVC controllers that respond to REST-style URLs with XML, JSON, RSS, or any other appropriate response. We'll look into Spring 3's new REST support in chapter 12.

A new expression language that brings Spring dependency injection to a new level by enabling injection of values from a variety of sources, including other beans and system properties. We'll dig into Spring's expression language in the next chapter.

New annotations for Spring MVC, including @CookieValue and @RequestHeader, to pull values from cookies and request headers, respectively. We'll see how to use these annotations as we look at Spring MVC in chapter 7.

A new XML namespace for easing configuration of Spring MVC.

Support for declarative validation with JSR-303 (Bean Validation) annotations.

Support for the new JSR-330 dependency injection specification.

Annotation-oriented declaration of asynchronous and scheduled methods.

A new annotation-based configuration model that allows for nearly XML-free Spring configuration. We'll see this new configuration style in the next chapter.

The Object-to-XML (OXM) mapping functionality from the Spring Web Services project has been moved into the core Spring Framework.