业务流引擎

关键词： 应用程序 规则 业务 标准

业务流引擎（精选六篇）

业务流引擎 篇1

一、决策规则调度技术-规则引擎

传统的业务处理系统一般是基于C/S架构, 即服务器接受客户端的请求, 进行业务逻辑运算, 操作数据库完成相应流程, 最后将结果返回到客户端进行显示;客户端需要安装特定的程序, 称为“胖客户端”。随着网络技术的发展, 越来越多的业务处理流程开始转移到以网络为基础的应用上, 由此出现了基于B/S分层架构的业务处理系统。在这种架构中, 大量的业务逻辑和各种运算作为中间层, 从客户端抽离出来, 形成专门的中间层应用服务器。客户端通过网络浏览器进行访问;而中间层作为处理系统的可重用组件, 当业务处理逻辑发生变化时, 只须修改相应的中间层组件即可, 这样就提高了业务处理系统的适应能力和扩展性。这两种系统架构如图1基于C/S分层架构和图2基于B/S分层架构所示。

图2所示的这种基于B/S分层架构的多层架构方式和以前的C/S架构相比, 有了更大程度上的灵活性和重用性, 但随着业务处理流程的复杂化, 这种架构也开始表现出一定的局限性, 主要如下:

(1) 虽然中间层组件更加清晰地表达了业务处理逻辑, 但业务模型和业务逻辑仍然混合在一起, 没有彻底将业务逻辑和代码逻辑分离开来, 在一定程度上仍然存在逻辑层次不清晰的弊病。

(2) 这些中间层组件虽然是可重用的, 但是当业务需求发生变化时, 需要经过编码、编译、发布等一系列步骤后才能适应业务逻辑的变化, 这使得业务处理系统的灵活适应能力不能充分发挥出来, 增加了升级、维护阶段的复杂程度。

规则引擎的出现解决了这些传统架构的弊端, 借助业务规则系统, 可以灵活地配置规则文件, 当系统的需求发生变化时, 只须修改业务规则, 而无须对整个系统进行复杂的升级修改。如图3为基于业务规则引擎的系统模型框图。

二、业务规则

一个业务规则包含一组条件和在此条件下执行的一组操作, 它们表示业务操作应用程序的一段业务逻辑。业务规则通常应该由业务分析人员和策略管理者开发和修改。业务规则的理论基础是:设置一个或多个条件, 当满足这些条件时会触发一个或多个操作。

运行时, 规则引擎必须对这些业务规则进行解释, 因而可以将规则引擎理解为一种高性能的专用解释程序, 其中包含ifthen命令, 可根据预先定义的规则对转换的值和对象进行分析, 然后返回修改后的值和对象, 或直接执行操作。

对于企业而言, 客户和整个市场情况的不断变更, 必须将这些变更归类为业务规则。业务规则专家组规定了业务规则的两个定义。其中一个定义与业务观点相关, 而另一个定义与IT相关:

1. 从业务的角度看, 业务规则是一种原则, 在特定活动或范围内作为指导、操作、实践或过程的行为规范。

2. 从IT的角度看, 业务规则是一个定义或限制业务某些方面的声明。业务规则旨在用于定义业务结构, 或者控制或影响业务行为。

三、规则引擎

什么是规则引擎?规则引擎是如何执行规则的?这就是称之为“什么”与“如何”的问题。专业组对规则引擎给出了这样一个定义:规则引擎由推理引擎发展而来, 是一种嵌入应用程序中的组件, 实现了将业务决策从应用程序代码中分离出来, 并使用预定义的语义模块编写业务决策;接受数据输入, 解释业务规则, 并根据规则做出业务决策。

当引擎执行时, 会根据规则执行队列中的优先顺序逐条执行规则实例, 由于规则的执行部分可能会改变工作区的对象数据, 从而会使队列中的某些规则执行实例因为条件改变而失效, 必须从队列中撤销, 也可能会激活原来不满足条件的规则, 生成新的规则执行实例进入队列, 于是就产生了一种“动态”的规则执行链。

规则条件匹配的效率决定了引擎的性能, 引擎需要迅速测试工作区中的对象数据, 从加载的规则集中发现符合条件的规则, 生成规则执行实例。

四、规则的灵活实现——词汇与规则部署

词汇表就是指包含规则条件及操作中使用的事实的用户定义名称的定义集合。词汇定义使得规则在某一特定的业务领域中更易于阅读、理解和共享。

在图4的词汇表定义器中可以看到词汇条目都被加盖上版本号, 然后发布到规则存储中。这就保证了词汇定义在调用过程中不会改变并保持了引用的完整性。

我们在规则引擎中根据需要定义词汇, 并赋予不同的版本, 在业务人员修改版本的时候, 甚至可以定义词汇生效的时间, 而不需要停止当时的规则引擎中的活动, 这样从技术角度, 只需完成最初词汇与规则的建立, 而词汇的内容, 也就是业务需求变动最多的地方与规则独立开来, 由业务人员自由调配, 从而真正实现了业务流程的灵活性。

五、小结

传统许多业务流程受到软件局限性困扰的主要原因大多是由于决策规则被准确地转换为程序代码后, 一旦软件投入正式运行, 对于基本代码的任何后续修改都将困难重重。

但在实际业务流程的使用中, 业务策略并不是静态的, 它们经常会变更, 同时与其关联的业务流程也会随之变更。正是由于这些变更, 故而有必要在实现和修改业务流程时保持灵活性, 从而在激烈的竞争中赢得一席之地。业务规则引擎可以实现所要求的这种灵活性, 从而确保工作流系统能够在各个应用中被广泛使用。

摘要：业务规则指导着所有业务流程中的决策行为, 业务规则就是一些条件标准, 系统根据这些标准对所有的事实变量进行评估, 从而决定恰当的业务操作。在传统的应用程序设计中业务规则被事先设计好并与流程密切相关, 无法分割。在新型的业务流程处理过程中, 通过规则决策引擎可以灵活有效的处理多变的业务策略, 并减少传统的开发方法所带来的局限性和低效性。

业务流引擎 篇2

引言

规则引擎原理

流程应用

基于saas的模式

意义

1、引言

目前，B2B电子商务平台发展了大量的中小企业用户，提供具有共性的信息管理服务，但是这些服务对于特定用户来说，无法根据该用户的业务流程来构造与其自身业务相匹配的管理过程；同时，平台亦无法应对会员企业将来发展带来的管理过程的不断变化。

在这种情况下，为中小企业用户提供个性化的服务，对企业的意义是非常重大的。尽管现在有些软件开发商为企业提供量身定制的功能需要，但这种方式开发成本很高，而且基本上是按照当时或者用户可以预见的方式进行开发，不可避免的出现一些弊端：

（1）需要安装专门的管理系统软件，维护困难；

（2）功能的灵活性较小，只能符合某些行业的特点，不符合B2B电子商务平台上广大行业的需求；

（3）功能的配置操作复杂，不利于中小企业用户的使用；（4）功能维护和修改的成本高。

为了解决上述弊端，基于SaaS的业务规则引擎的方法被提了出来，这种方法充分利用了SaaS（软件即服务）的特点，不需要在中小企业的计算机上安装任何软件，把系统的日常维护工作都交给软件服务运营商；而且使用成本低廉，符合中小企业的信息化成本要求。同时通过企业业务流程与规则引擎的结合应用，把商业规则与应用开发代码，让中小企业的工作人员能在运行时可以动态地管理和修改商业规则，保证了软件系统的柔性和自适应性，使电子商务平台为中小企业用户提供个性化的服务打下了良好的基础。

2、业务流程与规则引擎

2.1 业务流程与流程引擎

业务流程属于工作流的范畴。工作流指全部或者部分由计算机自动处理的业务过程。而工作流管理系统是这样的一个系统：详细定义、管理并执行“工作流”，系统通过运行一些软件来执行工作流，这些软件的执行顺序由工作流逻辑的计算机表示形式（流程定义）来驱动。

工作流系统与业务系统的关系如下图所示：

业务系统流程应用支撑层支撑审批流程支撑业务过程支撑业务整合工作流引擎

国际标准化组织WFMC（工作流管理联盟）发布了一个通用的工作流系统实现模型，这个模型可以适用于市场上的大多数产品，因此为开发协同工作的工作流系统奠定了基础。

把工作流系统中的主要功能组件，以及这些组件间的接口看成抽象的模型。考虑到会有许多其他的具体实现不同于这个抽象模型，因此，特定的接口在不同的平台中会采用不同的技术，有不同的实现方式。而且并不是所有的开发商都会暴漏功能组件间的每一个接口，具体的规范会定义接口之间的相互操作功能，不同的厂商必须支持这些开放接口才能实现不同工作流之间的协作。

