管理軟件開發(fā)技術(shù)課件

2024年1月2日19時30分CORBA模型與RMI

三種分佈式計算模型：（1）CORBA

（2）COM/DCOM

（3）JAVARMI2024年1月2日19時30分CORBA模型與RMI

CORBA是基於面向?qū)ο蠹夹g(shù)的，它能解決遠(yuǎn)程對象之間的互操作問題。

COM/DCOM是基於WINDOWS系統(tǒng)的。

JAVARMI能實現(xiàn)與平臺無關(guān)，但它只能用JAVA實現(xiàn)。

CORBA通過IDL（InterfaceDefinitionLanguage)的介面定義語言，能做到與語言無關(guān)。任何語言都能製作CORBA組件，而CORBA組件能在任何語言中使用。

CORBA是J2EE技術(shù)EJB的基礎(chǔ)，EJB的很多技術(shù)來自CORBA。

EJB和J2EE帶來了一種以JAVA為中心的基於構(gòu)件技術(shù)的方法進(jìn)行傳統(tǒng)中間件的編程。2024年1月2日19時30分CORBA參考模型

CORBA參考模型由以下幾個元素構(gòu)成：（1）對象請求代理（ObjectRequestBroker)ORG在分佈式環(huán)境下使得對象之間能夠透明地發(fā)送請求和接收回應(yīng)。它是在分佈式對象上建立其他應(yīng)用的基礎(chǔ)，也是異構(gòu)或同構(gòu)環(huán)境下實現(xiàn)互操作的基礎(chǔ)。（2）對象服務(wù)（ObjectServices)

支持如何使用對象和如何實現(xiàn)對象的是一系列服務(wù)（對象和介面）。對建立特定的分佈式應(yīng)用，對象服務(wù)是必需的，而且對象獨立於特定的應(yīng)用域。（3）公共設(shè)施（CommonFacilities)

公共設(shè)施是能被多個應(yīng)用所共用的一系列服務(wù)。如系統(tǒng)管理和電子郵件是公共設(shè)施。對象服務(wù)強(qiáng)調(diào)的是基本性。

2024年1月2日19時30分CORBA參考模型

（4）應(yīng)用對象應(yīng)用對象相當(dāng)於傳統(tǒng)應(yīng)用程式的概念。它是構(gòu)成參考模型最上層的元素。對象請求代理是整個CORBA參考模型的核心，它類似於電話交換機(jī)，提供產(chǎn)生呼叫和接收呼叫的基本處理機(jī)制，通過與對象服務(wù)的結(jié)合，可以確保符合CORBA規(guī)範(fàn)的應(yīng)用之間進(jìn)行有意義的通訊。2024年1月2日19時30分使用CORBA的優(yōu)點在J2EE中使用CORBA的優(yōu)點：

（1）使用CORBA與以前開發(fā)的系統(tǒng)實現(xiàn)無縫連接（2）CORBA支持用戶進(jìn)行高級中間件開發(fā)技術(shù)

EJB並不能解決任何問題，但如果存在一個可抽象出來的中間件服務(wù)，很可能它將成為CORBA標(biāo)準(zhǔn)中的一種服務(wù)。（3）CORBA與EJB有條件連接在一起。

EJB允許用戶的EnterpriseBeans被兩種不同類型的客戶端程式訪問：用J2EEAPIs編寫的客戶端和使用CORBAAPI的客戶端。其他語言編寫的程式可通過CORBA訪問用戶的EnterpriseBeans。

2024年1月2日19時30分CORBA的優(yōu)點

（1）CORBA簡化了分佈式應(yīng)用的集成（2）CORBA作為一種抽象的規(guī)範(fàn)定義而不限制具體的實現(xiàn)方案。（3）CORBA結(jié)構(gòu)更利於資源的靈活、合理利用（相對於C/S）。CORBA是對等的分佈計算環(huán)境，秘有應(yīng)用對象之間的地位是平等的，其擔(dān)任的角色是可互相轉(zhuǎn)換的。（4）CORBA是面向?qū)ο蟮?。?）CORBAIDL是一種與編程語言無關(guān)的介面定義語言，用來定義對象的請求/服務(wù)介面，描述應(yīng)用對象所封裝的內(nèi)容和界限。（6）CORBA作為一種標(biāo)準(zhǔn)，其核心元素的穩(wěn)定性有保證的。（7）具有開放性和平臺獨立性。2024年1月2日19時30分使用CORBA的缺點

（1）CORBA標(biāo)準(zhǔn)的發(fā)展比較緩慢。（2）CORBA的內(nèi)容非常多，使得很難全部掌握所有東西。

CORBA分成很多服務(wù)，在需要時只需學(xué)習(xí)相應(yīng)服務(wù)即可。（3）基於CORBA的產(chǎn)品可能包含不相容的特性。2024年1月2日19時30分CORBA的工作原理

（1）ORG

當(dāng)客戶程式要調(diào)用遠(yuǎn)程對象上的方法時，首先要得到這個遠(yuǎn)程對象的引用，之後就可像調(diào)用本地方法一樣調(diào)用遠(yuǎn)程對象的方法。當(dāng)發(fā)出一個調(diào)用時，ORG會截取個調(diào)用，因為客戶和服務(wù)器可能在不同一網(wǎng)路、不同的操作系統(tǒng)甚至不同的語言實現(xiàn)，ORG還要負(fù)責(zé)將調(diào)用的名字、參數(shù)等編碼成標(biāo)準(zhǔn)方式（Marshaling)通過網(wǎng)路傳輸?shù)剿欧鞣剑瑏K通過將參數(shù)Unmarshling的過程傳輸?shù)秸_的對象上（整個過程稱為重定向），伺服器對象完成處理後，ORG通過同樣方式將結(jié)果返回給客戶。2024年1月2日19時30分CORBA的工作原理

ORG具有以下能力：（1）對象定位（根據(jù)對象引用定位對象的實現(xiàn)）（2）對象定位後，確信SERVER能接受請求（3）通過客戶請求重定位到伺服器對象上（4）如果需要，將結(jié)果按同樣方式返回。2024年1月2日19時30分CORBA的工作原理OMGIDL

是定義介面，而不定義實現(xiàn)。

IDL到具體語言的映射須瞭解IDL到具體語言映射的細(xì)節(jié)規(guī)範(fàn)。CORBA靜態(tài)請求。通過一個本地方法調(diào)用，將此調(diào)用翻譯成遠(yuǎn)程方法的調(diào)用。2024年1月2日19時30分CORBA的工作原理

（2）CORBA服務(wù)瞭解必要的CORBA服務(wù)2024年1月2日19時30分RMI-IIOP

RMI-IIOP標(biāo)準(zhǔn)是EJB和CORBA相容標(biāo)準(zhǔn)的關(guān)鍵。

RMI與CORBA是非常相似的技術(shù)，但有所不同。

CORBA是一個相對完善的分佈式對象標(biāo)準(zhǔn)，它允許語言之間的互補(bǔ)，而RMI比較適合於純JAVA的應(yīng)用環(huán)境。它們是兩種不相容的技術(shù)。RMI-IIOP規(guī)範(fàn)允許將RMI與CORBA相結(jié)合。2024年1月2日19時30分結(jié)合RMI與CORBA的應(yīng)用步驟

RMI-IIOP客戶端與CORBA對象實現(xiàn)（1）利用JAVA編寫RMI-IIOP遠(yuǎn)程介面（2）生成必要的客戶端RMI-IIOPStubs來調(diào)用CORBA對象（3）生成OMGIDL（4）生成伺服器端必需的CORBA檔。（5）編寫客戶端應(yīng)用程式和服務(wù)器端應(yīng)用程式?？蛻舳伺c資料庫伺服器客戶端開發(fā)工具可以完成的工作資料庫可以完成的工作C/S模式下開發(fā)應(yīng)用系統(tǒng)應(yīng)考慮的問題資料庫設(shè)計

2024年1月2日19時30分客戶端開發(fā)工具可以完成的工作

