zongxing

TOMCAT源碼分析(啟動框架)
前言：
   本文是我閱讀了TOMCAT源碼后的一些心得。 主要是講解TOMCAT的系統框架， 以及啟動流程。若有錯漏之處，敬請批評指教！
建議：
   畢竟TOMCAT的框架還是比較復雜的， 單是從文字上理解， 是不那么容易掌握TOMCAT的框架的。 所以得實踐、實踐、再實踐。 建議下載一份TOMCAT的源碼， 調試通過， 然后單步跟蹤其啟動過程。 如果有不明白的地方， 再來查閱本文， 看是否能得到幫助。 我相信這樣效果以及學習速度都會好很多！
  
1. Tomcat的整體框架結構
   Tomcat的基本框架， 分為4個層次。
   Top Level Elements:
    Server
    Service  
   Connector
    HTTP
    AJP
   Container
   Engine
     Host
   Context
   Component 
    manager
   logger
   loader
   pipeline
   valve
         ...
   站在框架的頂層的是Server和Service
   Server:  其實就是BackGroud程序， 在Tomcat里面的Server的用處是啟動和監聽服務端事件（諸如重啟、關閉等命令。 在tomcat的標準配置文件：server.xml里面， 我們可以看到“<Server port="8005" shutdown="SHUTDOWN" debug="0">”這里的"SHUTDOWN"就是server在監聽服務端事件的時候所使用的命令字）
   Service： 在tomcat里面， service是指一類問題的解決方案。  通常我們會默認使用tomcat提供的：Tomcat-Standalone 模式的service。 在這種方式下的service既給我們提供解析jsp和servlet的服務， 同時也提供給我們解析靜態文本的服務。
  
   Connector: Tomcat都是在容器里面處理問題的， 而容器又到哪里去取得輸入信息呢？
Connector就是專干這個的。 他會把從socket傳遞過來的數據， 封裝成Request, 傳遞給容器來處理。
   通常我們會用到兩種Connector,一種叫http connectoer， 用來傳遞http需求的。 另一種叫AJP， 在我們整合apache與tomcat工作的時候， apache與tomcat之間就是通過這個協議來互動的。 （說到apache與tomcat的整合工作， 通常我們的目的是為了讓apache 獲取靜態資源， 而讓tomcat來解析動態的jsp或者servlet。）
   Container: 當http connector把需求傳遞給頂級的container: Engin的時候， 我們的視線就應該移動到Container這個層面來了。
   在Container這個層， 我們包含了3種容器： Engin, Host, Context.
   Engin: 收到service傳遞過來的需求， 處理后， 將結果返回給service( service 是通過 connector 這個媒介來和Engin互動的 ).
   Host: Engin收到service傳遞過來的需求后，不會自己處理， 而是交給合適的Host來處理。
Host在這里就是虛擬主機的意思， 通常我們都只會使用一個主機，既“localhost”本地機來處理。
   Context: Host接到了從Host傳過來的需求后， 也不會自己處理， 而是交給合適的Context來處理。
   比如： <http://127.0.0.1:8080/foo/index.jsp>
         <http://127.0.1:8080/bar/index.jsp>
   前者交給foo這個Context來處理， 后者交給bar這個Context來處理。
   很明顯吧！ context的意思其實就是一個web app的意思。
   我們通常都會在server.xml里面做這樣的配置
   <Context path="/foo" docBase="D:/project/foo/web" />
   這個context容器，就是用來干我們該干的事兒的地方的。
  
   Compenent: 接下來， 我們繼續講講component是干什么用的。
   我們得先理解一下容器和組件的關系。
   需求被傳遞到了容器里面， 在合適的時候， 會傳遞給下一個容器處理。
   而容器里面又盛裝著各種各樣的組件， 我們可以理解為提供各種各樣的增值服務。
   manager: 當一個容器里面裝了manager組件后，這個容器就支持session管理了， 事實上在tomcat里面的session管理， 就是靠的在context里面裝的manager component.
   logger: 當一個容器里面裝了logger組件后， 這個容器里所發生的事情， 就被該組件記錄下來啦！ 我們通常會在logs/ 這個目錄下看見 catalina_log.time.txt 以及 localhost.time.txt 和localhost_examples_log.time.txt。 這就是因為我們分別為：engin, host以及context(examples)這三個容器安裝了logger組件， 這也是默認安裝， 又叫做標配 ：）
   loader: loader這個組件通常只會給我們的context容器使用， loader是用來啟動context以及管理這個context的classloader用的。
    pipline: pipeline是這樣一個東西， 當一個容器決定了要把從上級傳遞過來的需求交給子容器的時候， 他就把這個需求放進容器的管道(pipeline)里面去。 而需求傻呼呼得在管道里面流動的時候， 就會被管道里面的各個閥門攔截下來。 比如管道里面放了兩個閥門。 第一個閥門叫做“access_allow_vavle”， 也就是說需求流過來的時候，它會看這個需求是哪個IP過來的， 如果這個IP已經在黑名單里面了， sure, 殺！ 第二個閥門叫做“defaul_access_valve”它會做例行的檢查， 如果通過的話，OK， 把需求傳遞給當前容器的子容器。 就是通過這種方式， 需求就在各個容器里面傳遞，流動， 最后抵達目的地的了。
    valve: 就是上面所說的閥門啦。
   Tomcat里面大概就是這么些東西， 我們可以簡單地這么理解tomcat的框架，它是一種自上而下， 容器里又包含子容器的這樣一種結構。