通用的工作流系统实现参考模型如下所示：

不同的厂商必须支持5类开放接口才能实现不同工作流之间的协作。

a)过程定义工具（Process Definition Tool）

过程定义是用来创建一个计算机可以处理的形式的过程描述。可能要以形式过程定义语言、对象关系模型、简单的系统、脚本、或者在参与者间进行信息传递的路径集为基础。工作流定义工具，可能作为工作流产品的一部分、也可能作为业务过程分析产品的一部分来提供给用户，作为业务过程分析产品一部分，会有其他的组件来负责处理业务过程的分析或者模型，这时，必须要有兼容的转换格式，与运行时期的工作流软件进行过程定义的相互转换。

b)过程定义（Process Definition）

过程定义包含，工作流执行软件运行过程所需的过程所有详细信息。包括过程的开始和结束条件、组成活动、在活动间进行导航的规则、需执行的用户任务、可能会被调用的应用程序、所有工作流相关数据的定义等。

过程定义可能会涉及到一个组织/角色模型，模型包含组织结构和组织中的角色等信息。从而使过程定义在，与具体活动或信息对象相关的组织实体和角色功能方面，十分详细。工作流执行服务器负责把工作流运行环境中的参与者与相应的组织实体或角色联系起来。c)工作流执行服务器（Workflow Enactment Service）

工作流执行服务器软件负责：解释过程定义、控制过程实例、安排活动的执行顺序、向用户工作表中添加工作项目、调用应用工具。这需要一个或者多个协同工作的工作流机来完成这些职责，工作流机管理各种过程的一个单独实例。工作流执行服务器维护内部控制数据，这些数据或者集中于一个工作流机中，或者分布在一个工作机集合中；这些工作流控制数据包括与各种过程、或者正执行的活动实例相关的内部状态信息，也包括工作流机用来合作或者从失败中进行恢复的检查点、恢复/重新启动信息。

过程定义与（运行时期）工作流相关数据协作，一同用来控制过程中活动的导航、提供活动的进入与退出条件、不同活动的并行执行、顺序执行选项、用户任务、与每个活动相关的IT应用程序等。如果过程定义包括组织模型/角色实体类型，那么完成以上任务，需要访问组织/角色模型数据。

工作流机也包括调用一些形式的应用工具的能力，来激活必要的应用程序执行相关活动。这种调用机制间有很大的不同，在一些简单的系统中，也许只提供对单一的固定工具调用（例如，文本编辑器），然而在工作流系统中可能提供调用本地与远程的大范围内工具的方法。

d)工作流相关数据和应用数据（Workflow Relevant Data and Application Data）

过程导航判断或工作流机中的其他控制操作，都以工作流应用程序产生或者更新的数据为基础，这些数据可以被工作流机和条件工作流相关数据（也成为情况数据）所访问；这是工作流机唯一可访问的应用程序数据。尽管，工作流机负责在应用程序间传递工作流应用程序数据，但工作流应用程序数据直接由被调用过程操作。不同的应用程序由工作流过程内的不同活动调用。

e)任务表（Worklists）

过程执行中需要用户交互的地方，工作流机把任务添加到任务表中，以便任务表处理器对其处理，任务表处理器管理与工作流参与者的交互。这个过程对工作流参与者可能是不可见的，任务表在工作流软件中维护，把用户需要执行的下一个任务提供给他。在其他系统中，任务表可能对用户是可见，用户自己从任务表中选择执行任务，任务表也用来指示任务的完成。

f)任务表处理器用户接口（Worklist Handler & User Interface）

任务表处理器是一个软件组件，管理工作流参与者与工作流执行服务器间的交互。任务表处理器负责请求用户关心的进展中的任务，并负责通过任务表与工作流执行服务器进行交互。在一些系统中，只是使用一个桌面应用程序来提供一个简单的任务进入，等待用户注意。在其他一些系统中，任务表的处理可能更成熟，控制任务在一些用户间进行分配，并考虑到转载平衡、任务重分配等。另外的一些任务表处理功能，工作流机典型支持与客户端应用程序大范围的交互，包括工作流参与者的签到和退出、请求过程实例的开始、任务排队等候特殊的参与者等。在工作流参考模型中，更广泛的使用“客户端应用程序”这个词，而不是“任务表处理器”，从而反映其潜在的广大使用范围，其包含任务表处理功能的同时也包含过程控制功能。

在上图中，用户接口是一个单独的软件组件，负责提示和处理用户对话框，并控制本地用户的本地接口。在某些系统中，用户接口可能会与任务表处理器组合到一起，构成一个简单的功能实体。我们希望一些客户端应用程序能够和几个不同的工作流服务器进行交互，从而把服务器中的任务整理成统一的格式，通过公共用户接口提供给用户。

可能会调用本地应用程序，来支持用户完成特殊的任务，这由任务表处理器来负责，或者由用户负责，在用户接口使用简易通用工具来安装适当的支持程序。在任务表处理器/用户接口中调用应用程序与工作流执行软件直接调用应用程序，有明显的不同。

g)管理操作（Supervisory Operations）

工作流系统中有许多的管理功能；这些管理功能以工作站点或者用户的管理权限为基础。这些管理功能使得管理者可以修改任务分配规则、确定过程中组织角色的参与者、跟踪遗漏的最终期限报警或根据其他事件、跟踪某一过程实例的运行历史、查询任务吞吐量或其他统计信息等。使用分布式工作流机的地方，可能需要特殊的命令来在不同的工作流机间传递控制操作或者（局部）响应，从而提供一个单一的管理接口。

h)外部和内部接口（Exposed and Embeded Interfaces）

上述的体系结构适用于大多数工作流产品，但是并不是所有的产品在每个不同的系统功能组件间，都提供外部接口；一些产品把几个功能组件作为一个逻辑实体来实现了，并把接口包含在了软件组件的内部，导致无法被第三方产品使用。WFMC规范定义了每个接口在实现多工作流系统协同工作中的作用，因此，可以鉴别单独的产品是否符合协同工作标准。

2.2 规则引擎

规则引擎是一种根据规则中包含的指定过滤条件，判断其能否匹配运行时刻的实时条件来执行规则中所规定的动作的引擎。与规则引擎相关的有四个基本概念，为更好地理解规则引擎的工作原理，下面将对这些概念进行逐一介绍。

1)信息元（Information Unit）

信息元是规则引擎的基本建筑块，它是一个包含了特定事件的所有信息的对象。这些信息包括：消息、产生事件的应用程序标识、事件产生事件、信息元类型、相关规则集、通用方法、通用属性以及一些系统相关信息等等。

2)信息服务（Information Services）

信息服务产生信息元对象。每个信息服务产生它自己类型相对应的信息元对象。即特定信息服务根据信息元所产生每个信息元对象有相同的格式，但可以有不同的 属性和规则集。需要注意的是，在一台机器上可以运行许多不同的信息服务，还可以运行同一信息服务的不同实例。但无论如何，每个信息服务只产生它自己类型相 对应的信息元。

3)规则集（Rule Set）

顾名思义，规则集就是许多规则的集合。每条规则包含一个条件过滤 器和多个动作。一个条件过滤器可以包含多个过滤条件。条件过滤器是多个布尔表达式的组合，其组合结果仍然是一个布尔类型的。在程序运行时，动作将会在条件 过滤器值为真的情况下执行。除了一般的执行动作，还有三类比较特别的动作，它们分别是：放弃动作（Discard Action）、包含动作（Include Action）和使信息元对象内容持久化的动作。前两种动作类型的区别将在2.3规则引擎工作机制小节介绍。

4)队列管理器（Queue Manager）

队列管理器用来管理来自不同信息服务的信息元对象的队列。

下面将研究规则引擎的这些相关构件是如何协同工作的。

如图2所示，处理过程分为四个阶段进行：信息服务接受事件并将其转化为信息元，然后这些信息元被传给队列管理器，最后规则引擎接收这些信息元并应用它们自身携带的规则加以执行，直到队列管理器中不再有信息元。

图2 处理过程协作图

3、规则引擎的工作机制

下面专门研究规则引擎的内部处理过程。如图3所示，规则引擎从队列管理器中依次接收信息元，然后依规则的定 义顺序检查信息元所带规则集中的规则。如图所示，规则引擎检查第一个规则并对其条件过滤器求值，如果值为假，所有与此规则相关的动作皆被忽略并继续执行下 一条规则。如果第二条规则的过滤器值为真，所有与此规则相关的动作皆依定义顺序执行，执行完毕继续下一条规则。该信息元中的所有规则执行完毕后，信息元将 被销毁，然后从队列管理器接收下一个信息元。在这个过程中并未考虑两个特殊动作：放弃动作（Discard Action）和包含动作（Include Action）。放弃动作如果被执行，将会跳过其所在信息元中接下来的所有规则，并销毁所在信息元，规则引擎继续接收队列管理器中的下一个信息元。包含动 作其实就是动作中包含其它现存规则集的动作。包含动作如果被执行，规则引擎将暂停并进入被包含的规则集，执行完毕后，规则引擎还会返回原来暂停的地方继续 执行。这一过程将递归进行。

