POJO application architecture: Comparison between Spring and ejbs 3.0

Einstein once said: "Everything should be as simple as possible, rather than simpler ". Indeed, the pursuit of scientific truth is to simplify the fundamental assumptions of the theory so that we can deal with truly troublesome problems. The same is true for enterprise-level software development.
The key to simplifying enterprise-level software development is to provide an application framework that hides complexity (such as transactions, security, and Yonhap. A well-designed framework component can improve the code reuse capability, improve development efficiency, and thus improve the software quality. However, currently, the EJB 1.4 framework component in J2EE 2.1 is generally considered to be poorly designed and overly complex. Java developers are very dissatisfied with EJB 2.1. They have tried a variety of other methods for sending middleware services. The following two framework components have aroused great interest and positive reflection from developers. They are likely to become framework components available for enterprise-level Java applications in the future.

· Spring framework components are popular but non-standard open source framework components. It is mainly developed and controlled by Interface21 Inc. The architecture of Spring framework components is based on the dependency injection (DI) design pattern. Spring can work independently or with an existing application server. It uses a large number of XML configuration files.

· The EJB 3.0 framework component is a standard framework component defined by the Java Community Organization (JCP) and supported by all mainstream J2EE vendors. The open source code and commercial implementation of the pre-release EJB 3.0 specification can be seen on JBoss and Oracle. EJB 3.0 uses a large number of Java annotations ).

The core design philosophy of these two framework components is the same: both aim to pass the middleware service to a loosely coupled simple old-style Java object (POJO ). These framework components intercept execution content at runtime or inject service objects to POJO to bundle application services with POJO. POJO itself does not care about the bundling process and has little dependency on framework components. As a result, developers can focus on business logic, and individuals can test their POJO without framework components. In addition, since POJO does not need to inherit from or implement the framework component interface from the framework components, developers have a high degree of flexibility in establishing the inheritance structure and building applications.

However, although the two have the same design philosophy, they adopt a completely different approach when delivering POJO services. Although a large number of books and articles have been published to compare Spring or EJB 3.0 with EJB 2.1, they have not carefully studied the differences between Spring and EJB 3.0. In this article, I will study the key differences between the Spring and EJB 3.0 framework components and discuss their advantages and disadvantages. The topic of this Article can also be applied to other well-known enterprise-level middleware framework components, because they all focus on the "loosely coupled POJO" design. I hope this article will help you select the best framework components that meet your needs.
Independence)

