企业平台(业务基础平台)的设计和应用

一、为什么需要企业平台
          虽然IT行业技术发展日新月异，但国内信息管理系统的开发模式，依然是在底层的技术基础平台上直接构建业务系统，从大型企业如电信行业的Boss系统到一般企业的人员管理系统，基本还是采用面向技术的开发模式：业务模块都由开发者贯穿始终去实现，理解用户的业务逻辑，并用计算机技术去实现，开发人员大部分的时间用在解决界面如何显示，数据库的连接与释放，用户业务流程如何用编码方式贯通等问题上，整个项目周期，花在获取用户需求，理解用户实际需要的时间太少，在实现用户需求的时间（编码阶段）又太长，而且在每个项目的生命周期内，这样的活动周而复始，每个项目都要花时间处理其他项目可能已经实现类似功能的代码，这种低层次的软件开发模式，已实现的业务逻辑无法重用，重复编码现象突出，业务组件无法重构，个人能力有效提升，使信息系统的开发、维护和扩展困难重重，导致项目成员疲惫，工期延误，而用户仍不满意。

          现今，业界已有诸如.Net、J2EE、SOA、ESB、BPEL等技术基础平台，提高了软件开发的性能与效率，但从技术基础平台到用户应用系统，为了能快速高效的实现用户需求，仍然需要预定义很多业务组件，开发人员在新项目中利用这些通用业务组件来实现用户的系统，设计良好的业务组件犹如黑箱系统，软件开发人员只需要业务组件的接口就能完成需要复杂编码才能完成的功能，极大的简化了编码工作，减少了调试错误的时间，整个系统的健壮性也得到了较大的提高。这些通用业务组件包括工作流引擎，规则引擎，报表系统，可视化的业务建模工具，可视化代码生成工具等，通过合理的规划与设计，形成了快速开发平台；在软件开发平台的基础上加入ESB，SOA，数据格式抽取及转换，业务流程的编制与编排，数据库系统，各种服务的在线监控等功能，形成了运行支撑平台。两个平台统称为业务基础软件平台，涵盖软件项目的详细设计－》编码－》测试－》部署－》运营的周期，并作为一个具有生产力的解决方案提供给用户使用。

                                   图1 传统项目开发和基于企业平台的项目开发


         综上所述，业务基础平台是指以业务为导向和驱动的、可快速构建应用软件的企业平台（开发模式的比较见图1）。业务基础软件平台包括快速开发平台、运营支撑平台两个部分。从技术角度分析，业务基础软件平台为复杂应用软件系统的开发提供了一个基本框架，并有与之相应的、方便易用的开发与维护管理工具。这个框架给出了一些复杂应用软件的通用业务组件和实现代码，利用这些通用组件来设计用户的业务功能，利用松耦合方式，用业务流程把各个业务功能串联起来，形成了完整的业务逻辑链，并用工作流引擎驱动业务流程。当业务流程发生了变化，只需要用建模器重新设计并部署，就能实现新的业务流程，加速了业务流程的重构。
        在业务基础软件平台之上进行项目开发，能降低复杂性，省去很多基础性的研发工作，从而缩短研发周期，缩减开发人员，减少项目支出成本，提高研发效率，很好的解决用户需求多变的场景，帮助企业提升信息化管理水平，有极大的社会价值和经济价值。



二、企业平台
          企业平台目前设想涵盖软件生命周期的详细设计编码测试部署运营。其中测试阶段,，特指支持流程测试，业务逻辑测试；API级别的单元测试由开发者自行完成。
             企业平台包括两个部分：快速开发平台和运行支撑平台，从软件生命周期来看，涵盖了详细设计-->编码-->测试-->部署-->运营等多个阶段。

            快速开发平台提供一个嵌入式工作流引擎，图形建模器以及向导工具，系统的可视化部分基于eclipse插件的方式实现，非可视化部分打包成jar包形式，并作为快速开发平台的底层库供项目开发人员使用，涵盖详细设计、编码和测试阶段。

1. 快速开发平台：
研究企业平台的结构分层、业务驱动、代码生成方法等问题。该平台由4个层次的工具包和支撑代码组成，围绕着工作流引擎而工作。

