Bernard Ligny

About Bernard Ligny

Bernard is a Senior IT Architect working on the Java ecosystem since 1999 in many different functional areas. He feels passionate about building elegant, scalable and effective Java solutions using the most appropriate software and techniques, with these last years a particular interest in E.A.I.

From Spring to Java EE 6

I recently worked on a quite complex project mixing many Java EE 6 technologies (such as JPA, JAXB, JMS, JTA, JAX-RS, etc…). For productivity and planning reasons, the prototyped application was designed as a standalone pure Spring application. When the development of the real application started, we re-challenged our initial choice (i.e. Spring v3) and analyzed the interest of switching to a Java EE 6 app server like GlassFish or JBoss.
This finally ended up in two major questions:

  • can we do in Java EE 6 everything we can do in Spring ?
  • can we do that as easy as in Spring ?

Well, I would say that, globally, the answer is: yes we can !

I do not want to reopen the (endless) debate of knowing which one, between Spring and Java EE 6, is the best. No, I just want to share with you my experience regarding this migration. I was – and I am still – a real Spring fanboy (which I, historically speaking, discovered after having been literally disgusted by EJB’s 1.0), but I am also aware of the recent progress, not to say simplifications, that have been introduced in Java EE  these last years, as well as the impressive speed improvements on the side of Java EE 6 application servers.

Let us now study in details some typical requirements of “enterprise” applications, and compare the code to produce in both worlds for:

  • Contexts & Dependency Injection
  • Messaging
  • Transaction management
  • Web services

This comparison should provide you with some concrete decision elements in the event you hesitate to migrate from one technology to the other…

Part I : Contexts & Dependency Injection (CDI)

Spring allows you to define beans using various stereotypes (eg @Repository, @Service, @Controller, and @Component). The one to choose is not that important (that’s not entirely true. For instance, tagging your DAO as @Repository will add the automatic translation of SQL exceptions) as this distinction is mostly intended to IDE’s (in order to categorize beans). Optionally, you can give your bean an alias.

public interface MyInterface {...}
import org.springframework.stereotype.Component;

@Component("firstBean")
public class MySpringBean implements MyInterface {...}

@Component("firstBeanMock")
public class MockImpl implements MyInterface {...}

Java EE provides a very similar annotation (@Named) but its use should be limited to pure pojo’s. In case of service-oriented beans (especially transactional coarse-grained services), consider using a (preferably stateless) EJB – namely because they offer better scalability.

import javax.inject.Named;

@Named("firstBean")
public class MyJeeBean implements MyInterface {...}
import javax.ejb.Stateless;

@Stateless(name="firstService")
public class MyJeeService implements MyInterface {...}

Also beware that, in contrary to Spring, singletons should be explicitly marked as such in Java EE:

import javax.inject.Singleton;

@Singleton
public class MyJeeSingleton implements MyInterface {...}

Remark: you may get confused when choosing between a “javax.inject.Singleton” and a “javax.ejb.Singleton”. The first one defines a standard POJO managed by the container (aka a “Managed Bean” in the Java EE world), while the second one defines an “Enterprise Bean”. Remember that the later is designed for concurrent access (a client doesn’t need to worry about any other clients that may be simultaneously invoking the same methods of the singleton) and also offers transaction management facilities (see further).

Now that we have registered (and optionally named) our beans, we can inject them in other beans. Once again, the procedure is somewhat similar at both sides:

SPRING

import org.springframework.stereotype.Component;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Qualifier;

@Component
public class UseCaseHandler {

  @Autowired
  @Qualifier("firstBean")
  private MyInterface serviceFacade;
  
}

JAVA EE 6

import javax.inject.Named;
import javax.inject.Inject;

@Named
public class UseCaseHandler {

  @Inject
  @Named("firstBean")  
  private MyInterface serviceFacade;
  
}

Remark: The JSR-330 has unified the way to inject managed beans. This concretely means that the @Inject annotation can be used to inject simple POJOs as well as EJB’s (making thereby the @EJB annotation a bit obsolete).

