#
think in java說：萬事萬物皆對象。
自從接觸java那天起，張口閉口言必稱面向?qū)ο螅阋f自己不知道什么是面向?qū)ο螅加X得很沒面子。
然而一直到現(xiàn)在，其實我心里都在小聲的問自己：面向?qū)ο笏季S，我現(xiàn)在到底領(lǐng)悟了多少？
大家都說：“面向?qū)ο蟮木柙谟诳紤]問題的思路是從現(xiàn)實世界的人類思維習(xí)慣出發(fā)的，只要領(lǐng)會了這一點，就領(lǐng)會了面向?qū)ο蟮乃季S方法。”。多么簡單的思想！可是，要從一個現(xiàn)實的世界中分析出一套真正實用的系統(tǒng)來，似乎又沒那么簡單了吧。僅僅是面向?qū)ο蟮乃枷胍约霸鷮嵉膉ava功底就夠了嗎？
然而面向?qū)ο髢H僅是告訴我們 “如何做”，卻沒有告訴我們“怎么做”。比如說，我們根據(jù)面向?qū)ο螅治龀隽似囉兴膫€輪子，有發(fā)動機，等等....，于是，我們實現(xiàn)了輪子的類，發(fā)動機的類。然而發(fā)動機的細節(jié)我們無從得之。于是我們打開發(fā)動機，看看內(nèi)部。我們再次利用面向?qū)ο蟮乃枷耄纸獬隽烁〉牟考＝K于到了無法拆分的零件了。
可是要實現(xiàn)這個真正運轉(zhuǎn)的零件，不就是要用到我們所說的“算法”來實現(xiàn)么，這個時候，面向?qū)ο笠呀?jīng)幫不上什么忙了。所以，面向?qū)ο笾皇欠治鍪挛铮J(rèn)識事物的一種手段而已。
去年底研究了一下sun的petstore，總因為各種事情，終究半途而廢了。今天心血來潮的看了一下。打開了sun的服務(wù)器以及pointbase數(shù)據(jù)庫，其間猜了半天的密碼，裝的比較久，都忘記了。呵呵！終于將petstore應(yīng)用部署了上去（腳本部署就是快 ^ ^），按sun的quickstart提示訪問8080端口，卻發(fā)現(xiàn)怎么都連不上，無奈打開domain下的配置文件一看卻發(fā)現(xiàn)端口卻是 3045。奇怪！
終于出現(xiàn)久違的頁面了，第一次訪問時，程序自動將數(shù)據(jù)庫結(jié)構(gòu)以及數(shù)據(jù)導(dǎo)入數(shù)據(jù)庫。過程是點擊鏈接，期間經(jīng)過2次populating.jsp頁面導(dǎo)向，在head中指定<META HTTP-EQUIV=REFRESH CONTENT="0; URL=Populate?success_page=//supplier/populating.jsp%3fforcefully%3d<%=request.getParameter("forcefully") %>&forcefully=<%=request.getParameter("forcefully") %>"來實現(xiàn)，在第一個populating.jsp中訪問了petstore\src\com\sun\j2ee\blueprints\petstore\tools\populate\PopulateServlet.java這個類來實現(xiàn)將數(shù)據(jù)庫結(jié)構(gòu)以及數(shù)據(jù)導(dǎo)入數(shù)據(jù)庫，在第二個populating.jsp中類似手法導(dǎo)向main.screen。真正的首頁才展現(xiàn)出來了。這些才僅僅是前奏。
個人感覺WAF框架目前應(yīng)用雖然似乎并不多見，但總覺得，其中許多思想還是可以借鑒的，深入下去必然有好處。特別是如果應(yīng)用的架構(gòu)中需要訪問EJB的時候。
WAF是WEB APPLICATION FRAMWORK的簡稱，是SUN藍皮書例子程序中提出的應(yīng)用框架。它實現(xiàn)了MVC和其他良好的設(shè)計模式。
開發(fā)人員編寫的兩個xml配置文件定義了WAF的運作參數(shù)。Screendefinition.xml定義了一系列的屏幕(screen)。Mapping.xml則定義了某個動作之后應(yīng)該顯示的屏幕，但沒有指定屏幕到哪里拿數(shù)據(jù)。
用戶發(fā)出一個HTTP請求（*.screen），由TemplateSERVLET屏幕前端控制組件接收，它提取請求信息，設(shè)置request對象CurrentScreen屬性，再把請求發(fā)到模版JSP。模版JSP收到請求后，JSP中的Template標(biāo)簽察看這個當(dāng)前屏幕，并從屏幕定義文件（Screendefinition.xml）中獲取這個屏幕的具體參數(shù)，再生成html返回給客戶。
假設(shè)返回給客戶的html中包括了html表單，用戶在輸入一定數(shù)據(jù)之后提交，發(fā)出一個HTTP請求（*.do）。這個請求被MainSERVLET接收，它提取請求信息，察看動作映射文件（mapping.xml），設(shè)置處理這個請求的動作對象(HTTPAction對象)，交給requestprosessor對象處理。Requestprosessor對象調(diào)用動作對象完成任務(wù)，如果需要進一步處理，requestprosessor對象會調(diào)用WEBclientcontroler對象的事件處理機制。MainSERVLET在處理完請求之后，從屏幕流管理對象那里得到下一個屏幕，并把請求傳給這個屏幕的JSP文件。
值得一提的是WEBclientcontroler事件處理機制最終把HTTP請求的數(shù)據(jù)傳到了EJBAction對象那里處理。這樣HTTPAction對象和EJBAction對象形成了兩級處理機制，前一級與request對象緊密相關(guān)，把數(shù)據(jù)封裝起來形成一個Event對象，再傳給了EJBAction對象，后者與Request對象無關(guān)。
這個方式可以形成一個session級別的數(shù)據(jù)處理機制。下圖顯示了這個方法。HTTPAction1對象處理一個請求，并把數(shù)據(jù)放到一個狀態(tài)SessionBean內(nèi)，HTTPAction2也如此，當(dāng)HTTPAction3接收到HTTP請求之后，把控制傳給EJBAction, 后者獲取狀態(tài)SessionBean數(shù)據(jù)，處理請求，成功后清控狀態(tài)SessionBean的內(nèi)容。這個機制非常適應(yīng)多個輸入頁面才能滿足一個業(yè)務(wù)的輸入數(shù)據(jù)的情況（比如購物車）。
中耳炎一點都沒見好,反而更嚴(yán)重了,真是痛苦,感覺左耳很不靈,而且漲痛.下午請了假,直奔同仁醫(yī)院.進去以后就象開罰款單一樣.就開了點消炎藥和滴耳液,竟然花了快200塊.真不知道接下來的媒體叫囂的醫(yī)療改革會成什么樣子.
接下來的時間準(zhǔn)備研究Front Controller模式了.
實在是無法忍受CSDN blog的速度了，今天決定搬家。
在這里記錄下自己的開發(fā)心得，給高手批判，給新手借鑒。
今年的夏天北京的雨特別的多，所以顯得不是特別熱。可是偏偏在這
清涼的夏天，我卻上火了。可惡的中耳炎又如期而至了。這是工作
2年后的第一次發(fā)作。之前是年年必發(fā)。