主持人 : 中国企业信息化SOA从哪个方向开始，如何开始？未来又会怎样？带着这些问题我们来到每年一度的SOA中国论坛，我是本次论坛的主持人，欢迎走进今天的SOA中国论坛。

主持人 : 通过刚才的短片大家看到，从2010年开始推动软件构建化，2006年IBM连通11家厂商共同建立了SOA国际标准组织OSOS，2007年SOA国际标准诺言在北京、伦敦、旧金山拉开帷幕，IDC同一年发布了SOA中国路线图。SOA就这样拉开了中国之旅，但与此同时，当SOA的概念如火如荼的时候，大家对它的困惑其实从未消失，有人在讲SOA是一种企业架构，应该从企业级入手，有人在想SOA是IT的救命稻草，能够大规模的降低成本，提高灵活性，也有人在讲SOA就是ESB，通过它就可以把各种各样的服务注册成管理，甚至有人说经济的衰退已经让SOA死了，那么SOA到底死没死？我们的企业用户和软件商到底应该从哪里开始？接下来我们看一下今天论坛的议程。我们的第一个议题是由黄柳青先生带给大家的SOA从应用开始。第二个议题是由程朝晖先生带给大家的打造先进的SOA应用。第三个议题是来自王克强先生的SOA中国技术特征与架构。第四个议题是SOA的应用模式之一 即插即用的one应用。第五是SOA业务导向的流程定制。最后一个议题是基于SOA服务业务交付。在过程当中有三次抽奖的机会，是价值超过千元的乐高机。

主持人 : 本次论坛是由普元软件主办，普元软件是全球领先的SOA中间件提供商，是SOA标准组织的成员以及OSOS互联网组织的核心成员，也是SOA中国路线图的倡导者，此次论坛也得到了OSOS国际标准组织的支持，以及《中国计算机报》、软件世界、中国软件网、TT中国、51CTO、中国IT实验室媒体和机构的支持。

主持人 : 接下来进入今天的第一个议题，第一位演讲嘉宾是OSOS组织专家黄柳青先生，他曾经担任亚信科技的CTO，主持了多项大型IT建设的项目，并完善了面向构建的方法论，著有《软件的涅磐》、《构件中国》等书，有请黄先生。

黄柳青 : 各位领导，各位朋友，大家下午好，非常高兴有机会参加每年一度的SOA中国论坛。记得第一次论坛也是在这个酒店，07年的时候最早第一次跟美国的OSOS具有中国的SOA论坛。当时我们我们有各种专家一起讨论，介绍SOA有关标准等等。

黄柳青 : 有人说IT的行业都是概念炒作的一个行业，没几年就出来一个新的概念，SOA这样一个主题经济这么多年的讨论之后，它是不是真的能够成为IT建设的主流呢？SOA在这么多年之后有没有比较成熟的切实可行的技术已经开始普及呢？在我们使用的时候会不会有哪些更好的措施帮助我们符合中国得特色进行推广？在这几年的努力之后，我非常高兴在这里跟大家分享有关这些方面的一些想法。

黄柳青 : SOA会不会成为IT的主流？这个我觉得有两个答案，一个是比较简短的答案，一个是比较理性的答案。简短的来讲，假如说我们现在北京市只剩下两个参观，一个叫肯德基，一个叫麦当劳，没有其他的地方可以吃。这个时候我相信，即使在任何情况下，汉堡等等慢慢都会成为大家习惯的主流食品。

所以像SOA能不能成为主流，现在我们全球最大的为数不多的主要是甲骨文和IBM，他们的产品已经全面的侵袭到第三代的SOA为核心的产品，所以很自然的大家越来越多的会让SOA成为我们日常工作主要的部分。但是实际上来讲，SOA确实会给我们带来很多的价值，这个价值就在于变化。在去年美国总统选举的时候，变化这个词成就了美国第一个黑人的总统。变化也会让SOA真真切切的发挥价值，成为IT建设的主流。因为软件我们已经做了那么多年，大家经常说税务也好、银行、电信、电子政务，我们的系统这五年和十年不断的建设，为什么它到现在还没有结束呢？因为软件并不是代码，软件是我们一个企业和组织业务的反应，而业务又是企业文化的反映，当我们的企业文化和企业业务不断的发展变化的时候，我们的软件就必须跟随着发生变化。同时每个企业，每个组织都有自己企业的文化，这也是为什么我们规定都不要用套装软件，需要大家去开发。

开发好了之后，第一件事情就是变化，因为软件开发后之后软件就会适应新的变化，所以从理性上来讲，SOA为什么会成为整个IT建设必选的主流呢？就是作为一个软件体系来讲，它的变化是本质，正是因为业务跟文化都是在发展变化的过程中，只有像SOA这样一个适应企业变化为核心发展出来的技术，才能够适应我们IT系统长期的建设，而不是像现在一样我们每一年两年，最多三年就要把我们辛辛苦苦打造出来的软件重新推翻掉，重新再来一次。所以在这样的环境中，我们看到了SOA作为第三代中间件是势不可挡的方式走到我们的前台。

从七八十年代开始，到九十年代主要解决了分布式计算的问题，现在以互联网为核心的社会体系里面，应用软件计算体系也需要越来越多的面向网络，SOA就是这样一个网络服务为核心的，满足大家变化的。所以我们可以看到，在经过多年的努力之后，SOA正在越来越多的企业里面得到使用和发展。

SOA到底是什么？现在技术的成熟度怎么样？有哪些比较成熟的方法？首先SOA就是什么样的东西能够随需应变，不断的发展，其实答案就是说越简单越好。在我们现在开发的软件里面互相的接口依赖性比较多，当我们的企业软件从一个部门级单向的功能发展到全企业应用的时候，互相之间的依赖性越来越强，所以我们就需要一种体系能够把所有的软件业务功能、IT的功能，通过一致的、开放的、互相之间没有太多关联度、容易替换的接口，所以服务就是这样一个概念。

在一个面向服务的体系里面，我们这样一个写好的应用的模块，可以被轻易的替换，同时也可以被快速的重新组合而应用。当然这个想法是非常好的，非常简单，在我们几年的努力过程当中，也发展出一些配套的核心技术，真是这些配套的核心技术才让SOA真正落地，成为一种可能，打造出能够灵活应变的SOA服务。在SOA相关的技术里面有几项比较重要的东西，第一项就是我们推广的SCA标准，就是服务构件标准，服务构件标准有两个层面，一个就是说我们怎么样通过更小颗粒的服务构件快速组装出网络服务，因为我们现在的系统开发中不可能重新大量的开发新的服务，希望这些服务能够快速的形成。

同时我们的服务通过构件化的方法，能够组装成更大颗粒的服务，也就是说在SOA服务理念里面，我们要落实一个真正组装的标准，SOA的标准已经提交，现在在很多地方得到使用，包括我们最新看到甲骨文和IBM的产品里面都在向这个方面做很多的努力，SOA已经成为他们产品的一个标准部分。下面就是一个引擎，使得构件之间可以通过流程进行组装。

还有一个关键的技术就是业务化，怎么样通过业务化的描述、配置，使得我们整个服务的功能特别灵活的调整，比如说我用代码写了一个组织管理的模拟，我们可以配置一下，这个组织机构是树状结构还是网状结构还是怎么样一个零碎的结构，经过业务化的设置之后，整个机构的软件就按照业务化进行调整。这个趋势就是说把应用软件最终的调整不是由技术然员完成，而是由业务可以直接对流程规则的配置，来完成对服务的重构，所以这是我们几项很重要的技术，就是在SOA上面有关服务构件、流程跟业务化的技术。正是因为这几个技术的辅助，使得SOA的实施成为非常现实而且高效的一个平台。

SOA也在不断的发展过程当中，SOA现在也成为云计算的基础技术，因为大家经常听到云计算等等，其实这些技术都是在SOA基础上发展出来的有关技术。所以我们可以看到，SOA已经有很成熟的配套技术，使得我们应用的灵活性、应用业务化的程度得到进一步的提炼。在我们现实IT的建设中，怎么样才能够把SOA很好的利用起来呢？我们早期听了国际上一些大的厂商的建议，去用这些方法对IT进行重造。后来我们也发现，这个方法不一定最适合我们中国，在国际厂商的交易过程中，他认为一个企业要做SOA，他是一个企业级全面的规划，因为在国外已经有好多标准现成的应用可以快速的变成SOA的服务。

但是当我们企图在整个企业级进行IT规划的时候，我们会发现即使在中国的几大银行，最大的电信公司，要一步到位在企业级实现SOA是非常困难的。正是因为我们现在已经有好多的系统正在运行，但是我们现在好多应用系统之间的切口并不是非常的清晰，同时应用系统之间的边界也不是很明确。在这个时候，如果我们要对整个IT进行重新规划的时候，这个规划的周期会非常长。同时即使我们有能力做一组IT的规划，也要求我们在一开始就建设好很多基础的服务，这个对很多企业来讲也是很大的一个挑战。也就是在我们真的一步到位全面做SOA的时候，这个里面有很多非技术性的，而是我们业务化带来的难度。

比如说我现在要实现SOA，整个企业以前都是按照项目应用来组织和招投标的，现在我的整个企业要重新把它架构的时候，第一我自己IT的规划能力要非常强，第二我以前传统项目的找投票，项目的管理、员工等等全部的体系都要达到。那么这个时候我们会发现，在这个方向上面的成功案例非常少。所以在全面的SOA起步的代价非常高，风险非常大，等于说一个飞机正在飞的时候，你要把马达换掉这是很难的事情，而且我们马上要建立很多IT的系统是现在就需要完成的，而不能等到三年五年的周期。这使得我们在这几年的实践过程中碰到这样的问题，碰到这些问题的时候，我们也跟银行、电信很多客户商讨，找到了一条更加符合我们中国自己开展SOA一条新的道路。

在中国要成功的实施SOA项目，我们看到有几个关键的要素，第一就是我们在投入开始建设SOA的时候，不是从整个企业的IT规划开始，而是从单个应用或者是一组相关的应用权开始进行，我们本来企业的规划里面说我们公司整个系统都达到什么，这个事情我想你的老总一定要反对的。但是假如说现在已经规划做的系统，你的客户管理系统里面可能会有五个十个相关的应用，这几个应用形成的应用权相对来说就是它的可控度是比较强的。所以第一个我觉得在中国建SOA，就是要从应用和应用权开始来建设，这样的话现有的IT规划里面就可以纳入SOA的元素，开始的投入会比较少。第二个很重要的因素就是因为SOA的思想非常好，但是SOA思想的一个关键要素就在于我已经有好多基础的服务，可以被我调用，可以使用，已经有比较多的，像美国这样既存的IT的资产，这样的话我们中国的情况不能达到这个水平，对于我们中国SOA平台的选择就提出更高的要求。

