近年来，随着互联网技术的高速发展以及在各类企业系统中基于Web的应用被广泛接受。SaaS吸引了越来越多工业界和学术界的目光。SaaS作为企业获得软件服务的一种新形式，使得企业无须在自己的电脑和服务器上安装软件，而是按某种服务水平协议(SLA)直接通过网络向专门的提供商获取自己所需要的、带有相应软件功能的服务，按需使用，按需付费。这种模式使得SaaS得以支持多个企业租户同时运行同一个软件实例，使用同一个数据库，从而可以通过规模经济来降低开发和维护的成本。从企业的角度来看．SaaS应用不需要对软件进行安装、部署以及维护，而且能够根据企业的运营现状来动态增加或减少一些服务，按需使用SaaS软件的服务，这使得企业能够低成本地使用SaaS软件。SaaS由于投入低、收益高、易于实施和管理、应用风险低等优点，为中小企业信息化的发展注入了新的力量。据ICT领域权威机构计世资讯(CCW research)在其最新发布的《软件业下一个十年——中国软件运营服务(SaaS)市场发展趋势研究报告》中指出，2006年中国SaaS产业的规模为68亿元，2011年将突破400亿元，未来5年的复合增长率将达到43％。
SaaS采用了多租户的架构，这对SaaS应用的开发技术和方法提出了新的挑战，其中可定制性即为关键问题之一。SaaS应用一般都力图设计成通用的软件，以便能为尽可能多的租户提供软件服务。由于存在行业专注、客户行为、供应产品、规章制度、运营策略、文化传统等差异，许多租户仍然有自己独特的业务需求。由于SaaS支持多个租户运行同一软件实例，应用提供商无法通过为每一个租户开发并维护一个代码版本来满足租户的独特需求。这就需要SaaS应用允许租户对软件的业务逻辑进行在线定制。
1 相关工作
软件的业务逻辑定制技术并不是一个全新的课题，国内外学者在面向传统应用的业务逻辑定制技术方面有不少研究成果，而且有些方法已经被工业界采用了。
参数设置是业界常用的业务逻辑定制方法之一。所谓参数设置，是指通过表格、XML、Wizard等方式来设置个性化参数，满足用户个性化需求。这种方法虽然实现起来很方便，但定制能力十分受限，很难达到灵活定义业务逻辑的目的。
流程可视化建模是工作流系统中采用较多的业务逻辑定制解决方案，但是流程在运行时的动态修改比较困难，即如何将运行中的流程实例迁移到新的流程模型中，以及如何在流程定义不完整的情况下进行运行比较困难，而且无法支持非流向型的业务逻辑的定制。
可变性建模是人们从制造业流行的大规模定制中得到启发进而提出的一种业务逻辑定制解决方案。用户可以按照自己的实际需求对可变点进行建模，然后以一定的方式对可变点进行组合从而达到定制的目的。该方法由于是确定性建模，模型建好后就很难扩展，对用户之后的一些个性化需求将难以满足。
在人工智能领域中，规则是用来构建基于知识系统的最常用选择。这就是所谓的业务规则方法。这种方法提供了一种灵活的业务逻辑定制模式。Nalepa等人针对业务流程建模中的业务规则设计问题提出了一种基于XTT的方法，XTT采用形式化的语言来描述业务规则，这使得业务规则便于验证。但是，这种方法对于用户来说操作很困难，因为它们可能缺乏数学基础，难以编写出业务规则。
对于SaaS应用来说，它与传统软件的业务逻辑定制仍存在不少差别，这些差别包括：a)SaaS应用的业务逻辑定制需要支持多租户。每个租户有着自己不同的定制，而传统软件在整个软件系统中只需要一份定制。b)SaaS应用的定制操作不是在系统运行前定制，而是要能够在系统运行过程中动态执行，从而能够根据需求的变化随时作出相应的定制，而且定制时不能把系统暂停下来，以免影响其他租户。c)在SaaS中，大多数定制操作由租户的管理员来执行，而不是由软件供应商的开发人员来配置，这要求定制操作简单易懂。
Salesforee是采用SaaS模式的先驱者之一。它提供了两种选择来定制业务逻辑，即点击式配置和基于代码的配置。前者提供了一些简单的点击式向导以供租户定制自己的业务逻辑，这种方式对于定制内容有很大的局限性；后者提供了一种名为Apex的编程语言来供租户定制复杂的业务逻辑，这种方法很灵活但是复杂性高，需要开发人员来定制，不太适合没有或很少有编程经验的租户。
也有学者提出了定制框架来支持面向SaaS应用的业务逻辑定制。此框架通过定义服务并且在运行时依据规则动态地修改、替换服务从而达到定制业务逻辑的目的。它采用了SOA的架构。比较适合于基于Internet系统之间的松散集成，对于紧密集成的单个系统，因性能问题，并不是很适合。
2 业务规则模板
SaaS应用的业务逻辑定制必须由租户在线定制，而租户可能没有或有很少编程能力，所以面向SaaS应用的业务逻辑定制须尽可能简单。而业务规则模板的方法具有很好的灵活性和易用性，比较适合SaaS应用。因此，笔者考虑采用此方法来使得租户可以方便地定制符合自己需求的业务逻辑。
在不同的领域中，业务规则的表述形式也不尽相同。所以，设计一种针对所有领域的通用的业务规则模板几乎是不可能的。本文采用了领域工程的方法针对一个特定领域来设计业务规则模板。
设计业务规则模板的步骤如下：
a)采用领域工程的方法，识别此领域中与业务逻辑相关的所有的共性和可变性。并建立领域分析模型。
b)对可变性进行分析，建立领域设计模型，并识别出与业务逻辑相关的核心业务对象及其属性。
C)对可变性中存在的共同形式进行抽象，然后以结构化的自然语言表述出来，形成业务规则模板。
对于业务规则模板的格式，笔者参考了ECA(event-condition-action)规则的表述形式。ECA采用了“ON some event if some condition then some actions”的格式，业务规则由事件、条件和动作三部分组成。为了便于所提出的业务逻辑定制框架中的规则翻译器将租户定义的业务逻辑转换成规则引擎可以识别的格式，将事件部分也归入到条件部分中，即将事件也看做是一种条件。
本文设计的业务规则模板包含两种类型，即条件模板和动作模板。条件模板描述了期望或不期望的约束；动作模板则表示当条件满足时会触发什么样的动作。这些条件模板和动作模板可以分别组合起来以表示复杂的条件与动作。将条件部分与动作部分组合则可以表示一条业务规则。
3 框架的架构
通过采用业务规则模板的方法，本文设计和实现了一个灵活的适合SaaS应用的业务逻辑定制框架。框架的架构如图1所示。
图1 面向SaaS应用的业务逻辑定制框架架构
从图1中可以看出，架构共包括七个构件：可视化规则定义器、规则翻译器、业务对象表、规则引擎、验证引擎、规则文件库以及数据库。根据此框架，业务逻辑的定制流程可以分为以下几步：
a)业务规则定义。通过可视化规则定义器，其提供了一些预先设计的结构化自然语言描述的业务规则模板，租户可以从这些模板中选择他们所需要的，并将模板内容填写完整然后进行自由组合。与此同时，系统会自动将租户定义的业务逻辑中相关的业务对象加入到租户的业务对象表中。
b)业务规则格式转换。在业务规则被定义好之后，它将会被送入到规则翻译器中。规则翻译器会按照预先定义好的转换规则自动将业务规则的条件部分和动作部分转换成规则引擎可以识别的格式。
C)业务规则验证。系统将规则名称、规则属性以及转换后的规则的条件和动作部分组合起来以形成完整的业务规则并加入到验证引擎中。验证引擎会对租户定义的所有的业务规则进行冗余性、循环依赖性及不一致性等语义错误进行检测。
d)业务规则存储。经验证成功的业务规则会加入到规则文件库中租户的规则文件中。为了便于规则的查询修改，将业务规则的各个部分如规则名称、规则属性、规则条件、规则动作等存储到数据库中。
e)业务规则执行。当一个租户登录进系统后，系统会将此租户的规则文件装载到规则引擎的规则库中以供规则引擎使用。当系统运行至规则引擎调用点时，系统将会首先检查租户的业务对象表来决定是否调用规则引擎。如果与当前调用点相关的业务对象存在于租户的业务对象表中，系统将会调用规则引擎以执行租户定义的业务逻辑，否则将不会调用。
在此框架中，之所以为每个租户配备了一个业务对象表，是因为每个租户都有其特定的需求，这将会导致租户可能需要定义大茸的业务逻辑。大量的业务逻辑可能会涉及到大量的业务对象。这就意味着在一个SaaS应用中，会预先设置大量的规则引擎调用点。对于某些租户来说，很多的调用点不是他们所需要的，这些多余调用点的存在会降低系统的性能，因此为每个租户配备了一个业务对象表。当租户定义业务逻辑时，与业务逻辑相关的业务对象将会被加入到租户的业务对象表中。如果系统需要调用规则引擎，它会首先检查租户的业务对象表；如果与当前调用点相关的业务对象存在于租户的业务对象表中，系统将会调用规则引擎，否则将不会调用。通过此种方法，系统的性能得到了优化。
此框架通过采用基于领域工程的业务规则模板的方法，与现有的业务逻辑定制方法相比，具有如下优点：a)可定制内容丰富。采用领域工程的方法，对某一领域内的可变点进行建模，基本覆盖了租户对于可变性的需求。b)定制操作简单。提供了大量的自然语言描述的业务规则模板，租户无须自己去编写复杂的业务逻辑，只需要选择符合自己需要的模板，并将模板内容补充完整即完成了一条业务逻辑的定制。c)错误发生概率低。由于采用规则模板的方式来定义业务逻辑，很大程度上可以避免业务逻辑语法错误的发生。
4 框架的实现
4.1 建立领域模型
本文选择了三个绩效考核系统来分析它们的共性和可变性：两个离岸产品和笔者为中石化东北化工销售公司大庆分公司开发的系统。一些领域专家也参与了整个领域建模的过程。遵循基于特征的领域分析方法，建立了绩效考核领域的领域分析模型。部分的领域分析模型如图2所示。
在图2中，没有圆圈的方框代表绩效考核领域的共性，而含有圆圈的方框代表可变性。含有圆圈的方框又可以分为两类，即可选的功能和业务逻辑约束。带有箭头的虚线表示依赖关系。可选功能是功能定制中所需考虑的问题，本文不作研究，只关注业务逻辑约束和依赖关系。
当领域分析模型建立好之后，会识别其中核心的业务对象并建立领域设计模型。部分的领域设计模型如图3所示。如“指标数目约束”中，识别出的相关业务对象是考核模板，相关的属性是指标数目。这些业务对象及其属性将会被提供给租户以供定制时使用。
图2 部分绩效考核领域分析模型
图3 部分绩效考核
4.2 基于领域的业务规则模板
通过对业务逻辑约束的分析，可以发现这些业务逻辑约束条件部分和动作部分都各自有着相似之处。对这些相似之处进行抽象然后以结构化的自然语寿表述出来，就形成了业务规则模板。对于依赖关系，也可以这样做。
例如，模板创建功能中包含这样一条业务逻辑：如果考核模板中的指标数目少于4，那么系统将会提示模板不可用。计分管理功能中包含这样一条业务逻辑：如果考核任务中实际完成任务与预先分配任务的百分比大于120％，那么此项指标得分加10分。从这两条业务逻辑约束中可以发现，它们的条件部分均符合这样的格式：一个业务对象的属性满足特定的值。因此，对这两条业务逻辑约束的条件部分进行抽象，然后以结构化的自然语言表示出来就形成了这样一条业务规则条件模板：(业务对象)的(属性)满足(操作符)(值)。同理，动作模板的设计也是如此。
分析所有的业务逻辑可变性后，本文设计的业务规则模板如表1所示。
表1 业务规则模板
模板内括号中的内容表示需要租户去选择或者填写。定义了八种类型的内容，它们分别是业务对象、属性、操作符、值、操作、信息、用户名以及邮件地址。在这些类型中。业务对象、属性以及操作的内容预先提供．租户只需要按照各自的需求选择他们所需要的，而其他内容则需要租户自己填写。
在这些条件模板中，本文设计了一个模板来表示定量的时间信息。然而这个模板不能转换成规则引擎可以识别的格式，需要由自己来处理这种形式的条件。为了解决这个问题，在应用中定义了一个时钟调度函数。
为了能够处理规则引擎的工作内存中的业务对象，本文设计了另外三个动作模板：a)插入(业务对象)；b)撤销(业务对象)；c)更新(业务对象)。它们均与业务逻辑不相关。
4.3 定制业务逻辑
采用可视化的规则定义器，如图4所示，用户可以通过选择和填写业务规则模板方便地定制出其所需要的业务逻辑。
图4 可视化规则定义器
用户可以通过填写规则名称和规则描述，设置规则的优先级以及选择合适的模板来定制符合他们需求的业务逻辑。通过这种方法，用户不需要具有编程知识，只需要了解企业的业务逻辑即可。这种定制方法使得业务逻辑的定制变得简单方便，而且杜绝了业务逻辑的语法错误。
4.4 转换和验证业务逻辑
当一条业务逻辑被定义好之后，它将会被送入到规则翻译器中。规则翻译器会自动将业务规则的条件部分和动作部分转换成规则引擎可以识别的格式。例如，租户自定义的一条业务规则的条件部分是“(考核轮次)的(考核状态)满足(=)(已开始)”，由于在实验中采用的规则引擎为JBoss旗下的Drools，转换后的Drools可以识别的格式为“Appraisalround(appraisalState==“已开始”)”。当业务规则的条件部分和动作部分被转换好之后，将规则名称、属性、优先级以及转换后的条件和动作部分组成完整规则的形式加入到验证引擎中进行验证。因为采用了业务规则模板的方法，所以可以很大程度上杜绝业务逻辑本身的语法错误。验证引擎主要验证业务逻辑之间的语义错误，如冗余性、循环依赖性和不一致性等。如果验证成功，将会被加入到规则文件库中，否则返回规则定义界面重新编辑。
4.5 存储业务逻辑
经验证引擎验证通过的业务规则将会被加入规则文件库中租户的规则文件中以供规则引擎运行时使用。另外，为了便于租户对业务规则进行查询修改，在数据库中，笔者定义了businessrule表来存放规则的名称、描述及属性；定义了businessruleconditon表来存放规则的条件；定义了businessruleaction表来存放规则的动作。
5 结束语
随着互联网技术的飞速发展和SOA的逐渐成熟，SaaS正成为研究的重点。本文提出了一个适合SaaS应用的灵活的业务逻辑定制框架，并且考虑到了框架的易用性和性能。由于租户没有或很少有编程能力，采用了基于领域工程的业务规则模板的方法来表述业务逻辑，这将使得租户可以很方便地设计出符合其自身需求的业务逻辑，并杜绝了业务逻辑语法错误的发生。为了优化系统的性能，为每个租户配备了一个业务对象表。尽管已经尽了最大的努力，其提供的业务规则模板可能也不是那么完美。在未来的工作中，会考虑设计出新的业务规则模板，以使得现有的模板体系更加完备。