Friday, March 8, 2002 06:08 AM
there are no purely technical reasons. It is only a matter of semantics.
The rmote interface extends the EJBObject interface, which contains methods designed for manipulating the EJB object itself, and have nothing to do with the bean instance referenced by the EJB object. These methods are for the container to implement, not for you.
But again, nothing prevents you for stubbing them just to stop the compilation errors. The reason you are refering to has to do with type safety. Making sure that there is structural difference between the EJB and the bean prevents a newbe (or otherwise confused EJB programmer) from passing one instead of the other. For all intent and purposes, the world only knows of the EJB. However, you as a programmer know that it is an artifact created by a server and wrapped around a bean class. So these error messages at compile time are your last safety against accidentally passing a reference to the bean class instead of a reference to the EJB wrapper. Self discipline is sometimes hard enough, so why refuse the help of the compiler...
btw, the problem is not when a bean passes a reference to its EJB object (that IS the desired behavior), but when the been passes a reference to itself directly (which the compiler won't complain about if the bean implements its own remote interface). think about it this way: the EJB container is very nosy, and NEEDS/WANTS to know everything that's happening to your bean. But it can oonly do that if the EJB is involved in the dialog, instead of the bean directly