• A. 界面层：研究可对多个web界面元素进行拖拽、组合生成所见即所得的界面设计方法。Web界面采用Flex技术，利用插件技术生成xml文件，并在xml文件中的数据元素绑定相关的数据（绑定服务层提供的API），由FlashPlay在浏览器中解析并渲染界面，以活动作为业务逻辑边界并根据内聚合外松耦合的原则，设计人工活动的交互界面，该活动将由工作流引擎来驱动。
• B. 引擎层：研究工作流引擎和与之对应的流程建模器设计方法。建模器提供一个基于插件方式的图形设计业务流程方式，而工作流引擎则是把定义好的业务规则在合适的时机执行。工作流引擎是整个快速开发平台的核心，起到对象总线的作用，通过定义标准的数据和应用调用规范，并通过工作流建模器来实现用户的业务流程逻辑，实现外部接口职能，完成外部应用的集成。工作流引擎作为业务流程自动化和构建流程应用提供了基础平台，实现了流程逻辑与业务逻辑的分离，支持业务流程的分析和规范化定义以及业务单元的自动组装，降低了复杂流程应用的开发难度，提高了应用系统的管理效率，提供了基于活动级别的业务逻辑重用功能。
• C. 业务逻辑层：利用代码生成器生成的API，使用插件技术来实现API在界面的拖拽，根据实际业务逻辑设定条件判断和参数的传入传出，以及起止点的设定，把简单的API组合成具有一定行业应用的业务逻辑，并也用API的形式供上层的工作流引擎来调度，这业务逻辑层面的API固化下来也就具有一定的行业逻辑意义，当不同的项目需要实现相同行业的业务逻辑，只需要简单的调用该API即可，从而在API层面实现了业务逻辑重用的功能。
• D. 代码生成器：提供表驱动的方式生成常用的增删改查代码并对外发布API，提供给项目开发人员的demo代码。该代码能实现一定的业务逻辑，如果项目采用迭代的开发方式，则生成的后台代码结合web界面可作为初次的系统原型，并和用户交互，以取得更精确的需求。

                                       图2：企业平台的开发环境模式


2. 运行支撑平台：         
           运行支撑平台是快速开发平台的顺延。支撑平台考虑得更多是系统性能的可靠性、健壮性、各个模块之间的相互调用和数据转换以及在高并发下的系统支撑。因此，运行支撑平台需要有面向服务架构（SOA）、企业服务总线（ESB）、WEB Service以及数据总线并且支持多服务器集群的功能。具体研究如下：

• A. 用户界面的开发，研究能和遗留web系统（如JSP，Struts，Tapestry等）相互调用和传参的界面设计方案。
• B. 系统功能的集成：研究数据总线（数据传递，格式转换），服务总线（业务逻辑的发布方式），支持SOA、ESB、Web Service的集成方法，工作流引擎需要和SOA有交互的接口
• C. 版本控制问题的研究，实现对于不同行业的API进行版本受限控制。
• D. 工作流系统处于支撑平台的核心位置，工作流建模的定义参考了XPDL，但必需在路由活动条件判断、业务回退处理、超时处理、多人领用任务等方面进行扩展，以符合国内业务的需求；并需要设计监控和统计接口，方便对流程进行管控和统计数据，为决策部门提供科学依据

                                    图3：企业平台的运行时支撑环境的组成


三、流程规划
假定现在有一个业务流程需求，通过企业平台来设计并支撑运行。
和需求方研讨，确定请假流程如下：

                                    图4：请假流程


流程详细说明

• 1、 该流程是普通员工的请假流程，只有1个条件分支
• 2、 流程设定为谁都可以启动
• 3、 《填写请假单》是人工活动，谁启动了该流程，该活动就分配给谁（参与者为流程启动者）。
• 4、 《经理审批》会在该员工的请假单上填写同意与否和备注（经理参与者由前面活动动态指定）。
• 5、 《条件判断》是路由活动，有2个后续分支，如果审批为不同意，则会把该表单反馈给申请者。
• 6、 《数据处理》是自动活动，根据请假类型和请假天数，存入请假系统中
• 7、 《请假人销假》填写实际请假天数，存入请假系统，并和考勤系统，工资系统交互会。之后该流程会全部完成

四、系统设计
1、 界面设计
           该流程在《请假单填写》，《经理审批》，《请假人销假》设定的是3个人工活动，采取Flex作为人机交互的界面，界面设计采取自定义界面方式。
           《数据处理》这里是自动活动，没有交互界面，在审核通过后自动处理，在这里是调用一个业务逻辑处理；《申请人销假》是人工活动，在销假完毕后，脚本中也会调用到几个预先设定好的业务逻辑处理，分别完成一些系统的后台处理。
            《请假单填写界面》:填写基本信息后，选择自己的审批人，在下拉列表框中选择自己的上级。


                                图5：请假单填写界面


