Accessing EJBs(Enterprise Java Beans):-
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.