SLSB, ejbCreate() and access to EJBObject

[Phanindra Nayani]

Hi,
In Stateless Session Bean, Actual bean creation and ejbCreate() invocation will happen unrelated to the actualt client invocation of create(). For example bean creation and ejbCreate() is invoked to create a bean and add it to pool. Later client may come and call create() on Home which will then create the EJBObject. tHis is how it is define in HFEJB book. In that case how can ejbCreate() have access to EJBObject? EJBObject wont be created while the ejbCreate() is being executed. PLease explain how this is possible.
Thanks,
Phani

[Jack Zhou]

In that case how can ejbCreate() have access to EJBObject? EJBObject wont be created while the ejbCreate() is being executed. PLease explain how this is possible.

I am not reading HF book Here is what i think.
I think bean instance and EBJObject are two separate objects. ejbCreate is called on the bean instance. The EJBObject represents the the class implementing the remote interface. When container instantiate a bean instance and call setSessionContext and finally call ebjCreate. The bean instance is already established. ejb spec simply requies container to make the EBJObject available to the bean instance at this point.

[Phanindra Nayani]

EJBObject is available at that point means, EJBObject instance which is representing the bean. It does not mean EJBObject class type which is allways available. I think you assumption may not be correct. Anyway thanks for trying to help me.

[Reid M. Pinchback]

The spec OID diagrams tend to be a bit clearer than HFE on issues like this, but SLSB is the significant the counter-example. The vary nature of a SLSB means you have to interpret some interface methods in a slightly more subtle fashion:
In SFSB, SessionContext.getEJBObject gets you *the* EJBObject, i.e. the bean instance and the client both have to be accessing the same EJBObject because to service any requests correctly they both need access to the same conversational state.
In SLSB, SessionContext.getEJBObject gets you *an* EJBObject, i.e. the bean instance and the client don't require access to the same EJBObject - to the container all bean instances and hence all EJBObjects are equally suitable for servicing requests.
[ February 23, 2004: Message edited by: Reid M. Pinchback ]

[Jack Zhou]

I do mean the instance of the type EBJObject to available.
Here what is from java doc

 
getEJBObject
public EJBObject getEJBObject()
                       throws IllegalStateExceptionObtain a reference to the EJB object that is currently associated with the instance. 
An instance of an entity enterprise Bean can call this method only when the instance is associated with an EJB object identity, i.e. in the ejbActivate, ejbPassivate, ejbPostCreate, ejbRemove, ejbLoad, ejbStore, and business methods. 
An instance can use this method, for example, when it wants to pass a reference to itself in a method argument or result. 

Returns:
The EJB object currently associated with the instance. 
Throws: 
IllegalStateException - Thrown if the instance invokes this method while the instance is in a state that does not allow the instance to invoke this method, or if the instance does not have a remote interface.
 

I believe an instance of EJBObject is an instance of a class that is created by container and implements the component interface provided by bean provider. This instance implements Remote.
A bean instance is usually an instance of the bean class that is usually not a Remote.
As the java doc says, the getEJBObject "Obtain a reference to the EJB object that is currently associated with the instance". It is client view of the "bean instance". It is the the proxy of the "bean instance" whose existence my be not neccessarily tied with the existence the EJBObject. When client calls create() on the home object, it returns an EJBObject which is a remote. Container need to assoicate a bean instance so that the client's subsequence call to this EJBObject is delegated to the bean instance. Container my create a new bean instance or use one in the pool to complete this assoication.
The ability to obtain a "associated EBJObject reference" should be looked as an evidance of this association not the existence of the bean instance or the remote EJBObject.
Thanks,

[Phanindra Nayani]

Sorry guys, Im not able to understand your point. Are you saying that there is some arbitary/temporary EJBObject instance associated with the bean when ejbCreate() is being executed?

[Jack Zhou]

The answer is Yes. But it may not be an arbitary one. I don't think it matters it is temperary or not for stateless sb. When a client calls on a remote interface, you can imagine it is like a RMI call, at the client side the EJBObject is like a stub, at the serverside the EJBObject is like skelleton. But these are one possible implmentation details. As far as EJB spec concerned, EJBObject is the Proxy for client interact with ejb or as ejb spec put it "client view" of the ejb.

[Reid M. Pinchback]

I think that Jack is saying that the javadoc suggests that SessionContext.getEJBObject returns you the same object that a remote client is accessing. In general the spec materials are written from the standpoint of SFSB, with a few "oh and by the way here is requirement in the case of a SLSB" caveats thrown in. I suspect that the javadoc reflects this tendency to discuss session beans from the standpoint of SFSB.
I'm saying that for a SLSB that it would be wierd to require such a correspondence when you are in ejbCreate, and the spec guarantees you can get an EJBObject while within ejbCreate on a SLSB. Besides, I don't see why it is computationally necessary for it to be the same object in the case of a SLSB. Remember that EJBObject.isIdentical is *always* true for SLSB. All session beans are considered equivalent to the container for a SLSB. Given that a remote client is, well, remote, it isn't like you'd *ever* be in a position to compare the reference you have in your bean to the reference that is used as the server-side skeleton to service client method calls. I suspect that the container is perfectly free to create any old EJBObject for the bean to use, but *only* in the case of SLSB. Basically you are saying "gee, I have a client, and the client is me".
[ March 03, 2004: Message edited by: Reid M. Pinchback ]

[Phanindra Nayani]

Thankyou Guys !!!

[Sudhir V]

This question already appeared once and the author kathy's reply is:
https://coderanch.com/t/158485/java-EJB-SCBCD/certification/beanness-stateless-session-bean