希望我们在中国选择SOA平台的时候，它已经具备了一些基础的构件和服务，我们要建设一个SOA的时候，不是从零去建设，而是在我们已经总结好的几十个、几百个构件跟基础服务上面在快速的建设和应用，这样可以大大的降低现在实施的风险。同时在这样一个地方我们也是用现有的项目管理框架，涉及面就会比较窄，都在我们可控的范围内。同时一旦这个应用或者应用权成功的话，就会给我们很好的一个台阶，让我们在企业内部更好的开展SOA的思想。在这个过程当中，我们也能够积累SOA使用的一些经验，这样的话一些积累的服务也可以在应用和应用权过程中逐步的提炼，慢慢的变成企业级的服务。

比如说人事、行政、客户管理等等这样的服务，我们现在一天之内要把它设计好、开发好、用起来难度很大。但是如果在一个小的应用群体的范围内满足需求还是比较容易的。当我们用户的要求满足之后，我们把它推广到更多其他的项目和应用的过程中，就可以在这些原有的服务上面逐步的提炼和加深，慢慢的变为企业级的一些过程。

我们总结了一个方向，第一我们要从小处入手，从可控的范围入手。第二要选择一个比较好的平台，在标准的SOA上面还有一些基础的构件，还有服务构件、业务配置等等各项增值服务的开发，会大大降低我们SOA的风险，增加我们成功的可能性。在这样的过程中，我们也具体的发现了一些SOA应用的模式，我们可以看到在经过这几年的发展之后，我们不光是说SOA是一个概念，而是在好多企业里面已经有规可循的非常成功的经验、样板可以让我们学习和提高。在我们理想的SOA环境里面，我们做过很多应用，每个应用逐步的会用SOA这样的方法来开发，在开发的过程中，这个应用又是由小构件、流程和业务配置来完成，通过应用逐步的能够在企业里面形成服务的规模和架构。

以上就是我今天跟大家分享的主要内容，SOA已经从概念走到一个实践，逐步的正在成为我们的主流，而且SOA的技术已经相当成熟，我们也有好多切实可行的模式帮助大家从应用开始建设我们企业级的SOA体系，谢谢大家。

主持人：谢谢黄博士。如果说SOA从应用开始是SOA在现实实施中的切入点的话，那么它又如何开始？应用的典型场景又有哪些？它们的应用具有哪些技术特性？接下来我们请出下一位演讲嘉宾程朝晖先生，他将帮助我们回答这些问题。程朝晖先生也是OSOA以及OSS组织的专家，也是OSOA中国的负责人，现任普元软件的副总裁以及应用产品线的总经理，他曾经在IBM有着超过16年的中间件产品的管理经验，见证了中间件在中国的成长。同时他也创作过大量的用中间件相关的白皮书和撰写过大量的问题，下面我们以热烈的掌声欢迎程朝晖先生，有请。

程朝晖：大家下午好，很高兴大家一起来见证这个非常重要的时刻。

左单元格

左单元格

在开始之前我也想做一个调研，大家都知道，今天是为了SOA这样一个主题而来，刚才黄博士提到过麦当劳、肯德基只剩两家的时候，通常到周末的时候带小孩出去吃饭，为了激励一下他，就会说你想要去哪里吃饭？他一般只有一个答案，麦当劳或者肯德基。所以在大家今天来到SOA这个会场，一定是带着自己的需求而来，需求有两类，用英文单词比较容易表达，一个叫want，I want SOA，还有一个就是need，就是I need SOA，他们有什么区别呢？

想要SOA的举手，需要SOA的人举手？也没有，大家是来参观一下五星级酒店是吗？（笑）。这很好，就说明了我们今天的内容会给大家带来说，你是不是想要SOA或者说你是不是真的需要SOA。所以在去麦当劳的时候，小孩其实是想去麦当劳，经常我的女孩到麦当劳之后就吃两口就跑到玩的地方去玩。所以需要是很客观的，是他有了问题，需要用SOA来解决他的问题，想要SOA是他现在问题不大，好像没有太多的问题，但是听说SOA很灵活、效率很高，他希望把现状变得更好。所以这两种需求一种是更主观一点，一种就是客观性就有问题。

我今天演讲的题目就是打造先进的SOA应用，刚才黄博士已经把他的观点摆了出来，SOA从应用开始，也就是我们今天的主题。接下来的一段时间我会阐述一下我们如何做到SOA从应用开始。先给大家看一下，我们现在的背景环境在发生哪些的变化，这个趋势非常重要，我们不能自己蒙头就说我要SOA了，要看看我们的业界客户，我们自己，我们的竞争对手他们在发生哪些变化。

当然我也免不了要俗套一下，介绍一下SOA的体系。接下来是我演讲内容当中最关键的，应用模式，可能大家也是经常听到这个词，但是放到这个地方，放到这个时间，放到09年有特定的含义。接下来我们会去看，这样一种应用模式，我们应该对于技术需要哪些特性支撑？需要什么样的平台支撑？

这可能是我们经常听到的一些概念或者观念，或者口号，我们做什么事情都在讲我要以客户为中心、业务为导向，现在多了一条，要以服务为基础。首先我们来看一下，其实在新浪上最近发布了一篇文章，他对于一个分析机构分析了我们整个中国信息化建设的500强，其中排名第一个是中国工商银行，中国工商银行正在规划建设它的第四代IT系统的建设，他为什么要做第四代的IT系统建设？

它建成之后要成为世界上在金融范围内第一个攻克金融难题，现在的商业银行产品成千上万，大概上千肯定是有的，工商银行将在世界范围内第一个摆脱一人千面的困扰，它会在全国乃至全球工商银行，要在业务处理层面实现同一个ICBC，就是One ICBC，这是我们客户发生的一些战略性的转变，我们也看到一些领先的银行也在规划2.0。去年电信完成了整个电信集团的三大融合，现在每家电信运营商都提供全业务的融合业务，并且他们在规划自己的下一代技术架构和平台，同样我们也是在往这个方面发展，可以看到我们企业都在说要给客户一个更加一致的体验，更好的一个窗口去服务于我们的客户。

要实现这一点，自然我们就需要由相应的业务来实现和保障。所以业务是满足需求和创造企业自身差异化优势的手段。因为大家都是做IT的，在IT的圈子里大家都会读《跨越鸿沟》等等一系列的书，最近有一本书叫做《公司进化论》。我今天看到一个新闻讲柳传志到了联想没几天就把战略和业务定清楚了，马上全公司就感受到这种危机感，应该往哪里去把战略定义清楚。柳传志就提到过，很重要的一点就是说怎么样整合外围资源，把自己的核心差异化的放大发展出来，所以同样这本书里面提到过，业务的核心就是能够创造差异。这就是业务在满足客户需求的时候，要去满足他的偏好，同质的东西当然你要做，这是基础，但是赢得竞争是通过需要你的差异优势。

我们要去实现这一点的时候会发现，资源好像非常多，银行的资源也能用，电信的资源也能耗，互联网上这么多也能用，这个时候怎么能够快速的整合外围的这些资源？围绕着自己核心的竞争力上面。因此我们需要有这样的基础，服务是真正实现业务的基础，服务会成为我们去协同IT业务的一个共同的语言。

那么服务来自于哪里？其实也是今天很重要的话题，服务一定来自于你的应用。为什么说SOA从应用开始？服务来自于哪里？包括四个方面，第一是你没有的业务处理和逻辑，需要新构造的。第二个你可能有一些应用系统里面这个服务是可被用的业务服务，可以分装一下。第三种就是基于这些基础，把它整合成适合你业务发展的更有力度的系统。第四就是通过端到端的编排实现新的服务。服务从四个方面而来，同样服务也会回到应用当中去。为什么工商银行和电信公司要建2.0的技术体系，他一定是碰到了问题，一定是有需求，他是碰到了在业务发展上，现在的体系架构不能很好的满足要求。

有句俗话叫做现在的问题一定是现在的方法所造成的，我们现在用了什么样的方法造成我们现在问题的结果？所以我们可以看到，在众多的系统数据当中，我们很多很多项目数据，这是我们在建立一个个单一系统的时候采取的体系架构所造成的。在短短的分析报告当中提到，单一的体系架构正在走向终点，而面向开放、网络环境下的SOA体系正在成为主流。这样的一个体系转变我们期望可以给我们带来信息更流畅、流程更敏捷、服务更可用、用户的体验会更好。是不是我们真的用了SOA？用了SOA的什么就能够真的做到这一点了呢？

所以接下来给大家介绍一下SOA。最近我自己在淘宝上买了尼康D90的数码相机，也是拍了几张照片，我们可以看到最早的时候，我们理解的SOA是什么？就是Web service，几年前大家都说支持SOA了，人家说怎么支持？他就说我支持Web service来解决业务之间的互通。又过了一段时间，就是现在或者是去年，大家都在讲我也SOA，或者说我做了一个Service的注册，管理SOA，所以大家都会看到，我SOA好像就是在这样一个角度用这样的技术在实现我的SOA，这是不是解决了我的问题。好像我们最后用了SOA和Web Service效果不是那么好，我们看SOA的不够深入，不够本质，所以今天我也想给大家介绍一下。

在我们本身要把它看得更加深入和本质的时候，其实首先要问的问题是，它存在的意义是什么？它是从哪里来的？要到哪里去？所以在我们第三张图里面给大家看到，SOA一定是从左边的应用中来，也一定会被左边的应用所使用，会回到应用当中去。那么当我们的服务不断积累增多的时候，自然几百个、几千几万的服务的时候，甚至于不是我们的服务，可能还有很多合作伙伴、银行、电信服务的时候就需要把这些服务很好的管理起来，这个时候对于SOA的基础设施有需要。所以现在我们基本上是一个Want。

这样一个体系我们首先要把SOA应用建立起来，这是实际解决我们现在业务问题的应用，在建立这样应用的时候，我们需要有相应的应用模式、定制环境，把我们的服务不断的组合、构造和编排出来。当然刚才大家在录像以及王博士的演讲当中都了解到，这样一个体系需要共同的厂商把这个体系标准化和规范化下来，这就是在05年筹备的，06年7月份正式成立，并且在07年3月份发布标准的第一个版本，OSOA组织，这个组织是由几十家全球领先的基础软件厂商共同推进的。当然普元也是亚洲唯一一家组织，所以可以看到我们SOA的理解也是不断的深入，到现在09年我们看到真正SOA服务的提供是最关键的，没有服务我放一个空的ESB，或者一个高速公路没有汽车是没有意义的。但是服务从哪里来？服务一定从应用上来，这就是我们今天的主题。

