Register for Real-World Java Seminar
In the first part of this article you learned how Java EE 5 has simplified enterprise application development by adopting a POJO programming model and making use of Java 5 metadata annotations. You also discovered how the Spring Framework version 2.0 integrates with Java Persistence API (JPA) and makes it simple to use from enterprise Java applications.
In this second part, you will learn how you can integrate the Spring Framework with EJB 3 components and to exploit Spring's declarative transaction features with Java EE applications. Finally we'll discover how Java EE application servers provide seamless management of Spring components from their JMX-enabled management consoles.
Using Spring and EJB 3
As we discussed in Part 1 of this article, EJB 3 greatly simplifies development of EJB components. Spring's Pitchfork project implements part of the EJB 3 specification, for example, enabling use of @Stateless or @Resource annotations with Spring beans. It also lets developers use @Stateless annotations in a web container.
You can mix and match EJB 3 and Spring components to leverage the power of both frameworks. For example, you can combine such features as statefulness, pooling, clustering, declarative security, Web Service feature, and message-driven beans of EJB 3 with AOP, POJO injection , template-based data, and resource access support provided by Spring.
Injecting Session Beans
You may remember from our earlier discussion that Java EE 5 lacks support for POJO injection. If you want to use an EJB from a helper class of your Web or EJB module then injection isn't supported and unfortunately you have to resort to JNDI lookup. Note that application server vendors will provide proprietary extensions to support POJO injection.
However you can use Spring to simplify and use its powerful dependency injection mechanism to inject an instance of a session bean. This will help your applications to port between application servers. Let us dive down and see an example.
The code examples that follow are taken from my recently published book, EJB 3 in Action, published by Manning Publications.
Assume that you have a session bean named ItemManager that you will use in the ItemServiceBean, which is a Spring POJO, as shown below:
public class ItemServiceBean implements ItemService {
private ItemManager itemManager;
public ItemServiceBean() {
}
// Setter injection of ItemManagerEJB
public void setItemManager(ItemManager itemManager) {
this.itemManager = itemManager;
}
public Long addItem(String title, String description,
Double initialPrice, String sellerId) {
Item item = itemManager.addItem(title, description,
initialPrice, sellerId);
return item.getItemId();
}
}
As you can see, we are using setter injection to inject an instance of ItemManager EJB object and invoke a method on the EJB.
By now you must be wondering where the actual magic happens? We're not doing a JNDI lookup and not using the @EJB injection (that we discussed in Part 1) to inject the session bean object. The real magic occurs through wiring in the EJB through the Spring configuration.
Let's assume that the Spring Bean uses a remote business interface of ItemManager EJB and retrieves it using a Spring 2.0 simplified jee-jndi lookup as follows:
<jee:jndi-lookup id = "itemManager" jndi-name = "ejb/ItemManager" resource-ref = "true"/>
Note that we are using setter injection in ItemServiceBean to inject an instance of ItemManager EJB and we must wire the ItemManager EJB as follows:
<bean id = "itemService" class = "actionbazaar.buslogic.ItemServiceBean">
<property name = "itemManager" ref = "itemManager"/>
</bean>
Remember from our discussion in part 1 of the article that EJB 3 Session beans are POJOs and interfaces are POJI. So there's no difference between invoking EJB3 session beans with either a remote or local interface if your Spring beans and EJBs are collocated in the same container, and the configuration is identical for both local and remote session beans. If your Session bean is in a remote container you'll have to provide the JNDI properties such has provider URL, principal, and credentials to invoke the remote bean.
Spring-Enabled Session beans
We 'll examine another interesting case of integration where you can leverage the power of Spring in an EJB 3-based application. You can use Spring in your session beans (both stateless and stateful) and message-driven beans (MDB). I'll demonstrate the use of Spring beans from an EJB 3 stateless session bean. If you've used Spring with EJB 2 you may remember that the framework provides several factory classes for such integration. You can use those abstract classes with EJB 3 session beans to enable access to the Spring bean factory. As these factory classes require they have to implement the onEjbCreate() method in your EJB 3 bean class to access a Spring bean.
Below is the same EJB 3 example (PlaceBid EJB) transformed into a Spring-enabled stateless session bean. Here the PlaceBid EJB acts as a façade and delegates the actual business logic to the PlaceBidServiceBean.
@Stateless(name = "PlaceBid")
public class PlaceBidBean extends AbstractStatelessSessionBean
implements PlaceBid {
private BidServiceBean bidService;
public PlaceBidBean() {
}
protected void onEjbCreate() {
bidService =
(BidServiceBean) getBeanFactory().getBean("bidService");
}
public Long addBid(String userId, Long itemId, Double bidPrice) {
return bidService.addBid(userId, itemId, bidPrice);
}
}
Now let's explore how the Spring bean factory is created and how the Spring configuration is provided.
When an EJB instance is created (when a client invokes an EJB), the onEjbCreate method is invoked automatically. A JNDI lookup is done to obtain the path for the bean factory by using an environment entry named ejb/BeanFactoryPath. So you have to define it in the EJB deployment descriptor for the EJB:
<session>
<display-name>PlaceBid</display-name>
<ejb-name>PlaceBid</ejb-name>
<env-entry>
<env-entry-name>ejb/BeanFactoryPath</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>/actionBazaar-service.xml</env-entry-value>
</env-entry>
</session>
Although EJB 3 made deployment descriptor optional there are a few cases where you still have to use it. If you're a heavy Spring user you live and breath XML configurations so you have nothing to complain about! In our example we've set the env-entry-value for the ejb/BeanFactoryPath environment variable at /actionBazaar-service.xml. So you have to package the EJB classes, Spring classes, and Spring configuration file into your ejb-jar package.
This way you can use the declarative security, transaction, remoteability, and Web Service features of EJB and combine that with POJO injection, AOP, simplified data, and resource access of Spring. Next we'll see a powerful combination of MDB and Spring JmsTemplate.
JmsTemplate and Message-Driven Beans
Message-driven Beans are simple to develop and can be configured as a message consumer. MDBs support several performance features such as pooling and may either be used with a JMS-compliant provider or an EIS using a JCA 1.5-compliant connector. Below is a simple MDB configured against a JMS provider.
@MessageDriven(activationConfig = {
@ActivationConfigProperty(propertyName =
"destinationName", propertyValue =
"jms/OrderBillingQueue"),
@ActivationConfigProperty(propertyName =
"destinationType",propertyValue =
"javax.jms.Queue") })
public class OrderBillingMDB implements MessageListener {
public void onMessage(Message message) {
}
Building JMS producer with Java EE 5 is still a pretty complex task in spite of its injection support. Spring makes building a message producer application very simple as evident in the following code:
public void sendMessage() {
try {
..
JMSSender jmsSender =
(JMSSender)appContext.getBean("jmsSender");
jmsSender.sendMesage();
} catch(Exception e) {
e.printStackTrace();
}
}
Looks pretty simple! You must be wondering: what is the connection factory and destination configured that this client is sending a message to? The magic is done in background by the Spring configuration as specified below:
<bean id="connectionFactory">
class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName">
<value>jms/QueueConnectionFactory</value>
</property>
</bean>
<bean id="jmsDestination"
class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName">
<value>jms/OrderBillingQueue</value>
</property>
</bean>
<bean id="jmsTemplate"
class="org.springframework.jms.core.JmsTemplate102">
<property name="connectionFactory">
<ref bean="connectionFactory"/>
</property>
<property name="defaultDestination">
<ref bean="jmsDestination"/>
</property>
</bean>
<bean id="jmsSender" class="oracle.fusion.demo.OrderService">
<property name="jmsTemplate">
<ref bean="jmsTemplate"/>
</property>
</bean>
If you look at this code, the JMS producer code is very simple, however, you have to write quite a bit of XML configuration. It's your choice!
While building enterprise applications you probably want your business operations to be transactional. Next we'll see how you can use Spring declarative transactions and how Java EE containers provide the integration of Spring with their Transaction Manager.
Spring-Declarative TX and Integration with Application Server TM
Java EE provides a robust platform for building and deploying a transactional enterprise application. Java EE supports both programmatic and declarative transactions and unfortunately you can use declarative transactions only with EJB. Spring has robust support for declarative transactions and you can use the scheme with any POJO, adding declarative transaction capability to the Web container.
Let's assume that you want to define a declarative transaction for a method in a Spring bean. You have the following code:
@Transactional(propagation = Propagation.REQUIRES_NEW, isolation = Isolation.READ_COMMITTED)
public Long addBid(Bid bid) {
..
}
When the addBid() method is invoked, Spring will automatically start a new transaction per our definition. The integration between Spring and the application server's transaction manager is what makes that possible.
Java EE containers such as Oracle Containers for Java EE (OC4J) provide integration between the transaction manager and Spring so that declarative transactions can be used. You can enable such integration with a simple setting:
!-- enable the configuration of transactional behavior based on annotations -->
<tx:annotation-driven/>
<bean id="transactionManager" class="org.springframework.transaction.jta.OC4JJtaTransactionManager">
The Manageability of Spring Components
While Spring components are easier to build and deploy in an application server, managing them may pose maintainability issues since Spring is a "foreign" framework. Application servers such as Oracle Application Server address this with interesting integration for managing Spring components.
For example, a Spring bean can be exposed in the MBean browser of Oracle's Application Server Control by making some minimal configuration changes in the Spring application context configuration. For example, we can register the Spring beans with the following Spring configuration:
<bean id="howToMBeanServer" class="org.springframework.jmx.support.MBeanServerFactoryBean">
<property name="defaultDomain" value="SpringHowTo" />
</bean>
<bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
<property name="beans">
<map>
<entry key="bean:name=empService" value-ref="empService" />
<entry key="bean:name=employeeDAO" value-ref="employeeDAO" />
</map>
</property>
<property name="server" ref="howToMBeanServer" />
</bean>
The Spring beans appear as application-defined Managed Beans (MBean) in the MBean browser of application server's management console. e.g., OracleApplication Server Control's MBean browser as shown in Figure 1. Thus managing Spring components is a snap!
You can perform MBean operations on the Spring beans deployed as a part of your application
Conclusion
This concludes the second installment of the two-part article. In this article, we provided a series of examples to illustrate how Java EE 5 developers can exploit some common integration points with the Spring Framework. Specifically, we demonstrated how EJB 3.0 and JPA combine naturally with Spring, as well as demonstrated how Spring-based applications can utilize high-end Java EE container services such as database access and the JMS messaging infrastructure. Finally you learned how application servers provide management capability for Spring beans.