2. Tomcat的啟動流程
   這篇文章是講tomcat怎么啟動的，既然我們大體上了解了TOMCAT的框架結構了， 那么我們可以望文生意地就猜到tomcat的啟動， 會先啟動父容器，然后逐個啟動里面的子容器。 啟動每一個容器的時候， 都會啟動安插在他身上的組件。 當所有的組件啟動完畢， 所有的容器啟動完畢的時候， tomcat本身也就啟動完畢了。
   順理成章地， 我們同樣可以猜到， tomcat的啟動會分成兩大部分， 第一步是裝配工作。 第二步是啟動工作。
   裝配工作就是為父容器裝上子容器， 為各個容器安插進組件的工作。 這個地方我們會用到digester模式， 至于digester模式什么， 有什么用， 怎么工作的. 請參考 <http://software.ccidnet.com/pub/article/c322_a31671_p2.html>
   啟動工作是在裝配工作之后， 一旦裝配成功了， 我們就只需要點燃最上面的一根導線， 整個tomcat就會被激活起來。 這就好比我們要開一輛已經裝配好了的汽車的時候一樣，我們只要把鑰匙插進鑰匙孔，一擰，汽車的引擎就會發動起來，空調就會開起來， 安全裝置就會生效， 如此一來，汽車整個就發動起來了。（這個過程確實和TOMCAT的啟動過程不謀而和， 讓我們不得不懷疑 TOMCAT的設計者是在GE做JAVA開發的）。
2.1 一些有意思的名稱：
   Catalina
   Tomcat
   Bootstrap
   Engin
   Host
   Context
   他們的意思很有意思：
   Catalina: 遠程轟炸機
   Tomcat: 熊貓轟炸機 -- 轟炸機的一種（這讓我想起了讓國人引以為豪的熊貓手機，是不是英文可以叫做tomcat??? ， 又讓我想起了另一則廣告： 波導-手機中的戰斗機、波音-客機中的戰斗機 ）
   Bootstap: 引導
   Engin: 發動機
   Host: 主機，領土
   Context: 內容， 目標， 上下文
  
   ... 在許多許多年后， 現代人類已經滅絕。 后現代生物發現了這些單詞零落零落在一塊。 一個自以為聰明的家伙把這些東西翻譯出來了：
   在地勤人員的引導(bootstrap)下， 一架轟炸架(catalina)騰空躍起， 遠看是熊貓轟炸機(tomcat)， 近看還是熊貓轟炸機！ 憑借著優秀的發動機技術(engin)， 這架熊貓轟炸機飛臨了敵國的領土上空(host)， 對準目標(context)投下了毀天滅地的核彈頭，波~ 現代生物就這么隔屁了~
 
   綜上所述， 這又不得不讓人聯想到GE是不是也參與了軍事設備的生產呢？
   反對美帝國主義！ 反對美霸權主義！ 和平萬歲！ 自由萬歲！
  
2.2  歷史就是那么驚人的相似！ tomcat的啟動就是從org.apache.catalina.startup.Bootstrap這個類悍然啟動的！
   在Bootstrap里做了兩件事：
   1. 指定了3種類型classloader:
      commonLoader: common/classes、common/lib、common/endorsed
      catalinaLoader: server/classes、server/lib、commonLoader
      sharedLoader：  shared/classes、shared/lib、commonLoader
   2. 引導Catalina的啟動。
      用Reflection技術調用org.apache.catalina.startup.Catalina的process方法， 并傳遞參數過去。
  
2.3 Catalina.java
   Catalina完成了幾個重要的任務：
   1. 使用Digester技術裝配tomcat各個容器與組件。
      1.1 裝配工作的主要內容是安裝各個大件。 比如server下有什么樣的servcie。 Host會容納多少個context。 Context都會使用到哪些組件等等。
      1.2 同時呢， 在裝配工作這一步， 還完成了mbeans的配置工作。 在這里，我簡單地但不十分精確地描述一下mbean是什么，干什么用的。
          我們自己生成的對象， 自己管理， 天經地義！ 但是如果我們創建了對象了， 想讓別人來管， 怎么辦呢？ 我想至少得告訴別人我們都有什么， 以及通過什么方法可以找到  吧！ JMX技術給我們提供了一種手段。 JMX里面主要有3種東西。Mbean, agent, connector.
       Mbean： 用來映射我們的對象。也許mbean就是我們創建的對象， 也許不是， 但有了它， 就可以引用到我們的對象了。
       Agent:  通過它， 就可以找到mbean了。
       Connector: 連接Agent的方式。 可以是http的， 也可以是rmi的，還可以直接通過socket。
      發生在tomcat 裝配過程中的事情:  GlobalResourcesLifecycleListener 類的初始化會被觸發：
         protected static Registry registry = MBeanUtils.createRegistry();  會運行
         MBeanUtils.createRegistry()  會依據/org/apache/catalina/mbeans/mbeans-descriptors.xml這個配置文件創建 mbeans. Ok, 外界就有了條途徑訪問tomcat中的各個組件了。（有點像后門兒）
   2. 為top level 的server 做初始化工作。 實際上就是做通常會配置給service的兩條connector.(http, ajp)
   3. 從server這個容器開始啟動， 點燃整個tomcat.
   4. 為server做一個hook程序， 檢測當server shutdown的時候， 關閉tomcat的各個容器用。
   5. 監聽8005端口， 如果發送"SHUTDOWN"（默認培植下字符串）過來， 關閉8005serverSocket。
