焦烈焱：大家下午好，非常感谢大家有这个机会和我们一起分享对SOA的构造、应用和技术平台的一些想法。刚才沈先生讲过普元这个公司，像一群农民一样，在哪里耕耘着、收获着，忽然一天发现赶到了浪潮上，做成了这样子。从这个角度上讲，我做农民已经很多年了。今天我们最重要希望跟大家分享我们这几年的收获、耕耘当中，我们看到我们始终有一个目标：怎么帮助我们客户快速构造应用、系统，怎么样帮助我们合作伙伴适应在SOA的浪潮下适应这个浪潮，怎么去提供这个平台，然后能让大家更容易、更简便地构造SOA的应用。所以在我的主题里面，我会跟大家讲在SOA的应用构造下，或者叫做SOA版应用中很重要的环节，服务是怎么构造出来的。我的同事会在下一个主题里面给大家介绍这样的业务流程如何构造出来，如何重新编排。

　　在普元，刚才也有朋友提到问题，我们会有哪些技术的发展，有哪些新的惊喜带给大家，后面我也会有一定的产品演示，给大家做一个演示。现在普元基本上有两个产品，一个是US的产品，主要是做服务构造这一块，还有BTS的产品，做流程编排、流程定制这一块。今天我们会说一些，刚才沈先生讲到SOA版的应用，它的生命周期有四个部分：规划设计、构造流程、营运管理、监控治理。我会讲规划与设计这一块，然后我结合产品的演示，看怎么构造这个服务，怎么构造SOA版的应用。

　　其实我们最早的时候，我们在做CS、BS的结构的时候，我们发现有一个方法论在这里面做支撑的。这里面的方法论就是面向对象。大家都知道，这里面有OA、OB这样的方法，它会告诉我们怎么用面向对象的方法，怎么用面向对向的方式去构造一个CS、BS的结构，我相信这个道理不用我讲，大家都会做这方面的应用。但是到了SOA的时代，构建一个SOA版的应用的时候，同样需要一个方法论，需要一个方法去支撑，这也是我今天的第一个话题，就是怎么样去做规划和设计。

　　其实，在SOA版应用的规划设计的时候，我们同样有一个输入和输出，输入是我们SOA的业务蓝图，输出就是经过你规划设计之后怎么去构造服务、构造这样的流程。然后我在中间这个大圈里面讲规划的设计流程。我讲一下输入，因为这里面一些词大家觉得新鲜一些，跟大家做一下沟通和交流。首先什么是SOA业务蓝图呢，举一个例子，SOA的业务蓝图，实际上SOA是从业务出发来看这样的应用、系统、业务组建、业务构件是怎么规划设计出来的。然后每一个企业，实际上你都会有SOA的蓝图规划，通过这样的规划，你可以把你的业务领域、你组建模块化的方式组建出来，你有了这样的方式之后，才能做到刚才讲的精细化的分工，什么是你企业核心机制，不是你企业的核心价值，什么是你优先解决的，什么是你最重要的。举个例子，招商银行它的核心价值是什么，就是它的一卡通，所有跟一卡通的东西，一定是放在最优先级上去，用最好的资源、最大的精力来做这件事情，也就是说一卡通做好了招商银行就做好了。同样我们面临的客户都有这样核心差异性的业务。在这里面，SOA的业务蓝图，我们知道哪些东西是我们要做的，是在这里面重复建设的，要避免的。实际说在应用蓝图上规划出来的东西，也就是程先生讲的业务的组建、业务的模块，我们的企业就致力于把业务的组建、模块做得最好，把这些模块做到产品化，做到深挖、精研，做到最好。这里面我们有一个建议，如果做SOA的试点的话，找差异性的业务来做，我们不建议你们找一个边缘的业务来做试点，这样的话，SOA的个性、SOA给我们带来的价值未必会体现出来。每个企业有每个企业的不同情况，这是我们的建议。