图3 规则引擎工作机制

Java规则引擎的工作机制与上述规则引擎机制十分类似，只不过对上述概念进行了重新包装组合。Java规则引擎对提交给引擎的Java数据对象进行检 索，根据这些对象的当前属性值和它们之间的关系，从加载到引擎的规则集中发现符合条件的规则，创建这些规则的执行实例。这些实例将在引擎接到执行指令时、依照某种优先序依次执行。一般来讲，Java规则引擎内部由下面几个部分构成：工作内存（Working Memory）即工作区，用于存放被引擎引用的数据对象集合；规则执行队列，用于存放被激活的规则执行实例;静态规则区，用于存放所有被加载的业务规则，这些规则将按照某种数据结构组织，当工作区中的数据发生改变后，引擎需要迅速根据工作区中的对象现状，调整规则执行队列中的规则执行实例。Java规则引 擎的结构示意图如图4所示。

图4 Java规则引擎工作机制

当引擎执行时，会根据规则执行队列中的优先顺序逐条执行规则执行实例，由于规则的执行部分可能会改变工作区的数据对象，从而会使队列中 的某些规则执行实例因为条件改变而失效，必须从队列中撤销，也可能会激活原来不满足条件的规则，生成新的规则执行实例进入队列。于是就产生了一种“动态” 的规则执行链，形成规则的推理机制。这种规则的“链式”反应完全是由工作区中的数据驱动的。

任何一个规则引擎都需要很好地解决规则 的推理机制和规则条件匹配的效率问题。规则条件匹配的效率决定了引擎的性能，引擎需要迅速测试工作区中的数据对象，从加载的规则集中发现符合条件的规则，生成规则执行实例。1982年美国卡耐基·梅隆大学的Charles L.Forgy发明了一种叫Rete算法，很好地解决了这方面的问题。目前世界顶尖的商用业务规则引擎产品基本上都使用Rete算法。

3、业务流程与规则引擎的融合

作为企业IT基础设施的关键部分，业务流程管理越来越重要了。在BPM产品套件平台上，可以建模、部署、执行和监视企业的业务流程，业务流程可以包含业务规则。例如，在银行的账户验证过程中，评估客户资格或确定价格的业务策略很复杂，而且在快速发展的市场中常常会变动。把这些策略硬编码在过程中是不合适的，因为很难在运行时管理和维护业务规则。通过把业务规则和业务流程分隔开，单独地执行和管理它们，可以提高整个业务流程的敏捷性和扩展性。ILOG的JRules在融入到IBM的WebSphere套件体系后，在架构层面和技术层面充分体现了这种业务流程与业务规则分离的思想，如下图所示：

ILOG JRules是先进的业务规则管理系统（Business Rule Management System，BRMS），提供编写、部署和管理业务规则等业务功能，支持高效地修改策略和快速部署策略。

ILOG JRules提供一种建模、实现和部署业务规则的系统化方法。它支持以有秩序的高效的方式进行协作。它包含的工具针对不同用户的技能和知识优化过，因此策略经理、业务分析师和开发人员都可以获得所需的支持，可以尽可能发挥BRMS的价值。

4、重要意义

企业管理者对企业级IT系统的开发有着如下的要求：

1.为提高效率，管理流程必须自动化，即使现代商业规则异常复杂；

2.市场要求业务规则经常变化，IT系统必须依据业务规则的变化快速、低成本的更新；

3.为了快速、低成本的更新，业务人员应能直接管理IT系统中的规则，不需要程序-而项目开发人员则碰到了以下问题： 4 5 程序=算法+数据结构，有些复杂的商业规则很难推导出算法和抽象出数据模型； 软件工程要求从需求->设计->编码，然而业务规则常常在需求阶段可能还没有明确，在设计和编码后还在变化，业务规则往往嵌在系统各处代码中； 6 对程序员来说，系统已经维护、更新困难，更不可能让业务人员来管理。

基于规则的专家系统的出现给开发人员以解决问题的契机。规则引擎由基于规则的专家系统中的推理引擎发展而来。

业务流引擎 篇3

应用系统中往往存在大量if ···then ···else结构的代码来完成对相应业务逻辑的判断与处理, 这种直接使用源码定义业务逻辑的方式很难适应外部业务逻辑的变化, 相应维护成本也将大大提高[1]。为了提高对业务逻辑定义与维护效率, 专门用于业务逻辑定义、解析与执行的规则引擎应运而生。Drools就是其中非常典型的一种[2]。然而Drools只能识别与处理基于DRL (Domain Rule Language) 格式定义的业务逻辑, 也就是说业务人员不能直接定义符合实际需要的业务逻辑, 而需要专业人员来完成;一旦规则本身发生变化, 需要在业务人员与专业人员之间进行大量的沟通与协调工作, 由此大大降低规则引擎在整个系统中的执行效。该问题解决的关键在于可由业务人员直接定义与维护相应业务逻辑。Drools也试图通过使用DSL (Domain Specific Language) [3]来解决该问题, 然而由于DSL只能解析与执行有限英文语句定义的业务逻辑, 因此其推广与应用非常有限。本文从领域逻辑入手进行领域逻辑的分析、规划、定义与解析, 从而提出领域规则元模板的概念;通过利用语言解析程序ANTLR来帮助业务人员基于领域规则元模板定义的业务逻辑到Drools DRL逻辑的转换, 从而有效地支持了业务人员对业务逻辑的直接定义与维护。

1 领域规则元模板定义

面向业务的逻辑描述方法与Drools可理解与执行的逻辑描述定义主要存在以下几点差异:

(1) 结构与语义方面。面向业务的逻辑定义通常用各种不同的自然语言描述, 由此导致面向业务的逻辑描述相应语句结构与描述内容不确定, 其相应语义也较模糊。面向规则引擎Drools的逻辑描述必须遵循严谨的结构以及语义定义才能被正确理解与执行。

(2) 描述方式方面。面向业务的逻辑定义通常可用“如果……那么……否则”的结构及其嵌套进行定义, 而面向规则引擎Drools的逻辑描述只能遵循非嵌套的ifthen描述形式。

为了在面向业务与面向Drools之间达成逻辑描述的一致性, 需要使用以下几个基本概念:

(1) 领域规则元模板。它是面向业务的逻辑描述中组成元素抽取的统称。这些领域规则元模板可以用于描述条件判断中的大小比较、赋值处理、嵌套结构句型等。领域规则元模板是不可再细分的逻辑单元, 它对应了严格的逻辑解析与执行方法。领域规则元模板通常由连接多个固定词汇与0到多个空白部分组成。

(2) 领域规则模板。它是在领域规则元模板基础上, 通过特定句型 (如ifthenelse及其嵌套) 及一定顺序约束组织起来的内容;它是一类具体业务逻辑的抽象。业务人员根据实际业务逻辑描述需要组织领域规则模板, 并在其领域规则元模板的空白部分输入或选择实际内容。

(3) 领域规则。它是由业务人员定义与维护的具体逻辑描述。

从面向业务的逻辑定义到面向Drools的逻辑定义, 需要完成以下几项基本工作:

(1) 领域规则元模板的定义与解析。需要由专业人员来定义与维护面向特定业务领域的领域规则元模板。除了维护领域规则元模板的组成结构, 还需要维护元模板的词法与语法解释。

(2) 领域规则模板的定义与解析。由专业人员来定义与维护领域规则模板的解析与处理。

(3) 面向业务的领域规则定义与解析。面向业务的逻辑描述由业务人员在系统提供的领域规则元模板与领域规则模板基础上完成;由领域规则元模板与领域规则模板解析程序将其转换为Drools可理解与执行的逻辑描述形式。

2 领域规则元模板及领域规则模板的解析

领域规则元模板以及领域规则模板的定义与解析属于基于自然语言的语句词法与语法解析问题。ANTLR[4]是目前一种被广泛认可与应用的词法和语法解析框架, 常被用于完成自定义数据库查询或编程语言的解析与执行。ANTLR可以对基于其语法表达的任意自然语句进行解析与处理, 相应文法文件定义了识别的范围与处理内容, 完成将满足特定约束的自然语句组成转换为面向Java或C++的对象。ANTLR对自然语句的解析分词法解析与语法解析两个步骤, 其中词法解析主要负责将输入的自然语句分解为相互独立的标识符、关键字、常量等组成单元, 语法解析即针对这些标识符、关键字及常量等组成定义其处理方法, 并可以对象的形式返回处理结果供其他应用程序使用。

