面向服务的水泥企业信息系统集成架构①

王少林, 田晨璐, 毛锡双, 魏仁政, 李 程



面向服务的水泥企业信息系统集成架构①

王少林1, 田晨璐1, 毛锡双2, 魏仁政1, 李 程1

1(山东建筑大学, 济南 250101)2(广西壮族自治区墙体材料改革办公室, 南宁530028)

为满足水泥企业流程重组与业务协同对企业信息系统的要求, 在充分考虑水泥企业的信息化现状的基础上, 综合利用混合云的优势, 以面向服务的方法构建了水泥企业信息系统应用集成架构, 设计了一种针对大型水泥企业的服务划分算法, 以移动服务和设备诊断检测服务为例详细阐述了服务实现的过程. 以该应用集成架构为基础构建了某水泥企业应用集成平台, 充分利用了云端资源及企业内部信息资源, 实现了该水泥企业信息系统的应用集成、共享及远程访问, 满足了该企业满足科学管理、流程优化、协同业务等信息化需求.

混合云; SOA; 水泥企业; 应用集成; 架构

水泥工业是国民经济的重要基础产业之一, 属于典型的流程型行业, 利用信息技术, 促进水泥行业的发展, 是两化融合的目标之一[1]. 在水泥企业生产计划中, 年度计划具有重要意义. 年度生产计划和销售计划, 决定了企业物料采购计划. 一般情况下, 企业按月份签订供货合同以及结算货款. 每周、每日生产计划的物料平衡依靠原材料库存来保证和调节[2]. 生产、采购、库存、销售等各环节相互配合完成水泥企业运营业务, 其运营业务流程如图1所示.

在水泥企业信息化过程中, 由于信息系统的引入缺少规划性, 每引入一个新的子系统就会新增相应的软硬件基础设施, 出现重复建设的问题, 系统资源利用率低且建设周期长. 系统与系统之间没有统一的接口标准, 信息孤岛现象广泛存在, 运维成本较高, 不利于水泥企业流程重组. 此外, 当前水泥企业均采用数据覆盖模式以实现海量数据的再存储, 这种模式导致数据资源的极大浪费.

针对目前水泥信息化现状, 为满足水泥企业面临的业务重组及应用集成需求, 部分研究人员针对水泥企业系统应用集成进行研究, 提出一些架构设计[2-4], 虽然一定程度上解决了异构系统的互操作问题, 但系统开放性与灵活性较差, 难以满足企业信息化的新需求. 杨阳[5]等人基于SOA方法进行系统集成设计, 并应用于水泥监控平台, 取得了良好的效果, 但并未考虑对数据资源的保护与云端资源的利用.

图1 水泥企业生产运营业务流程

1 SOA与混合云

SOA(Service-Oriented Architecture)即面向服务架构, 其思想表现是将信息系统的逻辑功能分解为更小的独立功能单元, 依据业务流程分析, 将相关功能进行聚合, 并通过标准技术, 将集合后的功能封装为独立存在的服务, 各服务相互配合, 实现用户需求的业务, 进而实现系统的体系化[6]. 在云计算的部署模式中公有云的计算能力强, 价格较低, 但是安全性差, 过多的依赖网络带宽; 私有云建设价格较高, 计算能力冗余少, 但安全性高; 社区云可充分利用区域内的计算能力, 但是现在仍处于探索阶段, 有很多技术问题需要解决; 混合云综合了私有云与公有云的优势, 以较少的资金投入获取足够的存储能力并保证数据安全[7].

SOA的优势在于应用集成与部署, 云计算的优势在于无限的存储与计算能力. 应用SOA方法, 充分利用混合云的优势, 对水泥企业信息系统应用集成架构进行设计, 满足企业流程重组与业务协同的需求, 实现水泥企业异构、分布式信息系统的应用集成和共享、数据资源的保护、集成平台的远程访问功能.

传统水泥企业中会存在多种遗留信息系统, 本文从业务驱动的角度自上而下进行平台开发, 集成企业各应用系统与云端资源, 基于混合云建立水泥企业公有云数据中心与私有数据中心, 有效集成并保护水泥生产及业务数据. 企业内部各个信息系统所需的功能逻辑实现模块以服务的形式按照标准进行封装, 服务之间通过简单、中立接口进行通讯, 针对云端Saas资源, 采用服务链接与调用API的模式进行集成, 水泥信息系统应用集成逻辑架构如图2所示.

