51CTO直播小组 : “2008 SOA中国的关键任务技术论坛（北京站）”将于下午13:30开始，51CTO.com为现场独家视频直播网络媒体，敬请广大网友关注！

51CTO直播小组 : 您将从本次论坛上收获：SOA在中国实施的关键任务、SCA/SDO最新规范进展、SOA服务构造的规划、标准和实施方法、SOA在中国实施的鲜活案例等。

51CTO直播小组 : “2008 SOA中国的关键任务技术论坛（北京站）”将于13:45准时开始！

51CTO直播小组 : “SOA中国关键任务-专家谈”短片播放！

主持人 : 各位来宾下午好！欢迎来到SOA中国技术论坛2008年会北京站，我是本次路演的主持人杨嘉伟，也是普元公司市场总监。刚刚大家看到的视频是我们利用了三天时间，采访了这个行业的专家、媒体以及客户代表。这个视频对整个论坛的命题，SOA中国的任务到底是什么，大家已经知道了就是服务构造。就是SOA里面的这个S。事实上在2007年，由IDC和普元共同发布的SOA共同路线图白皮书里，我们已经清晰回答了在中国这一片处女地SOA市场中，新建服务将变的和美国不一样，新建服务将成为SOA在中国最重要的任务。我们今年2008年将对此问题进行深化讨论，不仅要回答为什么说SOA服务构造是SOA中国的关键任务，同时，我们还会结合案例，演示回答SOA服务如何构造，以及业务流程化如何编排。

主持人 : 请允许我用简短时间，介绍本次论坛主办方，以及协办。本次论坛是由普元软件公司主办，普元软件公司是全球领先的面向构建的SOA中间件的领导厂商，同时也是SOA国际标准组织，以及OSS互联网电子商

务标准组织的核心成员，也是SOA中国路线图的倡导者。本次论坛还得到了全球领先的规则引擎厂商ILOG的支持，并有51CTO、Csdn、Infoq、IT168、中国计算机报，构客网，TT中国，IT专家网等等这些媒体的支持。本次论坛包括六大议题。 :

主持人 : 第一，SOA背景下的中国软件之道。

第二，SOA企业架构与标准规范。
:

第三，SOA中国关键任务是服务构造与业务流程化。
:

第四，SOA的服务规划设计与构造。
:

第五，基于SOA的业务化流程的模式实现。
:

第六，SOA架构中的规则服务。 :

主持人 : 同时，这六大议题结束之后，我们会安排一个短暂的构客网在去年举办的“SOA我有话说”博客大赛的颁奖礼，最后我们会抽出今天的六个奖项，它们分别是三等奖三项，价值人民币300元，二等奖两项价值人民币800元，一等奖一名，价值人民币1600元，奖品乐高积木，以积木的方式搭建出漂亮的应用，充分体现SOA的理念，希望大家到时候不要走开。

主持人 : 最后一点，我用非常沉重的心情宣布一下，截至目前为止，汶川地震中遇难人数超过41353人，受伤27万4683人，500万人失去家园，美丽的汶川等地毁于一旦，这是我们的伤痛，我们希望在座的大家能够把所领到的绿色丝带系在手上，表达对这些同胞的哀伤和希望。

主持人 : 同时此次地震中，我们的总理两小时之内赶到现场，我们的子弟兵超过11万人实施了中国有史以来最大规模的救援行动，我们救出33434人，治疗52934人，我们的社会捐款超过160亿，献血人数众多，甚至

造成拥堵，110个小时，179小时，196小时，216小时，一次次被救人员生命奇迹得以突破，在此次救援中，我们中国人所焕发的团结、互爱、关爱、坚强激荡于心，这是我们的力量也赢得了世界的尊重。联想起前一段时间藏独事件对中国的歪曲，以及即将举办的北京奥运会，更加让我们相信中国从来都是一个不会被击跨的民族，大家说是不是？谢谢大家！ :

主持人 : 接下来我们请出第一位嘉宾，普元软件CEO沈惠中先生。他的讲演题目SOA中国背景下的软件之道。帮助我们回答企业今天应对市场将存在的问题，SOA带来什么样的机会，以及战略上一个CIO应该怎样应对。沈惠中现任普元CEO之前，是全球基础件领导厂商BEA公司的全球副总裁，以及BEA中国总经理，在他任职六年期间，他带领BEA团队实现每年200%的增长，成为当时中国最大，成长最快的软件公司之一，我们有请沈先生。

沈惠中 : 各位来宾、各位朋友大家下午好！汶川大地震到今天已经十天了，从过去的时间中，我们可以感受到中国的强大，也可以感受到我们中国人空前的团结。同时十天前的大地震，我们看到倒塌的房屋，看到我们的灾民比较贫困的生活，我们可以清醒地认识到中华民族的振兴之路还非常长。

目前中国在很多方面离世界先进国家还有很大的差距，而在软件行业，我们目前还比较弱小。我今天演讲的题目是《SOA背景下软件中国之道》，想和大家探讨三方面的问题。 :

沈惠中 : 第一，目前整个企业软件的发展趋势。

第二，我们可以看看从传统行业发展历程，能得到什么启示。
:

第三，想跟大家探讨一下，对中国软件将来发展的一些斯卡。 :

沈惠中 : 希望我们这样的探讨能够帮助我们中国的软件产业不断的进步，为我们国家的信息化能贡献更多的力量，让我们中国真真正正成为二十一世纪的主载。

沈惠中 : 当我们看企业软件发展的趋势的时候，我选择一个角度，就是从目前业界的领导者他们在做些什么。目前企业软件市场其实被四大厂商，如果不是垄断，也是霸占的。

沈惠中 : 我们看看最近几年在看一些什么事情。SAP其实在过去五年中，它有一个最核心的战略，就是他们的平台战略。它们做的事情首先是自己研发了一个应用平台，这个平台叫Netweaver，过去两三年中做的事情，就是把以前企业管理软件的应用，套装软件在往这个平台上移植，而且是通过SOA的方式，也就是标准化组建化的方式，把自己的一个大的ERP软件拆成非常多的小软件，基于Netweaver它们今天可以面试了。

沈惠中 : ORACLE做的事情比较多，没有多久之前，完成了我以前工作过的BEA公司的收购。看了它做这么多的收购，其实背后隐藏的战略是什么呢？很简单，你看收购了CIM厂商，从一个做技术平台，就是一个数据库提供商，在逐渐向应用提供商在转型。同时，它把这么多的应用厂商买回来以后，内部也是做一个整理。这个定位和Netweaver定位一样的，这个目前还没有完全成型，也许做的过程中遇到很多困难，所以收购了BEA，可能希望充实。将不断收购过来的这些，全部用SOA方式，移植到它的统一平台上。

沈惠中 : IBM我们比较熟悉，我记得几年前，IBM一直在宣称绝对不会做应用软件。它们一直说提供技术平台软件。

程朝晖 : 希望接下来我的演讲能够给大家这样的回答。

程朝晖 : 应该说，现在的信息化建设当中，会碰到很多的一些关键词，信息化孤岛，打破这些系统。刚刚沈先生给大家看到了这样的一种理念，并且这种理念，一百年经过传统行业的实践，以至于我们软件产业还处在一百年前的汽车行业生产制造水平，同样看到飞机制造行业，等等各个行业都在用更加先进的这样一种标准化的组建化的协同的方式，在让这个产业里的各个厂商、客户都能够最大化它的价值。能够把这个更快速、更高质量的去把一个产品做出来。为什么我们软件产业一直到现在还是在这样一个手工作坊的阶段呢？

程朝晖 : 这样一个理念，协同？协作、标准化、组件化去生产的理念，可以在软件产业得到实现呢？相信说SOA这样一个时代的到来，真正的带给了我们这样一个机会和可能性，当然它也同样的是挑战。

程朝晖 : 因为可能我们没有很好的去认识到这一点，没有把我们公司自己最核心的能力发挥出来，而是在旧有模式下生产的时候，可能五年、十年以后，在座的各位一些公司可能就不存在了，也有可能在座的各位一些公司就发展非常好。

程朝晖 : 今天我的议题分三段。首先会看一下业界对SOA的机遇与挑战看法，希望我们在这里也能够看到这些关键的问题。

程朝晖 : 至于解决这些关键问题，我们会发现有很多的点，可能是一个技术点，可能是一个业务点，可能是一个管理点。我们是割裂的去解决这些问题？还是说应该有一个统一的方法去解决这样一些矛盾呢？这样的一种方法是不是架构，是不是现在有业界的标准？还是说现在无法形成标准？将来照着这个模式做，中国移动要么绑死在亚信身上，要么和朗信合作。

程朝晖 : 要么就是找到更合适的方式，并且服务更多的客户。中国的客户能够在市场上选择最适合于它最低成本最高质量的业务模块，能够把它最后组合成满足自己业务需要的应用出来。所以这样一种模式，必须要有这样一种业界的标准和规范，才能够说，让大家能够去协作。我们现在看似在竞争，打的头破血流的公司可以去合作，这样的合作可以给客户带来更大价值，给我们的开发商能够进入更多市场，发挥自己的核心模块更大的市场价值。

程朝晖 : 最后也是刚刚提到过，需要承载这样一种技术架构标准，不可能那么多开发商客户都深入研究这些SOA等等这些这么多的技术规范和标准。业界统计的和SOA相关的标准大概有82个，我们不可能自己了解的非常透彻，然后应用出来，所以树业有专攻，所以希望技术平台上找到最合适的商业平台，打造自己的业务模块出来。

程朝晖 : 首先看一下业界他们的观点或者看法。Gartner和IDC是比较权威的机构，我们可以看一下Gartner提到，目前基本企业级的应用都是基于java或者是.net平台来做，但是它越来越不足以去解决如下的需求，而如下的需求，又是我们企业现在和未来非常迫切关键的需求。比如它的这种整个的动态的应用开发，灵活的去应对需求的变化。比如我们需要可能是这样一种更加主动的及时的事件驱动机制，来帮助我面对需求变化、竞争变化等等一些我的业务管理上策略变化的时候，我及时的采取这样一种反应。这样一种架构势必会被先进的SOA架构替代掉。

程朝晖 : 新的软件模式和编程模式诞生，我们不在意原来作坊式的几百万、几千万的应用代码去写。我们用新的编程模式来替代现在的软件生产方式。新的一代支撑这样的方式技术标准的平台会出现，新一代中间件的产品会诞生。另外我们现在用的最多的90%几，甚至更多的这样一种主流的编程模型，在这个基础上，去不断的为了支持SOA，为了支持事件驱动，把功能不断加上去，这个不是很好的办法。这只是会使我们已经复杂的技术架构越来越复杂。这个是我们现在看到的。我们把很多的组装起来，最后发现服务需要管理，需要一个服务的管理，然后发现这些东西怎么开发，开发完的东西能不能被管理起来，又拿了很多技术进来。在已有的基础上，不断堆加，不断头疼医头的时候，只会进一步复杂我们的技术架构和开发的模型。而这种复杂带给我们的就是整个到一定程度上就会失控，我们的效率越来越低。当我们改一个应用的时候，牵涉面非常广泛。上面四点，可能是Gartner看到业界技术平台趋势的时候，给出的观点。

