Access and implementation of EJB

As a lightweight container, spring is often considered a substitute for EJB. We also believe that, for many (and not necessarily most) applications and use cases, sping as a container, plus its rich functional support in the areas of transaction, ORM, and JDBC access, is indeed a better choice.

However, it is particularly noteworthy that the use of spring does not mean that we cannot use EJB, and in fact, spring greatly simplifies the complexity of accessing and implementing EJB components or just implementing (EJB components) their functionality. In addition, if you are accessing the EJB Component Services through spring, you can then transparently switch the implementation of the service between local EJB components, remote EJB components, or Pojo (simple Java objects) without modifying the client's code.

In this chapter, let's look at how spring is helping us to access and implement EJB components. Spring is particularly useful when accessing stateless session beans (SLSBS), and we are now starting to discuss them.

accessing EJB

Concept

To invoke a method on a local or remote stateless session bean, the client's code would have to be a jndi lookup, get a (local or remote) EJB home object, and then call the object's "create" method to get the actual (local or remote) EJB object. A method on more than one EJB component was called before and after.

To avoid repetitive low-level calls, many EJB applications use the service locator (services Locator) and the business delegate (bussiness Delegate) mode, which is better than doing a jndi lookup everywhere in client code, But there are obvious flaws in their common implementations. For example:

In general, it is difficult to test your code if you rely on a service locator or a business agent single piece to use EJBs.

In cases where only the service locator mode is used instead of the business delegate pattern, the application code still needs to invoke the Create method of the EJB home component or to handle the exception that was introduced. Causes the code to still retain the coupling with the EJB API and the complexity of the EJB programming model.

Implementing a business delegate pattern usually leads to a lot of redundant code because we have to write many methods, and all they do is invoke the same method as the EJB component.

The approach that spring takes is to allow the creation and use of proxy objects, typically in spring's ApplicationContext or beanfactory, which, like business proxies, require only a small amount of code. We no longer need to write additional service locator or Jndi lookup code, or redundant methods within handwritten business delegate objects, unless they can bring substantial benefits.

Accessing a local stateless session Bean (SLSB)

Suppose you have a Web controller that needs to use a local EJB component. We followed the previous practice and used the EJB's Business Method interface (Business Methods Interface) mode so that the local interface of the EJB component extends the non-EJB-specific business method interface. Let's assume that this business method interface is called MyComponent.

Public interface MyComponent {

...

}