【導(dǎo)讀】本文首先介紹了OA系統(tǒng)的整體需求說(shuō)明，列出了各部分功能模塊。個(gè)人辦公、模板管理、車(chē)輛管理、信息中心、資料管理。隨后本文提出了系統(tǒng)分層開(kāi)。發(fā)的整體架構(gòu)，包括：數(shù)據(jù)持久化層、業(yè)務(wù)邏輯層、Web應(yīng)用層。其中，邏輯應(yīng)用層。要應(yīng)用場(chǎng)景，包括：發(fā)文流程、出車(chē)流程、資料借閱流程。同時(shí)本文也指出了引入jBPM的優(yōu)勢(shì)以及將面臨的問(wèn)題，模塊開(kāi)發(fā)方式的選擇。流模塊，并給出了模塊的測(cè)試和運(yùn)行效果。在工作流模塊中，本文給出了流程實(shí)例的動(dòng)態(tài)執(zhí)行流程圖顯?？刂坪晚?yè)面顯示。在測(cè)試過(guò)程中，本文實(shí)現(xiàn)了方便用于單元測(cè)試的工具類(lèi)，用于提供。一個(gè)沒(méi)有干擾項(xiàng)數(shù)據(jù)的測(cè)試環(huán)境，降低測(cè)試中的復(fù)雜性。大量的開(kāi)源工具，并在附錄中給出了各種工具基于的開(kāi)源許可協(xié)議。

　　