（1）設(shè)計窗口和定義窗口的控件（2）生成菜單（3）生成數(shù)據(jù)窗口（4）在程式中直接書寫SQL語句運算元據(jù)庫（5）可以極方便地生成和維護(hù)資料庫（6）在圖形方式下生成數(shù)據(jù)查詢。用戶即使不會使用SQL語句也可以在此環(huán)境下生成複雜的查詢，並將其作為一類對象保存。（7）實現(xiàn)資料庫之間數(shù)據(jù)的轉(zhuǎn)換2024年1月2日19時30分資料庫可以完成的工作資料庫是應(yīng)用系統(tǒng)的核心，從客戶端開發(fā)工具來看，它的作用主要有：（1）接收SQL指令，執(zhí)行SQL指令，並將指令的執(zhí)行結(jié)果返回給客戶端。（2）查詢優(yōu)化。從客戶端發(fā)為的SQL指令，資料庫要先對其進(jìn)行語法和句法分析，然後進(jìn)行查詢優(yōu)化。查詢優(yōu)化分為兩類：一類是基於語法的優(yōu)化，這類優(yōu)化是根據(jù)SQL語句的寫法，相同的查詢不同的寫法會導(dǎo)致完全不同的查詢效率。另一類是基於成本的優(yōu)化，這類優(yōu)化與SQL語句的寫法無關(guān)，僅與要完成的工作有關(guān)?；冻杀镜膬?yōu)化技術(shù)極大地降低了對開發(fā)人員的要求，可以使開發(fā)人員更專心地解決應(yīng)用中的問題。2024年1月2日19時30分資料庫可以完成的工作（3）事務(wù)處理資料庫的特點是數(shù)據(jù)的集中管理和共用，在通常情況下總是有若干個事務(wù)併發(fā)地運行，這些並行的事務(wù)可能併發(fā)地存取相同的數(shù)據(jù)。因此，資料庫的一個重要任務(wù)是要有一種機(jī)制去保證這種併發(fā)的存取和修改不破壞數(shù)據(jù)的完整性，確保這些事務(wù)能正確在運行並取得正確的結(jié)果。（4）併發(fā)處理事務(wù)併發(fā)執(zhí)行是若不加控制的話將導(dǎo)致不正確的結(jié)果和數(shù)據(jù)庫狀態(tài)的不一致。為保證資料庫正確地反映所有事務(wù)的更新，以及在一事務(wù)修改資料庫中的數(shù)據(jù)時，其他事務(wù)不能同時修改這些數(shù)據(jù)，資料庫必須用鎖來控制對數(shù)據(jù)的併發(fā)存取。2024年1月2日19時30分資料庫可以完成的工作（5）存取許可權(quán)管理用戶對數(shù)據(jù)庫對象的操作許可權(quán)是通過使用授權(quán)的方法來管理的。（6）資料庫規(guī)則規(guī)則是加在資料庫表列上的約束條件，是在資料庫上設(shè)定的。主要有限制列的取值範(fàn)圍、唯一性、是否非空等。如果用戶給此列的輸入值不滿足約束條件時，則資料庫會給出錯誤資訊，資料庫只接收滿足約束條件的數(shù)據(jù)。（7）主鍵和外鍵主鍵和相應(yīng)的外鍵是維持表間特定關(guān)係的一種方法，是實體間一對多關(guān)係的體現(xiàn)。相關(guān)完整性是指主鍵和相應(yīng)外鍵必須完全匹配的性質(zhì)。2024年1月2日19時30分資料庫可以完成的工作（8）存儲過程存儲過程是編譯好了存儲在資料庫中的SQL語句和控制流語句的集合。它可極大地增強(qiáng)SQL語句的功能、效率和靈活性，改善SQL語句的性能。（9）觸發(fā)器觸發(fā)器是一種特殊類型的存儲過程，它在插入、刪除或修改特定表中的數(shù)據(jù)時起作用。觸發(fā)器可以維持表間數(shù)據(jù)的一致性，保證數(shù)據(jù)的相關(guān)完整性。觸發(fā)器的優(yōu)點是不管什麼原因造成資料庫數(shù)據(jù)變化時都能自動回應(yīng)。2024年1月2日19時30分資料庫可以完成的工作（10）視圖視圖是一個或多個表中數(shù)據(jù)的一種表現(xiàn)形式，可將視圖看作為一個移動的窗口，通過它可看到感興趣的數(shù)據(jù)。視圖看起來非常象表，對它的查詢或操作與表相同。使用視圖有以下優(yōu)點：①看到的是所需要的。視圖允許用戶集中在他們感興趣的數(shù)據(jù)或他們負(fù)責(zé)的數(shù)據(jù)上進(jìn)行工作。那些對特定用戶或?qū)μ囟üぷ鳠o關(guān)的數(shù)據(jù)可被排除在視圖之外。②簡化數(shù)據(jù)操作。視圖不僅可簡化用戶對數(shù)據(jù)的理解，而且可以簡化他們的操作。那些被經(jīng)常使用的查詢可以定義為視圖，從而使用戶不必為以後的操作每次指定全部查詢條件。2024年1月2日19時30分資料庫可以完成的工作③視圖允許用戶以不同的方式查詢同樣的數(shù)據(jù)。④安全性。通過視圖用戶只能查詢或修改他們所能見到的數(shù)據(jù)。通過使用視圖和有選擇的授權(quán)，用戶可被限制在使用數(shù)據(jù)的不同子集上。⑤邏輯數(shù)據(jù)獨立性。視圖可幫助用戶遮罩真實表結(jié)構(gòu)帶來的影響，使應(yīng)用程式和數(shù)據(jù)庫結(jié)構(gòu)相互獨立，互不影響。（11）序號生成器資料庫可以自動生成連續(xù)的序號，這樣做的目的是避免多個用戶同時申請下一個序號造成的瓶頸。2024年1月2日19時30分C/S模式下開發(fā)應(yīng)用系統(tǒng)應(yīng)考慮的問題主要考慮兩個問題：（1）客戶端開發(fā)工具主要是應(yīng)用前臺的問題，資料庫主要是應(yīng)用後臺的問題。然而由於資料庫和客戶端開發(fā)工具的功能都在不斷增強(qiáng)，客戶端開發(fā)工具在向資料庫方向上延伸，資料庫的功能在向客戶端開發(fā)工具方向延伸，一些功能是相互交叉，所以有些問題用客戶端開發(fā)工具或資料庫都能解決。對於應(yīng)用中的某些特定問題，使用客戶端開發(fā)工具還是資料庫來解決，用資料庫解決問題的好處是什麼，用客戶端開發(fā)工具的好處又是什麼？（2）對於非資料庫莫屬的工作，客戶端開發(fā)工具表現(xiàn)特徵是怎樣？客戶端開發(fā)工具如何針對他們編程？2024年1月2日19時30分在實際應(yīng)用中可能遇到下列問題

（1）維護(hù)體現(xiàn)企業(yè)規(guī)則的表間關(guān)係可用客戶端開發(fā)工具編程完成，也可用資料庫觸發(fā)器來控制。這種表間的關(guān)係是隨著企業(yè)規(guī)章制度的變化而變化的。如果用客戶端開發(fā)工具編程來實現(xiàn)，則程式的維護(hù)將是很困難的。原則上，此類問題應(yīng)該用觸發(fā)器來解決，用觸發(fā)器來實現(xiàn)具有以下優(yōu)點：①企業(yè)規(guī)則可以在資料庫中集中控制。②如果企業(yè)規(guī)則發(fā)生變化只需修改相應(yīng)資料庫觸發(fā)器的內(nèi)容，無需修改客戶端應(yīng)用程式，系統(tǒng)容易維護(hù)。③客戶端應(yīng)用程式編程變得更簡單。④系統(tǒng)運行效率會提高。但過多地濫用觸發(fā)器反而會使系統(tǒng)的效率降低。2024年1月2日19時30分在實際應(yīng)用中可能遇到下列問題（2）體現(xiàn)企業(yè)規(guī)則的數(shù)據(jù)運算可用客戶端開發(fā)工具編程完成，也要用存儲過程完成。這種計算是隨著企業(yè)規(guī)章制度和國家的政策的變化而變化。如果用客戶端開發(fā)工具編程來實現(xiàn)，程式的維護(hù)也很困難。像這樣的問題應(yīng)該用存儲過程來實現(xiàn)。用存儲過程實現(xiàn)具有以下優(yōu)點：①企業(yè)規(guī)則可以在資料庫中集中控制。②如果企業(yè)規(guī)則發(fā)生變化只需修改相應(yīng)存儲過程的內(nèi)容，無需修改客戶端應(yīng)用程式，系統(tǒng)容易維護(hù)。③客戶端應(yīng)用程式編程變得更簡單。④系統(tǒng)運行效率會提高。2024年1月2日19時30分在實際應(yīng)用中可能遇到下列問題（3）事務(wù)是由資料庫管理的最小邏輯工作單元，在一個事務(wù)中所有對數(shù)據(jù)庫的更新操作要麼全部成功，要麼全部失敗。事務(wù)的劃分（起點和終點）是客戶端開發(fā)工具的任務(wù)，但在窗口環(huán)境下如何劃分事務(wù)，如何編寫管理事務(wù)程式是一個較難的問題。（4）併發(fā)處理是多人同時更新資料庫中相同數(shù)據(jù)時的處理方式，資料庫可以自動加鎖，但這種自動加鎖方式不一定適合實際需要。在實際的併發(fā)條件下會出現(xiàn)很多難以預(yù)料的複雜情況，“恰當(dāng)”地加鎖是客戶端開發(fā)工具的任務(wù)，也是一個較難的問題。2024年1月2日19時30分在實際應(yīng)用中可能遇到下列問題（5）序號生成。應(yīng)該由資料庫來完成。（6）視圖。視圖是資料庫中原始數(shù)據(jù)的某種變換。有的時候，這種變換可以用開發(fā)工具來完成。但視圖的許多優(yōu)良特性是客戶端開發(fā)工具不具有的。哪些工作應(yīng)由開發(fā)工具來完成，哪些工作應(yīng)由視圖來完成，是資料庫設(shè)計人員和開發(fā)人員要認(rèn)真研究的問題。

2024年1月2日19時30分2024年1月2日19時30分EJB框架

EJB分佈式應(yīng)用程式是基於對象組件模型的，低層的事務(wù)服務(wù)用了API技術(shù)。EJB技術(shù)簡化了用JAVA語言編寫的企業(yè)應(yīng)用系統(tǒng)的開發(fā)、配置。EJB技術(shù)定義了一組可重用的組件：EnterpriseBeans。你可以利用這些組件，像搭積木一樣的建立你的分佈式應(yīng)用程式。當(dāng)你把代碼寫好之後，這些組件就被組合到特定的檔中去。每個檔有一個或多個EnterpriseBeans，再加上一些配置參數(shù)。最後，這些EnterpriseBeans被配置到一個裝了EJB容器的平臺上。客戶能夠通過這些Beans的home介面，定位到某個Bean，並產(chǎn)生這個Bean的一個實例。這樣，客戶就能夠調(diào)用Bean的應(yīng)用方法和遠(yuǎn)程介面。EJB伺服器作為容器和低層平臺的橋樑管理著EJB容器和函數(shù)。它向EJB容器提供了訪問系統(tǒng)服務(wù)的能力。例如：資料庫的管理和事務(wù)的管理，或者對於其他的Enterprise的應(yīng)用伺服器。所有的EJB實例都運行在EJB容器中。2024年1月2日19時30分EJB框架容器提供了系統(tǒng)級的服務(wù)，控制了EJB的生命週期。EJB中的有一些易於使用的管理工具如：(1)Security：配置描述器（TheDeploymentdescriptor）定義了客戶能夠訪問的不同的應(yīng)用函數(shù)。容器通過只允許授權(quán)的客戶訪問這些函數(shù)來達(dá)到這個效果。(2)RemoteConnectivity：容器為遠(yuǎn)程鏈接管理著低層的通信issues，而且對EnterpriseBeans的開發(fā)者和客戶都隱藏了通信細(xì)節(jié)。EJB的開發(fā)者在編寫應(yīng)用方法的時候，就像是在條用本地的平臺一樣的。客戶也不清楚他們調(diào)用的方法可能是在遠(yuǎn)程被處理的。