图2 水泥信息系统应用集成逻辑架构

2 面向服务水泥企业应用集成架构

为确保集成平台建设的灵活性、可移植性, 适应企业业务变化与流程重组需求, 水泥企业应用集成架构采用数据资源与功能服务相分离、功能服务与业务应用相分离的思路, 其架构主要包含用户访问层、应用层、服务层、运维层、数据支撑层与基础设施层. 它们之间相互独立, 又紧密联系, 形成多层体系结构的特点, 其架构如图3所示.

图3 水泥企业应用集成平台架构

2.1 用户访问层

用户通过统一的登录界面进行访问, 获取权限内的功能应用. 统一登录功能的设计采用基于角色的授权方法[8], 并引入权限的继承与私有概念, 将管理理念渗透到统一登录平台中. 高权限的用户可全部或部分继承低权限用户的非私有权限, 用户的私有权限受到保护, 不允许继承. 此外, 用户访问层与用户进行直接交互, 界面风格需规范统一, 依据用户所关心的具体内容进行个性化设计, 为用户提供友好访问界面.

2.2 应用层

应用层由生产管理、财务管理、库存管理、质量管理、设备管理等的实现流程及框架组成, 流程采用高级语言定制的方式实现. 应用层接受访问层业务请求, 在服务运维层的辅助下, 与服务直接交互, 处理服务返回信息, 完成相关业务功能. 一个应用的实现一般需要调用服务层的一个粗粒度服务与多个细粒度服务. 应用层与服务层相分离, 保证了服务的独立性, 方便实现业务重组, 增强架构的灵活性.

2.3 服务层

服务层包括企业内部发布的服务和云端SaaS及其API. 水泥企业信息系统提供的服务一般有生产现场管理基服务、设备检测诊断服务、称重计量服务、质量检验服务、报表服务、用户管理与安全服务、能效分析基服务、办公管理服务等. 在未采用面向架构以前, 上述各个服务都是单独的子系统提供. 在某种程度上来说, 子系统之间存在信息间隙, 比如存在异构数据或同一数据由多个系统同时维护等问题. 这样会导致系统的可扩展性不足, 例如若需要在原有系统基础上新建应急指挥平台, 应急指挥平台需要全面、有效的生产现场运行状态、设备检验诊断等信息, 同时需要急修、调度、客服人员管理等多个业务系统相配合, 单纯依靠管理员登录不同的业务子系统, 操作相当复杂, 既降低工作效率, 又无法获取全面的信息资源. 服务层增强了系统的可扩展性与协同能力.

当水泥运营流程相对单一时, 可通过人工分析进行服务划分, 但是随着运营流程细化, 人工划分科学性与可靠性受到质疑. 服务粒度的粗细影响业务流程的柔性, 随着业务服务平均粒度增大, 流程的柔性度将先逐渐增长, 达到一定的程度后将逐渐下降[9]. 因此, 本文采用服务最小粒度化、分类再聚合的思路, 结合水泥企业业务流程分析进行服务划分.

定义1. 服务基础集SS(NM SF RU((NMi,&i),j) RD(((NMi,&i)),j) ID)

服务基础集是指所有单粒度服务集合, 所谓单粒度服务是指不可再分服务, 服务无中间结果, 服务内部无对等服务. 其中NM代表名字, SF代表提供服务的软件, RU代表上级服务关系, RD代表下级服务关系, ID代表服务标示. NM由一系列编号组成, 编号位数由服务等级决定, 服务编码由服务内容与服务提供软件决定, SF由一系列编号组成, 编号由服务所属部分, 及软件主业务决定; RU是与该服务相联系的上级服务, 包括服务名称NMi与关联度&i, 关联服务数量j, RD是与该服务相联系的下级服务, 包括服务名称NMi与关联度&i, 关联服务数量j; ID为服务标示, 表示服务类别, 通过服务标示显示是否为同一类可替换服务.

定义2. 业务流集BF(BSi(BSij))(i, j为自然数)

业务流集是指所有业务流的集合, 业务流用BSi(BSij)表示, BSij是组成业务流的具体业务, 业务在业务流中顺序存储.

定义3. 服务集SV(SVi(NM SF(sfi))ID(idi))

