【正文】 理。只需要極少的幾行代碼，遠程不同類型的客戶端就可以很容易的訪問到企業(yè)Bean. 一個EJB組件由一個Bean類，兩個接口組成。Bean類包含了企業(yè)應用事務邏輯實現(xiàn)細節(jié)的一個類。遠程接口定義了相應Bean類公開的所有事務方法。這些事務方法僅僅對客戶應用程序是可見的。引導接口定義了Bean生命周期的方法，這些方法用來創(chuàng)建新的Bean。圖22顯示了EJB運行時候的環(huán)境。┌─────────────────────────────┐│咚公白 ┌──────────────────┐ ││┌───┐│毛少 │ │││客戶端││ 應用服務器│┌──┐│││程序 ││ ││數(shù)據(jù)│││└───┘│ ││庫 │││ │ │└──┘││ └──────────────────┘ │└─────────────────────────────┘圖22 EJB運行時環(huán)境基于J2EE架構的電子政務網(wǎng)上申報審批系統(tǒng)的設計與實現(xiàn) 會話Bean(Session Bean)表現(xiàn)連接到J2EE服務器的一個單獨的客戶端。會話Bean被用來實現(xiàn)一個具有特定客戶事務邏輯的事務對象。客戶端通過調用會話Bean的方法來訪問部署在服務器上的應用程序。會話Bean完成客戶端的請求，從而對客戶端隱藏了服務器內復雜商務邏輯的執(zhí)行過程。 正如會話Bean的名稱所表示的，它代表一次會話。單獨的會話Bean對象是不可以共享的，它只能有一個客戶端訪問，同樣一次會話也只能有一個用戶。和一次會話一樣，會話Bean對象不是持久性對象。(就是說它的數(shù)據(jù)并不保存到數(shù)據(jù)庫。)當客戶端結束運行，對應的會話Bean也跟著結束并斷開與客戶端的聯(lián)系(不保留特定客戶端的任何信息)。 會話Bean在客戶程序和Bean之間保持會話。不同形式的會話可以模型化兩種類型的會話Bean，分別是有狀態(tài)((stateful)會話Bean和無狀態(tài)((stateless)會話Bean. 1)有狀態(tài)會話Bean是客戶應用程序的擴展。它代表客戶程序執(zhí)行任務并維護客戶程序相關的狀態(tài)。該狀態(tài)稱為會話狀態(tài)，因為它代表一個有狀態(tài)會話Bean與客戶程序之間的持續(xù)會話。在有狀態(tài)會話Bean中調用的方法即可以從該會話狀態(tài)中讀取數(shù)據(jù)，也可將數(shù)據(jù)寫入該狀態(tài)中如圖23所示。該狀態(tài)可以被該會話Bean所調用的所有方法共享。如果客戶程序終止，則會話就終止，狀態(tài)就消失了。有狀態(tài)會話Bean 圖23有狀態(tài)會話Bean 2)無狀態(tài)會話Bean不為特定的客戶程序保持會話狀態(tài)。僅僅是一組類似于批處理的相關服務，每一服務由一個方法來表示如圖24所示。其狀態(tài)也僅僅在基于J2EE架構的電子政務網(wǎng)上申報審批系統(tǒng)的設計與實現(xiàn)方法調用期間持續(xù)，當方法完成后，狀態(tài)也就不再保持了。與有狀態(tài)會話Bean的只服務于一個特定客戶程序相比，無狀態(tài)會話Bean對于需要大量客戶程序應用可以提供更好的可伸縮性[[6]0無狀態(tài)會話Bean 圖2一無狀態(tài)會話Bean 一個實體Bean(EntityBean)描述一個持久存儲備的商業(yè)對象。實體Bean常用來表示永久性數(shù)據(jù)并提供相關的操作這些數(shù)據(jù)的方法。一個實體Bean類的實例是唯一的，它們可以被多個用戶訪問。一個典型的例子是:每個實體Bean在關系數(shù)據(jù)庫中都有一個基本表，每個Bean類的實例相當于該表的一行。 實體Bean和會話Bean最大的區(qū)別在于實體Bean具有持久性、允許共享訪問和主鍵的特性。實體Bean的狀態(tài)保存在持久存儲介質中，該狀態(tài)的存在超越了應用程序的生命周期。 根據(jù)管理持久性的方式劃分，有兩種實體Bean，分別是容器管理持久((CMP)的實體Bean和Bean管理持久((BMP)的實體Bean. 1) Bean管理持久:管理自身持久性的實體Bean稱為Bean管理持久實體Bean。對于這種實體Bean, EJB開發(fā)者需要通過編寫數(shù)據(jù)庫調用或其他方式對持久存儲的訪問，來明確的編寫B(tài)ean的持久性邏輯。在大多數(shù)情況下，開發(fā)者使用JDBC來編寫持久性邏輯。 2)容器管理持久:由容器來處理實體Bean要求的所有數(shù)據(jù)訪問和持久性工作。在開發(fā)CMP實體Bean的時候，開發(fā)人員不需要知道用何種數(shù)據(jù)源來提供Bean的持久狀態(tài)，他們只需要制定那個域是持久的即可。所有訪問數(shù)據(jù)庫所需的JDBC代碼都是自動產生的，沒有任何SQL嵌入到Bean代碼中，Bean也沒基于J2EE架構的電子政務網(wǎng)上申報審批系統(tǒng)的設計與實現(xiàn)有綁定到特定的數(shù)據(jù)庫，是完全可以移植的。 J2EE中的事務管理 事務是健壯的服務器端開發(fā)所必須的一種關鍵性的服務。事務一般被定義為一個不可分割的工作單元。 JDBC事務 JDBC事務通過DBMS事務管理器來控制?？赡軙榱耸褂脮払ean中的原有代碼而采用JDBC事務將這些代碼封裝到一個事務中。使用JDBC事務，要。事務啟動是隱式的。一個事務得從最近的提交、回滾或連接操作后的第一個SQL的語句開始[[7]e JTA事務 JTA是Java Transaction API的縮寫。這些API允許用獨立于具體的事務管理器實現(xiàn)的方法確定事務界限。J2EE SDK事務管理器通過Java事務服務(JavaTransaction Service, JTS)實現(xiàn)。但是代碼并不直接調用JTS中的方法，而是調用JTA方法來替代，JTA方法會調用底層的JTS實現(xiàn)。 JTA事務被J2EE事務管理器管理?？赡苄枰褂靡粋€JTA事務，因為它能夠統(tǒng)一操作不同廠商的數(shù)據(jù)庫。一個特定DBMS的事務管理器不能工作在不同種類的數(shù)據(jù)庫上。然而J2EE事務管理器仍然有一個限制—它不支持嵌套事務。就是說，它不能在前一個事務結束前啟動另一個事務[f810 J2EE中的資源連接 JNDI是Java命名和目錄接口的首字母縮寫。J2EE平臺通過用M名來定位提供服務(資源訪問)的對象。JNDI名是由J2EE服務器提供的命名和目錄服務綁定到特定對象的用戶友好的訪問名稱，因為J2EE組件通過」NDI API來訪問這些服務，所以通常稱這些對象訪問名為JNDI名。例如」dbc/Cloudscape是Cloudscape數(shù)據(jù)庫的JNDI名，設置好后，J2EE服務器在啟動的時候從配置文件里讀取該信息，并自動將該」NDI名添加到名字空間。 并不是直接通過JNDI查找到資源訪問對象的。查找得到的是連接工廠。連接工廠“生產”出資源訪問對象。數(shù)據(jù)庫資源的連接工廠是」對象。在代碼中，并不是接通過JNDI名來查找資源，而是資源引用。具體地說就是通過資源引用來查找資源基于J2EE架構的電子政務網(wǎng)上申報審批系統(tǒng)的設計與實現(xiàn)工廠。資源引用是資源查找中l(wèi)ookup方法的實際參數(shù)(當然JNDI名也可以)，它在部署描述符中指定。 JNDI名和資源引用名是不相同的，所以需要建立兩者之間的映射關系。但是它可以降低組件和資源之間的禍合，這樣當組件需要訪問不同的資源時，可以不用改變資源引用名。這種靈活性使得更容易在已有組件的基礎上裝配應用程序。 設計模式是用來描述所交流的問題及其解決方案。設計模式可以幫助我們在一個特定的環(huán)境里整理并記錄己知的可重現(xiàn)的問題及其解決方案，并且通過模式來與他人交流這些知識。設計模式的思想認為在系統(tǒng)設計這一層次上，軟件開發(fā)可以抽象成一種模式，模式描述了系統(tǒng)面臨的問題及其解決方案，并且可以重用。每一個模式描述了一個在我們周圍不斷重復發(fā)生的問題，以及該問題的解決方案的核心。這樣，就能一次又一次的使用該解決方案而不必做重復勞動。每個模式是由三部分組成的一個規(guī)則，這個規(guī)則描述特定環(huán)境、問題和解決方案之間的關系。簡單的說，沒有一個模式是獨立的實體，每個模式都存在著相互支持，但支持的程度不同:大的模式可以內嵌小的模式，同等層次的模式并列存在，而小的模式被嵌入到大的模式之中。 設計模式的基本思想是，公共的“習‘質用法”(Idioms)在軟件設計中被不斷重復發(fā)現(xiàn)，因此這些模式應該被有意識地歸納整理，并用于類似問題的解決上[[9]0(pattern name) 一個助記名，它用一兩個詞來描述模式的問題、解決方案和效果。命名一個新的模式增加了我們的設計詞匯。設計模式允許我們在較高的抽象層次上進行設計?；谝粋€模式詞匯表，我們自己以及同事之間就可以討論模式并在編寫文檔時使用它們。模式名可以幫助我們思考，便于我們與其他人交流設計思想及設計結果。找到恰當?shù)哪Ｊ矫彩俏覀冊O計模式編目工作的難點之一。2. IA題((problem) 描述了應該在何時使用模式。它解釋了設計問題和問題存在的前因后果，它基于J2EE架構的電子政務網(wǎng)上申報審批系統(tǒng)的設計與實現(xiàn)可能描述了特定的設計問題，如怎樣用對象表示算法等。也可能描述了導致不靈活設計的類或對象結構。有時候，問題部分會包括使用模式必須滿足的一系列先決條件。(solution) 顧名思義，解決方案描述了設計的組成成分及成分間的關系及各自的職責，以及成分之間如何進行協(xié)作。由于模式是對一類問題的抽象，所以不描述具體問題的設計或實現(xiàn)，而是提供設計問題的抽象描述和怎樣用一個具有一般意義的元素組合(類或對象組合)來解決這個問題。(consequences) 描述了模式應用的效果及使用模式應權衡的問題。盡管我們描述設計決策時，并不總提到模式效果，但它們對于評價設計選擇和理解使用模式的代價及好處具有重要意義。軟件效果大多關注對時間和空間的衡量，它們也表述了語言和實現(xiàn)問題。因為復用是面向對象設計的要素之一，所以模式效果包括它對系統(tǒng)的靈活性、擴充性或可移植性的影響，列出這些效果對理解和評價這些模式很有幫助。 設計模式為開發(fā)者提供了好的設計經驗，為項目之間、程序員之間重用面向對象代碼提供一種方便的途徑，使得重用成功設計和結構更加容易110]0 MVC設計模式 MVC英文即ModelViewController，即模型一視圖一控制器模式，是設計模式中很重要的一種。它包括三種對象:模型((model)、視圖(view)和控制器(Controller)。模型提供了業(yè)務邏輯，視圖則是模型在屏幕上的顯示，控制器是用于管理用戶和視圖發(fā)生的交互。圖25揭示了三者之間的關系。 視圖((View):代表用戶交互界面。主管應用程序和人之間的接口，一方面它為用戶提供了輸入手段，并觸發(fā)應用邏輯運行。另一方面，它又將邏輯運行結果以某種形式顯示給用戶。對于Web應用來說，可以概括為HTML界面，但有可能為XHTML,XML和Applet o 模型(Model):就是業(yè)務流程/狀態(tài)的處理以及業(yè)務規(guī)則的制定。業(yè)務流程的處理過程對其它層來說是黑箱操作，模型接受視圖請求的數(shù)據(jù)，并返回最終的處理結果。業(yè)務模型的設計可以說是MVC最主要的核心?；贘2EE架構的電子政務網(wǎng)上申報審批系統(tǒng)的設計與實現(xiàn) 控制((Controller):可以理解為從用戶接收請求，將模型與視圖匹配在一起，共同完成用戶的請求。劃分控制層的作用也很明顯，它就是一個分發(fā)器，選擇什么樣的模型，選擇什么樣的視圖，可以完成什么樣的用戶請求?？刂茖硬⒉蛔鋈魏蔚臄?shù)據(jù)處理。 圖25 MVC結構圖 J2EE設計模式 J2EE設計模式有很多。下面主要分析與文中介紹網(wǎng)上申報審批系統(tǒng)框架設計有關的部分設計模式:((FrontController): 系統(tǒng)需要一個集中的訪問點來處理請求。如果沒有集中訪問點，那么多個請求之間公用控制代碼就會在許多文件(比如視圖文件)中重復出現(xiàn)。因此提出前端控制器模式以達到避免重復控制邏輯，并對多個請求采取共通的處理邏輯的目的。 使用前端控制器作最初的接觸點，用來處理所有相關請求。前端控制器為處理請求提供了一個集中的入口點，能集中控制邏輯，因此減少了直接置入視圖的代碼量，提高多個請求之間代碼的重用度，減少代碼重復。圖26顯示了前端控制器的類圖[fitl0基于J2EE架構的電子政務網(wǎng)上申報審批系統(tǒng)的設計與實現(xiàn)ClientFrontControllersends requestsServletFrontJSPFront 圖26前端控制器類圖((ViewHelper) 視圖助手模式就是使用視圖封裝顯示格式的代碼，使用助手封裝視圖處理器。助手通過POJO(plain old java object普通Java對象)、定制標記或標記文件的形式實現(xiàn)。視圖把處理邏輯交給這些助手完成，助手在視圖和模型之間充當了適配器的作用，同時也會執(zhí)行一些與格式邏輯相關的處理。 視圖助手把程序邏輯從視圖中分離開，這樣就可以更明確軟件開發(fā)者和網(wǎng)頁設計者之間的分工。圖27顯示了視圖助手的類圖。HelperCustomTagTa