Howdy,
Amin, this one used to bother me too... for exactly the same reason. But the best way to think about it is that for a *stateLESS* bean, the
EJB object is not tied to a particular bean anyway, so the Container can do whatever it wants to make it work. For example, if you have a stateless bean, and it wants to give a reference to itself to someone else, inside its ejbCreate() method, it can ask for a reference to its EJB object. But... we don't see the EJB object being made yet? That doesn't matter, because the bean isn't *really* tied to a particular EJB object, since each stateless bean is the same as the rest, and each EJB object for a stateless bean is the same as the rest. So a stateless bean just needs a reference to *something* that acts as "an EJB object for any stateless bean of this type."
Again, if I give someone a reference to my EJB object, and I'm a stateless bean, I'm not REALLY giving them a reference to ME -- this exact stateless bean. Instead, I'm giving them a *generic* EJB object reference that will work for ANY bean of that type.
I guess the real answer is "don't worry about it -- the Container takes care of making it work." And that's all we know. It's up to the Container to implement it any way that they want. Remember that the diagrams in the spec are merely "examples of how it MIGHT be implemented" but they do not represent the actual way that it MUST be implemented. The diagrams are more *conceptual* -- giving you a way to THINK about it, even if behind the scenes the Container is doing something very different. The only thing you care about is that the Container is required to make it BEHAVE as though things are implemented exactly as they are shown in the diagram. But how many real objects, and of which type, are actually created is a completely different story...
cheers,
Kathy