Fine ! However, in the real world, the name (eg “firstBean”) of the beans we want to inject might be dynamic. This is particularly true as soon as you play with behavioral patterns, generics, etc…

In Spring, this is pretty easy. You can for instance make your bean ApplicationContext-aware, so that you can then use the injected Spring context in order to lookup for specific bean instances:

import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
import org.springframework.stereotype.Service;

import com.javacodegeeks.Request;

@Service
public class Dispatcher implements ApplicationContextAware {
 
 private ApplicationContext appContext;

 public void setApplicationContext(ApplicationContext ctx) throws BeansException {
  appContext = ctx;
 }
 
 public void dispatch(Request request) throws Exception {
  String beanName = "requestHandler_" + request.getRequestTypeId();
  RequestHandler myHandler = appContext.getBean(beanName, RequestHandler.class);
  myHandler.handleRequest(request);
 }
 
}
public interface RequestHandler  {
 public void handleRequest(Request request);
}
@Component("requestHandler_typeA")
public class HandlerA implements RequestHandler {...}
@Component("requestHandler_typeB")
public class HandlerB implements RequestHandler {...}

In Java EE 6, the same is possible but yet requires a bit more lines of code (that could be centralized in an helper class):

import java.util.Set;
import javax.inject.Inject;
import javax.inject.Named;
import javax.enterprise.context.spi.CreationalContext;
import javax.enterprise.inject.spi.Bean;
import javax.enterprise.inject.spi.BeanManager;

import com.javacodegeeks.Request;

@Named
public class Dispatcher 
 
 @Inject
 private BeanManager beanManager;
 
 public void dispatch(Request request) throws Exception {
  String beanName = "requestHandler_" + request.getRequestTypeId();
  RequestHandler myHandler = this.getBean(beanName, RequestHandler.class);
  myHandler.handleRequest(request);
 }
 
 @SuppressWarnings("unchecked")
 private <T> T getBean(String name, Class<T> clazz) throws Exception {
  Set<Bean<?>> founds = beanManager.getBeans(name);
  if ( founds.size()==0 ) {
   throw new Exception("No such bean found: "+name);
  } else {
   Bean<T> bean = (Bean<T>) founds.iterator().next();
   CreationalContext<T> cc = beanManager.createCreationalContext(bean);
          T instance = (T) beanManager.getReference(bean, clazz, cc);
          return instance;
  }
 }
 
}
public interface RequestHandler  {
 public void handleRequest(Request request);
}
@Named("requestHandler_typeA")
public class HandlerA implements UseCaseHandler {…}
@Named("requestHandler_typeB")
public class HandlerB implements UseCaseHandler {...}

PART II : JMS

Java Messaging Service eases the implementation of a loosely coupled distributed communication.
This is why it has become a classical technique in Enterprise Application Integration (EAI).

Spring has an outstanding JMS support. You can very quickly setup JMS producers or consumers,
with destination resolvers, and optionally with an automatic conversion of JMS messages into pojos (and vice-versa). On the other hand, J2EE comes with a rich set of annotations in order to access or define JMS resources such as queue/topics, connection or messages-oriented beans.

Let’s start with a JMS client that receives messages, that is a message consumer (or subscriber):

SPRING

<bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
 <property name="environment">
         <props>…</props>
 </property>
</bean>
    
<bean id="jmsConnectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean">
      <property name="jndiTemplate" ref="jndiTemplate" />
      <property name="jndiName" value="java:/JmsXA" />
</bean>
    
<bean id="jndiDestResolver"
 class="org.springframework.jms.support.destination.JndiDestinationResolver">
 <property name="jndiTemplate" ref="jndiTemplate" />
</bean>
 
<bean id="jmsContainer"
 class="org.springframework.jms.listener.DefaultMessageListenerContainer">
 <property name="connectionFactory" ref="jmsConnectionFactory"/>   
 <property name="destinationResolver" ref="jndiDestResolver"/>  
 <property name="destinationName" value="queue/myQueue"/>
 <property name="messageListener" ref="myMsgConsumer" />
</bean>
   
<bean id="myMsgConverter" class="com.javacodegeeks.MsgToRequestConverter"/>
   
