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