一种基于Web的业务流程监控模型

一种基于Web的业务流程监控模型： 1 引言

随着Internet技术的发展和普及、Web应用因其零客户端、松祸合、易开发、易维护等优点受到极大的支持和推崇。同时复杂信息系统(CIS)作为部门或企业级信息化平台，它的内涵从最初简单数据检索发展到业务流程集成，以实现业务流程处理的自动化。 因此，基于Web的业务流程的执行会持续较长的时间，进而不能快速响应客户端请求。用户处于漫长的等待中而不知道请求的流程执行进度，从而降低了系统的可操作性。业务流程的相关研究主要集中于其建模技术方面，从数据流程图、控制流程图,IDEF到Petri网、UML、角色活动图等，并钊对业务流程的不同特点提出了多种业务流程模型，如面向状态的、支持动态变化的、与Web服务技术结合的业务流程模型。

而对业务流程的状态监控的研究并不多，本文介绍了一种基于Web的业务流程监控模型M-Model(Web based Business Process Monitor Model)，用来改善用户体验、增强流程的可控性，从而解决基于Web的业务流程长时间无反馈响应的问题。

本文第2节给出模型的定义，描述模型的组成以及相互关系;第3节从模型各部分的状态、协作关系和效果等方面阐述模型的运行机制;第4节给出模型的实现策略以说明模型的可行性，并通过实际应用来证明模型的有效性;第5节描述一些与该模型相关的工作;最后给出全文的总结和进一步的工作。

一种基于Web的业务流程监控模型： 2 模型定义

本研究提出一个模型来解决前文提出的问题，M-Model模型是一种通用的软件设讨模型，是一种独立的结构，同时它也可以整合到Web体系中以适用于各种情况下的Web开发。M-Mode工有七个组成部分(角色)，分别是应用(Application)、监控器(Monitor)、任务(Task)、任务池(TaskPool)、任务管理器(TaskManager)、流程(Process)和监控器存根(Monitor Stub)eM-Model的结构如图1所示。

M-Model适用于基于Web的多层体系结构。用户通过浏览器与系统交互;业务处理位于应用逻辑处理层，运行于Web服务端;业务流程的系统数据存储在数据服务层;监控模块是构建在Web服务之上的一个中间层，为应用提供业务处理的执行状态信息。

在M-Model中，每个用户请求的业务流程都是一个线程。当一个角色在多线程下只提供一个实例，则这个角色是线程共享的，多线程对共享资源的访问会引起线程安全问题。因此，为保证线程安全，在设计中需要细致考虑各个角色的线程特性。下面介绍M-Model中各个角色以及它们是如何在线程间共享数据并保证线程的安全。

角色1 应用(Application):应用是发出请求、显示结果的组件，是与用户交互的接口，在M-Model中应用位于客户层，一个应用的生存周期从它向业务层发出业务流程处理请求开始，到与此次业务流程相关的结果返回。

角色2 监控器(Monitor):监控器为M-Model中监控模块在客户层的代理。它是应用与业务层的桥梁，它接受应用发出的请求并将结果返回给应用。同时，在业务流程执行过程中监控器还周期性地向业务层请求业务流程的状态并且反馈给用户，其生命周期与应用的生命周期相同。

角色3 任务(Task):任务定义为业务流程中处理某一特定方面的操作，它是组成业务流程的最小单元。在面向对象设计中，任务可以是一个类，运行于M-Model的业务层，具有与数据层通信的能力，提供业务处理涉及的数据和操作。任务的生命周期是由任务管理器(角色6)控制的。任务不需要维护及保存其状态，将其实例存放于任务池(角色5)中，等待业务流程处理时激活。任务是多线程共享的，以减少创建任务的时间和存储任务的空问。同时任务也是线程安全的，因为任务的内部状态都转移到流程。

角色4 任务池(TaskPool):任务池是业务层存储任务的组件，是任务的容器，是在线程间共享任务的实例池，它对客户层是完全透明的。Web应用启动时，任务池被创建，停止时被清除。由于任务池提供的对任务的缓存机制，可以减少频繁地创建和回收任务实例产生的系统开销，并节省存储资源。

角色5 流程(Process):流程是若干任务通过协作组成的具有完整业务处理功能的组件。任务本身是无内部状态的，在线程间共享的，任务的状态存储在调用它的流程中，因此流程无法在线程间共享，但也保证了其线程安全性。流程控制任务之问的协作，主要是业务的逻辑控制，而不必关心任务的具体实现。在面向对象设计中，流程是一个抽象类，被每个具体的流程继承。流程实例运行于业务层，提供外部类获取其运行状态的方法。流程在业务层接收到应用发出流程处理请求时被创建，直至组成该流程的所有任务完成并将结果返回客户层时结束。

