基于药具发放管理服务信息平台技术解决方案

闫居先

（天津市计划生育药具管理中心，天津 300070）

随着移动互联网的迅速发展与普及，信息化在计生药具发放管理服务中发挥着越来越重要的作用。为实现计划生育药具调拨、发放、储存、质量、统计、宣传等各项业务工作相关数据的整合和统一管理，完善计划生育药具发放网络和发放模式，进一步提高药具优质服务水平，基于药具发放管理服务功能需求分析，开发设计了药具发放管理服务信息平台。本文主要从软件基础架构和应用服务器架构方面简述了计划生育药具发放管理服务平台架构搭建，提出计划生育药具发放管理服务平台技术解决方案。

1 平台概述

计划生育药具发放管理服务平台由药具发放设备管理系统、药具免费发放服务网站、药具免费发放微信公众服务系统、药具语音咨询服务热线管理系统、药具管理网络办公系统、药具购调存业务管理信息系统、药具仓储环境远程监管平台7个子系统组成，各系统按业务管理和发放服务需要设计功能模块。

1.1 药具发放设备管理系统

该系统是各类药具发放终端发放药具及相关统计、查询、管理和考核的专用系统。主要功能模块为用户管理、发放管理、统计管理、查询管理、报表管理、考核管理等。

1.2 药具免费发放服务网站

该网站是药具宣传咨询服务管理的专属网站，设服务、公告、咨询、视频4个中心和求助专线，主要栏目包括药具品种、发放网点、发放渠道、两性知识、健康专栏、视教频道等，设计订单查询跟踪系统和紧急避孕援助专线。

1.3 药具免费发放微信公众服务系统

微信公众平台设计品种介绍、小贴士、近期活动、两性健康、微视频信息等信息栏目。物流查询栏目设计发放药具功能。

1.4 药具语音咨询服务热线管理系统

该系统主要由自动语音应答、人工座席和数据库三部分组成。自动语音应答代替人工自动接听用户电话。人工座席主要是为了在自动语音应答系统无法解决用户问题的情况下，向用户提供人工服务。数据库系统主要用于保存用户基本信息、服务请求信息以及政府部门的业务相关信息。

1.5 药具管理网络办公系统

实现市区两级药具管理服务机构网络办公和全流程工作管理。功能模块设计主要有网络办公系统、信息中心、基础工作、网点信息、财务管理、计划统计、质量管理、库房信息等。

1.6 药具购调存业务管理信息系统

管理市区两级药具购进、存储、调拨环节业务。功能模块包括系统管理、收款管理、计划管理、药具管理账表、入库管理、数据查询、出库管理、业务监管、在库管理、报表管理、付款管理、数据字典等。

1.7 药具仓储环境远程监管平台

管理市区两级药具库房的温湿度，由测点终端、管理主机、不间断电源以及相关软件等组成。各测点终端对周边环境温湿度进行数据的实时采集、传送和报警；管理主机对各测点终端监测的数据进行收集、处理和记录。

2 平台开发架构

计划生育药具发放管理服务平台架构如图1所示。

图1 计划生育药具发放管理服务平台架构Fig.1 Framework of management platform for family planning drug delivery

3 软件基础架构

3.1 从功能角度划分

3.1.1 数据中心

数据中心用来存储药具领取人个人信息、药具信息、工作文档、通知、工作信息等，还存储发放单位组织机构信息、组织人员信息等数据，是整个平台的基础。

3.1.2 计划生育药具发放管理服务平台核心功能

该系统需要实现系统管理、权限管理、安全管理、用户管理、机构管理、人员管理、工作流管理、资讯、公告管理、系统对接管理、消息管理等。

3.1.3 各类数据接口

平台提供与各相关业务系统的数据接口，以便进行数据整合、信息发布。目前提供与网站、微信公众账号、语音服务热线（呼叫中心）、自助发放机、药具购调存系统等均采用数据接口进行数据交互。

3.1.4 WebService及XML数据服务

