robbin寫的EJB調用的原理分析

一個遠程對象至少要包括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類對象執行個體序列化發送給用戶端。 用戶端收到remote介面的Weblogic實作類別的stub類的對象執行個體，對該對象執行個體的方法調用（在用戶端代碼中實際上就是對remote介面的調用），將傳送給伺服器端remote介面的Weblogic實作類別的skeleton類對象，而skeleton類對象再調用相應的remote介面的Weblogic實作類別，然後remote介面的Weblogic實作類別再去調用Bean類的Weblogic實作類別，如此就完成一次EJB對象的遠程調用。 看了一遍文章，感覺還是沒有說太清楚，既然寫了文章，就想徹底把它說清楚。 先拿普通RMI來說，有4個class，分別是遠程對象，對象的介面，對象的stub類和skeleton類。而對象本身和對象的stub類同時都實現了介面類。而我們在用戶端代碼調用遠程對象的時候，雖然在代碼中操縱介面，實質上是在操縱stub類，例如： 介面類：Hello 遠程對象：Hello_Server stub類：Hello_Stub skeleton類：Hello_Skeleton 用戶端代碼要這樣寫： Hello h = new Hello_Stub(); h.getString(); 我們不會這些寫： Hello_Stub h = new Hello_Stub(); h.getString(); 因為使用介面適用性更廣，就算更換了介面實作類別，也不需要更改代碼。因此用戶端需要Hello.class和Hello_Stub.class這兩個檔案。但是對於EJB來說，就不需要Hello_Stub.class，因為伺服器會發送給它，但是Hello.class檔案用戶端是省不了的，必須有。表面上我們的用戶端代碼在操縱Hello，但別忘記了Hello只是一個介面，抽象的，實質上是在操縱Hello_Stub。 拿Weblogic上的EJB舉例子，10個class分別是： Bean類：HelloBean （使用者編寫） Bean類的Weblogic實作類別：HelloBean_Impl （EJBC產生） Home介面：HelloHome （使用者編寫） Home介面的Weblogic實作類別 HelloBean_HomeImpl（EJBC產生） Home介面的Weblogic實作類別的stub類 HelloBean_HomeImpl_WLStub（部署的時候動態產生位元組碼） Home介面的Weblogic實作類別的skeleton類 HelloBean_HomeImpl_WLSkeleton（部署的時候動態產生位元組碼） Remote介面： Hello （使用者編寫） Remote介面的Weblogic實作類別 HelloBean_EOImpl（EJBC產生） Remote介面的Weblogic實作類別的stub類 HelloBean_EOImpl_WLStub（部署的時候動態產生位元組碼） Remote介面的Weblogic實作類別的skeleton類 HelloBean_EOImpl_WLSkeleton（部署的時候動態產生位元組碼） 用戶端只需要Hello.class和HelloHome.class這兩個檔案。 HelloHome home = (Home) PortableRemoteObject.narrow(ctx.lookup("Hello"), HelloHome.class); 這一行代碼是從JNDI獲得Home介面，但是請記住！介面是抽象的，那麼home這個對象到底是什麼類的對象執行個體呢？很簡單，用toString()輸出看一下就明白了，下面一行是輸出結果： HelloBean_HomeImpl_WLStub@18c458 這表明home這個通過從伺服器的JNDI樹上尋找獲得的對象實際上是HelloBean_HomeImpl_WLStub類的一個執行個體。 接下來用戶端代碼： Hello h = home.create() 同樣Hello只是一個抽象的介面，那麼h對象是什麼東西呢？列印一下： HelloBean_EOImpl_WLStub@8fa0d1 原來是HelloBean_EOImpl_WLStub的一個對象執行個體。 用這個例子來簡述一遍EJB調用過程： 首先用戶端JNDI查詢，服務端JNDI樹上Hello這個名字實際上綁定的對象是HelloBean_HomeImpl_WLStub，所以服務端將建立HelloBean_HomeImpl_WLStub的一個對象執行個體，序列化返回給用戶端。 於是用戶端得到home對象，表面上是得到HelloHome介面的執行個體，實際上是進行了一次遠程調用得到了HelloBean_HomeImpl_WLStub類的對象執行個體，別忘記了HelloBean_HomeImpl_WLStub也實現了HelloHome介面。 然後home.create()實質上就是HelloBean_HomeImpl_WLStub.create()，該方法將發送資訊給HelloBean_HomeImpl_WLSkeleton，而HelloBean_HomeImpl_WLSkeleton接受到資訊後，再去調用HelloBean_HomeImpl的create方法，至此完成第1次完整的RMI迴圈。 注意在這次RMI迴圈過程中，遠程對象是HelloBean_HomeImpl，遠程對象的介面是HelloHome，對象的stub是HelloBean_HomeImpl_WLStub，對象的skeleton是HelloBean_HomeImpl_WLSkeleton。 然後HelloBean_HomeImpl再去調用HelloBean_Impl的ejbCreate方法，而HelloBean_Impl的ejbCreate方法將負責建立或者分配一個Bean執行個體，並且建立一個HelloBean_EOImpl_WLStub的對象執行個體。 這一步比較有趣的是，在前一步RMI迴圈中，遠程對象HelloBean_HomeImpl在用戶端有一個代理類HelloBean_HomeImpl_WLStub，但在這一步，HelloBean_HomeImpl自己卻充當了HelloBean_Impl的代理類，只不過HelloBean_HomeImpl不在用戶端，而是在服務端，因此不進行RMI。 然後HelloBean_EOImpl_WLStub的對象執行個體序列化返回給用戶端，這一步也很有趣，上次RMI過程，主角是HelloBean_HomeImpl和它的代理類HelloBean_HomeImpl_WLStub，但這這一次換成了HelloBean_EOImpl和它的代理類HelloBean_EOImpl_WLStub來玩了。 Hello h = home.create();h.helloWorld(); 假設Hello介面有一個helloWorld遠程方法，那麼表面上是在調用Hello介面的helloWorld方法，實際上是在調用HelloBean_EOImpl_WLStub的helloWorld方法。 然後HelloBean_EOImpl_WLStub的helloWorld方法將發送資訊給伺服器上的HelloBean_EOImpl_WLSkeleton，而HelloBean_EOImpl_WLSkeleton收到資訊以後，再去調用HelloBean_EOImpl的helloWorld方法。至此，完成第2次完整的RMI迴圈過程。 在剛才HelloBean_EOImpl是作為遠程對象被調用的，它的代理類是HelloBean_EOImpl_WLStub，但現在HelloBean_EOImpl要作為HelloBean_Impl的代理類了。現在HelloBean_EOImpl去調用HelloBean_Impl的helloWorld方法。注意！HelloBean_Impl繼承了HelloBean，而HelloBean中的helloWorld方法是我們親自編寫的代碼，現在終於調用到了我們編寫的代碼了！ 至此，一次EJB調用過程終於完成。在整個過程中，服務端主要要調用的類是HelloBean_Impl， HelloBean_HomeImpl，HelloBean_HomeImpl_WLSkeleton，HelloBean_EOImpl，HelloBean_EOImpl_WLSkeleton。用戶端主要調用的類是HelloBean_HomeImpl_WLStub，HelloBean_EOImpl_WLStub，這兩個類在用戶端代碼中並不會直接出現，出現在代碼中的類是他們的介面HelloHome和Hello，因此用戶端需要這兩個介面檔案，而Stub是伺服器傳送給他們的。