Hi Gavi,
In the simplest scenario RMI clients need only the home and remote interfaces in order to access the bean. Therefore is required that those two classes to be located in the client�s classpath. If the bean throws application exceptions, or it uses VO/DTO (either as input param or returned args) for transferring data from the server to the client then those classes need to be in the classpath as well. Other type of clients like CORBA/IIOP clients need also special stub classes in order to access the bean over the RMI-IIOP protocol. As you might guess these stubs need to be in the classpath either. However all other classes that the bean itself requires, like the bean�s class or other utility classes and libraries, packed along with the bean, are not required by the clients. Hence it makes sense to subtract client specific classes from the whole package and pack them separately as a client specific functionality. This way the clients will have only the minimal set of classes in order to be able to access the bean. After all why should a standalone client load the bean class if s/he doesn�t need it at all?
If the client is another server component like a
jsp,
servlet or other bean running in a different jvm, then from the bean�s perspective this is just another standalone client and therefore it needs to include all classes required by such a client.
Regards.