对于一个完善的平台来说，提供的扩展性接口以及数据服务都是必不可少的。平台间的数据交换就涉及一个跨平台的问题。从J2EE平台到.net平台是一种典型的跨平台数据交换，WebService就是解决目前跨平台数据交换最常用的方案[1-3]。

3.2 从系统架构角度划分

3.2.1 业务数据层

业务数据层完成数据存储的功能。药具领取人个人信息、发放药具信息、工作文档、通知、工作信息、发放单位组织机构信息、组织人员信息等数据，均存放在该层中。

3.2.2 应用服务层

应用服务层是整个平台业务处理的核心部分，基于J2EE标准建设，工作流管理、资讯、公告管理、支付管理等，都采用J2EE业务组件实现。

3.2.3 访问服务

访问服务可以支持基于Internet的浏览服务，基于Wireless的移动访问服务，通过联通或电信网关的短信服务。

3.2.4 浏览用户

支持最终用户使用浏览器、移动设备、微信进行访问。

4 应用服务器架构

多层结构的系统多采用瘦客户/胖服务器的架构，即业务逻辑放在服务器端，而客户机仅处理信息的输入、结果的显示和业务流程的控制。系统设计成多层结构，不仅扩展性好，而且可维护性也较好。

4.1 MTEAF架构概述

多层企业级应用框架MTEAF（multi tier enterprise application framework）是基于MVC[4]设计思想的系统框架。本框架和业务逻辑完全无关，目的是使得开发者在建设基于J2EE标准的多层结构系统时，能够在已经预先部署好的框架中进行设计与开发。MTEAF在系统的整体架构上已经做了细致的分层，在严格保证架构统一性的同时，又给业务逻辑的具体实现方式留出了足够的灵活性。对于设计者来说，只需要关注于业务逻辑的合理划分与如何封装；对于开发者来说，只需要关心某个具体功能的代码如何编写，对于框架的工作过程，开发人员无须掌握每个细节。

4.2 MTEAF架构结构

以B/S结构的JSP/Servlet[5]作前端的表现层开发，系统的客户端只需要1个浏览器即可。通过浏览器完成前台业务的相关操作。系统架构也充分考虑到了系统的安全性、可靠性和健壮性。通过设置系统日志，自动记录全部操作过程；通过完整的权限管理机制，将权限按系统级、数据库级和业务级划分到每个角色（包括操作员和系统维护人员），使之在严格规定的权限范围内工作。在大多数B/S结构的Web应用中，浏览器直接通过HTML或者JSP的形式与用户交互，响应用户的请求。虽然很直观，但当遇到大批量数据应用时，随着代码的增多会使JSP页面臃肿不堪，Web服务器的负荷过重。MTEAF框架采用多层结构设计，可使数据层与表示层分离，并且设计充分考虑降低层与层间的耦合[5]。

总之，应用系统架构在系统易用性、扩展性、可维护性、重用性、可靠性、安全性等方面都进行了充分的考虑。这是一种兼顾开发效率和运行效率，同时满足分布式事件处理功能的系统架构。在MVC设计模式的实现中，视图采用浏览器上显示的页面。这种设计具有B/S/S结构的客户端零维护的优势[6]。

4.3 MTEAF运行调用模型

在控制层的设计中分成两个部分：系统调用流程控制和系统服务。

将核心的业务做成组件的形式，使业务层得到最大限度的重用。并且在组件的数据交互接口不变的前提下，如果业务逻辑发生变化则只需要修改组件内部逻辑，不用修改系统的其他部分即可。实现了层次间的松耦合，实现了业务逻辑的封装。

调用模型的设计主要采用了层次化的设计思想，主要应用了MVC的设计模式。系统横向以MVC模式分层。总体调用层次分为4个大的横向调用层次：客户端层（view）→服务器框架（controller）→业务组件（model）→数据库（model）。MTEAF调用模型如图2所示，体现了系统的架构模式、调用顺序、调用层次，使用的技术及如何分布等一系列重要问题。客户端采用浏览器为解决方案，通过JSP及taglib来实现客户端的显示。

4.4 MTEAF各层次说明

图2 系统运行调用模型Fig.2 Call model of system operation