2024年1月2日19時30分EJB框架

(3)LifeCyclemanagement：客戶簡單的創(chuàng)建一個Enterprisebeans的實例，並通常取消一個實例。而容器管理著EnterpriseBeans的實例，使EnterpriseBeans實現(xiàn)最大的效能和記憶體利用率。容器能夠這樣來啟動和使EnterpriseBeans失效，保持眾多客戶共用的實例池。(4)Transactionmanagement：配置描述器定義了Enterprisebeans的事務(wù)處理的需求。容器管理著那些管理分佈式事務(wù)處理的複雜的issues。這些事務(wù)可能要在不同的平臺之間更新資料庫。容器使這些事務(wù)之間互相獨立，互不干擾。保證所有的更新資料庫都是成功發(fā)生的，否則，就回滾到事務(wù)處理之前的狀態(tài)。2024年1月2日19時30分EJB框架

EJB組件是基於分佈式事務(wù)處理的企業(yè)級應(yīng)用程式的組件。所有的EJB都有如下的特點：EJB包含了處理企業(yè)數(shù)據(jù)的應(yīng)用邏輯。定義了EJB的客戶介面。這樣的介面不受容器和服務(wù)器的影響。於是，當(dāng)一個EJB被集合到一個應(yīng)用程式中去時，不用更改代碼和重新編譯。EJB能夠被定制各種系統(tǒng)級的服務(wù)，例如安全和事務(wù)處理的特性，都不是屬於EJB類的。而是由配置和組裝應(yīng)用程式的工具來實現(xiàn)。有兩種類型的EJB：SessionBeans和EntityBeans。SessionBeans是一種作為單用戶執(zhí)行的對象。作為對遠(yuǎn)程的任務(wù)請求的相應(yīng)，容器產(chǎn)生一個SessionBean的實例。一個SessionBean有一個用戶。從某種程度上來說，一個SessionBean對於伺服器來說就代表了它的那個用戶。SessionBeans也能用於事務(wù)，它能夠更新共用的數(shù)據(jù)，但它不直接描繪這些共用的數(shù)據(jù)。SessionBeans的生命週期是相對較短的。典型的是，只有當(dāng)用戶保持會話的時候，SessionBeans才是活著的。一旦用戶退出了，SessionBeans就不再與用戶相聯(lián)系了。SessionBeans被看成是暫態(tài)的，因為如果容器崩潰了，那麼用戶必須重新建立一個新的Session對象來繼續(xù)會話。2024年1月2日19時30分EJB框架

SessionBeans典型地聲明了與用戶的互操作或者會話。也就是說，Sessionbean了在客戶會話期間，通過方法的調(diào)用，掌握用戶的資訊。一個具有狀態(tài)的SessionBean稱為有狀態(tài)的SessionBean。當(dāng)用戶終止與SessionBeans互操作的時候，會話終止了，而且，bean也不再擁有狀態(tài)值。SessionBean也可能是一個無狀態(tài)的SessionBean。無狀態(tài)的SessionBeans並不掌握它的客戶的資訊或者狀態(tài)。用戶能夠調(diào)用Beans的方法來完成一些操作。但是，Beans只是在方法調(diào)用的時候才知道用戶的參數(shù)變數(shù)。當(dāng)方法調(diào)用完成以後，Beans並不繼續(xù)保持這些參數(shù)變數(shù)。這樣，所有的無狀態(tài)的SessionBeans的實例都是相同的，除非它正在方法調(diào)用期間。這樣，無狀態(tài)的SessionBeans就能夠支持多個用戶。容器能夠聲明一個無狀態(tài)的SessionBeans，能夠?qū)⑷魏蜸essionBeans指定給任何用戶。2024年1月2日19時30分EJB框架

EntityBeans對數(shù)據(jù)庫中的數(shù)據(jù)提供了一種對象的視圖。例如：一個EntityBean能夠模擬資料庫表中一行相關(guān)的數(shù)據(jù)。多個Client能夠共用訪問同一個EntityBean。多個Client也能夠同時的訪問同一個EntityBean。EntityBeans通過事務(wù)的上下文來訪問或更新下層的數(shù)據(jù)。這樣，數(shù)據(jù)的完整性就能夠被保證。EntityBeans能存活相對教長的時間，並且狀態(tài)是持續(xù)的。只要資料庫中的數(shù)據(jù)存在，EntityBeans就一直存活。而不是按照應(yīng)用程式或者服務(wù)進(jìn)程來說的。即使EJB容器崩潰了，EntityBeans也是存活的。EntityBeans生命週期能夠被容器或者Beans自己管理。如果由容器控制著保證EntityBeans持續(xù)的issues。如果由Beans自己管理，就必須寫EntityBeans的代碼，包括訪問資料庫的調(diào)用。

EntityBeans是由主鍵（primarykey一種唯一的對象識別字）標(biāo)識的。通常，主鍵與標(biāo)識資料庫中的一塊數(shù)據(jù)，例如一個表中的一行的主鍵是相同的。主鍵使client能夠定位特定的數(shù)據(jù)塊。2024年1月2日19時30分EJB包容器包容器是組件的一種運行環(huán)境。組件駐留於包容器，而包容器為組件提供服務(wù)。類似地，包容器通常駐留於應(yīng)用程式伺服器，該伺服器為它和其他包容器提供運行環(huán)境。從技術(shù)上講，組件只與其包容器和包容器提供的資源相交互。由於包容器與應(yīng)用程式伺服器之間的介面沒有得到有效的定義，所以單獨的供貨商幾乎總是同時提供這二者，並且區(qū)分通常是沒有意義的。如果一個位於包容器與應(yīng)用程式伺服器之間的API被標(biāo)準(zhǔn)化，此時，區(qū)別將變得更為重要。

2024年1月2日19時30分EJB包容器編寫EJB組件的主要理由是為了利用包容器所提供的服務(wù)。理解這些服務(wù)的內(nèi)涵有助於確定，在設(shè)計過程中，應(yīng)該在什麼時候使用EJB組件，以及它們應(yīng)該扮演的角色。下麵是EJB包容器可以提供的一些服務(wù)。(1)持久化當(dāng)然，可以使用JDBCAPI直接讀寫資料庫。如果只需要讀一些數(shù)據(jù)，以便生成一個動態(tài)Web頁面，或者更新一些簡單的資訊，那麼這樣處理可能是合適的。如果讀者有更複雜的需求，EJB可以提供各種持久化服務(wù)。這些服務(wù)包括從簡單的池連接至自動化管理持久化，並且避免應(yīng)用程式開發(fā)人員編寫SQL代碼。除非使用一種類似於對象/關(guān)係映射框架的工具，編寫資料庫訪問代碼容易出錯並且耗時。在介紹沒有採用自動持久化的EJB時，EJB規(guī)範(fàn)意識到這種事實，“希望大多數(shù)的企業(yè)Bean將由應(yīng)用程式開發(fā)工具創(chuàng)建，這些工具將在組件中封裝資料庫訪問”。2024年1月2日19時30分EJB包容器

(2)聲明性事務(wù)JDBCAPI的確提供了管理事務(wù)的功能，而且該功能可以從Servlet或者JSP中得到較好的實現(xiàn)。然而，事務(wù)管理可能很複雜，尤其是，如果涉及多數(shù)據(jù)庫訪問組件與多數(shù)據(jù)源。EJB可以無需任何編碼就可以實現(xiàn)對複雜事務(wù)的管理。讀者可能已經(jīng)聽說過與事務(wù)管理相關(guān)的兩種JavaAPI。JTA或者JavaTransactionAPI，提供了事務(wù)管理器、應(yīng)用程式伺服器、資源管理器和應(yīng)用程式或應(yīng)用程式組件之間的一種標(biāo)準(zhǔn)介面。除了UserTransaction介面，該API中的任何一個介面都不是為應(yīng)用程式員所設(shè)計的，而且讀者可以也不應(yīng)該使用UserTransaction介面，甚至JTS(JavaTransactionService，Java事務(wù)服務(wù))似乎也不適合由應(yīng)用程式員直接使用。這是專門為開發(fā)商設(shè)計的規(guī)範(fàn)，用於映射JTA解決方案至CORBAObjectTransactionService1.1規(guī)範(fàn)。

2024年1月2日19時30分EJB包容器

(3)數(shù)據(jù)緩存在特定的環(huán)境下，EJB數(shù)據(jù)緩存可以導(dǎo)致應(yīng)用程式性能與伸縮性的顯著改善，並且不需要應(yīng)用程式開發(fā)人員編寫任何代碼。(4)安全性在每一個應(yīng)用程式中，必須保證對數(shù)據(jù)與業(yè)務(wù)邏輯的訪問功能的安全性開發(fā)人員可以使用Servlet或JSP頁面提供安全性，但是，這可能是一種複雜並且容易出錯的任務(wù)。如果多個Servlet或JSP頁面通過公用業(yè)務(wù)邏輯使用類。因此，應(yīng)用程式需要提供定制的安全框架，不需要任何編程就可以實現(xiàn)對EJB組件訪問的控制。2024年1月2日19時30分EJB包容器

(5)錯誤處理如果沒有一種確定且統(tǒng)一的出錯處理框架，應(yīng)用程式無論大小，都不太可能取得成功。EJB規(guī)範(fàn)明確定義了錯誤對事務(wù)、客戶端的結(jié)果、伺服器登錄和組件恢復(fù)的影響。(6)業(yè)務(wù)邏輯的組件框架開發(fā)複雜的業(yè)務(wù)邏輯軟體需要投入大量的企業(yè)資源。意識到這一點之後，軟體開發(fā)人員幾十年一直追求實現(xiàn)軟體的重用目標(biāo)。組件重用已經(jīng)成為最成功的策略之一。作為伺服器端組件的EJB，可以同時被多個客戶端使用，由於servlet和PSP表示的Web伺服器端表示邏輯，以及大量其他客戶端類型（諸如VisualBasic程式、Execl表單等）。如果應(yīng)用程式包含的業(yè)務(wù)邏輯需要大量的開發(fā)投資，EJB是一種可以獲得最大投資回報的理想途徑。2024年1月2日19時30分EJB包容器