这样一种体系架构之后，我是不是就能够把应用做得很好了呢？所以我们回想2000年、2001年、2002年甚至于2003年的时候，在应用服务器上做，但是做的也非常的困难，大家回想一下。后来什么事情发生之后让我们在应用服务器上做软件变得很容易了？真的是能够体现应用服务器带来的价值，当在应用服务器上开始MVC的模式出现，才真正改变了当时的应用。这个软件也没有给原来的架构好多少，但是SOA出来之后，大家发现很容易做了，比原来好做很多。

所以同样当前的SOA也遇到了同样的尴尬，大家为什么没感觉到SOA给我带来的很容易很好做呢？所以SOA所诉求的灵活、高效好像也还是更多停留在概念或者停留在PPT上面。因此今天的主题就给大家介绍SOA的三个应用模式，即插即用的One应用，业务导向的定制和基于服务的交互，SOA是未来的软件服务、云计算的基础。首先我们看一下第一种模式，就是One应用，刚才ICBC也提到了这样一种发展战略，我们可以看到应用系统繁多、用户操作比较低效，我们每天要登录很多，用户的体验差异很多，每个系统都要学习，操作和按纽都不一样。

所以就是跨系统的，在SOA体系上面这样一种模式，可以看到这样一种One应用的模式，企业里面整个管理是一个应用，或者整个业务是一个应用，整个企业是应用，当然我们也可以说OA是一个应用，它里面还有很多模块，应用没有大小。小应用可以到中应用里面，中应用可以到大应用里面，所以这样一种概念模式是怎么去建立的呢？有这样的方案。通过统一的这样一种模型，下面都是面向服务，都是一个个服务，然后通过统一的集中工作台来展现给我们的用户，给他非常好的体验。

通过一个统一的集中任务中心来调度任务、获取任务、管理任务。这样应用的好处是可以即插即用，把一个OA当中某一个办公室管理插进去，这个新的用户登录进去就可以看到了，可以进行办公室和会议室的管理，双耦合、可组装、可配置是它的特征。这样的一种应用模式是在新的多应用、One应用的体系架构上更高层的模式，给我们带来用户的体验更好。你到新浪去看新闻的时候，不会说每个频道都是不同的按纽，这个地方点下去发生这种事情，那个地方点下去发生另外一种事情，不会的，大家到新浪之后体验是非常一致的。更加的灵活高效，而且见效非常快，生命周期会很长，所以这是第一种模式。

第二种模式大家其实都知道，软件一点部署了很难去改，因为一旦要改就要从需求开始，设计、开发、上线、部署等等，是非常长的过程。因此我们希望我们的软件对于同样一个版本，对于不同的客户可能更加灵活，具有可定性。所以我们会发现，现在我们经常的应用系统里面流程、规则、表单都变化非常快，而调整的周期会很长。因此我们需要在SOA的体系架构上有这样一种应用模式，这种应用模式能够给我们带来什么？使得你在做业务设计的时候，流程设计的时候，你的业务人员跟IT人员是在一起做这个事情，大家是有共同的语言、共同的理解。并且可以通过这样一种定制的手段、方法、工具来帮我们做应用化的工作，并且基于底层的服务快速的进行编排。这样一个方案让我们可以看得到，它会反映出我可以继续的调整，某一个省的某一个应用系统到不同地市的时候，都可能同样是服务开通，不同的地市进去可能服务流程的开通是不同的，我们就需要为不同的客户快速的定制，即时的上线，体现出软件已经完成业务所需。这样一种业务化的客户定制模式可以让我们看到，它对于变化的响应会更加敏捷，而实施成本也非常低，不需要很冗长的过程，非常快，并且可以支持我们的业务可持续优化。

第三种模式大家都在说融合，电信和银行也在融合，如果我在淘宝上买D90的时候，到下单了，让我付钱，一下子弹出来招商银行给淘宝的系统，不知道怎么操作这个系统，要登录用户名密码，还要习惯招商银行的整个系统是怎么样，其实我只是需要做支付的服务，只是需要招商银行给淘宝一个支付的服务。使得这个融合变得非常困难，系统之间非常难融合，所以我们需要基于服务来交付我们银行的支付给淘宝，甚至于给其他的服务开发商。在这样一种模式需求变化的情况下我们可以看到，我们需要有相应的服务构造环境和服务的运行环境。同样刚才提到的，在这本书里面，企业重要的不是什么东西都自己做，你的能力是说能不能快速的整合你的资源，这个资源可能是你的客户的，你的合作伙伴的，你的上游的供应商的，电信的、银行的、SP的，你是不是有能够快速的整合这些外围资源，能够应用于你的核心，把你业务的差异化跟核心的竞争能力能够体现出来，这就是我们看到这样一个SCE跟SEE的环境，可以把我们企业里面已有的这些资源能够进行重新的组合，是一个组合的环节，也可以跟我们外界的资源进行组合，快速的编排，形成我们一个增值的新业务，这个在电信行业里面SDP这样一个应用领域已经走在最前面，在发展了。

当然我相信其他的行业也会快速发展，很多CP、SP都会基于这样一种服务组合的模式快速交付服务。这样一种方式让我们看到，整合资源更多的去降低成本，快速交付，灵活应用，而且把我们技术的障碍放在下面。昨天和一位电信专家交流，我问他这有什么用？他告诉我一万多的服务开发商非常困难，每天都打电话给我，说你又给了我一个Web Service，我看也看不懂，他们有一个客户说现在不光要把环境给一些中小的SP、CP，还要给到个人，比如说一个人要搞懂Web Service太辛苦，技术无法通过。

所以让小公司和个人能够快速的组合服务，能够编排他自己所需要的服务，部署上去供别人消费。同样的分析报告里面提到过，这样一种组合应用的模式会快速的被采纳和增长，它关键的价值在于降低开发成本，缩短交付时间，我是在交付一个服务，招行银行交付给淘宝的是一个支付，不是一个支付系统。

第四种我们有这么多的服务和系统，我们希望这个企业的资源，不管是计算资源还是软件资源，都能够更好的被集约化的使用，两个月前我去迪卡隆的时候，有一个人说我穿的衣服跟你是一样的，大家叫做撞衫，这种情况现在很少发生了。所以同样的，我们在互联网上，在企业提供的服务，未来也会往个性化方向发展，将来的流程服务开通也是很难撞衫的。所以在这样一种模式之下我们看到，《福布斯》在2月份的报表当中提到过，企业计算环境正在进行下一场技术的大战，这场战争是什么呢？就是我们谁有能力在SOA的体系架构下，能够让客户更好的去定制个性化，利用软件服务的模式，利用云计算的能力，把自己外围资源更好的整合，利用于核心，快速把这个资源交付出来。所以这样一种软件机服务的模式也是一个趋势，但是现在可能很多企业还没有走到那一步，我们需要去把握关注这样技术发展的潮流。

这样一些应用模式到底应该需要我们什么样的技术来支撑？一般大家都知道，就是三层架构，ES架构，什么架构，为什么会有这样架构？这个架构是哪里来的？架构是在右边，叫架构设计的原则，双耦合，分布式，它是来源于对于我们信息的需求，它的信息需要任何时间、任何地方、任何方式的时候。当信息不需要的时候，只需要到网点上取钱，你不需要一个分布式的架构，所以一定是信息需求发生变化的时候，对架构产生了要求。为什么会有信息需求的变化呢？是因为本身客户的业务战略发生了变化，就像刚才讲到的这些电信公司、工商银行，当然再往前一直推，所以我们可以看到，刚才我们所展示的这几种应用模式下，这些应用的特征，应用不再是一个庞大的市场，OA可以是一个应用，OA里面的模块可以应用，整个大的也是可以应用的。大家的模块都是即插即用的，服务是可交付的，不再是交付一个系统，招商银行交付整个的支付系统给淘宝，这个没有办法做。服务是可消费的，每次消费服务可能都是要收钱的，业务是可定制的，可以个性化，并且用户的体验也会更好。所以这样一种应用需求，对于信息的需求带来了我们架构上的要求，这个架构的要求是什么？这是五个SOA架构的应用基础特征，大家可以总结下面，模块化双耦合、可共享、可付用、分布式部署、基于文档的接口，接下来的内容当中也会给大家进行剖析。

这样一种技术特征我们可以看到，最终我们不能说拿这个模块化，这个拿不出来，没法拿出一个分布式，需要这样一种架构技术，这也是露一个小脸，我们今天的发布BPS6.0承载了整个的应用平台，构造我们整个应用服务和流程服务，而在网上这是一个服务基础，在网上我们要去实现业务的时候，要业务为导向，也就是我们实现One应用导向的时候，给客户更好的体验的时候，我们基于服务交付的时候，需要给客户更快速交付的时候，我们需要给客户更个性化的业务导向的时候，我们需要这样一种业务化的定制，来打造我们的SOA应用。使得我们可以看得到，SOA不再那么深刻，不再那么复杂，我们可能都可以在SOA上进行跳舞。所以在2007年的1月13日，苹果公司发布了他们第一个Iphone，那次其实把手机的用户体验推向了一个新的高度，同样我们可以看到，一会儿也会给大家有演示，大家可以看得到，在企业里面做到一个One企业的时候，One工商银行的时候，One移动的时候，会给我们的消费者一个全新的体验。

所以很重要的一点，这些业务带来了什么？更好的体验。同样的我们需要更高的效率，我们不能说IT与业务之间，大家讲的话还是讲不清楚的，语言不通，资源不能很好的整合，不能很好的服务，交付起来又庞大，我们要提高这样的效率。同样我们可以看到这种灵活性，随着整个SOA把复杂的系统化整为零之后，可以带来更多的灵活性，根据我的需求变化可以灵活的进行变化。最后一点就是可靠性，我们把一个系统当中可能单点出现的故障被割裂，割成不同的模块之后，分布部署，使得我们整个系统出错的概率控制在了一个模块，被模块化，被分布。所以解决复杂问题，SOA不再解决复杂问题，复杂问题可能不仅仅来自于企业内部应用，因为你还要跟你的其他的系统，你的合作伙伴去共同来搭建这样一个面向服务的世界。