程朝晖 : 同样IDC也看到，在整个企业要更灵活应对市场变化，比如采用SOA架构。去建设整个信息化建设的时候，需要遵循六大原则，包括SOA体系架构，包括组建化和标准化，包括端到端设计管理。刚刚沈先生提到波音的生产过程，商业模型下的开发模式的时候，其实非常重要的就是波音它完全自己能够控制这样一种端到端的设计，以及相应的管理能力。当然它把整个20页的设计图纸，把模块划分很清晰互相之间的关系，然后把模块通过大规模协同的方式组织起来，每一个模块可能是一个分包商，可能下面还有更小的子分包商进行协同，而每一个厂商在里面，这个领域里都是最强的。因为波音做的787，一定是业界要做成最领先的，它也是希望这样一种领先模式，能够带给它更大客户价值。因此对于客户或者开发商来讲，在我们所在的领域里，我们可能和我们的分包商，以及我们的上游需要有这样的能力，帮助客户去实现端到端的设计和管理能力。

程朝晖 : 在这样一种观点之下，我们所处的一个环境，刚刚沈先生提到了，十倍的灵活性，十倍的需求变化，十倍的吸引人，但是我们的钱只是别人的1/10，我们处在中国SOA市场环境，跟IBM、微软它们所定位的主要客户群，所在北美、欧洲市场很大的不同。虽然技术发展驱使下，SOA都可以给这种市场以价值，但是可以发现这个SOA它能够给到这些客户的价值，是有它的本质不同的地方。中国市场它的本质不同，就是在于快变化。我们本身管理和业务还在不断成长当中，这种变化速度是北美十倍。因此我们自己需要这样一种SOA应用的建设的路线图画。

程朝晖 : 同样的，对于服务构造，因为在国外的客户来讲，已有的系统已经百分之八九十已经满足需求，不需要什么变化，只是根据新的业务需求，把串联起来，做一些新的编排就可以了，但是中国的业务模块，业务支持根本没有被很好稳定住，我们还在不断的去改进。大家可能听到一个系统不断被一期、二期、三期推倒重新建设。在这个过程中，根据IDC分析，服务构造非常关键的，而且放在了整个服务管理的前面。它们之间当然互相需要

程朝晖 : 对于中国客户来讲，服务构造，如何构造我自己的业务模块，把这些业务模块能够稳定住，能够为上面的业务流程和服务提供可以组装的基础。这是我们的一个建设的关键，也是本次大会的主题。接下来很多任务都会围绕这个关键信息会展开。

程朝晖 : 在确立这样一个环境之下，可以看到中国用户必须站在自己的需求来为导向，并且通过一个平台化的发展，来实现自己的SOA应用，实现自己的一个客户价值。根据IDC最近的统计，可以看到中国用户对于SOA的采纳也是处在从实验，一直到现在更多的客户在局部性的部署和实验，现在也有一些行业领头羊的客户，金融或者电信的，已经开始在整个企业去规划，去试点，去推广去部署整个SOA的战略和应用。

程朝晖 : 这样的一个环境，其实让我们去看技术它本身，应该说是在为我们整个业务或者管理做支撑，因此大家在座的都是做IT行业，IT就是信息技术的一个行业。信息技术它每次到来的时候，都是带来了一个巨大机会，但是同时，它又可能会消灭掉、毁灭掉非常多的以前非常好的公司，我们不能够把握这种技术潮流的时候，就会很快被淹没掉。昨天、前天看到一个新闻，大家都是内心非常认同的伯能公司，以很低的价格被卖掉了，这样一个技术公司，当不能把握技术换代潮流的时候，大家都是基于更为开放平台的上面做的时候，它自己不能把握，没有专注在自己的核心能力上，它把自己的模块又搬到了微软，它希望通过这个扩大市场份额，可以突破更大成长，但是没有想到它的这种战略完全是错误的战略，把自己的核心竞争能力给放弃掉了，跑到自己陌生的环境里去。所以其实每一代技术架构，给了我们整个客户业务带来了很大的发展。从最早主机终端，可以让银行推出适时交易帐户处理业务，一直到了有了客户服务机的业务，可以跨地域通存通兑，电信也可以进行营业帐务处理，一直到有了BS以后，可以用任何时间任何地点任何方式响应这样的服务，而且这样的服务越来越便宜。从主机终端几百万美金部署业务流程，到BS架构下，几千块钱就可以部署。一直到SOA这样一个浪潮过来，如果能够把握住，找到自己的核心能力，在这样技术平台上发展，我们就可能成为未来很成功的公司。

程朝晖 : 在这样的潮流下，到底SOA的架构是什么样子的？通常很多人会讲SOA是一个业务问题，不是一个技术问题。SOA是管理问题，不是技术问题。但是最后所有的技术人员在讲SOA。其实我们看到整个信息化建设中，充满了矛盾。业务要求技术说你把业务功能实现，把我这个需求能够实现，把我流程改变掉，技术人员告诉他说，需要两个月时间。管理人员说，你到底需要多少开发人员，能不能更少一些，实实在在听到过一个客户去问，说你这个项目四个月时间，能不能两个月实现，管理人员说我需要一个业务模块，这个到底运行怎样，为我提供多少业务价值，技术人员回答不出来。所以会看到整个信息化过程中，业务技术管理是非常矛盾的。

程朝晖 : 解决矛盾最好的办法是什么？是需要把这些矛盾梳理出来，用一种架构模型的方法，能够把它统一起来。所以在这里我们可以看得到，这样集合业务技术管理矛盾统一体，是在统一解决我们所面对的这些问题。我们通过业务应该怎么做？业务需要通过刚刚讲到过构建化的方式，来进行分工、专业化、协同。通过流程来把我的每一个业务的组件、构件组装起来。这样一种业务模型，通过技术我们需要实现服务化，我们需要把具体的实现技术跟服务给剥离开。让服务形成一种标准，而这样一种标准，使得不同部门，不同企业之间进行协同。

程朝晖 : 同样，我们对于IT和业务要能够在具体的实施当中，能够有效的去定制，能够去管控，能够去治理，使得业务模型和流程，使得技术的支撑，能够非常清晰看到，哪里做得好，哪里做得不好，哪里应该进行优化。其实整个业务的分工协同当中，其实有这样的业务组件化的模型。这个其实我们回想一下制造行业中的微笑曲线，就是告诉企业，你要么越靠近核心技术，你的利润会最大，要么越靠近客户关键问题，业务关键问题，那么你的利润会最大，我们每家企业，都应该找到自己的核心优势在哪，普元这样技术厂商，我们的能力就是在技术平台上。我们很多开发商需要找到我们的核心能力就是业务构建证券交易这块，银行跟证券交易所，可能是银行现金管理这块，甚至更细。而你们在这个领域最能发现客户关键问题，帮助他最有效的解决，你们的价值就会被最大化。

程朝晖 : 大家都要在这种分工协同模式下，通过整个业务组件化的模型，这个也是SOA非常终了纬度，必须在业务上采用组件化的模型、构建化的模型，通过业务模型满足业务需求，通过业务构件，实现每个业务方面关键的问题，通过平台构件，还有技术构件这些都会有相应的规范和标准。

程朝晖 : 技术架构方面，我们需要一个SOA技术架构的分层体系，可以看到企业里这些资源，我怎么能够更好使用这些服务，装备这些服务，能不能有效灵活用它，这个是会给企业应用，是不是能够灵活快速的一个非常大的挑战。往上走就是构件这一层，实实在在构件业务逻辑，不能限于逻辑就是JAVA所做的，因为每一个企业技术为什么采用这种技术开发，是有它的道理的。

程朝晖 : 因此我们在构建层是一个非常开放的，可以支持各种构造技术，可能是图形化的安装，可能是一个JAVA的构件。再往上是企业层，对整个资源形成统一标准，以便为上面流程提供相应的服务。我们服务当中一定要标准化，这个标准化不仅是互联互通的协议标准化，更重要是软件开发模式的标准化，我们编程模式的标准化。什么叫构件？什么叫流程？把清晰定义出来。再往上走，通过我们的流程，根据客户的需要，去实际的组成客户的应用层，再通过协同层，来交付我们的服务，交付到真正的客户使用面，在不同的部门、角色之间协同工作，共同完成一个任务。这个就是我们在整个SOA技术流程中，看到需要服务剥离以及标准化。

程朝晖 : 第三个纬度，我们在业务和技术情况下，我们很难说，一天就想得很清楚了。因此我们需要有这样一套管理的治理的方法，能够对于我们的业务组件，业务模块，对于数据资源，对于一个逻辑的流程都能够有效的去管理起来。在管理当中不断的监控、分析、统计数据，一直到把我们的一些业务和IT策略给注入进去。很简单的例子，比如这个跟具体应用开发没有关系，当企业系统不断成长的时候，当我到了一定的吞吐量的时候，或者到了这个服务调用的时候，这种角色调用的时候，必须要符合安全的策略。我就会自动注入安全策略，使得我服务必须符合这个安全认证体系，才能被这个角色的人执行。同样我们可以适时通过管理控制，看到这些信息，来看到我们整个业务的运转情况，以便于定位到或者说预测到问题的发生。

程朝晖 : 当然，我们还可以对应用和平台在不同的涉及到不同的省和地市，对它们进行动态的配置。

程朝晖 : 有了这些架构以后，这样一种业务模型，你说技术分层，你说管理框架，是不是有技术规范和标准变的非常重要。有了技术和规范标准，才能让我们不同开发商之间，才可以去协同。不然我们刚刚的梦想还是不能得以实现。所以在2006年7月份的时候，正式对全球宣布标准组织成立，缩写叫做OSOA。

程朝晖 : 是一个开放的SOA组织，当时一共有18家重要的厂商在这里去共同推进SOA里面的这样一种构件化标准的制定。这个18家厂商可以看到，当然BEA现在被收购了，现在只剩下17家，普元是唯一一家亚洲厂商，制定这样的标准。业界也有这样的说法，一流的企业做标准。因为普元专注在做技术平台厂商领域七年多的时间，所以我们才能够被邀请到这样的标准阻止，共同制定这样的技术标准。

程朝晖 : 有了更注重的制定标准，也帮助普元能够更好的把我们的客户需求，把标准怎么样更好的应用起来，通过这些组织给协同起来。这个组织主要是制定SOA服务构造里面实现技术规范，比如可能是JAVA实现，C++实现，怎样知道具体服务，第二这些技术实现之后，它的装配，原数据的规范，以及SOA里面数据服务这一块的标准，包括在管理期、治理期整个服务策略和质量的框架，大家可以看得到，整个SOA里非常核心的开发模型这块非常完备，除了技术，还有管理。包括业务组件化的模型，这个也是更开放的组织，大家如果有兴趣可以到OSOA网站里面看，普元是作为唯一中国公司亚洲公司，承担整个中国官方中文社区的承建，有一个开元项目，普元和IBM，普元在里面承担了一个Client项目。整个流水线组装，每一个零部件长什么样子，它的规格是什么样子，这个是规范里做了明确的定义，原数据的定义，用这些构件来规范评比底层的各种技术。

