What exactly is EJB, really so mysterious??

1. We cannot help but ask what is a "service cluster"? What is "enterprise-level development"?  
Since EJB is meant for "service clusters" and "enterprise-level development", it must be said that what is called "service
Cluster "and" Enterprise-level development "!
This question is actually very important, because there is no white in the Java EE, there is no specific indicators or examples to tell
When do the vast numbers of programmers use EJBS? So we all have some associations that the EJB "distributed operation
"Load balancing" increases the operational efficiency of the system. However, it is estimated that a lot of people are mistaken, this "service cluster"
and "distributed operations" 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 crush it .
Let's make a good analysis of the EJB concept and see what clues we can find.

3.1 EJB concept analysis
Let's take a look at the official explanation of EJB: The core part of the
Business software is its business logic. The business logic abstracts the process of the entire business process and implements them using the
computer-counting language.
... The
Java EE approach to this problem is to extract the business logic from the client software and encapsulate it in a group of
pieces. This component runs on a separate server, and the client software provides real
current business logic through the services provided by the network invoke component, and the client software is simply responsible for sending the call request and displaying the processing results. In the Java EE,
the component that 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:
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 the business logic
? So poised, in fact, this so-called "business logic" we can fully understand to perform a specific task "class
".
Anatomy 2: The so-called: "Extract the business logic from the client software, encapsulated in the component ... Run 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
into a component, and put this component on a server to run.
3.2 The concept of EJB into plain English  
becomes plain English, " The classes that you write in the software that need to be executed are not placed on the client soft
, but instead are placed on a server with a packet. "
3.3 found a problem  
Either stereotyped writing or plain English said that the EJB concept mentions a word "Client Software".
"Client Software"? Does the concept of EJB say C/s software?
Yes, that's right!
EJB is to put those "classes" on a server, in the form of C/S software client to the "class" on the server to the "Incoming
line" call. The
is going to crash!
What is the relationship between EJB and JSP? EJB and JSP are related, but the relationship is not very large, at most the
server side of the JSP call the remote service EJB class, that's all.

4   .1 what is the lowest level of the EJB  
We uncover the true meaning of the EJB "stereotyped" concept, then analyze the EJB's underlying implementation techniques to analyze the EJB's working methods through the underlying real
technique.

4.2 EJB Implementation Technology
EJB is a component running on a stand-alone server. 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, the 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:
Serialization of objects
Distributed computing with RPC
 
Serialization of objects: the serialization of an object is the process of converting an object's state into a byte stream and recovering from a byte stream to a
image. After you convert the object state to a byte stream, you can 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 real
of your program to instantiate a class object, for example, you customize a class MyClass, or any class object, convert it to a
byte array, That is, you can put it in a byte array, now that you have put an object in the byte
array, then you can certainly dispose of it, the most used is to send him to the network on the remote Computing
machine. shown in 2 11.

 
 
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 of the programming languages before Java
, such as Fortran, C, COBOL, and so on, are procedural language, not object-oriented. As a result, these
programming languages naturally use procedures to represent work, such as functions or subroutines, that are executed on another machine on the network. When you say
White, the local computer calls a function on the remote computer. As shown in
2 12.

 
  The English name of the
RMI is "remote Method invocation", which is called "Remoting methods call", it is
the use of Java object serialization mechanism to implement distributed computing, the realization of the remote class object instantiation and the method of invocation.
said more clearly, is the use of object serialization to achieve remote invocation, that 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 sequence the object
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 to initiate a process, using this
mechanism, the program syntax rules used by objects on a computer when calling methods on another computer, and the
The syntax rules for method calls between objects on the local machine are the same. As shown in
2 13.

4.4 advantages
This mechanism brings great convenience to the design and programming of distributed computing system. As long as you follow the RMI rules design process
Order, you can no longer have 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. Also
is that a complex type like Java Hassi can be passed as a parameter.
4.5 disadvantage  
If it is a simpler method call, its execution might be much slower than local execution. Even if the simple data returned by the remote socket
mechanism is slower than the application, it is because the information it needs to pass across the network not only
contains the function's return value information, but also contains the byte content after the object is serialized.
4.6 EJB is RMI-based
with RMI technology, the EJB component is created as a remote object by the Java EE, and EJB uses RMI technology, but only
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, just make sure the RMI
principle is clear. You can also figure out when to use EJBS when you don't need ejbs.

5.  The so-called "service Cluster"   in EJBs;
Now that you know, RMI is to put a variety of tasks and functions on different servers, and then implement distributed operations through the call rules established between the various service
. We also understand the concept of EJB's so-called "service Cluster". The
is the CPU and memory resources that are used by several classes that were originally operating on one computer to be run on the other computer to share the operations
Row. At the same time, different software function modules can be placed on a different
server, when the need to modify some features of the server directly modify the class on the line, the modification of all guest
Client software has been modified. shown in 2 14.

6. Is this deployment impeccable?
The "service cluster" shown in Figure 2 14 looks "invulnerable", in fact, it is not a picture of the complete, we come
Complete the picture and see what the problem is.
6.1 Bottlenecks on the database side  
After careful observation, it is found that this configuration has bottlenecks, as shown in 2 15.

 
Let's look at the structure of Figure 2 15, Now if you want to implement individual server queries for the same database, that
No matter how many feature servers you deploy, you need to do a query on a database server. That is,
no matter how "distributed" Your calculations are, you also need to get data from a single server. Although, it seems that the various functions of the
can be distributed on different servers to share the CPU resources of each host computer, however, the real bottleneck is not
here, but the database server there. The database server is very busy responding to queries from individual servers and operating
for requests.
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 on the database server.
6.2 if separate database, data sharing what to do  
Some readers would have thought of the following application structure, as shown in 2 16.

 
is to deploy a database behind each of the feature 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.
6.3 Network is under great pressure to make your application 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 net" one is "B
NET, these two networks are different. "B Network" is often a local area network, the general bandwidth is 10m/100m, faster, so the
to fortunately say, 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 the WAN interconnect cost is higher than
, so there is generally no higher bandwidth.
What runs on this network is the data exchanged between the function module and the client software, and this part of the data exactly
advantage is very bandwidth-intensive.
As a result, the application architecture can see how slow it is to run. Say a word is not exaggerated, a little think old cow
pull broken car as slow.
A system such as the old cow:
Currently in the Chinese Internet as a carrier 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 described above has come to an intolerable level, opening a traffic graph, and
sometimes takes 15 minutes to render intact. 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-connected network of the application, thus causing the company a greater
loss, so that the development architecture was eventually abandoned.

7. EJB ingenious, EE is not required to use EJB   The
is explained in the above section as if the system relationship between EJB and the B/s structure of the development Web application is not very large, in fact
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 question of WAN bandwidth throttling.
However, do not use EJBS as much as possible:
1, simple web-only application development, do not need to use EJBS.
2, applications that need to be used in conjunction with other service programs, but applications that call or return custom network protocols that can be resolved
, do not require the use of EJBS.
3, more people concurrently access the C/s structure of the application, try not to use EJB.

What exactly is EJB, really so mysterious??