2.4 啟動各個容器
   1. Server
      觸發Server容器啟動前(before_start)， 啟動中(start)， 啟動后(after_start)3個事件， 并運行相應的事件處理器。
      啟動Server的子容器：Servcie.
   2. Service
      啟動Service的子容器：Engin
      啟動Connector
   3. Engin
      到了Engin這個層次，以及以下級別的容器， Tomcat就使用了比較一致的啟動方式了。
      首先，  運行各個容器自己特有一些任務
      隨后，  觸發啟動前事件
      立即，  設置標簽，就表示該容器已經啟動
      接著，  啟動容器中的各個組件： loader, logger, manager等等
      再接著，啟動mapping組件。（注1）
      緊跟著，啟動子容器。
      接下來，啟動該容器的管道(pipline)
      然后，  觸發啟動中事件
      最后，  觸發啟動后事件。
 
      Engin大致會這么做， Host大致也會這么做， Context大致還是會這么做。 那么很顯然地， 我們需要在這里使用到代碼復用的技術。 tomcat在處理這個問題的時候， 漂亮地使用了抽象類來處理。 ContainerBase. 最后使得這部分完成復雜功能的代碼顯得干凈利落， 干練爽快， 實在是令人覺得嘆為觀止， 細細品來， 直覺如享佳珍， 另人齒頰留香， 留戀往返??！
     
      Engin的觸發啟動前事件里， 會激活綁定在Engin上的唯一一個Listener：EnginConfig。
      這個EnginConfig類基本上沒有做什么事情， 就是把EnginConfig的調試級別設置為和Engin相當。 另外就是輸出幾行文本， 表示Engin已經配置完畢， 并沒有做什么實質性的工作。
      注1: mapping組件的用處是， 當一個需求將要從父容器傳遞到子容器的時候， 而父容器又有多個子容器的話， 那么應該選擇哪個子容器來處理需求呢？ 這個由mapping 組件來定奪。
   
   4. Host
       同Engin一樣， 也是調用ContainerBase里面的start()方法， 不過之前做了些自個兒的任務,就是往Host這個容器的通道（pipline）里面， 安裝了一個叫做
 “org.apache.catalina.valves.ErrorReportValve”的閥門。
       這個閥門的用處是這樣的：  需求在被Engin傳遞給Host后， 會繼續傳遞給Context做具體的處理。 這里需求其實就是作為參數傳遞的Request, Response。 所以在context把需求處理完后， 通常會改動response。 而這個org.apache.catalina.valves.ErrorReportValve的作用就是檢察response是否包含錯誤， 如果有就做相應的處理。
   5. Context
       到了這里， 就終于輪到了tomcat啟動中真正的重頭戲，啟動Context了。
 StandardContext.start() 這個啟動Context容器的方法被StandardHost調用.
 5.1 webappResources 該context所指向的具體目錄
 5.2 安裝defaultContex, DefaultContext 就是默認Context。 如果我們在一個Host下面安裝了DefaultContext，而且defaultContext里面又安裝了一個數據庫連接池資源的話。 那么其他所有的在該Host下的Context, 都可以直接使用這個數據庫連接池， 而不用格外做配置了。
  5.3 指定Loader. 通常用默認的org.apache.catalina.loader.WebappLoader這個類。   Loader就是用來指定這個context會用到哪些類啊， 哪些jar包啊這些什么的。
 5.4 指定 Manager. 通常使用默認的org.apache.catalina.session. StandardManager 。 Manager是用來管理session的。
     其實session的管理也很好實現。 以一種簡單的session管理為例。 當需求傳遞過來的時候， 在Request對象里面有一個sessionId 屬性。 OK， 得到這個sessionId后， 我們就可以把它作為map的key，而value我們可以放置一個HashMap. HashMap里邊兒， 再放我們想放的東西。
 5.5 postWorkDirectory (). Tomcat下面有一個work目錄。 我們把臨時文件都扔在那兒去。 這個步驟就是在那里創建一個目錄。 一般說來會在%CATALINA_HOME%/work/Standalone\localhost\ 這個地方生成一個目錄。