与其他语言解析程序不同, ANTLR具有以下几个鲜明的特点:

(1) ANTLR支持广泛的字符定义。ANTLR对输入自然语句的识别以字符为基础, 不仅可识别基于ASCII编码的字符, 还可识别基于Unicode编码的字符;因此从理论上讲, ANTLR可识别与处理基于任何自然语言字符组成的自然语句。

(2) ANTLR支持多种编程语言。ANTLR的语法定义可被自动转换为包括Java、C、C++在内的多种编程语言, 从而可将ANTLR与开发者比较熟悉编程语言开发的应用程序相结合来完成对业务人员输入的自然语句组成的处理。

(3) ANTLR文法定义与维护比较容易。ANTLR是基于扩展巴科斯范式EBNF上下文无关的元符号表示文法而定义的;且目前ANTLR还提供了相应的可视化工具来查看相应文法定义的DFA结构, 由此可在开发者与业务人员之间快速达成一致。

3 基于ANTLR的Drools改进后规则系统开发框架及应用案例说明

基于ANTLR领域模板解析改进后的规则系统开发框架ADF如图1所示。

ADF开发框架主要由客户端、ANTLR解析、Drools处理三部分组成。其中客户端部分又分专业人员定义与业务人员定义两部分;专业人员需要定义面向业务的领域规则元模板、模板结构及其相应解析方法, 业务人员则在领域规则元模板的基础上定义具体面向业务的逻辑内容。ANTLR解析部分首先利用ANTLR完成对面向业务的领域规则元模板及模板的文法文件的解析, 生成词法解析与语法解析对象;然后通过调用该词法解析与语法解析对象的对象完成对业务人员定义的逻辑解析与处理, 生成对应的Java对象以及相应的DRL规则。Drools处理部分则利用已生成的DRL规则定义结合实际的事实对象, 最终完成实际逻辑的匹配、选择与执行, 并将实际逻辑运行结果存储到相应Java对象中, 以便被其他应用程序调用处理。以下通过对工作流任务分派领域中面向业务的逻辑定义、解析与执行来说明ADF开发框架的使用方法。

3.1 客户端部分实现方法

专业人员需要针对实际的工作流任务分配的多种具体表达形式总结出相应的领域规则元模板及模板内容, 并利用ANTLR完成相应模板的文法解析定义;在此基础上, 向业务人员提供易于操作与理解的工作流任务分派规则元模板、模板的操作界面。如一具体工作流任务分派领域业务逻辑描述如下:

以上面向业务的工作流任务分派逻辑是基于以下几个领域规则元模板完成的:

(1) 流程变量比较元模板:流程变量 (<流程变量名称元模板>) (<关系运算符>) (<INT>) , 其中<流程变量名称元模板>定义为包含“申请金额”、“审批者”、“申请代理机构”等类似选项的元模板;<关系运算符>定义为包含“等于”、“不等于”、“低于”、“高于”等类似选项内容的元模板;<INT>定义了用户输入金额必须为整型数值的信息。机构级别比较元模板与之类似, 这里不重述。

(2) 面向流程所属机构的职位分配元模板:流程所属机构的职位 (<职位元模板>) 。其中职位元模板定义为包含“主管”、“副主管”、“技术主管”、“财政主管”等选项信息。

(3) 直接任务分配模板:

把任务分配给<任务分配对象模板>

(4) 条件任务分配模板:

如果 (<条件组合模板>)

则 (<直接任务分配模板>|<条件任务分配模板>)

否则 (<直接任务分配模板>|<条件任务分配模板>)

其中<任务分配对象模板>可定义为包含<面向流程所属机构的职位分配元模板>、<面向流程所属机构的上级机构的职位分配元模板>等在内选项的模板。<条件组合模板>由可包含“与”、“或”的多个<条件元模板>组成, 其中<条件元模板>又定义为包含<流程变量比较元模板>、<机构级别比较元模板>等选项的元模板。

以面向业务的条件任务分配模板为例, 其在ANTLR文法文件中的定义为:

condition Allocation Template返回String Buffer类型结果, 结果存储在str变量中。C1、C2、C3、C4分别代表识别固定词汇“如果”、“则”、“否则”、“把任务分配给”。execute Template代表当条件满足或不满足时执行的模板内容, else Execute Template代表条件不满足时执行的模板内容, 它又由固定词汇C3连接execute Template构成。condition Allocation Template、condition Template、else Execute Template使用ANTLRWorks编辑定义时对应的ADF分别如图2、图3、图4所示。

在condition Allocaiton Template的识别过程中, 将从condition Template实际获得的结果赋值给变量p1, 将“则”后面通过execute Template实际获得的字符串信息赋值给变量p2, 将“否则”后面通过execute Template模板获取的字符串信息赋值给变量p3;如果p3部分的内容为空, 则意味着该规则不包含不满足条件的处理。本处condition Allocation Template返回的对象为String Buffer类型, 目的是为了将后面更好地组织后面识别出来的String类型对象。

基于ANTLR的规则元模板与规则模板定义文法文件需要声明以下几项内容:

(1) 给规则元模板、规则模板赋以相应的英文名称, 以便后续引用与共享。

(2) 规则模板与元模板中出现的中文固定词汇需要使用相应的Unicode编码表达。

(3) 可将用户选择引用的规则元模板中输入或选择的内容所产生实际内容直接赋值个一个变量, 以便进行后续处理;注意这些直接声明的变量返回的结果都是字符串类型, 因此如果需要其参与类似数值计算的运算, 还需要对其进行相应的类型转换。

(4) 为规则元模板或模板定义一个返回值对象以及返回类型信息。

(5) 采用特定编程语言 (如Java或C++等) 说明返回对象的创建以及返回对象与直接声明变量之间的运算关系。

3.2 ANTLR解析部分实现

ANTLR会根据开发者定义的规则模板文法信息自动生成对应的词法解析Lexer和语法解析Parser对象 (如以上实例将生成allocation Lexer和allocation Parser对象) 供应给程序调用。开发者编写应用程序调用allocation Lexer与allocation Parser解析业务人员输入的任务分配规则, 并将其归约为多个Token对象, 并在使用的每个模板前面添加了模板标识。专业人员还需要在ANTLR处理部分编写程序完成面向业务的规则到面向规则引擎的规则转换, 具体包含以下两个内容: (1) 完成汉语“如果……则……否则”嵌套表达结构到Drools的“whenthen”非嵌套结构的转换。 (2) 完成各规则元模板中处理的汉语描述到Java对象方法的转换。

3.2.1“如果……则……否则”嵌套表达句型到Drools的“whenthen”非嵌套句型的转换

ANTLR针对外部输入语句中包含的“如果……则……否则”嵌套句型分两步来完成:

1) ANTLR对“如果”、“则”、“否则”的嵌套识别

系统在词法匹配过程中如果匹配到“如果”这样的词汇, 则自动将其及后面的内容与condition Allocation Template模板的内容组成进行匹配;如果词法匹配通过, 则会自动将“如果”、“则”、“否则”后面的内容送入condition Template、execute Template以及else Execute Template中;其中else Execute Template可为null, 也就是说该任务分配语句只针对条件满足时进行分配的处理。由于execute Template本身就是一个condition AllocationTemplate, else Template最终也转换为execute Template, 因此condition Allocation Template很好地支持了输入语句“如果”、“则”、“否则”的嵌入表达。

2) ANTLR对“如果”、“则”、“否则”的嵌套处理

不管任务分配的具体执行内容是针对条件满足或条件不满足, 最终它们转换为execute Template规则模板句型, 但是需要在execute Template模板的语法定义中完成对条件节点、满足条件执行节点以及不满足条件执行节点的识别。具体完成步骤就是:在匹配到condition Template时, 自动创建一个condition Node类型节点, 代表该任务分配项执行时必须满足的条件;如果继续读到的是一个direct Allocation Template内容, 则为该conditionNode节点生成一个Terminal Node类型, 并将其定义为conditionNode节点的左孩子。如果匹配到的是一个condition AllocationTemplate, 则继续分析condition Allocation中的conditon Template部分, 并为其条件内容部分创建一个新的condition Node节点, 该节点定义为上一condition Node的左孩子;如果是在else ExecuteTemplate中匹配到condition Allocation Template, 则将为其condition Template的内容创建一个condition Node节点, 而该conditionNode节点为上一condition Node的右孩子;如此匹配直到将“如果”、“则”、“否则”匹配完毕, 并激发convertRule Tree方法。该方法主要完成基于condition Allocation Template生成的规则条件树到Drools规则的转换。具体方法是遍历到该规则条件树的节点直到遇到Teminal Node节点则回退, 并将该过程遍历到的condtion Node节点condition Template信息与其父condition Node节点中的conditon Template信息连接到Drools规则中的WHEN部分;将Terminal Node节点中direct Allocation Template的分配信息映射到Drools规则THEN部分。在回退过程中需要区分相应condition Node节点是其父condition Node节点的左孩子还是右孩子, 如果是左孩子, 则条件直接连接, 否则需要补充“not”关键词。

