Well, I'm afraid I can't answer it because I don't have inside knowledge of any particular vendor's implementation. Remember that the specification does not really define this process at all... in fact, the lifecycle and OID diagrams are meant to be a *conceptual* picture of how it works, and not, according to the spec, "prescriptive." In other words, the Container doesn't necessarily create the objects in the way that it's shown in the diagrams. The only thing the Container must do is BEHAVE as if that's how it works.
For example, the Container might give each and every client a reference to the SAME remote service, and the stub carries enough information for the service to simply route it to the Container where the Container then lays the services in and invokes (if and when it is appropriate) the bean's method. So, there might not even *be* a real instance representing an EJB
object. When the bean calls getEJBObject() on its context, the bean is getting back *something* that implements the EJBObject interface, but you have no idea what or how that implementation exists in the Container.
And of course it will be different depending on whether the bean is stateful or stateless. So the question of what really happens to make that link is not a question that can be answered in the spec-- it can be answered only by a vendor who tells you how they chose to do it. From the Bean Provider's perspective, you have to know that it is guaranteed to BEHAVE in a particular way, as if it DID look just like the pictures in the spec (or in our book, for that matter), with all the objects floating around in the Container just as they are in the pictures, but what is inside the Container might look very, very different.
All I'm concerned with is that I KNOW, for example, that within my ejbCreate() method (for a session bean but NOT an entity bean) I am allowed to call getEJBObject() on my context, and *something* that implements that interface will be returned. And that the EJBObject implementation I get back can be passed to others as part of an argument or return, and that a remote stub (or something that functions as the stub) will be substituted, and that *whatever* that stub is, it can be used to invoke the component interface methods.
So, I did a lousy job of answering your question
, but as far as the spec and exam goes, this is all we can ever know about it. If you want more details, you'll have to get vendor-specific info, which of course could (and usually is) wildly different from Container to Container, and even within different versions of the same vendor's product.