程朝晖 : 同样普元投入精力，和民间组织，一起把规范翻译成中文。大家可以到满江红网站上下载中文规范。这个是对于构件标准定义，包括这个构建如何装配成更粗略的业务模块也有支持，包括对支持协议的绑定等等。

程朝晖 : 这些技术标准已经非常完备了，去年07年3月26号的时候，已经发布出来。这些是标准的清单，包括了组装模型非常全面，各种技术的实现，包括SDO数据对象这一块，这些技术标准要成为工业标准，必须要通过工业标准组织实现，通过讨论，普元大家一直觉得把这样技术标准提交到OASIS工业标准组织里，这个是工业标准组织建设介绍，以及工业标准组织下，专门制定SOA技术标准分会，下面会有九个SCA专门讲标准和组装规范的技术委员会。平时工作方式也是比较多，通过专门协同的平台，在互联网上，进行标准的制定，也共同制定整个技术标准的路线图。现在WEB服务已经很好地解决了服务之间的互操作性问题，而更为重要的解决是如何简化服务的实现和组合，这个也是SCA和SDO2.1来去落实服务构造技术标准，以及到以后的服务治理，业务建模都会有相应的标准出台。

程朝晖 : 最后看到这样一种技术架构以及这样一种技术标准，让我们在座的开发商都去把它掌握住，深刻理解把握住这个都是很困难的，因为树业有专攻。这个是整个SOA生态系统里，大家需要找到自己的定位。普元是专注做这样一个商业的平台，这个商业平台就必须要站在整个SOA架构，去解决业务模型、技术架构，以及管控治理框架的角度提供商业化的平台，可以帮助我们能够非常容易的去落实下来，我们去做整个SOA的服务和应用就会容易一些。这样商业化平台不是那么容易做的，大家做着做着就需要什么问题，什么框架，什么标准，做这样商业化的SOA平台，必须要有相应的完备的比如对技术标准的理解，因此商业平台，基本上需要覆盖这几个方面。

程朝晖 : 第一，最左边的开发环境，我们一个服务要被开发出来，流程要被开发出来，我们需要一体化的开发环境。这个是需要去覆盖到里面的建模、设计，一直到它的测试，到它的项目的文档，甚至于到质量的控制。这个其实都并不容易，作为商业化的平台都非常不容易。开发出来之后，我们需要中间这一块，就是我们的运行环境，服务管理环境，以及流程运行环境等等，有了这样运行环境之后，不断积累我们组件的环境，以及到右边管控和治理环境，我们对服务，原来技术架构上，从来不能对服务进行监控，我们现在服务是企业中非常重要的资产，因此需要对这些资源资产进行监控分析，不断注入我们所需要的业务的策略。

程朝晖 : 在这样一个平台下，我们需要一个方法。这个平台买来以后，怎么做事情？每个企业不一样，需求也不一样。因此我们需要在这样一个平台下，有这样一个方法，就是整个软件生命周期，它是怎么会生长出来？怎么长大？怎么应对变化，最后流程或者服务不需要的时候，怎么消亡掉？

程朝晖 : 我们要在整个平台上，我们需要有这样一套完备的方法，这个方法是需要去覆盖，我怎么去规划设计我的整个SOA，我自己的目标是什么，我希望通过SOA架构，给我哪些业务系统得到改善，达到哪些目的，我们自己需要一个非常清晰SOA业务蓝图和技术参考模型，这个一会儿也会在后面主题当中更多展开，我们需要对自己业务流程的梳理，有了这些以后，需要把流程构造出来，需要面向流程构造方法，把业务流程造出来，在这样的流程配置出更大的流程，具体实施当中去定制、配置，有了这些以后，我们在运行期需要对它进行管理。

程朝晖 : 比如业务服务的管理，整个的动态的服务如何被注册等等这些应用当中，不断帮助运营管理。一直有治理监控的方法框架，能够帮助我们在这样一个平台下，不断梳理优化这个业务，使得组织里，服务流程当中，能够持续被改进。这样一套从无到有到优的规划设计，从无到有，到实现的时候，一直到它的运行，到持续的优化和完善，有这样一套方法去帮助我们实施具体的项目。在这里在后面的主题当中也会更多的探讨。

程朝晖 : 总结一下刚刚我说讲到的这些内容，SOA这样一个时代，其实大家都没有怀疑，不然今天不会有这么多人来到现场。

程朝晖 : 因此可以看到SOA已经到来，我们抱着已有的技术作坊式的方法继续抱着，一种观点是这样，还有一种方式就是我们学习合作用更好平台和方法去找到我们自己核心业务的模块能力，去构造，并且让这种核心能力，通过大家的合作，给客户最大家知。

程朝晖 : 第二，我们这样一种到来的时候，我们应该怎么样去看待这件事情？从业务的角度，需要组件化、构件化、分工化的方式，并且通过流程的方式把业务做出来。技术架构上，我们要找到真正符合业务的规范，不然做出的业务模块很好，最后实现是一堆代码，无法被大家很好的协同起来，被更高层流程配置起来，装配起来。同时生产和管理的时候，更好的不要说一行一行代码去写，软件生产的时候，就能通过图形化的方式，就能够把这些模块构建组装起来，一体化开发、运行治理平体上进行生产管理。

程朝晖 : 可以看得到，整个SOA需要通过一个完备的标准化的这样的商业平台，去承载我们的软件生产模式，也能够像福特、波音向更高效的模式生产，能够让我们效率更高，质量更高。通过平台，通过个性化、标准化、业务化生产方式，把应用做起来。同样我们不仅需要这样的平台，同时我们还需要有这样的架构规范方法咨询和服务，能够大家一起看到把这块技术方法怎么有效的去学习吸收，转化成自己的业务的能力和技术的能力。所以需要这样一种咨询和服务的保证。

程朝晖 : 最后，SOA总是在改变生产方式，改变商业模式，这是为什么？一定是为了提升生产能力，而生产力永远体现在更高的效率，更高的质量，更强的灵活性以及更低的成本基础上，所以我们不断的在这样一个SOA到来的时候，去面对这样技术的潮流，去迎接它，改变我们自己。相信我们在这样一种模式下，给我们带来机会情况下，我们共同找到自己的定位，把自己的能力发挥到最强。并且通过大家整个社会协作，形成巨大力量，将来甚至于能够抗衡，包括全球的这些最大的软件厂商，相信都不是问题。谢谢！

主持人 : 程先生跟我们分享了SOA的企业架构与规范，我们现在和观众席的朋友们互动一下，我们有两个问题，对于踊跃提问者，我们可以赠送精美的礼品。

现场观众 : 程先生你好！我有一个问题是关于SOA实施问题。SOA是抽象构件的时候，大家什么力度是最好的？比如我们定位的功能，还有它的参数。

程朝晖 : 谢谢你的问题！为什么很多人讲SOA是业务问题，很多人站在这个角度看的。大家如果留意一下，来之前有一段录像，就是普元软件董事长讲到了，我们需要通过这种方法，我们能够梳理清楚的就是几十个流程，几十个我们的业务服务。但是我们不断积累，两年、三年后可能就是几百个，一直到未来可能更多。所以首先我们需要一套方法，这套方法就会在后面的演讲中给大家展现。我们需要自己看清楚，我在我的应用软件，以及跟我相关的客户需求，以及我的合作伙伴这一块，整个业务蓝图是什么，应该分成哪些业务模块，这是自上而下的方式去看。不断的梳理，如果你自己都不太清晰的模块，看看和哪些合作伙伴去合作。

程朝晖 : 另外就是自顶向下的方式，也基于这样的业务。另外通过业务流程不断的从粗到细去梳理。另外如果想不清楚，未来流程我怎么知道未来三年、三个月的流程，我们可以现在去看，我们基于技术构件、平台构件，在基础的层面把业务模块梳理出来。这些梳理出来，不代表就可以被很好的归纳或者说提取出来，而它是需要在我们实践当中，我们帮助交通银行几十个项目在做的时候，它们会有清晰的分析，这是自顶向下通过实际项目，来去不断确定我的力度构建，这个过程当中，为什么发现这个力度不行，自顶向下，当然这个需要一个平台工具来帮助它梳理进行分析。一会儿可能我们这边的OASIS技术专家会跟您分享这个方面的问题。

现场观众 : 程先生感谢您的精彩演讲，请教两个问题。第一个问题SOA的这种架构，一般适合用于哪种业务，举个例子，SOA可能在保障灵活性和可扩展性的前提下，会损失一定的效率问题。在这种情况下，对于高平台访问应用是否适合？有没有更好的解决方法？比如类似于网银这样的操作？会不会有这样的效率和灵活性的矛盾存在。

第二个问题，既然是为了支持它的灵活性，从功能上来讲，从业务层面也是一种个性化的。对于在展现层，基于SOA架构能提供什么样的方法或者工具或者理论来支持展现层得更好的个性化。同时也要兼顾效率的问题。谢谢！ :

程朝晖 : 两个问题，我就一并回答。第一个就是灵活性和效率的问题，这个矛盾是永远存在的，我们怎么平衡好这样的一种矛盾。其实SOA本身确实站在业务层面更高层的抽象，服务层抽象。在这个上面进行组装。但是它其实最底层实现的技术，还是我们的可以说JAVA技术，或者图形拼装代码技术，逻辑技术，或者是一个C++技术，对于这个实现技术没有限制。因此你可以对于性能要求特别高的地方，这是一个平衡，你的这个模块的灵活性又不要求那么高，它的稳定度比较高的时候，可能对这个力度会大一些。

程朝晖 : 首先业务构建的力度大一些，这个力度大一点之后，里面的实现技术你可以去用，所以这个本身SOA是提供了这样一种灵活性，它本身在制定这个标准的时候，当时0.95标准出来的时候，最早是IBM比较主动比较积极，参照WPS里面的架构来做的。到了0.95以后，整个被彻底推翻掉了，为什么？因为在设计的编程模式里，在SCA里，连递归都没有，所以整个被推翻掉了，成立了现在的非常好的SCA的模型。

程朝晖 : 回答你的问题，这是一个矛盾，我们需要在具体的业务上面去看，怎么去平衡这个矛盾。SCA本身不限制这个技术。

程朝晖 : 第二个，你提到在展现端能不能更好的发展，更具有个性化，我们可以看到现在的POT技术一定会被淘汰掉，现在客户用也根本用不好。因为它太重了，太复杂了。并且在整个页面端，它对于客户需求的把握其实还没有到位。客户需要可能是比较轻巧、灵活比较丰富的展现，现在这些基础之上，一方面技术也在发展，另外在这个基础上出现一些框架，比如EST等等有一些框架帮助我们来做展现端方面。在这个方面，普元也有非常大的投入。有一些技术我们还在不断发展，我们目前跟IBM美国实验室，也是开始启动这个项目，这个项目就是做展现端的整个拼装，当然将来会变成一个标准。什么意思呢？就是现在大家都知道这个后面逻辑都是拼装起来的，而我的页面就是写最头痛的这些代码，将来页面端也是拼装出来，当然这个技术还是在发展，以及在标准化发展当中，普元也是走在非常前面的。谢谢！

