An in-depth understanding of Java Technology EJB invoke principle analysis

A remote object must include at least 4 class files: The remote object, the interface of the remote object, the stub of the object that implements the remote interface, and the 4 class files for the skeleton of the object.

At least 10 classes are included in the EJB:

Bean class, specific app server Bean implementation class, Bean's remote interface, specific app server remote interface implementation class, specific app server remote interface implementation class stub class and skeleton class.

The Bean's home interface, the home interface implementation class for a particular app server, the stub class of the implementation class for the home interface of a particular app server, and the skeleton class and RMI, differ from the 10 classes in the EJB that really require the user to write only 3, The Bean class and its remote interface, the home interface, as to how the other 7 classes were built, where they were packaged, or whether more class files were needed, would vary widely according to the different app servers.

Take my most familiar WebLogic, the WebLogic Bean implementation class, and the WebLogic implementation class of the two interfaces are packaged into the EJB jar package at EJBC time, which can be seen in the 3 class files. The stub class and skeleton Class of the implementation class of the WebLogic of the home interface and the remote interface are the byte code of the stub class and the skeleton class dynamically generated by WebLogic when the EJB is deployed to WebLogic, so the 4 class files are not seen.

For a client-side remote Invoke EJB, it passes through multiple RMI loops of two remote objects. The first is to find the home interface through Jndi and get the implementation class for the home interface, which is actually quite complex.

The first is to find the WebLogic implementation class of the home interface, and then create an object instance of the stub class of the WebLogic implementation class of the home interface and serialize it to the client (note that the instance of the stub class is dynamically sent to the client by the server in the 1th RMI loop). Therefore, the client is not required to save the stub class of the WebLogic implementation class of the home interface, and finally the client obtains the object instance of the stub class (normal RMI needs to save the stub class on the client, and the EJB does not, because the server sends an object instance of the stub class to the client).

After the client takes the stub class object instance of the WebLogic implementation class of the server to its home interface, calls the stub class's Create method (in the Code is home.create (), but there are many things to do in the background), and then after the 2nd RMI Loop, on the server side , the skeleton class of the WebLogic implementation class of the home interface receives the invocation information of the stub class, which then calls the home interface's WebLogic implementation class's Create method.

On the server side, the WebLogic implementation class creation method of the home interface invokes the Ejbcreate method of the WebLogic implementation class of the Bean class, creating or allocating an EJB instance on the server side. The stub class object instance of the WebLogic implementation class of the remote interface of this EJB instance is then serialized to the client.

The client receives the object instance of the stub class of the WebLogic implementation class of the remote interface, and the method invocation of the object instance (in the client code is actually a call to the remote interface), The skeleton class object that will be routed to the WebLogic implementation class of the server-side remote interface, and the Skeleton class object calls the WebLogic implementation class of the corresponding remote interface. The WebLogic implementation class of the remote interface then invokes the WebLogic implementation class of the Bean class, which completes the remote invocation of the EJB object.

Read the post, feeling still did not say too clearly, since write a post, want to completely put it clearly.

For general RMI first, there are 4 classes, which are remote objects, object interfaces, stub classes of objects, and skeleton class. Both the object itself and the object's stub class both implement the interface class. While the client code invokes the remote object, while manipulating the interface in the code, it is essentially manipulating the stub class, for example:

Interface class: Hello

Remote objects: Hello_server

Stub class: Hello_stub

Skeleton class: Hello_skeleton

The client code is written like this:

Hello h = new Hello_stub ();

H.getstring ();

We don't write this:

Hello_stub h = new Hello_stub ();

H.getstring ();

Because of the wider applicability of the interface, you do not need to change the code even if you replace the interface implementation class. So the client needs Hello.class and hello_stub.class these two files.

But for EJBS, there is no need to hello_stub.class, because the server will send it, but Hello.class file client is not save, must have. On the surface our client code is manipulating Hello, but don't forget that Hello is just an interface, abstract, essentially manipulating hello_stub.

Take the EJB example on WebLogic, 10 class is:

Bean class: Hellobean (User written)

WebLogic implementation class for Bean class: Hellobean_impl (EJBC build)

Home interface: Hellohome (user written)

WebLogic implementation class of the Home Interface ((Hello Bean)) _homeimpl (EJBC generated)