The history of EJB development

The development history of 8.1.2 EJB

For the controversial yet legendary technology of EJB, we will once again look back on it from the glorious appearances, experience the dismal decline, until today again brilliant development cycle.

(1) EJB 1.0

The initial EJB 1.0 was released about 1998, with the initial specification containing only stateful and stateless server objects (later collectively known as stateful session beans and stateless session beans), and optional persisted domain objects (later called entity Beans), EJB 1.0 has provided a good distributed support function: It allows remote invocation of the business method in the EJB through remote interfaces.

The EJB 1.0 specification attempts to simplify the remote access programming of RMI, but the EJB 1.0 specification introduces a new chore, and it is even more difficult to develop an EJB than to use RMI directly. However, the remote access support for EJB 1.0 attracted a large number of vendors and immediately became the biggest hot technology of its time.

But EJB1.0 also has a less-than-considered place, which prematurely estimates that the network is the computer, forcing the client component to call the EJB in a remote way, and for some systems that do not require remote access support, the remote access support for EJB 1.0 becomes a nuisance: it increases the overhead of the system, Affect performance.

(2) EJB 1.1

The difference between EJB 1.1 and EJB 1.0 is that EJB1.1 formally supports entity beans, and entity beans become one of the EJB core specifications, and entity beans are a persistent solution that the Sun company has placed great hopes on, as well as an important reason for EJB's notoriety. In addition, EJB 1.1 introduces a deployment description file in XML format that uses an XML configuration file to manage EJB deployment information in a declarative manner.

When EJB introduces XML configuration file is probably the most beautiful when XML, a lot of technical implementation, the framework is intended to use XML as a configuration file, the "hard-coded" way of writing in the program code of the information extracted into the XML configuration file becomes a trend. Later, annotation appeared, and most of the technology and framework abandoned the XML configuration file, instead using annotation to manage configuration information.

(3) EJB 2.0

EJB 2.0 addresses the overhead and performance degradation of forced remote access support in EJB 1.0, and the EJB 2.0 specification introduces the concept of a local interface that allows developers to decide for themselves whether or not to allow the EJB component to support remote access, if the EJB component does not need to support remote access. Having the Bean implementation class implement the local interface avoids the overhead and performance degradation that remote access support can bring.

EJB 2.0 enhances the functionality of the entity bean, which provides container management relationship (CMR) support for CMP (container-managed persistence) EJBS, allowing developers to manage the association between EJBS through configuration files. It also introduces the EJB query language: EJB-QL,EJB-QL formally provides query support for entity beans. Unfortunately, EJB-QL does not seem to be as powerful as native SQL, and often creates some sort of constraint on developers.

Another highlight of the EJB 2.0 specification is the message-driven bean (MDB), which is essentially the same as a stateless session bean. It just doesn't need a remote interface, so it can't be called by the client. However, the client component can trigger the MDB's OnMessage method by sending a message to the message destination.

(4) EJB 2.1

EJB 2.1 Adds Web service support, and the addition of Web service-enabled EJBS facilitates the integration of heterogeneous systems. Furthermore, EJB 2.1 adds a timer service that allows you to invoke the EJB's business method at a specified time or at a fixed interval, and the timer service can easily provide support for task scheduling for the system.

In addition, EJB 2.1 enhances the functionality of the EJB-QL, providing more robust query support. While EJB 2.1 is trying to improve the EJB-QL query function, everyone's scolding for EJB 2 masks Sun's efforts on EJB-QL.

(5) EJB 3.0

EJB 3 completely discards the design of the EJB 2 entity bean, preserving only the original session bean and message-driven bean, which embodies the great courage of EJB 3 's self-innovation. EJB 3 introduces a new JPA specification as a persistent solution-perhaps this is problematic because JPA is defined as a standalone persistence API that is no longer even part of the EJB 3 specification.

EJB 3 simplifies the development of Sessionbean in EJB 2 again, the Session bean no longer needs the home interface, and the EJB 3 specification only requires a remote or local business interface. and EJB 3 no longer recommends using an XML file as a deployment profile, but instead uses annotation to set deployment description information, further simplifying the development of EJB components.

In summary, EJB 3.0 is one of the most important versions of EJB history, and EJB 3.0 brings the classic Java EE technology back into the mainstream, allowing more and more people to choose Java EE with EJB 3 as the core to develop enterprise applications.

(6) EJB 3.1

The EJB 3.1 specification was published as part of the Java EE 6 specification When I was writing a book. Since the EJB 3.1 specification was recently released, it is not uncommon to support EJB 3.1 application servers, but EJB 3.1 claims to further simplify the development of EJB 3.0, for example, EJB 3.1 allows enterprise beans to provide only one bean class, even without the need to provide a business interface ; Allows you to invoke the business method of the session bean asynchronously, simplifying the restriction that the EJB class file must be packaged into a jar file, allowing the EJB class to be placed directly into the war file.

It is believed that the application server vendors will soon launch a server that supports the EJB 3.1 specification, and EJB 3.1 will be more popular than EJB 3.0.

Now the Java EE Application Architecture has formed two mainstream technical architectures: one is EJB as the core, the front-end JSF is the MVC framework of the technical architecture, this technology architecture is the official Java EE technology advocated by Sun, the other is based on the spring+hibernate as the core, With struts 1 or struts 2, the front-end is the technical architecture of the MVC framework, which is dominated by the mainstream open source framework. I refer to the former as the classic Java EE, the latter is called Lightweight Java EE.