3.2.2 完成各规则元模板中处理的汉语描述到Java对象方法的转换

将通过结构转换获取的规则字符串变量rule中规则名称、condition、produce内容等分别进行处理。如condition中流程变量条件判断模板的内容转换为方法compare Variable (op1, op2, op3) 调用, 其中op1、op2、op3分别为相应模板三个需要用户填写或输入的内容。将produce中“分配给流程所属机构的职位”元模板汉语描述转换为对方法assign Work By Position (op1) 的调用, 其中op1为具体职位信息, 以此类推。

最终该面向业务的工作流任务分派逻辑转换的Drools规则内容如下:

3.3 规则引擎执行部分

规则引擎执行部分主要负责将经过解析与转换得到的基于DRL描述的工作流任务分派规则加载进来, 并根据实际业务流程产生的事实对象输入来完成任务分派规则的选择与执行。以上基于DRL描述的工作流任务分派规则在Drools规则引擎执行过程中会自动生成如图5所示的节点树, 以便加快匹配速度。

通过在规则引擎Drools前端引入ANTLR, 并利用ANTLR完成对面向业务人员提供的工作流任务分派规则元模板以及工作流任务分派规则模板的解析, 完成面向业务的工作流任务分派逻辑到Drools逻辑的转换, 最终由Drools在实际业务的驱动下完成与相应事实匹配的规则选择与执行。在未将ADF框架应用到某银行的工作流任务分派系统中之前, 相应银行信用审批流程中某审批条款的修改或增加需要由银行业务部在获得规则修改许可后向维护该审批系统的人员提出申请, 由维护人员与审批系统的开发单位进行协商, 然后由审批系统开发单位组织人员进行相应规则的Drools修改, 并做内部测试, 然后提交该银行审批系统维护人员共同测试, 通过后再在实际审批系统中应用。由此导致相应逻辑维护流程异常复杂, 需要在多个部门与人员之间进行沟通、设计、实践与测试;一条审批规则的修改大概需要经历6~12个月的时间才能修改维护成功, 大大降低了相应银行对政府政策以及市场需要的响应速度。ADF框架在相应银行信用审批系统的应用将规则维护任务完全交由银行业务部, 而审批系统的开发单位只需要维护规则模板ANTLR词法与语法的解析与转换。虽然最开始由于对ANTLR规则模板的解析与转换需要耗费大量的人力与物力来建设, 但是一旦建设成功后, 后期的维护成本大大降低, 后期的审批规则修改周期降低到1~2周, 使得相应任务分配系统的工作效率与质量得到大大提升。

4 结语

随着应用系统对于逻辑定义与维护要求的不断提升, 规则引擎将在企业应用系统中得到更广泛的应用。基于ADF框架开发的业务规则系统既充分利用了现有规则引擎Drools在规则选择、执行上的优势, 又通过ANTLR的引入可以将对面向业务的逻辑维护交由业务人员直接处理, 由此可以大大提升应用系统对规则的维护能力, 维护成本大大降低。通过利用ANTLR实现自然世界逻辑描述到计算机世界逻辑描述的部分自动转换, 为自然世界到计算机世界转换的广泛应用打下了坚实的基础, 也使得相应行业的规则识别与执行提升到一个新的高度。

摘要：针对Drools只能解析与执行由专业人员定义的业务逻辑问题, 提出基于语言解析程序ANTLR (Another Tool for Language Recognition) 的解决办法, 并给出相应改进后的开发框架ADF (ANTLR-Drools developing framework) 及其关键实施方法。业务人员可以利用ADF提供的领域规则元模板直接定义业务逻辑, 由基于ANTLR的元模板解析程序完成相应业务逻辑到Drools逻辑的转换。事实证明该框架的可行性和有效性。

关键词：Drools ANTLR ADF,领域规则元模板,元模板解析程序

参考文献

[1]王伟辉, 耿国华, 周明全.规则软件系统模式匹配算法研究综述[J].小型微型计算机系统, 2012, 33 (5) :913-920.

[2]Drools Introduction and General User Guide[EB/OL]. (2013-7-8) .http://docs.jboss.org/drools/release/6.0.0.Beta5/droolsjbpm-introduction-docs/html.

[3]Drools Expert User Guide[EB/OL]. (2013-7-8) .http://docs.jboss.org/drools/release/6.0.0.Beta5/drools-expert-docs/pdf/drools-expert-docs.pdf.

[4]Terence Parr.The Definitive ANTLR4 Reference[M].The Pragmatic Bookshelf.Dellas, Texas, Ralegh, North Carolina.2013-1.

[5]邓伟.基于Drools的领域专用语言应用研究[J].电脑开发与应用, 2012, 25 (2) :8-11.

[6]赵彤洲, 王海晖, 马帅军, 等.基于规则引擎的面向企业服务管理系统的设计[J].湖北大学学报:自然科学版, 2010, 32 (3) :265-268.

[7]Mark Proctor.Drools:A Rule Engine for Complex Event Processing[C].International Symposium on Application of Graph Transformation with Industrial Relevance 4th.2011.

[8]Chai Young Jung, Katherine A Sward, Peter J Haug.Executing medical logic modules expressed in Arden ML, using Drools[J].Journal of the American Medical Informatics Association, 2012, 19 (4) :56-67.

[9]Zhanlin Ji, Damien Meere, Ivan Ganchev, et al.Implementation and Deployment of an Intelligent Framework for Utilization within an InfoStation Environment[J].Journal of software, 2012, 7 (5) .

业务流引擎 篇4

关键词：工作流管理系统,BPMN2, 0,Spring+Strut2+Hibernate,Activiti5

随着业务不断扩大和日益激烈的市场竞争, 公司对于售后管理部分的服务也越来越重视, 为了让公司的售后服务更加管理流程化, 便利化, 增强用户的满意程度, 进一步提升产品的市场竞争力, 特开发本系统, 实现售后管理业务的规范化、信息化。本系统包括:安装评估、调试参数设定、安装参数设定、故障登记、故障排查及处理、故障处理回访, 还包括故障处理知识库维护、故障问题库维护等业务, 售后服务的启动是从设备调试安装开始。如采用传统开发模式, 代码量大、冗余度多, 不便于测试、扩展和维护, 采用S2SH框架进行开发, 采用MVC设计模式, 实现了模型、视图、控制器的分离, 层次之间职责明确, 让业务逻辑层与持久层也进行独立, 倘若对数据进行更改, 那么不会对前端造成影响, 同样地, 也不管前端如何变化, 模型层只需很少的改动, 这样可以大大提高系统的复用性。最主要的是采用Activiti5 工作流技术对系统的流程进行管理, 降低了复杂流程应用开发和维护的难度, 有利于团队开发成员并行工作。

1 主要技术简介

1.1 Activiti5技术

Activiti5 的创始人是Tom Baeyens加入Alfresco后推出的基于JBPM4 的开源工作流系统, 它本身是一个业务流程管理 (BPM) 系统, 它是由Apache开源许可的BPMN 2.0 引擎开发出来的一种轻量级的可实现嵌入的BPM引擎。Activiti5 提供宽松的Apache开源许可, 这样有利于Activiti5 BPM引擎和BPMN 2.0相匹配。Activiti5 的目标是简化应用以及实现功能扩展, 从而提供更多更强大的业务功能, 它能支持的数据库有h2, My SQL, Oracle, Postgres, db2, Mssql等, 甚至可以部署到任意的应用服务器上。Activiti5 的体系结构由Modeling, Runtime, Management这三种组件构成, 其中Modeling包括Activiti Modeler、Activiti Designer、Activiti Kickstart组成, Runtime中Activiti Engine是整个体系结构的核心部分, Management由Activiti Explorer和Activiti REST组成。 其中Activiti Modeler和Activiti Designer是两个模型设计工具, Activiti Modeler是面向业务人员, 遵循BPMN2.0 规范的图形化流程设计工具;另外一个Activiti Designer是面向开发人员的, 以Eclipse的插件形式存在, 开发人员可以根据系统的流程需要来制定流程。最后Activiti5 的比较核心的部分是BPMN2.0 流程引擎, BPMN2.0 流程引擎具有快速、容易集成Spring等诸多优势。

1.2 BPMN2.0规范