现场观众 : 程总你好！现在标准还没有发布之前是怎么处理的？今天早上收到邮件，称这个项目目前被批准了是吗？

程朝晖 : 前两天还得需要72小时，跟救援一样，非常高兴能够被批准为顶级项目，普元也是付出了一些努力。交易的问题，现在可能在里面，SCA也在制定。现在应该说这些东西对于使用原US的客户全是透明的，并不会一定要去看到里面的标准是什么样的，基本上在你用我们的运行环境服务的时候，现在已经完全可以支持交易的处理，这个都是没有问题的。但是将来在这个框架下，交易安全的这些标准出来之后，它会有标准，标准的好处就是不再需要把这些东西由普元自己实现，可能再更高层面形成标准之后，然后有相应的灵活性。

程朝晖 : 回答你的问题，是一部分用到了，因为跟IBM一样，在这个里面我们贡献了一些需求、代码，同样我们的产品当中也是用到了一些代码。

现场观众 : 现在构件服务安全是怎么处理得？

程朝晖 : 这一块，我刚刚已经说了，这个平台对你来说是透明的，具体产品怎么实现的。我们产品是多种技术，里面包括用到了一些交易安全这些机制。

主持人 : 更细节的东西，大家可以在会下交流。下面我们还会有更多更精彩的讲演。

主持人 : 我们说现在国内讲SOA厂商，会从ESP入手，利用ESP作为切入点，但是这种对ESP的重视，往往会导致SOA迷失，因为这种观点基于一个假设，就是很多服务已经存在了。这些真的存在吗？当然不是。接下来请出普元产品软件管理工程刘尔洪先生，他带给我们的演讲题目是SOA中国关键任务是服务构造和业务化流程。同时指出服务构造的难点和解决方案。

刘尔洪 : 各位来宾大家下午好！我今天跟大家分享的主题是想来解答一下为什么服务构造和业务发展流程是SOA中国发展的关键任务。在讲这个之前，我想我们先来回顾一下利用SOA我们到底要实现什么。

SOA的目标，我相信大家都比较清楚，实际上它的终极目标是想实现一个敏捷型的企业，什么叫敏捷型的企业呢？就是我们企业在很多年的IT建设过程中，无论是新建的还是怎样，通过不断积累，会形成一大堆原来的IT系统。原来我们企业的模式，就是说，可能我们建一个系统，它的生命周期很短，我们要一遍一遍的重建。SOA里面，就是我们能够把企业IT系统真正的能够作为资产，就是未来我新业务的建设都是在我原有IT资产的基础上，形成对业务支撑迅速响应能力，有一个数据统计，我们现在IT支撑能力，响应变化能力，实际上落后于我们实际业务变化能力的7到20倍。所以SOA本质上是建立一个敏捷型的企业。
:

我记得2002年的时候，当时中国EAR这个概念刚刚兴起的时候，大家知道当时EAR当时红红火火好几年，各个厂商、用户开口闭口都是EAR，主要是一些大的企业，试图通过EAR解决类似的问题。当然这个里面包括集成的问题。大家可以看到，后面我们EAR真正应用并不是很好，所以这几年IDC的观点，它是讲的我们在接受SOA的同时，还是能够以务实的思路去看待SOA。 :

刘尔洪 : 刚刚有位朋友提到什么样的应用需要SOA，什么样的应用不需要SOA。实际上不是所有的应用都需要SOA，如果我讲的很简单，我这个企业可能就是一个单一部门，单一的业务，这个时候不一定需要SOA。当然如果我有很多业务部门，有很多供应商，我需要它们快速协同去工作，那么这个时候SOA可能就比较重要。SOA的理想是什么呢？就是我们现在很多去讲我们的SOA解决方案的时候，基本上和这个图大概类似。就是原来有很多的遗留系统也好，新建系统也好，能够通过ESB，把原来的系统服务，先是把我遗留系统的服务能够重新包装好，通过ESB可以注册管理起来，同时跟其他的信用交互的时候，我有一个物流交换，还有通信转化机制，最后通过BPM流程编排，就很容易把一些服务组装成一个新的业务。这个实际上是一个理想的情况，为什么这么说呢？这个是把问题简单化了。我想通过一个具体的案例来讲一讲为什么津津有ESB，或者在ESB上加上BPM，依然不能解决我们说的目标当中要实现敏捷型的企业。

刘尔洪 : 我不知道大家对SOA有什么了解？做大的服务等级的开发商或者是我们电信或者金融的客户应该都会经历这个过程。我这个里面举了某一个电信运营商引入SOA的这样一个过程。这是一个很自然的，因为电信的运营我要不断的精细化运营，为客户提供差异化服务，肯定给客户分类，对不同等级的客户提供不同等级的服务质量，进而我可以跟他签订不同服务，这个肯定是发展方向，而且我们现在正在发生的。但是如果我们去看这个例子，就是说，如果某一个运营商引入SOA，我们把它看成其中一个业务，比如传统的固网，DDN，我不知道大家是否知道DDN，就是一个数据专线。原来我们在没有SOA的时候，实际上你只要告诉原点、终点，就是从哪到哪，电信局就给你拉通了，现在有了SOA指标就不一样了，我要签这个合同的时候，要把它的接通率的保障，是不是提供备用量，以及它的服务的优先级开通的实现，我都要作为要求的。如果你运营商达不到我这个要求，我可能付给你的钱是比较低的，如果你要达到这个要求，我可能付给你的代价比较高。自然是这样，大家想想原来我们在证券行业，大家可能炒股，我们下单的时候，大股的从证券公司到交易中的线路都是都是通过DDN专线，如果这个线断了，这个是什么后果？后果很严重。我们看看它的演进过程，时间关系，不具体讲业务过程。大家可以看到因为要引入SOA，那么对产品销售的流程，前端会有这样的变化，这个变化就是原来我直接受理DDN专线业务，现在变成我前端要有客户经理的参与，跟电信的这一块沟通，因为它想要的服务保障，我现在后端资源不一定能够保障，所以大家看，有一个人就表示人工的环节，这个里面有很多拓展图的，就代表自动环节。大家看我这两个人工活动，就划分出多了三个人工环节，多了一个自动环节。后端我们开通过程中也会有很多变化，我刚刚讲了售前，实际当中，资源配置上，会根据SOA里面不同客户不同类别，我就要走不通的开通流程，所以这个流程变化是比较大的。

刘尔洪 : 我们就对这样的案例做了梳理，这个梳理结果我给大家看一下，总共把整个销售和开通的这项业务过程中，所有涉及到的服务我们全列出来了。这里有它的状态是需要修建，还是重用，还是需要改进。最后的结果是我们需要改进的有53%，就是整个的服务，因为引入了SOA，我这个服务不合适了，要去调整这个服务，有53%服务需要调整，只有27%服务可以完全重用的，还有20%服务需要重建。而且从这个里面，我们可以得到两个结论，一个结论就是我们在管理流程演化的时候，对IT系统的支撑，对流程这个环节，不仅仅是说我能够自动的流程编排好就可以了，而是这个里面会存在大量的人工。为什么强调这个人工环节呢？这个前面无论是放的片子，还是程先生都讲了，中国跟一些发达国家是有很大的差别，这个差别实际上如果我们从流程的角度来看，在人工这个环节差别是最大的。为什么？因为人工环节它会涉及到组织和人，我想所有的人都会有这样的感觉，中国只要涉及到组织，涉及到人，这个事情就变化多了。因为领导会随时让你干一件可能是原来工作不相关的事情。所以在我们看了这个流程演化过程中，实际上你会发现有大量的人工环节。

刘尔洪 : 第二，我们有高达73%的服务，需要更改我们的内容或者是新建。所以，大家都知道，如果开发做得比较多，如果我们说高达73%的服务都需要重新建设或者是需要改进，对我原来系统意味着什么？如果没有很好的服务架构，基本上这个系统就会出现问题。

刘尔洪 : 实施SOA的挑战和难点，从非技术层面来讲，我觉得最大的挑战是企业管理上，就是流程是否规范，组织是否健全，是否稳定等等这些方面，我认为是很大的挑战。是不是稳定可能还好说一些，主要是你这个流程化情况怎样，如果从技术层面来讲，刚刚我讲了，我们管理流程需要不断的演进，而作为一个企业来讲，无论你今天做到什么样子，也许你今天管理水平很高了，但是你还是要持续的优化，优化你的流程，调整你的流程，在这样的环境下，随着管理精细化，你的服务是要求越来越细，要求越来越提供比较细致的颗粒化的服务。

刘尔洪 : 刚刚有个朋友问到了服务颗粒化问题，我认为这个问题不好讲，尤其中国这个环境里。因为你很难有一个非常稳定的，我就是这么大颗粒度的服务就可以了，我们刚刚谈了中间出现的很多管理流程的环节，都是要有相对应的服务，这种情况下，作为服务这一块，必须要有灵活的架构是第一位的。当然我规划的好，抽象的好，相对来讲，也可以让它适应度更好一些。

刘尔洪 : 第三，刚刚我讲了服务的颗粒度的问题，就是管理流程演进，需要越来越流程。如果实现我们说的SOA目标，就需要业务层面上，要具备配置流程。现在我们讲的很多BPM的解决方案，实际上是具备这个能力的，更多是编排一些自动活动。如果对人工的流程多了，很多一些比较复杂的处理，可能也很难处理。

另外，在中国人工活动是具有它很复杂的特性。 :

刘尔洪 : 比如说，在中国有很多代理、代办、督办、会签等等这些和人工活动相关的环节。这样一些处理和我们很多流程规范里都不会有这些内容，而是它只是存在于中国这样一个特殊环境中。我们要想能够达到这一点，还是需要具备很好的适应中国复杂人工环节的特点。

刘尔洪 : SOA的中国关键任务，我的论点是服务构造和业务化流程这两个问题。

刘尔洪 : 第一，我们怎么样建立高质量、可扩展、易管控的服务。

刘尔洪 : 这个我们的论点，就是服务的颗粒度，要很好的根据我的需要去变化。所以你的扩展能力一定要强。质量就不用说了。可管控是什么意思？就是要在服务的全生命周期，都要有很好的管理，实际上刚刚程朝晖先生也讲了，从管理技术和业务这三个角度，我们要能够达到一个矛盾的统一。

刘尔洪 : 第二，业务流程需要强大的业务配置能力和人工环节处理能力。

刘尔洪 : 讲到这里，有的人可能会问，我能不能通过规划去解决我的服务的颗粒度的问题。这个我刚刚已经回答了，就是很难通过规划去解决。为什么？中国这样一个环境下，在全球都是很难的，有的很多变化是我们不可预计的。比如中国电信行业，在近十年里，三番五次的不断的重新组合，它每次重新组合，对它原来的组织机构、职责、业务流程都产生翻天覆地的变化。就是你要按期规划做得再好也没有用。一旦变了以后，你发现原来规划的服务都没有用了。所以从规划角度，通常会有自上而下和自下而上两种规划的方法。