角色6 任务管理器(TaskManager):任务管理器是任务池中任务的管理者。任务管理器运行在业务层，Web应用开启时被创建，直到Web应用停止时消亡。在面向对象设计中，任务管理器是一个静态类，它用来负责管理一个任务的状态和生命周期，它被多个线程同时访问。第三节将详细描述任务管理器如何管理任务。

角色7 监控器存根(MonitorStub):监控器存根是M-Model中监控模块在业务层的代理。监控器存根主要监听并接收客户层发送的请求，根据请求类型创建并启动流程实例，监控器存根获取流程状态或触发流程外部事件，最后将流程的状态或结果返回给客户层。总之，监控器存根是应用请求在业务层的人口和出口。

一种基于Web的业务流程监控模型： 3 运行机制

依据M-Model中各组成部分的定义和它们之间的关系(如图1)，本节给出完成一次业务流程处理的步骤以及各个组成部分之间的协作关系。

第1步:用户通过应用提供的交互接口，提出一个执行流程请求。

第2步:监控器监听到执行流程请求，将请求及业务流程名称发送给业务层。

第3步:监控器存根收到执行流程请求及业务流程名称，并创建相应的具体流程实例。

第4步:监控器存根启动具体流程，流程在业务层独立运行。在流程运行期间会向任务管理器请求分配任务资源。任务管理器从任务池中分配有关的任务给具体流程，流程组装任务的协作以进行业务处理。

第5步:监控器存根返回流程开始状态。

第6步:监控器接到返回的流程状态后，将结果传送给应用以显示给用户。

第7步:监控器向业务层发送查询流程状态请求，同时监听应用是否提出改变流程请求。

第8步:监视器存根收到查询流程状态的请求，去获取流程的当前状态。

第9步:监控器存根返回流程状态。

第10步:监控器根据流程状态决定下一步的动作。如果流程状态为执行，执行第6步。

第11步:应用显示流程的执行结果，一次业务流程处理结束。

以上为业务流程正常执行的顺序。M-Model还提供客户请求并改变正在执行的流程的机制。当应用在流程启动但未完成的过程中发出改变流程请求时，监控器存根捕获到该请求，找到正在执行的流程并做相应改变或重新设定流程的状态。

一种基于Web的业务流程监控模型： 4 模型实现和案例分析

M-Model工已经成功运用在国家海洋环境数据管理和挖掘系统中。国家海洋环境数据库的数据量庞大，针对该数据库的管理和挖掘系统的每一个业务处理都会耗费大量时间(1至5分钟)。由于国家海洋环境数据管理和挖掘系统采用基于Web的三层体系结构，为了提高系统的可用性，该系统使用M-Model模型来监控业务流程，改善页面效果。系统采用MVC模型在SWAP平台的基础上进行改进，将M-Model融人其中，利用面向对象程序设计技术实现各个组成部分(角色)，各角色的具体设计见表1。

本文对采用与未采用M-Model两种情况下，系统的运行情况做了定量和定性的比较。对比流程执行时间、流程状态显示、流程可控性、用户满意度等方面，可以得出M-Model是有效的，而且性能优良。图2给出了流程执行时间的比较图，从图中可以得出以下结论:(1)执行相同的流程，采用M-Model执行时间比不采用M-Model增长。时间增长的原因是由于M-Model增加对客户层不断发来的流程执行状态请求的处理而产生的。

(2)平均时间增长率很小，约为百分之五左右。这说明采用M-Model系统增加的执行时间与正常执行时间相比是可以忽略的。(3)不同业务复杂度在使用M-Model前后流程执行时间都有增加，但增长率很小，而且增长率的方差非常小，趋近于零。这说明系统流程的执行具有良好的稳定性。表2列出M-Model与非M-Model的其它方面的比较，从对比中可以看出由于M-Model提供良好的流程状态实时显示和可控性，使得采用M-Model设计的系统的用户满意度高于一般的Web应用。

结论和进一步工作Web业务流程尤其是长，时执行的业务流程的可监控性是实际用户关心的问题。本文提出的Web业务流程监控模型采用多层体系结构将应用逻辑、处理过程和显示逻辑分成不同的层次实现，可以实现很好的用户体验，增强用户对流程的可控性，提高业务处理对用户的透明性。而Web应用的提供者可以灵活协调业务功能来处理业务流程，使得该模型可以较好地适应Web环境下各种各样的应用需求。M-Model模型没有提供一种强制手段来保证流程的事务性，流程的中断和回滚依赖于数据库、曰砂等第三方平台保证，如何自动实现流程的事务性是本研究进一步的工作。