EJB Concept Understanding

Transfer from http://blog.csdn.net/jojo52013145/article/details/5783677

1. We cannot help but ask what is a "service cluster"? What is "enterprise-level development"? Since the EJB is meant for "service clusters" and "enterprise-level development", it is necessary to say what is called "Service Clusters" and "enterprise-level development". This question is actually very important, because the Java EE does not explain the white, there is no specific indicators or examples tell the vast numbers of programmers when to use EJB when not. So we all have some associations, that the EJB "distributed operation" refers to "load balancing" to improve the efficiency of the system. However, it is estimated that many people are mistaken that this "service cluster" and "distributed operation" do not solve the problem of running load at all, especially the application system for database. Why? Let's take the EJB back to the prototype and analyze it slowly.

2. Break the EJB and break it. We analyze the concept of EJB and see what clues we can find.

3.1 EJB concept let's look at it first. The official explanation of EJB: 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 Java Bean) component. Here we mainly focus on these points, we have to analyze each article: Anatomy 1: 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? So poised, in fact, this so-called "business logic" we can fully understand as the implementation of a specific task "class." Anatomy 2: The so-called: "Extract the business logic from the client software and encapsulate it in the component ... 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. 3.2 Turning the concept of EJB into plain English into plain English is, "the class of the software you write that needs to be executed is not put on the client software, but instead is placed on a server with a packet." 3.3 found the problem whether it's "stereotyped writing" or "plain English," The EJB concept mentions a word-"client software". "Client Software"? Does the concept of EJB say C/s software? Yes! EJB is to put those "classes" on a server, in the form of C/S software client to the "class" on the server call. It's going to crash! What is the relationship between EJB and JSP? EJB and JSP are related, but the relationship is not very big, at most on the server side of the JSP call the remote service EJB class, that's all.

4 . 1 What is the bottom of EJB? We uncover the true meaning of the EJB "stereotyped" concept, then analyze the EJB's underlying implementation technology to analyze the EJB's working mode through the underlying implementation technology.

The implementation technology of 4.2 EJB 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. 4.3 See what RMI is. Before you speak RMI, you need to understand two nouns: object serialization distributed computing and RPC noun 1: Serialization of object Serialization concept: Object serialization 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. The above is a bit "stereotyped", we might as well explain in the vernacular: Object serialization is the object of a class instantiated in your program, for example, you customize a class MyClass, or any class object, convert it into a byte array, that can be placed in a byte array, this time, Now that you have put an object in a byte array, you can certainly dispose of it, and the most used is to send him to a remote computer on the network. shown in 2 11.

Noun 2: Distributed computing and RPC RPC are not a purely Java concept, because the concept of RPC was already in existence before Java was born, and RPC was 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. Shown in 2 12.

Noun 3: The combination of the two is the RMI RMI English full name is "remote method invocation", it's Chinese names are "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. shown in 2 13.

4.4 Advantages This mechanism brings great convenience to the design and programming of the distributed computing system. 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 Java Hassi can be passed as a parameter. 4.5 Disadvantages If it is a simpler method invocation, its execution efficiency may 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 between the networks does not only contain the return value information of the function, It also contains the byte content after the object is serialized. 4.6 EJB is an RMI-based RMI technology, which creates EJB components as remote objects, while EJB uses RMI technology, but only needs to define remote interfaces without generating their implementation classes, which masks some of the details of RMI technology. 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 when you don't need ejbs.

5. Since the so-called "service Cluster" in EJBs has been known, RMI is to put various tasks and functions of the classes on different servers, and then through the call rules established 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. shown in 2 14.

6. Is this deployment watertight? The "service Cluster" as shown in Figure 2 14 is seemingly "invulnerable", in fact, it is not a complete picture, let's complete the picture and see what the problem is. 6.1 Bottlenecks after careful observation on the database side, it is found that there are bottlenecks in this configuration, as shown in 2 15.

Let's take a look at the structure of Figure 2 15, and now if you want to implement individual server queries for the same database, no matter how many feature servers you deploy, you need to do a query against a database server. 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. 6.2 If separate database, data sharing what to do some readers will think of the following application structure, 2 16 is shown.

is to put a database behind each of the feature servers, so it doesn't solve the problem mentioned 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. 6.3 Network under the pressure, so that your application as slow as the old cow let's go ahead and look at the 2 15 shows that there are two networks in this architecture, one is "a network" is a "B network", the two networks are different. "B Network" is often a local area network, the general bandwidth is 10m/100m, faster, so fortunately, however, "A network" is often the Internet or the use of telecommunications network interconnection VPN network or called WAN. "A network" is characterized by a narrow bandwidth, such as ADSL network only has 512k-2m bandwidth, because of the high cost of WAN interconnection, so there is generally no higher bandwidth. In this network is running the function module and the client software exchange between the data, and this part of the data is the advantage of very bandwidth-intensive. As a result, the application architecture can see how slow it is to run. To say a word is not exaggerated, a little bit like the old bull pull the same slow car. A system such as the old cow: at present in China's Internet operators network management system of a large company, its early management software is the use of this architecture to do the C/s structure of the application system. Once, as an evaluator, I evaluated the application system and deployed it to a non-carrier large network, the situation that we described above, the speed is unbearable, open a traffic map, sometimes it takes 15 minutes to render complete. However, the system did not find this problem in the development phase, why? Because they did not take into account the complexity of the actual user connection to the network, thus causing a large loss to the company, the development architecture was eventually abandoned.

7. EJB Ingenious, the Java EE does not have to use EJB through the above section of the explanation seems like EJB and the development of the Web application of the B/s structure of the system relationship is not big, in fact, it is not. If we understand the "client program" as a server, it can also be applied, and if the server makes EJB calls to each other, there is no problem of WAN bandwidth limitation. However, do not use EJBS as far as possible: 1, a relatively simple web-only application development, do not need to use EJB. 2. Applications that need to be used in conjunction with other service programs, but invoke or return custom network protocols that can be resolved by applications that do not require the use of EJBS. 3, more people concurrent access to the C/s structure of the application, try not to use EJB.

Summarize:

A.EJB implementation principle: is to put the original client implementation of the code on the server side, and rely on RMI to communicate.

B.rmi implementation principle: It is through the Java object Serializable mechanism to achieve the distribution of computing.

C. server cluster: It is through RMI communication, connect the server of different function module, in order to realize a complete function.

EJB Concept Understanding