5.6  Binding thread。到了這里， 就應該發生 class Loader 互換了。 之前是看得見tomcat下面所有的class和lib. 接下來需要看得見當前context下的class。 所以要設置contextClassLoader, 同時還要把舊的ClassLoader記錄下來，因為以后還要用的。
5.7  啟動 Loader. 指定這個Context具體要使用哪些classes， 用到哪些jar文件。 如果reloadable設置成了true, 就會啟動一個線程來監視classes的變化， 如果有變化就重新啟動Context。
5.8  啟動logger
5.9  觸發安裝在它身上的一個監聽器。
 lifecycle.fireLifecycleEvent(START_EVENT, null);
 作為監聽器之一，ContextConfig會被啟動. ContextConfig就是用來配置web.xml的。 比如這個Context有多少Servlet， 又有多少Filter， 就是在這里給Context裝上去的。
 5.9.1 defaultConfig. 每個context都得配置 tomcat/conf/web.xml 這個文件。
 5.9.2 applicationConfig 配置自己的 WEB-INF/web.xml 文件
5.9.3 validateSecurityRoles 權限驗證。 通常我們在訪問/admin 或者/manager的時候，需要用戶要么是admin的要么是manager的， 才能訪問。 而且我們還可以限制那些資源可以訪問， 而哪些不能。 都是在這里實現的。
5.9.4 tldScan: 掃描一下， 需要用到哪些標簽(tag lab)
5.10 啟動 manager
5.11 postWelcomeFiles() 我們通常會用到的3個啟動文件的名稱：
index.html、index.htm、index.jsp 就被默認地綁在了這個context上
 5.12 listenerStart 配置listener
 5.13 filterStart 配置 filter
 5.14 啟動帶有<load-on-startup>1</load-on-startup>的Servlet.
  順序是從小到大： 1,2,3… 最后是0
  默認情況下， 至少會啟動如下3個的Servlet:
  org.apache.catalina.servlets.DefaultServlet  
      處理靜態資源的Servlet. 什么圖片啊， html啊， css啊， js啊都找他
  org.apache.catalina.servlets.InvokerServlet
      處理沒有做Servlet Mapping的那些Servlet.
  org.apache.jasper.servlet.JspServlet
      處理JSP文件的.
       5.15  標識context已經啟動完畢。
 走了多少個步驟啊， Context總算是啟動完畢嘍。
    OK! 走到了這里， 每個容器以及組件都啟動完畢。 Tomcat終于不辭辛勞地為人民服務了！
3. 參考文獻：
    <http://jakarta.apache.org/tomcat/>
    <http://www.onjava.com/pub/a/onjava/2003/05/14/java_webserver.html>
   
4. 后記
    這篇文章是講解tomcat啟動框架的，還有篇文章是講解TOMCAT里面的消息處理流程的細節的。 文章內容已經寫好了， 現在正在整理階段。 相信很快就可以做出來， 大家共同研究共同進步。
    這篇文章是獨自分析TOMCAT源碼所寫的， 所以一定有地方是帶有個人主觀色彩， 難免會有片面之處。若有不當之處敬請批評指教，這樣不僅可以使剛開始研究TOMCAT的兄弟們少走彎路， 我也可以學到東西。
    email: sojan_java@yahoo.com.cn

5. tomcat源碼分析(消息處理)

我使用OO技術第一次設計軟件的時候，犯了一個設計者所能犯的所有錯誤。那是一個來自國外的外包項目，外方負責功能設計，我們公司負責程序設計、編碼和測試。

第一個重要的錯誤是，我沒有認真的把設計說明書看明白。功能點設計確實有一些問題，按照他們的設計，一個重要的流程是無法實現的。于是我在沒有與投資方溝通的情況下，擅自改動了設計，把一個原本在Linux系統上開發的模塊改到了Windows系統上。結果流程確實是實現了，但是很不幸，根本不符合他們的需要，比起原先的設計差的更多。在詢問了這個流程的設計意圖之后，我也清楚了這一點。對方的工程師承認了錯誤，但是問題是：“為什么不早說啊，我們都跟領導講過了產品的構架，也保證了交貨時間了，現在怎么去說??？”。他們設計的是一個蘋果，而我造了一個桔子出來。最后和工程師商議的結果是：先把桔子改成設計書上的蘋果，按時交貨，然后再悄悄的改成他們真正需要的香蕉。的這時候距離交貨的時間已經不足三天了，于是我每天加班工作到天明，把代碼逐行抽出來，用gcc編譯調試。好在大部分都是體力活，沒有什么技術含量，即使在深夜大腦半休眠的情況下仍然可以接著干。

