基于J2EE的煤礦企業模塊化業務開發平臺應用研究

尹天明

(中國中煤能源集團公司，北京 100120)

隨著信息化的快速發展和煤炭企業集團運營管理方式的轉型升級，信息技術在支撐企業開展日常經營管理起到了越來越重要的作用，同時也面臨新的挑戰和機遇，一是煤炭企業發展的規模化和企業業態的多樣化，使得信息系統開發規模和難度越來越大，業務需求越來越雜，系統運行的風險系數也越來越高，管理和運維信息系統的成本也越來越高，二是信息化技術發展快，系統間適配要求高，數據交互頻繁，隨系統需求變化而進行的動態開發和運維難度增大。因此，有必要對現有的應用系統開發架構和流程[1]進行改造和升級[2]，以適應煤炭企業實際業務需要和開發需要?；谙冗M成熟的信息技術，運用模塊化開發理念，重新設計和調整應用系統基礎開發平臺，對應用功能和架構進行重組整合，建立新的、實現敏捷開發的企業級模塊化開發平臺，實現快速精益實施和部署，降低開發成本和實現復雜度，以更小的代價，快速響應企業業務需求變化的需求。

J2EE是一套技術規范，它包含的組件、服務、工具都遵循共同的標準。而本文采用基于J2EE架構進行模塊化平臺設計，可以借助部分成熟套件，提高對異構平臺的支撐，增強系統可伸縮性，同時利用遵循J2EE架構所提供的通用的、封裝的服務器端功能，可以讓模塊化平臺設計和開發人員更多的關注創建業務邏輯，縮短開發時間。

1 平臺架構

構建一套基于J2EE架構規范的模塊化部署和實施的業務開發平臺[3-5]，實現煤炭生產業務需求的快速落地和迭代，解決企業信息化建設過程中存在的諸如開發慢、維護難、標準不統一等一系列問題?；谏鲜觯P者提出的模塊化業務平臺總體架構如圖1所示。

圖1 總體架構圖

模塊化業務平臺總體架構由三部分組成：基于Eclipse的插件開發、框架工具、基礎模塊實現共計三個部分，各部分主要功能包括：

1.1 基于Eclipse的插件開發

在Eclipse基礎上主要進行功能插件的二次開發，開發的內容主要包括可視化建模工具、代碼生成器、發布器、部署器、數據遷移器等，封裝成各類”微服務”。整個Eclipse插件開發不僅僅依賴于具體項目，而是貫穿了整個軟件研發生命周期。該平臺主要內容包括：

1)可視化設計器：開發人員利用可視化設計器來將通用和專有業務封裝成實體，實體負責與數據庫表的對應和從頁面到數據庫表的邏輯實現，同時也包括操作的功能單元、權限等功能封裝。

2)代碼生成：開發人員生成代碼時，各代碼目錄同步生成，目錄中的包和子包按照代碼規范也會同步生成。代碼生成時候，為避免因需求變動反復修改實體，設計中將抽象類和具體類進行了分離。

1.2 框架工具

此部分內容融合了市場上主流的、基于Java EE技術的開源框架內容，包括數據遷移器、輔助開發工具等主流開發技術工具，使任何一個開發團隊可利用成熟的技術體系和工具實現代碼的快速開發和應用，同時，在這一部分引入開發規范、代碼規則、版本管理等內容，通過平臺保障團隊所交付產品的代碼質量。此外，還提供了多參數數據源、頁面校驗、單元測試、通用API、緩存等多種輔助開發手段，省去研發工程師大量的開發時間，避免重復設計和開發。

1.3 基礎模塊

此部分內容實現了通用基礎模塊內容，包括用戶管理、組織機構管理、權限管理、菜單管理、日志管理等內容，滿足通用情況下項目建設的基本需求；平臺設計了具備鏈式授權功能的PrivilegeProcessor接口和方法，開發者可結合煤礦企業特點、甚至于其他行業特點來自定義用戶權限范圍。

整個業務平臺采用面向對象的設計方法和MVC模式，通過可視化建模工具對各個模塊進行業務建模，每個模塊都將是一個獨立可運行的B/S架構應用程序(Web工程)，可以獨立部署到Java Web容器中，技術架構如圖2所示。

圖2 技術架構

模塊化業務平臺采用的技術框架是遵循J2EE架構的，組合方案為：Spring+Papilio UI+MyBatis3。其中，MyBatis3：在本平臺上主要實現數據的持久化。它支持定制化的 SQL語句、支持存儲過程等對數據庫的基本操作，從而避免了大多數的JDBC 代碼開發和手動設置數據庫參數過程。該平臺數據持久層主要包括三個方面內容：一是數據庫腳本文件，針對不同的數據庫配置不同的腳本文件，二是數據庫類文件，三是ORM配置文件，實現不同類型系統之間的數據轉換。