　　有这样的蓝图之后，我们知道我们先要做哪些业务，我们有那些业务的模块出来了，这些业务的模块相对来说是比较大的业务模块，这个模块可能跟我们一般来说OA、OB这样小的技术上的模块区别还是比较大的。实际上这些模块，就是我们说SOA的服务就是通过这些模块暴露出来的，而且每一个模块其实是有多个服务的。

　　然后我们可以看出来，我们已经有这样的模块化。其实SOA的方法论，和我们以前做的OA、OB，或者一般系统的设计规划其实也差不多，先画很多画，模块跟模块之间的关系找到了，接下来要找的跟OA、OB一样的，这些模块怎么组成的，对外接口有哪些，这些对外接口其实就是服务，这些模块有哪些模块可以对外提供服务。在SOA的应用下，我们就是做业务流程的梳理。从业务流程梳理开始，我们找出来业务模块到底有哪些要梳理出来。

　　这是一个例子，这是信用卡发卡的流程，这个流程上有很多关键要素。左侧是一些最关键的要素。第一，我每个活动到底是哪些组织和部门来承担的，这个流程可以变成什么样，然后这个流程服务水平怎么样，然后还有一些企业自己的东西，最重要的列在上面。举个例子，像这样的流程的话，贷款审核流程，某一个环节我需要两个小时做完，整个服务体系需要三天完成一个放款，跟每个操作员的成本相关，通过流程的监控，可以知道这个企业正常运营的成本是怎么样。而且通过这样的流程，可以找到有一些服务是在本系统，有一些服务实际上在外系统。实际上通过流程的梳理，就像我们最早在做OA的设计中，我们有很多USKISS，倒出来我们的序列图怎么，最后会转化成一种流程。这个例子就是交行的信用卡的例子，这个系统有58个流程，所有的系统围绕这58个流程，非常清晰。不仅是在技术上清晰，而且是在业务上清晰。刚才短信平台上朋友说SOA是围绕业务来划分，技术是一个支撑，我们并不是为了技术做SOA，而是为了业务，我们要为了让技术为了业务服务。所以我梳理58个流程之后，整个信用卡的流程非常清楚，整个业务模块就非常清楚了。然后在这个流程里面，可能还会做一些分解，因为58个流程都是大流程，我可能会分解成一些小的流程。如果是人工活动的话，可能会分成人工活动就是一个链结，或者像GSF一样是一个请求。然后很多自动活动，可以归到一个Java的方法，或者更小的一个自动流程。这些东西最后都会成为我们未来提取服务的基础。

　　回过头来看到，有了人工活动、自动活动之后，你得到的是侯选服务，我们从侯选服务里面知道哪些是服务，哪些不是服务。下面的环节，就是服务筛选。因为我们知道从流程分解到子流程，分解出来很多侯选服务。这上面流程每一个环节都可能对应一个服务，那么谁是服务，谁不是服务，我们就来回答这个问题。服务的筛选，实际上从自底向下、自底向上两个方法来做的。SOA自订向上更多，服务的来源很多，一种方式是服务已经存在了，变成一个活动，第二个是已经存在服务了，跟我现在要的不完全一样，我给服务组成一个组装，变成一个新的服务。还有一个就是新开发的一些服务。但是服务都具有天然的特性，这非常重要，什么特性呢？会有一些业务语义。很多朋友我们交流的时候都会讲，我往里面插入一个服务是服务吗？不是服务，因为你跟我讲的语言已经不是业务语言。你用业务语言来讲，可能增加一个客户是一个服务的话，跟增加一条记录是不一样的。我待会儿也会讲到，具有服务的很多特性，不是简简单单插入一条记录这么简单。还有一个排序功能是不是一个服务？答案也是一样的，不是服务，不具备业务语义，不是一个服务的东西。服务是一个无状态的，跨系统边界的。怎么讲呢？我们有一个设计原则，松偶合，并不是所有的东西都要松偶合，模块之间要松偶合，模块内部是紧耦合的关系，因为没有必要。你很紧密的模块的时候，你不需要做这样的方式。或者举个例子，我们所有的东西都要密钥吗？系统内部不需要。所以，前面是一些必要的原则，后面是一些不是非常必要，但是需要考虑的，就是你的业务重要性啊，包括你的业务重要性啊。