(7)伸縮性與錯誤修復(fù)

EJB規(guī)範(fàn)要求應(yīng)用程式開發(fā)人員在編寫業(yè)務(wù)邏輯組件時遵循確定的規(guī)則。依靠這些規(guī)則，應(yīng)用程式伺服器才能實現(xiàn)對大量併發(fā)客戶端實施管理，這些客戶端對業(yè)務(wù)邏輯組件與數(shù)據(jù)訪問組件有明確的要求。同樣是依靠這些規(guī)則，應(yīng)用程式伺服器才能運行於集群環(huán)境（跨越大量的機(jī)器），並且對任何的群集結(jié)點錯誤實施修復(fù)。儘管Web伺服器也可以實施擴(kuò)展，但Web包容器卻不是為包含業(yè)務(wù)邏輯與資料庫訪問代碼的擴(kuò)展組件而設(shè)計的，EJB包容器就是如此。Web層的等價服務(wù)組件，JavaBean，只有通過定制化地編程才能實現(xiàn)“池”。Servlet或JSP則沒有提供這樣的機(jī)制。

2024年1月2日19時30分EJB包容器(8)可移植性儘管應(yīng)用程式開發(fā)人員可以提供與EJB包容器所提供的同樣服務(wù)，但是，必須單獨地開發(fā)與集成這些服務(wù)。如果商業(yè)環(huán)境對應(yīng)用程式提出了新的需求，這些新的需求必須通過定制代碼（或至少是購買必須人工集成的技術(shù)）來實現(xiàn)。由於EJB是為一種行業(yè)標(biāo)準(zhǔn)的API而編寫的，它們通常不需要改動就可以運行於一種提供了擴(kuò)展功能的新應(yīng)用程式伺服器。(9)可管理性管理包含業(yè)務(wù)邏輯與數(shù)據(jù)訪問的Web組件的基本問題在於，對於管理工具而言，它們是不可見的。例如，考察控制誰可以修改消費者的信用卡問題。用EJB實現(xiàn)該功能的安全性，開發(fā)人員只需要使用由EJB包容器提供的聲明性訪問控制。為了管理訪問，可以從合適的角色中增加或者刪除用戶。對於純粹用Web組件開發(fā)等價應(yīng)用程式，為了實現(xiàn)其安全性，開發(fā)人員必須保護(hù)對每一個用戶介面的訪問（即Web監(jiān)視）。

2024年1月2日19時30分包容器如何提供服務(wù)

無需太過深入的瞭解其細(xì)節(jié)，就可以幫助讀者掌握這種機(jī)制的一些思路。EJB包容器依靠該機(jī)制向EJB組件提供各種服務(wù)。該機(jī)制包含三種基本的思想。首先，使用EJB組件——客戶端、EJB包容器和EJB組件（以及在EJB2.0持久化管理器）的應(yīng)用程式的各部分之間明確定義了職責(zé)。這些職責(zé)的定義正式地稱為契約。其次，包容器提供的服務(wù)以這樣一種方式定義，即它們與組件保持垂直關(guān)係，也就是說，安全性、持久化、事務(wù)和其他服務(wù)與實現(xiàn)組件的業(yè)務(wù)邏輯的Java檔是分開的。再次，包容器仲介每個對EJB組件的調(diào)用，以便它可以提供服務(wù)。換句話說，在每個業(yè)務(wù)方法調(diào)用時，包容器將自己置於客戶與組件之間。2024年1月2日19時30分包容器如何提供服務(wù)

1.契約在這裏，契約是提供對軟體不同層次之間職責(zé)的一種簡單描述。如果軟體的每種層次都遵循各自的契約規(guī)則，它就可以與其上、下層次保持有效的協(xié)作，而不需要瞭解哪個層次的任何其他資訊。這通常意味著，只要遵循契約，不用重新編寫自己的代碼就可以合成與配匹層次。EJB1.1規(guī)範(fàn)包含一種合理定義的層次：客戶bean和包容器(EJB2.0補(bǔ)充了另一種層次，即持久化管理器)。作為這些層次之間契約的結(jié)果，bean可以無改動地運行於不同的包容器。客戶端可以不用改動地訪問不同的bean。當(dāng)然，編寫契約不僅僅是為了出於移植性的考慮。這些規(guī)則是經(jīng)過周密處理的，以便伺服器開發(fā)商可以基於不同的技術(shù)創(chuàng)建自己的多功能伺服器。Bean程式員可以遵循這些相對簡單的規(guī)則和型式，應(yīng)用這些應(yīng)用程式伺服器的服務(wù)與功能。2024年1月2日19時30分包容器如何提供服務(wù)Bean程式員就遵循哪些規(guī)則？主要有：EJB組件開發(fā)人員（又稱為bean提供者）必須在實現(xiàn)類中實現(xiàn)業(yè)務(wù)方法（對應(yīng)用程式邏輯提供訪問的任何方法）。Bean提供者必須實現(xiàn)ejbcreate()、ejbpostcreate()、ejbremove()方法，如果是包含bean管理持久化的實體bean，還必須實現(xiàn)ejbfind<METHOD>()方法。Bean提供者必須定義企業(yè)級bean的本地介面與遠(yuǎn)程介面。對於會話bean，bean提供者必須實現(xiàn)在javax.ejb.SessionBean介面中定義的包容器回調(diào)方法。對於實體bean，bean提供者必須實現(xiàn)在javax.ejb.EntityBean介面中定義的包容器回調(diào)方法。Bean提供者必須使用編程技巧，將它與包容器對企業(yè)級bean實例的運行時管理連接。2024年1月2日19時30分包容器如何提供服務(wù)

2.服務(wù)EJB包容器是為了給bean程式員提供服務(wù)而存在的。一般情況下，bean程式員只需要遵循規(guī)則就可以自動地利用這些服務(wù)。它們可以只通知包容器應(yīng)該提供什麼服務(wù)的詳細(xì)資料。這個“通知包容器”又稱為聲明性語法，並且是EJB的最優(yōu)特性之一。聲明性資訊是在稱為配置描述的檔中定義的。對於很多特性，甚至這種聲明性資訊也並非必需，並且包容器將提供特性，而根本無需bean程式員做任何工作。事務(wù)管理是包含EJB包容器的每個應(yīng)用程式伺服器都提供的服務(wù)之一。事務(wù)是系統(tǒng)在面臨衝突與故障而保持?jǐn)?shù)據(jù)一致性的機(jī)制。包容器將讓應(yīng)用程式開發(fā)人員確定——無需任何編程——如何處理由客戶端對企業(yè)數(shù)據(jù)的修改，以便保證一致性。2024年1月2日19時30分包容器如何提供服務(wù)

EJB包容器提供的另一種重要服務(wù)是自動持久化。這是一種可由bean開發(fā)人員選擇的特性，不過，它為很多專案提供了有價值的替換方法，從而避免編寫幾千行數(shù)據(jù)訪問代碼。還有很多每個包容器都將提供的服務(wù)。聲明性安全避免EJB資料的未經(jīng)授權(quán)訪問。資源管理（諸如，連接池）和併發(fā)控制方便了多用戶訪問。出錯處理便於應(yīng)用程式開發(fā)人員提高效率。通信服務(wù)簡化了遠(yuǎn)程訪問。2024年1月2日19時30分包容器如何提供服務(wù)有些包容器將提供可選的服務(wù)。大型專案的一個重要選項是包含錯誤修復(fù)與伸縮性的集群技術(shù)。管理工具不是EJB規(guī)則的組成部分，但是，伺服器開發(fā)商將其作為可選組件提供，並且對任何專案的成功與否至關(guān)重要。可用的服務(wù)選取項只受開發(fā)商想像力的局限。隨著JavaAPI的普及，這些附加的服務(wù)可能成為標(biāo)準(zhǔn)。即將發(fā)佈的管理API(JMX)就是這樣一個例子，它可以為管理方案提供最不常見的命名者。對於所有這些服務(wù)，最重要的是應(yīng)該知道，他們都是由包容器開發(fā)人員，而不是由業(yè)務(wù)邏輯程式員實現(xiàn)的。即使包容器開發(fā)人員完全不了解業(yè)務(wù)邏輯，這也是可行的，因為業(yè)務(wù)邏輯組件——EJB——遵循規(guī)範(fàn)所定義的契約。2024年1月2日19時30分包容器如何提供服務(wù)

3仲介應(yīng)用程式開發(fā)人員遵循bean開發(fā)契約的規(guī)則，而包容器因此可以提供系統(tǒng)級服務(wù)。不過，目前可行嗎？仍然存在大量需要處理的問題。編寫一種有效的EJB包容器是一件困難的任務(wù)。但是，存在一種核心的概念，即仲介，它可以簡單開發(fā)人員對EJB包容器的理解。

