EJB's understanding

Reference Source: http://blog.csdn.NET/cymm_liu/article/details/7760989

1. Analysis of EJB concept Let's take a look at 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 JavaBean) component.

Here we mainly focus on these points, we have to analyze:

Anatomy 1: The so-called "business logic" we note that the main reference in the EJB concept is the encapsulation of "business logic", and what exactly is this 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, encapsulated 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.

Turning the concept of EJB into a plain English: plain English is, "the class of the software you write that needs to be executed is not put on the client software, but it is placed on a server." Discover 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.

2. 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 bottom-level implementation technology.

EJB Implementation technology: An EJB is a component that runs on a stand-alone server, and the client invokes 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.

See what RMI is: before you say 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, 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. :

Noun 2: Distributed computing and RPC
RPC is 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 of the programming language before Java, such as Fortran, C, COBOL, and so on, are procedural languages, not object-oriented. Therefore, these programming languages are naturally used to represent work, such as functions or subroutines, to be executed on another machine on the network. White, that is, the local computer calls a function on the remote computer.
is shown below:

rmi in English is "Remote Method invocation", its Chinese name is " Remote method call", it is more clearly, This method to invoke the remote class, there is no need to write the socket program, do not need to sequence the object The operation, 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, starting the other process, using this

Advantages: This mechanism brings great convenience to the design and programming of 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. 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, It also contains the byte content after the object is serialized.

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.

3. The so-called "service Cluster" in EJBs As already known, RMI is to put a variety of tasks and functions of the classes on different servers, and then through the call rules established among the various services to achieve distributed operations, but also understand the concept of EJB so-called "service cluster." is to put a number of classes that were originally on a computer and run it on a different computer to share the CPU and memory resources that are required for these classes of operations. At the same time, 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 software has been modified. is shown below:

Is this deployment impeccable ?
The "service cluster" shown on the diagram looks "invulnerable", in fact, it is not a picture of the complete, we come to complete the picture, and then to see what the problem is not.
Bottleneck on the database side !

Figure 2

After careful observation, found that this configuration is a bottleneck. We look at the structure diagram, now if you want to implement each server for the same database query, that No matter how many feature servers you deploy, you need to do a query against a database server. In other words, Here, instead, the database server there. The database server will be very busy to cope with the queries of each server and

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.

What if I separate the database and share data? Some readers will certainly think of this application structure below.

is to put a database behind each of the functional servers, so that it does not 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.

the network is under a lot of pressure to make your application slow as the old bull: 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-4m 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.

 

Span style= "font-size:14px" > 4, EJB ingenious, the Java EE is not required 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, 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 question of WAN bandwidth throttling. However, do not use EJBS as much as possible: 1, simple web-only application development , you do not need to use EJBS. 2, applications that need to be used in conjunction with other service programs, but a custom network protocol called or returned can address 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's understanding