[jdjlist] RE: J2EE generated classes

[Greg Nudelman]

This is a tough question, but that is why we're here! OK, here goes.

 

1) Home and Bean itself are not really that different to access.  Both behave similarly. Under the hood, both are remote objects accessed from the client via remote interface.  That should explain why they are both so similar and both require stub and skeleton classes.

 

2) Home is a specialized remote object responsible for Bean's lifecycle: taking the bean object instance from the pool and creating the actual bean objects, and returning the remote reference to the client, then returning the Bean object to the pool when the client is done with it.

 

3) The diagram for BOTH Bean and Home looks like this:
CLIENT                                                                                     EJB Server
[Remote Interface] wraps [stub] <------------------------------------------------------------>  [Remote Interface] wraps [skeleton] passes requests to [EJB Object] which wraps [Bean Instance]

 

(if this is EJB Home, there is no Bean Instance class, otherwise it is the same access mechanism)

 

4) Stubs and skeleton files allow communication between a client and a component in EJB Server.
 
5) Stub (or proxy) files act as a client-side remote control. You include the stubs in your client, and use it make calls to a remote component. The stub contains the method signatures for the server component, and handles the details of remote server communication.

 

6) Skeleton files are specific to server-code; they reside on the server, and map incoming client requests to server method invocations. A skeleton is used by the server to communicate with the component. (Only the server makes calls on a skeleton. As a client and/or component developer, you do not call or implement skeleton files at all.)

 

------------------------------------------- Now for actual code practice! -----------------------------

 

//[EJB home stub] wrapped as a [Home Interface] is returned from the servlet context
//(Note: no EJB Server communication yet occured).
//Why wrap with interface? Because no one wants to write TestHomeCtx_Stub.class manually and
//all the remote methods are specified in the interface.

 

TestHome home = (TestHome) context.lookup("YourSystem.TestHome");

 

//a TestHome.class interface method create() is called on a client-side stub, TestHomeCtx_Stub.class
//stub communicates with the TestHomeCtx_Skel.class on the server which has bindings to enable it to call
//the implementations of the actual methods, contained in the TestHomeImpl.class
//My guess that TestHomeCtx.class provides some grease in the middle to help this communication.
//Finally, an instance of the TestBeanImpl.class is created as well as the TestBeanCtx_Skel.class which
//contains the bindings to the actual bean methods.
//this bean stub is returned to the client wrapped by the Test.class interface.

 

Test test = home.create();

 

//Test.class interface contains all the remote method signitures that can be executed
//on the EJB server's instance of the TestBean.class object.
//We call the getXXX() method on the client stub. 
//TestCtx_Stub.class stub communicates with the TestCtx_Skel.class on the server which has bindings to enable it to call
//the implementations of the actual methods, contained in the TestImpl.class which executes the getXXX()
//method and the resulting xxx object is returned to the client.

 

Object xxx = test.getXXX();

 

//call is completed. Whew. I hope that helped.

 

Greg Nudelman

 

http://www.hotscifi.com

 

          

 

-----Original Message-----
From: Fewtrell, Tom [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 22, 2002 7:53 AM
To: JDJList
Subject: [jdjlist] J2EE generated classes

Can anyone give an explanation of the classes generated by a J2EE compiler implementing/extending the home interface and bean class to create a deployable EJB?

 

For example, from the initial classes:

 

Test.class
TestBean.class
TestHome.class

 

to:

TestBeanImpl.class
TestBeanCtx.class
TestBeanCtx_Skel.class
TestBeanCtx_Stub.class
TestHomeImpl.class
TestHomeCtx.class
TestHomeCtx_Skel.class
TestHomeCtx_Stub.class

 

I'm assuming the naming conventions Impl, Ctx, Ctx_Skel, Ctx_Stub,  are NOT implementation specific?, I am interested to know the significance of each generated class.

 

Cheers

Tom

To change your membership options, refer to:
http://www.sys-con.com/java/list.cfm
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
To change your membership options, refer to:
http://www.sys-con.com/java/list.cfm

To change your membership options, refer to:
http://www.sys-con.com/java/list.cfm