Java EE架構(gòu)原理探秘及企業(yè)級應(yīng)用
在之前的文章中我們曾介紹過Java企業(yè)級應(yīng)用架構(gòu)設(shè)計(jì)中的分布式結(jié)構(gòu),在實(shí)際的項(xiàng)目中,開發(fā)n級分布式應(yīng)用是一項(xiàng)復(fù)雜且富有挑戰(zhàn)性的工作,需要對Java EE架構(gòu)的原理深入掌握,并將其運(yùn)用到企業(yè)級應(yīng)用的開發(fā)中去。
Java EE架構(gòu)
將處理過程拆分到不同的級中分別處理,可以使資源得到更好的利用。同時我們還可以將工作分配給適合開發(fā)某一級程序的最佳人選。以網(wǎng)頁設(shè)計(jì)師為例,他們就更適合在網(wǎng)頁服務(wù)器上進(jìn)行表現(xiàn)層的開發(fā);而另一方面,數(shù)據(jù)庫開發(fā)人員則可以把精力集中于存儲過程與函數(shù)的開發(fā)。然而,簡單的將各級相互隔離開并不能滿足我們的需求。為了最終滿足企業(yè)的需要,我們必須把這些級整合起來。選擇使用最有效的協(xié)議對成敗至關(guān)重要,錯誤的選擇將會導(dǎo)致嚴(yán)重的性能降低。
除了系統(tǒng)整合之外,分布式應(yīng)用還需要各種各樣的服務(wù)。它必須能夠創(chuàng)建、參與或者管理與不同信息系統(tǒng)之間進(jìn)行交互時的事務(wù)(transaction),這一點(diǎn)對于保證企業(yè)數(shù)據(jù)的并發(fā)性絕對必要。因?yàn)閚級結(jié)構(gòu)是通過互聯(lián)網(wǎng)進(jìn)行訪問的,因此使用強(qiáng)大的安全服務(wù)阻止惡意訪問就變得至關(guān)重要。
今時今日,如CPU、內(nèi)存之類的硬件價格已經(jīng)有了極大地下降,但是局限仍然存在,比如處理器能夠支持的內(nèi)存總?cè)萘?。因此,我們就有必要?yōu)化系統(tǒng)資源的使用?,F(xiàn)代分布式應(yīng)用通常是建立在面向?qū)ο蠹夹g(shù)之上的,因此諸如對象緩存或者緩沖池之類的功能就變得非常方便。這些應(yīng)用會經(jīng)常與關(guān)系數(shù)據(jù)庫或者其他信息系統(tǒng)——比如面向消息的中間件——進(jìn)行交互。然而,建立與這些系統(tǒng)之間的連接代價很大,因?yàn)樗鼤拇罅康奶幚碣Y源從而嚴(yán)重影響系統(tǒng)性能。在這種情況下,“連接池”就變得非常有用,它既可以提高系統(tǒng)性能,又可以優(yōu)化資源的使用。
典型的分布式應(yīng)用會通過中間件服務(wù)器調(diào)用一些系統(tǒng)服務(wù),例如事務(wù)、安全以及緩沖池等。想要訪問這些服務(wù),就必須使用這些中間件服務(wù)器的應(yīng)用程序接口(API),因此,編寫出的應(yīng)用代碼中就必須摻雜進(jìn)某個特定的API。這種內(nèi)置服務(wù)提供商API的方式浪費(fèi)了大量的開發(fā)時間,并且使得維護(hù)變得非常困難,同時也限制了其擴(kuò)展性。
到了1999年,Sun 微系統(tǒng)公司發(fā)布了Java EE 2平臺,以解決企業(yè)級多級應(yīng)用開發(fā)中的難點(diǎn)問題。這個平臺基于Java平臺標(biāo)準(zhǔn)版本2(Java Platform, Standard Edition 2),因此它也可以實(shí)現(xiàn)“編寫一次就可以在任何地方部署運(yùn)行”。Java EE2一經(jīng)發(fā)布就迅速得到了來自開源社區(qū)以及主要商業(yè)供應(yīng)商——如IBM、Oracle、BEA等——的極大支持,而其原因,就在于Java EE2是基于技術(shù)規(guī)范的,任何人只要遵從技術(shù)規(guī)范的內(nèi)容,就可以開發(fā)出自己的服務(wù)程序。而Java EE規(guī)范與平臺也從此開始不斷發(fā)展,如今其平臺已經(jīng)基于Java平臺標(biāo)準(zhǔn)版本5(Java Platform, Standard Edition 5),其名稱也改為Java平臺企業(yè)版5(Java Platform, Enterprise Edition 5)。在本文中,我們將集中討論最新版本,其官方名稱為Java EE 5。
Java EE平臺通過一個基于“容器”(container)的結(jié)構(gòu)提供必要的系統(tǒng)服務(wù)。容器向使用Java編寫的面向?qū)ο髴?yīng)用程序組件提供運(yùn)行環(huán)境,并提供一系列的底層服務(wù),例如:安全、事務(wù)、生命周期管理、對象查找與緩存、持久化以及網(wǎng)絡(luò)通訊等等。這種方式有利于明確分工,系統(tǒng)程序員只管負(fù)責(zé)開發(fā)底層服務(wù),而應(yīng)用程序員就可以把更多的精力放在業(yè)務(wù)及表現(xiàn)邏輯的開發(fā)上面。
如圖1所示,在服務(wù)器端共存在兩種容器:
◆Web容器(web container)。Web容器中裝載著表現(xiàn)組件,例如Java服務(wù)器頁面(JSP)以及小服務(wù)程序(servlet)等。而這些組件又可以通過遠(yuǎn)程協(xié)議與EJB容器進(jìn)行交互。
◆EJB容器(EJB container)。EJB容器控制著企業(yè)級JavaBean(EJB)組件的運(yùn)行。
圖1. Java EE平臺架構(gòu)(圖中文字:Web Browser——網(wǎng)絡(luò)瀏覽器;Java Server Pages——Java服務(wù)器頁面“JSP”;Java Servlets——Java小服務(wù)程序“Servlet”;Web Container——Web容器;Application Client Container——應(yīng)用客戶端容器;Application Client——應(yīng)用客戶端;Enterprise JavaBeans——企業(yè)級JavaBeans“EJB”;EJB Container——EJB容器;Java EE 5 Application Server——JavaEE5 應(yīng)用服務(wù)器;Java 5 Virtual Machine——Java5虛擬機(jī))
在客戶端方面,獨(dú)立的客戶端程序是一個Java核心應(yīng)用程序,通過網(wǎng)絡(luò)與EJB容器連接;而如果用戶使用網(wǎng)絡(luò)瀏覽器,則通常瀏覽器會通過HTTP協(xié)議與Web容器進(jìn)行交互。EJB容器和Web容器都來自Java EE應(yīng)用服務(wù)器,而服務(wù)器程序本身又運(yùn)行在Java虛擬機(jī)(JVM)之上。
不同的容器提供不同類型的底層服務(wù),比如Web容器不提供對事務(wù)的支持,而EJB容器則正相反。容器所提供的服務(wù)可以通過標(biāo)準(zhǔn)的JavaEE API進(jìn)行訪問,例如Java消息服務(wù)(JMS,Java Message Service)、Java命名與目錄接口(JNDI,Java Naming and Directory Interface)、Java持久化API(JPA,Java Persistence API)以及Java事務(wù)API(JTA,Java Transaction API)(譯注:作者可能自己寫暈了,JTA寫了兩遍。。。)等等。這些服務(wù)的最大優(yōu)點(diǎn)是,應(yīng)用組件可以透明地調(diào)用它們而且不需要太多配置改動。如果想插入這些服務(wù),應(yīng)用組件需要與一個XML格式的部署描述文件一起封裝進(jìn)一個預(yù)定義好的歸檔文件。這種方式有效地減少了部署時間,也簡化了維護(hù)工作。
Java EE的應(yīng)用架構(gòu)
Java EE平臺簡化了n級分布式應(yīng)用系統(tǒng)的開發(fā),應(yīng)用組件可以根據(jù)功能的不同被輕松劃分到不同的級上運(yùn)行,不同級上的組件都要通過一個構(gòu)建好的架構(gòu)準(zhǔn)則實(shí)現(xiàn)相互間合作,而這個架構(gòu)就是MVC。
MVC概覽
MVC第一次被提出要追溯到1979年Trygve Reenskaug在他的一篇名為《Smalltalk-80™應(yīng)用程序開發(fā):如何使用模型—視圖—控制器結(jié)構(gòu)》的論文中對它的描述。最初它主要是作為一種分離用戶接口邏輯與業(yè)務(wù)邏輯的策略被設(shè)計(jì)出來的。然而,只是簡單的將二者分離開無法實(shí)現(xiàn)有效的功能,還需要加入一個間接層以連接并協(xié)調(diào)表現(xiàn)層與業(yè)務(wù)邏輯層。而這個新的層就被稱作“控制器層”。就這樣,MVC結(jié)構(gòu)將應(yīng)用程序劃分成了3個獨(dú)特又相互協(xié)作的組件:
◆模型。模型通過業(yè)務(wù)邏輯管理應(yīng)用中的數(shù)據(jù)。
◆視圖。視圖負(fù)責(zé)應(yīng)用程序的數(shù)據(jù)顯示以及向用戶提供控制選項(xiàng),使用戶可以與系統(tǒng)進(jìn)行進(jìn)一步交互。
◆控制器。控制器負(fù)責(zé)模型與視圖之間的協(xié)調(diào)。
圖2描述了這三個組件之間的關(guān)系。控制器截獲任何由用戶操作出發(fā)的事件;根據(jù)用戶操作的類型,控制器調(diào)用模型以應(yīng)用與之匹配的業(yè)務(wù)邏輯然后修改相應(yīng)的應(yīng)用數(shù)據(jù);之后控制器選擇一個視圖組件向終端用戶展示修改之后的應(yīng)用數(shù)據(jù)。從這個過程中你可以看到,MVC提供了一種明確應(yīng)用程序中各部分職能的方法。通過這種分離方式,多個視圖以及控制器就可以同時與一個模型一起工作了。
圖2. 模型—視圖—控制器(圖中文字:Apply business rules——應(yīng)用業(yè)務(wù)邏輯;Modify application data——修改應(yīng)用數(shù)據(jù);User Actions——用戶操作;Select view——選擇視圖;Display changed application data——顯示修改后的數(shù)據(jù);Model——模型;Controller——控制器;View——視圖)
使用MVC結(jié)構(gòu)的Java EE架構(gòu)
目前的企業(yè)級應(yīng)用開發(fā)中,MVC被廣泛使用。MVC的概念可以很容易地被用來構(gòu)建Java EE應(yīng)用架構(gòu)的基礎(chǔ)。Java EE的Servlet技術(shù)作為控制器就非常完美。任何瀏覽器請求都可以通過HTTP協(xié)議發(fā)送給Servlet,之后Servlet作為控制器可以調(diào)用EJB模型組件。這些模型組件內(nèi)部封裝了業(yè)務(wù)邏輯并可以對應(yīng)用數(shù)據(jù)進(jìn)行操作,而處理過的企業(yè)數(shù)據(jù)之后可以通過JSP表現(xiàn)給用戶。這是真實(shí)生活中企業(yè)級Java應(yīng)用架構(gòu)的一個最簡范例,盡管這種結(jié)構(gòu)只在很小的范圍內(nèi)能夠有效工作,但是它仍然對應(yīng)用的開發(fā)具有重大的意義。如果你能讓不同技術(shù)領(lǐng)域的專業(yè)人員一起工作,你的風(fēng)險就會降低,而生產(chǎn)力就會提高。除此之外,任何一層的替換都是透明的,你可以輕易的加入新的功能而不需要修改其它層(參見圖3)。
圖3. 基于MVC結(jié)構(gòu)的分層多級Java EE應(yīng)用架構(gòu)(圖中文字:Client Tier——客戶級;Clinet/Browser——客戶端/瀏覽器;HTTP Request/Response——HTTP請求/響應(yīng);Presentation Layer——表現(xiàn)層;Presentation Tier——表現(xiàn)級;Data Access Layer——數(shù)據(jù)訪問層;Business Tier——業(yè)務(wù)級;Enterprise Information Tier——企業(yè)信息級;Database——數(shù)據(jù)庫)
Java EE應(yīng)用中的層
從圖7中可以明顯看出,分層結(jié)構(gòu)是MVC結(jié)構(gòu)的一種拓展。在傳統(tǒng)的MVC結(jié)構(gòu)中,數(shù)據(jù)訪問(整合)層被認(rèn)為應(yīng)該是業(yè)務(wù)層的一部分,然而在Java EE中,數(shù)據(jù)訪問層被作為一個獨(dú)立的層。其原因是因?yàn)椋髽I(yè)級Java應(yīng)用需要與各種不同的外部信息系統(tǒng)進(jìn)行業(yè)務(wù)數(shù)據(jù)的整合與交流,這些外部信息系統(tǒng)包括:關(guān)系數(shù)據(jù)庫管理系統(tǒng)(RDBMS)、大型機(jī)、SAP ERP以及Oracle電子商務(wù)套裝等等等等。因此,將信息整合服務(wù)放到一個獨(dú)立的層上,有助于業(yè)務(wù)層將精力集中于業(yè)務(wù)邏輯的核心功能上。
Java EE架構(gòu)的這種松耦合分層架構(gòu)帶來的好處,與傳統(tǒng)MVC類似,因?yàn)閷?shí)施細(xì)節(jié)都被封裝進(jìn)了各個獨(dú)立的層中,我們可以很簡單的對功能進(jìn)行修改,又不會對鄰近的層產(chǎn)生重大影響,這使得應(yīng)用程序更具靈活性也更易于維護(hù)。同時因?yàn)槊恳粚佣加凶约好鞔_的職責(zé)定義,在不影響功能的前提下,應(yīng)用變得更加易于管理。
【編輯推薦】