對企業開發人員來講, 難以編寫分布式商務應用程序和其它任何較大的應用程序是他們所面臨著一個共同問題。如果一個應用程序是分布式的,或在網絡中以多重形式出現,那它必然應該是一個綜合化的產物。如果一個應用程序必須可靠而有保證地執行它的商務邏輯, 那麼其綜合化程度又必然需要進一步提高。
企業所面臨的另一個復雜問題是企業自身的基本操作環境也是多種多樣的。另外, 企業希望能以盡可能快的速度建立自己的應用程序, 而不是被限制在單一的平台上。理想的情況是, 企業開發人員只編寫一次應用程序, 而該程序即可在任意平台上運行。企業JavaBeansTM技術就是希望提供這種能力。
企業JavaBeans(EJB)的組件結構是以作為可重復使用的服務器端組件而設計的，它使企業能夠建立可升級、安全可靠、可運行於多重平台且以商務為重點的應用程序。本文描述了EJB組件模型的含義和結構，並且給出了一個EJB組件如何工作的實例。
什麼是企業JavaBeans技術?
EJB技術的設計目標
企業應用程序模型
特性
開發人員的角色分配
開發過程
EJB的未來
結論
什麼是企業JavaBeans技術?
EJB結構是JavaTM平台上的服務器端組件模型。設計EJB結構的目的是, 通過使企業開發人員將注意力只集中於編寫商務邏輯, 從而解決上面所提出的問題。EJB技術取消了編寫"全程(plumbing)" 碼的要求。例如, 企業開發人員不再需要編寫那些處理事務行為、安全、連接共享或線程的代碼, 因為EJB體系結構將這些任務委托給服務器廠商完成了。
對用戶和這一技術的實現者來說, 將會獲得如下收益:
生產效率: 使用這一技術, 企業開發人員將會進一步提高生產效率。他們不僅能夠獲得在Java平台上的開發成果, 而且能夠將注意力集中於商務邏輯, 從而使效率倍增。
業內支持: 試圖建立EJB系統的客戶會獲得一系列可供選擇的解決方案。企業JavaBeans技術已經被多達25個公司所接受、支持和應用。
投資保護: 企業JavaBeans技術建立在企業現存系統之上。事實上, 許多EJB產品都將建立在已有的企業系統之上。今天企業所使用的系統, 明天將會運行企業JavaBeans組件。
結構獨立: 企業JavaBeans技術將開發人員和底層中間件相隔離; 開發人員看到的僅僅是Java平台。 這一點除下面將要談到的交叉平台的好處外, 還? 得EJB服務器廠商在不干擾用戶的EJB應用程序的前提下, 有機會改進中間件層。
服務器端僅寫一次, 即可隨處運行（Server-Side Write Once, Run AnywhereTM）: 通過對Java平台的支持, EJB技術將"僅寫一次, 隨處運行"的概念提高到了一個新的水平。它可以保證一個EJB應用程序可運行於任何服務器, 只要這個服務器能夠真正提供企業JavaBeans APIs。
EJB技術的設計目標
服務器端環境和其所需工具極大地影響了EJB技術的設計目標。 一個主要的設計目標是減少（盡可能地）建立分布式應用程序的過程；它是通過將一般需要手工編碼的特性轉化為企業Beans簡單聲明屬性來實現的, 這些聲明屬性使開發效率大大提高, 因為某些行為, 如安全和事務不是以代碼形式, 而是通過Bean自身的"標記" 來設定的,。這種設計特性也是EJB技術使開發人員將注意力集中於編寫商務邏輯的另一條途徑。
EJB規范創建了一種底層結構, 它關系到系統級編程, 如事務、安全、線程、命名、對象生命周期、資源共享、遠程訪問和persistence等等；它同時也簡化了訪問現存應用程序的過程, 並為工具的創建和使用提供了統一的應用程序開發模型。
企業應用程序模型
除提供底層結構以外, EJB技術還涉及到另外一個問題。有兩種建立企業應用程序的基本模型。在第一個模型中, 客戶是從作為一個應用程序的對象開始對話期的; 該對象可代表客戶執行一項工作, 有可能包括多重數據庫事務；在第二個模型中, 客戶訪問一個對象, 這個對象代表了數據庫中的一個實體。EJB的設計適用性很廣, 它包括了這兩種模型:
Session Beans包括了第一種模型。一個Session Bean是一個對象, 它代表了與客戶的一個瞬時對話, 並為客戶執行數據庫讀寫操作；這些數據庫的訪問是在一個事務處理過程中實現的。一個Session Bean的字段包括對話的狀態且是瞬時的，之所以如此的意義在於, 一旦服務器或客戶崩潰, Session Beans就不存在了。該模型典型地用於數據庫編程語言, 如PL/SQL。
Entity Beans包括了第二種模型。一個Entity Bean與作用於一個數據庫中的數據的方法一起代表了這些數據。在關系型數據庫中, 例如一個雇員信息表格, 表中的每一行都有一個Bean。Entity Beans是事務型的且長壽, 只要數據庫中的數據存在, 則Entity Bean就存在。該模型大多數典型地應用於面向對象的數據庫中。
請注意在EJB規范中, 支持Session Beans是強制性的, 而支持Entity Beans在目前是選擇性的; 但在EJB規范2.0版中, 它將成為強制性的。
EJB 結構
上圖顯示了EJB技術的體系結構。EJB規范支持任何類型的客戶, 因為該規范不強制要求任何遠程對象的"網線"協議；這就意味著一個服務器可支持多種協議, 如RMI、IIOP(CORBA)和DCOM等；它也說明, 一個EJB服務器的客戶程序不一定要用Java語言來編寫。
EJB服務器實際是各種支持EJB安裝的服務的集合, 這些服務包括分布式事務管理、分布式對象管理和對這些對象的分布式調用以及低層次系統服務。簡而言之, EJB服務器管理那些支持EJB組件所需要的資源。一個EJB服務器提供商可提供一個容器的實現(詳情見後）, 他也可以為第三方廠商提供API以使其能嵌入附加EJB容器。EJB規范在服務器的設計和實現上給了開發人員以極大的自由。
EJB服務器正象是EJB組件的一個家, 而容器則是Bean生活的地方, 就象是一個記錄"生活"在數據庫中一樣。它提供了一個可升級、安全和事務性的環境, 在該環境中Bean可以操作。處理對象生命周期(包括創建和銷毀一個對象)的正是容器。容器也負責Bean的狀態管理。
容器對客戶是透明的, 容器上沒有客戶API。當一個Bean被安裝在容器中時, 該容器提供兩種實現: Bean的EJBHome接口的實現(詳情見後)和Bean的遠程接口的實現。容器也負責保證在JavaJNDI 中能夠獲得Bean的EJBHome接口。
要構造一個Bean, 你必須首先實現商務方法。 例如, 如果你正在編寫一個帳目檢查Bean, 你可能要實現一個"借方"方法用來作為接口的一部分；你還必須實現兩種類型的EJB接口之一 --Session Bean或Entity Bean；這些接口包括了諸如與工作設置管理相關的方法並且不暴露給客戶。
當把一個Bean安裝在服務器上時, 遠程接口(在CORBA中通常稱作skeleton)則被自動生成。遠程接口的實現被稱為EJBObject, 它只將程序員指定的遠程接口暴露出來。盡管企業Bean類包含了同樣的方法, 但它並不實現遠程界面。 EJBObject的作用就象是一個代理人, 它截取遠程對象調用並調用企業Bean實例中的適當的方法。
一個EJB容器可實現安裝在該容器中的每個企業Bean的EJBHome接口, 它允許Bean的創建和清除, 並且可查詢有關Bean的信息或"元數據"。該容器使客戶通過JNDI便可獲得EJBHome接口。對Entity Beans來說, EJBHome接口也包含了一個或多個"finder"方法, 使客戶用一個主鍵即可查詢有關Bean的信息。
特性
應用程序開發人員所面臨的最復雜的問題之一是編寫分布式事務應用程序。EJB技術的一個主要特性就是它對分布式事務的支持；EJB技術使你可編寫訪問跨越多個EJB服務器的多重分布式數據庫的應用程序。為使這一工作變得簡單, EJB規范允許你在部署階段就以聲明的形式指出事務行為, 而管理事務行為的負擔被轉移給服務器, 特別是轉移給容器和EJB服務器提供者。如果Bean的開發人員有更高的事務需求, 則可使Bean通過程序來管理事務界限。
安全是所有企業產品的需求。EJB組件模型充分發揮了核心Java平台安全模型的作用, 從而給予你兩種設置安全的方法。第一, 你可以在Bean的EJB-JAR文件中設置安全描述符； 第二, 你可以使用java.security包實現對安全的程序化管理。
EJB的另一個設計特性是獨立於對象的通信協議。這有許多好處, 首先, 它可以使編寫客戶端應用程序的程序員免於選擇通信協議; 其次, 它允許EJB服務器的建立者實現對其用戶最為重要的協議。例如, ORB提供者可能僅僅實現CORBA協議, 而UNIX提供者則可能實現RMI和CORBA協議。但無論如何, 所用協議對Bean的開發人員是透明的, 他僅僅針對Java平台來編寫程序。
Java平台為EJB服務器提供了許多繼承性的優點。最明顯的一點是, 一旦基於Bean的應用程序編成後, 它便可以在任何可運行企業Bean服務器的地方運行；其連帶的優點是升級性。如果你目前的EJB應用程序在性能上出了問題, 你可以將應用程序的主要部分移植到另一個更高性能的平台的EJB服務器上。
專用容器可大大簡化對現存企業應用程序的訪問。這樣的容器可使現存非Java語言應用程序作為Bean出現, 它使Java開發人員可在不了解現存系統和應用程序特點的情況下訪問那些應用程序。
開發人員的角色分配
EJB技術將開發人員分成固有的五種角色: 服務器提供者、 容器提供者、 企業Beans提供者、 應用程序裝配者和部署者。對上述五種角色描述如下:
服務器提供者是分布式事務管理方面的專家, 主要負責處理分布式對象和低層次系統服務。數據庫和TP監控器廠商可典型地充當該角色。
容器提供者一般是系統編程方面的專家, 由於容器有能力將EJB環境與現存應用程序(如SAP R/3和CICS)橋接起來, 因而這些專家有可能具備某一應用領域的經驗。由於容器為Bean提供了安全、可升級和事務性的環境, 因而容器提供者需具備這些領域的經驗。數據庫和事務服務器廠商也適合這一角色, 並可提供標准容器。
企業Beans提供者為EJB應用程序提供"積木", 他們是典型的以Bean的形式編寫商務邏輯的域專家,而他們不一定是數據庫或系統編程方面的專家。他們生成包括所有組件在內的EJB JAR文件。對象庫廠商適合這一角色。
應用程序裝配者是域專家, 他們的工作是用第三方Beans建立應用程序, 他們也有可能建立客戶端GUI。典型的應用程序裝配者通常是程序員，他們建立應用程序來可訪問已部署的組件。
部署者通常熟悉企業的操作環境, 他們利用應用程序包並設置部分或全部應用程序的安全和事務描述符。部署者也有可能使用工具來修正Bean的商務邏輯。
開發過程
值得注意的是, 有幾種不同的建立EJB應用程序和組件的方案。開發過程的不同主要取決於是否編寫session Bean、entity Bean和應用程序或上述三項的某種組合。
考慮一個有關帳目檢查並編寫session Bean的簡單方案。 建立EJB組件的開發過程是簡單的: 首先, 你應該使用IDE(如Java Workshop, Cafe 或JBuilder)為你的Bean或基於Bean的應用程序編寫商務邏輯；編譯後, Beans被打包到一個EJB JAR文件中, 它與常規的JAR文件相似, 但包含了一個序列化的DeploymentDescriptor類實例, 其中包括了對安全、事務行為等的設置；然後, 你應該使用服務器廠商提供的部署工具在EJB服務器上安裝Bean。至此, 部署者(如數據庫管理員)將設置Bean在特定站點的屬性, 如事務模式或安全等級。一旦Bean被安裝到了服務器上, 則客戶可調用實例的遠程方法。
請看一個有關電子商務的例子-- 一個網上"購物車"。考慮一下你將如何建立一個購物車Bean? 或許你應該從建立Bean的遠程接口開始:
public interface ShoppingCart extends javax.ejb.EJBObject{
boolean addItem(int itemNumber) throws
java.rmi.RemoteException;
boolean purchase() throws java.rmi.RemoteException;
}
這個接口定義了兩個方法: additem()用於向購物車中增加物品, purchase()用於完成這筆交易。一旦公共接口的定義完成，我們必須編寫Bean的類:
public class ShoppingCartEJB implements SessionBean{
public boolean addItem(int itemNumber){
// the code for adding items to the cart
// may include JDBC code.
}
public boolean purchase(){
//the code for purchases
}
public ejbCreate(String accountName, String account){
// object initialization code
}
}
請注意, 企業Bean類不實現Bean的遠程接口, 它是由EJBObject來完成的。另外, session Bean不支持自動的persistence。因而, 顯式數據庫訪問必須在其方法中實現。例如, 在purchase()方法中, JDBCTM調用可被用來更新數據庫, 而由容器在安裝時生成的EJBObject可實現遠程接口；EJBObject的作用就象是一個"代理人", 它將方法調用傳遞給安裝在服務器中的Bean實例。
客戶做的第一件事是使用JNDI為所需要的Bean定位EJBHome。在本例子中, EJBHome對象可能以下列形式出現:
public interface CartHome extends javax.ejb.EJBHome{
Cart create(String customerName , String account)
throws RemoteException, BadAccountException;
}
CartHome接口包含一個create()方法, 當客戶請求一個新的Bean的時候該方法將被調用。請注意, 這個方法是在EJBObject中實現的並將在被調用時調用Bean類中的ejbCreate()方法。
ShoppingCart類的EJBHome對象可使用下列代碼來定位:
Context initialContext = new InitialContext();
CartHome cartHome = (CartHome) initialContext.lookup
("application/mall/shopping-carts");
在本例中, 調用InitialContext()以得到JNDI命名層次的根；lookup()方法被用來得到CartHome。 在此種情況下, "applications/mall/shopping.carts"是JNDI到達你感興趣的CartHome的路徑。此時, cartHome持有了ShoppingCartEJB的EJBHome對象的引用。然而, 請注意客戶的JNDI的命名空間可能被設置為包括分布於網絡上的多種機器上的EJB容器; EJB容器的實際位置一般來說對客戶是透明的。
下例顯示了客戶是如何使用EJBHome對象並調用方法的:
ShoppingCart cart = cartHome.create("Emma","0507");
Cart.addItem(100);
Cart.addItem(251);
Cat.purchase();
在上述代碼中, create()方法創建了一個新的session Bean, 變量cart 包括了一個對遠程EJB Object的引用, EJB Object允許你調用它的方法additem()和purchase()。cartHome中的create()方法將調用對應的Bean中的ejbCreate()方法。
EJB的未來
EJB規范1.0是在1998年JavaOne大會期間發布的, 它為建立分布式商務對象系統提供了堅實的結構體系基礎, 它不應該被認為是這一研究主題的結束, 而應該是進一步完善這一體系結構的開始。該規范的一些內容還需改進, 特別是處理persistence對象的EJB模型。另外, 還應考慮標准化開發工具和開發系統之間的協定，以為所有開發環境提供統一的調試界面。
將來, SunMicrosystem還將研究兼容性問題。有兩個領域涉及到兼容性問題, 一是"EJB兼容的"服務器到底是由什麼組成的? 一個兼容性計劃有望在不久的將來出現; 二是保證不同廠商的EJB服務器具有相互操作性。Sun正在就這些問題征求其合作伙伴的意見, 以決定如何發展。
結論
企業JavaBean技術為我們提供了一種開發、部署和管理分布式商務應用程序的新途徑。它使開發人員編寫作為可重復使用的服務器組件的分布式商務應用程序變得更簡單, 並且不必擔心系統級編程問題。企業JavaBean組件結構代表了在簡化企業應用程序的開發、部署和管理方面的一個巨大進步。有關企業JavaBean技術的完整描述, 請訪問企業JavaBean的網。