BPMN2.0 规范的最终版本是OMG (The Object Management Group, 对象管理组织) 于2011 年1 月发布, BPMN是用来设计业务流程图的, 其实就是一个业务流程图的编辑工具, BPMN2.0 相对于BPMN1.0 规范以及XPDL、BPML及BPEL等最显著的不同点在于它定义了业务流程的符号以及模型, 并且为流程制定了转换格式, 这样可以使复杂的业务流程简单化, 对流程进行可视化管理, 这样业务的设计分析人员在不依赖与业务开发人员的情况下就可以独立地对流程进行设计和管理。BPMN2.0对流程执行语义定义了三类基本要素, 它们分别为Activities (活动) 、Gateways (网关) 、Events (事件) 。Activities (活动) , 从宽泛的角度来说, 凡是在工作流中有一定的生命周期的都可以称之为“活动”, 通常用圆角矩形这样的符号来表示活动, 任务 (Task) 和子流程 (Sub-Process) 是依据活动类型的不同二划分的, 它们都属于活动;用菱形符号来表示Gateways (网关) , 从字面意思来看, 所谓“网关”就是用来决定流程分支流向的一个关卡, 有Parallel Gateway ( 并行网关) 、Exclusive Gateway ( 排它网关) 、Inclusive Gateway (包容型网关) , 用网关可以对流程的执行要么进行进行要么选择性地排它执行;Events (事件) 用圆圈表示, 按照种类分为开始事件, 中间事件, 结束事件, 在BPMN2.0 执行语义中也是一个非常重要的概。总而言之, BPMN2.0 规范是通过定义了XML规范, 在语法上对流程描述文件进行定义, 这样使得流程文件应用更加广泛, 针对目前各个领域的业务需求, 在业务功能上提供了能够解决不同问题的工作流种类。

1.3 S2SH框架

S2SH框架, 就是将Strut2、Spring、Hibernate这几种技术整合而成的一种集成技术, Spring在S2SH占据核心地位, 它不仅可以整合Spring和Strut2, 而且还能整合Spring和Hibernate, 第一种整合可以看作为向上整合, 第二种整合可以看作向下整合。由此, 整个S2SH框架就是这样被Spring为核心整合在了一块, 这样的整合降低了各层之间的的耦合性, 即松散性增大, 进而可以提高程序的灵活性、可扩展性和可维护性。

Strut2 是在Web Work2 的基础上演变发展起来的, 它的设计是是一种无侵入式的设计, 采用拦截器对用户提交的一些请求就行处理, 在配置文件web.xml中一般情况下首先要注册其核心拦截器;Spring是一个主要有两部分组成的开源框架, 即控制反转 ( Inversion of Control, IOC) 和面向切片编程 (Aspect-Oriented Programming) 。Java Bean的生命周期就是由它来进行管理的, 另外也可以单独地使用Spring框架;Hibernate是一个ORM (Object Relation Mapping) 框架, 其中O是对对象进行操作的, R是关系数据库, M是有关对象关系的映射文件, Hibernate的最重要的核心功能是使数据库和程序中的Dao层建立关系, 然后封装JDBC的操作步骤, 可以简化对数据库的操作, 更加得方便快捷。将这三个框架整合在一起后, 可以明显地体现出了MVC设计模式的思想, 不仅减轻了IT开发人员的开发负担, 也大大缩短了开发周期。S2SH也是现在Web开发的主流框架, 大部分的公司都采用这种开发框架, 对系统也可以进行很方便的扩展。S2SH框架的优点众多, 但它也是这三个大框架的整合使用, 对调试过程的难度也相对来说加大了不少。

2 基于Activiti55的售后业务信息系统结构

2.1 系统整体架构

系统采用B/S结构, 使用Eclipse IDE作为本系统的开发平台, 运用Strut2、Spring、Hibernate组合的Web框架, 采用j Query等开发技术, 同时将Activiti5 引擎整合到S2SH框架中。采用MVC设计模式, 这样降低层与层之间的联系, 使系统的耦合度降低, 增强代码的复用性, 便于开发人员对后期功能的。 的扩展和维护。系统总体结构如图1 所示。

2.2 系统设计的四层架构

Activiti5 技术主要是针对以Java EE为框架的这种多层结构的系统, 然后对其中间层部分进行改进, 将业务逻辑层独立为单独的一个层, 把业务流程层嵌入到数据持久层和业务逻辑层间的中间, 这样会有两个突出的优点:其一, 业务流程层是独立的一个层, 方便设计分析人员对工作流流程进行设计;其二, 当业务需要变更, 或者动态变化时, 其他的层次操作都不会收到影响。

本系统采用的四层架构, 分别有用户表示层, 业务逻辑层, 业务流程层, 数据持久层。其中表示层, 主要的功能是依据用户的请求进行页面跳转以及用户访问接口的实现, 采用的设计模式是MVC模式, 即模型 (model) —视图 (view) —控制器 (controller) , 降低了图1:系统的总体架构图系统的耦合性, 可以把代码复用最大化, 便于后期平台的扩展和维护。业务逻辑层的主要功能就是提供访问接口, 它提供两个接口, 一个是业务逻辑层接口, 另外一个就是数据持久层的访问接口, 来完成相关功能操作。业务流程层主要负责工作流中的活动管理和执行;数据持久层主要是负责相关数据的抽象化, 可以完成对象映射等功能操作。

3 基于Activiti55的售后业务信息系统的实现

3.1 工作流数据库设计

Activiti数据库中表的命名方式都是以ACT_ 开始的。紧接着的部分是一个用例表的前两个字母来标识。此用例大体与服务API是匹配的。

ACT_RE_*:’RE’表示repository。带有这样前缀的表里面的内容是一些静态信息, 如, 流程的定义以及流程的资源 (图片, 规则等) 。

ACT_RU_*:’RU’表示runtime。带有这样前缀的表所表示的是存储的是运行时的流程变量, 比如用户任务, 变量, 等运行时的数据。实际上Activiti5 存储的只是实例执行时的运行时数据, 当流程实例结束时, 将把这些记录删除。从而保证了这些运行时的表小并且速度快。

ACT_ID_*:’ID’表示identity。带有这样前缀的表存储的是一些标识的信息, 如用户, 用户组, 等等。

ACT_HI_*:’HI’表示history。带有这样前缀的表所包含着的是一些历史的相关数据, 如结束的流程实例, 变量, 任务, 等等。

ACT_GE_*: 带有这样前缀的表就是很普通数据, 在各种情况都可能使用到的数据。

配置Process Engine Confi guration对象, 主要定义数据库的连接配置和建表策略, 配置文件码, 主要代码如下:<beans xmlns="http://www.springframework.org/schema/beans"

3.2 工作流程图设计

该系统的业务流程图采用的是Activiti5Modeler工具进行绘制的;这样业务流程以图形化的方式呈现出来, 而且绘制过程完全符合BPMN2.0 规范的流程定义文件, 图2 所示为本系统中某任务的流程图。

使用Activiti5 Modeler绘制流程图后, 它会自动生成相应的BPMN2。0 代码, 上述工作流程图的关键代码片段如图3 所示。

4 结语

本文通过对Activiti5 的集成应用进行了探讨, 采用当前开源领域最流行的Activiti5引擎为研究对象, 整合了Struts2、Spring、Hibernate三大集成框架, 将用户界面、业务逻辑和数据访问分离开来, 并在实际的具体的企业应用中整合Activiti5, 让流程业务系统的耦合降低, 系统的结构清晰, 管理分工明确, 增加了业务流程管理的便捷话和易操作化性。以公司的售后业务流程为例, 给出了流程图的设计和部分的配置信息, 其中业务流程的严格按照Activiti5 标准, 与传统开发相比, 可以使业务人员独立进行流程设计, 提高了业务流程需求变化时的响应速度和管理, 让公司的信息化应用水平迈上以新的台阶。

参考文献

[1]王学伟.基于S2SH2和Fireflow工作流的办公自动化系统的设计与实现[D].武汉科技大学, 2011.

[2]曹伟.面向办公自动化的工作流引擎研究和设计[D].南京理工大学, 2013.

[3]郭伟锋.面向分布式工作流系统的Agent模型研究[D].昆明理工大学, 2013.

[4]葛扬瑛.基于java EE和工作流的项目申报系统的设计与实现[D].电子科技大学, 2013.

[5]吴志霞, 陈平.基于S2SH的在线项目管理平台的设计与实现[J].计算机与现代化, 2011, (8) :49-51, 189.

[6]贾松浩, 杨彩, 刘军.基于S2SH框架的个性化实验室管理系统[J].实验室研究与探索, 2014, (8) :232-235.

[7]范新灿, 赵明.基于Struts+Hibernate+Spring的轻量级架构开发应用研究[J].现代计算机 (专业版) , 2010, (1) :176-179.

