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