Author: robbin (MSN: robbin_fan AT hotmail DOT com)
A remote object should include at least 4 Class files: remote objects; the interface of the remote object; the STUB of the object of the remote interface; 4 Class files for the object's Skeleton.
In EJB, at least 10 CLASS:
Bean class, a bean implementation class for specific APP Server
BEAN's Remote Interface, Remote Interface for Specific App Server Implementation Class, STUB classes for the Remote interface of specific App Server, and Skeleton classes
BEAN's Home interface, HOME interface for specific App Server implementation class, the implementation of the HOME interface of a specific App Server, Skeleton Class
Unlike RMI, the 10 CLASS in EJB really requires only three, which are the bean class and its Remote interface, HOME interface, how is the other 7 CLASS? How to generate, what is packaged? Or if you need more types of files, it will be more common depending on the different App Server.
Take my most familiar WebLogic, WebLogic's bean implements classes, and the implementation class of the two interfaces of WebLogic is packaged in the jar package of EJB when EJBC, which can be seen. The Stub class and the Skeleton class of the HOME interface and the Remote interface of WebLogic are used when EJB is deployed to WebLogic, which is dynamically generated by the web class and the Skeleton class by the weblogic, so these 4 files cannot be seen. .
For a client remote call EJB, you should pass multiple RMI loops in two remote objects. The first is to find the Home interface through JNDI, get the implementation class of the Home interface, this process is actually quite complicated, first to find the WebLogic implementation class of the Home interface, then create an object instance of the WEBLOGIC implementation class of the Home interface, set it sequence Transfer to the client (Note that the instance of the Stub class is in the first RMI loop, dynamically sent by the server to the client, so it does not require the client to save the WEBLOGIC implementation class of the HOME interface, and finally the client gets STUB class object instance (ordinary RMI needs to save the Stub class on the client, and EJB does not need because the server sends the STUB class's object instance to the client).
After the client gets the server to the WEBLOGIC implementation of the home interface, the client is called the STUB class object instance, and the Create method of the Stub class is called, (on the code is home.create (), but the background must do a lot of things), so through 2 RMI loops, after the server side, the WEBLOGIC implementation class of the Home interface, after receiving the call information of the Stub class, then call the Home interface WebLogic implementation class CREATE method.
At the server, the Home interface WebLogic implementation class CREATE method then calls the bean class's WebLogic implementation class's EJBCREATE method, create or assign an EJB instance in the server, and then use the WebLogic's remote interface of the WebLogic implementation class STUB Class object instance serialization sent to the client.
The client receives the object instance of the STUB class of the REMOTE interface, the method of calling the object instance (actually in the client code is actually calling the Remote interface), which will transmit to the server-side Remote interface WebLogic implementation The class of the Skeleton class object, and the Skeleton class object calls the WebLogic implementation class of the corresponding Remote interface, then the REMOTE interface's WebLogic implementation class will call the bean class's WebLogic implementation class, which completes the remote call of the EJB object. After reading a post, I didn't say it too clearly. Since I wrote post, I would like to completely clear it.
Take ordinary RMI, there are 4 CLASS, which are remote objects, objects interface, object's Stub class, and Skeleton classes. The STUB class of the object itself and the object implements the interface class. When we call the remote object in the client code, although the interface is manipulated in the code, it is essentially in manipulating the Stub class, for example:
Interface class: hello
Remote object: Hello_Server
Stub class: Hello_STUB
Skeleton Class: Hello_skeleton
Client code to write this:
Hello H = new hello_stub ();
h.getstring ();
We will not write this:
Hello_stub h = new hello_stub ();
h.getstring ();
Because the use interface is applicable, even if the interface is replaced, you do not need to change the code. Therefore, the client needs two files that hello.class and hello_stub.class. But for EJB, hello_stub.class is not required, because the server will send it, but the Hello.Class file client is invalid, there must be. On the surface, our client code is manipulating Hello, but don't forget that hello is just an interface, abstract, essentially in manipulating Hello_stub.
Take the EJB on WebLogic Example, 10 Classs are:
Bean class: Hellobean (user writing)
BEAN's WebLogic implementation class: Hellobean_Impl (EJBC generated)
HOME interface: Hellohome (user writing)
Home interface WebLogic implementation class (Hello Bean) _ HomeImpl (EJBC Generation)
Home interface WebLogic implementation class STUB class ((hello bean) _ HomeImpl_WLSTUB (dynamically generated byte code when deploying)
Home interface WebLogic implementation class's Skeleton class ((Hello bean) _ HomeImpl_wlskeleton (dynamically generated byte code when deploying)
Remote interface: Hello (user writing)
The WebLogic implementation class of the Remote interface ((Hello Bean) _ EOIMPL (EJBC Generation)
Remote interface WebLogic implementation class's Stub class ((Hello bean)) _ EOIMPL_WLSTUB (dynamically generated byte code when deploying)
Remote interface WebLogic implementation class Skeleton class (Hello bean) _ EOIMPL_WLSKELETON (dynamically generated byte code when deploying)
The client only needs both files of hello.class and hellohome.class. (Hello Home) Home = ((Portable Remote Object)). Narrow ("Hello"), ((Hello Home). Class);
This line of code is a Home interface from JNDI, but please remember! The interface is abstract, then what kind of object instance is this object? Very simple, use the toString () output to look at it, the following line is the output:
((Hello Bean) _ HomeImpl_wlstub @ 18C458
This indicates that Home is actually an instance of the Hellobean_HomeImpl_wlstub class by looking for the object obtained from the server's JNDI tree.
Next, client code:
Hello h = home.create ()
The same hello is just an abstract interface, then what is the H object? Print:
(Hello Bean) _ EOIMPL_WLSTUB @ 8fa0d1
It turned out to be an object instance of Hellobean_eoImpl_wlstub.
Use this example to briefly describe an EJB call process:
First of all, the client JNDI query, the server JNDI tree actually binds the object that is hellobean_homeimpl_wlstub, so the server will create an object instance of Hellobean_homeImpl_wlstub, serialization returns to the client.
So the client gets the HOME object, the surface is an instance of the HelloHome interface. It is actually an object instance of the Hellobean_HomeImpl_wlstub class once, don't forget that hellobean_homeimpl_wlstub also implements the HelloHome interface.
Then home.create () it is essentially HelloBean_HomeImpl_WLStub.create (), which sends the information to HelloBean_HomeImpl_WLSkeleton, and after HelloBean_HomeImpl_WLSkeleton receive information, go call the create method HelloBean_HomeImpl, and thus completed the 1st cycle of the complete RMI.
Note that during this RMI cycle process, the remote object is Hellobean_HomeImpl, the interface of the remote object is HelloHome, the object's stub is Hellobean_HomeImpl_wlstub, the Skeleton is Hellobean_HomeImpl_wlskeleton.
Then Hellobean_HomeImpl then calls the Hellobean_Impl EJBCREATE method, and the Hellobean_impl's EJBCREATE method will be responsible for creating or assigning a bean instance and creates a Hellobean_eoIMPL_WLSTUB object instance.
This step is more interesting. In the previous step RMI loop, the remote object Hellobe_HomeImpl has an agent Hellobean_HomeImpl_wlstub in the client, but in this step, hellobean_homeimpl acts as a proxy class of Hellobean_impl, but hellobean_homeiMPL is not in the client, but On the server, there is no RMI.
Then the object instance HelloBean_EOImpl_WLStub serialized back to the client, this step is also very interesting, the last RMI process, and its protagonist is HelloBean_HomeImpl proxy class HelloBean_HomeImpl_WLStub, but this time replaced HelloBean_EOImpl and its agents to play the class HelloBean_EOImpl_WLStub . Hello h = home.create (); h.helloworld ();
Assuming that the Hello interface has a HelloWorld remote method, the surface is a HelloWorld method that calls the Hello interface. It is actually called HelloBean_eoIMPL_WLstub's HelloWorld method.
Then HelloBean_eoImpl_wlstub's HelloWorld method will send information to hellobean_eoimpl_wlskeleton on the server, and hellobean_eoimpl_wlskeleton receives the information, then call HelloBean_eoImpl's HelloWorld method. At this point, complete the second complete RMI loop process.
In just now hellobean_eoimpl is called as a remote object, its proxy class is hellobean_eoimpl_wlstub, but now hellobean_eoimpl is a proxy class of Hellobean_Impl. Now hellobean_eoimpl went to call the HelloBean_Impl's HelloWorld method. note! Hellobean_impl inherits Hellobean, and HelloWorld method in Hellobean is the code we personally prepared, and now I finally called to our code!
At this point, the EJB call process is finally completed. During the whole process, the class mainly want to call the class is Hellobean_Impl, Hello Bean®_HomeImpl, HelloBean_HomeImpl_wlskeleton, Hellobean_EoImpl, Hellobean_eoImpl_wlskeleton. The class mainly called by the client is Hellobean_HomeImpl_wlstub, hellobean_eoimpl_wlstub, these two classes do not appear directly in the client code, the classes in the code are their interface hellohome and hello, so the client needs these two interface files, STUB is the server is delivered to them.