服务集是最终呈现在服务层的单粒度服务聚合后的服务的集合, 服务集中的服务用SVi(NM SF(sfi) ID(idi)), 聚合后的服务具有更强的独立性, NM代表名称, SF(sfi)代表提供服务的软件集, ID(idi)为服务标示, 表示聚合后服务内部基础服务的服务类别, 通过服务标示, 显示服务内部基础服务的可替换性.

以下是本文设计的大型水泥企业服务划分算法:

算法: 水泥服务划分算法

输入: BF,SS

输出: SV

方法:

服务基础集对象的RU、RD均置零

for each 业务流BSi属于BF

for BSi业务序列

业务序列匹配服务

if 服务匹配

扫描RU、RD,

if 已有服务关系, 则更新&i, 即&i加1

else 创建新的服务关系

end if

end if

end for

end for

for each Si属于SS

if Si.RU.j=0or1 and Si.RD.j=0or1

服务划分为A类服务

else

服务划分为B类服务, 表示服务为SVi

end if

end for

标记A中所有Si为unvisited

do

随机选取服务Si

标记Si为visited

Si为sv

repeat

将sv的上、下级服务与A中unvisited服务进行匹配

if 上级服务可匹配

将上级服务标记为visited

聚合服务为sv

end if

if 下级服务可匹配

下级服务标记为visited

聚合下级服务与sv替换原sv

end if

until sv无上下级匹配服务

输出sv为SVi

标记为C类服务

until 没有标记为unvisited的服务

通过算法, 得到细粒度的公共服务, 即B类服务, 以及粗粒度的专项服务, 即C类服务, B类服务与C类服务共同构成服务集SV, 某水泥厂服务层划分如图3服务层所示. 生产现场管理服务、设备检测诊断服务、质量检验服务等为基服务, 即B类公共服务, 频繁为外界提供服务. 生产管理服务、财务管理服务等为C类专项服务, 这类服务为粗粒度服务, 服务于某个业务部门.

2.4 运维层

运维层接受和响应用户访问层来的业务请求, 与服务提供层的服务进行信息交互, 是用户访问层与服务提供层的中介. 服务运维层进行平台与服务的管理运维, 为平台运行安全性与平稳性提供保障, 该层包括业务逻辑库、服务管理器、服务元信息库、服务目录、服务日志及服务配置文件等模块.

2.5 数据支撑层

数据支撑层维护和管理公共平台所有数据资源, 对不同来源、不同种类数据进行统一管理, 提供多种通用的数据访问接口, 为平台运行提供数据支撑. 通过调用服务提供层的相关数据处理服务进行数据清洗、转换、加载, 构建数据仓库, 为平台数据挖掘及相关决策分析提供基础.

水泥企业现有信息存储设备难以长时间存储巨大生产数据量, 现主要采用数据覆盖机制进行存储资源的节约, 因而导致数据资源的极大浪费. 企业建立公有云数据中心与企业私有数据中心, 将非敏感数据存入公有云数据中心, 敏感数据存入企业私有数据中心. 数据运维管理机制主要包括数据转换机制、数据交互机制、数据规约机制、数据查询机制、数据整合机制, 其中数据交互机制中的数据映射子机制, 主要通过目录映射与定期数据转存设置实现数据自动上传与更新, 保证数据安全的同时, 为企业节省开支[8].

2.6 基础设施层

基础设施层位于最底层, 是整个平台的基础与支撑, 提供开发、运行、使用的基础平台和用于数据传输的安全通道等, 为上层“建筑”提供基本支持. 基础设施层包括用户操作的计算机系统, 支持应用系统开发、运行的服务器系统和各类操作系统、各种存储设备(系统), 还包括数据备份、容灾、备灾等保障数据安全的设备设施.

3 水泥企业典型服务的实现

3.1 移动服务的设计与实现

随着移动终端设备的普及, 水泥企业逐渐产生了将现存信息系统中部分功能迁移到移动平台的需求. 在混合云环境下本文将移动服务WebService部署到公有云, 为水泥企业职工提供人事管理、信息发布、远程办公等服务,并注册到企业的UDDI服务注册中心.企业职工可以通过下载相应的智能手机客户端软件远程访问已发布的WebService, 实现相应的应用功能.

