ejb一直是一個讓我很糾結的技術，雖然ejb作為sun推薦的最佳實踐，在sun的J2EE教程中，推薦jsp和servlet作為view層，ejb作為業務邏輯層。
上述就是J2EE教程講J2EE體系中J2EE的EJB示意圖了，講了EJB的位置，詳情可以看:http://docs.oracle.com/javaee/1.4/tutorial/doc/
然而我所接觸使用ejb開發的程序員(都是國內)，用了ejb，都沒什么特別好感，甚至我以前的項目經理說，很多人被sun給欺騙了。
目前ejb已經出到了3.x了，然而國內已經幾乎沒有使用ejb3.x，有的也是ejb2.x，都是老系統遺留，有的是銀行項目，有的是erp項目(都是大型項目)。
之前jboss出名就是因為它支持ejb，並且支持得最好，然而現在隨着ejb的使用份額下降，這幾年jboss在國內的使用份額也下降了，用tomcat和其他開源服務器多了很多。
我也很少用ejb，在開發中根本不用，除非是以前為了支持一些老系統，才會接觸，而且為了應付ejb的，學了ejb3.0，但是遇到的項目全部是ejb2.x，ejb3.0相比ejb2.0，簡單了很多，不想ejb2.0那么繁瑣，為了一個業務邏輯類，要寫業務接口類，home類啥啥的，我覺得進步很大，但是在國內依然沒什么人使用。
這里就談一下我對ejb的一些看法:
1.ejb是比較重量級:實現ejb是一件很復雜的事情，J2EE規范中ejb規范的實現是一塊硬骨頭，而ejb實在復雜，很多開發人員都喜歡簡單的東西，復雜的東西，會帶來未知風險。
2.ejb的移植性低:雖然ejb是遵循J2EE規范的，但是各個廠家在實現J2EE EJB的規范的同時，也會加入自己的一些實現，例如你要讓一個EJB查找一個數據源，這個數據源如何配置，幾乎所有的應用服務器廠商都不一樣,weblogic，websphere，jboss，apusic都有自己的一套實現方式。我每次想到移植ejb的應用，最怕是去找這些不同點，然后一一修改相應配置。這無疑加大了開發人員的負擔，java的東西，平台可移植性就是一大亮點。
3.ejb調用流程:ejb是支持遠程調用，客戶端值需要ejb的業務類接口，服務端值需要ejb的業務類實現，然后客戶端只需要調用jndi(這個規范實現很復雜，使用比較簡單,還是很多人用)的lookup方法，就可以使用業務類接口直接調用服務端實現類的方法了，這中間，應用服務器做了很多處理,基本流程都是:客戶端通過jndi和業務類接口，調用對應ejb應用服務器廠商jndi的lookup服務端實現類方法，然后ejb應用服務器生成業務類的存根和代理，存根從服務端序列化到客戶端，客戶端調用的ejb業務接口就是調用這個存根，然后這個存根又通過rmi協議或者iiop協議發送命令到業務類的代理，代理再調用業務類實現，最終把執行結果返回到客戶端。
3.ejb難以調試:看到ejb的調用流程，雖然看上去ejb讓用戶不用了解遠程調用細節，使用簡單，但是由於里面的調用過程復雜，一旦有一個環節錯了，用戶都難以調試，排錯，開發過程中出現問題不可避免，而解決ejb的問題，解決周期要比較久。出錯的時候，錯誤信息也千奇百怪。
4.ejb的性能問題:ejb的調用涉及太多類的序列化和反序列化，本來通過網絡傳輸已經很慢了，還要傳遞對象，數據量又更大了，還要涉及了對象的序列化和反序列化，這中間有太多的開銷了。
5.ejb的替換開源產品太多了:現在業務邏輯，在java上要用框架的有spring，遠程調用，有webservice(apache cxf已經做得很好了，而且webservice又是通用標准)，mina(一個apache的NIO框架)，netty(現在性能最快的NIO框架，來自jboss).而且這些產品都是可移植，社區交流多，出了問題，google就找到了。