項目中出現的另外一個錯誤是：我對工作量的估計非常的不準確。在第一個階段的時候，按照功能設計說明書中的一個流程，我做了一個示例，用上了投資方規定的所有的技術。當我打開瀏覽器，看到頁面上出現了數據庫里的“Tom，Jerry，王小帥”，就愉快的跑到走廊上去呼吸了一口新鮮空氣，然后樂觀的認為：設計書都已經寫好了，示例也做出來了，剩下的事情肯定就象砍瓜切菜一樣了。不就是把大家召集起來講講設計書，看看示例，然后撲上去開工，然后大功告成。我為每個畫面分配的編碼工作量是三個工作日。結果卻是，他們的設計并不完美，我的理解也并不正確，大家的思想也并不一致。于是我天天召集開會，朝令夕改，不斷返工。最后算了一下，實際上寫完一個畫面用的時間在十個工作日以上。編碼占用了太多的時間，測試在匆忙中草草了事，質量……能掩蓋的問題也就只好掩蓋一下了，性能更是無暇顧及了。

還有一個方面的問題是出在技術上的，這方面是我本文要說的重點。按照投資方的方案，系統的主體部分需要使用J2EE框架，選擇的中間件是免費的JBoss。再加上Tomcat作為Web服務器，Struts作為表示層的框架。他們對于這些東西的使用都是有明確目的，但是我并不了解這些技術。新手第一次進行OO設計，加上過多的新式技術，于是出現了一大堆的問題。公司原本安排了一個牛人對我進行指導，他熟悉OO設計，并且熟悉這些開源框架，曾熟讀Tomcat和Struts源代碼?？墒撬_實太忙，能指導我的時間非常有限。

投資方發來設計書以后，很快就派來了兩個工程師對這個說明書進行講解。這是一個功能設計說明書，包括一個數據庫設計說明書，和一個功能點設計說明。功能點說明里面敘述了每一個工作流程，畫面設計和數據流程。兩位工程師向我們簡單的說明了產品的構想，然后花了一個多星期的時間十分詳細的說明了他們的設計，包括數據表里每一個字段的含義，畫面上每一個控件的業務意義。除了這些功能性的需求以外，他們還有一些技術上的要求。

為了減少客戶的擁有成本，他們不想將產品綁定在特定的數據庫和操作系統上，并且希望使用免費的平臺。于是他們選擇了Java作為開發語言，并且使用了一系列免費的平臺。選用的中間件是JBoss，使用Entity Bean作為數據庫訪問的方式。我們對Entity Bean的效率不放心，因為猜測他運用了大量的反射技術。在經過一段時間的技術調查之后，我決定不采用Entity Bean，而是自己寫出一大堆的Value Object，每個Value Object對應一個數據庫表，Value Object里面只有一些setter和getter方法，只保存數據，不做任何事情。Value Object的屬性與數據庫里面的字段一一對應。與每個Value Object對應，做一個數據表的Gateway，負責把數據從數據庫里面查出來塞到這些Value Object里面，也負責把Value Object里面的數據塞回數據庫。

按照這樣的設計，需要為每一個數據表寫一個Gateway和一個Value Object，這個數量是比較龐大的。因此我們做了一個自動生成代碼的工具，到數據庫里面遍歷每一個數據表，然后遍歷表里面的每一個字段，把這些代碼自動生成出來。

這等于自己實現了一個ORM的機制。當時我們做這些事情的時候，ORM還是一個很陌生的名詞，Hibernate這樣的ORM框架還沒聽說過。接著我們還是需要解決系統在多種數據庫上運行的問題。Gateway是使用JDBC連接數據庫的，用SQL查詢和修改數據的。于是問題就是：要解決不同數據庫之間SQL的微小差別。我是這樣干的：我做了一個SqlParser接口，這個接口的作用是把ANSI SQL格式的查詢語句轉化成各種數據庫的查詢語句。當然我沒必要做的很全面，只要支持我在項目中用到的查詢方式和數據類型就夠了。然后再開發幾個具體的Parser來轉換不同的數據庫SQL格式。

到這個時候，數據庫里面的數據成功轉化成了程序里面的對象。非常好！按道理說，剩下的OO之路就該順理成章了。但是，很不幸，我不知道該怎樣用這些Value Object，接下來我就懷著困惑的心情把過程式的代碼嫁接在這個OO的基礎上了。

我為每一個畫面設計出了一個Session Bean，在這個Session Bean里面封裝了畫面所關聯的一切業務流程，讓這個Session Bean調用一大堆Value Object開始干活。在Session Bean和頁面之間，我沒有讓他們直接調用，因為據公司的牛人說：“頁面直接調用業務代碼不好，耦合性太強。”這句話沒錯，但是我對“業務代碼”的理解實在有問題，于是就硬生生的造出一個Helper來，阻擋在頁面和Session Bean中間，充當了一個傳聲筒的角色。

于是在開發中就出現了下面這副景象：每當設計發生變更，我就要修改數據庫的設計，用代碼生成工具重新生成Value Object，然后重新修改Session Bean里面的業務流程，按照新的參數和返回值修改Helper的代碼，最后修改頁面的調用代碼，修改頁面樣式。