以信息发布服务为例, 查询发布信息的时序图如图所示. 企业职工通过智能手机APP登录之后, 选择信息查询服务, 选择具体日期, 点击查询按钮将查询请求通过WebService发送到Web服务器, 由相应的程序对请求进行解析, 然后查询相应的数据库, 将查询结果返回给手机APP显示到界面上. 移动终端利用webservice和web服务器通信, 无论是调用哪一种具体服务, 收到的数据都是xml形式, 因此移动终端只需编写一种解析程序就可以实现对异构数据的解析.

图4 查询发布信息时序图

本文中移动终端为Android平台, 获取WebService的方法是调用第三方类库kSOAP2. Android开发的具体的实现方法如下:

STEP1: 导入所需的jar文件;

STEP2: 实例化SoapObject对象;

STEP3: 设置调用接口方法参数, 本文中为日期参数;

STEP4: 设置SOAP请求信息;

STEP5: 注册Envelope;

STEP6: 构建传输对象, 生成WSDL;

STEP7: 调用WebService;

STEP8: 返回xml格式文件.

3.2 设备检测诊断服务的设计与实现

设备检测诊断服务包括以下几个子服务, 设备运行状态信息获取服务、设备状态评估服务、参数异常报警服务、故障诊断服务、设备故障报警信息服务、设备综合监测与评价结果服务. 通过设备运行信息获取服务获取各设备的运行状态信息, 设备状态评估服务主要获取经计算后的幅值域(峰值、均值、均方根等)与设备震动情况(实测值/初值), 为设备状态评估提供逻辑数据, 设备状态评估分为健康、亚健康、不健康、病态等; 参数异常服务无输入参数, 该服务主要针对水泥厂关键设备的关键状态进行监测, 并返回是否报警及报警信息; 故障诊断服务为故障诊断逻辑模块提供数据支持, 输出功率值、幅值域参数等, 返回各指标值; 设备故障报警信息服务提供某时间段的某设备或多个设备的报警信息; 设备综合监测与评价结果服务主要服务于设备管理层领导, 给出设备综合信息状况.

本服务中WebService是基于.NET平台开发实现. 在.net平台下, 新建一个WebService项目, 将相关功能逻辑分别封装入该Web服务的Web方法中, 并修改其默认XML命名空间, 保证其唯一性, 编译后, VisuaI Studio. NET 将自动生成相应的 WSDL 文件, 生成网站, 即创建完设备监测诊断Web服务. 本服务的webservice部署在企业内部IIS之上. 将该服务发布到IIS时, 需要创建虚拟目录指针指向该服务. 由于本系统中服务数量较多, 需要单独描述每个服务, 即在[WebMethod(Description ="对该服务的描述")]. Webservice中的设备检测诊断服务帮助界面如图5.

图5 设备检测诊断服务帮助界面

以煤磨设备运行状态信息查询服务为例说明服务方法的测试实现. 点击DRStatusInfo超链接, 出现图6所示画面, 输入煤磨ID值、时间, false, 点击调用, 即返回煤磨状态监测参数xml结果, 如图7所示, 包括设备名称(EQUIPMENT)、返回时间(TIME)及煤磨的状态监测参数, 其中煤磨状态监测参数之间以“/”隔离, 格式为“煤磨参数编码: 煤磨参数value”,当有应用程序调用该服务时, 需要按照此协议进行解析.

水泥集成平台构建过程中, 在服务注册中心查询到该服务, 添加引用, 创建设备监测诊断服务代理对象, 通过该服务代理对象调用设备信息查询服务方法.

4 实例分析

某水泥企业现有两条日产5000吨的熟料生产线, 每条熟料生产线均配有余热发电厂. 两条生产线的DCS系统分别由西门子和浙大中控提供, 两个发电厂的DCS系统分别由和利时和浙大中控提供. 此外, 磅房计量称重系统(计量熟量料的出库量和煤炭等原料的入库量), 能源管理系统, 及各个部门生产经营管理系统, 生产过程信息管理系统、生产原料管理系统是原有系统的遗留系统, 其服务器平台为J2EE. 报表系统、能耗信息管理系统为本次新增系统, 主要为实现该水泥企业生产过程与管理决策的管控一体化, 实现流程优化与业务重组. 本次所设计的面向服务的水泥企业应用集成架构, 采用了Ajax、WebService 、Cristal 报表等技术, 并将原有遗留子系统进行信息集成, 基于.net平台实现该企业的应用集成平台.