应用服务器端分成Web控制层、业务委派层、商业逻辑层、持久层。在商业逻辑层采用EJB。将核心的业务做成组件的形式，使业务层得到最大限度的重用。并且在组件的数据交互接口不变的前提下，如果业务逻辑发生变化则只需要修改组件内部逻辑，不用修改系统的其他部分即可。实现了层次间的松耦合，实现了业务逻辑的封装。

4.4.1 表示层

表示层即用户操作界面，在本系统中，用户只需要使用浏览器就可以满足业务的需要。除此之外，对于一些常用的信息浏览，系统提供XML数据接口，可以通过RSS浏览器等工具进行浏览。

4.4.2 Web控制层

Web控制层是整个应用系统的中间层，是应用客户端和业务逻辑层之间的中介。由于Web控制层在整个应用结构上所占据的位置，所以在应用系统的架构设计上也具有很重要的意义，也是系统架构设计第一个需要解决的问题。

Web控制层作为整个应用系统的中间层，同时需要为整个应用系统进行会话管理、身份验证、授权验证等管理控制任务。Web控制层作为客户端请求的入口，根据整个框架、尤其是业务逻辑层的要求对请求进行预处理，负责把业务请求传递到业务逻辑层进行处理，同时把业务逻辑层的处理结果作为响应发回给客户端，在客户端业务请求与业务逻辑层业务处理之间起到了协调控制的作用。

Web控制层的主体是由一组 Filter/Servlet[7]构成的，它们同时依靠一些支持类库和工具类库来正常运行。Web控制层主要由最前端的HeadFilter、SaftyFilter、MainServlet组 成 的 过 滤 器 链 （Filter Chain）。

Web控制层需要截获请求，首先由HeadFilter对请求消息进行解析、重组后（主要为了验证请求是否符合通用规则）转发请求到SaftyFilter，在这里进行用户身份验证、用户授权和用户会话的控制管理，最后客户请求将发送到MainServlet主控器，MainServlet根据后端业务派遣层和业务逻辑层的要求封装业务请求并提交业务处理请求，业务派遣层最终把业务请求传递到业务逻辑层进行处理，同时把业务逻辑层的处理结果封装后发回MainServlet，控制权重新回到Web控制层。MainServlet将请求转发至 ViewDispatchServlet，ViewDispatchServlet根据本次请求的 FunctionID和表现层 Web页面的对应关系，将请求转发到相应的页面显示给用户。处理结果通过在Request上绑定EventResponse进行传递。

4.4.3 业务委派层

业务委派层作为Web控制层与企业应用层之间的代理，从Web控制层接收业务处理请求，然后转交给企业应用层进行实际处理，把企业应用层的业务处理结果发回Web应用层。

业务委派层采用Command设计模式来处理业务请求的分发派遣。

业务委派层由业务处理请求控制器（Request Processor）统一接收Web控制层提交的业务处理请求，业务处理请求控制器进行业务处理请求的封装，从业务请求中截取对应业务处理行为类信息（具体Action子类），并且通过动态实例化获得类型为Action的具体业务处理行为实例。采用Command模式设计的BaseAction以及其子类来完成业务处理请求的派遣。通过BaseAction接口对业务请求处理的一致抽象，RequestProcessor不需知道业务请求派遣的具体实现细节，利用多态性，业务处理请求会准确传递到具体BussinessAction，并进一步传入业务逻辑层，最终由数据访问DAO协同执行业务处理。

4.4.4 业务逻辑层

业务逻辑层实现了所有的业务逻辑处理。

BussinessAction层的设计使用的是业务代表（Business Delegate）的设计模式，BussinessAction的作用是向表示层提供客户需要访问业务服务。

使用BussinessAction作为业务代表的好处是可以降低表示层客户端和业务服务层的耦合，业务代表隐藏了业务服务的实现细节，提供更简单的、统一的接口更好的向客户端提供服务。业务逻辑最终通过BussinessAction调用DAO实现，DAO通过更底层的DBUtil和DBTransUtil实现对数据库的操作。

4.4.5 持久层

根据J2EE设计模式、DAO（data access object）模式、VO（value object）模式、以及ORM（O/R mapping）模式，构建核心平台的持久层。