實際情況比我現在說起來復雜的多。比如Value Object的修改，程序規模越來越大以后，我為了避免出現內存的大量占用和效率的下降，不得不把一些數據庫查詢的邏輯寫到了Gateway和Value Object里面，于是在發生變更的時候，我還要手工修改代碼生成工具生成的Gateway和Value Object。這樣的維護十分麻煩，這使我困惑OO到底有什么好處。我在這個項目中用OO方式解決了很多問題，而這些問題都是由OO本身造成的。

另一個比較大的問題出在Struts上。投資方為系統設計了很靈活的界面，界面上的所有元素都是可以配置出來，包括位置、數據來源、讀寫屬性。并且操作員的權限可以精確到每一個查看、修改的動作，可以控制每一個控件的讀寫操作。于是他們希望使用Struts。Struts框架的每一個Action恰好對應一個操作，只需要自己定義Action和權限角色的關系，就可以實現行為的權限控制。但是我錯誤的理解了Struts的用法，我為每一個頁面設計了一個Action，而不是為每一個行為設計一個Action，這樣根本就無法做到他們想要的權限控制方式。他們很快發現了我的問題，于是發來了一個說明書，向我介紹Struts的正確使用方式。說明書打印出來厚厚的一本，我翻了一天，終于知道了錯在什么地方。但是一大半畫面已經生米煮成熟飯，再加上我的Session Bean里面的流程又是按畫面來封裝的，于是只能改造小部分能改造的畫面，權限問題另找辦法解決了。

下面就是這個系統的全貌，場面看上去還是蔚為壯觀的：

系統經歷過數次較大的修改，這個框架不但沒有減輕變更的壓力，反而使得變更困難加大了。到后來，因為業務流程的變更的越來越復雜，現有流程無法修改，只得用一些十分曲折的方式來實現，運行效率越來越低。由于結構過于復雜，根本沒有辦法進行性能上的優化。為了平衡效率的延緩，不得不把越來越多的Value Object放在了內存中緩存起來，這又造成了內存占用的急劇增加。到后期調試程序的時候，服務器經常出現“Out of memory”異常，各類對象龐大繁多，系統編譯部署一次需要10多分鐘。投資方原先是希望我們使用JUnit來進行單元測試，但是這樣的流程代碼測試起來困難重重，要花費太多的時間和人手，也只得作罷。此外他們設計的很多功能其實都沒有實現，并且似乎以后也很難再實現了。設計中預想的很多優秀特點在這樣框架中一一消失，大家無奈的接受一個失望的局面。

在我離開公司兩年以后，這個系統仍然在持續開發中。新的模塊不斷的添加，框架上不斷添加新的功能點。有一次遇到仍然在公司工作的同事，他們說：“還是原來那個框架，前臺加上一個個的JSP，然后后臺加上一個個的Value Object，中間的Session Bean封裝越來越多的業務流程。”

我的第一個OO系統的設計，表面上使用了OO技術，實際上分析設計還是過程主導的方式。設計的時候過多、過早、過深入的考慮了需要做哪些畫面，畫面上應該有哪些功能點，功能點的數據流程。再加上一個復雜的OO框架，名目繁多的對象，不僅無法做到快速的開發，靈活的適應需求的變化，反而使系統變得更加復雜，功能修改更加的麻煩了。

在面條式代碼的時代，很多人用匯編代碼寫出了一個個優秀的程序。他們利用一些工具，或者共同遵守一些特別的規約，采用一致的變量命名方式，規范的代碼注釋，可以使一個龐大的開發團隊運行的井井有條。人如果有了先進的思想，工具在這些人的手中就可以發揮出超越時代的能量。而我設計的第一個OO系統，恰好是一個相反的例子。

實際上，面向對象的最獨特之處，在于他分析需求的方式。按照這樣的方式，不要過分的糾纏于程序的畫面、操作的過程，數據的流程，而是要更加深入的探索需求中的一些重要概念。下面，我們就通過一個實例看一看，怎樣去抓住需求中的這些重要概念，并且運用OO方法把他融合到程序設計中。也看看OO技術是如何幫助開發人員控制程序的復雜度，讓大家工作的更加簡單、高效。

我們來看看一個通信公司的賬務系統的開發情況。最開始，開發人員找到電信公司的職員詢問需求的情況。電信公司的職員是這樣說的：

“賬務系統主要做這樣幾件事情：每個月1日凌晨按照用戶使用情況生成賬單，然后用預存沖銷這個賬單。還要受理用戶的繳費，繳費后可以自動沖銷欠費的賬單，欠費用戶繳清費用之后要發指令到交換上，開啟他的服務。費用繳清以后可以打印發票，發票就是下面這個樣子。”

經過一番調查，開發人員設計了下面幾個主要的流程：

1、 出賬：根據一個月內用戶的消費情況生成賬單；

2、 銷賬：沖銷用戶賬戶上的余額和賬單；

3、 繳費：用戶向自己的賬戶上繳費，繳清欠費后打印發票。