從總的路線上看，平臺充分發揮了Spring IOC與AOP功能，實現業務層兩端的無縫集成，同時針對煤礦具體業務提供一套結合煤礦實際、調用友好的抽象層，抽象出班組管理、巷道、開拓等煤礦具體業務并進行封裝，除封裝和集成外，還提供了一套客戶可配置的通用性強的API，供上層開發者調用，使平臺具備針對其他行業實現業務的封裝和集成的功能。

綜上所述，平臺技術架構從縱向和橫向看，業務模塊之間都是松耦合關系，各模塊和層級之間通過對應的訪問方式建立異步通信機制，單個模塊的調整和修改不會影響其他模塊的正常使用和通信，這種松耦合關系也是保證模塊化可拔插特性的關鍵。

業務模塊與基礎模塊之間采用直接的接口依賴關系(在Java架構中，這種依賴關系主要表現為Jar包依賴以及接口調用)，即：基礎通用模塊提供業務通用模塊所需的接口方法API并供其調用，而且，業務模塊不能直接調用基礎模塊的service方法，只能通過基礎模塊提供的接口類來訪問其中的數據，這樣就保證了基礎模塊的相對獨立性。

2 關鍵技術

2.1 模塊化

在大中型信息化項目中，由于涉及到多組織、多業務、多平臺等一系列涉及團隊協作的問題以及需求復雜度和適應性的要求，需要在前期就要對系統模塊進行詳細梳理和劃分，對應用系統和業務需求進行模塊化設計。軟件模塊化的主要目的是為了建立能復用且具備事務特性的軟件組件和服務，可以在幾乎不需要修改的情況下，通過模塊的配置、部署和調用再次用來組建新的應用系統，提高軟件的開發周期和可靠性，降低開發成本和運維成本。模塊化是本平臺設計核心，其特性主要包括模塊的可插拔、模塊之間的異步通信、模塊顆粒度劃分、模塊間引用關系等[7-9]。

2.1.1 可插拔模塊

模塊的可插拔主要解決兩個問題：

1)模塊的發布。在開發平臺中發布應用要包含兩個部分信息：應用基礎信息和配置應用信息，應用基礎信息主要包括項目版本、名稱及簡介等，配置應用要告知平臺模塊的部署方式，主要包括數據庫腳本、工程配置XML文件，編譯好的JAR包，工程包等內容，以上內容準備好后，即可通過平臺生成項目發布文件。

2)模塊部署。將項目發布文件導入平臺部署，系統首先會對發布文件進行驗證，驗證通過則可部署到項目文件，否則報錯直至修改通過。

2.1.2 模塊之間的異步通信

模塊與模塊之間要有建立良好的異步通信功能。例如，設備業務系統應該在“設備管理”模塊中，但“生產管理”應該可以調用“設備管理”中的設備信息，從而控制設備的啟停與運轉情況。如果一個項目只要求有“生產管理”不要‘設備管理’，“生產管理”中就不能體現出所“設備”相關的所有信息，基本實現原理如圖3所示。

圖3 模塊間異步通信

在本業務平臺上實現了從如下幾個方面進行控制：

1)在頁面管理上，生產管理中不顯示與設備相關的鏈接、按鈕或菜單。

2)在代碼設計上，當點擊生產管理中的某個按鈕或鏈接時，如果這事件需調用相關設備信息，那么要確保發出調用申請并保證程序正常向后執行。

3)在數據庫表結構上，理論上一個業務系統沒有指定的模塊，那么就不應該提供這個模塊下的頁面、代碼、數據庫表，而一些表是一定是有跨模塊之間的外引用(即數據庫外鍵，一個表中的字段是另一個表的主鍵)的。因此要盡力降低數據庫表外引用的同時，確保有這種外引用也能正常運行。

4)在用戶權限上，基礎通用模塊內借鑒微服務的思想，細化權限粒度，保證模塊內權限的分配，更要保證模塊間權限的管理和分配。

2.1.3 模塊顆粒度適度

所謂模塊顆粒度就是一個模塊所提供的功能點的多寡[5]。例如，是否“生產管理”作為一個模塊還是把生產管理下的“生產成本”作為一個模塊。模塊的粒度越小，系統就越靈活而開發工作量，技術難度與部署難度就越大，反之系統就越僵硬(不利于擴展與維護)而開發工作量，技術難度與部署難度就越小。本平臺在模塊顆粒度劃分的基本原則為：

1)基于業務的層層梳理和功能分解，模塊的顆粒度是由業務本身行為所決定的，是原子型的不可分割的業務行為。

2)綜合平衡業務、軟硬件資源、異構系統交互等條件，確定最后模塊顆粒度。

由于模塊顆粒度問題的復雜性，考慮設計可量化的模塊顆粒度優化模型，期望能在模塊顆粒度設計層面實現資源分配的總體平衡。

2.2 代碼覆蓋

