作者:openEJB 來源：ebjnow
全面研讀 EJB 2.0
EJB 2.0 中引人注目的變化增強了應用程序開發的靈活性和可移植性
Richard Monson-Haefel
OpenEJB 首席設計師
2000 年 6 月
內容：
CMP
抽象的持久性方案
EJB 2.0 的 CMP 模型
EJB 查詢語言
新的 ejbHome 方法
MessageDrivenBean
什麼是 JMS？
EJB 2.0 中的 JMS
作為 EJB 2.0 資源的 JMS
JMS 與 MessageDrivenBean
結論
參考資料
作者簡介
新的 EJB 2.0 規範不僅僅是一個新的階段性發行版，它加入了許多引人注目的變動，包括 CMP 組件模型中的一些變動和一種新的 bean 類型，它們將增強您在開發應用程序時的靈活性和可移植性。請率先了解此新規範的功能，本月已發布了它的公開草案。
6 月 2 號發布的 Enterprise JavaBeans 2.0 不僅是一個階段性發行版，而且是該規範的一個新版本。整個規範有 500 多頁，比以前的 EJB 1.1 規範長了 200 頁 (66%)。該規範中最重要的變動是對容器管理的持久性 (CMP) 所作的更改，以及引入了一種全新的 bean 類型，即 MessageDrivenBean。
EJB 2.0 中的大量更改都集中在一種新 CMP 組件模型的定義中。它完全不同於舊的 CMP 模型，因為它引入了一個全新的成員，即持久性管理器，並引入了全新的方式來定義容器管理的欄位，以及定義這些欄位與其它 bean 和從屬對象的關係。
MessageDrivenBean （消息 bean）的引入也是非常重要的。消息 bean 體現出 JMS （Java Message Service）與 EJB 相集成，以創建出一種全新的 bean 類型，它設計用來處理非同步的 JMS 消息。這種振奮人心的新型 bean 為 JMS 客戶機提供一種組件模型，允許將它們部署到 EJB 容器系統的豐富而強健的環境中去。
對該規範還作了許多較小的其它更改。這些其它更改雖然也重要，但它們主要是涉及使該規範更嚴格，以便消除多義性，並使這些組件具有更高的可移植性。本文集中討論 EJB 2.0 中引入的新 CMP 和消息 bean 組件模型。
我將提供幾個具體的例子，所以讀者應該很容易跟上並理解它。但是，EJB 初學者可能發現這個材料比較困難，因為它假定讀者已對 EJB 有了基本的了解。有關 EJB 的詳細信息，請參閱參考資料。
容器管理的持久性
容器管理的持久性在 EJB 2.0 中發生了根本變化。在 EJB 2.0 中，持久性管理器在運行時自動處理 CMP 實體 bean 的持久性。持久性管理器負責根據一種稱為抽象持久性方案的新的 bean 持久性管理器合約，將實體 bean 映射到資料庫。此外，持久性管理器還負責實現和執行多種查找方法，這些查找方法均基於一種稱為 EJB QL 的新型查詢語言。
注意到以下事實是很重要的，即符合 EJB 2.0 規範的產品必須能支持 EJB 1.1 CMP 模型，又能支持新的 EJB 2.0 模型。雖然這兩種模型並不兼容，但是為了保證向後兼容性，就必須能支持 EJB 1.1 模型。
抽象持久性方案
為了理解抽象持久性方案是如何工作的，以及它為什麼重要，我將為您快速地回顧一下在 EJB 1.1 中是如何處理 CMP 的，隨後再討論在 EJB 2.0 中如何定義它。
EJB 1.1 中的 CMP 模型
在 EJB 1.1 中，bean 開發人員負責將 bean 類的持久性欄位聲明為 Java 基本類型或可序列化類型。下列示例顯示了一個 Employee 企業級 bean 類，它是按 EJB 1.1 定義的，帶有幾個 CMP 欄位：
// Employee bean 類
public class EmployeeBean implements
java.ejb.EntityBean {
// 實例欄位
EntityContext ejbContext;
// 容器管理的欄位
public int identity;
public String firstName;
public String lastName;
public double salary;
public Address address;
public Integer ejbCreate(int id, String fname,
String lname){
identity = id;
firstName = fname;
lastName = lname;
return null;
}
...
}
// Address 從屬類
public class Address implements Serializable{
public String street;
public String city;
public String state;
public String zip;
}
當將關係資料庫用於持久性時，基本欄位如 identity、firstName、lastName 和 salary，很容易持久化，因為它們很好地映射為 SQL 類型，如 INTEGER、CHAR 和 DOUBLE。
在 EJB 1.1 中，CMP bean 的 XML 部署描述符提供 cmp-field 元素，用以標識此 bean 類中的持久性欄位（容器管理的欄位）。如下所示，cmp-field 元素用來區分寫入資料庫的欄位和不寫入資料庫的欄位。例如，ejbContext 欄位就不包括在容器管理的欄位的列表中，因此它不是持久性欄位。
EmployeeEJB
...
Container
...
identity
firstName
lastName
salary
address
...
容器提供者提供一種工具，用來將 bean 的持久性欄位映射到資料庫表中的列，通常每個 bean 對應一個表。但是，可序列化的類型，如 Address，就比較難於持久化。在 EJB 1.1 中，沒有標準的方法將可序列化的對象映射到關係資料庫。雖然 Address 類有其自身的欄位集，但 XML 部署描述符並沒有提供一種機制，來將這些欄位映射到資料庫。在大多數情況下，人們期望將可序列化的對象（如 Address）作為二進位類型（有時稱為 blob 類型）持久化到某個資料庫表中。
由於實體 bean 的數據方案逐漸複雜起來，所以這個問題也變得嚴重了。例如，Employee bean 可能有多個類似於 Address 的子對象，如 Benefits 和 JobPosition。這些子對象稱為從屬對象，可以形成關係資料庫中跨幾個表的複雜對象圖。另外，EJB 1.1 中的 CMP 在很大程度上不足以持久化與其它 bean 的關係。在 EJB 1.1 中，如果某個 bean 準備維持與另一個 bean 的關係，則容器會自動將主關鍵字或句柄用作一個鏈接。與某些其它 bean 的關係其性質可能是雙向的，或者要依賴於一些不易用主關鍵字或句柄來表示的欄位，為了保持與這類 bean 的關係，上面的辦法已被證明是一種遠未完善的機制。
EJB 2.0 的 CMP 模型
在 EJB 2.0 中，CMP 實體 bean 和持久性管理器之間的新合約，使您能夠在實體 bean 中定義更複雜的、可移植性更強的關係，包括 bean 與 bean 之間、bean 與從屬對象之間、甚至從屬對象與從屬對象之間的關係。
持久性管理器是新加入到 Enterprise JavaBeans 部署過程中的。容器廠商，或專長於特定資料庫的持久性的廠商，將能提供這種持久性管理器。其思路是將用於管理 bean 關係的機制從容器中分離出來，容器只負責管理安全、事務和資源。這種職責上的分離使不同的持久性管理器能夠與不同的容器一起工作。它也使實體 bean 在不同 EJB 廠商之間以及在各種持久性管理器之間具有更強的可移植性。
如果您使用或學習過 Thought Inc. 生產的，能自動為 EJB 1.1 容器生成 BMP（bean 管理的持久性）bean 的產品 CocoBase，則您對持久性管理器工具如何工作就已經比較熟悉了。CocoBase 根據 bean 部署者提供的，從對象到關係的映射信息，為 BMP bean 生成全部資料庫訪問邏輯。在 EJB 2.0 中，持久性管理器能夠根據部署描述符、bean 的抽象持久性方案和部署者完成的工作所提供的信息，生成 CMP 實體到關係資料庫的映射。但是，持久性管理器並不局限於關係資料庫。也可以為對象資料庫以及遺留的系統和 ERP 系統（如 SAP）開發持久性管理器。
為了將持久性管理器從容器中分離出來，必須定義 bean 與持久性管理器之間的合約。這個合約在新的抽象持久性方案中表現出來。此方案是通過部署描述符中一組新的 XML 元素和 CMP 實體 bean 中的一組代碼習語定義的。在 EJB 2.0 中，CMP bean 類被聲明為抽象類，它的持久性欄位和關係欄位是使用抽象的讀方法和寫方法來訪問的，而這兩種方法的方法特徵則映射為 XML 部署描述符中的特定元素。
在部署該 bean 時，您將使用持久性管理器工具，根據 XML 部署描述符和 bean 類，來具體實現此抽象 bean 類及其從屬對象類。具體實現將包括數據訪問代碼，此代碼將在運行時將 bean 的狀態實際讀出和寫到資料庫中。在運行時，容器使用由持久性管理器工具生成的子類，而不使用 bean 提供者定義的抽象類。
bean 類的繼承層次結構
為了使討論更充實，這裡提供一個 CMP 實體的示例，它更具體地說明了抽象持久性方案是如何工作的。
EJB 2.0 中的一個示例 CMP 實體
在 EJB 2.0 中，容器管理的實體 bean 被定義為抽象的，而且它的持久性欄位並不在 bean 類中直接定義。作為替代，開發了一種抽象的持久性方案，從而允許 bean 提供者間接地聲明持久性欄位和 bean 關係。下面是 Employee bean 的一個示例，它使用了新的抽象持久性方案。請注意，該 bean 類中未聲明任何持久性欄位。
public abstract EmployeeBean implements
javax.ejb.EntityBean {
. // 實例欄位
EntityContext ejbContext;
// 容器管理的持久性欄位
public abstract void setIdentity(int
identity);
public abstract int getIdentity();
public abstract void setFirstName(String
firstName);
public abstract String getFirstName();
public abstract void setLastName(String
lastName);
public abstract String getLastName();
// 容器管理的關係欄位
public abstract void
setContactInfo(ContactInfo info);
public abstract ContactInfo
getContactInfo();
...
}
在此 bean 的 XML 部署描述符中，抽象的持久性方案聲明容器管理的各個欄位和各種關係。
EmployeeEJB
...
Container
...
identity
firstName
lastName
...
ContactInfo
ContactInfo
street
city
state
zip
homePhone
workPhone
email
...
Employee-ContactInfo
employee-has-contactinfo
one
EmployeeEJB
contactInfo
ContactInfo
contactinfo_belongsto_employee
one
ContactInfo
用來描述容器管理的關係的 XML 元素可能變得非常複雜，因為他們必須處理各種關係的對應性和方向（單向的還是雙向的）。上面的代碼段說明，為了描述 bean 與其從屬對象類之間的簡單關係，您需要哪些元素。雖然即使是簡單的關係也會被轉換為冗長的 XML，但所有這些元素都是必需的，以便持久性管理器能夠將複雜的對象圖映射到資料庫中。
雖然用於定義 CMP bean 的抽象持久性方案的 XML 元素是 EJB 2.0 中的 CMP 的主要問題，但為了簡潔起見，本文不再提供 XML 示例。作為替代，本文將純粹依靠 bean 類中必須使用的抽象習語，來說明 EJB 2.0 中的 CMP 背後的基本概念。這些代碼習語與 XML 部署描述符中的關係元素一起使用，並由後者定義，所以您不能只有其一而沒有另一個，但它們比該方案的 XML 部分較容易理解。
除了 XML 元素之外，抽象的持久性方案還定義了一組習語，它們在聲明 bean 類及其相關的對象時必然會用到。用來訪問和修改欄位的方法是嚴格定義了的，要求用 set 方法修改持久性欄位，而用 get 方法訪問它們。這些方法的名稱和返回類型由部署描述符中它們相應的 XML 關係元素規定。
實體 bean 類和從屬類都遵循相同的抽象持久性方案。下面是如何將 ContactInfo 對象定義為從屬對象類的示例。
public abstract class ContactInfo {
// 家庭地址信息
public abstract void setStreet(String street);
public abstract String getStreet();
public abstract void setState(String state);
public abstract String getState();
public abstract void setZip(String zip);
public abstract String getZip();
public abstract void setHomePhone(String phone);
public abstract String getHomePhone();
// 工作地址信息
public abstract void setWorkPhone(String phone);
public abstract String getWorkPhone();
public abstract void setEMail(String email);
public abstract String getEMail();
...
}
從屬對象隨實體 bean 的存在而存在，隨實體 bean 的中止而中止，這是理解從屬對象與實體 bean 之間關係的關鍵。從屬對象包含在一個具體的實體中，所以刪除這個實體將導致從屬對象也被刪除。用關係資料庫的術語來說，有時這就稱為級聯刪除。
從屬對象，如 ContactInfo，用在關係欄位中。與實體 bean 形成關係的從屬對象技術上稱為從屬對象類。EJB 客戶端應用程序永遠不能直接訪問從屬對象類；這種類不能用作 bean 的遠程或本地介面中的參數或返回值。從屬對象類只對 bean 類才是可見的。
從屬對象類不適合作為遠程參數類型，因為它們與 bean 在運行時的持久性邏輯有密切的聯繫。持久性管理器擴展了抽象的從屬對象類，以便能提供一種實現，可用於在運行時管理 bean 的持久性狀態。此外，抽象的持久性方案還為數據建模 -- 而不是為那些由企業級 bean 表示的業務概念建模 -- 所以，作為一種設計策略，將抽象的持久性方案對 EJB 客戶機隱藏起來是有意義的。
例如，ContactInfo 關係欄位中除了 bean 的客戶機所需的簡單地址信息之外，還包含許多其它信息。雖然您可以使用抽象持久性方案中的從屬對象類 ContactInfo（它對 bean 的客戶機是隱藏的），但是，您得用其它的對象來把這些數據實際表露給客戶機。下面是一個示例，說明了如何對 EJB 客戶機隱藏 ContactInfo 從屬對象。在此例中，地址信息是通過在 EJB 1.1 的示例中開發的 Address 對象來表露的。
// Employee bean 的遠程介面
public interface Employee extends javax.ejb.EJBObject {
public Address getHomeAddress();
public void setHomeAddress(Address address);
public int getIdentity() throws RemoteException;
public void setFirstName(String firstName) throws
RemoteException;
public String getFirstName()throws RemoteException;
public void setLastName(String lastName) throws
RemoteException;
public String getLastName() throws RemoteException;
}
// Employee bean 的 bean 類
public abstract EmployeeBean implements
javax.ejb.EntityBean {
...
public Address getHomeAddress(){
ContactInfo info = getContactInfo();
Address addr = new Address();
addr.street = info.getStreet();
addr.city = info.getCity();
addr.state = info.getState();
addr.zip = info.getZip();
return addr;
}
public void setHomeAddress(Address addr){
ContactInfo info = getContactInfo();
info.setStreet(addr.street);
info.getCity(addr.city);
info.getState(addr.state);
info.getZip(addr.zip);
}
....
// 容器管理的關係欄位
public abstract void setContactInfo(ContactInfo
info);
public abstract ContactInfo getContactInfo();
...
}
儘管容器管理的關係欄位沒有表露給客戶機，但您仍然可以從遠程介面直接使用容器管理的持久性欄位。請注意，用來訪問 firstName 和 lastName 的容器管理的持久性欄位是在遠程介面中使用的。
一個 bean 與各種從屬對象類之間可能具有多種不同的關係，它們由這種關係的對應性和方向來定義。Bean 與從屬對象類之間可以有一對多和一對一的關係。例如，Employee bean 可能僅有一個 Benefit 從屬對象類，但可能有許多 ContactInfo 從屬對象類。
public abstract EmployeeBean implements
javax.ejb.EntityBean {
...
public abstract void setContactInfos(Collection
addresses);
public abstract Collection getContactInfos():
public abstract void setBenefit(Benefit benefit);
public abstract Benefit getBenefit();
...
}
與從屬對象類的一對多關係既可表示為 java.util.Collection 類型，也可表示為 ava.util.Set 類型（註：在本規範的後續版本中，java.util.Map 和 java.util.List 被視為附加的返回類型），而與從屬對象的一對一關係則使用從屬對象的類型。
實體 bean 也可以定義與其它實體 bean 的關係。這些關係可以是一對一、一對多或多對多。例如，Employee bean 可能有許多子級 bean，而只有一個配對的 bean。下面的代碼段使用抽象持久性方案的方法習語，說明了如何為這些關係建模。該應用程序中，子級 bean 和配對的 bean 都表現為 Person bean。
public abstract EmployeeBean implements
javax.ejb.EntityBean {
...
public abstract void setSpouse(Person manager);
public abstract Person getSpouse();
public abstract void setChildren(Collection
family);
public abstract Collection getChildren();
...
}
與另一個 bean 的一對多關係表示為 java.util.Collection 類型或 java.util.Set 類型，而一對一關係則使用該 bean 的遠程介面類型。
從屬對象本身與同一個 bean 中的其它從屬對象之間可以有一對一、一對多和多對多的關係。此外，從屬對象與其它實體 bean（除其父級 bean 之外）也可以有一對一、一對多的關係。下面的示例顯示，Benefit 從屬對象類與 Salary 從屬對象（一種報酬計算程序）之間怎樣具有一對一的關係，而與 Investment bean 又怎樣具有一對多的關係。
public abstract class Benefit {
public abstract void setSalary(Salary salary);
public abstract Salary getSalary();
public abstract void setInvestments(Collection
investments);
public abstract Collection getInvestments();
}
在部署時，部署者將使用持久性管理器工具來具體實現這個 bean 類及其從屬類。這些具體實現將在運行時保持各種關係，並使各 bean 實例的狀態與資料庫同步。容器將在運行時管理持久性實例，從而提供一種強健的環境，其中具有自動的訪問控制和事務控制。
bean 也可以定義從屬對象的值，這些對象是可序列化的對象，如 EJB 1.1 示例中的 Address 對象。這些值通過序列化而變為持久的，它們並不形成與 bean 的關係 -- 它們是嚴格的容器管理的持久性欄位。
容器與持久性管理器之間也已經定義了一個合約，使持久性管理器可以獲得事務的句柄，並訪問由該容器管理的資料庫連接池。這個合約稍嫌寬鬆，將來還需要使其更為嚴格，但它是允許持久性管理器跨 EJB 容器移植的基礎。容器和持久性管理器之間合約的細節已超出了本文的範圍。
除了通過抽象持久性方案定義持久性之外，EJB 2.0 還提供了一種新的查詢語言，用來說明持久性管理器應該如何實現 CMP 中的各種查找方法。
EJB 查詢語言
EJB 查詢語言 (EJB QL) 規定了持久性管理器應該如何實現在本地介面中定義的各種查找方法。 EJB QL 以 SQL-92 為基礎，可由持久性管理器自動編譯，這使得實體 bean 具有更高的可移植性，並且更容易部署。
EJB QL 和查找方法
EJB QL 語句是在實體 bean 的部署描述符中聲明的。使用 EJB QL 非常簡單。作為一個例子，Employee bean 的本地介面可以按以下方式聲明：
public interface EmployeeHome extends javax.ejb.EJBHome
{
...
public Employee findByPrimaryKey(Integer id)
throws RemoteException, CreateException;
public Collection findByZipCode(String zipcode)
throws RemoteException, CreateException;
public Collection findByInvestment(String
investmentName)
throws RemoteException, CreateException;
}
給定了上面的本地介面定義之後，您就可以使用 EJB QL 來指定持久性管理器應該如何執行查找方法。每個實體 bean 都必須有一個 findByPrimaryKey() 方法。為執行該方法所需的查詢是很明顯的 -- 使用主關鍵字的（一個或幾個）欄位在資料庫中查找 bean，這樣就不需要任何 EJB QL 語句。
findByZipCode() 方法用來獲得具有某個郵政編碼的所有 Employee bean。這將使用部署描述符中的下列 EJB QL 來表達。
FROM contactInfo WHERE contactInfo.zip = ?1
該語句本質上是表示「選擇其郵政編碼等於 zipcode 參數的所有 Employee bean」。
在用於查找方法的 EJB QL 語句中，不需要使用 SELECT 子句來表明要選擇的內容。這是因為，查找方法將總是選擇與其自身的 bean 類型相同的遠程引用。在這種情況下，就可以認為選擇語句將返回遠程 Employee bean 的全部引用。
如果各種查找方法都一起部署在同一個 ejb-jar 文件中，並且其間具有可導航的實際關係，那麼這些查找方法就甚至可以跨越到另一些 bean 的抽象持久性方案中去。例如，findByInvestment() 方法將要求該查找查詢從 Employee 導航到投資 bean 的抽象持久性方案中去。聲明來表達這種查找操作的 EJB QL 語句如下所示。
FROM element IN benefit.investments WHERE element.name
= ?1
以上語句是說：「選擇全部這樣的 Employee bean：其獲利從屬對象至少包含一個投資 bean 的引用，並且其名稱等於 findByInvestment() 方法的 investmentName 參數。」
EJB QL 和選擇方法
EJB QL 也用於一種稱為 ejbSelect 方法的新查詢方法中，該方法類似於查找方法，只是它僅供 bean 類使用。該方法不在本地介面中聲明，所以也不顯露給客戶機。此外，ejbSelect 方法可返回範圍更大的各種值，而不僅限於 bean 本身的遠程介面類型。
存在兩種選擇方法：ejbSelect 和 ejbSelectInEntity。ejbSelect 方法是全局執行的，這是指這種方法並非專用於執行該方法的 bean 實例。ejbSelectInEntity 方法則專用於執行該方法的實體實例。這些選擇方法在 bean 類中被聲明為抽象方法，並在這些類的業務方法中使用。下面是 ejbSelect 方法和 ejbSelectInEntity 方法的示例，同時說明了可以如何在業務方法中使用它們。
public abstract class EmployeeBean implements
javax.ejb.EntityBean {
...
// ejbSelectInEntity
public abstract Collection
ejbSelectInvestmentsInEntity (String risk);
// ejbSelect
public abstract Collection
ejbSelectInvestments(String risk);
...
}
在上面的聲明中，兩種選擇方法運行於不同的範圍。ejbSelectInvestmentsInEntity() 僅在當前的 Employee bean 實例上執行，所以它只返回僱員的風險投資。
SELECT invest FROM invest IN benefit.investments WHERE
invest.type = ?1
另一方面，ejbSelect 方法的範圍則是全局性的，所以同一個查詢將返回整個企業內所有僱員的全部風險投資。
ejbSelectInEntity 選擇方法可以返回 bean 的遠程類型（如在上面的查詢中那樣）、從屬對象或任何其它 Java 類型。另一方面，全局選擇方法則不能返回 bean 的從屬對象類型。
選擇方法的 EJB QL 語句要求使用 SELECT 子句，因為它們能夠返回範圍更廣的各種值。
新的 ejbHome 方法
在 EJB 2.0 中，實體 bean 可以聲明一些 ejbHome 方法，用來執行與 EJB 組件相關的操作，但並不專用於某個 bean 實例。在 bean 類中定義的 ejbHome 方法在本地介面中必須有一個與其相匹配的本地方法。下面的代碼說明了一個本地方法，它正是作為 Employee bean 的本地介面定義的。applyCola() 方法用來根據最近 COLA（生活費用調整）的增長來更新所有僱員的薪水。
public interface EmployeeHome extends javax.ejb.EJBHome
{
// 本地方法
public void applyCola(double increate) throws
RemoteException;
...
}
applyCola() 方法在 bean 類中必須有匹配的 ejbHome 方法，它被聲明為 ejbHomeApplyCola()。ejbHomeApplyCola() 方法並非專用於一個 bean 實例，它的範圍是全局的，所以它將對所有僱員的薪水使用同一個 COLA。
public abstract class EmployeeBean implements
javax.ejb.EntityBean {
...
// ejbHome 方法
public void ejbHomeApplyCola (double increase ){
Collection col = ejbSelectAllEmployees ();
Iterator employees = col.iterator();
while(employees.next()){
Employee emp =
(Employee)employees.next();
double salary =
emp.getAnnualSalary();
salary = salary + (salary*increase);
emp.setAnnualSalary(salary);
}
}
}
bean 的開發人員需要為 BMP 和 CMP 實體 bean 都實現 ejbHome 方法。CMP 實現可能在很大程度上要依賴於全局的選擇語句（如上面所說明的那樣）和 finder 方法，而 ejbHome 的 BMP 實現則將使用直接資料庫訪問和 bean 的 finder 方法，來查詢數據和進行更改。
MessageDrivenBean
在 EJB 2.0 中，對規範的一個基礎性更改是添加了一種全新的企業級 bean 類型，即 MessageDrivenBean。MessageDrivenBean 專門設計來處理入網的 JMS 消息。對於許多開發人員來說，JMS 是一種新的範例，所以本文將花一些時間逐步說明對 JMS 的理解，以及它們在 EJB 2.0 中的用法。
什麼是 JMS？
JMS 是一種與廠商無關的 API，用來訪問消息收發系統。它類似於 JDBC (Java Database Connectivity)：這裡，JDBC 是可以用來訪問許多不同關係資料庫的 API，而 JMS 則提供同樣與廠商無關的訪問方法，以訪問消息收發服務。許多廠商目前都支持 JMS，包括 IBM 的 MQSeries、BEA 的 Weblogic JMS service 和 Progress 的 SonicMQ，這只是幾個例子。
JMS 使您能夠通過消息收發服務（有時稱為消息中介程序或路由器）從一個 JMS 客戶機向另一個 JML 客戶機發送消息。消息是 JMS 中的一種類型對象，由兩部分組成：報頭和消息主體。報頭由路由信息以及有關該消息的元數據組成。消息主體則攜帶著應用程序的數據或有效負載。根據有效負載的類型來劃分，可以將消息分為幾種類型，它們分別攜帶：簡單文本 (TextMessage)、可序列化的對象 (ObjectMessage)、屬性集合 (MapMessage)、位元組流 (BytesMessage)、原始值流 (StreamMessage)，還有無有效負載的消息 (Message)。
消息收發系統是非同步的，也就是說，JMS 客戶機可以發送消息而不必等待回應。比較可知，這完全不同於基於 RPC 的（基於遠程過程的）系統，如 EJB 1.1、CORBA 和 Java RMI 的引用實現。在 RPC 中，客戶機調用伺服器上某個分散式對象的一個方法。在方法調用返回之前，該客戶機被阻塞；該客戶機在可以執行下一條指令之前，必須等待方法調用結束。在 JMS 中，客戶機將消息發送給一個虛擬通道（主題或隊列），而其它 JMS 客戶機則預訂或監聽這個虛擬通道。當 JMS 客戶機發送消息時，它並不等待回應。它執行發送操作，然後繼續執行下一條指令。消息可能最終轉發到一個或許多個客戶機，這些客戶機都不需要作出回應。
EJB 2.0 中的 JMS
EJB 2.0 以兩種方式支持 JMS 的集成：作為一種 bean 可用的資源，和作為一個 MessageDrivenBean。當將 JMS 用作一種資源時，使用 JMS API 的 bean 就是消息的產生者或發送者。在這種情況下，bean 將消息發送給稱為主題或隊列的虛擬通道。另一方面，MessageDrivenBean 則是消息的使用者或接收者。它監聽特定的虛擬通道（主題或隊列），並處理髮送給該通道的消息。為了更好地理解消息產生者和消息使用者的作用，用 SessionBean bean 來發送一條使用 JMS 的消息，然後使用一個新的 MessageDrivenBean 來使用該同一條消息。
作為 EJB 2.0 資源的 JMS
會話 bean 和實體 bean 都是基於 RPC 的組件，為了將各種事務性的組件裝配到一起，這是一種卓越的體系結構。但是，在某些情況下，RPC 的同步性質會成為一種障礙，這正是 EJB 1.1 中將對 JMS API 的訪問作為一種資源包括在內的原因。利用 JNDI 環境命名的上下文，bean 可以獲得一個 JMS 工廠，並將一條非同步消息發送給主題或隊列（也從 JNDI 獲得），而不必等待回應。下面是 ShoppingCart bean 的一個例子，它使用 JMS 將 Order 的詳細信息發送給消息收發主題。
public class ShoppingCartBean implements SessionBean {
// 訂單詳細信息是一個可序列化的對象，它包含全部訂單信息。
public OrderDetail orderDetail;
public void processOrder(){
// 處理訂單的邏輯從此處開始
....
// ... 處理訂單以後，向其它系統發送有關此訂單的一條消息
InitialContext jndiEnc = new
InitialContext();
// 使用 JNDI ENC 獲取 JMS 工廠和主題標識符
TopicConnectionFactory factory =
jndiEnc.lookup("java:comp/env/jms/topicfactory");
Topic orderTopic =
jndiEnc.lookup("java:comp/env/jms/ordertopic");
// 獲得一個用來發送消息的發布者
TopicConnection con =
factory.createTopicConnection();
TopicSession session =
con.createTopicSession(false,
Session.AUTO_ACKNOWLEDGE );
TopicPublisher publisher =
session.createPublisher(orderTopic);
// 將一個 ObjectMessage 發送給主題（虛擬通道）
ObjectMessage message =
session.createObjectMessage();
message.setObject(orderDetail);
publisher.publish(message);
con.close();
}
...
}
在這種情況下，JMS 是用來通知另外的應用程序，訂單已被處理。這些另外的應用程序對於處理訂單來說並不重要，但它們會因為得到一個訂單已被處理的通知而受益。這樣的例子包括自動調整庫存的庫存系統，和能將客戶添加進產品目錄郵寄名單中的銷售應用程序。
使用 JMS 使 bean 能夠發布（發送）消息而不會發生阻塞。bean 並不知道誰將收到消息，因為它是將消息發送給某個主題（虛擬通道），而不是直接發送給另一個應用程序。應用程序可以選擇預訂該主題，並接收有關新訂單的通知。這樣就有可能動態地在虛擬通道中添加或刪除應用程序，從而產生了一種更加靈活的系統。
預訂了訂單主題的應用程序將收到有關新訂單的通知，應用程序可以使用它們認為合適的任何方式來處理這個通知。預訂了各種主題的應用程序或者從各個隊列中接收消息的應用程序可以是 Java 應用程序、EAI 系統（用於集成遺留系統和 ERP 系統）或者 MessageDrivenBean 組件，在 JMS 的術語中，它們全部被認為是 JMS 客戶機。
JMS 和 MessageDrivenBean
雖然大多數 JMS 廠商都提供消息中介工具，來將消息從發送者路由到接收者，但構建使用（接收）消息的 JMS 客戶機卻是應用程序開發人員的職責。在許多情況下，接收消息的應用程序必須強健、安全、快速而且可伸縮；它需要的基礎結構基本上與 EJB 應用程序相同。
由於認識到這種需要，EJB 2.0 現在包括了 MessageDrivenBean 類型，它可以使用 JMS 消息，並且在同一個強健的、基於組件的基礎結構中處理這些消息，這樣的基礎結構對於會話 bean 和實體 bean 都非常有用。MessageDrivenBean 類型（消息 bean）是一種企業級 bean 組件，它設計來使用非同步的 JMS 消息。
除了提供容器基礎結構以外，EJB 還具有另一個重要的優點：併發處理。在 EJB 中，一個已部署的消息 bean 表示一個單一的消息使用者，但這個 bean 本身是由許多 bean 實例提供服務的。每個 bean 實例都可以分別地使用消息 bean 接收到的消息。這意味著，消息 bean 不必像常規 JMS 客戶機那樣連續地使用消息。消息 bean 可以併發地使用接收到的多個消息，這樣就能達到比傳統 JMS 應用程序高得多吞吐量和好得多的可伸縮性。
為了說明消息 bean 的作用，就開發了 MarketingBean 類，並將它從訂單主題中部署到供使用的消息中去。MarketingBean 將從消息中提取 OrderDetail 對象，並使用它將客戶添加到適當的目錄郵寄名單中。這是一種最精緻的大量郵寄系統。
下面是 MarketingBean 類的定義，這個類使用發布給訂單主題的消息。
public class MarketingBean implements
javax.ejb.MessageDrivenBean {
public void onMessage(Message message) {
ObjectMessage orderMessage =
(ObjectMessage)orderMessage:
OrderDetail orderDetail =
(OrderDetail)orderMessage.getObject();
Integer customerID =
orderDetail.getCustomerID();
InitialContext jndiEnc = new
InitialContext();
CatalogHome catalogHome =
(CatalogHome)jndiEnc.lookup("java:comp/env/ejb/catalog");
Iterator productIDs =
orderDetail.getProductsIDs();
while(productIDs.hasNext()){
Integer productID =
(Integer)productIDs.next();
Catalog cat =
CatalogHome.findByProductID(productID);
cat.addCustomerToMailingList(customerID);
}
}
}
正像會話 bean 和實體 bean 一樣，MessageDrivenBean 也是一種完備的企業級 bean，但其間仍存在一些重要的區別。消息 bean 沒有遠程介面或本地介面。這是因為消息 bean 不是 RPC 組件。它沒有供 EJB 客戶機調用的業務方法。消息 bean 監聽虛擬消息通道（主題或隊列），並使用其它 JMS 客戶機發送給該通道的消息。
各個消息 bean 構成一個 bean 類，這個類實現 MessageDrivenBean 介面和一個 XML 部署描述符。下面是 MessageDrivenBean 介面的定義，所有消息 bean 都必須實現這個介面。
package javax.ejb;
import javax.jms.Message;
import javax.jms.MessageListener;
public interface MessageDrivenBean extends
MessageListener{
public void onMessage(Message message);
public void ejbCreate();
public void ejbRemove();
public void
setMessageDrivenContext(MessageDrivenContext mdc);
}
當部署了一個消息驅動的 bean 以後，它就被指派來處理特定主題或隊列中的消息。JMS 客戶機（Java 應用程序、bean 或本地客戶機）發送的任何消息，將由消息路由器轉發給消息 bean，該消息 bean 正是被指派來從該虛擬通道中接收消息的。當一條消息被發送給一個消息 bean 時，EJB 容器就會從某個池中選擇該 bean 的一個實例，來處理這條消息。當 bean 實例調用其 onMessage() 方法時，它就會接收到這條消息，並能夠以它認為合適的任何方式來處理這條消息。一旦這條消息被使用，則只要事務沒有異常中止，這條消息都不會被傳送給這個消息 bean 的任何其它實例。
消息 bean 在某點上類似於無狀態的會話 bean，即這兩種 bean 在兩次請求之間都不保持任何狀態。因此，消息驅動的 bean 是無狀態的，但是，就像無狀態的會話 bean 一樣，它們也可以有實例變數，這些變數在這個 bean 實例的整個生存期內均保持。
對消息 bean 的最後一點說明是，理解這樣一個事實是很重要的，即 bean 使用的消息不一定要是由其它 bean 所產生的。消息 bean 可以使用由符合 JMS 的廠商提供的任何主題或隊列中的消息。消息 bean 使用的消息可以來自其它 bean（會話 bean、實體 bean 或消息 bean）、非 EJB 的 Java 應用程序、或者甚至非 Java 的應用程序（如果其供應商符合 JMS）。例如，遺留應用程序可能使用 IBM 的 MQSeries 向隊列發送消息，而該消息既可以由其它遺留應用程序使用，同樣可以由消息 bean 使用。
結論
與以前的規範相比，Enterprise JavaBeans 2.0 中作了一些相當大的更改。新的 CMP 模型比以前的模型要靈活得多，它允許各種實體為複雜的對象圖建立模型，而同又提供跨容器的更大的可移植性。人們迫切地期待著為查找和選擇操作定義一種通用的查詢語言，而它也將有助於提高可移植性。
這種新的 MessageDrivenBean 類型將有助於使這種強大的消息收發範例成為眾人矚目的焦點，就像 EJB 那樣。消息收發在分散式的混合計算中是一個極其重要的組成部分，將它包括在 EJB 內就是其重要性的一個證明。
在寫這篇文章時，EJB 2.0 剛剛作為公開草案發布，這意味著在它成為一個最終規範之前仍有可能更改。如果更改對此處提供的材料有重大影響，屆時我將設法對本文作一些註釋，但這個規範正在趨於穩定，所以不太可能有真正重大的更改。
參考資料
"A Beginner's Guide to Enterprise JavaBeans," Mark Johnson（JavaWorld，1998 年 10 月）：
Richard Monson-Haefel 的 EJB 開發者網站，EJBNow.com
EJB 2.0，規範
Thought 的 CocoBase
IBM 的 MQ Series
BEA 的 WebLogic JMS Service
Progess Sonic MQ
Richard Monson-Haefel 所寫的其它文章：
"Create forward-compatible beans in EJB, Part 1"（JavaWorld，1999 年 12 月）
"Create forward-compatible beans in EJB, Part 2"（JavaWorld，2000 年 1 月）
作者簡介
Richard Monson-Haefel 是最近發布的 Enterprise JavaBeans 第二版的作者。他是 OpenEJB 的首席設計師（OpenEJB 是一種開放源代碼的 Enterprise JavaBeans 2.0 容器），他曾經以設計師身份為 Enterprise JavaBeans、CORBA、Java RMI 以及其它 Java 方案提供諮詢。Monson-Haefel 還維護著一個網站，供人們討論 Enterprise JavaBeans 和相關的分散式計算技術。可以通過 richard.monson-haefel@javaworld.com 與 Richard Monson-Haefel 聯繫。
JavaWorld 雜誌授權翻印。Web Publishing Inc.（一家 IDG 通信公司）版權所有。要獲得編輯郵件預告，請註冊。