我们通过今天的内容介绍，给大家看到SOA离我们很近，我们利用这样一种应用模式，能够真正让我们看到我们的应用有更好的体验，更高的效率，更强的灵活度和可靠性。

我的介绍就到这里结束了，谢谢主持人，谢谢大家。

主持人：谢谢程先生，据说程先生有一份厚礼要送给大家，当然这是有前提的，那是什么呢？

程朝晖：这个是一般大家得不到的，所以才叫难得的厚礼，这是今天发布的产品，这是一个纪念的礼盒，通常个人下载或者获得一张光盘是拿不到这个盒子的，盒子里面有什么呢？一般个人也是不知道的，藏着什么也不知道。但是一般企业花了几十万、几百万、几千万买来之后，肯定是放在保险柜里，专门是入库的，一般的人也是得不到的，所以这个礼盒送给在座的一位嘉宾，当然前提是你要回答出问题来。问题很简单，请讲出刚才主题当中我认为最关键的SOA的三种应用模式或者四种，说到三种就可以获得。

嘉宾：一个即插即用是One应用，一个是业务定制，第三是业务交互软件及服务。

主持人：非常感谢，请上台领取这一份礼品。这个里面是开发版，我刚才讲了是贵在盒子上，光盘大家知道是可以刻录的，通行证是一个开发版的。

程朝晖：接下来还有一个回答问题的机会，是我们一件T恤和一本新书，主要探讨的是软件竞争力的提升。

嘉宾：我是来自水利部信息中心的，我想请教一个技术方面的问题，SOA国内外现在说的也很多，我想请问对于SOA具体实现的话，我们的US和BPS产品有没有考虑将2000年提出的框架也融入到产品的实现里面？另外考虑底层实现加网格的技术也与SOA做一个结合。

程朝晖：首先第一个问题是US和BPS6.0有没有考虑将这个技术纳入到产品体系当中。应该说其实对于这些技术的把握我们有专门的架构组一直在前瞻性的工作，所以其实我们已经验证过这种风格的访问方式，是可以直接去访问我们的US的服务的。但是具体可能在实现的时候，可能在这方面需要提供工具，访问的时候更加好访问，所以这方面我们目前还在研究和规划当中，本身这个技术调用是没有问题的。另外你讲网格技术，这对于我们来讲其实我们是一个SOA的技术平台，底层的这些技术发展的时候，包括虚拟化，包括网格计算，其实我们是可以做到集成的，但是有些我们并不自己完全做这些技术，我们会借助底层我们一些技术平台，为我们提供技术能力，实现网格的技术方案的管理。我觉得这个题目很好，我们可能也会随着大家的支持，更多的投入到技术的研究当中。

主持人：谢谢程先生，我们将礼品赠送给这位朋友。接下来是今天第一轮的奖项三等奖。

主持人：接下来进入第三个演讲题目。我们了解到SOA从应用开始是一个不错的切入点，同时程朝晖先生也为我们分享了SOA应用的四个典型场景，对于我们的用户来讲需要用什么样的产品可以实现？这些产品又应该具有哪些特性呢？接下来我们请出王克强先生帮助我们回答这些问题。王克强先生是资深的产品研发总监，在中间件产品的研发领导经验非常丰富，大家一起欢迎王克强先生，有请。

王克强：各位嘉宾下午好，我今天带来的主题是普元在SOA中间件技术特征与架构，刚才黄柳青先生和程朝晖先生给大家带来了SOA从应用开始的演讲，我们看到了在SOA时代里面三个典型的应用场景。

我们回头看一下，在这三个典型应用场景里面我们发现要解决的问题是非常有挑战性的，如何去实现一个大型企业里面将所有的应用都通过模块的方法搭建出来？我看到的不是ABCD的应用，而是几千上万个模块，并且模块很容易被管理起来，为了应对敏捷度实现快速的业务交付，我们希望由客户或者业务方直接去定制业务，因此我们需要提供客户定制的能力。最终我们会发现，现有的事件里面有大量的服务，我们会发现在网站上面有一系列支付的相关服务，我们如何将现有的服务能够快速编制，形成新的服务，以服务的形式交付呢？面临很大的挑战就是，我们需要什么样的架构去解决这样的问题。所以我今天给大家带来了一个很关键的问题，就是我们在这种形态下面需要什么样的技术架构。

我们看整个技术架构的时候，做一个架构的评估。片子里面我们可以看到早期系统里面有主机，或者是我们会看到客户服务器的这种体系结构，或者是客户服务器的一个变量。但是我们发现一个很重要的特点，客户服务器里面很好的解决逻辑和数据分流的问题，并且通过接口的编程实现了模块的结果。但是我们发现面临很大的挑战，这种大量的应用时候都会面临很大的问题，就是应用系统很多孤岛。而对于这些孤岛我们怎么办？我们会发现通常意义上面会成为ESB的这种技术来解决这个问题，但是可能在座的有很多技术人员，大家也有人实施过。我们发现作为一个EI实施的时候，甚至比做原来的服务花的代价更大，那我们怎么办？这是什么原因？因为我们原来所有的架构都面临着这种单一应用去考虑这个问题。因此回顾一下我们很重要的特征就是，我们现在企业已经从单应用架构走向了多应用架构体系，而在多应用架构演进里面，我们希望现在的大系统都不是从原来的模式里面建一个大而全的。

比如我们很实际一点，像电信运营商，他们希望在原来巨大的架构下分解成下的架构实施。或者我们在银行发现，建设企业应用的时候，我们真正用模型的方法拆分出来，所以我们要给用户一个非常好的统一的视角。使得我们只有在这种架构里面，开发的时候就考虑了技术问题，而不是等我做完了，然后说我要做一个EI，把我的业务通过服务的方法，通过界面的方法表现出去，这样的话你的代价成本是极其高昂的，需要一个天然具有集成能力的应用体系结构。但是基于现有的应用体系结构里面会有什么样的技术特征？Garther当中有五个关键的技术特征，分布式部署、模块化、服务和客户端、可共享与管理，文档接口风格。我下面会针对这五种技术特征阐述一下整个架构的内容。

在分布式部署模式里面，我们很重要的希望解决One应用的问题，我们以前做的大量的应用系统里面都是一个系统里面包含了所有应用的模块，我们会发现一个很重要的问题，最简单的问题，如果发现我里面有一个特别重的操作，比如一个报表，我里面一个报表的操作访问量非常少。在这种情况下我们面临很大的挑战是什么呢？我会需要一种一堆的机器解决。所以我们可以看到，像e-Bay和淘宝，他在进行集群当中，我们很容易看到已经非常成熟了。很重要的一个特征就是我们希望逻辑本身是横向可以伸缩的，比如说把报表那一小块功能，在部署里面统一部署，只留了一种机器专门解决报表的问题，进行系统的开销和访问。这样的话我们需要应用架构设计的时候，就需要考虑能不能够随时的将一组功能模块随时的拆除、独立部署出来。还有一个很重要的关键概念，我们会发现因为互联网的应用，我会发现我们的客户数据是海量的，你有没有能力将我们的数据从单一的数据库走向分离的数据部署模型？

所以我们可以看到，现在有很多应用架构可以解决很多的问题，我们可以看到基于数据，比如电信的系统里面，可以针对本地接入号的区号来决定数据库在哪儿，容易根据区号的方式，注入到我们访问的逻辑里面去。这样的话对于我们的业务来说表现是一样的，但是本身很容易体现到分布式的部署，这是我们在分布式部署当中考虑的问题。

然后我们看一下第二点，我们要解决模块化的问题，我们模块化谈了几十年了，只要做计算机的人都说，这模块化我们读书的时候天天都在讲，但是我们发现一个很重要的概念，就是模块化真正能不能做到独立部署，可插拔呢？能不能把你的应用系统的某一个模块拿出来，使得系统能够正常运行？你会面临很大的挑战。

因此我们看到，一个非常经典的模块化的设计，它应用了这种技术很好的去解决了每一个软件模块的加载、启动的过程。并且很容易的通过应用的实现，业务进行伸缩灵活的变化。比如普元我们的开发工具需要在上面加注一项对于我来说，只要有一个插件进去，因为我在这个里面有了这个业务以后，很容易的去实现插拔的效应。但是对于我们的企业应用来说有同样的道理，比如我们在数据访问的时候，希望通过组织机构进行数据的过滤，有没有能力很容易的纠正一个插件，我整个数据过滤的方法和内容呢？这就需要我们整个架构里面去考虑这种业务点，很容易被插拔的，这是我们解决模块化一个很重要的技术和特征。

然后我们可以看到，要解决我们企业业务之间的收入问题，我们会发现不要直接访问别人系统的数据，那是标准的设计语言，只有一种方法才能保证对方的业务变化不会影响自己。并且这样还可以很好的提高高可用的问题，但是在SOA时代里面是怎么回事呢？实际上并不像大家以前想的那种特征，我们还会有新的元素，我希望客户访问我们服务的时候，他随着部署的位置自动的调用模型，在北京调用的时候对于这种来说怎么办？肯定是希望在你的架构设计里面就已经考虑了位置的问题。所以我们回头看一下，只有这种方法才能很好的去解决模块双耦合的问题。

所以我们再往下看具体的第三个特征的时候，就是服务的共享，我们可以看到Garther对于一个服务具体的定义的时候，我们发现现有三种形式的SOA服务应用，第一种的服务是怎么做的？70%的服务是已经有了，我只是有30%通过组合的方法利用。还有一种方式就是只要把系统包装出来变成服务，还有第三种就是全新的开发。但是我们回头看一下，对于上面这三种类型服务的时候，我如何实现共享呢？第一种就是服务的组装，第二种就是服务的编制，具体的服务组装我们可以看到，在服务组装里面我们描述了构件之间的关系，我如何去描述两个构件之间如何形成一个他们之间的依赖关系，然后再包装起来形成一个更大力度的构件呢？

形成更大力度的构件还需要以不同的形式暴露出去，这是在我们产品里面一个很重要的特征，就是引入了SOA的技术规范，描述了构件之间的理论关系，描述了小颗粒构件变成大颗粒构件的模式。还能够解决我们支持服务方式的调用，但是在这个图里面很技术化，看不懂，因为服务组装是解决具体的实际问题，给大家看一下，服务组装是解决了为已有服务提供的基础，我们具体如何去提供服务基础呢？可以参考一下，我们看看具体的设计方式。在Java时代里面，很好的解决了两者之间的关系，以及很容易解决双耦合的问题。它需要解决这一块的实现是什么，属性是什么，引用的对象名称是什么，通过这种方法就很好的解决了Java时代里面的各种方法。但是我们会发现在SOA时代里面，上述的问题是不能够解决所有的场景的，使得你的变成更加的透明，但是在SOA时代里面我们会发现，很实际，你的Java不能解决任何的问题，我会发现调用的方法形式是不一样的，因此很容易的去引入不同的协议，在这一套模型当中加入了协议。

