Analysis on the principle of calling an EJB written by robbin

A remote object must contain at least four class files: remote objects, remote object interfaces, stub that implements remote interfaces, and skeleton class files.

In EJB, there must be at least 10 classes:
Bean class, Bean implementation class for specific App Server
Bean remote interface, specific App Server remote interface implementation class, specific App Server remote interface implementation class stub class and skeleton class
Bean home interface, home interface implementation class of the specific App Server, stub class and skeleton class of the home interface implementation class of the specific App Server

Unlike RMI, only three of the 10 classes in EJB really need to be written by the user, namely the Bean class, its remote interface, and the home interface, as to how the other seven classes are generated, where they are packaged, or whether more class files are required, the differences vary greatly depending on the App Server, cannot be generalized.

For Weblogic, which I am most familiar with, the Bean implementation class of Weblogic and the Weblogic implementation class of the two interfaces are packaged into the jar package of ejbc, the three class files can be seen. The stub and skeleton classes of the Weblogic implementation classes of the home and remote interfaces are the bytecode of the stub and Skeleton classes dynamically generated by Weblogic when the EJB is deployed to Weblogic, therefore, these four class files cannot be seen.

For a client to remotely call ejbs, it must go through multiple RMI loops of two remote objects. First, find the Home interface through JNDI and obtain the implementation class of the Home interface. This process is actually quite complicated. First, find the Weblogic implementation class of the Home interface, create a Weblogic implementation class stub class object instance of the Home interface and serialize it to the client (note that stub class instances are in 1st RMI loops, the server dynamically sends the message to the client. Therefore, the client does not need to save the Weblogic implementation class stub class of the Home interface ), finally, the client obtains the stub class object instance (the common RMI needs to save the stub class on the client, but the EJB does not, because the server will send the stub class object instance to the client ).

After the client obtains the stub class object instance of the Weblogic implementation class of the Home interface provided by the server, it calls the create method of the stub class (in the code, it is home. create (), but there are many things to do in the background), so after 2nd RMI loops, after the skeleton class of the Weblogic implementation class of the Home interface receives the call information of the stub class on the server side, it then calls the create method of the Weblogic implementation class of the Home interface.

On the server side, the create method of the Weblogic implementation class of the Home interface then calls the ejbCreate method of the Weblogic implementation class of the Bean class, and creates or allocates an EJB instance on the server side, then, serialize the Weblogic implementation class stub class object instance of the remote interface of the EJB instance and send it to the client.

The client receives the stub class object instance of the Weblogic implementation class of the remote interface and calls the method of this object instance (in the client code, it is actually a call to the remote interface ), the skeleton Class Object of the Weblogic implementation class that is sent to the remote interface on the server side, and the skeleton Class Object then calls the Weblogic implementation class of the corresponding remote interface, the Weblogic implementation class of the remote interface then calls the Weblogic implementation class of the Bean class to complete a remote call of the EJB object.

After reading the post, I still didn't think it was clear. Since I wrote the post, I wanted to make it clear.

Take RMI for example, there are four classes: remote objects, object interfaces, stub classes of objects, and skeleton classes. The object itself and the stub class of the object both implement the interface class. When the client code calls a remote object, although the interface is manipulated in the code, it is essentially manipulating the stub class, for example:
Interface Class: Hello
Remote Object: Hello_Server
Stub class: Hello_Stub
Skeleton class: Hello_Skeleton

Write the client code as follows:
Hello h = new Hello_Stub ();
H. getString ();

We won't write the following:
Hello_Stub h = new Hello_Stub ();
H. getString ();

Even if the interface implementation class is replaced, you do not need to change the code. Therefore, the client needs the Hello. class and Hello_Stub.class files. But for EJB, Hello_Stub.class is not required, because the server will send it, but the Hello. class file client cannot save, and must have. On the surface, our client code is manipulating "Hello", but don't forget that "Hello" is just an interface. It is abstract. It is essentially manipulating Hello_Stub.

Take the EJB on Weblogic as an example. The 10 classes are:
Bean class: HelloBean (written by the user)
Weblogic implementation class of Bean class: HelloBean_Impl (generated by EJBC)

Home interface: HelloHome (prepared by the user)
The Weblogic implementation class HelloBean_HomeImpl of the Home interface (generated by EJBC)
The stub class HelloBean_HomeImpl_WLStub of the Weblogic implementation class of the Home interface (the bytecode is dynamically generated during deployment)
The skeleton class HelloBean_HomeImpl_WLSkeleton of the Weblogic implementation class of the Home interface (Dynamic bytecode is generated during deployment)

