EJB - Bean Types

EJB - Bean Types

根據上一篇EJB-簡介所提到，EJB根據beans的功用分成三大類分別是session beans, message-driven beans和entities。

Session Beans

Session bean是為了執行特定商業操作而被client調用，如檢查客戶信用history。Session這個名字意味著bean實例存在時間是“每個工作單位”和當伺服器shutdown或crash的時候就會消失。Session bean可以將任何應用程式邏輯模組化。Session bean有兩類分別為: stateful和stateless。

           Stateful session bean當客戶調用的時候在不需要寫任何多餘的程式碼的狀況下可以自動儲存bean的狀態。比較典型的例子就是網頁商城裡的購物車系統。相反，stateless session bean 不會維護任何狀態和模組應用程式服務。我們可以實作商業流程如信用卡付費或檢查查客戶信用記錄而建立stateless session bean.

           一個session beans不管在本地或遠端都可以透過Java RMI被調用。一個stateless session bean可以公開為網頁服務。

Message-driven Beans

MDBs 就像session beans，都是處理商業邏輯。但MDBs最大的不同是clients永遠不會直接調用MDB method。相反MDBs是透過訊息驅動然後傳給messaging server, 就是在系統元件之間啟動傳送非同步訊息。Messaging servers的典型例子有IBM WebSphere MQ，SonicMQ， Oracle Advance Queueing,和 TIBCO。MDBs通常是使用在系統整合或非同步處理的健全性。上。Messaging的一個例子，從自動零售系統傳送庫存補貨的需求到供應鏈管理系統。

Entities and the Java Persistence API

EJB 3當中其中一個新特色就是處理persistence的方法。之前我們概略的提到persistence 提供者和JPA，現在讓我們更深入到細節。 

         Persistence的能力是將Java objects中包含的data自動儲存到關聯式資料庫像Oracle, SQL Server, DB2。Persistence 在 EJB 3是透過JPA管理。它自動的使用Object-relational mapping(ORM)這項技術persists Java objects。ORM的本質是透過設定檔在java objects處理mapping data然後儲存到資料表中。它緩解我們寫底層，複雜的JDBC程式碼persist objects到資料庫的工作。

           在EJB 3中，persistence provider基本上就是Java Persistence API (JPA)所支援的ORM框架。JPA定義了一些標準：

•  ORM設定metadata的建立mapping entities到 relational tables.
•  EntityManager API – 是一個標準的API在entities執行CRUD persistence operations.
•  Java Persistence Query Language (JPQL)，是用來搜尋和獲取persisted application data.

自從為了Java平台JPA將 ORM frameworks標準化，我們可以在應用程式plug in ORM 產品如 JBOSS Hibernate,OracleTopLink，或BEA Kodo 做為JPA“persistence provider”的底層。

Entities

如果在我們的應用程式採用JPA建立persistence logic，那就必須使用entities. Entities是Java objects用來persisted到資料庫。就像session beans將process模組化，entities將低階應用概念包裝成高階商業流程管理。

The EntityManager

JPA EntityManager介面管理entities和提供persistence 服務。Entities會告訴JPA provider如何map資料庫。EntityManager 介面讀取ORM metadata的entity和執行persistence. EntityManager知道如何對entities在資料庫中執行CRUD（CREATE, RETRIEVE, UPDATE, DELETE）。另外JPA 提供處理lifecycle management，performance tuning，caching和transaction management的能力。

Java Persistence Query Language

JPA 有提供一個類似SQL的語言稱為Java Persistence Query Language (JPQL) 可以搜尋儲存在資料庫中的entities. 在一個健全和彈性的API如JPQL，我們在選擇自動persistence而不是手寫JDBC是不會遺失任何東西。另外，JPA支援native database-specific SQL, 在一些罕有的案件是這是值得使用。

         在這時候，我們應該對EJB各個部分都有部分的認識。我們也知道需要透過EJB container去執行session beans和MDBs 且persistence provider執行entities，那這些元件都能存取EJB 3所提供的服務。

Reference：

1）EJB 3 in action

EJB - 簡介

EJB – 簡介

         EJB 的全名是Enterprise JavaBeans，簡單來說它是一個平台讓開發人員使用Java語言開發一個portable, reusable 和 scalable 的商業應用程式。自EJB推出的時候就一直宣導它是一個元件模組或框架且可以讓我們在開發商業應用程式時不需要重新開發一些服務例如：transactions, security, automated persistence 等等。EJB允許開發人員在開發應用程式時專注在商業邏輯不需要花費時間在建立基礎架構的程式碼。

        在開發人員的觀點來看，EJB只是一段的Java程式碼執行在一個特別的運行環境稱為 EJB container, 且提供大量的component services.