EJB包容器介入客戶端業(yè)務(wù)邏輯與EJB業(yè)務(wù)邏輯之間，提供諸如事務(wù)、安全性、出錯處理和持久化管理等服務(wù)。2024年1月2日19時30分包容器如何提供服務(wù)考察一個遠(yuǎn)程客戶端對企業(yè)級JavaBean的典型方法調(diào)用：●首先，客戶端執(zhí)行一個對RMIstub的調(diào)用?！裨揜MIstub仲介方法調(diào)用，以便調(diào)度參數(shù)、並且通過網(wǎng)路發(fā)送資訊?！袼欧鞫丝蚣芊凑{(diào)度參數(shù)，並且將它們交付EJB包容器。不過，方法調(diào)用還沒有涉及業(yè)務(wù)邏輯。現(xiàn)在，出現(xiàn)了第二個中介：●包容器將對方法調(diào)用者進(jìn)行安全性驗證?！袼鼘踊蛘呓槿肴魏涡枰氖聞?wù)?！袼鼘Τ志没瘮?shù)執(zhí)行任何必要的調(diào)用?！袼鼘痈鞣N回調(diào)，以便EJB組件能夠請求資源?！裰挥羞@些都完成之後，才調(diào)用實際的業(yè)務(wù)方法?！褚坏┧徽{(diào)用，包容器將執(zhí)行事務(wù)、持久化、回調(diào)等任務(wù)?！褡钺?，業(yè)務(wù)方法的結(jié)果將被發(fā)送回遠(yuǎn)程客戶端，可能是一個返回數(shù)據(jù)，也可能是一個異常。

2024年1月2日19時30分包容器如何提供服務(wù)這解釋了EJB技術(shù)中比較抽象的部分。應(yīng)用程式開發(fā)人員將編寫一個聲明其業(yè)務(wù)邏輯的介面，並且還需要編寫實現(xiàn)這些方法的類。不過，如上所述，該類不需要實現(xiàn)介面，實際上，這裏強(qiáng)烈建議程式員不要在自己的業(yè)務(wù)邏輯類中實現(xiàn)該介面。因此，在介面中的遠(yuǎn)程方法調(diào)用是如何一步步地到達(dá)對應(yīng)的業(yè)務(wù)邏輯實現(xiàn)方法呢？基本上，已經(jīng)用一種命名慣例進(jìn)行了替換介面實現(xiàn)。包容器將使用Java仲介——無論是配置EJB，還是運行EJB——配匹介面中的方法與實現(xiàn)中的函數(shù)。

2024年1月2日19時30分EJB類型此前曾介紹過，EJB是中間層中的伺服器方業(yè)務(wù)邏輯組件。實際上，EJB類型有幾種：會話Bean(Sessionbeans)實體Bean(Entitybeans)消息驅(qū)動的Bean(Message-drivenbeans)下麵介紹每種EJB類型及其作用。

2024年1月2日19時30分EJB類型顧名思義，會話Bean的壽命與所在客戶會話的壽命一樣長，即在這個客戶交互期間有效。這樣會話Bean可以分為下列幾種：無狀態(tài)會話Bean——不聲明任何實例（類型）變數(shù)。因此，每個方法只能操作局部參數(shù)，無法在方法調(diào)用之間維護(hù)狀態(tài)。狀態(tài)會話Bean——在方法調(diào)用之間維護(hù)狀態(tài)。這種會話Bean在類定義中聲明實例變數(shù)?？蛻粼诜椒ㄕ{(diào)用期間設(shè)置這些變數(shù)的值，在其他方法調(diào)用期間使用這些變數(shù)的值。

2024年1月2日19時30分EJB類型從上述介紹可以看出，無狀態(tài)會話Bean與狀態(tài)會話Bean的主要差別（從Bean開發(fā)人員角度看）是實例變數(shù)的聲明。具體地說，任何具有類級變數(shù)聲明的會話Bean都是狀態(tài)會話Bean。不難看出，無狀態(tài)會話Bean能提供很好的伸縮性，因為容器不需要在方法調(diào)用之間記住Bean狀態(tài)。但是，保存EJB狀態(tài)需要大量資源，因此狀態(tài)會話Bean比無狀態(tài)會話Bean在伺服器中涉及更多工作。因此，在應(yīng)用程式中使用狀態(tài)會話Bean之後，可能減少其伸縮性。2024年1月2日19時30分EJB類型

(2)實體Bean實體Bean用於映射基礎(chǔ)資料庫表格，生成資料庫的對象視圖。例如，如果資料庫中有表格Customer,則可以生成一個實體Bean，將表中每一行映射到Bean，表中每一列映射到Bean的相應(yīng)實例變數(shù)。這樣，實體Bean總是狀態(tài)Bean。實體Bean根據(jù)誰負(fù)責(zé)同步Bean狀態(tài)（實例變數(shù)值）與基礎(chǔ)資料庫而進(jìn)行分類。因此，可以將實體Bean分為下麵幾類：容器管理的持久性（CMP，Container-managedpersistence）這裏容器負(fù)責(zé)同步Bean狀態(tài)（實例變數(shù)值）與基礎(chǔ)資料庫?？蛻粼趬勖L期中可以多次修改Bean狀態(tài)，多個客戶可能在不同時間修改Bean狀態(tài)。容器要負(fù)責(zé)保證使用CMPBean時的數(shù)據(jù)一致性與完整性。容器提供同步狀態(tài)所需的代碼，主要是INSERT、MODIFY、DELETE之類的SQL語句。容器在Bean部署時自動產(chǎn)生所有這些語句。但一定要注意的是，CMP要求基礎(chǔ)資料庫是關(guān)係型的。

2024年1月2日19時30分EJB類型

Bean管理的持久性（BMP，Bean-managedpersistence）這裏Bean編程人員負(fù)責(zé)同步Bean狀態(tài)（實例變數(shù)值）與基礎(chǔ)資料庫。Bean編程人員要在Bean實現(xiàn)類中編碼所有需要的SQL語句和JDBC調(diào)用。容器負(fù)責(zé)在適當(dāng)時候通過回調(diào)方法調(diào)用這個代碼，跟蹤Bean狀態(tài)何時搞髒和需要同步。相應(yīng)地，它調(diào)用Bean實現(xiàn)類中的回調(diào)方法，Bean編程人員負(fù)責(zé)提供必要的同步代碼。

CMP容器直接提供服務(wù)，而BMP實體Bean還需要Bean編程人員增加編程，為什麼用BMP呢？有時需要增加設(shè)計靈活性或在非關(guān)係型存儲中支持持久性。例如，EJB規(guī)範(fàn)V1.1只允許實例變數(shù)和表格列之間的一對一映射。這樣，使用這個版本時，如果要在實體Bean中表示在多個表格中存儲狀態(tài)的累計對象，則無法使用BMP。EJB2.0規(guī)範(fàn)定義了複雜查詢語言（QL,QueryLanguage），用於持久性管理。2024年1月2日19時30分EJB類型

(3)消息驅(qū)動的Bean消息在當(dāng)今的分佈式電腦體系結(jié)構(gòu)中起著重要作用。消息本身是非同步的，而方法調(diào)用通常是同步的。如果要向EJB中實現(xiàn)的業(yè)務(wù)邏輯發(fā)送一個消息，怎麼辦？由於消息本身是非同步的，因此發(fā)消息時不能保證訪問Bean。這樣，應(yīng)用程式接收消息時需要生成或啟動Bean。這裏就需要用到消息驅(qū)動的Bean。消息驅(qū)動的Bean是在收到非同步消息時驅(qū)動的。消息驅(qū)動Bean是EJB2.0規(guī)範(fàn)中增加的。

2024年1月2日19時30分EJB中的角色

EJB2.0規(guī)範(fàn)定義了以下六種不同的角色來完成其任務(wù)。(1)企業(yè)bean開發(fā)者企業(yè)bean開發(fā)者負(fù)責(zé)開發(fā)執(zhí)行商業(yè)邏輯規(guī)則的EJB組件，開發(fā)出的EJB組件打包成ejb-jar檔。企業(yè)bean開發(fā)者負(fù)責(zé)定義EJB的遠(yuǎn)程介面和自身介面，編寫執(zhí)行商業(yè)邏輯的企業(yè)bean類，提供部署EJB的部署描述符(Deploymentdescriptor)。部署描述符包含EJB的名字，EJB用到的資源配置，如JDBC等。企業(yè)bean開發(fā)者是典型的商業(yè)應(yīng)用開發(fā)領(lǐng)域?qū)＜摇?024年1月2日19時30分EJB中的角色(2)應(yīng)用組裝者應(yīng)用組裝者負(fù)責(zé)利用各種EJB組裝成大的可部署的應(yīng)用系統(tǒng)單元。應(yīng)用組裝者根據(jù)企業(yè)bean開發(fā)者提供的ejb-jar檔，創(chuàng)建出包含應(yīng)用組裝說明的ejb-jar檔。應(yīng)用組裝者有時還需要提供一些相關(guān)的程式，如在一個電子商務(wù)系統(tǒng)裏，應(yīng)用組裝者需要提供JSP程式。應(yīng)用組裝者必須掌握所用的EJB的自身介面和遠(yuǎn)程介面，但不需要知道這些介面的實現(xiàn)。2024年1月2日19時30分EJB中的角色

(3)部署者部署者負(fù)責(zé)將企業(yè)bean開發(fā)者或應(yīng)用組裝者的ejb-jar檔部署到用戶的系統(tǒng)環(huán)境中。系統(tǒng)環(huán)境包含某種EJB伺服器和EJB容器。部署者必須保證所有由EJB組件開發(fā)者在部署檔中聲明的資源可用，例如，部署者必須配置好EJB所需的資料庫資源。部署過程分兩步：部署者首先利用EJB容器提供的工具生成一些類和介面，使EJB容器能夠利用這些類和介面在運行狀態(tài)管理EJB。部署者把EJB組件和其他在上一步生成的類安裝到EJB容器中。部署者是某個EJB運行環(huán)境的專家。2024年1月2日19時30分EJB中的角色(4)EJB伺服器提供者EJB伺服器提供者是系統(tǒng)領(lǐng)域的專家，精通分佈式交易管理，分佈式對象及其它系統(tǒng)級的服務(wù)。一個典型的EJB伺服器提供者是一個操作系統(tǒng)開發(fā)商、中間件開發(fā)商或資料庫開發(fā)商。在目前的EJB規(guī)範(fàn)中，假定EJB伺服器提供者和EJB容器提供者來自同一個開發(fā)商，所以，沒有定義EJB伺服器提供者和EJB容器提供者之間的介面標(biāo)準(zhǔn)。2024年1月2日19時30分EJB中的角色

(5)EJB容器提供者EJB容器提供者提供以下功能：提供部署企業(yè)bean所需的部署工具。提供對已部署好企業(yè)bean實例運行時刻的支持。由企業(yè)bean看來，EJB容器是目標(biāo)系統(tǒng)環(huán)境的一部分。EJB容器為部署企業(yè)bean提供運行環(huán)境，EJB容器負(fù)責(zé)為企業(yè)bean提供事務(wù)管理，安全管理等服務(wù)。

EJB容器提供者必須是系統(tǒng)級的編程專家，還要具備一些應(yīng)用領(lǐng)域的經(jīng)驗。EJB容器提供者的工作主要集中在開發(fā)一個可伸縮的，具有事務(wù)管理功能的集成在EJB伺服器中的容器。EJB容器提供者為企業(yè)bean開發(fā)者提供了一組標(biāo)準(zhǔn)的、易用的API訪問EJB容器，使EJB組件開發(fā)者不需要瞭解EJB伺服器中的各種技術(shù)細(xì)節(jié)。

EJB容器提供者負(fù)責(zé)提供系統(tǒng)監(jiān)測工具用來即時監(jiān)測EJB容器和運行在容器中的EJB組件狀態(tài)。2024年1月2日19時30分EJB中的角色

(6)系統(tǒng)管理員系統(tǒng)管理員負(fù)責(zé)為EJB伺服器和容器提供一個企業(yè)級的計算和網(wǎng)路環(huán)境。系統(tǒng)管理員負(fù)責(zé)利用EJB伺服器和容器提供的監(jiān)測管理工具監(jiān)測EJB組件的運行情況。

2024年1月2日19時30分EJB中的角色企業(yè)應(yīng)用具備系統(tǒng)級服務(wù)的容器在企業(yè)特定應(yīng)用環(huán)境中配置的容器系統(tǒng)管理員安裝容器其他組件一個ejb-jar檔中的企業(yè)bean一個ejb-jar檔中的企業(yè)beanEJB容器提供者和服務(wù)器提供者企業(yè)bean開發(fā)者編寫商業(yè)邏輯業(yè)務(wù)問題包含應(yīng)用組裝說明的ejb-jar檔等部署者應(yīng)用組裝者2024年1月2日19時30分EJB的特性

(1)分佈式事務(wù)的支持隨著電腦網(wǎng)絡(luò)技術(shù)的發(fā)展，應(yīng)用程式開發(fā)人員所面臨的最複雜的問題之—是編寫分佈式事務(wù)應(yīng)用程式。EJB支持分佈式事務(wù)；EJB技術(shù)可編用訪問跨越多個EJB伺服器的多重分佈式資料庫的應(yīng)用程式。EJB規(guī)範(fàn)允許在部署階段就以聲明的形式指出事務(wù)行為，而管理事務(wù)行為的負(fù)擔(dān)被轉(zhuǎn)移給伺服器，特別是轉(zhuǎn)移給容器和EJB伺服器提供者。如果Bean的開發(fā)人員有更高的事務(wù)需求，則可使Bean通過程式來管理事務(wù)界限。

2024年1月2日19時30分EJB的特性

(2)安全性能安全是所有企業(yè)產(chǎn)品的需求。EJB組件模型充分發(fā)揮了核心Java平臺安全模型的作用，兩種設(shè)置安全的方法。第一、可以在Bean的EJB-JAR檔中設(shè)置安全描述符；第二、可以使用java.security包實現(xiàn)對安全的程式化管理。(3)EJB是獨立於對象的通信協(xié)議首先、它可以使編寫客戶端應(yīng)用程式的程式員免於選擇通信協(xié)議。其次，它允許EJB伺服器的建立者實現(xiàn)對其用戶最為重要的協(xié)議。例如，ORB提供者可能僅僅實現(xiàn)CORBA協(xié)議，而Unix提供者則可能實現(xiàn)RMI和CORBA協(xié)議。但無論如何,所用協(xié)議對Bean的開發(fā)人員是透明的，僅僅針對Java平臺來編寫程式。

2024年1月2日19時30分認(rèn)證

認(rèn)證是指用戶向系統(tǒng)證明他是誰的過程。在J2EE中，應(yīng)用伺服器使用認(rèn)證來控制客戶端對應(yīng)用程式或組件的訪問。

J2EE中的用戶、域和組（1）域域代表使用相同認(rèn)證方式的一群用戶。如在J2EE中有兩個域：Certificate和Default。Certificate用於在HTTP協(xié)議中認(rèn)證WEB用戶，伺服器在認(rèn)證該類用戶時，需使用X509證書。而Default域用於除WEB流覽器用戶之外的所有用戶。（2）組組只適應(yīng)於Default域，它是對用戶的邏輯分類，Default域中每一用戶都可屬於一個組。2024年1月2日19時30分客戶端認(rèn)證

J2EE認(rèn)證服務(wù)對客戶端的訪問進(jìn)行控制。當(dāng)一個J2EE應(yīng)用程式客戶端開始運行時，容器會打開一個窗口要求用戶輸入用戶名和密碼。容器認(rèn)證通過後，產(chǎn)生一個安全的Context對象和此用戶聯(lián)繫起來，用戶每次調(diào)用容器中的Bean時，都需要使用此對象來獲得安全性資訊。當(dāng)客戶端要訪問受保護(hù)的WEB層資源時，WEB容器啟動為該資源設(shè)置的認(rèn)證機(jī)制，對用戶進(jìn)行認(rèn)證。設(shè)置WEB資源的認(rèn)證機(jī)制有3種方法：HTTP基本認(rèn)證、基於表單的認(rèn)證和客戶端認(rèn)證證書認(rèn)證。2024年1月2日19時30分認(rèn)證

（1）HTTP基本認(rèn)證如果設(shè)置此種認(rèn)證機(jī)制，WEB容器使用WEB客戶端獲取的用戶名和密碼進(jìn)行身份認(rèn)證，這各認(rèn)證方式?jīng)]有經(jīng)過加密。（2）基於表單的認(rèn)證這種認(rèn)證方式允許用戶自己定制登錄介面?？梢赃x擇如果認(rèn)證失敗或出錯，要把用戶導(dǎo)向哪一個錯誤提示頁面。這種認(rèn)證方式也沒有經(jīng)過加密。（3）客戶端認(rèn)證證書如果設(shè)置此種認(rèn)證方式，伺服器使用X.509證書認(rèn)證客戶端，是最安全的一種方式，在此種認(rèn)證方式的數(shù)據(jù)傳輸使用了SSL，所有數(shù)據(jù)都消費品了安全層的加密。2024年1月2日19時30分授權(quán)

