Spring Tutorials

Enterprise Java Beans (EJB) can be used extensively in Spring’s environment. The transparent support available in Spring for using the Stateless and the Stateful Session Beans in Spring.As a lightweight container, Spring is often considered an EJB replacement.

We do believe that for many if not most applications and use cases, Spring as a container, combined with its rich supporting functionality in the area of transactions, ORM and JDBC access, is a better choice than implementing equivalent functionality via an EJB container and EJBs.

It is important to note that using Spring does not prevent you from using EJBs. Spring makes it much easier to access EJBs and implement EJBs and functionality within them. Additionally, using Spring to access services provided by EJBs allows the implementation of those services to later transparently be switched between local EJB, remote EJB, or POJO (plain old Java object) variants, without the client code having to be changed.

The Spring Distribution for providing integration support of Enterprise Beans.That provide the important classes available in the following packages:

• org.springframework.ejb.support
• org.springframework.ejb.access

There are two ways to accessing EJB in Spring. When call a method on a local or remote stateless session bean, client code must normally perform a JNDI lookup to obtain the (local or remote) EJB Home object, then use a create method call on that object to obtain the actual (local or remote) EJB object. One or more methods are then invoked on the EJB.

To avoid repeated low-level code, many EJB applications use the Service Locator and Business Delegate patterns. These are better than spraying JNDI lookups throughout client code, but their usual implementations have significant disadvantages.

For example

1. Typically code using EJBs depends on Service Locator or Business Delegate singletons, making it hard to test.
2. In the case of the Service Locator pattern used without a Business Delegate, application code still ends up having to invoke the create() method on an EJB home, and deal with the resulting exceptions. Thus it remains tied to the EJB API and the complexity of the EJB programming model.
3. Implementing the Business Delegate pattern typically results in significant code duplication, where we have to write numerous methods that simply call the same method on the EJB.

The Spring approach is to allow the creation and use of proxy objects, normally configured inside a Spring container, which act as codeless business delegates.

Spring Framework especially supports accessing stateless type of EJB. The obtained EJB is here treated like an ordinary Spring bean (type: org.springframework.ejb.access.LocalStatelessSessionProxyFactoryBean). There needs to be specified the JNDI name of the EJB and the business interface in Spring bean definition. Additionally, when the resourceRef attribute is set to true then the mandatory JNDI prefix: java:comp/env is added automatically to the name.

<bean id="eJBService"
class="org.springframework.ejb.access.LocalStatelessSessionProxyFactoryBean">
<property name="jndiName" value="ejb/eJBService"/>
<property name="businessInterface" value="com.r4r.in.eJBService"/>
<property name="resourceRef" value="true" />
</bean>
<bean id="springController" class="com.r4r.springController">
<property name="ejbService" ref="eJBService" />
</bean>

The springController bean definition sets the eJBService property of the controller class to the EJB proxy. Alternatively (and preferably in case of many such proxy definitions), consider using the <jee:local-slsb> configuration element in Spring’s "jee" namespace:

<jee:local-slsb id="eJBService"
business-interface="com.r4r.ejbService"
jndi-name="ejb/eJBService" resource-ref="true" />

This EJB access mechanism delivers huge simplification of application code: the web tier code has no dependence on the use of EJB. If we want to replace this EJB reference with a POJO or a mock object or other test stub, we could simply change the eJBService bean definition without changing a line of Java code. Additionally, we haven’t had to write a single line of JNDI lookup or other EJB plumbing code as part of our application.

Accessing remote EJBs is essentially identical to accessing local EJBs, except that the SimpleRemoteStatelessSessionProxyFactoryBean or <jee:remote-slsb> configuration element is used. of course, with or without Spring, remote invocation semantics apply; a call to a method on an object in another VM in another computer does sometimes have to be treated differently in terms of usage scenarios and failure handling.

There is also possible to obtain remote EJB component by using SimpleRemoteStatelessSessionProxyFactoryBean instead of LocalStatelessSessionProxyFactoryBean and remote-slsb instead of local-slsb in case of spring-jee.xsd schema. The JndiEnvironment probably will be required to specify to access remote objects.

1. Prepare EJB component
2. Define an appropriate Spring bean representing EJB (point to right JNDI name, business interface, optionally set additional properties e.g. resourceRef) by specifying FactoryBean class:

org.springframework.ejb.access.LocalStatelessSessionProxyFactoryBean or

org.springframework.ejb.access.SimpleRemoteStatelessSessionProxyFactoryBean.

3. Use the bean definition where needed.