<bean id="myMsgConsumer" class="com.javacodegeeks.MsgConsumer"/>
import javax.jms.Message;
import javax.jms.MessageListener;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.jms.support.converter.MessageConverter;

import com.javacodegeeks.Request;
import com.javacodegeeks.Dispatcher;
        
/**
 * Example of message consumer (Message-Driven-Pojo) in Spring
 */
public class MsgConsumer implements MessageListener {
 
    @Autowired
    private MessageConverter msgConverter;
 
    @Autowired
    private Dispatcher dispatcher;
     
    public void onMessage(Message message) {       
     try { 
      Request request = (Request) msgConverter.fromMessage(message);
      dispatcher.dispatch(request); 
     } catch (Exception e) {
    e.printStackTrace();    
     } 
    }

}

JAVA EE 6

import javax.inject.Inject;
import javax.jms.Message;
import javax.jms.MessageListener;
import javax.ejb.MessageDriven;
import javax.ejb.ActivationConfigProperty;

import com.javacodegeeks.Request;
import com.javacodegeeks.Dispatcher ;
import com.javacodegeeks.MsgToRequestConverter;

/**
 * Example of message consumer (Message-Driven-Bean) in JEE
 */
@MessageDriven(activationConfig = { 
 @ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"),
 @ActivationConfigProperty(propertyName="destination", propertyValue="queue/myQueue") 
} )     
public class MsgConsumer implements MessageListener  {
 
 @Inject
     private MsgToRequestConverter msgConverter;

 @Inject 
 private Dispatcher dispatcher;
 
 public void onMessage(Message message) {       
     try { 
      Request request = msgConverter.fromMessage(message);
      dispatcher.dispatch(request);      
     } catch (Exception e) {
  e.printStackTrace();     
 } 
    }
    
}

Let’s now code a JMS client that creates and sends messages, that is a message producer (or publisher):

SPRING

<bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
 <property name="environment">
    <props>…</props>
 </property>
</bean>
    
<bean id="jmsConnectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean">
      <property name="jndiTemplate" ref="jndiTemplate" />
      <property name="jndiName" value="java:/JmsXA" />
</bean>
    
<bean id="jndiDestResolver"
 class="org.springframework.jms.support.destination.JndiDestinationResolver">
 <property name="jndiTemplate" ref="jndiTemplate" />
</bean>

<bean id="jmsTemplate" class="org.springframework.jms.core.JmsTemplate">
 <property name="connectionFactory" ref="jmsConnectionFactory" />
 <property name="destinationResolver" ref="jndiDestResolver" />
 <property name="messageConverter" ref="myMsgConverter" />
</bean>
    
<bean id="myMsgConverter" class="com.javacodegeeks.MsgConverter">
import org.springframework.stereotype.Component;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.jms.core.JmsTemplate;
import com.javacodegeeks.Request;

/**
 * Example of message producer component in Spring
 */
@Component 
public class MsgProducer {

 @Autowired
 private JmsTemplate jmsTemplate;
 
 public void postRequest(Request request) throws Exception {
  jmsTemplate.convertAndSend("queue/myQueue", request);
 }
 
}

JAVA EE 6

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.annotation.Resource;
import javax.inject.Inject;
import javax.jms.Connection;
import javax.jms.ConnectionFactory;
import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.MessageProducer;
import javax.jms.Queue;
import javax.jms.Session;
import javax.ejb.Stateless;
import javax.ejb.EJBException;

import com.javacodegeeks.Request;
import com.javacodegeeks.MsgToRequestConverter;

/**
 * Example of message producer (here a session bean) in JEE
 */
@Stateless(name="msgProducer")
public class MsgProducer {
 
 @Inject
     private MsgToRequestConverter msgConverter;

 @Resource(mappedName="java:/JmsXA")
 private ConnectionFactory connectionFactory;
 
 @Resource(mappedName="queue/myQueue")
 private Queue queue;
 
 private Connection jmsConnection;