刘尔洪 : 实际上在中国更适合的，还是说我有一定的自上而下的规划的基础上，更多是采用自下而上的去规划服务，可能更来得可行一些，自下而上的意思就是我先看我现在看得到的一些东西，现在看得到的系统遇到的一些问题，比如我现在要走CRM，我应该提取哪些服务，可能这些服务和我其他系统有一些什么关系，这个可能从成本化收益的角度，可能投资回报率更高一些。所以，我们很难从规划的层次去解决这样的问题。

刘尔洪 : 我们下面来看看服务构造，为什么会比较困难。这个里面我想大家在座的可能对原来我们没有SOA的时候，建设应用系统的时候，有很多的体会。我不知道大家很多都存在这样的问题，就是越大的项目，达不到项目的预测概率越高。你会发现失败率是比较高的。我调研过很多的公司，基本上都存在着这个问题。

刘尔洪 : 第二，项目实施的周期和质量不可控，常常拖延周期和发生质量问题。

第三，技术人员很辛苦，但是你会发现价值得不到体现。进而，会引起我们的技术人才流动比较大，项目质量的成功也是更多取决于我们每个人参与这个项目的个体素质。
:

第四，难以进行知识转移和知识承接，知识积累比较困难。也就是说，我如果参与一个项目，我积累了很多东西，我要交给另外一个人，在这个基础上去发展，这是一件很困难的事情。 :

刘尔洪 : 最后，服务构造的标准化的问题。在电信行业里有一句话，不知道大家是否知道。就是真爱生命，远离BOSS。就是指做BOSS这样大的一个系统，工程师都很辛苦，但是常常因为最终交付的东西达不到用户希望，所以大家辛苦的价值没有被充分体现出来。这个问题从哪里来的呢？我想分三个层面来看：

刘尔洪 : 第一，看一下软件规模和生产率的矛盾。

按照软件行业的经验，用户对我们的要求，移动的BOSS规模，两年之前是大于360万行，那个时候我记得我们有一个大的开发商，它一共有四个版本，等于1600万行，这个公司要维护1600万行代码，如果按照上面顶级标准去算，不讲上线、部署、推广，也要3000人月，电信CRM是大于400万行，超过3000人月，开发期一般6到12个月，前一段时间我们CTO在上海站演讲，讲到国内可能用户给你1/10价钱让你做一个10倍于美国这样的环境复杂度的软件，实际上从这个数据上就可以看得出来。
:

在这样一个条件下，我们交付的软件，如果没有一个很好的方法，你是不可能像我们刚刚讲的那样，有很高质量很低成本，而且也没有用户付得起这个钱。我们解决这个问题的有效方法，实际上刚刚最开始沈先生在他的报告中已经讲了，传统行业给了我们很好的借鉴，一个就是我们要能够不断去提升我们的复用能和生产工艺的改革，生产工艺的改革是任何产业发展到一定阶段时候，必须要经历的事情，而且谁能在这个里面抢得先机，谁就具有最核心的竞争能力。 :

刘尔洪 : 第二矛盾，可扩展、快速变化和高质量的矛盾。

也就是在不断变化环境下，我还要让它高质量，这个事情比较麻烦。大家做过项目实施的都有体会，用户需要你改这个，改那个，还要把文档做好，测试要做得很充分，还要让软件质量很高，这个也是很大的矛盾。要解决这个矛盾，必须从技术架构入口去解决。原来可能我们有很多的用户是不关心这个架构，我那个时候和他们沟通，我说如果我给你一个选择，今天我给你两种方案，一个方案是百分之百把你业务功能做出来，我的扩展性比较差，稳定性比较差。还有一种方案，把你50%功能做出来，但是我告诉你另外50%业务功能稳定性比较好，可扩展性比较好，他们一般会选择第二种。这就说明非功能性需求有时候比功能性需求更重要，因为第二个业务功能没有完全实现，但是非功能性需求做得很好，这个就靠我们软件架构保证的。也就是软件架构的存在，之所以我们需要一个架构，就是因为我们有很多下面这些非功能性需求需要解决，它的可扩展性、性能、稳定性、可维护性、可管理性，尤其可维护性、可管理性架构设计的时候没有考虑，你等系统做完了再考虑，是一定做不到的，你会发现维护这条系统很麻烦。 :

刘尔洪 : 第三，管控问题。

我想讲一个全程管控，还有从软件生命周期来看，从软件的需求开始，设计到开发，到测试，到链条，到上线，到后面的维护，到再使用全生命周期管控，实际上软件行业做得很差。我刚刚讲的软件项目，取决于每一个工程师个体能力，实际上就是一个这样一个缩影，就是做的过程当中，我做什么样子没有人可以知道。这个问题怎么造成的呢？我觉得最重要是软件生产复杂度太高造成的。任何一个东西太复杂了，我们都必须要借助于工具去解决。就跟我们今天，如果面临管理一两个客户，你可能脑袋里面肯定记得你不需要任何工具，你要管理上百个上千个客户，肯定是需要一个工具，如果像电信运营商管理几千万个客户，就必须要有一套IT系统，当你管理的东西达到一定复杂度的时候，一定需要这个工具。软件复杂度问题，因为它这么复杂，所以造成了这样一个管控的难题。所以要想去解决的办法，必须要依靠工具，光依靠工具还不行，必须还有一定的标准。 :

刘尔洪 : 我们看到三个层面的问题以后，我们怎么样解决它？

刘尔洪 : 第一，需要建立适合SOA的服务架构。

刚刚我说了架构重要性，就是我们可扩展性、管控性的一部分，都是需要架构里面解决。这个架构要去解决，怎么解决？比如说可扩展性，就是说我们需要从不同的维度去看架构的时候，都必须是一个可扩展的，我们看层次的时候有层次结构，从管理的视角，也有一些其他的问题。要都做到不是很容易的事情，大家平时更多的是关注我这个功能结构是不是做得很松散，但是层次结构可能就不够。普元提供了很好的解决方案，无论从哪个维度看上去都是松散耦合的结构。 :

刘尔洪 : 第二，将复杂的未知的服务能够分解为简单的收敛的稳定的单元。 如果我们今天统一都用汉字，大家知道中国常用汉字就5千个，汉字上组成词组，汉字和词组组成文章，这样就可以做成每个人可以理解的文章，我们能不能把复杂服务，分解成稳定的单元很重要。

刘尔洪 : 最后采用标准化的技术构造，形成天然的SOA服务。

刘尔洪 : 第二，建立统一封装的平台化架构。我们最后要有统一封装的平台化架构，这个不仅仅是复用问题，我们作为一个平台完备性是非常重要的，当然还有一个很重要因素，既然架构这么重要，怎么样很完整的复用，最好有一个平台化的架构。

最后我们需要一整套方法，去解决我们前面提的这些问题。 :

刘尔洪 : 流程平台的挑战和问题分析，如果要建立管理体系，从哪几个角度去建呢？就是这几个要素，流程、组织，组织职责是什么，流程是什么，人是什么，KPI是什么，建管理体系就是这样。从这个角度来讲，大家可以看到，在管理上，实际上这些要素都是经常变化的，无论组织也好，人也好，KPI也好，都会经常不断变化，所以我们在去实施SOA的时候，需要流程平台，这样就能够在业务层面上能很好的去配置我们刚刚讲的四个方向的灵活变化，今天由于时间关系，我不仔细展开讲了。等一下我们还有演示。

刘尔洪 : 我再讲一下，我们去实现业务层面配置流程和传统模式有什么区别。

刘尔洪 : 传统模式下实现一个业务流程，业务流程提需求，到技术部门去消化以后去设计，设计完以后，开发测试部署上线，最后给业务部门去验收。整个流程很长，沟通成本很高。如果我们在业务层面可以配置流程，它的实现模式是什么？实际上就变成了前面除非我在流程的实现的环节里面，有我新需要的服务，否则它在业务层面上全部可以自动调整，包括部署，包括自动的部署。完全就是实施部署的系统，我这个流程KPI也好，组织也好，人也好，变了以后，业务流程的页面上就可以做上配置，马上就可以测试验证去发布了。

刘尔洪 : 不一定需要技术人员的参与。

刘尔洪 : 总结一下，第一SOA的规划很难用单一的自上而下或者自下而上的方法，而且很难通过规划去解决我们的服务颗粒度的问题。所以我们的服务需要一个很好的架构。

刘尔洪 : 另外SOA关键挑战在于，第一，是管理流程的规范性建设和逐步演进的需求。因为管理流程的逐步演进是会要求你整个IT支撑系统，要能够具备支撑它的能力。在这个能力里面，有两个核心关键问题，一个就是服务的构造，我要足够的灵活，第二我要能够有足够的适合中国国情业务化配置能力的流程。它的解决方法，就是我们能够有一个适合SOA架构的这样一个平台的一体化的解决方案。谢谢大家！

主持人 : 感谢刘总！

现场观众 : 刘先生你好！我想问的是你刚刚说服务很难被构造出来，你说需要一个很好的服务架构来帮助SOA来实行。打个比方，可能这个比方不是很恰当。要建一个很漂亮的房子，房子外表很漂亮，但是内部的装饰，你的家具都不是很好，那么怎么让你的房子从里到外让人都感觉到很舒适呢？

刘尔洪 : 我不是说服务不可能被构造，只是中国这样的环境下，你要去构造一个很稳定的服务是很困难的。为什么呢？刚刚我说到了，随着管理细化，你会发现管理细化到管理流程细化，今天可能三个环节，明天可能细化到八个环节，新增加五个环节，一定会访问原来服务系统，这样你会发现，原来提供的数据可能会少了，我再增加一些内容，那这些内容一增加，你又会发现原来服务会需要重新再去增加一些内容或者改进一些服务工作，尤其在中国这样一个日新月异的变化之中，要想通过我自上而下的规划方法去建立一个稳定的服务，实际上是不可能的。这样的话，服务的架构问题，就是我怎么样能够有一个可以适应变化的服务结构就会变为核心问题。谢谢！

现场观众 : 我想问一下SOA现在虽然是一个新型的规范，但是肯定存在很多不足，您能不能谈一下SOA在哪些方面存在不足？

刘尔洪 : SOA的理念我一直认为很好，实际上我认为SOA不仅仅是概念，我记得2002年我在参加中国电信的业务支撑系统规范的时候，当时北方电信事业部的他们在谈的时候，那个思路和想法跟我们现在很多SOA提供的很多想法都是类似的。我觉得这个思路肯定是代表未来的方向，那我去认识这个问题，第一我是觉得SOA也不是说是解决所有的问题，因为它实际上要解决的还是在一个比较高的层面上，能够去打造一个敏捷型企业的问题。不足的地方，我觉得可能我们很多时候做到了，实际上并不像想的那么好。刚刚我跟大家分享了IDC观点的时候，也是讲到了他们的一些认识，IDC也是通过很多调研以后，来讲它的观点。它的观点也是说，我们去实施SOA的时候要从实际出发。包括我们自己的看法，很多厂商推SOA解决方案的时候，很多时候是从技术层面来论述很多问题。比如说，我今天讲的业务流程问题，如果你不重视人工环节，如果你不重视流程业务化配置，你说能叫SOA吗？很难实现SOA的。当然我觉得更多的还需要在座的大家一起去努力，我们也看到这个规范正在逐步成熟和完善，任何东西都会有不足，但是这还是非常主导前进的方向，大家还是随着这个方向多前进多思考。谢谢！