授權(quán)是指應(yīng)用伺服器授予某個用戶訪問哪些Bean的哪些方法的許可權(quán)，用戶可為每一個Bean的每一個方法設(shè)置其安全性。一般分為三步：（1）定義角色（2）設(shè)置Bean的方法的訪問許可權(quán)（3）把角色映射到用戶或組。2024年1月2日19時30分安全授權(quán)的傳遞

如果有兩個Bean，第一個Bean需要調(diào)用第二個Bean的某種方法，有兩種方式進(jìn)行授權(quán)：（1）讓第二個Bean繼承第一個Bean的授權(quán)（2）單個授權(quán)J2EE概述J2EE產(chǎn)生背景J2EE技術(shù)

J2EE產(chǎn)生背景J2EE由來體系結(jié)構(gòu)實現(xiàn)多層應(yīng)用程式的解決方案J2EE由來90年代早期，傳統(tǒng)企業(yè)資訊系統(tǒng)提供商通過從兩層，客戶端/伺服器應(yīng)用模型向靈活的三層和多層應(yīng)用模型的遷移回應(yīng)客戶的需求。新模型將業(yè)務(wù)邏輯從系統(tǒng)服務(wù)和用戶介面分離出來，將其作為中間層擺在這二者之間。新的中間件服務(wù)，事務(wù)監(jiān)控，面向消息中間件，對象請求代理等的發(fā)展為這種新的架構(gòu)提供了推動力。這時的Internet或Intranet使用的增長顯露出原有編程模型對生成易於分佈的客戶端的不足。多層結(jié)構(gòu)設(shè)計戲劇性地簡化了開發(fā)、布署和維護(hù)企業(yè)應(yīng)用。使應(yīng)用開發(fā)者可以專注於業(yè)務(wù)邏輯細(xì)節(jié)的編程，依靠後端服務(wù)提供基本服務(wù)，客戶端應(yīng)用(包括獨立和Web流覽器包容)提供用戶交互。開發(fā)完成之後，業(yè)務(wù)邏輯根據(jù)實際的需要部署在伺服器上。然而，除了這些優(yōu)點，模型制訂了開發(fā)者的從標(biāo)準(zhǔn)化組件建立應(yīng)用，在廣泛的不同的平臺上部署單個應(yīng)用或簡單地制定應(yīng)用規(guī)模來適應(yīng)變化中的業(yè)務(wù)狀況的能力。J2EE由來

這些努力都導(dǎo)向J2EE技術(shù)的形成。首先，JavaServlets技術(shù)顯示開發(fā)者熱衷於生成運行於任何支持Java平臺的Web伺服器上的類似於CGI的行為。第二，JDBC技術(shù)提供了將“一次編寫，到處運行”的Java編程語言與已有的資料庫管理系統(tǒng)結(jié)合的模型。最後，EnterpriseJavaBeans的成功顯示了將一系列完整行為封裝到易於配置，已有的可重用組件中是非常有用的。這三點集中到一起，Java語言編寫的伺服器端行為，連接已有的企業(yè)系統(tǒng)和模組的連接器，易於部署的組件，最終結(jié)合形成J2EE。體系結(jié)構(gòu)