持久层是数据访问对象DAO。持久层是位于数据层之上的一层结构，它将所有数据连接逻辑封装到数据访问对象中，隐藏访问数据源的API。使在系统架构上建立的应用程序不了解数据所在的数据库平台。使应用程序与其使用和操纵的数据源分离。建立持久层的目的是分开数据持久逻辑与表示和业务逻辑的整洁机制。业务层与数据库的交互是通过为数据访问对象提供的统一接口和辅助实现类DAO来实现的，取代了使用JDBC之类的数据访问API访问数据库。

DAO模式和VO模式完全分离业务应用程序的开发人员与其在应用程序中使用的数据源，不需要知道数据访问的API，而是用统一的接口来完成对数据库表的插入、删除、更新、查询等数据操纵功能。

4.4.6 系统运转纽带

FunctionID是用来区分客户端不同请求的标示。每一个需要进行业务处理的请求，都必须为其定义一个唯一的FunctionID。系统的运行依托于和FunctionID相关的2个重要的对应关系。

FunctionID和BussinessAction的对应关系：每一个FunctionID都必须有一个BussinessAction相对应。业务委派层中的RequestProcessor通过这种对应关系，找到和请求相对应的BussinessAction，调用BussinessAction.perform （Event），进行相关业务处理，从而实现业务的分发。此对应关系可以通过xml文件进行定义，也可以保存在数据库中。在进行业务逻辑部分编程的时候，需要对该对应关系进行提前设计和定义。在MainServlet进行初始化的时候进行加载，保存在ServletContext上，供全局调用。

FunctionID和ViewSuccess的对应关系：每一个FunctionID都必须对应一组ViewSuccess（实质上是一组jsp页面）。一个业务逻辑处理完毕后，控制权将重新交给MainServlet，MainServlet并不能直接显示用户界面，而是将控制权转给 ViewDispatch-Servlet，ViewDispatchServlet根 据 FunctionID 和ViewSuccess的对应关系，将请求转发到相应的页面。业务处理的结果通过将ResponseEvent绑定在request上传递到JSP页面进行显示。一般来说，每个FunctionID根据处理结果是成功、失败、错误3种情况分别对应3个JSP页面。此对应关系可以通过xml文件进行定义，也可以保存在数据库中。进行业务逻辑部分编程的时候，需要根据客户端页面的开发情况，对该对应关系进行定义。在ViewDispatchServlet进行初始化的时候，加载该对应关系，保存在ServletContext上，供全局调用。

FunctionID和两个对应关系是本系统架构中非常重要的概念，是系统运行贯穿始终的纽带。

5 结语

上述多个层面的应用系统和相

关技术再结合的解决方案，特别是在移动媒体上开创性设计的微信发放药具功能系统紧跟当今最新潮流，将计划生育药具发放管理和发放服务的所有业务领域和各环节均纳入到信息化平台中，采用最新软件开发技术路线，应用ORACLE数据库，JAVA开发语言，确保了系统的安全性、稳定性和可扩展性。

[1] CayS.Horstmann.JAVA核心技术卷II：高级特性[M].陈昊鹏，等译.8版.北京：机械工业出版社，2008.

[2] Michael Blaha，James Rumbaugh.UML面向对象建模与设计[M].车皓阳，杨眉，译.2版.北京：人民邮电出版社，2006.

[3] Steven John Metsker，William C.Wake.Java设计模式[M].2版.北京：电子工业出版，2012.

[4] 孙卫琴.精通Struts：基于MVC的Java Web设计与开发[M].北京：电子工业出版社，2004.

[5] 刘晓华，周慧贞.JSP应用开发详解[M].北京：电子工业出版社，2007.

[6] 布吕格，迪图瓦.面向对象软件工程：使用UML、模式与Java[M].叶俊民，汪望珠，等译.3版.北京：清华大学出版社，2007.

[7] 昊斯特曼.Java核心技术：卷Ⅰ基础知识[M].叶乃文，邝劲筠，杜永萍，译.8版.北京：机械工业出版社，2008.