經初步測算，利用本平臺開發項目中近80%的代碼是自動生成的，為保持邏輯一致性，代碼生成器會反復生成并覆蓋部分類和文件，造成開發者手動改寫或添加的代碼被覆蓋掉，經分析，生成器生成的文件從類型上看主要有兩大類：①與實體屬性密切相關的類或者配置文件，因為只要實體中的屬性名稱或量發生變化，生成器就要適應實體屬性的變化；②與整個服務相關的配置文件，因為一個服務下會有多個實體，生成器的目的是要適應服務下實體數據庫的增減。

總體而言，涉及工程整體性配置的內容原則上不能修改，如ORM框架配置，分頁信息配置，安全信息配置，緩存容器配置，部署配置等，這些要求會在代碼規范中說明.涉及代碼修改的，為避免代碼覆蓋，筆者提出的解決方案包括：

1)修改模型。如果要對模型類實現某個接口或方法，可改寫模型包下的具體類，該類只會生成一次，不能修改模型包下抽象中的內容，因為抽象類會被重新生成。

2)按照調整內容，可分別修改表現層、業務層、權限配置文件?；具^程是在新建一個配置文件，在配置文件中修改或增加action，然后再對應的XML文件中引入該配置文件，使得該action會被優先調用。以修改表現層xwork-test.xml配置文件為例，操作應該是：①新建一個xwork-test-customer.xml配置文件；②將要修改或要增加的actoin寫在該文件中(即使action名與xwork-test.xml只的action名重復也沒有關系，系統會以action為最高優先級)；③在xwork.xml文件中引入該配置文件注意一定要放在xwork-customer.xml引用的下面。

2.3 模塊初始化部署

由于運行每個業務模塊的容器(如Tomcat)的運行要占用相應的硬件資源(內存、硬盤空間，CPU時間等等)，所以一臺物理 Server 能運行的 Tomcat 是有限的。如果模塊過多，則建議相應增加 Server來緩解應用程序運行壓力。以部署A模塊為例，并且假設A模塊在 Eclipse項目的web路徑為：C：/workspace/cmim-A /web，整個部署過程[6]關鍵環節有：

2.3.1 配置容器目錄

部署方式如下：

1)配置XML文件。在${CATALINA_HOME}/conf/server.xml 中進行配置[10]，在該XML文件的標簽部分加入如下代碼：

2)修改XML參數。修改 ${CATALINA_HOME}/conf/web.xml中的對應代碼段，如果listings 參數的值為 false，則改為 true，目的是要啟用虛擬路徑。

2.3.2 容器群集配置

1)配置XML文件。在 ${CATALINA_HOME}/conf/server.xml 中找到如下代碼：

，添加集群代碼信息。

2)修改XML文件。修改 ${CATALINA_HOME}/conf/server.xml 中除了上述 ① 中的 port，以保證每個 Tomcat 的端口號不重復。

3)修改批處理文件。修改 ${CATALINA_HOME}/bin/ 下的 startup.bat 和 catalina.bat，在內容的最開始加入如下代碼：

CATALINA_HOME=C：/tomcat-cluster/tomcat-A

JAVA_HOME=C：/opt/jdk

JAVA_OPTS=“-Xms256M -Xmx512M -XX：PermSize=256m -XX：MaxPermSize=512m”

每個模塊的Tomcat 也應放在 tomcat-cluster 目錄中。

4)在每個模塊的部署描述符文件(web.xml)中添加： 標記。

3 結 語

項目組利用該平臺對中煤集團某特大型煤礦企業的生產管理系統進行了應用、開發和部署，共實施和部署了包括調度管理、設備管理、一通三防、班組管理等在內的十余個模塊，并對項目實施情況進行了2年的跟蹤和效果分析：

1)從經濟效益層面看，一是極大的加強了煤炭企業對生產的閉環管控，降低噸煤成本；輔助實現科學采掘接替，提高對生產設備點檢水平，月平均故障時間減少5h，按平均生產能力約1萬t/d，每噸煤300元計算，每年能夠增加營收750萬元，二是實現生產各類數據的多維度統計、分析和匯總，同時大幅減少用人崗位和人員工作強度，企業員工崗位比三定減少28人，每年直接人力成本節約300萬元，三是系統配置靈活、擴展性強，上線后，通過模塊化的業務配置模式，后期的業務增加和功能變更僅需單獨維護單個模塊即可實現，保證了系統其它模塊的穩定運行，系統運維成本平均降低20%，企業每年可節省運維費用近100萬元。

2)從社會效益層面看，該平臺除了應用于煤礦企業，還可以在電信、金融、醫療等各領域推廣使用，應用前景廣闊。業務基礎平臺采用模塊化結構，對業務流程進行重組，實現資源的集成和整合，可大幅提高工作效率，以適應不斷變化的需求，對企業信息化水平提高具有良好的推進作用。

后期，筆者將在復雜業務邏輯代碼生成、模塊顆粒度模型優化、軟硬件資源性能比等方面開展進一步的研究。