Something about ejb

I recently used ejb3 ea to review ejb2.1 spec. By the way, I also summarized my understanding of ejb:

Enterprise JavaBeans is an architecture for component-based computing.

The ejb specification clearly states that ejb is a component-based structure, that is, something of component architecture. Then its basic starting point is the SoC of technical and business problems, only with this understanding can we talk about the importance of ejb and the reuse of ejb. There was once a well-known dx in China who told me: "Both COM and EJB advocate modularization and reuse. modularization is true, and reuse is a lie." At that time, I became cold, I admit that ejb is not easy to reuse, but if it is a lie, I guess this dx didn't notice ejb's component architecture, nothing in the component architecture can be removed from the container for reuse, because there is a convention between the component and the container, which part belongs to the container and which part belongs to the component are described in advance, such as transaction, if the container supports this, component does not write the transaction code, but uses the annotation declaration in deploy. Otherwise, it must be written. In ejb, ejb container undertakes a lot of technical support, such as scheduling, cache, transaction, etc, the reason why ejb is not easy to reuse is that it is only necessary to provide sufficient technical context for business establishment to reuse. The component structure ensures that component is reused in an equivalent technical environment. Therefore, ejb can only be reused between ejb contianer or provide an equivalent technical environment. ejb reuse is not a lie, you just need to have a correct understanding.

Enterprise beans are components of transaction-oriented enterprise applications.

This sentence was noticed at the time of reading this article. Then, just like the example above, I understood why ejb looks like this. Some of the criticisms against ejb are due to the fact that compared with jdo or hibernate, entity bean cannot provide complete oo modeling capabilities. This is indeed true, but it has already been mentioned in the specification, all ejbs are facing the transaction-oritented enterprise application, and there is no commitment to support oo modeling. Why? Because the underlying databases in large enterprise applications require additional tuning, dba may optimize tables with multiple concurrent accesses (for example, splitting tables based on possible data needs to reduce concurrency). In a real high-performance enterprise system, there is little chance or even no chance of a complete oo model. ejb emphasizes enterprise-oriented applications, so it is also right to support only transaction-oriented enterprise applications. As for the simple community, the only reason is that the systems they need are not so complex and there is not such an enterprise, so the ejb tailored for the enterprise obviously does not apply. Sun once said that for most people that do not use ejbs, this is indeed true. Especially in China, maybe 90% of j2ee programmers do not use ejbs because the system is too small, not enough for enterprise.

After review ejb 2.1, compared to ejb3, ejb3 uses javaBean as the component model. Persistence supports oo modeling and other persistence methods, ejb3 has changed from enterprise java bean to enterprise-ready javabean. It may be better to change it to enhanced java bean.