主持人 : 我不知道大家是否还记得程朝晖先生给大家分享SOA的架构规范的时候，其中有一张图片，里面是一张图，是SOA的生命周期，有谁能说一下这四个部分是哪四个方面。

现场观众 : 第一，规划，第二，设计的阶段，第三，部署，第四管理阶段。

程朝晖 : 73%的对。

主持人 : 分别是服务的规划与设计，服务的构造与流程，第三服务的运营与管理，第四服务的管控与治理四个方面构成SOA实施的全生命周期。对于当前更迫切的任务就是SOA服务规划与设计。

主持人 : 近一千人坐在现场一起做操也是非常壮观的场面。接下来我们请出OASIS SOA专家杨玉斌先生，他为我们带来的题目是SOA服务规划设计与构造，并结合10分钟演示，帮助我们回答如何通过梳理业务流程筛选服务，筛选出来的服务如何定义，如何将构造的服务，组装成完整的SOA应用，以及这些应用又将如何得到有效的管理与监控。杨玉斌先生是一名非常资深的架构师，同时也是普元SOA中间件产品中的核心部件EOS服务整体架构的参与者，有请！

杨玉斌 : 各位来宾大家下午好！刚才主持人已经给我把这个饼图给大家介绍了，下面的嘉宾已经回答了。嘉宾回答的是对了75%，还有25%不正确。

杨玉斌 : 第一，规划与设计，在规划与设计完成SOA的策略与愿景，业务蓝图的规划。

第二，愿景规划完成以后，我们需要将服务构造出来，然后用流程的方式把这些服务编排。
:

第三，构造出来服务以后，我们就需要来进行管理。
:

第四，刚刚嘉宾漏了一点，就是对服务进行监控和治理。服务运行效率怎样、性能怎样，我的流程它的整体的响应时间是不是满足我规划中设定的目标。 :

杨玉斌 : 今天我主要给大家分享两个部分，第一是服务规划与设计。

服务规划与设计主要讲的内容就是方法论，我们用什么样的方法来规划SOA中的业务蓝图，怎样梳理流程进行服务筛选等等。如何来规划SOA企业的业务蓝图呢？我们提供的一种方式，首先是将企业涉及的业务领域预构件的方式体现出来，比如这是一个钢铁行业的规划，分成几层，比如L4、L5层，通过业务领域的方式规划出来，并且通过一些构件建模的方式，把业务领域拆分成一个一个业务构件，这个就是拆分方法，首先将业务横向的维度是业务领域划分，纵向决策是决策控制执行，然后综合评估企业的业务蓝图。这种评估方法也是参考了业界成功的模式，也是横向的维度和纵向维度来划分。通过一些价值链的分析手段，确定企业差异化业务和一般性业务，来确定我企业的一些核心竞争力。 :

杨玉斌 : 在具体实施SOA的时候，需要找到企业中差异化的业务，优先投资差异化的业务。比如将这些差异化的业务作为一个SOA试点项目来进行。规划完业务蓝图以后，我们需要将这个企业的业务流程进行梳理，也就是刚刚我们副总裁刘尔洪也讲到，企业业务流程核心几个元素有组织、人工活动、KPI等等，一个流程会跨到企业多个业务部门，涉及到很多人工环节、自动环节。在规划设计这些流程的时候，还要关注流程的KPI，就是它的服务水平的承诺，比如服务响应时间多久，有多久能够完成这个服务，这个服务客户满意度怎样，我需要把这些信息定义好，这个是业

杨玉斌 : 通过流程梳理，我们将一个企业级业务梳理成一个一个子流程，落实到不同业务域中，这个在企业体系中可能是不同的系统，比如有的落到ERP系统，每一个字流程又划分为人工活动和自动活动。我们找出这些服务，可能是良莠不齐，不一定是满足我们需求的，但是我们还是需要用一些方法和原则来过滤这些服务。

杨玉斌 : 服务筛选方法，可以采用自顶向上的方法或者自底向上的方式。自顶向上的方式，相对考虑的简单一些，我们设计服务的时候，还要考虑到其他系统，有些应用已经提供了一些服务，而且这些服务是满足需求的，但是有些服务是需要通过服务组合的方式才能满足这个流程需要。服务的组合，我们就可以采用SCA技术和标准，来将我们企业已有的服务或者已有的业务路线组装成新的服务，如果分析到我们有些服务是没有的，我就需要在这个服务开发过程中具体开发。

杨玉斌 : 服务还是必须符合一系列筛选原则，主要满足业务需求和技术需求，业务需求必须要可以重用的，这些服务必须要有具体业务语意的，比如短信平台上大家看到嘉宾的问题，这些算不算服务，但是从SOA整体来看，这些并不算服务，做一个服务必须有业务语意的，必须是跨边界，可以重用的，这里不一一展开这些筛选原则。

杨玉斌 : 当通过筛选以后，需要用一种方法把服务定义出来。定义的方式主要是关注服务的功能性需求和非功能性需求，功能性需求，这个服务参数是什么，刚刚有嘉宾问到参数具体到什么类型，业务人员关注的肯定不是具体技术性的，这里定义的肯定是某一种业务质体，比如订单对象，或者输入是订单向，或者查询一个订单的列表，返回到订单列表，在功能定义的时候，不会关注到具体的技术。

杨玉斌 : 另外服务，刚刚讲到服务和服务之间依赖的数据，SOA这种应用里面，我觉得服务是跨整个企业的，可能会涉及到多个业务系统，比如有的是CRM系统，HR系统，ERP系统，同一个数据存在不同系统中，这个数据必须要有统一体现，比如建立统一数据系统，规范统一这些数据，有可能采用一些工具进行管理。

杨玉斌 : 刚刚讲到服务功能性的定义，我们还需要定义一些，从业务角度定义非功能性的特性，比如吞吐量，比如我的服务是每秒钟享受几万条交易，比如300条按照一般处理方式就可以了，对于一万条数据库表格的设计等等都需要做特殊的处理，才能满足这样的时间。

杨玉斌 : 刚刚讲到服务的定义，拿到服务定义以后，怎么样让服务用具体技术实现呢？需要将服务分配到特定构件中，比如将已有服务组装成新服务，定义服务的访问协议，其实SOA这个体系，服务并不仅仅只是从技术上，它是对外，有可能是一个WEB 服务或者EMS。如果系统和系统之间能够认识这样的协议就OK了。

杨玉斌 : 在SOA提供了绑定模型，可以讲一个服务包括到任意一个协议，你只要配置一下，就可以把服务绑定成WEB服务或者其他的，这样客户端可以灵活的选用自己要调用怎样的协议。

杨玉斌 : 当我这个服务运行一段时间以后，我可能需求发生改变，或者我的流程满足不了我的SLA这个定义，需要重构这些服务，这样就需要一系列的原则。比如一些服务已经在企业中得到了大规模的应用，我有很多流程使用了这个服务，如果我要重构这个服务，改造这个服务，就意味着大部分的流程不能用了。这个是很严重的问题。所以流程重组的时候，对于已有的服务，一般要分析这个服务是不是还被重用，如果被重用不能随意更改，只能包装分装出新的服务，尤其设计服务的时候，要考虑到服务力度不要太大，如果太大，出现这种情况，我看到一个客户，同一个服务有三十多种版本，我觉得这个就是业务规范上的问题了，把服务规范力度小一些，可能重用度好一些，这样维护成本少一些。

杨玉斌 : 今天简单给大家介绍每个环节采用的方法手段，其实是非常简单的。在具体实现的时候，我们需要有一整套非常成体系的方法和过程以及模板来保证。比如流程梳理，业务流程定义侯选服务，服务筛选原则服务列表，服务设计的时候，我怎么样将服务落实到构件中，应该遵从什么设计方法，有哪些原则需要遵守。这是我讲的第一部分内容，给大家简单介绍服务规划和设计的一些方法。

杨玉斌 : 接下来介绍服务的构造，结合我们的产品做一下演示。

我们提供了一套完整的服务构造，服务运行和服务监控的开发和运行监管平台，我们的服务构造提供业务构件设计，数据模型设计，服务设计、服务开发、服务审计。每个业务域产生很多个业务构件，需要规划处企业的数据模型。服务运行，服务运行容器，构件运行环境，基础构件库，一个服务上线了，但是还是有BUG，能不能让系统很容易的升级，不要将系统停掉，结合我们的产品，给大家演示一下具体过程。 :

杨玉斌 : 这是一个迷你的CIM系统，是企业中的一个业务域，我们将CIM拆成一系列的小的业务构件，比如客户管理、订单管理、产品管理等等，除了业务构件以外，还要设置重用的业务构件，比如公共的业务构件中，定义数据模型，比如设计到公共模块，公共信息的定义，包括这些数据模型，但是数据模型中，建出来的形式要符合SDO规范的，SDO规范中如何描述这个数据模型，当然不是泛意义上的规范，还有一系列的规则和限制。我们在数据模型定义中，是完全符合SDO数据规范标准的。比如支持实体定义，属性定义，支持实体和实体间的定义。这个就是我们的数据模型。

杨玉斌 : 当我们建完数据模型以后，我们需要进行服务设计，刚刚我们在服务流程梳理的时候，我们发现从自顶向下的方法和自底向上的服务，我们产品都支持这两种服务模式，你可以完全新开发一个服务构件，根据这个服务构件生成实现，我们也可以自底向上的方式，比如将JAVA构件自动拖入进来，形成SCA构件，这是一个构件系统，我们这些构件是从底层的逻辑流构件装配起来的，我们希望将订单服务构件提供服务暴露出来，我们这里只要将订单服务构件给改一下，只要添加一下，就不需要修改任何银行代码，就可以支持这个WEB服务了。这个就是我们的SOA提供的规范服务能力。

杨玉斌 : 我们从这么小的粒度的运算构件，装配出大粒度的具有运算反应粒度的构件。这些构件经过我们严格测试，而且这些构件在我们大多数客户中得到应用，它的质量、可扩展性和管理性都是非常好的，这样我们在构造这些业务模型的时候，就不需要重新再来，只需要依靠这些老的服务构件重新用就好了。

杨玉斌 : 接下来看一下服务质量，我们构件完服务以后，这些服务都是一系列的小粒度的构件构成的，我怎么知道我一个项目中，这个我构件多少服务，这些服务质量怎样，有没有完成的文档。我们可以给整个项目导出生成项目的开发文档，比如项目统计报告，项目的开发文档中，构件中会把数据模型，还有构件装配，还有具体构件实现都导出来。然后又支持导入各种格式，导出统计报告的，会导出具体服务，每个服务我们可以看得到这些服务质量统计怎样的。我们可以看到完整的系统，它服务哪些业务构件，我们看这个模块，可以看到刚刚建的数据模型，我们通过这个文档，可以提高项目的管理性，所有这些开发出来的构件，都是完整的项目文档，从它的业务构件设计，到数据模型的设计，到它的具体的构件的实现，我们可以看到它的输入输出是什么，在这个文档中都有详细描述。