[8]姜雷, 基于JAVA技术的实验室管理系统的设计与实现[D], 成都:电子科技大学, 2012.

业务流引擎 篇5

互联网和数据业务伊始, 网络带宽需求便无休增长, 近来更是每2~3年就翻倍。带宽激增的推手既有固网接入的“光进铜退”, 又有移动互联网的井喷;既有爆炸增长的视频业务, 也有云计算转型和大量数据中心的整合。国内运营商对这些促使因素了然于胸, 也明确知道自己需要合理的网络规划来满足带宽增长。他们已经开始加速演进传输网络的步伐, 从现在的10G和40G升级到100G, 满足人们对速率的热切需求。

阿尔卡特朗讯2012年推出的400G光业务引擎 (PSE) 中引入了软判决、超高速数模转换、滑码抑制和波长整型等多项新技术, 不但能直接支持200G/400G速率, 而且将100G的传送距离提升到3000公里, 并进一步降低了功耗 (30%) 和提高了系统的集成度 (30%) 。阿尔卡特朗讯不但继续引领100G市场, 而且开始实现100G+商用。

突破成本与容量的“零和博弈”

运营商对这些带宽增长因素既熟悉又头痛, 包括移动数据、视频流和社交媒体;移动设备、各种应用和互动性业务。为了满足每2~3年就会加倍的带宽需求, 他们不得不努力升级网络容量。虽然运营商可以不断扩容, 他们很清楚地认识到网络的扩展性有着自身的限制。运营商所面对的不仅仅是带宽的挑战——保证今天的网络能够处理现在和未来可以预见的带宽需求, 还有成本挑战——他们为了扩容网络所进行的大量投资与获得的回报并不一致。随着云业务的普遍化和要求的带宽越来越高, 这种成本与带宽“零和博弈”的影响变得更加深远, 需要传输网络为承载云业务做出相应的改变。运营商既需要保证他们的传输网络能够扩展带宽来满足带宽要求, 还要通过采用最具有经济性和灵活性的方式来实现回报最大化, 并通过减少电源消耗和设备空间来降低成本。

用未来的技术“武装”今天的网络

400G光业务引擎 (PSE) 既是阿尔卡特朗讯贝尔实验室的智慧结晶, 也是阿尔卡特朗讯总结大量相干光检测100G实际部署经验的实践成果。作为为1830 PSS光子业务交叉机特别研发的光电芯片, 400G光业务引擎可以根据运营商的要求以各种方式应用于实际组网中。当配置为支持100G时, 它不但通过优化性能把传输距离在没有任何电中继的情况下扩展50% (从2000公里到3000公里) , 还可以把功耗和体积减少30%。这样就允许运营商最大限度地利用各种光纤的频谱带宽, 并减少在速率和传输距离之间的妥协。当配置为支持200G/400G时, 它不但可以把光纤容量提升2.6倍, 还可以把功耗降低33%。

400G光业务引擎

一般情况下, 光电业务引擎决定了传输设备的速率、板卡密度、系统容量、功耗、传输距离和性能。在研发过程中, 400G光业务引擎 (PSE) 专注于最基本的网络属性:在保证1830 PSS光子业务交换机扩展性的同时增大每块板卡的带宽并降低功耗。

400G光业务引擎采用了超过100个阿尔卡特朗讯的专利技术, 它既包括新的调制方案, 也有更加高级的数据处理技术 (DSP) ;既有更快的数模转换模块, 也有新型的判决技术。高级的数据处理技术 (DSP) 能够支持波长整形, 从而提高光谱利用率并增强对非线性效应的忍耐能力。

当配置为支持200G时, 400G光业务引擎 (PSE) 可以保证1830 PSS光子业务交叉机支持88个50GHz的光波;当配置为支持400G时, 400G光业务引擎 (PSE) 可以保证1830 PSS光子业务交叉机支持44个100GHz的光波。这两种配置都与ITU的50GHz光谱间隔相兼容, 从而取消了额外部署灵活栅栏技术的必要性。

400G光业务引擎 (PSE) 同时支持BPSK, QPSK和16QAM的调制方案, 以及极具创新的解调方案。与一般芯片以固定或静态的方式解调信号不同, 400G光业务引擎 (PSE) 根据实际情况动态解调信号。通过软判决和更高的符合率, 400G光业务引擎能够大大提升传输速率, 提高信噪比, 并提供对非线性效应更好的容忍度。

在接收端, 400G光业务引擎既包含有强化的算法来对色散进行补偿, 也支持高级的滑码抑制技术。这样不但可以提升网络弹性和优化对突发性错误的恢复能力, 还可以在零代价的情况下消除相移效应。该引擎同时也能为色散提供预补偿, 从而提升对非线性效应的容忍度和传输距离。

通过对滤波器的配置, 400G光业务引擎 (PSE) 可以将光波调整为任意形状, 把传输100G的光谱带宽缩小到37.5GHz。这样以来光谱利用率就能够提升25%。在此基础上采用阿尔卡特朗讯的灵活栅栏技术能够把光纤的容量从8.8T提升到11.7T。如果采用200G或者400G技术, 光纤的容量能够从8.8T提升到23T!

面向未来的解决方案

带宽的需求从未停止。伴随着移动设备的普遍化、视频业务的流行化和社交网络的深入化, 人们对带宽的需求只会持续增加。这必将使得运营商在成本与容量的“零和博弈”中受到更大的挑战。

业务流引擎 篇6

1.1 搜索引擎营销的巨大市场

由于互联网信息的不断增长, 搜索引擎应运而生。搜索引擎成为越来越多互联网用户必不可少的工具, 它的出现使得消费者可以轻松地获取信息, 同时使企业有了新的向目标群体传递产品与服务信息的渠道。这种传统营销理论与搜索引擎有机结合而形成的搜索引擎营销。由于其巨大的商业价值成为了当代企业必不可少的一种重要营销手段。

1.2 现有搜索引擎营销存在的弊端

(1) 关键词单一。

关键词是企业搜索引擎优化的关键之一, 如今搜索引擎关键词单一的缺陷, 不仅不利于网民准确找到搜索目标, 而且也不利于企业在最短时间内推广自己的产品或服务, 无法获得更大的搜索引擎推广收益。

(2) 竞价排名更新速度。

通过竞价排名机制产生的搜索结果来自于不同企业在竞价排名上的投资多少, 相互竞争的企业, 会在竞价排名上展开激烈的角逐, 最终造成大量资金投入却得不到很好的回报的结果。

(3) 恶意点击。

由于搜索引擎提供的竞价排名结果和推广的广告链接对于企业一般都是按照点击收费, 所以就会出现一些企业的竞争对手进行恶意点击, 使其浪费巨大网络营销投入资金的情况。

1.3 选择百度为例的理由

百度作为全球最大的中文搜索引擎, 在国内拥有着76%的绝对市场占有率, 该数字即将在2010年末突破80%。国际市场方面, 从Strategy Analytics 2010第二季度的统计报告中可以看到, 百度的全球市场份额从上季度的3.2%大幅增长到4.6%, 对比去年同期上涨76%, 与微软的Bing已只有0.2%之差。

国内国际两大市场的不断扩张, 各种新型服务的陆续运营, 是我们本次以百度搜索引擎为研究对象的根本原因。

2 创新方案

2.1 方案灵感

搜索引擎公司的最主要的经济来源就是营销广告。Google、百度为首的搜索引擎主流商务模式都是在搜索结果页面放置广告, 或者通过特殊算法人工干预最终结果网页排名, 并根据这种营销广告的点击数收费。搜索引擎提供商如果想要获得更高的利润, 就要吸引更多的人使用自己的搜索引擎, 这就需要涉及到搜索引擎周边的创新型服务。

对于搜索引擎来说, 它的宗旨是让用户快捷地找到他们最想要的信息。除此之外, 一个搜索引擎的成功与否还在于是否可以通过技术的不断革新为搜索引擎用户带来更好的体验。这种体验渗透在搜索速度、准确性、排序以及对各种编码字符的支持等诸多因素之中, 当然也体现在这个搜索引擎是否通过更好的个性化服务满足用户的各种需求, 牢牢把握住已有的用户群并并吸引更多的用户。

2.2 现有服务的完善

根据我们的调查, “百度知道”目前有以下几点不足:

(1) 知识产权不明晰。

由于网络作品复制、传播的速度极快, 发生侵权问题后很难区分谁是原作者, 而证明是原作者又是维护知识产权所有者权利中最重要的一环, 这样原作者的作品在发生侵权后很难收集有效证据来维护其知识产权。

(2) 问题及回答的重复率较高。

用户为了通过提问获取更多积分, 很少关注是否已存在类似问题, 在一定程度上使得问题的重复率较高。