【正文】 。 14 14 圖 17 企業(yè)級(jí) 系統(tǒng) 應(yīng)用模型 圖 17 所示的是 J2EE 系統(tǒng)的 分層 模型 ，主要分為 四個(gè)層次 ： 客戶(hù)端表現(xiàn)層、服務(wù)器端 表現(xiàn) 層、服務(wù)器端業(yè)務(wù)邏輯層、企業(yè)信息系統(tǒng) 層 。 [23] 客戶(hù)端表現(xiàn)層是用來(lái) 把客戶(hù)請(qǐng)求的信息展現(xiàn)到客戶(hù)面前，主要有如下幾種技術(shù)：純 HTML 技術(shù)、 Java Applet、 一般的 Java 程序 、其他的 J2EE 客戶(hù)端如移動(dòng)設(shè)備 。 客戶(hù)端表現(xiàn)層把顯示功能從業(yè)務(wù)邏輯中分離了出來(lái) 。 服務(wù)器端表現(xiàn)層指的是將業(yè)務(wù)邏輯返回的數(shù)據(jù)通過(guò)某種格式傳遞給客戶(hù)端表現(xiàn)層。 主要的技術(shù)有： Java Servlet、 JSP、 XML、 WebService。 其中 Servlet 是一種實(shí)現(xiàn)了多線程請(qǐng)求響應(yīng)模型的技術(shù)，克服了傳統(tǒng) CGI(Common Gateway Interface)程序效率低的問(wèn)題 ； JSP 是基于 Servlet 的便于編寫(xiě)網(wǎng)頁(yè)的顯示層技術(shù)，它會(huì)被 JSP 容器編譯為Servlet 的 class 文件 ， Servlet 和 JSP 都需要有 Web 容器支持 。 服務(wù)器端 表 現(xiàn)層 主要用于表現(xiàn) 層 邏輯的控制，以及 生成用于客戶(hù)端表現(xiàn)層顯示的數(shù)據(jù) ，如 HTML 文本 。 服務(wù)器端表現(xiàn)層將服務(wù)器端的業(yè)務(wù) 處理 和結(jié)果 數(shù)據(jù)返回分離開(kāi)來(lái)，降低了系統(tǒng)業(yè)務(wù)和表現(xiàn)之間的耦合性 ，提高了系統(tǒng)的可重用性及可維護(hù)性 。 服務(wù)器端業(yè)務(wù)邏輯層主要負(fù)責(zé)業(yè)務(wù)的處理，主要技術(shù)有： EJB(Enterpise JavaBeans)、 WebService。 EJB 技術(shù)是服務(wù)器端的組件，主要用于處理分布式應(yīng)用程序。 EJB 主要分為會(huì)話 Bean(Session Bean)、實(shí)體 Bean(Entity Bean)和消息驅(qū)動(dòng)Bean(MessageDriven Bean)，會(huì)話 Bean 用于實(shí)現(xiàn)業(yè)務(wù)邏輯，分為有狀態(tài)和無(wú)狀態(tài)兩種形式，當(dāng)用戶(hù)請(qǐng)求到來(lái)時(shí)，由 EJB 容器選擇創(chuàng)建 EJB 對(duì)象；實(shí)體 Bean 用于實(shí) 現(xiàn)對(duì)象關(guān)系映射，每個(gè)實(shí)體 Bean 對(duì)應(yīng)一條數(shù)據(jù)庫(kù)記錄，可以讓開(kāi)發(fā)人員使用面向?qū)ο蟮姆椒ü芾黻P(guān)系型數(shù)據(jù)庫(kù)；消息驅(qū)動(dòng) Bean 基于 JMS(Java Messaging Service)， 用于 實(shí)現(xiàn)會(huì)話 Bean 異步接受 JMS 消息 。 服務(wù)器端業(yè)務(wù)邏輯層是整個(gè)系統(tǒng)的功能邏輯核心 ，專(zhuān)注于企業(yè)的業(yè)務(wù)處理。 企業(yè)信息系統(tǒng)層是 企業(yè) 數(shù)據(jù)中心， 存儲(chǔ)了所有企業(yè)系統(tǒng)的數(shù)據(jù)資料，是整個(gè) 企業(yè)應(yīng)用系統(tǒng) 最根本的價(jià)值所在。 一般包括了企業(yè)基礎(chǔ)建設(shè)系統(tǒng)如企業(yè)資源計(jì)劃 (ERP)、 15 15 大型機(jī)事務(wù)處理、數(shù)據(jù)庫(kù)系統(tǒng)以其他遺留信息系統(tǒng)。 在業(yè)務(wù)層和數(shù)據(jù)層之間， J2EE提供了 JDBC(Java DataBase Connectivity)接口來(lái)簡(jiǎn)化數(shù)據(jù)庫(kù)的開(kāi)發(fā)。 Java 分布式對(duì)象技術(shù)簡(jiǎn)介 分布式對(duì)象技術(shù)是分布式計(jì)算技術(shù)和面向?qū)ο笏枷胂嘟Y(jié)合的一種技術(shù)，系統(tǒng)中的對(duì)象以分布式的方式相互作用，構(gòu)成一個(gè)完整的面向?qū)ο蟮姆植际较到y(tǒng)。 目前主要有三種 體系規(guī)范 ： CORBA、 COM+、 EJB。 [9] CORBA 全稱(chēng) Common Object Request Broker Architecture，公共對(duì)象請(qǐng)求代理體系結(jié)構(gòu)，是由 OMG(Object Management Group，對(duì)象管理 組織 )組織制訂的一種標(biāo)準(zhǔn)的面向?qū)ο髴?yīng)用程序體系規(guī)范。 CORBA 的組件之間基于 IIOP(Inter InterORB Protocol)進(jìn)行通信。 COM 全稱(chēng) Component Object Model，組件對(duì)象模型 。 COM+是 微軟 公司 推出的 基于 COM 組件模型的 分布式組件對(duì)象模型 ，是微軟 .NET 框架的一個(gè)組成部分 ，組件間 通過(guò) .NET Remoting 框架技術(shù)進(jìn)行交互 ，采用 SOAP(Simple Object Access Protocol，簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議 )等通信方式 。 EJB 全稱(chēng) Enterpise JavaBean，企業(yè) Java 組件 ，是 J2EE 的 組件模型 。 EJB 使用 Java RMI 和 Java IDL 技術(shù)作為其分布式對(duì)象模型 。 Java RMI(Java Remote Method Invocation， Java 遠(yuǎn)程方法調(diào)用 )是 Java 平臺(tái)的分布式對(duì)象通信模型 。 Java 的分布式對(duì)象技術(shù)，包括 JavaRMI、 RMI— IIOP 和 JavaIDL。 RMI 支持兩種引用層消息協(xié)議 — JRMP 和 IIOP。開(kāi)發(fā)者可以選擇完全工作在 Java 環(huán)境下，使用 JRMP作為傳輸協(xié)議；也可以選擇使用 IIOP 協(xié)議，與其它的 CORBA 兼 容的語(yǔ)言一起工作。Sun 的 J2SE 平臺(tái)還包含 ORB 軟件和 Java IDL API，它本質(zhì)上是 CORBA 的 Java 語(yǔ)言映射的實(shí)現(xiàn)。通過(guò)使用 Java IDL，可以用 Java 語(yǔ)言開(kāi)發(fā) CORBA 應(yīng)用。 Java RMI(RMI/JRMP) 使用 JRMP 的 RMI 一般稱(chēng)為 RMI/JRMP，或簡(jiǎn)稱(chēng) Java RMI。 JRMP 是 Java 標(biāo)準(zhǔn)的遠(yuǎn)程調(diào)用的傳輸協(xié)議，在 TCP/IP 之上操作，在 RMI 中，JRMP 是 RMI 專(zhuān)用的，但是在 RMI 中已經(jīng)可以使用 JRMP 和 IIOP 了。使用RMI/JRMP 可以通過(guò) HTTP 服務(wù)器信 通，這需要在發(fā)送消 息時(shí)加上一個(gè)HTTPostHeader 標(biāo)識(shí)符，在接收消息時(shí)加上一個(gè) HTTPResponseHeader 標(biāo)識(shí)符。 使用 Java RMI編譯器 (rmic)編譯用 Java語(yǔ)言來(lái)編寫(xiě)服務(wù)器實(shí)現(xiàn)類(lèi)，可以生成 JRMP存根和框架， CORBA 客戶(hù)機(jī)利用 IDL 文件訪問(wèn) RMI 服務(wù)器。 JRMP 使用的存根 (Stub)用 JRMP 協(xié) 議 與 服 務(wù) 器 框 架 通 信 。 RMI/JRMP 的 服 務(wù) 器 實(shí) 現(xiàn) 要 繼 承 類(lèi)。 建立服務(wù)器對(duì)象 之后，就可以 分 布這個(gè)對(duì)象，即讓分布式 客戶(hù)機(jī)能夠訪問(wèn) RMI服務(wù)器。 RMI/JRMP 使用 RMI 注冊(cè)表 (RMI Registry)的命名服務(wù)定位遠(yuǎn)程對(duì)象，通過(guò)rmiregistry 工具提供。 RMI 框架提供了訪問(wèn) RMI 注冊(cè)表的簡(jiǎn)單方法： JRMP 服務(wù)器應(yīng)用程序可以使用 ()方法注冊(cè)遠(yuǎn)程服務(wù)對(duì)象到 RMI注冊(cè)表： JRMP客戶(hù)機(jī)可以使用 ()方法查找服務(wù)器對(duì)象，得到所需服務(wù)接口。但是， rmiregistry 不支持持久命名服務(wù)。 RMI/JRMP 還支持分布式垃圾收集 (Distributed Garbage Collection， DGC)特性。 16 16 RMI/JRMP 適合于全部使用 Java 語(yǔ)言編寫(xiě)的應(yīng)用程序，以實(shí)現(xiàn)不同虛擬機(jī)和不同物理機(jī)器上的 Java 對(duì)象間的通信，在可移植性、安全性以及分布式垃圾回收等方面具有 優(yōu)勢(shì) 。 [9] RMIIIOP 使用 IIOP 協(xié)議的 RMI 一般稱(chēng)為 RMI— IIOP(Java RMI over IIOP)。 RMIIIOP 由Sun 公司和 IBM 公司聯(lián)合開(kāi)發(fā)，是 J2EE 和 J2SE 平臺(tái)的一部分。和 CORBA 一樣，RMIIIOP 基于由 OMG 中許許多多廠商和用戶(hù)參與制定的開(kāi) 放標(biāo)準(zhǔn)。 RMIIIOP 合并了 Java RMI 和 CORBA 的最佳特性。 使用 RMIIIOP，可以不用學(xué)習(xí) CORBA IDL，就能夠編寫(xiě) Java 平臺(tái)下的 CORBA應(yīng)用程序。 RMIIIOP 允許開(kāi)發(fā)者在純 Java 編程環(huán)境中開(kāi)發(fā)，使用 Java 語(yǔ)言編寫(xiě)遠(yuǎn)程接口，然后使用 Java 和 Java RMI 的相對(duì)簡(jiǎn)單的 API 實(shí)現(xiàn)它。 RMIIIOP 還支持在應(yīng)用程序組件只見(jiàn)的按引用 (by reference)或按值 (by value)方式傳遞任何類(lèi)型的 Java 對(duì)象，這為分布式應(yīng)用程序的開(kāi)發(fā)帶來(lái)了極大的方便性。 RMIIIOP 使用 CORBA 命名 (CosNaming)服務(wù)定位遠(yuǎn)程對(duì)象，包括兩種命名服務(wù)，一種是臨時(shí)命名服務(wù) (通過(guò) tnameservv 工具提供 )，另一種是持久命名服務(wù) (通過(guò) orbd工具提供 )。使用 CosNaming 命名服務(wù)需要訪問(wèn) Java 的 Orb，所以注冊(cè)和查找服務(wù)器對(duì)象時(shí)， RMIIIOP 要比 RMI/JRMP 復(fù)雜一些。 RMIIIOP 適合那些使用 Java 語(yǔ)言并想通過(guò)編寫(xiě) RMI 接口而使用 IIOP 作為基礎(chǔ)傳輸協(xié)議的開(kāi)發(fā)者。 RMIIIOP 提供和其它用各種語(yǔ)言實(shí)現(xiàn)的 CORBA 對(duì)象之間的互操作性，這通常要求所有的遠(yuǎn)程接口最 初都是以 Java RMI 接口的形式定義的 (或者在一些很小的編程限制下直接編寫(xiě) IDL 接口文件 )。 RMIIIOP 對(duì)于 EJB 編程人員也有特別的吸引力，因?yàn)?EJB 組件的遠(yuǎn)程對(duì)象模型就是基于 Java RMI API 的。 [9] JavaIDL Java IDL 是 J2SE 平臺(tái)的一部分。 Java IDL 實(shí)際上是 Sun 公司的一個(gè) CORBA 實(shí)現(xiàn)，包含一個(gè) CORBA ORB，這個(gè) ORB 在所有的 J2SE 平臺(tái)的部署中都可以被使用。J2SE 以及 J2SE 平臺(tái)的 Java IDL 遵循 CORBA 規(guī)范。 Sun 的 Java IDL 技術(shù)目前不支持動(dòng)態(tài)調(diào)用接口 (DII)和接口倉(cāng)庫(kù) (IR)，也不直接支持動(dòng)態(tài)框架接口 (DSI)。 Java IDL 使用 CORBA 命名 (CosNaming)服務(wù)定位遠(yuǎn)程對(duì)象，包括兩種命名服務(wù)，一種是臨時(shí)命名服務(wù) (通過(guò) tnameserv 工具提供 )，另一種是持久命名服務(wù) (通過(guò) orbd 工具提供 )。要在 orbd 中注冊(cè)永久服務(wù)，需要使用 servertool 命令啟動(dòng)該服務(wù)器， servertool 是一個(gè)方便開(kāi)發(fā)者注冊(cè)、取消、啟動(dòng)和關(guān)閉永久服務(wù)的命令行程序。 Java IDL 使用 CORBA 命名 (CosNaming)服務(wù)定位遠(yuǎn)程對(duì)象。 如果企業(yè)中存在一些遺產(chǎn)系統(tǒng)或者有需要整合的系統(tǒng)，而且這些系統(tǒng)向開(kāi)發(fā)人員提供了一些 IDL 接口，那么應(yīng)該從 IDL 入手使用 Java IDL 技術(shù)進(jìn)行開(kāi)發(fā)。 [9] 框架技術(shù) 介紹 J2EE 雖然有著嚴(yán)謹(jǐn)?shù)恼w架構(gòu)、全方位的組件設(shè)計(jì)、優(yōu)秀的分布式平臺(tái)，但是 它 17 17 的 EJB 組件模型 卻 同時(shí)也 帶來(lái)了開(kāi)發(fā)、部署成本高、開(kāi)發(fā)者學(xué)習(xí)曲線陡峭等限制 ，使得小型企業(yè)很難在實(shí)際應(yīng)用中使用 。 但是，近幾年出現(xiàn)的“輕量級(jí) J2EE”應(yīng)用，使得 J2EE 平臺(tái) 更廣泛 的延伸到了各個(gè) 應(yīng)用領(lǐng)域。 “輕量級(jí) J2EE”模仿了 J2EE 的架構(gòu)，在保留了 J2EE 可擴(kuò)展性、可維護(hù)性等優(yōu)點(diǎn)的同時(shí)，它提供了更高效的開(kāi)發(fā)平臺(tái)，降低了開(kāi)發(fā)成本，成為一種更實(shí)用的信息化平臺(tái)。 下面分別介紹組成 輕量級(jí) J2EE[18] [25]的框架技術(shù)。 IoC框架 IoC 是“ Inversion of Control”的縮寫(xiě)，中文翻譯為“控制反轉(zhuǎn)” 或者“依賴(lài)注入” 。IoC 其實(shí)是工廠模式 [16]的特例， IoC 容器就是一個(gè)總工廠的實(shí)現(xiàn)。 系統(tǒng) 一但 引入實(shí)現(xiàn)了 IoC 模式的容器，就可以它用來(lái)管理對(duì)象的生命周期、依賴(lài)關(guān)系等，從而使得應(yīng)用程序的配置和依賴(lài)性規(guī)范與實(shí)際的應(yīng)用程序代碼分開(kāi) ，提高了系統(tǒng)的可 重用性及 可 維護(hù)性 ，并降低了代碼的耦合程度 。 目前比較 具有代表性的 “輕量級(jí)” IoC 框架 有： Spring[25]、 HiveMind、 Pico Container。 SpringIoC 是一個(gè)開(kāi)源的 IoC 框架 ， 使用基本的 JavaBeans 來(lái)管理對(duì)象 ，相比 EJB容器具有簡(jiǎn)單、可測(cè)試性、松耦合性等特點(diǎn) 。 SpringIoC 是由 Rod Johnson 創(chuàng)建的 Spring Framework 的一個(gè)組成部分。 AOP框架 AOP 是“ Aspect Oriented Programming”的縮寫(xiě)，中文翻譯為“面向方 /切 面編程” 。AOP 其實(shí) 是代理模式 [16]的一種應(yīng)用， 它 可以通過(guò)預(yù)編譯方式和運(yùn)行期動(dòng)態(tài)代理實(shí)現(xiàn)在不修改源代碼的情況下給程序動(dòng)態(tài)統(tǒng)一添加功能的一種技術(shù) ，它實(shí)現(xiàn)了調(diào)用者和被調(diào)用者之間的解耦 。 AOP 使得我們可以從一個(gè)更高的抽象概念來(lái)理解系統(tǒng)，這對(duì)于大型系統(tǒng)的開(kāi)發(fā)非常有意義。 使用 AOP 可以提高系統(tǒng)的可重用性及可維護(hù)性。 目前比較 具有代表性的 AOP 實(shí)現(xiàn)有： AspectJ、 Spring。 AspectJ 創(chuàng)建于 Xerox PARC，有近十年的歷史，比較成熟，但是它最大的缺點(diǎn)是過(guò)于復(fù)雜，需要有專(zhuān)門(mén)的 Java 編譯器。 SpringAOP 是基于字節(jié)碼 技術(shù)和 Java 動(dòng)態(tài)代理技術(shù)實(shí)現(xiàn)的 AOP 框架，比 AspectJ簡(jiǎn)單易用，是 Spring Framework 的一個(gè)組成部分。 MVC框架 MVC 是 “ ModelViewController” 的縮寫(xiě)，中文翻譯為 模式 視圖 控制器 ，即把一個(gè)應(yīng)用的輸入、處理、輸出流程按照 Model、 View、 Controller 的方式進(jìn)行分離，這樣一個(gè)應(yīng)用被分成三個(gè)層 —— 模型層、視圖層、控制層。 視圖 (View)： 代表用戶(hù)交互界面，對(duì)于 Web 應(yīng)用來(lái)說(shuō)， 最常見(jiàn)的是 HTML 界面，但有可能為 XHTML、 XML、 Applet 等其他 視圖 形式 。 模型 (Model)： 就是業(yè)務(wù)流程 、 狀態(tài)的處理以及業(yè)務(wù)規(guī)則的制