了不起的工作！
不辭辛勞，詳盡明白。

一定會好好學習的！

另外，有沒有可能分析一下，這樣的工作方式的“所以然”。或者說“不得不然”。再或者有沒有“其他的實現(xiàn)方式”。

簡單講，就是為了適應分布式開發(fā)的需要。

首先，回到我最后給出的流程圖。

Client端最原始的沖動，肯定是能直接調用#10.UserServiceBean就爽了。那么第一個問題來了，
Client和Server不在一個JVM里。

這好辦，我們不是有RMI嗎，好，這個問題就這么解決了：
1. UserServiceBeanInterface.getUserInfo()
2. UserServiceBeanStub
3. UserServiceBeanSkeleton
4. UserServiceBean

用著用著，第二個問題來了，
UserServiceBean只有人用，沒人管理，transaction logic, security logic, bean instance pooling logic這些不得不考慮的問題浮出水面了。

OK，我們想到用一個delegate，EJBObject，來進行所有這些logic的管理。client和EJBObject打交道，EJBObject調用UserServiceBean。

注意，這個EJBObject也是一個Interface，#6.UserService這個interface正是從它extends而來。并且EJBObject所管理的這些logic，正是AppServer的一部分。

現(xiàn)在的流程變?yōu)榱耍?
EJBObject
1. UserService.getUserInfo()
2. UserServiceStub
3. UserServiceSkeleton
4. UserServiceImp
5. UserServiceBean

這已經(jīng)和整幅圖里的#6, #7, #8, #9, #10一一對應了。

現(xiàn)在能滿足我們的需求了嗎？不，第三個問題又來了：
既然是分布式開發(fā)，那么我當然沒理由只用一個Specified Server，我可能需要用到好幾個不同的Server，而且EJBObject也需要管理呀

OK，為了適應你的需要，我們還得加再一個HomeObject，首先它來決定用哪個Server(當然，是由你用JNDI String設定的)，其次，它來管理EJBObject。

注意，這個EJBHome也是一個Interface，#1.UserServiceHome這個interface正是從它extends而來。并且EJBHome管理EJBObject的logic，也是AppServer的一部分。

現(xiàn)在的調用次序是
1. EJBHome.create()
2. EJBHomeStub
3. EJBHomeSkeleton
4. EJBHomeImp(EJSWrapper)
5. EJSHome

得到EJBObject

6. UserService.getUserInfo()
7. UserServiceStub
8. UserServiceSkeleton
9. UserServiceImp
10. UserServiceBean

現(xiàn)在已經(jīng)完全和流程圖的調用順序一致了。

綜上所述，EJB的調用確實很麻煩，但是搞的這么麻煩，確實是有搞的麻煩的道理，實在是不得不為也。