Remote interface: Hello (prepared by the user)
Weblogic implementation class HelloBean_EOImpl of the Remote interface (generated by EJBC)
The stub class HelloBean_EOImpl_WLStub of the Weblogic implementation class of the Remote interface (the bytecode is dynamically generated during deployment)
The skeleton class HelloBean_EOImpl_WLSkeleton of the Weblogic implementation class of the Remote interface (Dynamic bytecode is generated during deployment)

The client only needs the Hello. class and HelloHome. class files.

HelloHome home = (Home) PortableRemoteObject. narrow (ctx. lookup ("Hello"), HelloHome. class );

This line of code obtains the Home interface from JNDI, but remember! The interface is abstract. So what kind of object instance is the home object? It's easy to use toString () for output. The following line shows the output result:
HelloBean_HomeImpl_WLStub @ 18c458
This indicates that the home object obtained from the server's JNDI tree is actually an instance of the HelloBean_HomeImpl_WLStub class.
The client code is as follows:

Hello h = home. create ()

Similarly, Hello is just an abstract interface. What is the h object? Print:
HelloBean_EOImpl_WLStub @ 8fa0d1
It turns out to be an object instance of HelloBean_EOImpl_WLStub.

This example is used to describe the EJB call process:

First, the client JNDI query. The Hello name bound to the server's JNDI tree is HelloBean_HomeImpl_WLStub. Therefore, the server creates an object instance of HelloBean_HomeImpl_WLStub and serializes it and returns it to the client.

The client obtains the home object. On the surface, it obtains the HelloHome interface instance. In fact, it performs a remote call and obtains the HelloBean_HomeImpl_WLStub class object instance. Do not forget that HelloBean_HomeImpl_WLStub also implements the hello.

Then home. create () is actually HelloBean_HomeImpl_WLStub.create (). This method will send information to the consumer. After the consumer receives the information, it will call the create method of HelloBean_HomeImpl to complete 1st complete RMI loops.

Note that during this RMI loop, the remote object is HelloBean_HomeImpl, the remote object interface is HelloHome, the object's stub is HelloBean_HomeImpl_WLStub, and the object's skeleton is callback.

Then HelloBean_HomeImpl calls the ejbCreate method of HelloBean_Impl, while the ejbCreate method of HelloBean_Impl will be responsible for creating or allocating a Bean instance and creating an object instance of HelloBean_EOImpl_WLStub.

This step is interesting. In the previous RMI loop, the remote object hellobean_homeimpl has a proxy class ingress on the client, but in this step, hellobean_homeimpl acts as the proxy class of hellobean_impl, hellobean_homeimpl is not on the client, but on the server, so RMI is not performed.

Then, the hellobean_eoimpl_wlstub object instance is serialized and returned to the client. This step is also interesting. During the last RMI process, the main character is hellobean_homeimpl and its proxy class hellobean_homeimpl_wlstub, but this time it was changed to hellobean_eoimpl and its proxy class hellobean_eoimpl_wlstub.

Hello H = home. Create (); H. helloworld ();

Assume that the hello interface has a helloworld remote method. On the surface, the helloworld method of the Hello interface is called. In fact, the hellobean_eoimpl_wlstub helloworld method is called.

Then, the hellobean_eoimpl_wlstub helloworld method will send information to hellobean_eoimpl_wlskeleton on the server, and the worker will call hellobean_eoimpl's helloworld method after receiving the information. So far, 2nd complete RMI cycles have been completed.

Hellobean_eoimpl was called as a remote object. Its proxy class is hellobean_eoimpl_wlstub, but now hellobean_eoimpl is used as the proxy class of hellobean_impl. Now hellobean_eoimpl calls hellobean_impl's helloworld method. Note! Hellobean_impl inherits hellobean, And the helloworld method in hellobean is the code we have compiled. Now we have finally called the code we have compiled!

So far, an EJB call process has finally been completed. The main classes to be called by the server are hellobean_impl, hellobean_homeimpl, hellobean_homeimpl_wlskeleton, hellobean_eoimpl, and hellobean_eoimpl_wlskeleton. The main classes called by the client are hellobean_homeimpl_wlstub and hellobean_eoimpl_wlstub. These two classes do not appear directly in the client code. The classes in the Code are their interfaces hellohome and hello, therefore, the client needs these two interface files, and stub is sent to them by the server.