平台主要采用两种方式进行企业内部的信息系统应用集成. 一种主要针对信息集成, 将对原有数据库的逻辑操作封装为Web服务, 发布到IIS上, 生成服务目录, 其他应用有使用到相关数据库的数据时, 通过查询服务目录, 调用相关数据库操作服务, 实现数据的读取、录入、及相关运算; 另一种方式是针对遗留系统的升级或改造. 当构建web服务时, 引用遗留系统的.dll文件, 可直接使用.dll文件中的公有方法, .dll文件作为服务的构件, 可以实现功能的改进与再创造. 此外, 针对云端Saas, 建立云端服务的目录映射机制, 方便云服务集成.

所搭建水泥应用集成平台部分界面如图8、图9所示, 用户进入平台后, 即可选择所需服务. 该企业信息系统完成集成后, 业务的逻辑更加分明, 改善了业务流程, 降低了系统二次集成成本与开发难度, 减少了维护和管理集成系统工作量.

5 结语

本文在分析当前水泥企业生产经营业务流程及信息化现状的基础上, 综合利用SOA与混合云的优势, 应用面向服务方法进行水泥企业信息系统应用集成架构设计, 在该架构下, 具体逻辑业务由一系列相对独立、低耦合、可重用的服务实现. 以该架构为基础搭建了某水泥企业应用集成平台, 该平台实现了企业信息系统的集成、共享及远程访问, 适应于该企业集团化、规模化的快速发展, 满足科学管理、协同业务、流程优化等信息化需求, 取得了良好的效果.

1 董锴.水泥生产企业信息化战略研究.科技情报开发与经济, 2011,21(2):128–131.

2 仲琴,吴士亮,徐宏斌.水泥行业信息化需求特点分析及信息化参考架构设计研究.中国制造业信息化:学术版,2008, 37(5):17–20.

3 卢扬帆,王海东,李海亮,等.基于DCS/MES/ERP 集成系统在水泥企业的研究与应用.中国水泥,2013,(3):102–104.

4 胡苏楠.山东省散装水泥管理系统设计与开发[硕士学位论文].济南:山东大学,2011.

5 杨阳.基于SOA的系统集成方法及其在水泥生产监控中的应用[硕士学位论文].武汉:武汉理工大学,2013.

6 He W, Da XL. Integration of distributed enterprise applications: A survey. IEEE Trans. on Industrial Informatics, 2014, 10(1): 35–42.

7 Zou C, Deng H, Qiu Q. Design and implementation of hybrid cloud computing architecture based on cloud bus. 2013 IEEE Ninth International Conference on Mobile Ad-hoc and Sensor Networks(MSN). IEEE. 2013. 289–293.

8 彭友,鞠航,王延章.复杂时空约束条件下基于角色的转授权模型研究.大连理工大学学报,2013,3(3):462–468.

9 陈华,方丁,赵卫东.SOA中业务服务粒度与流程柔性的关系研究.计算机工程与应用,2009,45(27):7–10.

Service Oriented Integrated Architecture for Cement Enterprise Information Systems

WANG Shao-Lin1, TIAN Chen-Lu1, MAO Xi-Shuang2, WEI Ren-Zheng1, LI Cheng1

1(Shandong Jianzhu University, Jinan 250101, China)2(Guangxi Wall-Materials Reform Office, Nanning 530028, China)

There is a need for procedure reorganization and business collaboration in cement enterprises. Aiming at this demand, the current operating circumstances and informatization status are analyzed in this paper. Based on the analysis, we apply service oriented methods in the integration for the cement enterprise application with comprehensive utilization of the advantage of hybrid cloud. A service partition algorithm for cement enterprise is designed. In addition, mobile services and equipment diagnosing services are illustrated in details. We build a cement enterprise platform for application integration based on the architecture which makes full use of the cloud and enterprise resources. Integration and sharing of the applications are realized. The remote access to the platform is achieved. The platform satisfies enterprise scientific management, process optimization, and business collaboration needs.

hybrid cloud; SOA; cement enterprise; application integration; architecture

广西壮族自治区科技攻关项目(2060402)

2016-04-16;收到修改稿时间:2016-06-12

[10.15888/j.cnki.csa.005561]