 @PostConstruct
 private void initialize() {
  try {
   jmsConnection = connectionFactory.createConnection();
  } catch (JMSException e) {
   throw new EJBException(e);
  }
 }
 
 
 @PreDestroy
 private void cleanup() {
  try {
   if (jmsConnection!=null) jmsConnection.close();
  } catch (JMSException e) {
   throw new EJBException(e);
  }
 }
 
 
 public void postRequest(Request request) throws Exception { 
  Session session = null;
  MessageProducer producer = null;
  try {
   session = jmsConnection.createSession(false, Session.AUTO_ACKNOWLEDGE);
   producer = session.createProducer(queue);
   Message msg = msgConverter.toMessage(request, session);
       producer.send(msg);  
  } finally { 
   try { 
    if (producer!=null) producer.close();
    if (session!=null) session.close();
   } catch (Exception e) {
    System.err.println("JMS session not properly closed: "+ e);
   }
  }
 }
 
}

Remarks:

  • Do not forget that, in contrary to JMS connections and JMS queues, JMS sessions are not thread-safe. Sessions should therefore not be shared by all bean instances, nor be created in the constructor or in a PostConstruct method.
  • PostConstruct and PreDestroy methods should only throw runtime exceptions; this is the reason why JMS exceptions have to be wrapped (for instance) into EJB exceptions.

Part III : Transaction management

The need for transactions is crucial in system architecture, especially with the advent of SOA. In such architectures, coarse-grained transactional services can be built by assembling existing – possibly also transactional – smaller services (“microservices”).

Both Spring and Java EE fulfills this need by offering a powerful declarative (annotation-based) transaction management.

SPRING

<!-- Recognize @Transactional annotations in our beans --> 
<tx:annotation-driven transaction-manager="txManager"/>

<!-- The transaction manager to use (here the JPA implementation) --> 
<bean id="txManager" class="org.springframework.orm.jpa.JpaTransactionManager">
 ...
</bean>
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import org.springframework.transaction.annotation.Propagation;

import com.javacodegeeks.Request;
import com.javacodegeeks.RequestProcessor;

@Service
public class RequestProcessorImpl implements RequestProcessor {

 @Transactional(propagation=Propagation.REQUIRED, rollbackFor=Exception.class)
 public void process(Request request) throws Exception {
  ...
 }
 
}

JAVA EE 6

import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.ejb.TransactionManagement;
import javax.ejb.TransactionManagementType;

import com.javacodegeeks.Request;
import com.javacodegeeks.RequestProcessor;

@Stateless
@TransactionManagement(value=TransactionManagementType.CONTAINER)
public class RequestProcessorImpl implements RequestProcessor {

 @TransactionAttribute(TransactionAttributeType.REQUIRED)
 public void process(Request request) throws Exception {
  ...
 }
 
}

Be very careful with runtime/unchecked exceptions in Java EE. By default, they are automatically wrapped by the EJB container into an EJBException, which may cause surprising results (especially in try…catch statements!). If you need finer tuning of rollback cases, consider tagging such runtime exceptions as applicative exceptions, either using the @ApplicationException annotation, or by augmenting the ejb descriptor like this:

<ejb-jar>
   <assembly-descriptor>
    <application-exception>
      <exception-class>java.lang.NullPointerException</exception-class>
      <rollback>true</rollback>
    </application-exception>
   </assembly-descriptor>
</ejb-jar> 

Part IV : Restful web services

Enterprise applications often need to expose some of their services to the outside world, typically through internet. This is where web services are coming into play. Like JMS (for asynchronous communication), web services are another classical integration technique for implementing a synchronous, request-response oriented, communication using XML (or JSON) as exchange format.

SPRING

<servlet>
 <servlet-name>ws</servlet-name>
 <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