　　有了这些筛选原则，我们要有一张打分表，打打勾，几个专家在一起，我们基本上可以确定什么东西是服务，什么东西不是服务。你可以看到，这些东西很简单，我们以前做OO的设计是一样的，什么是一个类，什么不是一个类，什么是方法，什么不是一个方法。有了原则你可以看这些事情。

　　刚才说到服务，为什么说数据库的记录不是服务呢？因为服务的定义远比插入记录要多，你需要功能描述，用户，优先级、例外，接口定义等等。这些功能，我们做设计都会涉及到。但是服务设计还有其他的内容，比如在服务定义里面，我们许多通过数据管理的东西，能够在企业内部共享高层SChema。换句话说，在SOA的情况下，其实我们现在的环境越来越复杂了，不像我们过去一个单一的系统、一个单一的应用平台，我们面临的环境复杂了，需要的事情越来越多了，这一块也需要我们一个SOA平台，可以帮助大家把这些事情简化，作起来。

　　还有服务定义中很重要的一个就是服务的契约，这些服务，如果说前两页的东西的话，大家做的时候会做的话，在服务的契约，在我们做OO的设计提到是比较少的。我刚才说我们的一个服务和我们一条记录最大的不同就在于契约里面。我会对服务的响应时间有一个很明确的要求，我会对服务的等级水平有要求，会对服务的安全、费用等等、用户调用的频次有要求，有了这些要求，其实这些要求都是在服务的消费者和提供者之间的契约，甚至我们可以看到像SC里面，会定义一个框架，在这个框架立一个服务有多个时间，给你一个契约，给你自动的陆游，到底用什么才能实现，到底哪种实现才能实现契约要求的服务。这是跟我们过去设计比较大的不同。因为服务是相对粗力度、有语义的东西。这些东西更多的是业务的含义在里面。

　　有了服务定义里面，其实我们要做的是服务的设计的过程。我们这里才到了服务的设计。前面我们是从需求的角度看服务。服务的设计，我们要干什么呢？设计上服务的设计是要把服务分解到更小的业务构件里面去，分解到更小的业务模块里面去。你整个系统肯定是大模块套小模块，小模块套更小的模块，我们需要的服务分解到模块里面去，到底哪个模块来实现。然后这些服务是不是已有的服务能组装出来，这个服务能用什么协议来提供数据。实际上你有SOA这个平台的话，其实你用这个协议，就是说用一个新的协议提供服务是很方便的事情。但是你设计的过程中，我到底要提供什么CS，提供什么EAB，这是设计中要考虑的。还有一个问题，我们有很多的服务契约，你要把契约用到框架里，就是说在框架里你要有支持这些契约的实现。我们SOA里面，我们把很多服务分解到具体的实践联系起来、绑定起来。

　　最后，我们有了流程梳理出来了，有了服务，知道是什么样子的，把服务设计出来、构造出来，最后一个环节就是服务流程重组的过程，因为你的流程不可能是一万年不变的。SOA的灵活性从哪里来？从流程的重组中来。从流程的重组，我们可以看到里面的关键因素，就是你流程重组的时候，一定会基于一些已有的服务。为什么呢？过去很多朋友问到，我的业务部门怎么重组流程呢？你让业务部门变流程好象是不可能的。实际上我的答案是说我们不可能百分之百完全由业务人员重组这些服务。过一会儿，我的同事会给我们看业务流程平台的话怎么样去重组这些流程。你不可能重新创建一个流程，这不太容易，是基于业务流程去重组。而且什么人重组，谁能重组这个事情，你能重组什么环节这是很重要的问题。包括重组的原则，你不能把这件事情不做了，其实这不是流程的重组，是对流程的破坏。这样的话，我们会形成了这样一个系统。我们回过头看，每个过程都有关键的环节，我跟大家再介绍一下。

