An analysis of the principle of EJB invocation Robbin Write

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. In the EJB, you must include at least 10 Class:bean classes, the specific app server Bean implements the remote interface of the class bean, the remote interface implementation class for the specific app server, the specific app Server's remote interface's implementation class stub class and the Skeleton Class Bean's home interface, the specific app server's home interface implementation class, the specific app server's home interface implementation class's Stub class and skeleton class Unlike RMI, the 10 classes in the EJB really require the user to write only 3, respectively, the Bean class and its remote interface, the home interface, as to how the other 7 classes are built, where they are packaged, or whether more class files are needed, will be based on different app server show a larger difference, can not generalize. 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 to get the implementation class of the Home interface, which is rather complicated, first of all, 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, Serializing it to the client (note that instances of the stub class are dynamically sent to the client in the 1th RMI loop, so that the client does not need to save the stub class of the WebLogic implementation class of the Home interface), Finally, the client obtains an object instance of the stub class (normal RMI needs to save the stub class on the client, and the EJB does not need it because the server sends the 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, it invokes the Create method of the stub class (in the code is home.create (), but the backgroundDo a lot of things), so after the 2nd RMI cycle, on the server side, the home interface of the WebLogic implementation class skeleton class received the call information, it then calls the home interface WebLogic implementation class 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. When we call the remote object in the client code, while manipulating the interface in the code, we are essentially manipulating the Stub class, for example: interface class: Hello remote object: Hello_server Stub class: Hello_stub Skeleton class: Hello_ Skeleton client code is written like this: Hello h = new Hello_stub (); H.getstring (); We do not write these: 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. Get the WebLogic on the EJB example, 10 classes are: Bean class: Hellobean (User-written) Bean class WebLogic Implementation class: Hellobean_impl (EJBC generated) Home interface: Hellohome (user written) The WebLogic Implementation class Hellobean_homeimpl (EJBC generated) home interface is a stub class of the WebLogic implementation class Hellobean_homeimpl_wlstub (dynamically generating bytecode when deployed) Home interface WebLogic Implementation class skeleton class Hellobean_homeimpl_wlskeleton (dynamically generating bytecode when deployed) remote interface: Hello (user written) Remote interface WebLogic Implementation class Hellobean_eoimpl (EJBC generated) remote interface WebLogic implementation class stub class Hellobean_eoimpl_wlstub (when the deployment of dynamically generated bytecode) Remote interface WebLogic Implementation class skeleton class Hellobean_eoimpl_wlskeleton (dynamically generate bytecode when deployed) clients only need Hello.class and hellohome.class these two files. Hellohome home = (home) portableremoteobject.narrow (Ctx.lookup ("Hello"), Hellohome.class); This line of code is to get the home interface from Jndi, but keep in mind! The interface is abstract, so what exactly is the object instance of the Home object? Quite simply, with the ToString () output, you see, the following line is the output: hellobean_homeimpl_wlstub@18c458 This indicates that home this is actually hellobean_ by looking up the object from the server's Jndi tree An instance of the Homeimpl_wlstub class. Next client code: Hello H = home.create () Same Hello is just an abstract interface, so what is H object? Print: Hellobean_eoimpl_wlstub@8fa0d1 was originally an object instance of Hellobean_eoimpl_wlstub. Use this example to briefly describe the EJB invocation process: First client Jndi lookup, server-side JnThe name of hello in the di tree is actually a Hellobean_homeimpl_wlstub object, so the server will create an object instance of Hellobean_homeimpl_wlstub and serialize it back to the client. So the client gets the home object, ostensibly to get an instance of the Hellohome interface, actually making a remote call to get the object instance of the Hellobean_homeimpl_wlstub class, and don't forget Hellobean_homeimpl_ Wlstub also implements the Hellohome interface. Then Home.create () is essentially hellobean_homeimpl_wlstub.create (), which sends the message to Hellobean_homeimpl_wlskeleton, and Hellobean_ Homeimpl_wlskeleton receives the information and then calls the Hellobean_homeimpl create method to complete the 1th full RMI loop. Note that during this RMI cycle, the remote object is Hellobean_homeimpl, the interface of the remote object is Hellohome, and the stub of the object is Hellobean_homeimpl_wlstub, The skeleton of the object is Hellobean_homeimpl_wlskeleton. Hellobean_homeimpl then calls the Hellobean_impl Ejbcreate method, and the Hellobean_impl Ejbcreate method is responsible for creating or allocating a bean instance. and create a Hellobean_eoimpl_wlstub object instance. What's interesting about this step is that in the previous RMI loop, the remote object Hellobean_homeimpl has a proxy class hellobean_homeimpl_wlstub on the client, but in this step, hellobean_ Homeimpl himself as a Hellobean_impl proxy class, but Hellobean_homeimpl not on the client side, but on the server, so do not carry RMI. Then the Hellobean_eoimpl_wlstub object instance serialization is returned to the client, which is also interesting, and the last RMI process, the protagonist is Hellobean_homeimpl and its proxy class hellobean_homeimpl_wlstub, But this time it was replaced by Hellobean_eoimpl and its proxy class Hellobean_eoimpL_wlstub to play. Hello h = home.create (); H.helloworld (); Assuming that the Hello interface has a HelloWorld remote method, the surface is calling the HelloWorld method of the Hello interface, which is actually invoking the Hellobean_eoimpl_wlstub HelloWorld method. Then the Hellobean_eoimpl_wlstub HelloWorld method sends the message to the Hellobean_eoimpl_wlskeleton on the server, and Hellobean_eoimpl_ Wlskeleton receives the information, then calls the Hellobean_eoimpl HelloWorld method. This completes the 2nd time full RMI cycle process. In just Hellobean_eoimpl was invoked as a remote object, its proxy class is hellobean_eoimpl_wlstub, but now hellobean_eoimpl to be the proxy class for Hellobean_impl. Now Hellobean_eoimpl to invoke the Hellobean_impl HelloWorld method. Attention! Hellobean_impl inherited Hellobean, and the HelloWorld method in Hellobean is the code we wrote ourselves, and now we finally call the code we wrote! At this point, the EJB call process is finally complete. Throughout the process, the main server to invoke the class is Hellobean_impl, Hellobean_homeimpl,hellobean_homeimpl_wlskeleton,hellobean_eoimpl,hellobean_ Eoimpl_wlskeleton. The class that the client is calling primarily is hellobean_homeimpl_wlstub,hellobean_eoimpl_wlstub, and these two classes do not appear directly in the client code, and the classes appearing in the code are their interfaces Hellohome and Hello, So the client needs both of these interface files, and the stub is sent to them by the server.