Contradiction between EJB components and reusability


EJB Technology is coming to a juncture like other brilliant technologies. Before 2000, this technology was full of legend and was accepted by a large number of enterprises without thinking. However, ideal is ideal after all. After several years of development, today this technology is being doubted or at least hesitated by technicians. The reality is that J2EE rivals have come out Net seems to have the technical advantage of late development. Most of the discussion and debate have begun to turn to the comparison of the two architectures. There are also skeptical voices within the Java camp. The most direct is the attack on EJB, because people find that the promises made by this technology seem to be moving in the opposite direction

1. A large number of cases have made the system development more and more complex due to the adoption of this technology, rather than simplifying the development cycle as imagined. It has become commonplace to increase the development cycle. It is difficult for many people to realize a purchase, sales and inventory.

2. EJB has become synonymous with expensive, rather than the expected cost reduction

3. It’s better to use message passing for system interoperability

4. Finally, it is found that it is impossible to get rid of the platform completely

But Java is still good, so there are n systems such as spring. EJB began to confuse people. Any technology, like life, has its confusion period, but the confusion caused by EJB is particularly classic and more meaningful. The comparison between J2EE and other systems has spread on the Internet, and the practical application experience can be seen everywhere, so that it does not need to be introduced here. However, EJB has not been paid attention to alone, which should be noted, which is contrary to the development history of J2EE. It must be acknowledged that EJB was proposed and defined separately, and was originally a completely separate specification, which has no direct relationship with the so-called architecture. In other words, the significance and goal of EJB is not just to encapsulate business logic in J2EE, so it is too much to discuss EJB within the framework, In other words, it is worth exploring whether it is appropriate to think that the weakness of J2EE must spread to EJB.

The excitement of people at the beginning of EJB was that the model absorbed the essence of the previous component technology and made great progress, so that people could see the expectation of strong commercial component manufacturing cost reduction, especially the assemblability and transplantability across the platform. Because this means that the industrialization and detailed division of labor of enterprise computing programming may become possible. At present, this idea also affects the application at the interface level, such as the so-called portlet technology. The technology of IBM’s WebSphere platform may not be terrible, but dozens of partners actually provide similar cooperation to it, which really scares the opponent. Therefore, when we talk about EJB, we talk about its value and role. If we are divorced from its design goal, we will lose greater significance. The following business environment and software technology bottlenecks should be re examined:

1. In terms of reuse, has software engineering gone beyond the era of components, or does it no longer need components?

2. Does the reuse of software only need to be mutually transferred without repeated assembly, or even assembled to different parts?

3. Does business logic still need to be encapsulated, maintain robust features and serve continuously

4. Are components and robustness and availability replaced by interconnect specific performance?

5. Is there a cheaper component form that surpasses EJB and is also supported by many?

  6. . Is the component standard of. Net comparable to EJB, or what component form is comparable to EJB?

When you think calmly, you know that technology should not be touted as a star, but there is no software technology that is easy to fall down. EJB is immature, but it does not mean that it can be easily denied. It is EJB that enables many ordinary programmers to intervene in the original noble component development, or even develop components on UNIX on simple windows. Most of the historical problems of EJB lie in the misuse of this technology: a poor advertising browser with few visitors also uses components, For a customer who only wants to calculate the inventory simply, the scalability required after n years is designed. Similarly, in reality, in the field where this technology is good at, at least for now, we can’t find a stronger competitor. Technology selection is the eternal theme of application-oriented technicians. Similar puzzles will continue to appear. The most important thing is to identify with their ideals and goals and maintain an objective and clear understanding of them. Technology in the field of expertise is the most beautiful, which is no different from life.