EJB

?Enterprise JavaBean,企業級javabean,是J2EE的一部分，定義了一個用于 ? 開發基于組件的企業多重應用程序的標準。其特點包括網絡服務支持和核心開發工具(SDK)。 是Java的核心代碼，分別是會話Bean（Session Bean），實體Bean（Entity Bean）和消息驅動Bean（MessageDriven Bean）。
會話Bean是為了完成業務邏輯, ?實體Bean是為了完成數據/映射, ?消息驅動Bean是為了完成消息發送. ? 有點像SSH.都是框架性的東西。

Enterprise JavaBean(EJB)是一種服務器端組件體系結構，它簡化了Java開發企業級的分布式組件應用程序的過程。通過EJB，我們能寫出可擴展的、健壯的和安全的應用程序，而不用自己去寫復雜的分布式組件框架，EJB 開發服務器端應用程序，通過利用由業界提供的預先寫好的分布式基礎結構，我們可以快速而且輕松地利用Java構建服務器端組件



EJB是sun的服務器端組件模型，最大的用處是部署分布式應用程序，類似微軟的.com技術。憑借java跨平臺的優勢，用EJB技術部署的分布式系統可以不限于特定的平臺。

　　EJB (Enterprise JavaBean)是J2EE的一部分，定義了一個用于開發基于組件的企業多重應用程序的標準。其特點包括網絡服務支持和核心開發工具(SDK)。

　　在J2EE里，Enterprise Java Beans(EJB)稱為Java 企業Bean，是Java的核心代碼，分別是會話Bean（Session Bean），實體Bean（Entity Bean）和消息驅動Bean（MessageDriven Bean）。

　　1.Session Bean用于實現業務邏輯，它可以是有狀態的，也可以是無狀態的。每當客戶端請求時，容器就會選擇一個Session Bean來為客戶端服務。Session Bean可以直接訪問數據庫，但更多時候，它會通過Entity Bean實現數據訪問。

　　2.Entity Bean是域模型對象，用于實現O/R映射，負責將數據庫中的表記錄映射為內存中的Entity對象，事實上，創建一個Entity Bean對象相當于新建一條記錄，刪除一個Entity Bean會同時從數據庫中刪除對應記錄，修改一個Entity Bean時，容器會自動將Entity Bean的狀態和數據庫同步。

　　3.MessageDriven Bean是EJB2.0中引入的新的企業Bean，它基于JMS消息，只能接收客戶端發送的JMS消息然后處理。MDB實際上是一個異步的無狀態Session Bean，客戶端調用MDB后無需等待，立刻返回，MDB將異步處理客戶請求。這適合于需要異步處理請求的場合，比如訂單處理，這樣就能避免客戶端長時間的等待一個方法調用直到返回結果。

　　EJB實際上是SUN的J2EE中的一套規范,并且規定了一系列的API用來實現把EJB概念轉換成EJB產品.EJB是BEANS,BEANS是什么概念,那就是得有一個容納她,讓她可勁造騰的地方,就是得有容器.EJB必須生存在EJB容器中.這個容器可是功能強大之極!她首先要包裝你BEAN, EJB的客戶程序實際上從來就不和你編寫的EJB直接打交道,他們之間是通過HOME/REMOTE接口來發生關系的.它負責你的BEAN的所有的吃喝拉薩睡,比如BEAN的持續化,安全性,事務管理...

　　一.什么是 EJB?

　　一個技術規范：EJB 從技術上而言不是一種"產品"
　　EJB 是一種標準描述了構建應用組件要解決的:
　　可擴展 (Scalable)
　　分布式 (Distributed)
　　事務處理 (Transactional)
　　數據存儲 (Persistent)
　　安全性 (Secure)

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就找到了。

?

?

?