还有我们的实现也有特殊的，我的实现并不止是Java，因此我们回头看一下，在SOA的时代里面，SCA就像一个SOA时代的Spring，所以给大家阐述的就是，SOA时代里面你的服务组装是用这种全新的架构模型装起来的，很容易将现有的服务组装出来。

我们会看到一个很重要的概念，将现有的服务暴露出去以后，还需要有更快捷的服务附用模式，我们在现有应用系统里面服务重新打包编制起来，我们用流程的方法。可以将一些很多无编制的服务变成有编制的服务，并且串在一起。而流程本身编排出来的结果也是服务，因此在我们系统里面，我们对流程里面还会有更多的体验，来解决人的业务流程的处理，还有解决业务模型的处理，在后续我们的演示里面会给大家看到如何编制这一方面的内容。

通过这种方法，使得我们的服务能够快速的定制，因为是图形化，可以使得服务快速的实施，所以服务编制提供了基础。而我们刚才提到了还有一点，就是我的接口是希望文档风格的接口，我们以前在面向对象模型的时候，大家会提到那里面希望我的数据和对象是一体的，你的数据和风险和企业行为在一起的，需要给你一个非常一致统一的数据业务定义，使得你很清晰的知道对方需要什么样的数据，而他具体操作行为里面内容是不用关注的。所以我们会给他提供一种文档结构风格的接口，而这种接口里面还有一个很重要的概念，就是接口的灵活性。因为数据定义本身就是伸缩的，如何解决伸缩的问题？

因此在这一点我们引入了关键的标准，就是SBO，它帮助你很好的解决了跨语言的定义。不同的系统里面之间，大家用统一的数据定义，然后因为有动态和静态的接口，使得我的数据很容易去伸缩。在一个对象里面额外增加一个属性怎么办？SBO里面很容易解决动态的属性问题，还提供了统一的数据导向，使得这种技术实现了数据的读取和访问的方法。并且通过标准的数据序列化的方式，使得在这个平台里面进行数据的交付，很容易将SBO对象展示，这个是这种风格接口的技术特征。

因为有了以上几个关键的技术特征之后，因此我们普元在整个SOA的技术架构，就是围绕解决这五个标准技术特征实现的。前面也提到过，在上一个时代里面大家提到的都是MAC，给大家一个标准的编程模型，可以实现界面和逻辑的问题，因此在SOA架构里面，我们可以看到最下面的就是资源层，提供统一的数据访问，我们会使用SBO的规范，我们还会有一层逻辑层，逻辑层很好的去解决了逻辑的编制，提供了多种实现，并且可以实现可插拔。通过构件的容器，对于这种扩充点的支持，很容易使我的构件插拔进去，并且通过短流程的方法使得我快速的编程。有了逻辑的具体实践之后，上面就是这种形态，很容易的告诉我，如果去解决外部访问的时候，给你一个标准的访问单位，并且解决了服务注册的路由等等一系列的问题，很好的解决了服务的包装形态。

在这一层我们很欣喜的看到，再下面告诉大家就是服务的提供者。它提供的服务，上面就是服务的消费，这边有一个流程图，我们有一个BPM的产品，我们解决了统一的任务中心，使得业务流程被管理起来，我们最终流程的消费是需要通过人的方法去把业务实施起来，因此最终的这一层实际上是协同，它最终解决了人、流程、信息之间的这种协同交互的过程，我们会通过这种方法，不同的接入形式，使得我们接入的方式非常丰富，并且很好的满足了我们业务的需求。而里面会有一系列的规范，使得界面的风格各方面都是统一的，这就是我们普元SOA整个技术架构，通过这些技术架构，最终支持了One应用，支持了快速业务的交付和快速业务的定制。而我们最终落实到具体的里面，我们会通过两个产品来支撑我们整个SOA的中间件内容。

下面就是BPS6.0，解决了SOA应用的平台，为快速的服务构造提供了稳定的运营和开发的平台，还会有一个SOA的流程平台，很好的解决了中国特色业务流程，并且通过业务的定制能力实现了快速业务的定制。以上就是我今天演讲的所有内容，谢谢各位嘉宾。

主持人：谢谢王克强。刚才程朝晖先生给大家馈赠了一个礼品，下面我们还有一个名额，由王克强先生送给现场一位有幸的嘉宾。

王克强：为什么说这个非常贵呢，我有客户花了几千万元买了，我给大家带来的问题是，我想问一下SOA的五个技术特征是什么？

嘉宾：分布式应用、模块化、双耦合、服务的共享和附用，以及提供文档风格的接口。

SOA以组件为核心，通过应用服务化、双耦合、可附用，从而带来了新用融合的灵活性，它循环改进商业流程，创造柔性业务管理，最终实现了业务与IT的更加融合。正如太极世界中的阴与阳，表与里，它们既相互对立又相互融合，而成为世界万物变化的规律。无极生太极，太极生两宜，两宜生四相，四相生八卦，八卦生万物。现在为我们表演的是城市太极拳传人杨松学大师和他的弟子们。

太极拳表演

主持人：接下来我们进入今天SOA新产品的发布环节，让我们一起来欢迎SOA应用平台产品线总经理程朝晖先生与SOA流程总经理刘尔洪。大家知道我们此次发布的新产品的Logo是一个太极，这也是我们刚才把城市太极拳的杨大师和他的弟子们请上来的原因，我们知道太极象征着无穷无尽的变化，太极的意向也象征着我们在SOA的世界里以客户为中心，将IT与业务不断的融合，从而创造出生生不息的企业动力，现在让我们的产品经理点亮新产品的Logo。

新产品Logo发布仪式

主持人：谢谢两位，请两位走到台前。我接下来给他们出一个难题，既然他们两个是今天所发布的两款新产品的产品总经理，我们给他们的挑战是，让他们在一分钟的时间之内做一个电梯演讲，清楚的给大家阐述他们产品的价值。就是你从楼底到楼顶的时候，可能只有短短的30秒的时间，在有限的时间之内把该款产品的价值阐述清楚，现在首先有请程朝晖教授这个挑战。

程朝晖：首先非常感谢在座一千多位来宾朋友见证这个时刻。这也应该说是中国人自主第一款打造的全球符合最新SDA标准的，我们还在酝酿当中，或者还不能完整的产品发布。大家都知道产品做广告都是要代言人的，我就请三位代言人，第一个其实就是我们在中国的五大银行的四大银行，买了我们企业级的通行证。另外我们有一位全球第四大电信解决方案的提供商，就是华为，他把我们的产品已经带到了30多个国家。第三个大家都知道，最近有一份CCID的报告，普元的产品在中间件里面排在中国市场的前三名。最后是这么多客户在信任我们，使用我们的产品，这也是任重道远，我们也是肩负更多的责任，把我们的产品做得更好，能够给客户更好的体验和更高的效益，以及更可靠的这种应用系统。

刘尔洪：各位来宾大家好，我主要讲三点。大家记住一二三就行了。一就是一天学会，可以打造入门级的水平，不信你去试试。二是两个保障，一个是案例的保障，一个是服务的保障，我们BPS这个产品，其实在各行各业都已经有了数百个应用案例，比方说在电信行业，我们大概有75%的省都用了普元的BPS产品，五大行里面有四大行都用了。那么服务的保障，我们在流程相关的实施过程中，会碰到的问题我们都由专业的服务保障，不信也可以找我们客户了解。三就是三个优势，更高、更快、更准，什么叫更高？就是高稳定性、高性能。更快就是比传统的模式，无论是开发还是我后面的实施调整更快，是传统模式的五到十倍。然后更准，就是因为普元是一个立足中国的公司，我们永远会以中国的客户需求为根本，不断的满足我们中国客户的需求，进行我们的产品规划。所以我们的客户也会更容易用我们的BPS产品解决你们的流程问题。不信大家可以去体验体验，谢谢大家对我们国产软件的支持，谢谢。

主持人：刘尔洪先生把更快更高更强的奥林匹克精神待到了BPS产品里面去，肯定会引起在座很多同仁的共鸣。接下来有两个提问的机会，针对这两款产品，如果大家有任何的问题现在多可以举手提问。我们同时也会有主题的T恤以及平台战争一书的赠送。

嘉宾：你好，我想问一下，BPS里面提到了中国特色的工作流，我想了解一下这个是指的哪些方面？

刘尔洪：这个方面比较细，其实有很多，因为中国的环境跟国外的环境很大的区别就是我们在涉及到组织和人的时候，其实我们很多流程都跟组织和人相关，涉及到这一块，它的不稳定性非常大，比方说在中国模式下我们有自由流，什么叫自由流，就是产品流程转到我这里以后，我决定下一步往那里转。这样一个流程的模式，你在任何流程的标准和规范里面都不会定义的，只有真正了解中国市场、中国客户需求的人，你才能够把这样的特性支撑的很好。其实除了这个之外我们还有很多其他的中国特色的流程，谢谢。

嘉宾：我是来自北京大学软件电子学院的学生，我们最近开了一门课程是和IBM合作的，是SOA的原理和实践，最近我们实验课上一直在用IBM的BPS，我想问一下咱们这一款BPS和IBM的区别是什么？

刘尔洪：举几个例子，贵州移动、安徽移动，我们其实在最终用户选型的时候，大的项目会做一轮测试，在这些测试里面，我们的性能和适应功能的变化速度，我们都是第一名，不仅如此，就是在这些项目，我们的稳定性也是最好的，所谓稳定性，在测试里面有一个，我在持续、高压力的并发状态下，要去看整个流程和事务的成功率，普元是百分之百，但是其他的厂商做不到，谢谢。

嘉宾：程经理你好，我有一个问题，我们在谈论SOA的时候，基本上都谈论它的业务方面的灵活性以及高附用性，因为我们业务由很多模块组成的，这其中又涉及到一个安全问题，我们在业务层面的安全，组合的时候和我们之间要遇到授权与策略管理的问题，我们在这些产品的报告里面都没有提及这些问题，我想请问一下您是怎么考虑的。