One of the most important reasons for developers to choose a Java platform is that the vendor independence of the platform. EJB 3.0 is an open, standard, and vendor-independent platform. The EJB 3.0 specification is developed and supported by all mainstream open source code and commercial vendors in the Enterprise Java Community. The EJB 3.0 framework component isolates developers from the application server implementation (implementation. For example, although JBoss's EJB 3.0 implementation is based on Hibernate and Oracle's EJB 3.0 implementation is based on TopLink, developers do not need to learn the special APIs of Hibernate or TopLink, they can run their applications on JBoss and Oracle. Vendor independence separates EJB 3.0 framework components from other POJO middleware framework components.

However, many critics of EJB 3.0 quickly pointed out that at the time of writing this article, the EJB 3.0 specification had not reached the final version. It may take one to two years before EJB 3.0 is adopted by all mainstream J2EE vendors. However, even if your application server does not naturally support EJB 3.0 (natively), you can download and install an "embedded" EJB 3.0 product, run the EJB 3.0 Application on the server. For example, the JBoss embedded EJB 3.0 product is open-source and can run in any J2SE-5.0-compatible environment (for example, in a Java application server. It is currently in beta testing. Other vendors may soon release their embedded EJB 3.0 products, especially for the standardized "Data forever" section.

On the other hand, Spring has always been a non-standard technology and remains like this for the foreseeable future. Although you can use Spring framework components with any application server, however, all Spring applications are "locked" in the specific services that Spring itself and you choose to integrate into Spring.

· Although the Spring framework component is an open-source project, it still owns the patented XML format and patented programming interface of the configuration file. Of course, such "locks" occur on any non-standard product, and Spring is no exception. But it does: the long-term viability of your Spring application depends on the Spring project itself (or Interface21 Inc, which employs most Spring core openers ). In addition, if you use any Spring-specific services, such as Spring Transaction Manager or Spring MVC, you will be "locked" in these Apis.

· Spring applications need to know the backend service provider. For example, for the data persistence service, the Spring framework components JDBC, Hibernate, iBatis, and JDO use different DAO and template helper classes. Therefore, if you want to replace a continuous service provider for a Spring application (for example, switching from JDBC to Hibernate), you must refactor your application code and use the new helper class.

　　Service integration

At a higher level, the Spring framework component is located on the application server and service library. Its service integration code (such as data access templates and helper classes) is located in the framework components and exposed to application developers. In contrast, the EJB 3.0 framework component is tightly integrated into the application server, and the service integration code is encapsulated in the standard interface.

As a result, the EJB 3.0 vendor can actively optimize the overall performance and developer experience. For example, in JBoss's EJB 3.0 implementation, when EntityManager is used to maintain the BeanPOJO object, the lower-layer Hibernate conversation transaction is automatically associated with the JTA transaction of the method called, when a JTA transaction is committed, it will also commit. If you use simple @ PersistenceContext annotations (an example is provided later in this article), you can even use stateful) in the dialog bean, The EntityManager and its underlying Hibernate transaction are bundled into an application transaction. This application transaction spans multiple threads in a dialog, which is very effective in transactional Web applications (such as multi-page shopping cart. In JBoss, The EJB 3.0 framework component, Hibernate, and Tomcat are tightly integrated, so that the preceding simple and integrated programming interfaces can be implemented. The EJB 3.0 framework Component of Oracle and its underlying Toplink continuous service also implement integration at a similar level.

Another example of the integration service in EJB 3.0 is cluster support. If you deploy an EJB 3.0 Application in the server cluster, all the Failed Connections (fail-over) server Load balancer, distributed cache, and status replication can be automatically used by applications. The underlying cluster services are hidden behind the EJB 3.0 programming interface, which is completely transparent to EJB 3.0 developers.

In Spring, it is much more difficult to optimize the interaction between framework components and services. For example, to use Spring's declarative Transaction Service to manage Hibernate transactions, you must explicitly configure Spring TransactionManager and Hibernate SessionFactory objects in the XML configuration file. Spring application developers must explicitly manage transactions that span multiple HTTP requests. In addition, there is no easy way to use the cluster service in Spring applications.

　　Flexibility of service integration

Since the service integration code in Spring is exposed as part of the programming interface, application developers can flexibly integrate services as needed. This feature allows you to integrate your own "lightweight" application server. Spring is most commonly used to "Bond" Tomcat and Hibernate together to provide simple database-driven web applications. In this case, Spring itself provides the transaction service, and Hibernate provides the persistence service-this organization creates a micro application server in Spring.

The EJB 3.0 Application server does not give you the flexibility to select Services. In most cases, you get a set of prepackaged features, and you only need some of them. However, if an application server is dominated by a modeled internal design (similar to a JBoss), you may separate it to remove unnecessary features. It is not easy to customize mature application servers under any circumstances.

Of course, if the application is beyond a single node, you may need to bind services (such as resource buffer pools, message queues, and clusters) from common application servers ). In terms of overall resource consumption, the Spring solution is "Heavyweight" like any EJB 3.0 solution.

In Spring, flexible service integration makes it easier to bind a mock object instead of an actual service object to an application for unit testing outside the container. In EJB 3.0 applications, most components are simple POJO and we can easily test them outside the container. However, for testing objects that involve Container service (such as continuous EntityManager), we recommend testing in containers because they are simpler, more robust, and more accurate than the method for copying objects. Comparison Between XML and annotations
From the perspective of application developers, Spring programming interfaces are mainly based on XML configuration files, while Java annotations are widely used in EJB 3.0. XML files can express complex relationships, but they are also lengthy and weak. Annotations are simple and clear, but it is difficult to express complicated or hierarchical structures in annotations.

Spring and EJB 3.0's selection of XML or annotations depends on the architecture behind these two framework components: Because annotations can only save a small amount of configuration information, comments can be used as configuration options extensively only for pre-integrated framework components (similar to most preparations have been completed in framework components. We have discussed that EJB 3.0 meets this requirement, and Spring, as a general DI framework component, does not meet this requirement.

Of course, both EJB 3.0 and Spring are learning the best features of each other, and both support XML and annotation to some extent. For example, in EJB 3.0, the XML configuration file is an optional overload mechanism that can be used to change the default behavior of annotations. Annotations can also be used to configure a certain deployment pring service.

The best way to understand the differences between XML and annotations is through examples. In the next section, we will see how Spring and EJB 3.0 provide key services for applications.
Declarative Service(Declarative Services)

Both Spring and EJB 3.0 bind runtime services (such as transactions, security, logging, messages, and custom services) to applications. Because these services are not directly associated with the application's business logic, they cannot help the application itself