引言
近年来，随着互联网技术的高速发展以及在各类企业系统中基于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所示。