EJB and without EJB

Since ancient times, there have been yundun for spears and evil for the positive and evil. The Chinese people say, "Everything in heaven and earth, Yin and Yang, and two poles." westerners say: "dialectical materialism ". In fact, the essence is the same, it means that everything has two sides.
I have read a little bit of EJB data before. From the immature ideas at the time, I think the distributed concept of EJB is quite good. It is also a practical method for actual work, such as in power supply, in large industries of China Telecom and banking, this architecture is used to separate the business layer from the Web server layer, and the business layer is all placed in the EJB layer. This is because of the security and the large changes in the business layer, it is placed here for processing, the same is true for computing, database operations, and so on. This is what I personally think of as the best EJB. Later I heard from the Internet that rod Johnson, the famous developer, wrote a new book J2EE. development. without. EJB. To be honest, the author's title is very good. It's a big stunt. It's curious, including me. At that time, I couldn't imagine how to. I couldn't imagine such a good framework without having to have a better framework. I spent some time looking at the author's "light" container spring.
After reading this, I found that my previous ideas are fundamentally wrong. In fact, the "light" container does not fundamentally subvert the distributed concept, because distributed architecture is a good framework at the present stage, spring is actually just changing EJB to optimize it from some places, so as I said. in fact, EJB is actually a gimmick in it.
The important distributed concepts and frameworks of ejbs are not replaced. Spring should replace the operating mechanism of ejbs. Instead of interface connection, spring should improve the control, not the application.Program Control, while external Code Control, this is the control inversion. Later, this is called dependency injection. "At runtime (system boot, USB device loading), the container (running in Windows operating system) inject dependencies (laptops rely on USB devices for data access) into components (Windows File Access Components )." From the perspective of concept, it seems a bit empty. In fact, the difference is that the calling mechanism of the program is above. The "light" and "heavy" points are not in the fundamental structure, and the fundamental thinking is above, the difference is only in simplicity and convenience. One is to dynamically load the program from the configuration file, and the other is to find and call the Session Bean through two interfaces. This can also be seen from the first chapter of the book J2EE. development. Without. EJB. In the first chapter, Rod Johnson lists various types of ejbs (excerpt is as follows ):
Since the formation of the EJB specification, many things have changed:
1. Some of the EJB specifications are outdated.
2. The traditional closeness between ejbs and RMI began to seem a bit inappropriate.
3. EJB is best at implementing the architecture of Business Object distribution. However, to what extent is the universality of this architecture, it seems quite doubtful now. (Note that I am skeptical that the original article is "has proved problematic ").
4. The advantages and disadvantages of EJB can also be used by people. Most developers and architects only use stateless Session Bean (slsb) and (if asynchronous call is required) Message-driven Bean (MDB ).
5. Although EJB has been in existence for five years and has been applied in many J2EE projects, it is clear that many developers still do not really understand it due to its complexity.
6. To solve the problem of EJB, The EJB specification is becoming increasingly complex.
7. EJB is so complex that it means that the development efficiency of using EJB is relatively low.
8. Strict unit testing and test-driven development (TDD) are becoming increasingly popular-that is also reasonable.
9. aspect Oriented Programming, AOP) the rapid development gives us a more powerful and likely simpler solution.
10. In most cases, Source code Metadata attributes (as used in. Net) can replace the XML-based deployment descriptor very elegantly-since ejb1.1, we have been dealing with these complex XML files.
Based on our experience, the failure of EJB mainly includes the following points:
1. EJB is not necessary to reduce complexity, but introduces a lot of new complexity.
2. As a persistence mechanism, Entity Bean's attempt completely fails.
3. Compared with other J2EE technologies (such as servlet), applications using EJB lack portability between different application servers.
4. Despite the commitment of EJB to improve high scalability, the performance of the EJB system is often unsatisfactory, and EJB is not necessary to achieve scalability.
5. EJB may make simple things difficult.
The above is only an excerpt from the original article. In order not to misunderstand the meaning of the author, we recommend that you read the original article directly.
From the above, we can easily see that most of the problems and defects of EJB are explained. Therefore, the author invented the Spring framework to make up for the shortcomings of EJB, rather than simply abandoning it.
However, unfortunately, my current research on spring is only limited to studying the benefits of modifying the configuration file of spring to facilitate the calling of different class files, from this point of view, I personally think that it is not enough to stand against EJB, and other spring aspects need to do more research, I hope some friends will share their other research experiences in this area with me and let me know.