杨玉斌 : 另外我对质量的一些统计，就是我这个项目质量，一共用了多少服务，多少逻辑流，这些逻辑流它的注释怎样，它的性能检查，它的折射代码是什么，形成完整报告。我们再看这个EXCEL报告中，我们看到整个项目一共生成分子员数多少个，业务逻辑、业务流程一共有多少，而且每个人写了多少，我们有详细统计。另外可以看到整个项目，比如构件库，自定义构件的复用率，和构件库里的复用率多少，都可以从导出来的报告看得到。还可以看到展现逻辑，比如分子个数，通过这些质量的检查报告，我们可以非常容易找到，我的性能是不是有问题，我实现的是不是不好，我的注释够不够，这样非常有益于我的项目的管理和维护。

杨玉斌 : 我们这个产品演示，大家可以看出来有一体化的过程，从业务构件设计，到数据模型设计，到构件具体开发，到构件服务部署，刚刚因为时间关系没有讲，我们是一体化的环境。另外我们支持业务标准，比如SCA1.0，SDO2.1规范，所有的实现都是用图形化的方式，就可以将简单的应用搭建起来，这些就是我今天演讲的内容，谢谢大家！

主持人 : 我们还是有两个提问的机会，杨先生给我们分享了其实是一个很具体的问题，就是SOA服务到底应该如何构造，这个问题很具体，也是大家在听厂商忽悠这么长时间，SOA应该是很实在的一个方面的内容。

现场观众 : 我想请问一下，用了普元的这种开发结构以后，相比原来的开发缩小多少，产品质量提升多少？谢谢！

杨玉斌 : 很多项目中，实现的业务构架工作，利用率能达到70%，这个意味着我们一般只有20%、30%工作量是写代码，其他的工作都是用拖拖拉拉的方式，我们搞的业务构件库里组成业务逻辑，质量如何呢？一个是开发周期缩短很多质量我们判断也是高很多，我们可以在同样时间内，完成原来根本完不成的任务，而且将系统上线，我们这个系统里，有很多这样的成功案例，可以和大家分享。

现场观众 : 杨先生你好！我是普元的一个用户，通过您的演讲，我想了解一个事情。我们单位想做一个计划，但是属于全国性的，我们一直对性能要求不是很高，具体想让您给回答一下，性能要求不是很高的时候，用SOA这种构架是否合适？

杨玉斌 : 当然合适了。关键还是跟你的业务问题的一些分析。

现场观众 : 是全国性的，并不是一个省的，可能跨区域的，这样逐级的，比如北京市可能性能不会有影响，但是跨到地域，比如到吉林省，会不会影响速度会逐级的递减呢？我只是关心这个。

杨玉斌 : 我从技术上给你分析一下这个问题。首先你最主要关心的是分布式部署的问题，分布式会不会导致性能下降的问题。分布式部署有几种模式，一种是集中部署，就是将我的服务统一部署在北京，所有的各地都可以访问，这样性能，就是网络性能基本上现在网络带宽下，大家基本都是访问一致，没有什么问题。主要的负担是在集中部署下，我的服务是否能够承受这样的压力，而我们这个系统是能够支持这种集群，对于第二种部署模式，就是你要分布式部署，要分级部署，比如北京是一个总的服务，各地市有自己分布式部署系统，这样考虑，你要考虑到总的服务会不会出现性能瓶颈，比如各个地市所有数据都要向总的服务汇总和分发，这样就可能造成性能瓶颈。

杨玉斌 : 在这个里面，我们一般有成功的经验，比如采用这种二级走线的部署方式，或者地市总线，全国性大的总线，下面的向大的上面的汇总，这个看业务设计，大的总线一定是关键核心问题才能用大的总线，比如建行项目中，他们用的ER系统是管理非常严格的。底下的要申请一个服务，要费很大的劲。不管是SOA系统还是传统的系统，都是需要考虑这个问题的。

主持人 : 我们知道在SOA的全生命周期中，除了服务规划和构造以外，业务化流程实现非常重要。可以说未来很多企业通过灵活的流程构造变成流程企业，我们的银行变为流程银行，我们的电信公司变为流程电信公司，接下来我们请出普元软件产品经理王程志先生，带来的讲演题目基于SOA业务流程实现模式，他将结合10分钟演示回答，第一流程持续调整和优化能力的重要性，第二，基于SOA的业务流程实现模式，以及带来业务的敏捷性和灵活性，同时我简单介绍一下王程志先生，是BPM业务流程专家，主持了普元软件业务流程平台等产品的规划和管理工作，有请。

王程志 : 各位来宾、各位朋友大家下午好！我下面演讲的主题是SOA业务的流程演示。在这个环节之前，我看到一个朋友提到的议题很好，他在短信平台上问到，说今天论坛应该有更多业务人员来参加，而不仅仅是技术人员，他的主要意思SOA不仅仅是技术创新，更是一个业务创新。我非常赞同他的想法，下面我想从这种业务的维度，来介绍一下业务流程实现的模式。

王程志 : SOA的关键任务是业务服务的构件和业务化流程。在业务化流程实现过程中，为什么说业务化非常重要呢？大家从最近的这种赈灾或者最近身边发生的事情，可以深切体会到，我们在灾难面前，除了悲痛之余，我们会发现我们的国家现在在发展壮大，主要体现在哪几个方面呢？第一，就是体现在经济发展，这个我相信大家都可以看到。第二，体现在管理的变革。我们的刘先生也介绍了管理的重要要素，管理中很重要一点就是流程变化。第三，流程变化会导致我支撑企业管理和业务的IT系统会频繁去变化。在这个过程中，我们需要对业务流程进行频繁的调整。这个调整如何来降低它的成本，缩短它的周期，这个就需要我们的业务化工作的平台，来实现我们业务的调整。

王程志 : 面我从三个层面，给大家介绍业务流程的实现。

第一，整个业务流程实现过程中，为什么说业务流程持续调整和优化能力特别重要。也就是我们面临的挑战是业务流程调整和优化。
:

第二，通过实际案例，来展示上面介绍的一个电信的DDA产品销售流程，是如何来进行快速的变化。
:

第三，通过普元提供的业务流程定制平台这样的产品，来通过案例的方式，给大家介绍一下在实际项目实施过程中所产生的收益。 :

王程志 : 上面副总裁刘尔洪先生已经介绍过，在管理精细化和差异化营销不断演进过程中，我们在管理的策略上会不断的引入SLA、QOS等等这些管理方法，这些管理方法的引进，会带来服务指标或者业务指标发生变化。比如说这样产品销售流程的接通率，以及开通时限都会发生变化，这样就会影响整个管理流程。从原来我面对所有用户是统一流程处理方式，到后来，可以针对不同的服务等级，定义不同流程，并且这个流程定义过程中，是在业务层面上实现的。在这里我们就可以看到，在这个过程中，就要要求业务流程可以动态变化，并且需要在这个变化中我需要敏捷实现，并且是灵活可以在业务层面进行调整。

王程志 : 下一步，我通过一个实际案例演示，如何敏捷实现和灵活调整。

普元提供的业务流程定制平台产品，如何从架构上来实现敏捷和业务变更。首先这个产品是在普元商业成熟工作流之上，业务员可以在业务层面上进行业务的调整和优化。我们通过业务的服务库、环节，以及我的规则库等等，来实现我整个流程。在流程实现之后，我也可以通过流程治理来实现流程整个流转的控制、监控，以及流程中所需要服务的管理和缄口。 :

王程志 : 在这样流程定制平台之上，通过怎样的过程，来实现业务流程的定制和调整。首先我的同事已经介绍了如何快速构造我的服务，我们构造服务会分为不同类型，比如页面服务构件，包括流程中的事件服务构件，这个基础之上，可以实现流程环节的装配，比如订单服务来装配出具体的人工环节或者自动环节，更进一步，我们可以在业务层面上，通过装配的环节，来实现业务流程组装和定制，在这个过程中，实现的流程进行马上的发布和部署，最后我们对流程流转过程中，进行监控和管理。

王程志 : 下面我通过一个实际的流程演示，来演示如何通过敏捷过程，来实现业务流程的定制。

这是我们业务流程的登录界面，我们进行业务流程的定制与调整。在这里我们可以看到，上一步我们同事所实现的构造服务，将我们的构造服务进行管理。这里就包括多种类型的服务，包括页面服务，页面构件服务，我可以通过这个过程，如何通过服务来装配我的环节，以及环节到流程的装配和定制。 :

王程志 : 在这里也会发生另外一些变化，就是流程业务规则。就比如说，我在客户经理确认之后，如果是客户经理确认通过，我就下一步进行洽谈，如果不通过，就是需要修改授权方案。修改方案之后，又到确认，需要到服务系统中确认SLA的域位指标。

王程志 : 在这里也可以让流程直接结束，同样客户洽谈这里，也是客户洽谈成功之后，下面再进行SLA合同签定，如果不成功，需要进行客户指标确认，这个里面就涉及到业务规则，我们看业务规则是怎样快速调整的。我们看客户经理确认情况下，如果客户经理确认，他通过我就走这样一个分支，如果没有，就可以在这样的分支上设立一个业务规则。这样就可以设置一个业务规则，当客户经理确认没有解决方案的时候，整个流程自动结束，在客户洽谈这里也是同样道理，我可以设置客户洽谈的结果来设置业务规则，如果客户洽谈成功，我下这样一个通知，到现在为止，我这样一个业务流程已经快速定制完成了。下一步，我们可以在业务流程定制平台产品上，进行流程的验证、保存以及快速的发布。

王程志 : 现在流程保存成功了，下一步可以看到流程状态变成已改动，可以在流程定制平台上，对这个流程进行发布。流程发布成功之后，我们可以看到当前变化的几个版本中，当前这个版本是正在运行的版本，下一步，我可以通过业务流程的运行和监控，来给大家展示一下，如何在一体化平台中，实现对业务流程的整体监控。在这里提交之后，我们可以在普元平台默认的客户中，可以查到我现在要处理得任务，我们可以看到当前处理任务的状态，从提交售前解决方案，到自动的调用服务来确认这个订单的一个指标，下一步到客户经理确认的环节，首先处理这样一个环节。处理得时候，我们可以给一些处理意见，处理结果，比如选处理通过。处理通过之后，我们再看一下当前的流程，我们当前的状态，就是我们所设计的业务规则，运转到客户确认这个环节，在客户确认的环节，下一步我选择处理洽谈成功，我们看一下当前处理流程的状态，也是按照所设的业务规则，来执行到流程的SLA合同签定这样一个业务环节。这是在我们上面调整了流程两个关键要素，就是流程环节调整，从原来一个环节到现在的五个环节。第二对流程流转业务规则的配置。

