I know that EJB is very closely following the RMI paradigm. If you see RMI alone, we would create stub and skeleton by rmic, keep stub on client side and skeleton on server side.
But in EJB, I don't see that we are not doing anything like this. The underlying idea is that the client should call the local (stub) class and that will talk to remote (skelton) class and invoke the actual object methods. But in EJB, where are we copying the stubs and skeltons? At least, I know, that we are not copying anything on the client side. So, how does this work then?
While EJB conatiner starts it deploys ur application and at that time it runs ejbc ,which genrates the stubs and skeleton for the same.
I hope this answers your question
Joined: Feb 13, 2003
You are right. ejbc is called.
But the generated stubs and skeletons would still be in the container. These are not avaibale to the client. How does a client which sits far apart from the server gets this generated stub? Is a physical copy needed?
Guru, We would be specifying a client jar file location in the EJB's deployment descriptor with a tag <ejb-client-jar> </ejb-client-jar> which is optional. If the EJB client (Servlet, JSP etc) & the EJB runs in the same JVM (same server instance), then there is no need for this client jar to be made available explicitly, because they will have a common classpath.
But if you have your EJB client running in a different machine, then you should copy all the required classes like Stub's etc in your EJB client location like what you do in RMI.
Usually, you would have all the Implementaion classes and Stubs (Both generated by Container Provider Tools) package along with Home & Remote interfaces to form a client jar file. Then this JAR would be included in the classpath of your EJB.
And if there are any external clients for the EJB, then this JAR can be used that provides the necessary classes.
To conclude, Yes we need to physically copy the necessary classes.