《经理审批界面》
打开后获得该用户的填写纪录
1、填写审批过程
2、在结论处选择通过，不通过
选择不通过后，该页面会反馈给申请人，需要重新填写
这个时候只有请假时间和事由可以重新修改，其他输入框为只读

图5：经理回复界面


2、 流程设计
在流程详细说明的基础上，在流程建模器中设定业务流程

                                      图6：流程建模器设计的流程

在设计流程的时候，有3个地方要注意：

• A. 请假单填写，需要选定上级审批人，选定后，该页面将由选定的的审批人打开
• B. 经理审批，有个结论进行YES/NO的选择，选择yes，表示通过，
• C. 条件判断节点，设定一个相关数据，用来控制后续变迁的走向

3、参与者设定
人工活动就是需要有人参与的工作流活动，在实际流程中，它体现在产生由人完成的工作项以及由人决定一些决策变量，这些决策变量会对流程的运行产生影响（例如分支的选择等等）。

在流程中确定参与者，有2种方式：设计期间指定和运行时动态指定
1. 设计期间指定：在建模器就设定了某人工活动的参与者，该参与者类型可以是员工，角色，部门，如果是采取部门，角色的参与者，他们之间有个竞争关系，看谁能获取到该任务。
2. 运行期间动态指定：需要在流程运行期间指定的，比如有的人工活动是流程启动者就需要的，还有的人工活动是前面页面中指派的。比如请假流程，《请假单填写》活动，就是由流程启动者来完成，他启动这个流程就是为了完成自己的请假申请。《经理审批》活动，其参与者是由前面活动指派的，在流程设计期间并不能预见谁是该活动的执行者。

参与者设计期间指定，这种方式简单，这里不作阐述。参与者动态有2种类型：
1、 参与者为流程启动者，设定参与者类型为“assign_myself”，流程启动后会有个信息存储在run process表中，由engine负责提取。
2、 参与者由前面流程指定，设定参与者类型为“assign_ dynamic”：

• A、 设定相关数据，方式经理审批的路由判断方式一样：在《请假单填写》活动中，设定一个应用数据，并在《经理审批》活动设定一个相关数据，应用数据和相关数据的id相同，engine会自动根据相关数据的id获取应用数据的值，从而获得参与者信息
• B、 程序指定，在《经理审批》活动所引用到的参与者，在这里设定一个class，负责返回一个员工信息，该员工信息即为该活动的实际执行者。

4、表设计，自动生成代码
假定我们已经获取了需求，该需求就是设定一个请假流程，并且界面也提交给用户，并且获得了通过，用户交互界面看图4，图5。
然后我们采取表驱动设计模式，对于密集数据的企业应用，比较适用的，设计完表结构，采取代码生成方式生成了base_api，假定调试并且通过单元测试。这些base_api里面涵盖了对请假表的增删改查功能以及对周边系统的处理机制

                           图7：表设计示意图（工作列表、活动定义是engine的已有的定义）

有如下主要api
====================================================
活动             需要的API     说明
----------------------------------------------------
请假单填写        insertLeaveInfo()
                        updateLeaveInfo() 在请假表中插入新纪录
----------------------------------------------------
经理审批        getLeaveInfo()
                       updateLeaveInfo() 在请假表中更新纪录
----------------------------------------------------
数据处理        getLeaveInfo()
                       updateWorkDayInfo()
                       insertWorkDayInfo() 在工作日报表中新插入、更新纪录
-----------------------------------------------------
申请人销假        getLeaveInfo()
                       updateLeaveInfo()   在请假表中更新纪录
                           updateWorkInfo()    在出勤表中更新纪录
                           updateSalaryInfo()  在薪酬系统中更新纪录
-------------------------------------------------------


这里只对“请假人销假”作一个业务逻辑事例，其他的类似，设计业务逻辑有3种方式，目前拟使用直接生成代码的方式

假定销假业务逻辑用到了如下api：
=====================================================
api名称                函数说明
------------------------------------------------------
updateLeaveInfo    更新请假表
getLeaveInfo        获取更新表信息
updateWorkInfo    更新工作日报表
updateSalaryInfo    更新薪酬表
------------------------------------------------------

以上api可以是代码生成直接使用，也可以是手工设计，以上api称呼为原子服务 或 base_api

判断节点：当请假为婚假，休假，只是修改工作日报表
如果是其他请假类型（事假，病假，扣薪水的基数也有不同），则还需要修改薪酬表，表示需要扣点薪水 ；）

                      图8、申请人销假后的业务逻辑设定



