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 classes, specific App Server's bean implementation class bean's Remote interface, the Remote interface of a particular App Server implementation class, the implementation of the specific App Server's Remote interface of the STUB class and Skeleton class BEAN's Home interface, the HOME interface of a particular app server implements the class, and the STUB class and the Skeleton class and RMI of the HOME interface of the specific App Server are different. These 10 CLASs in EJB really require only 3 users. They are the bean class and its remote interface, HOME interface, so that the other 7 CLASS is generated, what is packaged, or if more type files are needed, it will show a relatively large number of app servers. Differences, can not be generalized. 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. And when we call the remote object in the client code, though in the code, it is actually manipulating the Stub class, for example: interface class: hello remote object: Hello_Server Stub class: Hello_STub SkeleTon Class: Hello_skeleton client code To be like this Write: hello h = new hello_stub (); h.getstring (); we will not write: hello_stub h = new hello_stub (); h.getstring (); because the interface is applicable, even if the interface is replaced No 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 of WebLogic Example, 10 Class: Bean Class: Hellobean (User Writing) Bean WebLogic Implementation Class: Hellobean_Impl (EJBC Generation) Home Interface: HelloHome (User Writing) Home Interface WebLogic Implementation HelloBean_HomeImpl EJBC Generation) Home Interface WebLogic Implementation Class Stub Class Hellobean_HomeImpl_WLSTUB (Dynamically generated by) Home interface WebLogic implementation class Skeleton class Hellobean_HomeImpl_wlskeleton (Dynamically generated by means) Remote Interface: Hello (User Writing ) Skeleton HelloBean_EOImpl_WLSkeleton stub class based Remote Weblogic Weblogic implementation class interface implementation class HelloBean_EOImpl (EJBC generation) Remote interface HelloBean_EOImpl_WLStub (when deployed dynamically generated byte code) Weblogic Remote interface implementation class (when deployed dynamically generated byte Code) The client only needs hello.class and hellohome.class two files.
HelloHome Home = (Home) PortableRemoteObject.narrow ("Hello"), HelloHome.Class; this line of code is from JNDI to HOME interface, but please remember! The interface is abstract, then what kind of object instance is this object? Very simple, use toString () output to look at it, the following line is the output result: hellobean_homeimpl_wlstub @ 18c458 This indicates that Home This is actually an instance of the Hellobean_HomeImpl_wlstub class through the objects obtained from the server's JNDI tree. Next client code: Hello H = home.create () The same hello is just an abstract interface, what is the H object? Print: Hellobean_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 queries, the server JNDI tree is actually bound to the object is Hellobean_HomeImpl_wlstub, so the server will create an object instance of Hellobean_HomeImpl_wlstub, serialization returns to customers end. 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.