弄清了流程，接著就設計用戶界面來實現這樣的流程。下面是其中一個數據查詢界面，分為兩個部分：上半部分是繳費信息，記錄了用戶的繳費歷史；下半部分是賬單信息，顯示賬單的費用和銷賬情況。

界面上的數據一眼看起來很復雜，其實結合出賬、繳費、銷賬的流程講解一下，是比較容易理解的。下面簡單說明一下。

繳費的時候，在繳費信息上添加一條記錄，記錄下繳費金額。然后查找有沒有欠費的賬單，如果有就做銷賬。沖抵欠費的金額記錄在“欠費金額”的位置。如果欠費時間較長，就計算滯納金，記錄在“滯納金”的位置上。沖銷欠費以后，剩余的金額記錄在“預存款”的位置上。“其他費用”這個位置是預留的，目前沒有作用。

每個月出賬的時候，在賬單信息里面加上一條記錄，記錄下賬單的應收和優惠，這兩部分相減就是賬單的總金額。然后檢查一下賬戶上有沒有余額，如果有就做銷賬。銷賬的時候，預存款沖銷的部分記錄在“預存劃撥”的位置，如果不足以沖抵欠費，賬單就暫時處于“未繳”狀態。等到下次繳費的時候，沖銷的金額再記錄到“新交款”的位置。等到所有費用繳清了，賬單狀態變成“已繳”。

銷賬的流程就這樣融合在繳費和出賬的過程中。

看起來一切成功搞定了，最重要的幾個流程很明確了，剩下的事情無疑就像砍瓜切菜一樣。無非是繞著這幾個流程，設計出其他更多的流程?，F在有個小問題：打印發票的時候，發票的右側需要有上次結余、本次實繳、本次話費、本次結余這幾個金額。

上次結余：上個月賬單銷賬后剩下來的金額，這個容易理解；

本次結余：當前的賬單銷賬后剩下的金額，這個也不難；

本次話費：這是賬單的費用，還是最后一次完全銷賬時的繳費，應該用哪一個呢？

本次繳費：這個和本次話費有什么區別，他在哪里算出來？

帶著問題，開發者去問電信公司的職員。開發者把他們設計的界面指點給用戶看，向他說明了自己的設計的這幾個流程，同時也說出了自己的疑問。用戶沒有直接回答這個疑問，卻提出了另一個問題：

“繳費打發票這個流程并不總是這樣的，繳費以后不一定立刻要打印發票的。我們的用戶可以在銀行、超市這樣的地方繳話費，幾個月以后才來到我們這里打印發票。并且繳費的時間和銷賬的時間可以相距很長的，可以先繳納一筆話費，后面幾個月的賬單都用這筆錢銷賬；也可以幾個月都不繳費，然后繳納一筆費用沖銷這幾個賬單。你們設計的這個界面不能很好的體現用戶的繳費和消費情況，很難看出來某一次繳費是在什么時候用完的。必須從第一次、或者最后一次繳費余額推算這個歷史，太麻煩了。還有，‘預存劃撥’、‘新交款’這兩個概念我們以前從來沒有見過，對用戶解釋起來肯定是很麻煩的。”

開發人員平靜了一下自己沮喪（或憤怒）的心情，仔細想一想，這樣的設計確實很不合理。如果一個會計記出這樣的賬本來，他肯定會被老板開除的。

看起來流程要改，比先前設計的更加靈活，界面也要改。就好像原先蓋好的一棟房子忽然被捅了幾個窟窿，變得四處透風了。還有，那四個數值到底應該怎樣計算出來呢？我們先到走廊上去呼吸兩口新鮮空氣，然后再回來想想吧。

現在，讓我們先忘記這幾個變化多端的流程，花一點時間想一想最基本的幾個概念吧。系統里面最顯而易見的一個概念是什么呢？沒錯，是賬戶（Account）。賬戶可以繳費和消費。每個月消費的情況是記錄在一個賬單（Bill）里面的。賬戶和賬單之間是一對多的關系。此外，賬戶還有另一個重要的相關的概念：繳費（Deposit）。賬戶和繳費之間也是一對多的關系。在我們剛才的設計中，這些對象是這樣的：

這個設計看來有些問題，使用了一些用戶聞所未聞的概念（預存劃撥，新交款）。并且他分離了繳費和消費，表面上很清楚，實際上使賬單的查詢變得困難了。在實現一些功能的時候確實比較簡單（比如繳費和銷賬），但是另一些功能變得很困難（比如打印發票）。問題到底在什么地方呢？

涉及到賬務的行業有很多，最容易想到的也許就是銀行了。從銀行身上，我們是不是可以學到什么呢？下面是一個銀行的存折，這是一個委托收款的賬號。用戶在賬戶上定期存錢，然后他的消費會自動從這里扣除。這個情景和我們需要實現的需求很相似?？梢杂^察一下這個存折，存入和支取都是記錄在同一列上的，在支出或者存入的右側記錄當時的結余。