对于完善“百度知道”, 我们有以下几点建议:

①加强知识产权保护。

百度知道的知识产权保护主要可从三个方面入手。一是提供完善的用户注册界面要求提供详实的资料, 以便在维权时更好地证明自己是原作者, 从而维护好网络著作权。或根据国家版权局《作品自愿登记试行办法》的规定, 在作品公开发表前, 可以向版权局进行登记, 在作品被侵权后就可以按照登记确认作者, 追究侵权者的责任。二是用户通过注明转引文献附加网页链接等方式来保护网络知识产权。三是通过设立保护知识产权举报投诉服务中心, 方便用户在线举报投诉, 形成良好的保护知识产权的氛围。

②降低问题及答案的重复率。

在用户的提问界面中, “百度知道”应对用户所提问题与已存在的问题进行匹配, 当相似度较高甚至相同时, 应自动的拒绝用户的提问请求, 并引导用户至已解决的类似问题的页面, 达到在降低问题重复率的同时, 与用户进行了较为友好的交互。对于回答问题的重复率较高的问题, “百度知道”可以通过建立用户举报、管理员监督等机制来减少此类问题。

2.3 创新方案

2.31 为特定人群提供专门网站

(1) 以青少年为市场主体的个性化搜索。

①平衡网站建设。

在保留百度原有的“个性化设置”的所有内容外, 可再加上虚拟社区等交互手段, 从而促进这些特殊人群之间的信息交流。设计简洁的检索界面, 提供自然语言检索方式, 提供强大的容错检索机制容错性 (即在青少年及老年人检索信息时若犯拼写错误可以进行自动检查或者提供帮助) , 以此方便他们迅速、准确地查询信息, 满足信息需求。

同时不断地对个性化服务进行完善和创新, 比如可允许儿童用户创建个人的网络虚拟形象, 让他们通过设计搭配为自己的虚拟形象进行打扮, 不仅可以提高儿童对于色彩、审美、创造方面的能力, 还可以使得儿童对于该搜索引擎产生强烈的好感。

在网站组织方面, 网站栏目内容设置上应以游戏、学习、动漫为主。在网站信息内容方面, 由于儿童理解信息的方式与成人有着很大的不同, 具有阶段性、形象性、好奇性等等, 因此应该强调健康、积极、有趣味的信息内容, 打造青少年儿童的网上精神乐园。

②加强网站设计的引导化。

百度的附加网站还要在一定程度上具备一定的教育性, 这样才更能吸引家长并得到家长的认同, 从而在“家长圈”中打开知名度, 提升档次, 区别于普通的搜索引擎。

考虑到儿童爱玩的天性, 我们将娱乐与教育融为一体, 倡导“以用户为中心”。在网站形式上、内容上应做到生动活泼, 合理地将游戏融入到网站的各个部分中, 让孩子们在放松心情的同时, 进行了学习、接受了教育, 也培养了他们对于百度附加网站的好感度, 一举多得。

③加强与图书馆的合作。

百度附加网站是提供一青少年儿童为主要目标受众的, 涵盖青少年儿童信息类、教育类、休闲娱乐类等综合网站, 图书馆是为社会提供系统文献信息服务的社会文化教育机构。图书馆在青少年儿童的教育应道方面、在信息资源的广度、深度方面的特点更为突出。另外, 百度与图书馆的合作不仅能提供青少年儿童需要的信息, 还能满足社会各界人士对知识的渴求, 而且大大提高了百度搜索信息的权威性。另外, 百度还可以结合3D技术, 推出3D图书馆 (后文将会重点阐述) 服务, 增强信息的可读性和可理解性。

(2) 以老年人为主的个性化搜索。

老年人相对于青少年、中年人来说, 有其特殊的需求。因此针对于老年人这个特殊的用户群体, 百度推出了相关的“老年搜索”。其特点为字体大而清晰、色调舒适明亮、内容也相对应地根据老年人的需求而定。针对老年人打字困难的这一状况, 还特地在搜索栏处增加了手写功能, 使老年人能够更快捷更方便的搜索信息。这样的一个特色搜索服务, 体现了百度“以人为本”的服务理念, 不仅赢得了可观的用户群体, 更赢得了广大网民的良好口碑, 提升了其自身的品牌价值。

2.3.2 虚拟3D服务

(1) 虚拟都市。

百度可以把3D虚拟现实覆盖的范围逐步扩大, 逐渐覆盖个大型城市, 提供 “虚拟城市游览”的功能。

这一服务可以理解为更具实用性的地图服务, 例如:很有旅客因为对景点的不了解而盲目旅游, 造成了旅游不愉快;更有一部分人因为工作等原因很少有机会出去旅游而造成遗憾。3D景点旅游就能够很好的解决这个问题。似于“网上世博会”的模式, 可以通过图文、照片、视频以及真实的3D建模等方式全方位立体式地介绍景点。既可以让旅游者在出门旅游之前选择自己喜爱的景点, 也可以在一定程度上弥补不能出门旅游者的遗憾。

最重要的商机在于, 百度可以通过把现实中存在的真实店面投射在虚拟的3D世界中, 为想要参与的企业提供最新颖的营销方式体验。

(2) 3D图书馆。

这一技术还可以与现有的“百度文库”相结合。创建3D虚拟图书馆, 给网民带来更有趣的阅读体验。建立虚拟的3D图书馆, 能够足不出户就感受浓浓的书卷气息, 在无广告、无干扰的情况下获取知识、信息, 对用户来说会是一种全新的体验。

3D化搜索引擎不仅提供了一个全新的搜索方式, 更拉近了搜索引擎用户与世界的距离, 足不出户就能面对面地感受世界, 获得更多的感官互动体验。通过相关服务的开发和不断的完善, 必将更能迎合市场的需求, 取得更大的用户群和更加好的口碑。

2.3.3 其他更多人性化设置

(1) 关键字自动选择 (人性化推荐功能) 。

联系到现在最流行的搜狗输入法, 在安装过程完成之后会进行一个用户所感兴趣的关键词设置, 以便根据用户选择的类别在更新的时候增加相应的词条, 方便用户输入。由此联想到百度可以施行类似措施方便用户查询资料。如百度将所有的数据库分类为不同领域, 并增加一个用户注册搜索功能, 即特定人群可通过注册专属用户名的同时选定自己关注或者感兴趣的领域, 当需要特定领域的知识搜索时, 用户可选择登陆搜索的方式, 那么输入关键词搜索出来的所有内容即是该领域的所有知识, 更加方便信息的查找和读取。

(2) 提供更多的专业化、特色化搜索 (人性化推荐功能) 。

前些年, 博客开始成为网络上的一个新兴产业。针对这一区域, 百度开发了博客搜索引擎, 使信息搜索的领域扩大化。

众所周知, 大部分网页都是以Web版式视图给网友提供文字信息, 但是还有很多相关网页为PDF电子文件的格式浏览, 目前搜索领域的PDF搜索杂而片面, 没有一个完完全全让用户满意的PDF搜索引擎, 也就使得很多有价值的PDF资料没有真正的被搜索人利用。鉴于百度作为目前国内最强大的搜索引擎公司, 具有最全面的数据库系统, 完全可以推出一款适合中国网民的PDF搜索引擎, 想必能够得到普遍的使用和广大的好评。

(3) 信息语音播报 (人性化推荐功能) 。

百度可以将语音播报模式与网页信息结合, 即开发相关功能, 使客户能够随时随地从听觉上获得信息。如每天使用百度, 都会获得很多国内外新鲜资讯, 选择感兴趣的内容, 然后使用语音播报功能, 就能如同听广播一样从听觉上获得信息了。

3 结语

在Web2.0时代的今天, 搜索引擎已成为用户最喜爱的网络信息采集渠道, 这使得搜索引擎营销越来越受到企业的重视, 这也就是本小组研究搜索引擎营销价值的分析及业务模式创新的直接目的。

本小组在对调查结果进行了深入的分析, 解释了当今搜索引擎的价值之所在, 并以目前国内最大的搜索引擎——百度为例, 全面评析了百度现有的服务优点与缺陷, 在全小组的集体努力下针对其缺陷与用户的需要提出了兼具创造力与可行性的创新方案, 旨在建立更加优化、更加创新的搜索引擎, 让搜索引擎更加方便的服务于大众, 同时也让搜索引擎公司取得更加良好的口碑和更加丰厚的收入。

参考文献

[1]吴海莉.企业实施搜索引擎营销存在的问题及对策分析[J].现代商业, 2009.

[2]熊莉, 谢园.百度:营销决策知而后行[J].成功营销, 2010, (5) .

[3]李莎.搜索引擎及搜索引擎广告现状研究[J].广告大观理论版, 2006, (3) .