程朝晖：谢谢，这是很好的问题。在这个价值的第四点当中，就是可靠性，其中含有安全这一块，因为在企业级应用里面，安全是一个最基本的要求，这个不是说可有可无的，是必须的。这样一个安全其实从SOA体系里面，它对安全会做得更深入。一方面原来的安全可能更多的是基于应用，整个系统的安全，现在会基于更小力度的每一个服务。在SOA体系架构里面，如果关注体系架构里面，包括标准规范，包括普元的实现里面，标准规范里面都可以把你更灵活的安全策略，针对不同服务的不同颗粒度的构建安全策略都可以根据你自己的需要注入进去。当不同的用户甚至于不同的前台客户端的内容都可以针对某一个服务或者某一组服务采取不同的安全策略，是已经提供了这么一个比较灵活的框架，具体的实现还是需要根据我们的业务要求，把我们的安全机制注入进去。

嘉宾：我是交通部水利科学院的，我想问一下，因为是属于政府应用部门，我想知道一下这里面集成了哪些国家政务系统这些标准又开发了哪些新的标准？因为您说要研究符合标准的问题。

程朝晖：首先EOS包括BPS，我们这个产品不是针对某一个行业的产品，我们是一个技术平台产品。所以我们支持的技术一般都是像SOA这样一些技术和标准，当然现在在这方面和行业的一些标准，其实也是在SOA体系里面发展的。在刚才开始的时候我提到过，国家在工信部，包括国家标准化委员会共同领导的中国电子技术标准化组织，普元也是这个组织的创始人，这个组织现在把体系确定下来，包括参考模型架构，也是做了非常多的裁减。因为在SOA标准体系里面有很多的标准，有很多已经淘汰了，我们的客户可能很困难理清楚。这件事情完了之后就进入到行业SOA的规范和标准，目前包括制造业，包括金融业，您讲的政府我可能也会去关注一下，看行业的标准记录和我们的横向标准记录共同合作，在电子政务推动SOA行业标准的发展。

主持人：我们知道SOA有四种典型的应用场景，其中第一种就是即插即用的One应用，One应用的提出其实是当越来越多的系统出现后，企业用户渴望一种简单的回归，简单的页面和应用就可以实现全业务的管理，在它的背后将会出现哪些挑战，我们接下来请出的嘉宾袁义先生将帮助我们回答这些问题。袁义先生是资深的技术顾问，长期致力于面向构件和SOA技术理念方法的实践，擅长于项目管理、软件实施等方面的咨询，让我们一起来欢迎袁义先生，有请。

袁义：谢谢主持人，谢谢与会的各位专家！

在前面程朝晖先生给我们介绍了SOA从应用开始的几种模式，接下来的时间里，我跟大家分享一个银行的具体案例，通过这个具体的案例，我们感受一下对于即插即用One应用实施的效果。

在开始案例之前，我想和大家一起认识这家大型银行的几位专业人士。这位是老陈，他是浙江大型银行的业务主管，老陈每天通过银行的IT系统处理各种数据和做一些工作任务，这种系统包括在CM这样的系统里面审批客户的工作，比如说在办公智能化的系统里面去审批请假或者是做财务系统的一些审批，或者是去做一些信贷系统里面的审批。你会看到前面都加了一个系统，这个应用那个应用的系统。那么这些系统都会给老陈带来这些工作的任务，也就是说老陈如果每天工作的话需要到这些应用里面查看或处理任务。但是如果说老陈有一天忘记了登录其中某一套系统，而这套系统刚好有一个很重要的任务的话，他有可能在这一天就忽视了很重要的工作。但是同样的话，也可能他登录到了一个系统，发现这个系统里面根本就没有他的任务。

接下来这个美女叫小雨，她是这家大型银行几千名信用卡人员中的一个普通的营业员，她在工作过程当中，会使用到日常处理业务操作的系统，或者说发起一个联系单的系统，或者说查询知识库，查询费用积分、帐务等等。这些系统因为提供的都是不同的应用，在不同的时期，不同的开发团队去开发出来，应用之间的操作风格的差异性比较大，而且鼠标点击的层次比较深，所以在一天工作下来，小雨每天的感受就是觉得肩膀很酸胀，手指乏力。

这位小伙子叫小张，他是这家大型银行的一个IT的工程师，他也同时是经营的高手。小张在IT部门做五套系统的维护工作，包括这些系统日常的日志处理、备份、系统的监控或者说这些应用的Bug的修订，或者增补一些小的功能。他在政务的工作任务里面，这些系统也都是他所熟悉的应用，但是每套系统应用产生的框架不一样，技术的规范也不一样，所以他一天忙于应付这些工作，经常在加班，但是他的处长似乎对他的工作不是很满意。

我们认识完这三个人以后，我们看到这几位专业人士在银行的不同部门工作。我们看到这家银行，在IT建设过程当中有存在这样一些现状，系统非常多，可以看到像左边像蜘蛛网一样的应用，以及应用之间的关系。这些系统技术架构非常发散，维护代价都很高，而且每一套应用之间因为在不同时期做出来，技术规范也比较难统一，系统之间，包括系统内部的耦合性太强，很难去分离相应的业务模块，对于未来的变更管理非常复杂。在业务部门看来，这些系统在操作过程当中不断的频繁切换，操作的风格差异很大，培训的成本都很高。很多的应用采用了一些流程去实现，流程会产生任务，这些任务因为在不同的应用里面，所以分散到不同应用里面，导致老陈出现的局面，需要登录不同的系统使用系统提供的任务。

像这样一种现状，实际上目前还在上演，新的业务应用还在给不同的部门提出来不断的建设。在这个背景下，这家大型银行的IT部门就在考虑，这么多应用还在不断的建设过程中，我们是不是还要重复昨天的故事呢？在这种应用下，基于SOA新的架构以及基于SOA的运营平台，他们提出了一个叫One的解决方案。通过这个One应用的解决方案，一方面提供了基于统一的企业应用中心来包容相应的集中工作平台，集中的任务中心以及基于一个统一的应用平台去构造一些新的业务模块，这样一种方式来解决前面所遇到的问题和挑战。

这个应用的方案提出来实施之后，实际上是给两个层面的体验都有一些改变。首先就是基于One应用的这种模式，从系统的使用者体验来讲，我们都知道可能能整合不同的应用和界面，但是仅仅是把这些界面整合问题做好，但是真正的实现One的概念，在这个里面是没有达到的。所以One应用使用的体验是单一的操作入手，一个集中统一权限的控制和一致的操作风格体验，以及集中任务的处理。从One应用IT建设者的使用体验来讲，它跟以往的IT建设也有很大的区别，首先未来所有业务的建设不再是一个一个建设，而是一个一个的构件，我们成为构件或者是模块。而这种建设是基于一种统一的技术架构，统一的平台，统一的规范去进行。所以在这种建设过程当中，他的业务功能是在增量式即插即用的方式体现出来。

陈先生的特点就是说，应用不存在，存在的是模块化，存在的是流程、服务，而这些之间实现松散的耦合、配置和组装。最终一个大的银行不可能在一个物理的环境下部署所有的业务，所以实现分布式的部署，而实现集约化的管理。我们接下来给大家看一看One应用的体系架构，对于所有的使用者来讲，无论是业务操作人员、管理人员、系统的维护者，他在使用银行的IT系统的时候，他看到的是一个统一企业的应用中心，在这个企业应用中心里面提供了统一企业的桌面，提供了集中的工作平台，实现了权限和组织用户的管理，提供了集中的任务中心。在这个框架下面，对于具体业务的内容可能是部署在不一样的基础环境上面，那么每一个具体的业务，我们物理上可以把它看作是物理的应用，那么这个应用物理环境的时候，就可以注册到其中的工作平台。

在应用里面去实现一个个业务松散的构件模块的时候，实现一个，部署一个可插拔的方式注册到这个集中工作平台，然后注册之后经过一个功能的菜单，这样的话业务用户就通过菜单的方式去执行这样业务的功能。像这样的模式，所有的业务模块不断的实现的时候，当业务里面出现流程的话，通过企业的流程平台推送到其中的任务中心，对于前端来讲同样是通过企业应用中心实现集中的处理。在了解完大概的背景和总体的框架之后，我们现在可以跟大家一起分享一下具体的一些体验内容。在这个体验里面，在这些演示里面，无论是一个IT的管理者还是具体的业务人员，是通过统一的企业运行中心进入，可以看到在操作台上所有业务的操作，这些业务操作可能来自于ABCDE很多套的系统，这些系统之间可能对于小雨和老陈来讲并不清楚是来自于什么应用，但是他们集中的呈现在工作的空间里面。对于配置来讲，在工作台里面提供了介入，这个应用不是在任何一个物理的环境里面，实现功能的介入，然后再把功能配置成相应的菜单，分配给相应的角色，再把角色赋予给相应的人。

同时在各种不同的应用里面，都会涉及到用户的组织模型，用户的组织模型同样也会在企业应用中心的集中工作平台里面进行管理，这样的话不是说没法应用，都需要去实现一套用户组织的管理，而且数据和服务是基于共享的。同样对于流程的应用，因为在这家大型银行里面不可能说所有的系统都共建在一个流程平台之上，可能每一个地方都有一套流程引擎，把流程统一注册在企业应用中心里面，这样的话基于这些应用流程的任务，也被通过服务的方式推送到企业集中任务中心里面，这样的话当业务运行的时候，所有企业的流程都推送到集中任务中心，这样老陈进入到这个系统里面，看到的任务可能是多套应用，对于他来讲就是一个感受不到的，是一个完整统一的流程任务中心。要做到这个目标，在原来进行IT建设过程当中，也存在小张的模式，就是有不同应用的发生的架构，包括比较老一点的模式，或者是直接Java的模式，而且维护成本比较高，系统与系统之间的整合比较复杂。

为了打造这个One应用的体系架构，他们需要做的很重要的工作，就是把这个架构统一到SOA的架构上面来，就是构件业务的基本单元，基于构件事先开发、部署、管理和维护。同时这个构件的标准是基于SOA的规范实现的，在这样一个框架里面，在基于第一套统一的技术规范来实现技术构件与一些平台整合集成构建的分装。围绕这个统一的技术架构，去构造一个SOA的应用平台，去实现单一的这种不同构件的开发，然后在这个平台里面提供了相应的一系列平台化的特性，比如说一体化的开发，构件的容器，然后就是基础的构件库，应用的一些框架，还有包括像流程、规则、报表业务化的平台，以及在对于这样一个平台上开发任何一个构件服务的管理监控的环境。所以借助于这个平台之后，实现企业应用中心里面一个集中工作平台的时候，在集中工作平台里面去实现一个基础的应用框架，包括统一的权限控制，统一的用户组织的管理，这个实现的框架可以不用到任何一个业务的具体物理应用环境里面，业务的应用物理环境里面再去实现具体的业务构件，这样用户再注册到企业应用中心的平台里面，实现一个无差异化的透明访问。

