中文Business Rules Whitepaper_1.docVIP

BizTalk Server 2004业务规则工具 描述：本文探讨现行编程语言和方法在实现基于规则的复杂流程时存在的局限性，分析如何在BizTalk Server 2004中创建和部署业务规则“策略”，并展示使业务规则作为透明服务发挥作用的开发环境是如何真正提升企业灵活性的。 关键词：企业应用集成、业务流程自动化、面向服务的架构（ＳＯＡ）、BizTalk Server、XML、XML Schema,、Web 服务、业务规则 发布日期：２００４年１月 适用范围：Microsoft BizTalk Server 2004 介绍 业务规则指导着所有业务流程中的决策行为。业务规则就是一些条件标准，系统根据这些标准对所有的事实变量进行评估，从而决定恰当的业务操作。在传统的应用程序设计中，业务规则被编码为过程实现方法。在应用程序中嵌入业务规则往往会存在一定的问题，因为这样会降低应用程序的效率和灵活性，并最终对应用程序所支持的业务流程产生负面影响。这种开发方法的局限性和低效性在应用开发周期的每一阶段都很明显。 开发过程需要一个转换步骤，把在功能说明中详细阐述的规则逻辑转化为过程实现代码。规则包括业务事实、条件语句等。 规则逻辑一旦被转化为过程代码，其语义就不再为那些负责业务流程完整性的知识工作者和业务分析人员所知了。 将业务规则嵌入实现代码会使其与过程功能之间建立起一种不必要的相互依赖性。被嵌入的业务规则无法完全独立地发挥作用，从而使规则逻辑的建模、测试和修改变得十分复杂。 嵌入业务规则要求开发人员创建或实现一个推理引擎，对事实和规则进行匹配，并把复杂的规则集连接在一起。当事实被引入业务流程时，应用程序必须将规则条件与相关的事实进行匹配、评估，然后触发操作。假如事实不多且评估标准较为简单，其逻辑和所需的编程工作还不会太复杂。但是，假如有大量的事实且评估标准又很复杂，就会大幅增加所需的编程工作和逻辑复杂性。 大多数针对业务流程生命周期的修改都属于业务规则的修改（而不是技术方面的修改）。传统的应用程序将业务规则嵌入非透明的过程代码中，如果不中断正在运行的进程，就不能轻易地访问或修改这些规则。 尽管存在上述局限性，但是由于没有更好的方法，这种方法依然被广泛采用。直到最近，仍然没有一种程序开发环境，能够将业务规则与实现方法分离，保留规则的易理解性，并支持规则与其它功能的动态绑定。 编程语言的本质仍然是语法性、缩略性和过程性，而没有转向语义性、扩展性和声明性。因此，大多数的编程语言仍然类似于机器指令的抽象表示，或者说是“代码”。这是计算机受到有限计算资源的限制而遗留下来的产物，在当时只有极其简洁的程序才能以最佳状态运行。实际上，这些用汇编语言编写的程序过于简洁，以至于只有编程时确定的目标计算机和编写它们的编程人员才能理解其含义。今天，我们已经拥有了足够的原始计算能力，但是资源节约这一“遗风”已经对编程语言的进化产生了长久的影响。 由于编程语言的结构与计算实现模型密切相关，它们并不适合于描述复杂实体和事件（进程）的含义与功能。所以，必须首先运用一种不同的方法对这些实体和事件进行建模。在传统的开发工作中，这样的建模发生在复杂且高度说明性的设计和规范过程中：业务分析人员制定规范，编程人员则将这些规范转化为实现代码。 一旦规范被准确地转换为过程代码，通常会出现另一种情况：代码的行为比起它们建模的过程更加不可预测。因此，一旦软件投入运行，对于基本代码的任何后续修改都将困难重重。这就是许多业务流程受到软件局限性困扰的原因。 将业务规则实现为过程代码以实现流程自动化所遇到的困难，只是现行开发方法局限性的一个例子而已。由于业务规则在定义业务模式和流程上占据着中心主导地位，任何修改或加强规则部署方式的尝试都会使人们强烈意识到构筑灵活的企业基础架构势在必行。 相应的解决方案要求在新的开发环境下对概念进行重新定位，新开发环境的主导思想应该是：揭示信息与实现方法的含义和功能；便于任意应用程序组件间的松散耦合（无论是在设计阶段还是运行时）。 这样的开发模式已经出现，并在以下方面显示出巨大优势，它能够显著提高创建、修改、扩展和重新定位诸多解决方案的效率：企业应用程序集成、流程自动化以及贸易伙伴互动。面向服务的架构（ＳＯＡ）的出现重新定义了应用程序的概念。应用程序不再使用非透明的过程实现机制，而是成为一种由发送、传递、处理和转换事件组成的和谐过程。其中，消息内容以及处理消息的功能组件都通过ＸＭＬ技术展示。基于XML的开发和部署平台推动了ＳＯＡ编程模式，并且非常有吸引力，因为这种平台不但能显著降低开发周期的成本，而且对应用程序组件和全部应用程序的扩展和重用的支持达到了空前的水平。 那些根据复杂且时时变化的业务规则而设计的应用程序从是这种模式的最大受益者。长期以来人们意识到，将