在電子商務(wù)迅猛發(fā)展的今天，商業(yè)社會的各個部門需要依賴企業(yè)級應(yīng)用程式來共同完成自己的工作，比如：企業(yè)之間需要線上交易；企業(yè)的電子商務(wù)網(wǎng)站需要使用銀行的系統(tǒng)進(jìn)行線上支付和結(jié)算；企業(yè)要進(jìn)行網(wǎng)上分銷和採購；政府部門的城市規(guī)劃需要使用網(wǎng)路來進(jìn)行招標(biāo)投標(biāo)等等?？梢灶A(yù)見，在不久的將來，企業(yè)級的應(yīng)用程式將大大影響社會經(jīng)濟(jì)的發(fā)展。開發(fā)企業(yè)級應(yīng)用程式的關(guān)鍵是在強(qiáng)調(diào)時間性（即適時性）的同時，還要求程式部署方便、移植靈活、容易升級和更新等。這對應(yīng)用程式開發(fā)人員提出了兩個基本的開發(fā)要求：快速和有效。那麼快速開發(fā)和部署高質(zhì)量的應(yīng)用程式的關(guān)鍵又是什麼呢？是“體系結(jié)構(gòu)”，或者說是編程的模型。在電腦領(lǐng)域裏，“Model”和“Architecture”兩詞佔有相當(dāng)重要的地位：好的模型常常能夠讓程式的開發(fā)工作事半功倍；好的體系結(jié)構(gòu)通過合理的層次劃分不僅可以提高開發(fā)效率，而且還可以為程式的升級和移植提供便利。體系結(jié)構(gòu)

每當(dāng)談到企業(yè)級應(yīng)用開發(fā)的時候，都會提到N層體系結(jié)構(gòu)。典型的客戶/伺服器系統(tǒng)是基於兩層結(jié)構(gòu)的，其中在數(shù)據(jù)層和表示層/業(yè)務(wù)邏輯層之間有著清晰的界線。這類應(yīng)用一般都是數(shù)據(jù)驅(qū)動的，應(yīng)用在客戶機(jī)上，並且在企業(yè)中會配置一個資料庫伺服器。雖然在這種結(jié)構(gòu)下，企業(yè)內(nèi)部可以共用數(shù)據(jù)，但是它有許多缺點。

體系結(jié)構(gòu)

（1）2層體系結(jié)構(gòu)（C/S）在傳統(tǒng)的2級結(jié)構(gòu)中，處理負(fù)載都位於客戶PC機(jī)上，而伺服器僅充當(dāng)了應(yīng)用程式和數(shù)據(jù)之間的傳輸控制器。結(jié)果，不僅應(yīng)用程式的性能受限於PC機(jī)資源，而且網(wǎng)路流量也增加了。當(dāng)整個應(yīng)用程式都在PC機(jī)上運行時，在把結(jié)果呈現(xiàn)給用戶之前，應(yīng)用程式不得不多次訪問資料庫，這種多次訪問資料庫的方式浪費了網(wǎng)路帶寬。

2層體系結(jié)構(gòu)的另外一個問題是可維護(hù)性。哪怕是對應(yīng)用程式的一個小小的修改都會涉及到把整個應(yīng)用重新分發(fā)給用戶。即使這個過程是自動化的，仍然要在每一個客戶機(jī)上更新應(yīng)用的問題。另外，一些用戶可能還來不及更新整個應(yīng)用程式，而其他一些用戶已經(jīng)及時作了更新，就會造成不同的客戶使用的應(yīng)用程式版本不一致。體系結(jié)構(gòu)

(2)3層體系結(jié)構(gòu)為了解決這些問題，軟體界提出了一種3層體系結(jié)構(gòu)的概念。應(yīng)用層被劃分為幾個相互隔離的邏輯層。每一邏輯層都定義好一套介面集。第一層，也就是表示層，主要由類似於圖形用戶介面的部分組成；中間層，即業(yè)務(wù)層，由應(yīng)用邏輯和業(yè)務(wù)邏輯構(gòu)成；而第3層——數(shù)據(jù)層——包括了應(yīng)用程式所需要的數(shù)據(jù)。中間層（應(yīng)用邏輯）代碼由用戶調(diào)用（通過表示層）來獲取所需要的數(shù)據(jù)。表示層接收數(shù)據(jù)並且按照適當(dāng)?shù)母袷斤@示出來。從用戶介面中分離出來的應(yīng)用邏輯，極大地增強(qiáng)了應(yīng)用程式設(shè)計的靈活性。在應(yīng)用邏輯對表示層提供了一套定義清晰的介面的情況下，甚至不用改變應(yīng)用邏輯部分，就可以建立和分發(fā)多種用戶介面。2024年1月2日19時30分體系結(jié)構(gòu)

用戶介面應(yīng)用邏輯XML文檔DB體系結(jié)構(gòu)

第3層包含了應(yīng)用程式所需要的數(shù)據(jù)。這些數(shù)據(jù)可以由不同的資訊源組成。例如Oracle和Sybase那樣的資料庫，也可以是XML文檔（按照XML規(guī)範(fàn)存放的數(shù)據(jù)）集，還可以是如LDAP伺服器的目錄服務(wù)。除了傳統(tǒng)的關(guān)係資料庫存儲機(jī)制外，還有許多種應(yīng)用程式可以訪問的不同的企業(yè)數(shù)據(jù)源。然而，對應(yīng)的層次劃分還沒有終止，最終的目的是創(chuàng)建N層體系結(jié)構(gòu)的應(yīng)用。體系結(jié)構(gòu)

在N層體系結(jié)構(gòu)中，要較快地定義各個應(yīng)用層並不容易。實際上，一個N層結(jié)構(gòu)系統(tǒng)能夠支持多種不同的配置，在N層結(jié)構(gòu)中，應(yīng)用邏輯的劃分是根據(jù)功能而不是根據(jù)物理方面來進(jìn)行的。

N層結(jié)構(gòu)的劃分方式如下：

(1)用戶介面層：負(fù)責(zé)處理用戶與應(yīng)用程式之間的交互過程；它可以是一個通過防火牆運行的WEB流覽器，也可以是一般的桌面應(yīng)用程式，甚至還可以是無線設(shè)備。

(2)表示邏輯層，定義了用戶介面要顯示的內(nèi)容和如何處理用戶的請求——根據(jù)所支持的是什麼樣的用戶介面。對於相應(yīng)的客戶，表示邏輯層版本會有相應(yīng)的不同。體系結(jié)構(gòu)(3)業(yè)務(wù)邏輯層：通過與應(yīng)用數(shù)據(jù)打交道，對應(yīng)的業(yè)務(wù)規(guī)則實施建模。(4)基礎(chǔ)框架服務(wù)層：提供了應(yīng)用系統(tǒng)需要的其他功能，如傳輸消息、事務(wù)支持等等。(5)數(shù)據(jù)層：存放企業(yè)的應(yīng)用數(shù)據(jù)?；哆@種結(jié)構(gòu)的應(yīng)用程式採用了模型—視圖—控制器（Model–View–Controller,MVC）模式。採用這種模式的目的是要把數(shù)據(jù)（模型）與如何表示資訊的部分（視圖）分離出來。它們兩者之間是由應(yīng)用/業(yè)務(wù)邏輯（控制器）來控制資訊的流向。通過這種模式，就能設(shè)計出基於三種相互交互的功能組件（模型、視圖、控制器）的應(yīng)用程式。2024年1月2日19時30分體系結(jié)構(gòu)流覽器XML文檔DB表示邏輯業(yè)務(wù)邏輯應(yīng)用客戶服務(wù)防火牆體系結(jié)構(gòu)(4)企業(yè)結(jié)構(gòu)到目前為止，所有的討論只集中在單個應(yīng)用程式的結(jié)構(gòu)上，而實際上，把這些應(yīng)用程式看作是獨立而封閉的是不行的。也就是說，不能僅僅把這些應(yīng)用看成是不同的——甚至可能是不同體系結(jié)構(gòu)的——它們之間不相互通信。在企業(yè)中，應(yīng)當(dāng)尋找一種內(nèi)在統(tǒng)一的、整體的方式來對待這些應(yīng)用。不需要在結(jié)構(gòu)上作變動——企業(yè)級結(jié)構(gòu)本質(zhì)上是N層的——需要在對應(yīng)的認(rèn)識上作一些變化。要把N層結(jié)構(gòu)應(yīng)用到企業(yè)級系統(tǒng)中，只需要簡單地考慮用多個應(yīng)用對象而不是單個簡單應(yīng)用來擴(kuò)展中間層。這些應(yīng)用對象都必須有各自的介面，從而允許它們之間相互協(xié)調(diào)工作。體系結(jié)構(gòu)介面就像契約。每個對象通過介面來接受一定的參數(shù)，並返回相應(yīng)的結(jié)果集。應(yīng)用對象通過使用介面來進(jìn)行相互之間的通信。就企業(yè)級結(jié)構(gòu)來說，在各個部門之間採用一組通用的組件就可以實現(xiàn)多種應(yīng)用。從而，通過創(chuàng)建一套具有業(yè)務(wù)功能的模組集合使整個企業(yè)訪問，就可以使各種商業(yè)實踐標(biāo)準(zhǔn)化。如果商業(yè)規(guī)則發(fā)生了變化，那麼只需要對商業(yè)對象做修改就行了；若有必要的話，也可以修改介面，那就需要修改訪問該介面的任務(wù)對象。要注意的重要的一點是：當(dāng)在設(shè)計應(yīng)用對象及其介面時，最好盡可能使得介面通用化，以免以後修改。因為其他對象通過應(yīng)用對象的介面而不是其本身進(jìn)行通信的，所以修改對象本身與修改介面相比，前者要相對簡單和快捷得多。實現(xiàn)多層應(yīng)用程式的解決方案(1)微軟.NET體系結(jié)構(gòu)微軟.NET體系結(jié)構(gòu)是WindowsDNA體系結(jié)構(gòu)的升級版本。.NET平臺最重要的部分是.NETFramework，這是一個與操作系統(tǒng)緊密相關(guān)的綜合運行環(huán)境，它包括面向組件的中間層基礎(chǔ)結(jié)構(gòu)COM+、CLR(CommonLanguageRuntime)環(huán)境、一個運行時的編譯器和一組使用.NET組件模型的操作系統(tǒng)庫。程式員的開發(fā)工具是VisualStudio.NET。表示層程式員使用VisualStudio.NET來定義向瘦客戶端系統(tǒng)提交HTML頁面格式的顯示邏輯；商務(wù)層程式員使用VisualStudio.NET以多種語言實現(xiàn)商務(wù)邏輯，然後將商務(wù)邏輯打包為COM+組件。VisualStudio.NET是中性的語言，也就是說應(yīng)用程式可以採用多種語言開發(fā)，然後集成到一塊，這一點可以說是.NET一大優(yōu)勢。.NET的伺服器端組件可用微軟公司開發(fā)的VB.NET、VC.NET、C#等語言編寫。微軟公司把不同語言編寫的組件COM翻譯成一種中間語言(MicrosoftIntermediateLanguage)，實現(xiàn)了程式的“跨語言”特性，這種中間語言通過CLR（CommonLanguageRuntime）執(zhí)行（CLR類似於Java中的JRE）。將語言特性合併到一種通用運行語言CLR中，而不是合併到一種特定的語言中，這使得各種語言可以自由地在整個.NET平臺內(nèi)互用。實現(xiàn)多層應(yīng)用程式的解決方案