　　实际上我刚才讲到的这些事情，就是在SOA的环境下，或者做一个SOA版的应用的时候，你怎么去做应用的规划。我也说了，其实这个过程，实际上在我们过去做OO设计的过程，其实是一个非常好的类比。它其实就是说你如果做一个BS的结构，你就需要从OO设计开始，你如果做SOA的架构的话，你要从流程的梳理开始，进行一个基于SOA的设计。我们看到首先是流程的梳理，你能得到业务流程的定义，能得到哪些东西的服务。从服务的筛选开始，有筛选的原则、筛选的列表。从服务定义，你有数据定义、服务接口、数据依赖、服务的契约。然后在服役设计，有哪些服务构件，组合服务怎么，绑定怎么样，策略如何实现。最后我们在流程重组过程中，都会给重组留下足够的空间。这就是我们怎么去设计SOA版应用的过程。

　　后面我结合普元的产品，既然有这样的设计过程之后，我如何把这些服务、流程能构造出来，构造出来的这些SOA是什么样的，怎么样才是标准化的、业务化的、组建化的SOA，怎么才能从业务的角度、技术的角度、管理的角度看这样的应用，怎么才能符合五层的架构。

　　我们看到，我们做任何一个SOA应用，还是三块东西构成的：一个是服务要开发、构造、要运行出来，你的服务需要管理、监控。这个地方不仅仅在SOA的应用里面，不仅仅是服务，你应用的方方面面都需要构造，都需要管理和监控。然后在普元的产品里面，实际上我们在这个地方，我配合我们开发的环境去做这样一个演示。

　　首先我们看到，我们在做任何事情的时候，进行一个模块的划分。在模块划分里面，把应用系统划分成若干的模块。这是在我的开发工具里面的划分示意图。在这里面可以看到系统有哪些组成，模块跟模块的关系怎么样，甚至每个模块是什么样子的。实际上在技术实现中，普元的产品，是按OASIS的标准、SOA的标准结合起来，形成对组件、构件的定义。每一个组件包都会包含几个关键特性：第一个有对外接口提供服务，第二个特性是一个独立的、可自己部署的单位，第三个特性它符合了SC的标准。我们有了这张图的时候，我希望大家在设计的时候，能重视对模块划分的设计。其实大家都会去划分模块，是不是重视这件事情呢，可能跟大家的经验相关。但是在普元的产品里，你做SOA版的应用，你首先做的事情就是把模块划分清楚，这样就能避免你在后期的时候你的系统会变成一个网状的结构，可能有一些修改，可能就不知道影响哪些人、哪些事。在普元的产品里面，除了做这些以外，我们每一个模块还是独立的、可部署的单元，我们可以把这些模块进行部署和升级，甚至进行回馈。比如客户上线的时候，发现有问题，怎么办？只要我在管理平台退回到某一个历史版本去，就可以退回。但是历史版本里面有某些东西需要重启，但是绝大部分情况下你不需要重启就可以应用。也就是说，我们在组件包里面，我们利用SC这样一些标准，把逻辑的模型、开发的模型、部署的模型有机地统一在一起。这是我首先给大家看到的，我们构建SOA版应用的话，第一步要做的事情就是从业务角度模块的划分。

　　然后呢，第二个，我们会看到，这里面有一个数据模型的定义。我们可能用Java定义等等，这都是数据模型的定义。在普元的产品里面，我们是以SEO作为一个数据的载体。SEO规范讲了，我不会讲规范的问题。SEO的好处是统一的一种数据访问方式，它会结合一些像接管级这样的动态的特性，也结合了Java访问静态的特性。把几种特性集中在SEO里面去。我们用了类似的词组化功能来对数据进行持久化。我们还有对于语句的统一管理。包括有的数据不想在数据库里面，我们也可以在这里面起到跟视图同样的功能。  而且你会看到，在这个视图里面，并不仅仅可以视图化，有些非视图化的结构也可以定义出来。

