[jdjlist] RE: J2EE generated classes

[Greg Nudelman]

Here is a good article for more complications with the failover stuff and clustering.  It also looks like the actual naming of the classes _is_ vendor-specific after all.

 

Home Stub - This object is the first object accessed by remote clients and runs locally on a client's virtual machine. Since stubs and skeletons are typically generated by EJB compilers at deployment time, the underlying logic in a stub can be vendor-specific. Vendors can instrument some method-level load balancing and failover schemes directly in the stub. Since the primary action of the home stub is to create or load beans on a remote server, the server in which a bean is ultimately created is not important. Effectively, every create(...) and findXXX(...) method could load balance requests to a different home skeleton in the cluster. Node D in Figure 1 represents this.

Remote Stub - This object is instantiated by the home skeleton and returned back to the client. This object can perform the same types of load balancing and failover that a home stub can do, but vendors have to be careful about when they choose to do so. For instance, if a client has created an entity bean, it is likely that the entity bean will only exist in one server in the cluster. It is too expensive to have the contents of the same primary key active on multiple servers in the cluster if there aren't multiple clients all requesting the same entity bean. A remote stub that accesses an entity bean cannot freely load balance its requests to other servers in the cluster since the entity bean will only be active on a single server. Essentially, the remote stub is "pinned" to the server that it came from and is not free to load balance at will. Node E in Figure 1 represents this.

http://www.onjava.com/pub/a/onjava/2000/12/15/ejb_clustering.html

Greg

http://www.hotscifi.com

-----Original Message-----
From: Greg Nudelman
Sent: Wednesday, May 22, 2002 11:24 AM
To: JDJList
Subject: [jdjlist] RE: J2EE generated classes

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

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