leading:
- EJB is the abbreviation of Enterprise Java Beans technology, also known as Enterprise Java Beans.
- The birth of EJB technology marks the official expansion of the operation of Java Beans from the client field to the server field
1. We can't help but ask, what is a "service cluster"? What is "Enterprise Development"?
Now that it is said that EJB is for "service cluster" and "enterprise-level development", then we have to talk about what the so-called "service
cluster" and "enterprise-level development" are!
This question is actually quite critical, because J2EE does not explain it clearly, and there is no specific index or example to tell
programmers when to use EJB and when not to use it. So everyone has some associations, thinking that EJB "distributed computing
" refers to "load balancing" to improve the operating efficiency of the system. However, it is estimated that many people have made a mistake. This "service cluster"
and "distributed computing" have not fundamentally solved the problem of running load, especially for database application systems.
Why?
Let's first return EJB to its original form for everyone to analyze slowly.
2. Break the EJB apart and crush it
Let's analyze the concept of EJB and see what clues we can find.
2.1 Anatomy of the 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 flow of the entire business process and
implements them using computer language.
...
J2EE's approach to this problem is to extract the business logic from the client software and encapsulate it in a component
. This component runs on an independent server, and the client software invokes the services provided by the component through the network to implement
business logic, while the function of the client software is so simple that it is only responsible for sending call requests and displaying processing results. In J2EE,
the component that runs on an independent server and encapsulates business logic is the EJB (Enterprise Java
Bean) component.
Among them, we mainly focus on the following points, let's analyze them one by one:
- Analysis 1: The so-called "business logic"
We noticed that the encapsulation of "business logic" is mainly mentioned in the concept of EJB, and what is this business logic
? It is so suspenseful, but in fact, this so-called "business logic" can be understood as a "class
" that performs specific tasks.
- Analysis 2: The so-called: "Extract the business logic from the client software and encapsulate it in a component... to run on a server"
Now that we know that the concept of "business logic" is a "class" that performs a specific task, what is "
extracted from client software"? In fact, this is to take the "class" that was originally placed on the client, take it out and not put it on the client, put it
into a component, and put this component on a server to run.
2.2 Turn the concept of EJB into vernacular
In the vernacular, it means, "put the classes in the software you write that need to perform the specified tasks not on the client software
, but pack them into a package and put them on a server."
2.3 Found a problem
Whether it is said in "eight-legged essays" or in plain language, this EJB concept has mentioned a word-"client software".
"client software"? Could it be that the concept of EJB refers to C/S software?
Yes, that's right!
EJB is to put those "classes" on a server, and use the software client in the form of C/S to call the "classes" on the server
.
It's about to collapse!
What is the relationship between EJB and JSP? EJB and JSP are related, but the relationship is really not very big. At most,
the EJB class on the remote service is called on the server side of the JSP, and nothing more.
3.1 What is the bottom layer of EJB
We uncovered the true meaning of EJB "stereotyped" concept, then, let's analyze the underlying implementation technology of EJB, and
analyze the working mode of EJB through the underlying implementation technology.
3.2 Implementation technology of EJB
EJB is a component running on an independent server, and the client calls the EJB object through the network. In Java
, the technology that can realize remote object invocation is RMI, and the basis of EJB technology is RMI. Through RMI technology, J2EE
creates EJB components as remote objects, and clients can call EJB objects through the network.
3.3 See what RMI is
Before talking about RMI, you need to understand two terms:
serialization of objects,
distributed computing and RPC
- Noun 1: Serialization of objects
Object serialization concept: The object serialization process is to convert the object state into a byte stream and restore the object from the byte stream
. After converting the object state to a byte stream, you can save it to a file using the various byte stream classes in the java.io package,
or send the object data to another host over a network connection.
The above statement is a bit "stereotyped", we might as well explain it in vernacular: the serialization of objects is to
instantiate , for example, you customize a class MyClass, or any class of objects , convert it into
a byte array, that is to say, it can be placed in a byte array. At this time, since you have put an object in a byte array
, you can of course dispose of it casually. The most used It is to send him to a remote computer on the network
. As shown in Figure 211.
- Noun 2: Distributed Computing and RPC
RPC is not a pure Java concept, because the concept of RPC existed before the birth of Java. RPC
is the abbreviation of "Remote Procedure Call", that is, "remote procedure call". Most programming languages before Java
, such as Fortran, C, COBOL, etc., were procedural rather than object-oriented.
So, it is natural for these programming languages to use procedures to represent work, such as functions or subroutines, to be executed on another machine on the network. To put it
bluntly, the local computer calls a function on the remote computer.
As shown in Figure 212.
- Noun 3: The combination of the two is RMI
The full name of RMI in English is "Remote Method Invocation", and its Chinese name is "remote method invocation"
.
To put it more clearly, it is to use object serialization to realize remote calls, which is a combination of the above two concepts
. It is very convenient to perform serialization
operations and call them directly.
Remote method call is a mechanism for objects between computers to call each other's functions and start each other's processes. Using
this when an object on one computer calls a method on another computer, the program syntax used The rules are
the same as the syntax rules for method calls between objects on the local machine.
As shown in Figure 213.
3.4 Advantages
This mechanism brings great convenience to the system design and programming of distributed computing. As long as the program is designed according to the RMI rules
, you don't need to ask about the network details under RMI, such as: TCP and Socket and so on.
Communication between any two computers is entirely the responsibility of RMI. Objects on remote computers can be invoked just as easily as local objects.
RMI can pass complete objects as parameters and return values, not just predefined data types. That
is, complex types like Java hash tables can be passed as a parameter.
3.5 Disadvantages
If it is a relatively simple method call, its execution efficiency may be much slower than that of local execution, even compared with the
simple data return application of the remote Socket mechanism, it will be slower, because the information that needs to be transmitted between the networks is not only Only
the return value information of the function is included, and the serialized byte content of the object is also included.
3.6 EJB is based on RMI
Through RMI technology, J2EE creates EJB components as remote objects. Although EJB uses RMI technology, it only needs to
define remote interfaces without generating their implementation classes, which shields some details of RMI technology.
But in any case, the basis of EJB is still RMI, so if you want to understand the principle of EJB, you only need to understand the
principle of RMI. You also figure out when to use EJB and when not to use EJB.
4. So-called "service clustering" in EJB
Now that we already know, RMI puts various tasks and functional classes on different servers, and then realizes distributed computing through the call rules established between each
server , and understands the so-called "service cluster" of EJB. concept.
It is to put several classes that were originally calculated on one computer to run on other computers, so as to share the
CPU and memory resources required to run these classes. At the same time, different software function modules can also be placed on different
servers. When some functions need to be modified, it is enough to directly modify the classes on these servers. After the modification, all client
software has been modified. As shown in Figure 214.
5. Is this deployment invulnerable?
The "service cluster" shown in Figure 2.14 seems to be "impeccable", but the picture is not complete. Let's complete the picture
and see if there are any problems.
5.1 The bottleneck is on the database side
After careful observation, it is found that this configuration has a bottleneck, as shown in Figure 2-15.
Let's take a look at the structure diagram in Figure 2.15. Now if you want to realize the query of each server against the same database, then
no matter how many functional servers you deploy, you need to perform query operations against one database server. In other words,
no matter how "distributed" your "computing" is, you also need to get data from a server. Although it seems that the various functional
modules are distributed on different servers to share the CPU resources of each main computer, however, the real bottleneck is not
here, but the database server. The database server will be very busy to cope with the queries and operation
requests of each server.
Therefore, through this structural diagram, we understand that EJB cannot completely solve the load problem, because the bottleneck
is not where the functional modules are located, but the database server.
5.2 What to do if the database is separated and data sharing
Some readers will definitely think of the following application structure, as shown in Figure 216.
It is to deploy a database behind each functional server. Doesn't this solve the problem mentioned in the previous section
? Yes, the problem of database query load has been solved, but new problems have arisen, that is, the problem of "data sharing" is
not easy to solve.
5.3 The network is under great pressure, making your application slow
Let's look forward and see that there are two networks in this architecture as shown in Figure 2.15, one is "A network" and the other is "B
network". These two networks are different. "B network" is often a local area network, the general bandwidth is 10M/100M, and the speed is relatively fast, so it is
okay to say, however, "A network" is often the Internet or a telecommunication network interconnected VPN network or a wide area network. The characteristic of "A network"
is that the bandwidth is generally narrow. For example, the ADSL network only has a bandwidth of 512K-2M. Due to the high cost of WAN interconnection
, it generally does not have a high bandwidth.
And what runs on this network is the data exchanged between the functional modules and the client software, and this part of the data just
takes up a lot of bandwidth.
Therefore, the running speed of this application architecture can be imagined how slow it is. It is not an exaggeration to say that it is as
slow as an old cow pulling a broken cart.
A system as old as an old cow:
At present, a large company in the Internet of China is engaged in the network management system of operators, and one of its early network management software is a
C/S structure application system based on this architecture.
Once, as an evaluator, I evaluated its application system and deployed it in a large-scale non-operator network. The
situation we described above appeared, and the speed was unbearable. Opening a traffic The picture
sometimes takes 15 minutes to render completely. However, the system did not find this problem during the development phase,
why? Because they did not take into account the complexity of connecting the actual users of the application to the network, which caused great
losses to the company, so that this development framework was eventually abandoned.
6. EJB learning and utilization, J2EE does not have to use EJB
Through the explanations in the above sections, it seems that the relationship between EJB and the B/S structure of developing Web applications is not great, but it is actually
not the case. If we understand the "client program" as a certain server, this can also be applied. Moreover,
if the servers make EJB calls between each other, there will be no problem of wide area network bandwidth restrictions.
However, try not to use EJB in the following situations:
1. For relatively simple pure Web application development, EJB is not required. 2. Applications that need to be used in conjunction with other service programs, but the application programs that
can be resolved by calling or returning a custom network protocol do not need to use EJB. 3. Try not to use EJB for applications with a C/S structure that many people access concurrently.
Summarize:
- EJB implementation principle: It is to put the code originally implemented on the client side on the server side, and rely on RMI for communication.
- RMI implementation principle: It is to realize distributed computing through the serialization mechanism of Java objects.
- Server cluster: It is to connect servers of different functional modules through RMI communication to realize a complete function.