EJB as a Component

        在這每當提到EJBs時，指的是伺服端的components，你可以用它來構建應用程序的某些部分例如：商業邏輯，persistence code. 很多人往往對 components這個詞聯想到開發一個複雜和重量級的CORBA, Microsoft COM+ 程式碼。但在EJB3.0這個嶄新的世界，component 它只是一個不外乎多了一些特別功能的POJO。更重要的是，這些功能在不需要的時候都是“隱形”，不要分散component真正用途上的注意力。

        Component 背後真正的想法是有效率的封裝應用程式的行為。Component的使用者不需要了解內部如何運作。他們只需要知道傳入什麼和回傳什麼。EJB components 有三種：session beans, message-driven beans和entities. Session beans和message-driven beans 是在EJB應用程式實作商業邏輯，而entities則使用在persistence.

        Component 是可以重複使用。假設現在公司開發一個賣書的網站，設計了一個用信用卡過賬的模組只是簡單的Java物件。然後另一組人又在不同的開發環境當中開發了賣CD的網站，這時候因為開發環境的不同所以不能直接套用之前信用卡的模組，另一組人需要將你整個模組複製到他們的網站才能使用，因為沒有更容易的方法可以存取之前的模組。如果是使用EJB components建立的信用卡模組，這會讓新使用者更簡單的重複使用該模組而不需要知道其內部運作（Figure 1）。

Figure 1

EJB as a Framework

        EJB components 是在container中。Components和container可以看成對商業應用程式開發提供有價值服務的框架。

        雖然很多人認為使用EJB開發中等的網頁應用程式有點大材小用。但從頭開發一個商業應用程式是不實際的。大多數的伺服端應用程式有很多是普遍的 ，就像管理應用程式狀態 ，資料庫提取或儲存資料，安全性，非同步進程，整合系統等等。

        作為一個框架，EJB container提供了這些普遍的功能，那EJB components 可以直接使用這些功能到自己的應用程式也不需要重新開發這類功能。這些服務，當EJB components 部署在EJB container的時候就能使用，就像Figure 2. 這代表開發一個高品質，豐富功能的應用程式比你所想的還要快。

Figure 2

        Container使用了一些優雅的新方法提供服務給EJB components：metadata annotations 是當container部署EJBs用來預設EJBs 服務的類別。在Java 5中有介紹metadata annotations是設定一段程式碼的設定，如某些class需要特定屬性。這是程式語言的宣告方式讓開發者註明需要完成什麼然後系統將程式碼加上。

        在 EJB meta annotations 大大的簡化了應用程式的開發和測試，不需要額外的xml 設定檔案. 這允許當開發者需要的時可宣告式的增加愛服務到EJB components。就像Figure

3 描繪，annotations 將一個簡單的POJO轉換成 EJB

Figure 3

Layered architectures and EJB

        大多數的企業應用程式包含大量的components.企業應用程式是為了解決客戶特定問題所設計，但它們共享很多common 特色。舉例來說，多數企業應用程式有些UI界面，商業模式，將資料儲存到資料庫特性。因為這些共同特性，在構建企業應用程式可以跟隨常見架構或設計原則稱為 “patterns”.

        對於伺服端開發，較好的pattern是layered architectures. 在layered architecture 中components被劃分在tiers。應用程式的每一個tier都有很好定義。EJB在建立應用程式允許採用兩種不同的layered architecture分別是：traditional four-tier architecture 和 domain-drive design (DDD).

Traditional four-tier layered architecture

Figure 4 顯示traditional four-tier layered architecture.這個架構非常直覺也非常普及。在這架構presentation layer是負責GUI和處理user input, 然後將每個得到的request傳給business logic layer. Business logic layer是應用程式的核心而且包含工作流程和processing的邏輯。Business logic layer透過persistence tier 從資料庫獲取或儲存資料。Persistence layer 在 database layer之上提供高階的抽象的OO。Database layer 就是DBMS。

Figure 4

EJB 明顯不是presentation layer. EJB完全支援在實作商業邏輯和persistence layer. Figure 5 顯示 EJB如何透過它的服務支援這些layers.在一開始有提到bean的種類session beans 和 message-driven beans是用在business logic tier, 而entities實在persistence layer.

Figure 5

        Traditional four-tier architecture 是不完美的。其中一個常見的批評就是破壞了OO模組化商業領域為物件且封裝資料和行為的理想。因為traditional architecture 專注在business process的模組化而不是領域。而且persistence layer也比較像簡單的資料處理元件，像資料庫資料的定義而不是OO世界的第一級公民。

Domain-driven design

Domain-driven design (DDD )重點放在領域的物件應該包含商業邏輯和不應該只是複製資料庫的資料。Domain objects 在EJB3 也稱為entities。在DDD中，一個貿易應用程式的Catalog和Customer物件是entities的典型例子，它們應該包含商業邏輯。

        然而，就算EJB發布的時它的價值已經非常清楚，但還是很困難的實作DDD。在EJB 2 實作 domain model是不可能的，因為beans不是 POJOs 且沒有支援多數的OO特色，如：inheritance 和 polymorphism。有個好消息是EJB 3 已經可以讓我們簡單的跟隨好的OO設計或DDD。在EJB 3 Java Persistence API (JPA)定義的entities 支援OO。我們可以簡單的實作persistence object,最重要的是可以簡單的增加商業邏輯在entities上，那在透過EJB 3實作一個rich domain 是在簡單不過的任務。

Reference：
1）EJB 3 in action