Spring's take on Java EE 6

Java EE platform main destination was to provide a framework to developer a user level component model, but initially it stayed more as a deployment platform and system service provider. Spring could play one on man-ship  by providing Business component framework and infrastructural orchestration framework. This differentiator has put Spring where it is now "Challenging the forte of Java EE". Although, Spring could not build a successful app server, but it could build on where J2EE left.

Java EE 5 could get it on level playing field with match up version of Spring 2.5 with its comprehensive support of annotations for EJB life-cycle.
In 2009, Java again did another long jump to make Spring run for its money. Here I present Java EE 6 features with Spring answer to it. There are two major improvement of Java EE which has got Spring into catchup game: JAX-RS and EJB 3.1 improvements.

JAX-RS:
After some time, every tech bound to become obese that what has also happened to Web Service. To save the world, a bond appears and in this case it is Restful Web Service (Representational State Transfer), an platform independent standard. It is light weight Web Service which considers everything on server as a resource and allows access. But there are apprehension about it.
It uses servlet container to expose server resources as URI to Endpoint implementation. It can be used to get very atomic interaction with sever with expected less processing of data.  But has a limitation of isolation from all server side processing in application server (EJB, JSF, severTempalate, viewDispatcher, serverContextServlet, DAO, etc). That is why its is also called island tech standard and discouraged from server side programming as well as MVC model. 
It has its place in cloud computing, where client are powerful, capable of maintaining states and driver of processing on server. It can also be useful in Rich Internet Content based client like Flex, Java App, Applet etc where server is only used for resource access.

@Path("widget")
public class WE {
@Autowired
private WE sever;
@GET
@Path("{id}")
@Poduces("text/html")
public String getWidget(@PathParam("id") {}
@post
@Consumer("application/widget+xml"}
public void setWidget(Widget widget) {}
}

Spring: Its MVC model can be morphed into RESTful service development with its native support for URI template variable extraction, ability to design resources in hierarchical endpoints and web user interface as web service.  

EJB 3.1:
Heart of the Java EE system is EJBs and it can be left out of touch with each version upgrades. Few of new features are addition of default convention for JNDI name for EJBs, declarative transactional model and allowing deployment of EJBs within WAR archives.  
Also a new concept EJB 3.1 lite = EJB 3.1 - Remote Bean - Message Bean =  Local Bean 

Singleton bean with declarative concurrency:
EJB brings singleton to remove session bean issues of pooling overhead and cerainly compete with Spring on this. Also control of bean lifecycle like Startup and shutdown hook. New bean feature Container Managed Locking presents an aggressive default strategy with write lock on all methods. Though, developer still have option of bean-managed concurrency option still in hand.

@Singleton @Startup
@DependsOn({"OtherObj", ..})
public class A {
public Data sData;

@PostConstruct
public void init() {}

@Lock(READ)
public string retunSharedDataValue() {
retun this.sData;
}

Spring: Consideration of defaults is This is where fundamental difference between Java EE and Spring crops up.

Java EE 6	Spring
Lazy initialization with EJB container	Eager initialization with EJB container;
Does not load at startup;	Loads Bean at startup;
@Startup to push the inilization front	@Lazy to push the initilization back
Forces WRITE lock on initialized bean	Does not force any lock on bean instanace
Override by @Lock annotations	Depend on concurrency API from users

Async Methods:
Any component can call these @Asynchronous annotation-ed methods, container will spun a new thread from pool and return Future object which returns will contain result in future. Callling componet can call get on Future method to see if result are ready to be consumed. With Future return type, a new class AsyncResult package retured results.

@Stateless
public class A {
@Asynchronous
public void methodA() {}

@Asynchronous
public Future methodB() {
return AsyncResult(value);
} }

Spring: It has @Async for sometime, but differs in void return behaviors where caller does not get return value. Spring maintains natural support for EJB 3.1 with its dedicated container with defaults for transaction and concurrency. 

I have talked about newly added feature in my earlier blog "Java EE 6 - Coming of age". Here I just talk about Spring response to it.


Concurrency: JSR 236
Spring: Spring already has answer to this by having their own Scheduler Adopter implementation packaged.  

Web Bean: JSR 299
Spring: Spring claims that Web Beans are inspired by their native DI approach with a differentiators like component scoping which they will match in next release. 

Web Profile:
Spring: Spring still deploy full set but doubt about vendor inclination to implement web profile. 
 

JSF 2.0:
Spring: Spring provides natural integration to JPA tech. But it also has managed bean concept already implemented as @Component @Value.
JPA 2.0:
Spring: It provides natural integration to it. But it dear Hibernate needs to lot work for its 4.0 release.


References: 

• Spring and Java EE 6 - Jurgen Holler
• http://www.infoq.com/news/spring-ejb-3-compared/
• Stefan Tilkov: Java EE/EJB 3 vs. Spring
• http://java.sys-con.com/node/366297 
• Spring and Java EE 5 (PART 2)
• http://www.devx.com/Java/Article/32314/0/page/1
• http://onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html
• http://www.theserverside.com/tt/articles/article.tss?l=SpringNewJavaEE