王程志 : 第三，如何调整流程的参与度，我们看客户洽谈这样的环节，我们假设在系统执行过程中，我需要通过不同方式设置环节参与度，我们需要设置四种方式，一种是组织结构和角色，比如我具体某个结构或者角色，或者通过执行者或者通过复杂的业务规则来参与。比如到某某规则版图的时候，我是A角色来执行，否则就是另外的机构来执行。由于现场时间关系，我刚刚演示的是通过流程启动的方式来做的。

王程志 : 第四，流程的KPI，我们知道流程环节当中，需要调整流程的时间限制，不同环节对整个流程都会设置时间限制，并且这个时间限制，是严格按照业务的方式，我可以通过业务的方式来指定哪种类型的工作日历，比如看到A部门是5 8小时工作方式，另外一种可能就是6 8小时的工作方式。王程志

王程志 : 我们看我们如何来做到这一步的？这个主要来自系统设计思想，主要是业务流程提出，到最终可用的业务系统，是实现两个分离，第一个分离，可以实现业务域和技术域的分离，技术实现的服务基础之上，我可以实现服务的复用，实现业务层面上，流程的梳理，服务的筛选，服务的重用，到后续流程的编制、发布以及预警管理监控等等，这个过程都是可以在业务层面上通过业务人员来完成的。

王程志 : 第二，在这个过程中实现另外一个分离，就是流程设计以及它实现的分离，流程中的一个分离可以通过分物构造环节开发完成，整个流程梳理设计可以完全在业务层面上进行业务建模，实现业务流程。对比传统模式，为什么做不到这一点，是由于传统模式下，我们往往将技术域和业务域混合起来，从业务方面的提出，到中间实现过程，一直在技术领域实现业务流程的分析，以及技术的建模，到后面流程的部署、上线等等都是需要技术人员的深入参与。直到最后业务部门需要验收的时候，才会发现这个流程是否是满足我之前提的业务需求。在没有满足情况下，我需要又回到开始的状态，来进行流程的调整。我们可以看这个周期是非常长的。

王程志 : 最后我通过一个案例，来说明一下普元业务流程制定平台这个产品，如何来帮助您快速实现业务流程实现，以及业务平台构化。

王程志 : 这是我们最新产品的一个截图，我下面介绍的实际案例，是06年的时候实施的安徽电信全业务服务保障和电子运维项目，这个项目建设之初，客户对我们提出很高要求，其中大家可以注意一下，最关键一个要求，要解决全过程管控问题，解决长期困扰的快和安全生命周期管控的问题，解决流程敏捷实现和灵活变化的问题，全流程管控方面，整个流程实现过程中，不需要技术域和业务域交叉方式，需要一个很长周期才能实现我的业务流程。在后续业务流程会不断变化，这个变化过程中，我也需要快速实现，这个快又体现在我对业务流程快速灵活调整，这个在上面我反复介绍了，就是对于流程关键四个要素，流程环节、业务规则，以及流程KPI的调整，在实施效果上，07年1月份部分上线了，现在整个系统上线实施状态，是07年8月份统计数据，当时可以看，在用的流程已经有898个，曾用的流程有2千多个，大家可以非常清晰看到，第一组数据，为什么有再用流程和曾用流程概念，这个就是表达了之前提到了业务流程持续调整优化的重要性，就是业务是持续变化的，我需要对支撑业务的流程进行快速灵活的调整，最好的方式，就是通过业务层面上来实现这个流程的调整。

王程志 : 第二组数据，就是我刚提到的，基于服务重用的方式，我们可以看到这样一个系统中，它是三千多个流程，我可以实现一个构件的服务支撑13个服务的运行，这样对业务的价值是非常大的。

王程志 : 经过我们前期的统计，据现在了解，现在在这样一个系统中，现在流程已经达到4千多左右，可以看到这个过程中，业务流程对它的重要性。

王程志 : 最后我们可以看到这样一个业务保障系统，基于SOA模式，实现业务流程所取得的收益。主要体现在，之前程先生也提到了，我们在实现流程或者实现服务构造几个关键的，一个是效率问题，第二质量，第三灵活性，第四，成本。我们可以看到效率方面，我们把原来需要两三个月实现的流程，现在只要一分钟就可以通过业务层面实现，第二，可以控制到一天左右，而不是原来的一个月。另外整个系统实施过程中，可以看到是业务人员全程参与，一方面激发了业务人员参与创新激情，第二更重要的是我们可以实现业务流程的在整个全过程业务层面的调整，来实现业务流程的灵活变化，以支持它整个管理的需要。最后一点，整个过程中，我们可以看到因为实现了服务重用的效果，整个系统运行过程中，我们发现从一上线系统就是稳定运行，并且流程变更，可以从业务层面进行快速调整，所缩短它的周期，降低它的成本。我们今天介绍的业务流程定制平台，如何来实现我业务流程的敏捷定制与灵活调整我介绍的主要主题就到这里。

王程志 : 谢谢王先生！

现场观众 : 你好！我们一直用SOA，使用过程中遇到的一些问题，主要用了你这个平台之前，你们还没有发布定制平台，现在已经有的业务流程，是不是能够兼容？这个怎么处理？

第二，流程整合过程中，有的要求上一级没有审核的时候，我可能发现错误了，想回收。这个问题，另外流程监控过程，咱们能监控到哪个结点，这个不直观。 :

王程志 : 您提的几个问题，都是我在上面介绍的，刘尔洪副总裁介绍整个业务流程实现过程中的几个难题。第一个问题涉及到产品版本兼容性的问题，我们业务流程定制平台，是业务化的分装，您之前业务流程，是可以在我这个上面来实现来导入的，提供导入的功能。

王程志 : 第二个问题，就是人工环节回收的问题，我上面提到了，为什么中国这样一个特色环境下，业务流程中的人工环境的处理能力特别重要，这是我们工作提供的一个关键特性，这是我们对人工活动的回收，甚至回收之后，还有一个业务补偿的问题。我需要对业务进行补偿，这个都是可以做到的，并且上面已经介绍了，对业务流程的我的这种委托代理代办的模式都是可以灵活实现的。

现场观众 : 第三个问题就是每个结点参与人比较多，怎么才知道这个是在谁的手上。

王程志 : 我们看到绿色的是这种已经完成的，红色是表示当前正在完成的。我们在这里可以看到这个环节是谁来做的，监控中都是可以看到的。

现场观众 : 监控是给管理员看的。

王程志 : 我们上面提到页面服务构件，这个默认是管理员可以用，业务员也可以用，另外通过构件方式，组装我们新的工作流程监控。

现场观众 : 你好！在业务流程的变更，我觉得并不只是技术上的问题，包括很复杂的，比如人力资源管理等等各个方面的，我刚刚听您介绍对于普元的软件，我觉得在技术方面的确支持了按需变更的要求，但是假如说一个过程有好有坏之分，关键是KPI。我们是比较难找到的平常。当一个复杂的业务流程展现在面前的时候，很难找到它的瓶颈所在。所以不知道咱们对管KPI选择，还有如何降低或者如何评判一个业务过程的好坏有哪些方法？

现场观众 : 您这个问题问的非常好，其实是业务流程分析和优化的问题。我刚刚演示的版本中，只是通过统计表的方式来分析每个流程环节运转情况，在现在最新版的产品中，我们已经实现了流程可以通过它的模拟仿真方式来做，并且可以监控到流程中每个环节，以及整个流程中的瓶颈在什么地方，我觉得你提的问题非常好。有机会可以到我们公司做这个产品的深入交流。

主持人 : 谢谢！接下来最后一位嘉宾带给我们讲演之前，我想针对现场的朋友做一个小小的调查。我想问一下这位朋友，请问您买过房子吗？是贷款买的吗？

现场观众 : 我买过房子，我贷了20年。

主持人 : 其实我为什么要做这样一个调查吗？如果我购买的是第一套房子，我的贷款利率是央行指导利率。如果我购买的是第二套房子，现在目前国家银根紧缩，利率提升到首付40%，利率要求第一次购房优惠率的1.1倍，如果这样对应到整个软件里，其实就是规则服务。接下来有请我们这次论坛的支持机构ILOG公司，带给我们SOA架构中的规则服务方面的问题，这位是ILOG规则管理专家苏明富先生。

苏明富 : 非常感谢大家能够坚持到现在，今天我是最后一个。希望我能给大家带来一些惊喜。前面我们的合作伙伴普元提到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提供相关产品，就是刚刚我讲的规则管理。我的演讲到此结束，谢谢各位！ :

主持人 : 谢谢苏明富先生。

主持人 : 首先谢谢您的精彩演讲，我刚刚看了您的业务规则管理，规则管理引擎是完全处理业务的数据模型，我想问的就是一旦数据模型发生变化，那个数据管理引擎如何应对这种变化，谢谢！

苏明富 : 你问的问题非常好，实际上这是都关心的问题，就是你的模型变了怎么办？我们在做系统分析设计的时候，首先关心模型的稳定性。我们最初设计的时候，首先要考虑各方面的要素，但是我们实际上开发代码的时候，往往发现数据要素会变，不光逻辑变，数据要素也在变，如果采用这种规则的，给你带来的好处是什么？你这种模型在10分钟之内可以搞定，重新导入，这些新的数据马上就出来了，你可以重新在上面做组合，这个不是问题，非常容易，如果采用这种业务规则。

现场观众 : 我想问一个比较简单的问题，如何识别这个规则之间是冲突的？当规则太多的时候，会影响整个性能，你一共允许有多少规则？

苏明富 : ILOG有这种规则的分析工具，你写了一大堆的规则，最可怕的是规则之间相互冲突，永远不会执行或者之起来有冲突，还有一种就是规则有覆盖，所谓覆盖就是重复的规则，同样满足的条件，同样的逻辑执行两遍，还有的不全的规则，写的不全，还有的规则永远不会被执行到，举个例子，在同一条规则写的，假如客户年龄小于80岁，而同时又写了客户的规则应该大于多少岁，这个时候永远都不会被执行，所以说，ILOG这个工具提供规则的分析工具，可以做这种分析，来实现冲突的，永远执行不到的这种给你出报告。

主持人 : 谢谢苏先生！

支持人 : 到现在为止，今天六个讲演话题到此告一段落，接下来还有两个环节，一个环节是构客网的《SOA我有话说》的博客大赛颁奖礼。我们博客大赛是围绕2007年IDC所发布的SOA中国路线图话题展开的，前后差不多应该有三个月时间，有一千多位构客网用户参与到此次大赛中，产生了五百多篇文章，在北京地区，我们这次有四个获奖者，今天到会的有两位嘉宾，一位获奖者叫李俊杰，获得最佳博客奖，另一位是张丹，获得奖项是最佳博客奖与信用用户奖。

主持人 : 接下来进入今天最后一个环节，这个环节也是比较令人兴奋的一个环节。今天抽出六项奖项，分别三等奖三名、二等奖两名，一等奖一名。不同等级的乐高玩具。

51CTO直播小组 : 此次“2008 SOA中国的关键任务技术论坛”在轻松的抽奖中伴着优美的音乐结束了，请大家继续关注51CTO后续专题报道！