Hi there
This issue drives almost EVERYONE crazy at first. There are two things you might want to keep in mind here:
1) The diagrams in the spec (and in HFEJB) are a way to *conceptually* think about what it happening, but they do not represent exactly what is happening inside. As long as the system behaves according to the spec, the vendor can do whatever it wants... the Container can have an implementation that looks very different from the diagrams (in terms of what is instantiated and when) but it must BEHAVE as though it matches the pictures.
2) So... if the Container is required to return *something* to the SLSB in ejbCreate(), that represents the bean's EJBObject, then that is what happens. Even though it *appears* that the EJBObject is not actually created until *after* there is a client. So it DOES look like a contradiction -- the bean might be created BEFORE there's a client, yet the EJBObject is not created until AFTER there is a client request... but then how does the bean get a reference to an EJBObject during ejbCreate()??? Yes, it looks like a contradiction. And the answer is...
The Container is required to give SOMETHING to the bean, during ejbCreate(), as a result of calling getEJBObject(), that implements the bean's component interface. For all we are to know, the Container gives ALL SLSB's a reference to the very same object. As others have mentioned, since all SLSBs are the same, it really doesn't matter. As long as the SLSB is connected to something that knows how to return the method return value to the correct client (i.e. the client that invoked the business method) then we don't really care how that happens.
Again, the answer is: the Container is required by the spec to do this, even though it appears contradictory according to the lifecycle. That's the Container's problem... something the vendor has to deal with it, while WE get to enjoy the fact that while inside ejbCreate(), WE can get a reference to our EJBObject.
And why is it important that we be able to get a reference to our EJBObject? Well, one reason could be because the bean, as part of its own internal initialization during ejbCreate(), might need to pass a reference to itself to some *other* object, and this is the bean's only chance to do that. In fact, this is why Entity beans have an ejbPostCreate()... so that they, too, have a chance to get a reference to their own EJBObject as part of the Entity bean's initialization process (and since Entity bean's can't get a reference to their EJBObject during ejbCreate(), the lifecycle includes a follow-up "part two" call -- ejbPostCreate() to give the Entity bean a chance to finish its initialization, especially if that initialization requires that the Entity bean get a reference to its EJBObject). Yes, there IS another reason why ejbPostCreate() matters now, because of CMR fields, but that is new to EJB 2.0 -- the original motivation for the ejbPostCreate() method was so that Entity beans could get a reference to their own EJBObjects during creation.
cheers,
Kathy