　　下面的一个就是说SCA这一块是怎么做的。刚才我们看到，首先有一个模块划分，下面有五层的架构，每一层里面都有自己实现的标准。在服务这一块，就是我们使用SCA的标准来实现服务。同样，有服务对外接口的描述，这是服务对外接口的描述。然后这个服务是可以引用的，可以引用其他的服务，也可以跟其他服务组装起来变成新的服务。这个服务的实现有不同的实现，这是Java的实现。也可以用普元的画流程图的方式来实现。这就是这样的例子。这个地方，整个过程其实完全符合我刚才讲的SCA的标准。在这样的版本里面，我们把SCA作为服务层的标准。

　　下面是具体服务的开发。可能我们会看到，在普元的产品里面，我们最重要的特征，就是用流程的方式，用流程的方式，来表达业务的逻辑。也就是说很多业务逻辑可以用流程图的方式来表达。这里面我们解决了很关键的问题，就是这个流程可以做调试的，就是普元的产品里面解决了图形化调试的方式，而且这个是可以更新的，这是我们服务开发的时候很重要的一个理念，就是普元把流程的方式最大化。这是我们多年以来的方法，就是我们用图形化的方式把软件描述出来，让这个软件更灵活、更容易配置、更好管理。

　　还有一个很重要的就是说，我们希望做这个软件是更容易管理的方式。这个管理除了运行期的管理之外，你可以看到标准时间、标准频次、运行期的管理之外，在开发期这个管理也是非常重要的，我们开发期的管理提供了两个功能：一个功能是生成用户的文本。大家知道，我开发的过程中，我画流程图，生成了结构，把代码改完了之后，我没有办法回到设计里面去了。这个事情不仅仅是在座各位，在普元也很难。因为我们自己做这个平台的时候，你维护这个设计也几乎是不可能的事情。但是普元的平台上，我们为用户提供了很好的功能，就是用户文本的生成。所有的用户文档，跟你在开发过程中能看到的东西基本上是相似的。在用户文档里面，同样你也可以看到这个项目到底有多少组件包组成的，这些流程对应到什么流程。你改了代码，你就会得到一个跟你代码一模一样的文档。我们设计的理念，就是你的设计、你的开发、你的文档是在一张图上开发的，是一个一体化的过程。还有一个我们经常碰到这样的情况，我昨晚一个代码、一个项目的时候，项目质量是什么样的，是不是存在一些隐患？我们知道有一些Java的工具也会做到这一点，但是你为你的企业大量定义的时候，你用代码审查的工具，你会有几千个工具都是可怀疑的对象，但是你都不想改。但是我们提供了代码可查的报告，这是我给大家看的一个事例。每个构件包的质量什么样子，有一个评价，你可能画的图结点太多，我们认为可能有性能隐患，性能检查，还有工作量的计算，而且是基于一个模板来生成的，用户可以自己定义。我有一个朋友在做的时候，他作为一个项目经理，重新定义了他的格式，基本上它的项目周报都靠这样的模式来生成。就是说你在这样的开发上，你把你的项目管理、质量监控等等，都可以作为一个统一的管理流程。

　　刚才我们看到了我们整个平台，因为时间关系，我不可能给大家有特别多的演示，我会把我们一些重要的思想和理念给大家演示出来。然后在普元呢，实际上我们一直做这样的平台，我们的目标就是希望快速构建高质量、灵活、易管控的SOA的应用。实际上在我们这里，有一个一体化的特征，就是说我在开发、运行、管理、监控实际上是一体化的平台完成的，你不是用一个一个工具拼凑出来的，而且这个平台是满足业界最领先的SOA的标准，而且整个开发过程是一个图形化的开发过程，你会降低了对软件SOA版应用复杂的过程，会有很多复杂的东西会屏蔽在这样的平台之后，然后通过图形化的方式可以做服务的组装、服务的装配，然后基于这样的平台去构建SOA的应用。可能今天我跟大家分享就到这里，我的同事会跟大家分享一下怎么去构建一个流程，我的流程怎么去做重组。可能在SOA版应用，这两个东西都是密不可分、非常重要的过程。