一个远程对象至少要包括4个class文件：远程对象；远程对象的接口；实现远程接口的对象的stub；对象的skeleton这4个class文件。

在ejb中则至少要包括10个class：

bean类，特定app server的bean实现类，bean的remote接口，特定app server的remote接口实现类，特定app server的remote接口的实现类的stub类和skeleton类。

bean的home接口，特定app server的home接口实现类，特定app server的home接口的实现类的stub类和skeleton类和rmi不同的是，ejb中这10个class真正需要用户编写的只有3个，分别是bean类和它的remote接口，home接口，至于其它的7个class到底是怎么生成，被打包在什么地方，或者是否需要更多的类文件，会根据不同的app server表现出比较大的差异，不能一概而论。

拿我最熟悉的weblogic的来说吧，weblogic的bean实现类，以及两个接口的weblogic的实现类是在ejbc的时候被打包到ejb的jar包里面的，这3个class文件可以看到。而home接口和remote接口的weblogic的实现类的stub类和skeleton类是在ejb被部署到weblogic的时候，由weblogic动态生成stub类和skeleton类的字节码，因此看不到这4个类文件。

对于一次客户端远程调用ejb，要经过两个远程对象的多次rmi循环。首先是通过jndi查找home接口，获得home接口的实现类，这个过程其实相当复杂。

首先是找到home接口的weblogic实现类，然后创建一个home接口的weblogic实现类的stub类的对象实例，将它序列化传送给客户端（注意stub类的实例是在第1次rmi循环中，由服务器动态发送给客户端的，因此不需要客户端保存home接口的weblogic实现类的stub类），最后客户端获得该stub类的对象实例（普通的rmi需要在客户端保存stub类，而ejb不需要，因为服务器会把stub类的对象实例发送给客户端）。

客户端拿到服务器给它的home接口的weblogic实现类的stub类对象实例以后，调用stub类的create方法，(在代码上就是home.create()，但是后台要做很多事情),于是经过第2次rmi循环，在服务器端，home接口的weblogic实现类的skeleton类收到stub类的调用信息后，由它再去调用home接口的weblogic实现类的create方法。

在服务端，home接口的weblogic实现类的create方法再去调用bean类的weblogic实现类的ejbcreate方法，在服务端创建或者分配一个ejb实例，然后将这个ejb实例的远程接口的weblogic实现类的stub类对象实例序列化发送给客户端