The EJB of historical mystery

In the process of learning the sping framework, I have seen many criticisms of EJB. Use SPRINGMVC but did not really feel the merits of it, so it is necessary to the traditional Java beans and EJB to do some understanding, but Baidu search a lot of knowledge, or understanding is very abstract, and did not instantiate the idea in the brain. So it is necessary to explore the history of EJBS, so there is this article.

EJB is an enterprise Java bean with the word name. Every word has its karma to take the name, so it is the first name to say. EJB official explains this: The core part of business software is its business logic. Business logic abstracts the process of the entire business process and uses the computer language to implement them. The approach of Java EE to this problem is to extract the business logic from the client software and encapsulate it in a component. This component runs on a separate server, where the client software invokes the service provided by the component through the network to implement the business logic, and the client software functions simply to send the call request and display the processing results. In the Java EE, this component, which runs on a separate server and encapsulates the business logic, is the EJB (Enterprise JavaBean) component.

Here we focus on a few points, we have to analyze each: the so-called "business logic", we note that the concept of EJB is mainly referred to as the "business logic" of the package, and what is the business logic in the end? Say so poised, in fact this so-called "business logic" we can fully understand to perform a specific task "class
"。 So-called: "Extracting business logic from client software, encapsulating it in components, running on a server", since we know that the concept of "business logic" is the "class" that performs a particular task, what is called "extracting from the client software"? In fact, this is the original put on the client's "class", take it out to the client, put in a component, and put this component on a server to run.　　

so, in one sentence, the EJB is: "You write the software that needs to perform the task of the class, not put on the client software, but to the package he put into a server." EJB is to put those "classes" on a server, in the form of C/S software client to the server "class" into the row calls.

Analyze the EJB implementation technique: EJB is a component running on a stand-alone server, and the client calls the EJB object over the network. In Java, the technology that enables remote object invocation is RMI, and EJB technology is based on RMI. With RMI technology, Java EE creates the EJB component as a remote object, and the client can invoke the EJB object over the network.
What is RMI? Before you understand it, you need to understand two abstract concepts: Object serialization and distributed computing with RPC. First, the serialization of objects: the serialization of an object is the process of converting an object's state into a byte stream and recovering an object from a byte stream. After you convert the object state to a byte stream, you can either save it to a file with the various byte stream classes in the Java.io package, or send the object data to another host over a network connection. That is, the serialization of an object is the object of a class that instantiates your program, for example, if you customize a class MyClass, or any object of a class, convert it to a byte array, which means it can be placed in a byte array, when you have placed an object in a byte array , then of course you can dispose of it, the most used is to send him to the network on the remote computer. Distributed computing and RPC:RPC is not a purely Java concept, because the concept of RPC is already in existence before Java was born, and RPC is the abbreviation for "Remote Procedure call", which is called "remoting procedure calls". Most programming languages Prior to Java, such as Fortran, C, COBOL, and so on, are procedural languages, not object-oriented. So, these programming languages naturally use procedures to represent work, such as functions or subroutines, to be executed on another machine on the network. To be blunt, the local computer calls a function on the remote computer. The combination of the two is Rmi,rmi "remote method invocation", its Chinese name is a "long-distance methods call", it is the use of Java object serialization mechanism to implement distributed computing, the realization of remote class object instantiation and the method of invocation. More clearly, is the use of object serialization to achieve remote invocation, which is the combination of the above two concepts, the use of this method to invoke the remote class, there is no need to write the socket program, and do not need to serialize the object, the direct call on the line is very convenient. A remote method call is a mechanism by which objects between computers invoke each other's functions to initiate a process that uses the same program syntax rules as the syntax rules of a method call between objects on a local machine when an object on one computer calls a method on another computer.so, in one sentence, RMI implements another layer of encapsulation on serialization and distributed computing .。 Then the advantages and disadvantages of RMI: The advantage of this mechanism for distributed computing system design, programming has brought great convenience. As long as the program is designed according to the RMI rules, you can avoid having to ask about the network details under RMI, such as TCP and sockets, and so on. The communication between any two computers is solely the responsibility of RMI. Invoking objects on a remote computer is as convenient as a local object. RMI can pass complete objects as parameters and return values, not just predefined data types. In other words, a complex type such as a Java hash table can be passed as a parameter. Disadvantage: If it is a simpler method call, its execution might be much slower than local execution, even if it is slower than the application of the remote socket mechanism's simple data return, because the information it needs to pass across the network does not only contain the return value information of the function, Also contains the byte content after the object is serialized (and that's sacrificing efficiency.)。

EJB is based on RMI, through RMI technology, the EJB component is created as a remote object, EJB Although using RMI technology, but only need to define the remote interface without generating their implementation class, so that the RMI technology, some of the details of the problem is masked. But anyway, the basis of EJB is still RMI, so if you want to understand the principle of EJB, as long as the principle of RMI to clear the line. You can also figure out when to use EJBS and when not to use EJBS. The so-called service cluster in EJBS: RMI is to put a variety of tasks and functions of the classes on different servers, and then through the establishment of the call rules between the various servers to achieve distributed operations, but also understand the concept of EJB so-called "service Cluster". is to put a few classes that were originally operating on a computer and run it on another computer to share the CPU and memory resources that are required to run the classes. At the same time, the different software function modules can be placed on different servers, when the need to modify some features of the server directly modify the class on the line, the modification of all the client's software has been modified.

After careful observation, found that this configuration is a bottleneck, and now if you want to implement the individual servers for the same database query, no matter how many of the server you deploy, you need to target a database server query operations. In other words, no matter how "distributed" Your calculations are, you also need to get data from one server. Although it seems that the various functional modules are distributed across different servers to share the CPU resources of each host computer, the real bottleneck is not here, but the database server. The database server is very busy responding to queries and operational requests from individual servers. As a result, this structure allows us to understand that EJB does not completely solve the load problem because the bottleneck is not at the location of the function module, but here in the database server.

So instead of having a database on each of the functional servers after switching to the above structure, does that solve the problem in the previous section? Yes, it solves the problem of database query load, but there are new problems, that is, the problem of "data sharing" is not easy to solve. We find it seems that the system relationship between EJB and the B/s structure of the Web application is not very large. To summarize: the principle of EJB implementation: is to put the original client implementation of the code on the server side, and rely on RMI to communicate. RMI Implementation principle: It is through the Java object Serializable mechanism to achieve the distribution of computing. Server cluster: It is through RMI communication, connect the server of different function module, in order to realize a complete function.

The EJB of historical mystery