基于J2EE的煤矿企业模块化业务开发平台应用研究
2019-09-04尹天明
尹天明
(中国中煤能源集团公司，北京 100120)
随着信息化的快速发展和煤炭企业集团运营管理方式的转型升级，信息技术在支撑企业开展日常经营管理起到了越来越重要的作用，同时也面临新的挑战和机遇，一是煤炭企业发展的规模化和企业业态的多样化，使得信息系统开发规模和难度越来越大，业务需求越来越杂，系统运行的风险系数也越来越高，管理和运维信息系统的成本也越来越高，二是信息化技术发展快，系统间适配要求高，数据交互频繁，随系统需求变化而进行的动态开发和运维难度增大。因此，有必要对现有的应用系统开发架构和流程[1]进行改造和升级[2]，以适应煤炭企业实际业务需要和开发需要。基于先进成熟的信息技术，运用模块化开发理念，重新设计和调整应用系统基础开发平台，对应用功能和架构进行重组整合，建立新的、实现敏捷开发的企业级模块化开发平台，实现快速精益实施和部署，降低开发成本和实现复杂度，以更小的代价，快速响应企业业务需求变化的需求。
J2EE是一套技术规范，它包含的组件、服务、工具都遵循共同的标准。而本文采用基于J2EE架构进行模块化平台设计，可以借助部分成熟套件，提高对异构平台的支撑，增强系统可伸缩性，同时利用遵循J2EE架构所提供的通用的、封装的服务器端功能，可以让模块化平台设计和开发人员更多的关注创建业务逻辑，缩短开发时间。
1 平台架构
构建一套基于J2EE架构规范的模块化部署和实施的业务开发平台[3-5]，实现煤炭生产业务需求的快速落地和迭代，解决企业信息化建设过程中存在的诸如开发慢、维护难、标准不统一等一系列问题。基于上述，笔者提出的模块化业务平台总体架构如图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文件中引入该配置文件
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)从社会效益层面看，该平台除了应用于煤矿企业，还可以在电信、金融、医疗等各领域推广使用，应用前景广阔。业务基础平台采用模块化结构，对业务流程进行重组，实现资源的集成和整合，可大幅提高工作效率，以适应不断变化的需求，对企业信息化水平提高具有良好的推进作用。
后期，笔者将在复杂业务逻辑代码生成、模块颗粒度模型优化、软硬件资源性能比等方面开展进一步的研究。