对于集中任务中心来讲，同样在中心里面提供了代理的服务，每一个业务的应用理念会部署他流程的引擎，产生基于这个业务流程的一些工作，这些流程的任务会通过在业务应用里面的代理来实现对于所有任务的一个自动的推送，自动推送的手段，可以实现多种方式。比如说可以基于Web Service，也可以通过ESP企业服务的管理平台，基于消息的方式实现这种推送。当然也可以通过其他的方式推送到像邮件系统、短信平台、即时消息这样一些多渠道的平台。这就是作为One应用框架最核心的几个特点。基于在One应用的体系模式下，一个具体的业务内容实现的过程是怎么样的呢？从需求来讲，还是同一个时期由业务提供的需求，这些业务的需求通过分析，交付到IT部门，IT部门构件方式进行构件化的设计和开发。开发是以一种共建的形态开发出来，在部署的时候就在One应用的体系上考虑部署策略的问题。前来王克强给大家介绍了作为逻辑层面的横向伸缩的能力是部署的形态展示的，在部署的时候我们既可以把开发的一些构件布置在已有的服务器环境上面，也可以把它独立的部署到一个新的物理环境上面，基于这种横向的扩展。所以假设这是一个已有的IT物理部署环境，有可能会把其中的某一些开发新的模块即插即用的方式部署到原有的服务环境，也可能会把开发的一些新的构件部署到一个新的物理的环境里面。第三个步骤就是把部署好的内容再接入到企业应用中心，交付给最终的业务部门进行使用。

所以采用这样一种模式的话，我们可以看到老陈在这种模式下，他每天是通过集中用户中心的任务列表来处理和浏览不同的任务，这样不会遗失工作，也不会因为没有登录耽误时间。作为小雨的话，她可以把所有能够操作的业务内容都整合在一起，这样可以非常方便快捷的操作他所需要的信息，而且每一次操作的次数由原来的鼠标点击5次以上，缩到每一次要完成一个操作只有鼠标点击在3次以内。对于小张来讲，因为他基于了统一的业务平台业务模式的开发，在开发、更改和维护的过程当中变得从容和省心。所以在这样的体系下，也进一步的印证了前面程朝晖先生所提到的基于即插即用的One应用所带来的四种效果，就是体验更好、效率更高、灵活性更好、可靠性更强。这种体验在对于老陈来讲，他的操作体验、工作效率和小雨一样都得到了提升，而对于小张来讲，他的维护效率、系统的灵活性和可靠性也得到了保证，所以这个即插即用的One应用是非常棒的效果，希望大家感受一下。

主持人：大家认为刚才他讲到的即插即用的One应用有没有什么问题？

嘉宾：袁先生您好，我是来自西门子的。我有一个问题，刚才您的系统架构图没有完全放出来，你的自己新建的业务，新的流程用这个One应用的话应该是很方便快捷的。但是像老陈原来就有很多种旧的系统，他很多重要的业务都在那些旧的系统上，你怎么保证快速的把这些东西集成到这里面，而且能保证它不出问题，这是一个很大的问题。如果说你只是开发了一个新的东西的话，他可能多了一个新的系统而已，如何推动这件事情呢？

袁义：你的问题提的非常好，也是大家非常关注的问题。的确在我们的案例里面，当时更多考虑的是新的应用实现模式，不需要重复昨天的故事。所以更多的是考虑新的，但是对于老的有几种策略，首先就是说对老的有三种模式，第一种就是老系统本身可能已经进入到生命的终结期了，所以对于这一般应用有新的模式重新搬过来，还有一种应用就是比较好，可能存在二期建设和三期建设的情况。这种模式纳入到One应用的体系架构里面，考虑到的方式主要就是把它的服务或者把它的这种界面做一下整合，当然效果肯定没有达到我所描述的这种最新业务模式的效果，但是实施现在这种整合，界面的一些处理。包括我的体验里面也有，比如说邮件系统是一个老系统，但是也可以介入进来，或者说原来的客户管理系统都是可以介入进来的，但是在操作体验上风格可能还是跟新个One应用模式有一些差别，这个是不得以的。第三种模式就是基本上也不需要做调整，很稳定，像这种情况的话，主要还是基于门户的整合方式，还是维持原有的现状，他考虑的更多的是未来的模式。

嘉宾：袁先生你好，我们是做石油方面的开发，因为您今天所有的人举的例子，我听到的主要就是银行和电信的，或者电力的，还有一些政务方面的，我们做石油方面的一些应用系统，现在遇到很多的典型问题，在石油行业里面。更多的倾向于一些专业的应用，专业应用就是一些算法或者模型，这样的一些应用在原先，在过去主要是集中在一些Linux平台等等，一般是上百G的数据量。这样一些应用我们在油田方面都在探讨，如何把这些应用能够通过SOA的模式发布出来，供油田广大的研究人员进行应用。这一块请问对于一些国际上大的专业的集成和发布？

袁义：这是代表了企业信息化的问题，我们现在在中石油、中石化也有相应的一些案例。这个问题很具体，可能一下子回答得很清楚也是比较难的。我想大概的意思就是说，我们在整个SOA体系里面更多考虑的是业务模块化的分装、松散的耦合和部署的融合性。您提到大容量的效率问题，可能的确在SOA解决方案里面会有相应的特殊解决方案。我觉得在这里可能会涉及到SOA业务平台之外的一些处理，比如说你的数据整合、集成领域的内容。有机会的话我们可以私下里再沟通一下，因为SOA业务平台解决的是业务模块的综合问题，因为在整个SOA解决方案里面整个范围是比较广泛的。

我给大家进行一下演示，这些系统都是在不同的环境里面，包括前面还有邮件系统等等，这些应用的效果，实际上也有不同的风格，比如说业务应用想转换一种风格，基于Windows的操作模式，进入到这样一个操作风格，同样整合业务的操作，而他的体验，打开任何一个业务内容，我们点击一个具体的业务内容的时候，可能就是一个构件，即插即用进来，大家可以看到这是具体的一些业务的内容和界面。因为时间的关系，在这一部分我就不继续下去了，到时候提供给网站下载。

主持人：感谢袁义与我们分享SOA模式之一，即插即用的One应用。接下来的话题是SOA应用模式之二，业务导向的流程定制，分享这个话题的嘉宾是王程志先生，王程志也是BPS业务流程产品的专家，同时他主持了普元业务流程平台产品BPS的一些规划以及管理工作，有请王程志。

王程志：大家下午好，我在这里有一个非常精彩的案例跟大家分享。上面在我们发布产品的仪式里面，我们BPS产品线的总经理刘总提到我们产品的一个很关键的特性。下面我给大家展示一下这方面的情况，让大家体验一下。一就是我们如何快速的实现我们的流程，二就是我们通过一个案例的方式给大家展示，三我会给大家重点的介绍高快准的快，就是如何来实现流程快速的调整和优化。

上面我们确实也介绍过，变化会让SOA成为主流，我们通过两个方面看这样一句话，其实我们在现在竞争日益激烈的环境下，我们可以从多个方面体会到我们的变化。比如说我们在实施一个同版的应用，在各个省份来进行实施的时候，我们可以发现它需要根据各个省个性化的需求来实现我们流程的一个灵活的调整，这是第一个。第二个就是我们在很多情况下，我们实现一个业务系统，由于业务系统的模型不是非常的成熟，在这种情况下，我们可能也会面临在系统上线的时候，需要对这个系统很多业务和流程、规则、表单等等进行调整。那么这个也体现了一个变化。第三个刚才大家也提到了，我们在进行业务创新和管理优化的时候，往往也需要实现流程快速变化，以支持我们业务的创新和管理的优化，这是我理解的第一方面。

第二个方面就是我们可以通过SOA这种方式，让大家更快的去适应这种变化。通过什么方式呢？就是我们今天介绍的三种应用模式，我介绍第二点，业务导向的流程定制，它真的能快速的解决流程变化的问题吗？我相信事实胜于雄辩，下面通过中国移动NGI-CRM领域的客户端系统给大家展现一下业务导向的定制方案在现场实施的效果，希望能够给大家带来一些启发和收益。下面先简单说一下这个系统的背景，这是中国移动在08年启动的应用当中一个小的模块，在这个模块当中，由于很多新建的困难，所以当时作为我们中国在电信领域最大的节能商之一来实施，由于保密的关系，我可能不会详细介绍具体是谁。它在中国电信领域业务支撑领域占有半壁江山，在这里他实施这个系统的时候，我们来看一下他当时所面临的有哪些挑战，这些挑战我相信大家可能都做过很多应用系统的实施，都会有似曾相识的感觉。

第一就是用户的需求不稳定，我刚才其实也提到了，由于业务模型是一个比较新的业务，所以说由于业务模型的不稳定，由于各个省的业务差别比较大，因为当时是三个省同时实施，另外最关键的一点，由于是试点，其实中国移动总部也希望通过试点实施不断的去完善业务模型，进一步完善业务流程。很关键的一点就是在实施的时候，需要在上线的过程中不断的去通过优化的方式来响应这个变化，所以说当时上线基本上可以平均下来，我们当时估算了一个数据，要达到平均每人日完成一个流程的调整、演示以及上线。

由于所带来的第二个难点就是我们他们当时实施过程当中发现项目工期特别紧张，体现在几个方面。第一个就是当时要在五个月，因为这个系统的应用试点是在08年的6月27日启动，在年底总部要求在当时五个试点省上线，这是第一个。该集成商在实施的过程当中，在7月份他们使用国际上比较有名的产品在做。但是实际上花了两个月左右的时间才实现了这样一个流程，并且后来由于这方面的原因，还有其他的比如说流程平台发展的前景不明朗等等，导致了后来没有采用。很关键的一点就是当时在实现过程当中，用户要求他们一个周完成两个项目的实施，所以工程量是非常紧张的。第三就是人员紧张，由于业务扩充，由于三个省的同时实施和对人员的集中要求导致人员比较紧张。第四他们考虑到做产品类型的公司，在后期实施的过程中如何来快速响应，如何实现流程的应用，快速的传递到后期的实施人员和维护人员，在这一块都对他们提出了一个很严峻的挑战。我相信这样一些问题和场景，或者这些困难，我们在实施应用的时候大家都遇到过。