五、实例运行
1、 流程平时保存在模型库中，点击启动后，就会产生一个流程实例，每个实例都不同，流程实例有自己的主键，每个流程的活动，同样也有唯一的活动实例主键
2、 人工活动有两种类型，假定我们现在采取的是“自定义页面”方式，也就是通过一个URL地址和页面关联，并能通过一定的方式传入参数（这里需要翔实信息），，
3、 业务页面（比如请假单填写部分）是一个没有状态的数据载体，需要有个参数来控制界面显示什么数据。这个数据就是工单号。
A、 第一次请假单填写的时候，工单号为空，故界面展示的是一个可以输入的form表单，（界面参看图4）。
B、 第二次是经理打开，这个界面就是前面界面携带数据流转过来的，因为是请假单数据，故是调用getLeaveInfo()，这个时候需要从第一个页面携带的工单号，用于提取已经保存的数据，经理在其后填写其他内容（界面参看图5）。
C、 这里有个很重要的地方，就是填写结论结果YES/NO，如果是yes，则调用后续的自动活动，如果是NO，则返回给请假申请人，需要他修改部分条件，重新申请一次。在判断后续分支走向，这里有2种方式，我们这里假定采取一种免编程的方式[注5]。在设计流程的时候，该“经理审批活动”处需要设定一个应用数据（application_data），并且该数据的id取名和后面的“审核判断路由活动”的相关数据取名id要一致，路由活动会根据跟他关联的相关数据的取值，来决定后续分支的走向。
 To_Yes：该工单号继续传给下一个活动，自动工具里面会提取leave表的数据，对日报系统等其他系统进行更改。
 To_No：由申请人重新打开申请表，因为有经理的批示，所以他看到的是图5界面，不同的是，姓名，审批人不能再修改，只能修改请假时间和请假事由，这个得由界面编程来控制。


六、结论
             通过对可视化表单界面设计以及数据绑定技术、可视化代码生成、过程图形建模、基于状态机的工作流引擎的研究，能设计符合企业快速开发和可靠部署运行的业务基础平台。



七、附录：
注1：界面生成的方式有2种

• 自定义页面方式：界面需要开发者预先设定，以及界面的数据的存储方式（自己写api还是调用业务逻辑均可），然后人工活动和自定义页面的方式通过类似URL地址的方式来传递
• webForm设定方式：界面有开发者设定，但界面的数据的存储可以采用设定方式，比如设定该输入框的字段对应某个表的某个字段等，某个下拉框的数据来源与某个表（可用sql作为表示方式），这样开发者就不需要编程，但前提是平台支持这种设定方式以及提供与此匹配的数据操作。

注2：开发方式有2种：

• 领域式驱动开发（domain-driver），在软件架构建模期间，由用例提取domain object，涵盖了功能和业务数据，再从domain object提取表设计元素。软件功能基本上是采取面向对象方式，数据库存储多采用ORM方式。
• 表驱动开发方式（table-driver），在需求获取，和用户确认UI界面，从而提炼出用户需要的表结构，界面设计采取mvc方式，业务逻辑采取service+dao模式。数据库存储多采用JDBC方式。结构示意图见图9。

                                     图9 表驱动开发模式

注3：业务逻辑生成有3种方式：

• 生成直接java代码，在代码中就直接调用base_api，前面就是采取这种方式
• 生成接口java代码方式，类似flow4j的方式，flow4j的方式是按照它自己的格式，生成了一些接口，和实现该接口的骨架类代码，在骨架类代码中的execute()处，需要手工填写base_api。
• 生成xml方式，在xml里面定义java function和参数定义方式，engine会通过反射机制来执行他。

评论

2 楼 timeson 2009-04-25  

这是公司内部的一个项目

底层代码基本实现完毕，实现的有工作流引擎，建模器，底层基础平台（数据库连接，事务，日志，util类，定时器等）

还有些交互的部分没有做完，主要是eclipse插件技术还有些不熟练


下面有些系统的切图：

工作流引擎的核心实现，引擎基于有限状态机控制状态变化，根据过程，活动，任务项，被设计成三层有限状态机（HFSM）方式

图1：引擎有限状态机


1、 所有的对外接口通过EngineFacade对外暴露
2、 引擎的基本的增删改查有service + serviceInternal + basedao 来提供
3、 每个具体的工作流对象，比如过程，活动，任务项，在service这层被工厂实例化，并会使用service+internal内部的api
4、 各个对象的通用处理在他们的抽象类完成
5、 3个抽象类的父类完成事件的传递和送达功能


图2：引擎的总体架构图（简略）

1 楼 lmxbitihero 2009-04-25  

像论文，不知道是否有成功案例。