Using the Spring AOP Framework and EJB components in Java EE

The rapidly evolving developer community, support for a variety of backend technologies (including JMS, JTA, JDO, Hibernate, Ibatis, and so on), and (more importantly) non-intrusive lightweight IOC containers and built-in AOP runtimes, these factors make spring The framework is very attractive for Java EE application development. Spring-Hosted components (POJO) can coexist with EJBS and allow AOP methods to be used to handle crosscutting aspects of enterprise applications-from monitoring and auditing, caching, and application-level security, until the application-specific business needs are addressed.

This article will introduce you to the practical application of Spring's AOP framework in the Java EE application.

Brief introduction

Java-EE technology provides a solid foundation for implementing server-side and middleware applications. The Java EE container, such as Bea WebLogic Server, can manage system-level elements, including application lifecycle, security, transaction, remote control, and concurrency, and it guarantees support for common services such as JDBC, JMS, and JTA. However, the size and complexity of Java EE makes development and testing extremely difficult. Traditional Java EE applications often rely heavily on services that are available through the jndi of the container. This means that a large number of direct jndi lookups are required or that the service locator mode is used, which is slightly improved. This architecture increases the coupling between components and makes it almost impossible to test a component individually. You can read the Java Development without EJB book written by the Spring Framework creator, which delves into the pitfalls of this architecture.

With the spring Framework, business logic implemented using unformatted Java objects can be connected to the traditional EE infrastructure, while significantly reducing the amount of code required to access the Java EE Components and services. Based on this, traditional OO design can be combined with orthogonal AOP components. Later in this article, we will demonstrate how to refactor the Java component to take advantage of a spring-hosted java-based object and then apply an AOP approach to implement new features to maintain good component independence and testability.

Spring provides a limited subset of the AOP functionality compared to other AOP tools. Its goal is to seamlessly integrate AOP implementations with the spring IOC container to help solve common application problems. This integration is done in a non-invasive manner, allowing a mixture of spring AOP and more expressive frameworks, including ASPECTJ, in the same application. Spring AOP uses the Unformatted Java class, does not require a special compilation process, controls class loader hierarchies, or changes deployment configurations, but instead uses proxy mode to apply notifications to target objects that should be hosted by the spring IOC container.

You can choose between two types of agents depending on the situation:

The first type of proxy is based on the Java dynamic Proxy and applies only to interfaces. It is a standard Java feature that delivers exceptional performance.

The second type of proxy can be used for scenarios where the target object does not implement any interfaces, and such interfaces cannot be introduced (for example, in the case of legacy code). It is based on run-time bytecode generation using the Cglib library.

For the object being represented, spring allows the use of static (method matching based on exact name or regular expression, or annotation driven) or dynamic (matching is at run time, including Cflow pointcut type) pointcut definition to assign a specific notification. Each pointcut can be associated with one or more notifications. There are several types of notification supported: Surround notification (around advice), front notification (before advice), notification after return (after returning advice), notification after an exception is thrown (after throwing advice), And the introduction of notifications (introduction advice). An example of a surround notification will be given later in this article. For more detailed information, refer to the Spring AOP framework documentation.

As mentioned earlier, only target objects that are hosted by the spring IOC container can be notified. However, in the Java EE application, the lifecycle of the component is hosted by the application server, and depending on the integration type, a common endpoint type can be used to expose the Java application component to remote or local clients:

Stateless, stateful, or entity bean, local or remote (based on RMI-IIOP)

Message-driven beans (MDB) listening for local or external JMS queues and themes or inbound JCA endpoints

Servlet (including struts or other end-user UI frameworks, XML-RPC, and soap-based interfaces)

Figure 1: Common endpoint types

To use spring's AOP framework on these endpoints, you must transfer all business logic to a spring-hosted bean, and then use a server-hosted component to delegate calls, or define transaction partitioning and security contexts. Although this article does not discuss transaction issues, you can find related articles in the Resources section.

I'll explain in detail how to refactor the Java EE application to use the spring feature. We will use the Xdoclet metadata to generate the home and bean interfaces, as well as the EJB deployment descriptor. You can find the source code for all the sample classes in this article in the downloads section below.