??? 在這里只是簡單的介紹一些企業應用開發應該采納和借鑒的一些展現層技術、架構和開發方式，之所以稱它們為新，主要是針對技術和趨勢而言，其實他們的概念已經不算是太新的了（已經存在一段時間了），正是因為如此，它們更加具有可借鑒的價值。
???
瀏覽器胖客戶端技術：
??? 無論如何說、無論采用何種技術目前的三層分布式企業級應用也都是網絡應用，它在本質上與其他的網絡應用是有相似性的，我們可以在它們之間作一個類比。
???
就在不遠的以前，網站的用戶界面也是靜態的，雖然很多網站提供了服務端動態網頁的支持，但是用戶看到的卻還是一張張靜態的網頁。用戶與網站之間是一個請求
和交互的過程（本質上就是這樣，看上去也是這樣），用戶通過超鏈接在一個個動態/靜態的頁面之間瀏覽。而所有的處理全部是由服務器來進行的。大多數能夠即
時響應客戶的是Flash或者Applet這種瀏覽器的插件。當然客戶端動態網頁的技術當時也已經存在很長時間了，但是并沒有得到太多的重視。
???
但是，近幾年來，動態網頁無刷新技術逐漸興起起來，它充分利用了客戶端瀏覽器所具備的計算能力，通過借助于DHTML容器的事件機制和非提交形式HTTP
訪問服務器的方法實現了可以在客戶端自行處理用戶請求的基于瀏覽器的胖客戶端，使得使用界面更加友好和易用，而且還在相當的程度上減輕了服務器處理的負
擔。
???
???
再拿二層的分布式企業級應用來作縱向比較，雖然抽象出應用服務器這一層對于數據庫服務器是一種解脫（也為SOA打下了基礎），但是由于當時的網絡應用的技
術所限，真正的用戶體驗是下降了的，胖客戶端的安裝和升級確實比較麻煩，但是一般說來客戶端的安裝問題只是部署和維護企業級應用系統的一個很小的問題。但
對于底層的實際用戶而言，基于網絡HTML技術的客戶端界面可能會好看一些，但是效率、操作性、實時反應的能力都是下降了的。對于底層的用戶而言，鍵盤操
作要比鼠標操作工作效率更高。企業級應用的系統是要給企業做的，而企業的主要目標是創造最大利潤，在這一點上其實很多三層的企業級應用都是對企業級應用所
要達成的目標的一種背離。但是，這主要是因為當時的技術所限，就算是最能代表當時網絡技術的大型商業網站，他們的用戶界面也幾乎全是靜態的HTML網頁。
???
???
綜上所述，可以看出三層分布式的企業級應用系統應該在展現層進行一次革新，應該盡可能的采用瀏覽器胖客戶端的技術，這樣一方面可以充分利用客戶端的計算能
力和資源，緩解服務端壓力，還可以通過快捷鍵、自定義快捷方式甚至自定義宏的方式提高用戶的使用效率和使用體驗。
???
服務端組件化開發技術：
??? Struts
是一個很好的框架，它的靈活性和穩定性是有目共睹的。但是無論如何它給開發人員帶來的工作量和調試起來的難度也是很多的（尤其是在沒有充分體現出分層概念
的企業級應用系統中）。其實難度最終是要轉化到網絡應用的開發上去的。三層的企業級應用系統也是網絡應用，而對于網絡應用而言，業務開發人員和美工（又叫
WebUI？）人員的分工也是比較頭疼的問題。JSP等模板技術于是應運而生，但其實這不過是一種善意的謊言。對于JSP而言業務開發人員還是必須對
HTML有比較深的了解，而且最頭疼的是，除非你把它放在Web容器中運行，否則你決不會知道它到底是一個什么樣子（除非你把你自己的大腦變成一個Web
容器加上一個瀏覽器），JSP Tag的出現并不能解決什么問題，從本質上來說它就是JSP概念的一個延展，可以節省代碼而已（而且帶來更多的復雜度）。
??? 難道真的沒有辦法了嗎？
??? 我們縱向對比一下二層的企業級應用，它開發和維護起來就沒有三層那么麻煩。原因何在？組件已經封裝了絕大多部分的工作，你所需要的只是應用組件、配置組件、添加事件處理代碼而已。
???
從這個方面上來說，還有什么DHTML更好的用戶界面描述語言？設想一下，你可以試圖拿Swing（為什么Swing？——平臺無關）寫一個可以在運行時
動態的改變界面結構、通過樣式描述文件動態改變組件樣式的程序（這一切可以跟一個或多個很完善的腳本語言無縫集成），它會多復雜？
??? 還記得桌面應用的開發嗎？沒有一個像樣的桌面程序沒有自定義組件的，但是它們的自定義組件大多數其實只是基礎組件的組合。
??? 同理，也可以對HTML進行如此開發。
??? 下面給出解決的架構。
???
展現層開發架構：
???? 開發要明確體現出客戶端、應用服務器端、數據庫服務器端的三層概念。數據庫服務端的開發與展現層無關略去不講。
- 客戶端開發：使用JavaScript進行事件處理響應用戶的操作，對組件進行相應的操作，如有必要可以采取遠程服務器端服務調用（既可以調用自己服務器提供的服務也可以調用其他的公用網絡服務，符合SOA的要求）的方式。
- 服
務端開發：展現層組件分為兩部分，動態網頁組件和JavaScript組件。動態網頁組件采用基于組件化的動態網頁框架（比如Tapesrty，為什么不
用JSF稍后再講）。另外服務端開發還有業務邏輯處理服務，其中業務邏輯處理屬于業務邏輯層不再多說，而業務邏輯處理服務和服務的遠程調用以及相應的安全
處理可以采用Spring + Acegi +
DWR的方式（這樣可以既可以實現JavaScript客戶端遠程調用業務邏輯服務，還可以很容易的實現服務的安全公開化，符合SOA的要求）。
??? 為什么這么看重Tapestry而不用JSF呢？
- JSF
的標準還是跟JSP綁在一塊的，雖然有Facelet的存在，但是本身擺脫不了JSP的JSF還是會被JSP所拖累的。我并沒有說JSP一無是處，作為模
板技術而言，JSP已經非常成功了，但是對于JavaScript胖客戶端開發而言，JSP本身容器相關的特性實在是沒什么好處。
- 目前
而言JavaScript是可以進行單元測試的，而Tapestry的Html模板技術使得JavaScript和Html的集成測試達到可能。你可以完
全不管Tapestry而調試JavaScript，調試成功以后再加上Tapestry的組件標簽就可以了。你可以為重要的JavaScript（一些
起粘結作用的Script就沒有必要測試了）寫測試腳本進行測試，而這些全部都是遠離Web容器的。
???
??? 我們的開發人員為什么要遠離JavaScript呢？因為它是動態解釋語言？Ruby也是。只要測試到位，動態語言也可以實現穩定的系統。
??? 運行的效率低？也許吧，但總高過整個頁面刷新，我說的不過分吧。
???
開發人員對JavaScript認識不夠，沒有很好的IDE支持？事實上，根本不必讓開發人員對它認識“夠”，因為他所寫的主要是一些GlueCode，
配置一下組件，把組件之間通過事件結合起來。當然，這些有一部分你可以自己發明一些XML來達到，值得嗎？我個人認為寫動態腳本也好過寫XML（別跟我說
你還可以寫個DTD）。至于IDE的話，我認為，寫JavaScript根本用不著，尤其是在你根本不會寫很多的時候。只要有一個瀏覽器和瀏覽器支持的
JavaScript調試器足夠了。只要組件化做好了，再結合工程模板，那么開發人員就象回到了二層的時代，選擇相應的組件，組合然后就是調試了。比兩層
有優勢的一點是，他不必啟動服務器就可以調試客戶端。
???
這一方面的網絡應用開發先驅是Google（可惜，他們沒用JavaEE技術，呵呵），到現在已經成為一種風潮，對企業級應用開發趕時髦是沒有必要的，但
是技術的發展帶來了新的可能，不管是在開發方面還是在客戶體驗和客戶效率提高上都會有更好的機會，為什么不把握這個機會呢？
??? 末了，SOA完全可以評為今年的軟件開發最流行關鍵詞。呵呵。它的核心概念是什么呢？不要浪費現有的IT資源。
??? 我們現在對于網絡和計算機技術的資源開發和應用的大部分都處于浪費狀態，有政治原因、有商業原因但是還有技術原因。能夠盡可能有效的利用手中現有的資源，對于企業的發展也有相當的積極作用。