客戶端（流覽器、無線設(shè)備等）採用ASP.NET與伺服器端組件交互；伺服器組件通過ADO.NET訪問資料庫；組件運行於MTS或COM+中；消息處理採用MSMQ。此外.NET還支持多種伺服器：最新的.NET企業(yè)級伺服器是ApplicationCenterServer（應(yīng)用中心伺服器）；InternetSecurityandAccelerationServer(Internet安全與加速伺服器，ISAServer)重點解決表示層的需求；BizTalkServer是一個綜合的集成產(chǎn)品；CommerceServer是用於創(chuàng)建電子商務(wù)站點的架構(gòu)，它重點是解決電子商務(wù)零售業(yè)務(wù)的需求，使用CommerceServer提供的組件，並進(jìn)行專門化，就可以快速地創(chuàng)建電子商務(wù)零售網(wǎng)站。

.NET的缺點是從開發(fā)到部署到運行，都只能採用微軟公司的平臺。此外，由於.NET還不夠成熟，所以它的市場份額並不高。實現(xiàn)多層應(yīng)用程式的解決方案

(2)SunJ2EE體系結(jié)構(gòu)J2EE是由Sun公司領(lǐng)導(dǎo)、多家公司共同參與制定的一個企業(yè)應(yīng)用程式開發(fā)標(biāo)準(zhǔn)。熟悉Java語言的人都知道，Java2平臺有3個版本，它們分別是適用於小型設(shè)備和智能卡的Java2平臺Micro版（Java2PlatformMicroEdition,J2ME）、適用於桌面系統(tǒng)的Java2平臺標(biāo)準(zhǔn)版（Java2PlatformStandardEdition,J2SE）、適用於創(chuàng)建伺服器應(yīng)用程式和服務(wù)的Java2平臺企業(yè)版(Java2PlatformEnterpriseEdition,J2EE)。SunJ2EE並不像微軟公司的.NET那樣是一系列的產(chǎn)品，而是一個規(guī)範(fàn)和標(biāo)準(zhǔn)，任何一家公司都可以依據(jù)這些規(guī)範(fàn)和標(biāo)準(zhǔn)來開發(fā)自己的產(chǎn)品。Sun公司的目的就是讓多個廠家共同參與這個規(guī)範(fàn)的制定，這樣，只要以這樣的規(guī)範(fàn)來開發(fā)自己的產(chǎn)品就能給用戶帶來更大的開放性和可移植性，正是因為如此，基於Java的應(yīng)用伺服器要比.NET多得多。Java的開放性和Java本身具有的“一次編寫、到處執(zhí)行”的跨平臺性使得J2EE在企業(yè)分佈式計算領(lǐng)域中佔據(jù)了很大的優(yōu)勢。後面將介紹到J2EE的相關(guān)技術(shù)。J2EE技術(shù)J2EE框架分佈式結(jié)構(gòu)和J2EEJ2EE相關(guān)技術(shù)EJB與JavaBean

J2EE框架J2EE是Sun公司推出的一種全新概念的模型，與傳統(tǒng)的互聯(lián)網(wǎng)應(yīng)用程式模型相比有著不可比擬的優(yōu)勢。J2EE是一種利用Java2平臺來簡化諸多與多級企業(yè)解決方案的開發(fā)、部署和管理相關(guān)的複雜問題的體系結(jié)構(gòu)。J2EE技術(shù)的基礎(chǔ)就是核心Java平臺或Java2平臺的標(biāo)準(zhǔn)版，J2EE不僅鞏固了標(biāo)準(zhǔn)版中的許多優(yōu)點，例如“編寫一次，到處運行”的特性。方便存取資料庫的JDBCAPI、CORBA技術(shù)以及能夠在Internet應(yīng)用中保護(hù)數(shù)據(jù)的安全模式等等，同時還提供了對EJB、JavaServletsAPI、JSP以及XML技術(shù)的全面支持。J2EE使用了EJBServer作為商業(yè)組件的部署環(huán)境，在EJBServer中提供了分佈式計算環(huán)境中組件需要的所有服務(wù)，例如組件生命週期的管理、資料庫連接的管理、分佈式事務(wù)的支持、組件的命名服務(wù)等等。有些企業(yè)級的EJBServer，例如Sybase公司的EAS3.6(EnterpriseApplicationServer)還提供了支持高可用性和高性能的群集技術(shù)、失敗的自動轉(zhuǎn)移和恢復(fù)、應(yīng)用負(fù)載的自動均衡能力等。實現(xiàn)商業(yè)邏輯的EJB組件可以更加高效地運行在應(yīng)用伺服器中，支持多種客戶端的訪問，HTTP的客戶端可以先向運行在WebServer上的JavaServlet或者JSP發(fā)出請求，在JSP中嵌入Java的代碼調(diào)用運行在EJBServer中的EJB，以實現(xiàn)商業(yè)邏輯；而其他的客戶端，可以通過IIOP直接訪問運行在EJBServer中的組件。J2EE框架JDBCJMSJNDIIIOPRMIJavaMail(X)HTML/XMLApplet客戶應(yīng)用程式Web包容器ServletsJSPs標(biāo)記庫EJB包容器會話Beans實體BeansRDMSJava應(yīng)用程式CORBA伺服器郵件伺服器消息佇列目錄服務(wù)HTTP(S)J2EE應(yīng)用伺服器客戶數(shù)據(jù)應(yīng)用邏輯圖5J2EE總體結(jié)構(gòu)JNDIJTARMI/IIOPJDBCJMSJavaMailJAFJNDIJTARMI/IIOPJDBCJMSJavaMailJAFJ2EE框架一個多層的分佈式的應(yīng)用模型意味著應(yīng)用邏輯被根據(jù)功能而劃分成組件，並且可以在同一個伺服器或不同的伺服器上安裝組成J2EE應(yīng)用的這些不同的組件。一個應(yīng)用組件應(yīng)被安裝在什麼地方，取決於該應(yīng)用組件屬於該多層的J2EE環(huán)境中的哪一層。這些層是客戶層、Web層、業(yè)務(wù)層及企業(yè)資訊系統(tǒng)層(EIS)(1)客戶層(ClientTier)J2EE應(yīng)用可以是基於Web的，也可以是不基於Web的。在一個基於Web的J2EE應(yīng)用中，用戶的流覽器在客戶層中運行，並從一個Web伺服器上下載Web層中的靜態(tài)HTML頁面或由JSP或Servlets生成的動態(tài)HTML頁面。在一個不基於Web的J2EE應(yīng)用程式中，一個獨立客戶程式，或者不運行在一個HTML頁面中，而是運行在其他一些基於網(wǎng)路的系統(tǒng)(比如手持設(shè)備或汽車電話)中的Applet程式，在客戶層中運行，並在不經(jīng)過Web層的情況下訪問EnterpriseBeans。該不基於Web的客戶層可能也包括一個JavaBeans類來管理用戶輸入，並將該輸入發(fā)送到在企業(yè)層中運行的EnterpriseBeans類來處理。J2EE框架(2)Web層J2EEWeb組件可以由JSP頁面、基於Web的Applets以及顯示HTML頁面的Servlets組成。調(diào)用Servlets或者JSP頁面的HTML頁面在應(yīng)用程式組裝時與Web組件打包在一起。就像客戶層一樣，Web層可能包括一個JavaBeans類來管理用戶輸入，並將輸入發(fā)送到在業(yè)務(wù)層中運行的EnterpriseBeans類來處理。(3)業(yè)務(wù)層作為解決或滿足某個特定業(yè)務(wù)領(lǐng)域(比如銀行、零售或金融業(yè))的需要的邏輯的業(yè)務(wù)代碼由運行在業(yè)務(wù)層的EnterpriseBeans來執(zhí)行。一個EnterpriseBean從客戶程式處接收數(shù)據(jù)，對數(shù)據(jù)進(jìn)行處理(如果需要)，再將數(shù)據(jù)發(fā)送到企業(yè)資訊系統(tǒng)層存儲。一個EnterpriseBean還從存儲中檢索數(shù)據(jù)，並將數(shù)據(jù)送回客戶程式。運行在業(yè)務(wù)層的EnterpriseBeans依賴於容器來為諸如事務(wù)、生命期、狀態(tài)管理、多線程及資源存儲池提供通常都非常複雜的系統(tǒng)級代碼。業(yè)務(wù)層經(jīng)常被稱作EnterpriseJavaBeans(EJB)層。J2EE框架業(yè)務(wù)層和Web層一起構(gòu)成了3層J2EE應(yīng)用的中間層，而其他兩層是客戶層和企業(yè)資訊系統(tǒng)層。(4)企業(yè)資訊系統(tǒng)層企業(yè)資訊系統(tǒng)層運行企業(yè)資訊系統(tǒng)軟體，這層包括企業(yè)基礎(chǔ)設(shè)施系統(tǒng)，例如企業(yè)資源計畫(ERP)、大型機(jī)事務(wù)處理(MainframeTransactionProcessing)、資料庫系統(tǒng)及其他遺留資訊系統(tǒng)(LegacyInformation