EJB有哪幾種類型(Bean)
阿新 • • 發佈：2019-01-25
EJB 依照特性的不同，目前區分為三種，分別是 Session Bean ，Entity Bean ，以及 Message Driven Bean 。其中 Session Bean 與Entity Bean 算是 EJB 的始祖，這兩種 EJB 在 EJB 規格 1.x 的時候就已經存在了，而 Message Driven Bean 則出現在 EJB 2.0 的規格中。
Session Bean
Session Bean 主要的目的是讓程式開發者將邏輯層抽離，特別是複雜的邏輯可以放在 Session Bean 中。 Session Bean 還可以再細分為Stateful Session Bean 與 Stateless Session Bean ，這兩種的 Session Bean都可以將系統邏輯放在 method 之中執行，不同的是 Stateful Session Bean 可以記錄呼叫者的狀態，因此通常來說，一個使用者會有一個相對應的 Stateful Session Bean 的實體 (Instance 注一 ) ，換言之，當使用者呼叫某個 Stateful Session Bean 的兩個 methods 的時候，EJB Container( 注一 ) 會清楚的知道某個 EJB 的實體屬於某一個使用者的。因此一般的設計上，不會讓兩個使用者同時使用某個 Stateful Session Bean ( 這並不是表示兩個使用者不能使用同一個 Stateful Session Bean) 。
Stateless Session Bean 雖然也是邏輯元件，但是他卻不負責記錄使用者狀態，也就是說當使用者呼叫 Stateless Session Bean 的時候，EJB Container 並不會找尋特定的 Stateless Session Bean 的實體來執行這個 method ，換言之，很可能數個使用者在執行某個 Stateless Session Bean 的 methods 時，會是同一個 Bean 的 Instance 在執行。
從記憶體方面來看， Stateful Session Bean 與 Stateless Session Bean 比較， Stateful Session Bean 會消耗 J2EE Server 較多的記憶體，然而 Stateful Session Bean 的優勢卻在於他可以維持使用者的狀態。
Entity Bean
Entity Bean 主要是資料元件， Entity Bean 主要的目的，在於提供資料，也就是說程式設計師可以將 Entity Bean 當程式資料，至於 Entity Bean 實際上怎麼存取實際上的
Entity Bean 實際上是針對 RDBMS 而設計，也就是說當其它的程式使用 Entity Bean 的時候， Entity Bean 的資料主要是從 RDBMS 而來，當然，如果程式設計師熟悉 Entity Bean 的運作，那麼也可以很輕易的把RDBMS 用其它的資料庫取代，像是 LDAP 。
Entity Bean 主要區分為 Bean-Managed Persistence 以及 Container-Managed Persistence ( 簡稱 BMP 及 CMP) ，這兩種 Entity Bean 的型態不同，但是目的相同，都在於提供資料！這兩種 Entity Bean 主要的差別在於維護資料的角色， BMP 是由 Bean 自行維護資料的一致性，而 CMP 則是由 EJB Container 來維護。一個 Entity Bean 往往代表一張RDBMS 的表格，這個表格內的一筆一筆的資料，則是透過另外一個叫做 Primary Key( 注三 ) 的 Class 來加以區分。
Bean-Managed Persistence
當我們說 BMP 是由 Bean 自行維護資料的一致時，有些人會覺得太過於抽象，簡單一點來說，原來的資料均由資料庫而來，而當資料從資料庫中取出之後，在 BMP 中需要自行宣告欄位來存放這些資料，同時也要自行撰寫相關的程式程式碼，包括相關的 JDBC 語法等等。
Container-Managed Persistence
CMP 是比較高階的 Entity Bean ，比較高階的意思是說，撰寫 CMP 的程式設計師並不需要撰寫大多數的 JDBC 語法，只需要透過一些定義，即可產生 CMP ，實際上的 EJB 的程式程式碼則是 EJB Container 依據相關的 Deployment Description ( 注四 ) 在部署（注五） EJB 的時候產生。
BMP 與 CMP 的型態不同，適用的場合也不同，主要的差異在於如果我們想要自行控制所有的動作，那麼應該使用 BMP ， BMP 允許程式設計師完全的控制 BMP 的資料存取行為，而 CMP 很適合快速開發，但是由於要支援 CMP 的 J2EE Server 需要較高的技術，因此每一家對於CMP 的支援程度也不大相同。
此外，資料庫中有一個很重要的關係是 OR Mapping ，也就是常聽到的一對一，一對多，多對多這種關係，在 EJB 1.x 的規格中，這種一對多的對應關係只有兩種方式可以做出，一種是透過 Session Bean 來存取多個 Entity Bean ，另外一種則是透過 BMP 來控制另外數個 BMP 或是CMP ，但是在 EJB 2.0 的規格中，已經可以透過純粹的 CMP 配合EJB-QL( 注六 ) 語法來做出這種對應關係，這也是 EJB 2.0 的一大特色。
Message Driven Bean Message Driven Bean 與 Session Bean 或是 Entity Bean 均不相同，一般 Session Bean 或是 Entity Bean 都可以讓使用者主動觸發（可以在需要的時候，呼叫他們的 method 來觸發他們），但是 Message Driven Bean 主要的目的在於反應 Message Queue 中的事件。
也就是當 Message Queue 中有訊息傳入時， Message Driven Bean 可以主動被觸發，做出相對應的反應。因此如果說 Session Bean 與 Entity Bean 是同步模式的 EJB ( 使用者呼叫某個 Method ，就只能等 EJB 響應之後才能進行下一步 ) ，那麼 Message Driven Bean 就可以當成是專門處理非同步資料格式的 EJB ，也就是說程式設計師將某個訊息丟入 Message Queue 之後，就繼續執行下去，另外一方面， Message Driven Bean 會受到通知，知道有某個訊息需要處理，這時候他會自行運作。因此 Message Driven Bean 並不是直接給使用者呼叫的，而是透過 MessageQueue 來觸發。
有狀態會話bean ：每個使用者有自己特有的一個例項，在使用者的生存期內，bean保持了使用者的資訊，即“有狀態”；一旦使用者滅亡（呼叫結束或例項結束），bean的生命期也告結束。即每個使用者最初都會得到一個初始的bean。
有狀態session bean生命週期
1. 當客戶呼叫create(args)時，容器呼叫newInstance()方法，剩下來的建立過程同無狀態session bean。
2. 有狀態session bean的方法執行分為事務與非事務兩種情況
a. 不包含事務的方法在該bean處於ready狀態後就可以執行
b. 包含事務的方法執行就比較複雜：
客戶呼叫事務方法-->容器呼叫afterBegin()
客戶提交方法-->容器呼叫beforeCompletion()
事務嘗試提交，提交結果可能會成功，也可能會滾事務
事務結束-->容器呼叫afterCompletion()
Session Bean
Session Bean 主要的目的是讓程式開發者將邏輯層抽離，特別是複雜的邏輯可以放在 Session Bean 中。 Session Bean 還可以再細分為Stateful Session Bean 與 Stateless Session Bean ，這兩種的 Session Bean都可以將系統邏輯放在 method 之中執行，不同的是 Stateful Session Bean 可以記錄呼叫者的狀態，因此通常來說，一個使用者會有一個相對應的 Stateful Session Bean 的實體 (Instance 注一 ) ，換言之，當使用者呼叫某個 Stateful Session Bean 的兩個 methods 的時候，EJB Container( 注一 ) 會清楚的知道某個 EJB 的實體屬於某一個使用者的。因此一般的設計上，不會讓兩個使用者同時使用某個 Stateful Session Bean ( 這並不是表示兩個使用者不能使用同一個 Stateful Session Bean) 。
Stateless Session Bean 雖然也是邏輯元件，但是他卻不負責記錄使用者狀態，也就是說當使用者呼叫 Stateless Session Bean 的時候，EJB Container 並不會找尋特定的 Stateless Session Bean 的實體來執行這個 method ，換言之，很可能數個使用者在執行某個 Stateless Session Bean 的 methods 時，會是同一個 Bean 的 Instance 在執行。
從記憶體方面來看， Stateful Session Bean 與 Stateless Session Bean 比較， Stateful Session Bean 會消耗 J2EE Server 較多的記憶體，然而 Stateful Session Bean 的優勢卻在於他可以維持使用者的狀態。
Entity Bean
Entity Bean 主要是資料元件， Entity Bean 主要的目的，在於提供資料，也就是說程式設計師可以將 Entity Bean 當程式資料，至於 Entity Bean 實際上怎麼存取實際上的
Entity Bean 實際上是針對 RDBMS 而設計，也就是說當其它的程式使用 Entity Bean 的時候， Entity Bean 的資料主要是從 RDBMS 而來，當然，如果程式設計師熟悉 Entity Bean 的運作，那麼也可以很輕易的把RDBMS 用其它的資料庫取代，像是 LDAP 。
Entity Bean 主要區分為 Bean-Managed Persistence 以及 Container-Managed Persistence ( 簡稱 BMP 及 CMP) ，這兩種 Entity Bean 的型態不同，但是目的相同，都在於提供資料！這兩種 Entity Bean 主要的差別在於維護資料的角色， BMP 是由 Bean 自行維護資料的一致性，而 CMP 則是由 EJB Container 來維護。一個 Entity Bean 往往代表一張RDBMS 的表格，這個表格內的一筆一筆的資料，則是透過另外一個叫做 Primary Key( 注三 ) 的 Class 來加以區分。
Bean-Managed Persistence
當我們說 BMP 是由 Bean 自行維護資料的一致時，有些人會覺得太過於抽象，簡單一點來說，原來的資料均由資料庫而來，而當資料從資料庫中取出之後，在 BMP 中需要自行宣告欄位來存放這些資料，同時也要自行撰寫相關的程式程式碼，包括相關的 JDBC 語法等等。
Container-Managed Persistence
CMP 是比較高階的 Entity Bean ，比較高階的意思是說，撰寫 CMP 的程式設計師並不需要撰寫大多數的 JDBC 語法，只需要透過一些定義，即可產生 CMP ，實際上的 EJB 的程式程式碼則是 EJB Container 依據相關的 Deployment Description ( 注四 ) 在部署（注五） EJB 的時候產生。
BMP 與 CMP 的型態不同，適用的場合也不同，主要的差異在於如果我們想要自行控制所有的動作，那麼應該使用 BMP ， BMP 允許程式設計師完全的控制 BMP 的資料存取行為，而 CMP 很適合快速開發，但是由於要支援 CMP 的 J2EE Server 需要較高的技術，因此每一家對於CMP 的支援程度也不大相同。
此外，資料庫中有一個很重要的關係是 OR Mapping ，也就是常聽到的一對一，一對多，多對多這種關係，在 EJB 1.x 的規格中，這種一對多的對應關係只有兩種方式可以做出，一種是透過 Session Bean 來存取多個 Entity Bean ，另外一種則是透過 BMP 來控制另外數個 BMP 或是CMP ，但是在 EJB 2.0 的規格中，已經可以透過純粹的 CMP 配合EJB-QL( 注六 ) 語法來做出這種對應關係，這也是 EJB 2.0 的一大特色。
Message Driven Bean Message Driven Bean 與 Session Bean 或是 Entity Bean 均不相同，一般 Session Bean 或是 Entity Bean 都可以讓使用者主動觸發（可以在需要的時候，呼叫他們的 method 來觸發他們），但是 Message Driven Bean 主要的目的在於反應 Message Queue 中的事件。
也就是當 Message Queue 中有訊息傳入時， Message Driven Bean 可以主動被觸發，做出相對應的反應。因此如果說 Session Bean 與 Entity Bean 是同步模式的 EJB ( 使用者呼叫某個 Method ，就只能等 EJB 響應之後才能進行下一步 ) ，那麼 Message Driven Bean 就可以當成是專門處理非同步資料格式的 EJB ，也就是說程式設計師將某個訊息丟入 Message Queue 之後，就繼續執行下去，另外一方面， Message Driven Bean 會受到通知，知道有某個訊息需要處理，這時候他會自行運作。因此 Message Driven Bean 並不是直接給使用者呼叫的，而是透過 MessageQueue 來觸發。
有狀態會話bean ：每個使用者有自己特有的一個例項，在使用者的生存期內，bean保持了使用者的資訊，即“有狀態”；一旦使用者滅亡（呼叫結束或例項結束），bean的生命期也告結束。即每個使用者最初都會得到一個初始的bean。
有狀態session bean生命週期
1. 當客戶呼叫create(args)時，容器呼叫newInstance()方法，剩下來的建立過程同無狀態session bean。
2. 有狀態session bean的方法執行分為事務與非事務兩種情況
a. 不包含事務的方法在該bean處於ready狀態後就可以執行
b. 包含事務的方法執行就比較複雜：
客戶呼叫事務方法-->容器呼叫afterBegin()
客戶提交方法-->容器呼叫beforeCompletion()
事務嘗試提交，提交結果可能會成功，也可能會滾事務
事務結束-->容器呼叫afterCompletion()