</servlet>
<servlet-mapping>
 <servlet-name>ws</servlet-name>
 <url-pattern>/services/*</url-pattern>
</servlet-mapping>
<!-- Dispatch requests to controllers + use JAXB (if found in the classpath) -->
<mvc:annotation-driven />
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.ResponseBody;

import com.javacodegeeks.Geek;
import com.javacodegeeks.GeekService;

@Controller
@RequestMapping("/geeks")
public class GeekWebService {
 
   @Autowired
   GeekService bizService;
   
  @RequestMapping(value="/{id}", method=RequestMethod.GET)
  @ResponseBody
  public Geek getGeek(@PathVariable("id") long geekId) {
     return bizService.findGeek(geekId);
 }
 
}
import javax.xml.bind.annotation.XmlAttribute;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;
 
@XmlRootElement(name="geek")
public class Geek {
 
 private String name;
 private Long id;
 
 @XmlElement
 public String getName() {
  return name;
 }
 
 public void setName(String name) {
  this.name = name;
 }
 
 @XmlAttribute
 public Long getId() {
  return id;
 }
 
 public void setId(Long id) {
  this.id = id;
 }
 
}

JAVA EE 6

import javax.inject.Inject;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;

import com.javacodegeeks.Geek;
import com.javacodegeeks.GeekService;

@Path("/geeks")
@Produces(MediaType.APPLICATION_XML)
public class GeekWebService {

 @Inject
  GeekService bizService;
   
 @GET
 @Path("/{id}")
 public Geek getGeek(@PathParam("id") long geekId) {
    return bizService.findGeek(geekId);
  }
  
}
import javax.xml.bind.annotation.XmlAttribute;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;
 
@XmlRootElement(name="geek")
public class Geek {
 
 private String name;
 private Long id;
 
 @XmlElement
 public String getName() {
  return name;
 }
 
 public void setName(String name) {
  this.name = name;
 }
 
 @XmlAttribute
 public Long getId() {
  return id;
 }
 
 public void setId(Long id) {
  this.id = id;
 }
 
}

Remark: some JAX-RS implementations, like JBoss RestEasy, do not require to modify the web.xml in order to configure and install web services…

PART V : Conclusion

Arguing that things are in Spring much simpler, much lighter than in Java EE is not – more exactly, no more – true. It is merely a matter of taste. Furthermore, recent Java EE 6 application servers (like GlassFish 3 or JBoss 6 & 7) are booting really fast, actually nearly as fast as Spring applications. Nevertheless, in a “best-of-breed” perspective, it may still be interesting to combine both technologies; this will be the subject of my next post on JCG :-)

Reference: From Spring to Java EE 6 from our W4G partner Bernard Ligny.

Related Articles :

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

3 Responses to "From Spring to Java EE 6"

  1. Jean-Jay Vester says:

    Thank you for the article.

    Just to be clear, when drawing some of these comparisons, are we including the full Spring stack portfolio, ie: Data, integration, Batch, security etc. I mention this because i find it hard to extract comparable equivalents In the EE space for some of what i just mentioned…. or am i missing something.

    In this day and age i guess it would boil down to two NB things for me:

    1. How cloud ready is EE 6, 7?
    2. Is the JCP as fast to market as VMWARE?

    Perhaps someone could enlighten me on these points.

    Thanks.

  2. Craig says:

    What is the EE 6 replacement for Spring WebFlow? I can’t imagine processing complex, multi-page forms with multiple paths without it.

  3. struberg says:

    Good article! I just like to add a few additional comments regarding CDI:

    1.) javax.inject.Singleton should work but is pretty underspecified. Use @ApplicationScoped instead will ease your job. You will get a proxy which will handle serialisation and a few other things for you. Clustering aspects are in general much easier to approach in CDI. If you use ‘NormalScoped’ beans this works out of the box.

    2.) The ‘Dispatcher': Instead of iterator().next() you should use
    Bean bean = BeanManager#resolve(beans);
    Oh and there are a few helpers in Apache DeltaSpike (check out BeanProvider for example) who provide all this and a lot of other tricks to you. I don’t know the reason you need a manual dispatcher at all. With CDI there are quite a few new patterns (producers, proxying, etc) which _might_ solve your need more elegantly.

    3.) In CDI we don’t use @Named that much but prefer typesafe injection. Either by writing your own @Qualifier or by really using Java Types. Much easier to refactor later if your compiler can check the correctness and you don’t need to hunt down random typos in some Strings.

    LieGrue,
    strub
    (Apache OpenWebBeans/TomEE guy)

Leave a Reply


four − 1 =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close