我们可以看到他们最后实施的效果是怎么样的，下面通过所反馈回来的信息看一下实现的效果。首先在需求这一块，当时确实出现了各个省业务模型不一致导致的各个省需要进行个性化的定制实施。在这里首先在公司内部实现了三个省的三个产品，每个产品实行了三个业务，九个流程就到各个省进行实施，在实施过程当中比较快速的进行业务的方式来实现一个个性化的实施。在上线的过程当中会出现刚才我所介绍的，基本上刚才说时间久了之后，到其中的某一个省进行上线。这个上线基本上当时8月份就实现了9个流程，9月份实现了近20个流程，这20个流程我们可以看到，在9月份实现了基本上达到每个人天要完成一个流程的上线。在给另外一个省做上线的时候，由于保密的关系可能不会具体说出哪一个省，在实现上线的时候，要求他们在一周的时间内实现两个流程，也就是说基本上能达到两人日完成一个流程原形。

另外一组数据，最后在8月底启动，4个月要实现三个省的上线，基本上每个月达到上线一个省，这是他们当时实现的效果。从项目人员紧张这一方面也可以看出，从当时的8月4日到8月8日，正好是去年奥运会之前，他们要实现刚才所说的两个流程的实现，在这里他们当时是三个人，基本上可以达到一天的培训，这个要给大家实际的提供一个数据。我们第一个是快，就是一天可以学会，跟这个关系是非常大的。他们基本上由前期的三个骨干，分别带着几个新人到每个省市实现个性化的实施，他8月底招聘了一些人，进行分布式的实施，更带来了困难。后期也体现了确实需要新人来实施，刚才也提到了分布实施并没有带来太多的困扰，这个就是我们所说的如果把前期实现的流程更好的传递给后来的实施人员。通过最后的实现效果，我们可以看到，实际深已经超额完成了当时项目所规定的任务，从原来的四个产品的三个业务，一共是12个流程，但是实际上他们实现了7个产品4个业务的28个流程，这个省也是类似的，已经超额完成了这个任务，达到了客户的要求。

大家可能会有疑问了，如何体现这三个优势当中的快，这是当时产品线的负责人反馈产品的时候说的，我们基于业务化的定制方式确实很有特色，一方面解决了原来一直头疼的问题，如何实现同版的应用，可以在多个省进行差异化的实施，这个当时确实解决了。第二个问题我们可以看一下，他当时需求不稳定是非常头疼的问题，在这个过程当中，他们确实也采用了我们这种方式，更好的解决了。最重要的就是由于业务的扩张，当时人员紧张的情况是他们非常关心的。通过我们的开发效率，平均每二人日实现一个流程，也解决了他们项目工期紧张的问题。

下面通过具体的案例演示，给大家展现一下他们当时在T省的流程，到S省实施的时候业务流程的变化。下面通过冰山一角展示一下这个流程是如何变化的，我们可以看到，在流程具体某一个环节，原来是业务方案的评审就可以了，现在由于各个省的业务不一致，会导致可能在某些业务的情况下增加一个流程的环节，这个变化会体现在我增加一个流程环节，在某些情况下，也就是在某些业务规则下，我去增加环节，业务规则会发生变化。第三就是这样一个环节是谁来做？这里我们可以看到，他的参与者我们可以灵活的调整。第四个我们这个环节做需要有什么样的约束和要求？也就是当时他们所提出的，比如说我需要两个工作日完成，那么在这里就是我所说的第四个，KPI实现的调整，当然这是最关键的四个。

我们下面看如何来通过快的方式敏捷的响应流程的变化。需求不稳定、项目工期紧张、人员紧张。基于Web的方式进行流程的调整过程当中我们可以看到，我们现在演示的是一个短信受理流程的变化过程，首先我们可以看到，基于在技术层面上所分装的服务以及通过服务装配流程中的环节，通过环节来实现流程的编制，下面我们可以看一下。主要演示的是一个流程变化的过程，实际上在流程新建的过程当中也是类似的，刚才上面提到了，变化的过程在这里重点介绍四个方面，环节、业务规则、参与者以及我们的PKI实现，下面一一来看一下。

在增加环节的时候我刚才提到了，在某些业务规则下，也就是说我在这个业务场景下比如说客户级别大于一定程度的时候，我才需要进行业务方案的步审等等这样一个环节。在这里可以看到，我们可以实现业务化的方式而非编码的方式实现流程的调整，在这里可以看到，第二个关键要素业务规则的变化，是通过非编码的方式。第三个可以看到，在这个环节当中谁来做？就是它的参与者，我们对参与者的设置也是通过比较业务化的方式进行设置，比如说我们可以通过一个规则，某某条件满足的情况下可能是A参与者来实现，否则是B参与者，在这里确实也是通过一种比较业务化的方式来实现流程参与者的调整。第四个对于时间限制也是类似的，我刚才举了一个例子，在两个工作日完成，什么是两个工作日呢？这就是我们通过比较业务化的方式定制我们的工作日历，是4×8小时还是6×9小时？另外我们还可以看到在PKI时间限制发生的时刻，我们通过一些业务化的事件，比如说通过短信通知，甚至可以在快超时的前四个小时通过邮件和短信通知具体的参与人员，通过这种定制的方式，我们可以非常灵活的实现流程的调整。在这里其实演示的是四个方面，在业务上我们还可以进行其他更多方面的调整。流程调整之后，我们下面可以马上看到，我们可以实现流程的再现用户数，重新服务器服务器就可以生效了。在发布部署之后，下面会通过一个实际的例子给大家演示一下如何让它即时生效。

通过一个表单实现业务流程的启动，通过图形化的方式实现流程的监控，在这里流程已经启动了，我们通过流程客户端查看到我们的大半任务，通过大半任务查到我们流程的监控，进而看到流程之间的轨迹。在这里我们会继续往下演示几个环节，这里我们可以看到，刚才所增加的一个环节在这里已经体现出来了，并且大家可以看一下下一步我刚才设置的条件是客户级别大于三的时候，实际上这里是四，我们可以看到，他已经按照我所的规则走到我们新的业务方案复审的环节，大家可以看到，通过也许一种案例，我们可以通过比较业务化的方式来实现流程的调整和优化。

上面是我通过一个具体的案例给大家展示了一下如何快速的调整我们的流程，这就体现了我们三大优势其中的快，我们是怎么做到的？通过刚才演示的过程，就是通过这样一个过程展示的。第一我们通过在技术层面上所实现的服务，这个包括页面服务和业务服务，通过这个服务我们进而来装配流程的环节，通过环节我们来实现流程的编制，也就是实现面向业务的定制与调整，刚才主要演示的是一个调整的过程，调整之后我们通过任务数发布流程，以及通过管理监控进行运营、管理和监控，当流程发生变化的时候，我们一般情况下只需要在业务域去实现流程的调整，只有到我流程变化比较大，比如说我增加了一个环节，这个环节所调用的服务不存在，或者需要调整的情况下，我们才需要到技术域去实现或者调整这个服务，这是我们实现的一个过程。

下面可以看到，这个过程当中很关键的一个要点，我们对比传统业务定制的方式和技术定制的方式他们之间的差别，我们刚才其实已经展示了，比如说传统的方式我们在调整流程的时候，可能需要通过很多编码的方式来实现。刚才我们定义的方式，大家可以看到，我是通过一个比较业务化的方式来实现我的流程、规则以及对我参与者等等相关方面的调整。上面其实是我通过一个实际的案例给大家展示的实现效果，这个效果其实底层就是采用我们刚才所发布的BPS产品所提供的一个面向业务的解决方案来实现的，这个解决方案，BPS产品为什么可以做到这个层面呢？其实是跟BPS的设计思想是相关的，首先BPS是在流程引擎之上提供了一个比较业务化的定制工具，通过这个工具才可以实现我们刚才所演示的业务化的调整。我们对比传统模式跟这种模式的差别可以看出来，传统模式刚才我们上面陈总已经介绍了，从业务部门提出需求到技术部门去进行需求的分析、设计、开发、测试以及布置上线，一直到我们发现业务部门验收的时候才发现流程没有满足需求，这时候我们可能需要进行迭代，会导致流程变化的周期非常长。在这种模式下，我们刚才做演示了，我们对流程的变化主要是在业务域来实现变化，这样我们可以发现流程变化周期非常短，并且可以敏捷的响应刚才我们演示的流程变化。

最后我们来总结一下，上面刚才提到了，其实挑战是什么？就是变化，变化体现在哪些方面？需求不稳定、地域差异、业务创新等等，这个变化传统的实现模式我们可能会发现调整的周期非常长，我们通过解决方案几个主要要点，第一个就是可以业务部门更多的参与，因为是比较业务化的方式参与到流程的调整过程中。第二个是可以实现在线的即时调整，通过这个我们刚才也演示了，可以实现流程的敏捷变化，并且可以达到我们持续优化流程的目的。无独有偶，其实这种宾馆并不是我们提出的，在刚才的统计报告里面也指出，在最近一到三年，业务的敏捷性和流程的持续优化是面临的最大的挑战，其实我们刚才介绍的一二三的准，也就是普元的BPS其实就是瞄准了客户的这种需求。

希望通过以上的介绍，大家能够从过程当中发现一些对于我们有启示的东西，最后希望普元的BPS能够助大家打造持续、敏捷和优化的流程，我今天的介绍就到这里，谢谢。

主持人：谢谢王程志先生，下面进入一个简短的互动环节，有一个提问的机会。

嘉宾：我想请教一个问题，关于具体实施方面的问题，对于一些比较大的单元或者机构，会有一种需求，就是说在整体的流程里面会有一定的内部流程，然后对于刚才您提到的这种大型的全国性的应用系统，在纵向会有这种流程中的流程，也就是说对于横向的，因为不同的业务有这种不同业务需求之间的流程对接，我想问的问题，不是说普元产品能不能实现。我想问的是针对于这种业务需求，对于实施团队的支撑，咱们产品的支撑主要有哪些？

王程志：您刚才问的问题非常好，正好贴切我刚才所介绍的案例，您提到的这种跨系统或者甚至跨部门的流程，其实我们在这里会有不同的解决方案。我们上面介绍的第一个是通过我们这种短流程，比如说通过流程的业务服务编制体现短流程的编制，第二个我们在实施方面，其实刚才提到了，到实施的时候可能会面临各种不同的问题，比如说可能A地域跟B地域的要求是不一样的，那么这个不一样我们最主要的是通过前期的一个流程的设计，规划的时候要去把这些服务抽取出来，然后我们在后续实施的过程中，甚至我们在上线的过程中，基于这些抽取的服务来实现流程的快速调整。

主持人：接下来进入二等奖的抽奖环节。

抽奖环节