有兩次賬戶上的金額被扣除到0，這時候金額已經被全部扣除了，但是消費還沒有完全沖銷。等到再次存入以后，會繼續支取。這種記賬的方式就是最基本的流水賬，每一條存入和支出都要記錄為一條賬目（Entry）。程序的設計應該是這樣：

這個結構看上去和剛才那個似乎沒有什么不同，其實差別是很大的。上面的那個Deposit只是繳費記錄，這里的Entry是賬目，包括繳費、扣費、滯納金……所有的費用。銷賬扣費的過程不應該記錄在賬單中，而是應該以賬目的形式記錄下來。Account的代碼片段如下：

Entry有很多種類型（存入、支取、滯納金、贈送費），可以考慮可以為每一種類型創建一個子類，就像這樣：

搞成父子關系看起來很復雜、麻煩，并且目前也看不出將這些類型作為Entry的子類有哪些好處。所以我們決定不這樣做，只是簡單的把這幾種類型作為Entry的一個屬性。Entry的代碼片段如下：

Entry是一個枚舉類型，代碼如下：

下面的界面顯示的就是剛才那個賬戶的賬目。要顯示這個界面只需要調用Account的GetEntrees方法，得到所有的賬目，然后按時間順序顯示出來。這個界面上的消費情況就明確多了，用戶很容易弄明白某個繳費是在哪幾個月份被消費掉的。

并且，發票上的那幾個一直搞不明白的數值也有了答案。比如2005年6月份的發票，我們先看看2005年6月份銷賬的所有賬目（第六行、第八行），這兩次一共扣除73.66元，這個金額就是本次消費；兩次扣除之間存入200元，這個就是本次實繳；第五行的結余是17.66元，這就是上次結余；第八行上的結余是144元，這個就是本次結余。

用戶檢查了這個設計，覺得這樣的費用顯示明確多了。盡管一些措辭不符合習慣的業務詞匯，但是他們的概念都是符合的。并且上次還有一個需求沒有說：有時候需要把多個月份的發票合在一起打印。按照這樣的賬目表達方式，合并的發票數值也比較容易搞清楚了。明確了這樣的對象關系，實現這個需求其實很容易。

面向對象的設計就是要這樣，不要急于確定系統需要做哪些功能點和哪些界面，而是首先要深入的探索需求中出現的概念。在具體的流程不甚清楚的情況下，先把這些概念搞清楚，一個一個的開發出來。然后只要把這些做好的零件拿過來，千變萬化的流程其實就變得很簡單了，一番搭積木式的裝配就可以比較輕松的實現。

另一個重要的類型也漸漸清晰的浮現在我們的眼前：賬單（Bill）。他的代碼片段如下：

Bill類有兩個與滯納金有關的方法，這使開發者想到了原先忽略的一個流程：計算滯納金。經過與電信公司的確認，決定每個月進行一次計算滯納金的工作。開發人員寫了一個腳本，先得到系統中所有的欠費賬單，然后一一調用他們的CaculatePenalty方法。每個月將這個腳本執行一次，就可以完成滯納金的計算工作。

Bill對象中有賬戶的基本屬性和各級賬目的金額和銷賬的情況，要打印發票，只有這些數值是不夠的。還要涉及到上次結余、本次結余和本次實繳，這三個數值是需要從賬目中查到的。并且發票有嚴格的格式要求，也不需要顯示費用的細節，只要顯示一級和二級的費用類就可以了。應該把這些東西另外封裝成一個類：發票（Invoice）：

通信公司后來又提出了新的需求：有些賬號和銀行簽訂了托收協議，每個月通信公司打印出這些賬戶的托收單交給銀行，銀行從個人結算賬戶上扣除這筆錢，再把一個扣費單交給通信公司。通信公司根據這個扣費單沖銷用戶的欠費。于是開發人員可以再做一個托收單（DeputyBill）：

賬單中的GetFee方法的返回值類型是Fee，Fee類型包含了費用的名稱、金額和他包含的其他費用。例如下面的情況：

我們可以用這樣的一個類來表示費用（Fee），一個費用可以包含其他的費用，他的金額是子費用的金額和。代碼片段如下：

現在開發者設計出了這么一堆類，構成軟件系統的主要零件就這么制造出來了。下面要做的就是把這些零件串在一起，去實現需要的功能。OO設計的重點就是要找到這些零件。就像是設計一輛汽車，僅僅知道油路、電路、傳動的各項流程是不夠的，重要的是知道造一輛汽車需要先制造哪些零件。要想正確的把這些零件設計出來不是一件容易的事情，很少有開發者一開始就了解系統的需求，設計出合理的對象關系。根本的原因在于領域知識的貧乏，開發者和用戶之間也缺乏必要的交流。很多人在軟件開發的過程中才漸漸意識到原來的設計中存在一些難受的地方，然后探索下去，才知道了正確的方式，這就是業務知識的一個突破。不幸的是，當這個突破到來的時候，程序員經常是已經忙得熱火朝天，快把代碼寫完了。要把一切恢復到正常的軌道上，需要勇氣，時間，有遠見的領導者，也需要有運氣。