速记参考：

    苏明富：非常感谢大家能够坚持到现在，今天我是最后一个。希望我能给大家带来一些惊喜。前面我们的合作伙伴普元提到SOA架构，以及架构中的服务，刚刚又提到了流程。接下来我要讲的是SOA架构中的规则。这个是SOA的理论，实际上它的目标非常简单，就是提高系统的灵活性。怎么来实现呢？就是通过服务。服务从最底端的比较细颗粒的服务，到粗颗粒服务。通过服务的组装，通过服务的重用来达到它的灵活性。
    我们把重点关注在服务方面，我们知道实现了这些服务，它肯定是不同的。从分类上来讲，无外乎两种，一种是比较稳定的服务，另外一种是频繁变化的服务。比较稳定的服务，比如认证服务、数据访问服务，这种一般做好了，可能几个月，半年之内不需要做什么大的变动。比较麻烦的是这种你和业务部门打交道的时候，麻烦就来了，业务部门告诉你不对，你实现的需求不满足，我还要在变。于是你发现这种需求每周都在变化，这种就是我们要面对的问题。我们把这种服务叫做决策服务，在定价系统、数据关联、合规检查中都有大量的变化存在。
    对服务的要求是什么呢？我们知道对服务上有管理的要求，管理上有不同的渠道，有时候会把一些系统交给我们的合作伙伴去管理，我们有不同的产品，不同产品处理逻辑不一样，还有不同的地域，中国移动、中国电信有不同的省份公司，省份公司下还有地市公司，我们都要满足他们的需求，这个里面有大量的复杂性的问题。还有一个就是对服务逻辑的访问，谁能看到，谁能查到，谁能变更，我们要求对这种服务逻辑达到可视，所谓可视就是能够看见。我们知道写的代码肯定能看到，只有开发的人才能看懂，换了一个开发人员，可能就要过一段时间才能看懂。还有无序变更就导致系统无限庞大，SOA架构里的服务我们要有这种要求。
    目前SOA架构里的服务现在存在一些问题，最主要的问题是什么？决策服务是一个黑盒子，这个是使用代码来写的，是一个黑盒子，我们讲重用一个东西，如果不了解这个里面的逻辑，你重用的风险有多大？实际上它使用起来的效果如果不像你想得那样，那问题就来了。做到系统重用，要最起码去了解它，黑盒子不好审计，所谓审计，有的财务系统，以及银行对审计最关心，你这种黑盒子无法审计，必须要使用代码来去审计。或者使用你的测试过程来去审计。如何在这种开发完毕之后，就可以交给客户进行审计呢？这也是当前面临的问题。
    另外带来一个问题就是难以维护。因此我们需要解决这些问题，首先不要把它们做成黑盒子，要把决策逻辑不要做成黑盒，黑盒限制了重用性、灵活性、可视性。在SOA服务中，加入我们的业务规则管理，加入这种业务规则，使用业务规则工具把逻辑管理起来，这样刚才我们讲了BPM还有一定要保证BPM简单，就是业务流程一定要简单。业务流程和我刚刚讲的业务规则都是面向需求的，都是面向最终客户，面向业务的。假如我们的BPM经常变化，我们的问题就来了，我们知道变化带来的问题可能就会出错误，可能会不稳定，这个时候，我们在开发BPM的时候，一定要把它做成简单、简洁、减少变化。怎么来做呢？就应该把里面的流程逻辑和决策逻辑分出来。我们这里有好多做流程逻辑的时候，里面写了大量决策逻辑，比如审批，假如大于5千块钱A部门审计，小于5千块钱B部门审计，如果你在流程中，融合了业务逻辑和你的流程逻辑，对你的流程管理就不好管理，所以我们说，还要保持流程的简单，这个是我们要解决的问题。
    最佳方法，我这里提到ILOG产品，有一个产品就是基于业务规则的透明决策服务，这个就是实现了这个目标，就是你看到的就是你得到的逻辑，你看到的逻辑表达，你要得到运营的结果。进入业务规则了，我们就看什么是业务规则，我们刚刚举了一个非常形象非常生动的例子，确实那就是业务逻辑，比如贷款的规则。投影上打的就是我们计算征收税的规则，如果客户给你逻辑，你要实现这种需求，还有像移动、或者网通、电信等等回馈的逻辑，如果你入网预存的多，可以给你回馈一些服务，或者回馈其他有偿的东西，这个也是逻辑。还有按揭贷款，你不同贷款情况，不同贷款人，你的风险是不一样的，要评价你的风险，给你评价的风险，最后决定你的授信怎么给你贷款。这就要进入业务规则的定义了，规定了一个企业如何开展一个特定的业务，因此这种业务规则往往限定某些条件下，我要做什么样的操作，因此，和我们的业务需求和业务部门关系最为密切，在银行、通信行业、保险行业都有大量的存在。
    进入这种业务规则，我们就说你有规则不错，假如我要用的话，应该采取怎样的形式去存在呢？我们就说，下面要讲如何用，我们应该是怎样去表现？这是我们目前的系统，我们采用人工处理，采用大机系统，才用数据库表，加上代码、编码进行逻辑处理，结合起来实现业务逻辑，一定程度的灵活性。但是目前这种东西，我们说不变化，或者局部变化还行，要是做大的变化问题就来了，告诉业务部门我们现在没有人，或者经过一段时间才能实现，因此这些问题，我们就说面临变化的问题。如果采取业务规则应该怎么来做呢？首先会有一个规则库，规则库做什么？我们知道把业务数据采用了各种的数据库，我们把业务数据保留下来，这个是你运营当中得到的一些结果，还需要它做分析，需要开展做后续业务，这个规则库，同样把你的逻辑，从你零散的这种系统中分离出来了，从代码里抽出来，从你的库表中抽出来，我们知道如何开展一个业务，我们说这是谁的资产呢？是开发商的资产？还是我们客户的资产？毫无疑问，肯定是客户资产。如果银行开展一个业务，这个业务就是这么制定的，促销的话，如果客户使用某些产品，我赠送什么业务，这个是客户的资产。如果我的资产都采用代码来做，采用库表结构来做，我们的资产在哪？我们的资产没有了，可能就只有文档了。我们的业务部门做这种教育的时候，我们也没有东西，所以说，假如我们把原有业务和项目保存我们的数据一样保存下来，那就是我们的客户自己控制了我们的资产。
    有了这种规则库来保证我们的业务逻辑之后，还有相关的界面，就是访问这些业务逻辑，通过WEB，通过专用工具，来去创建它、变更它、部署它，包括授权，生命周期的管理，都采用这种界面工具来进行处理。另外一块比较重要的，就是厂家比较关心的，就是目前的规则引擎，这个引擎会从规则库里提取出我们的逻辑。引擎开始初始化，初始化之后就可以和我们的商业应用打交道，我们的商业应用和规则引擎来进行交互，进而形成一个逻辑。业务逻辑执行是在引擎来执行，我们的厂家做到更多的把你的业务组织起来。这是我要讲的业务规则主要的构件，这三种肯定一个不能缺了。
    我们再看刚刚说的规则怎么实现，我们现在采用代码来做的，刚刚这些规则我们写了一堆代码，如果满足一个条件，假如增值税金额达到多少给你什么税率，如果采用业务规则，这个就要采用全新方式，可视方式来写这个逻辑，可视的方式，就是如果贷款人买的房子价值多少钱，第几套房子，那么我们设置贷款税率多少，就是这种。就像我们自己写逻辑一样，基于这种写完的规则，我们看业务人员可以操作，我们的管理人员能够看得懂，这个可以被审计的，并且这个可以作为资料保留下来，它的变更可以被跟踪，管理受控的，这样对我们的业务开展有很大帮助，并且也能够帮助我们建一个比较好的SU的服务。
    回到ILOG产品，这个产品叫JRules，目前有六个产品，它的产品有四个构件。左边的是Rule  Tech，然后是Rule  Care，面向业务的原则，通过WEB操作页面，完成规则的编写，跟规则的部署，规则的生命周期，规则的权限管理。下面就是规则的引擎，这个可以部署在各种环境下，可以采用SOA。可以做大量的场景，通过场景做各种的回归测试、单元测试，这是它的主要部件。
    主要部件的关系，我们可以看，Rule  Stuido有一个库，这个管理规则库和业务人员下面的库是相关的，是击中了所有变更都在这个里面来存放。开发人员可以通过我们的版本控制工具像CVS这种，来实现同步，包括最初的开发来提交，提交完以后，变更完以后，可以由业务人员变更，业务人员写了新的，再去给开发人员，可以完成协同。这是整个架构。
    下面这个执行服务器，我们可以看左下角是一个透明决策服务，这个透明决策服务就是一个SOA的WEB服务，我们写完这个业务规则，被规则引擎加载之后，可以通过一个SOA的分装提供给我们其他的应用进行调用，这样的话，我们就说要把逻辑外置，逻辑被管理起来，逻辑可以单独调用，这个是我们产品的整体结构。
    我们有这个结构，它被执行的过程怎样？我们首先看上面，最上面就是我们的应用，我们可以采用不同的技术来进行编写我们的应用。首先你去准备你的数据，我们知道任何东西都依赖于数据，尤其现在的业务系统离不开数据模型，你的数据可以来自你的数据库，也可以来自你的前台输入，总之把数据准备好，你的目的是干什么，要问规则引擎，这条数据是帮助我校验规则，把准备好的贷款人的产品输入到规则引擎，规则引擎从规则库里输入规则，做第一次初始化，然后做规则逻辑运算，然后返回给我们的应用，应用就会得到，这个客户是可以被贷款的。并且贷款税率是多少，这个是它的一个过程，有可能还会修改我们的数据，这个是它的技术架构的集成。
    接下来我简单有几个界面的截图，大概有一个形象的了解。第一个界面就是Rule  Stuido这个是面向技术人员使用的，从最初的JAVA代码开发，业务建模，最初规则的开发，都在这个环境下来做。写规则，我们可以看右边的，就是这种定义的模式，就是像写文档一样，只不过有一个格式条件，如果某某满足什么样的条件，那么动作是做什么动作，我们知道动作无外乎调用你的函数，修改你的数据，这个都是动作，条件就是做逻辑运算，加减乘除对比，或者做函数运算，可能还会做预测的运算，这个都是可以的。
    这个是Rule  Studio，这个肯定有一个先后顺序，有一个依赖关系的。首先做数据校验，然后才能做下一步资格检查，我们把数据校验的规则打成一个包，可能有四条规则，把资格校验的规则打包，可能有20条规则，如果通过了，就说数据没有问题了，再走下一个流程，就做资格检查。也可能我们从一个调用，比如全球通客户，走全球通的规则，如果是动感地带，走动感地带的规则，运行当中，采用规则流把它编排起来，这个是编排工具。
    这边就是提供给业务人员的，它采用这种WEB界面，登录WEB界面以后，这个是受控的，有角色管理的，完成规则的创建，规则的变更，规则生命周期的管理都可以完成。这个是一个规则的浏览，进来之后，我们通过左边的视图，我们用规则视图，通过点击，可以得到自己感兴趣的视图，通过规则可以看到规则怎么写的，这是规则列表。这个就是业务人员看到业务规则，我们可以看非常简单，就是如果输入申请人的年龄大于80，成功数量是什么，性别是什么，如果想编排，选择一个条件，鼠标一点就会出来下拉列表，我们通过选择这些业务词条，来组织出一个逻辑，这个是业务人员的编写规则的界面。
    另外一种编写规则还是一种决策表，如果我们有大量的结构性的规则，我们很希望采用这种决策表，我们决策表可能一条就是一条规则，我们针对不同的属性，得到不同的结果，这个时候采用决策表是比较好的。另外就是规则树，决策树，如果你的决策表是非常稀疏，那么意味着某些条件可能不考虑，这种情况下，可能比较适合用决策树，当然我们学过决策科学的人都会知道这个东西。
    再一个就是规则的管理，规则历史的管理，有时候规则在变，变了以后，可能就会想原来是怎么实现的，你可以把规则的历史找出来，我们对比一下两个版本，把不同的给你标识出来，能够了解原来业务怎么做的，可以把历史规则恢复回去变成当前的版本，以及权限的管理，哪些人可以访问，我们可以采用目录结构，采用一些其他的命名规则来去实现对访问规则的权限控制。当然还有大量的其他管理功能，你可以把你关心的规则，对到每一个部门的规则，或者访问某些属性的规则，都可以做一个视图。另外它的状态，有没有被审核，它的生效日期，生效时间是什么时段，还有这种生命周期的控制，什么样的角色可以把规则从新建状态改成可以部署状态或者审核通过状态，通过这种只有被审核的过程，才会被发布，这个就很需要这种生命周期的管理。尤其是银行，不可能随便做一个规则就马上发布了，肯定会审核的，审核通过以后，系统管理员才能把审核通过的规则给部署出去，才能生效。
    另外规则查询功能，有时候你可能提了新的需求，客户来了找你，还要增加一个人的年龄的需求，如果一个人的年龄大于一定岁数，我还需要一个约束。这个时候可能就想了，我们有没有使用过年龄来做的规则呢？如果有，会不会有冲突，会不会重复？这个时候需要做一个查询，查询所有的规则，这个规则访问了哪个类或者哪个表里的年龄属性，那么要把相关的规则查出来，你可以进行相关了解，来决定这个是不是在原来基础上做组合，还是新建一个。
    另外多用户访问的时候，可以通过仿真设施这些都是管理的功能。再往下就是业务热部署，我们都强调业务的敏捷性，就是业务部门提交了需求，可能告诉你，明天早上必须给我看到结果。这种情况下，这种热部署，就是实现完了这种需求，你就很希望马上把它部署上去，业务规则可以满足这种，就是把整个运行系统不需要停，直接把变更规则直接发布，这种热部署的功能也很重要。并且你的规则，所有的规则存放在规则库里，但是你的规则有的侧重于营业的，有的侧重于计费的，有的侧重于营销的，你可以采用一个规则库保存，但是运行的时候，可以采用不同的方式保存在容器里。回到SOA目标，就是提高灵活性，重用性，提高服务的重用性，提高灵活性，缩短业务开发周期。基于业务规则的开发，我们就可以实现这种敏捷，上面的这一块，就是传统的开发过程，从客户的提交需求，到我们的需求分析、编程、测试、确认、部署、上线这些都是很长过程，如果牵涉到代码变更至少要两天，因为从变更来讲，找到谁来开发，那个开发人去抓紧投入开发完以后，晚上肯定要做测试，因为代码重新整合，第二天，小心翼翼发布，这个周期非常长。如果遇到需求比较大的，那就更长了。
    基于这种业务规则，那就方便了，业务人员自己了解业务逻辑，简单的说还自己采取WEB界面来定义规则，不愿意维护，可以让维护人员通过这个界面来去组织这个规则，变更规则，变更完以后，这个就很简单，直接提取相关规则来看，如果通过了，就可以直接部署了。可以一个小时之内，几分钟之内，就可以完成新的业务需求，因此，通过这个来实现我们的业务灵活性。
    往下讲，就是我提到的BPM，就是业务的流程。我们刚刚讲了，要把业务流程里的流程逻辑和决策逻辑要分离。下面我这个界面展示的就是一个流程，这个流程很庞大，经历了两年以上。为什么这么庞大呢？因为它里面有好多的判断分支，满足了一个条件，就走另外一个分支，客户又提一个需求，我又加了一个部门，这个部门在另外一个条件下要把分支给它，要马上改流程，所以流程会变的非常复杂。因此为了简化这个流程，我们需要把决策逻辑从流程里拿出来，拿出来使用这种BRM业务规则来完成这个决策。我们知道简单的这种决策在流程里还可以配置，如果是复杂的逻辑怎么办？根本无法配置，怎么办？我们往往采用第三方调用，我们写一段函数处理，让流程去靠它，但是这又有一个问题，业务人员看流程是这样做的，如果你又去印编码了，不知道逻辑从哪来的，所以应该拿出可视的业务规则，无论从流程上还是决策逻辑上，可视自己的系统怎样运作，通过这种业务规则来简化BPM。
    当然我们的BPM合作厂家非常多了，包括普元。下面就是一个示意图，SOA里的规则服务，规则在里面可以作为一个决策服务，就是我刚刚讲的透明决策服务。有关决策的内容，都会调用外部的服务，来完成决策，对于其他的客户接触的服务，或者是合作伙伴的这种服务，或者是数据或者第三方应用的服务，都会采取SOA分装起来，什么时候我要不要调用一个第三方ERP应用来去查一些东西呢？什么时候需要？这个可能是一个逻辑。也可以，也可能会在决策服务里来实现，还有流程服务，怎样影响流程，什么时候来派发应用下一个点，可能会在决策服务里面，这个就是SOA架构里的规则服务，这个就是我今天要讲的主题。
    这个就是结论，要想实现真正的SOA的灵活性，可以说就是规则必不可少。我们现在在好多银行，包括建行、光大银行、中信银行，电信行业的，比如移动、电信、网通都有在用我们的产品来实现它的业务逻辑的变化。尤其是在营销里面，我们知道营销队伍是变的，还有一些银行的审核，一个保险的核保，银行的信贷，这个里面都有大量的规则，如果完全采用编码就很麻烦了，首先资产不是你的，第二你如果变更，周期很长，风险很大。透明决策服务，基于BIMS的这种透明决策服务，是真正能够提高SOA的稳定性。
    最后一分钟，介绍一下ILOG公司，是一家法国公司，现在在欧洲纳斯达克两地方上市，实际上我们有三个产品，我今天介绍了BIMS是其中一个产品，我们在宝钢，现在在中国石化都有这种优化的应用，就是有限定的资源，限定的这种人力，我要达到一个最优的运营，我们怎么去运营，这个有数学的求解。
    另外就是界面，我们用过画图表的，界面是一些开发的主编库，把从JAVA界面繁杂的数据中脱离出来，你可以不用关心图形，只要写数据，把数据给图形组建，自动给你展示。这是我们的产品，我们全球有800人，在上海06年设立了分公司，国内目前有80个员工。另外ILOG公司宗旨，虽然公司不大，但是做的很专注，主要宗旨非常简单：
    第一，帮助客户更快更好的做出决策，我们企业高层每天都会面临这些问题，我如何做决策，怎样保证我的决策是正确的，ILOG会提供相关工具帮助你。
    第二，同时帮助客户来管理这种变化和复杂性。我们谈得最多的就是变化和复杂，如何把这种复杂变为简单，ILOG提供相关产品，就是刚刚我讲的规则管理。我的演讲到此结束，谢谢各位！