SOA从面向构件开始

5月29日，SOA国际标准全球路演中国站正式揭幕。以下是来自普元公司的CTO黄柳青先生关于SOA从面向构件开始的主题演讲：

各位朋友、各位专家下午好，今天上午刘总他们都再一个远见的层次看到软件未来都会像SOA、SCA/SDO方面去发展，今天下午大家比较关心的是这样一个软件怎样能够逐步来实现。一方面我们看到SCA/SDO的标准已经在1.0发布，也正在不断地成长、成熟。今天下午还会有IBM、Oracle的 专家详细介绍SCA/SDO时间的事情。另一方面我跟刘总一起在2001年创办普元公司，普元公司从01年到现在差不多六年的实践就是专注在服务构件领 域，虽然标准方面来讲现在正在6.0、7.0方面，越来越标准了。但是从理论方法和实践方面已经积累了大量的经验，怎样通过服务构件来建设一个比较灵活、 多变的应用系统。在这里我也想跟大家分享一下，六年来我们在面向构件服务构件领域里所取得的一些体会跟成果。

实际上为什么要用SOA或者是SCA这样一个技术？它的本质并不是说技术方面的要求，而是业务方面迫切的需要。比如金融行业今年有大量的金融公司上 市，上市之后大家感到的压力还更大，为什么呢？一方面我们上市了，竞争对手也上市了，同时国外的竞争对手也大批地进入中国。在这样一个情况下，我们要建的 系统越来越多，给我们建设系统的时间却越来越短，按照Gartner的分析报告来讲，我们看到作为一个软件的生产部门，或者是作为整个银行、电信企业的 IT支持部门来讲，责任越来越重大。

不是说我们有什么技术，而是从业务发展上就必须要求我们的IT框架能够快速地做出调整，而这个调整的时间是越来越短了。从现在可能有二三十天的时 间，两年前是两个月能够做出一个系统就非常好了。这个压力还会持续，按照Gartner的报告来讲，这个压力并不是到现在为止，还会缩短到七天、三天，甚 至是更短的时间要实现业务的转换。正是在这样一个挑战背景下，我们看到越来越多SOA这样的技术对IT建设带来的价值。

为什么我们看到SOA这个技术没有马上解决所有的问题呢？实际上SOA这样一个非常重大的IT转化思想跟理念，要真正落实到我们市场的工作中，特别 是把以前从国际上以应用集成为核心的环境，改造成比应用开发更重要，或者是应用开发跟新的应用集成并重的局面，现在SOA技术跟我们的要求还有很大的差 距。

看到IBM公司早期或者是现在对SOA的宣讲，他们有一个电视，在SOA整个发布理念里，现在制造厂里面已经有非常好的制造设计部门、非常好的营销 部门的信息系统，还有非常好的组织生产管理等等系统，但是由于缺乏这些系统之间的沟通，使得这个企业没有办法灵活应变。按照他的讲法SOA就解决了部门间 的问题。

但是这样一个假设的前提是，每个大型子系统已经存在了，我们可以用SOA进行整合。第二点来讲，SOA子系统的数量是有限的，一个公司里面肯定有 10到30个部门，用10到30个系统足够能够形成快速的变化。实际上它的颗粒度对于这样一个快速变化的电信银行、制造、电子政务部门来讲，颗粒度太大 了。必须对一个大的、部门级的服务有更小颗粒度的技术，来作为服务支撑的体系架构。

现在中国管理类子系统没有成熟，不可能做一个固定的人事管理系统在公司里使用，因为人事管理还在不断地调整、变化。生产也在变化，营销管理更是我们 的薄弱环节，我们正在学习什么叫营销、什么叫管理，所以这样的系统不可能把它作为一个完整的服务给人家提供，还需要更小的颗粒对它进行整合。

从某个意义上来讲，SOA是什么东西？SOA并不是一个单纯的技术，SOA是一个业务，同时更是一种思想跟理念。我们需要把SOA这个理念从大颗 粒、从应用集成贯彻到子系统的开发跟应用本身的快速建设跟成长。从SOA这个软件本身来讲，更是一种架构。我们在看整个电信、银行、大型企业时，首先关心 的是怎样在架构一层建立一套思路，使得我们的应用可以达到目标。

举几个例子，现在传统基于面向对象的开发理念，甚至很多人对SOA的现代理念都存在一个很根本的、致命的缺陷，这个缺陷使得我们面向构件的方法、面 向对象的方法是不可能把一个好的系统建立起来的，这就是数据的变化。因为所有面向对象的理念里面都认为数据是我们的核心，数据结构的稳定性是我们开发的一 个基本原理。如果数据结构发生变化，软件的每个部门都会受到牵连。比如说银行里如果是一个中文系统，假设一个人只有三个字的名字，如果现在要到国外市场去 交互，或者说国际人士可以在工商银行开户的话，一个人的名字可能是20、30个字符，这样就会彻底打破软件架构。

我们要真正地随需应变时必须要在数据上有一个很好的变化。我们的服务还需要是完备的服务，如果只是说现在已经建了20个系统，把现在的人事管理抽取 出来，把现在的制造管理抽取出来，会发现原来十个系统里有十个产品管理，但这十个产品管理都不一样，局限性都各自存在着，我们并不是把现有的一个服务提取 出来就能够变成一个很完备的服务了。很多情况下这是我们面向构件实践里最大的一个困惑。并不是把原来的代码拿过来就是一个很好的界面。

还有整体性的考虑，如果我们要走到SOA的话，可以在一个局部的SOA做一些尝试。逐步用构件来建设系统，但是必须要有一个全局的眼光才能真正体会 到SOA跟SCA的好处。还有灵活性以及标准体系，这更是非常重要的。因为没有标准，就不会有重复的构件。没有标准，企业里面每个部门之间跨的企业就不能 沟通。

实际上我们看到SOA是这样一个非常好的理念，但是如果SOA要真正落地的话，在软件架构的设计方面，以及软件IT规划方面还需要超越SOA的标 准，有一个更好的技术帮我们建立一个架构。这个架构不但是在应用之间可以集成，同时可以快速搭建灵活应用的子系统。这个技术实际上就是普元公司在六年来一 直努力的方向。这个方向就是服务构件。

因为一个系统里不会有20个、30个非常固定的子系统，但是可能有两百到三百个非常稳定的服务构件，通过服务构件就能够快速地搭出20到30个灵 活、多变的子系统，再整合成整个企业的应用。正是因为有SCA、SDO这样的标准，我们就能够把SOA更好地实现，从我们的规划、应用子系统的开发以及到 应用的集成，成为一体化构件的技术。

有了构件就可以通过构件的组专来快速调整应用。我们可以看到构件技术是SOA技术真真、切切实实让大家体会到服务、体会到灵活多变业务最核心的技 术。所以等一下会看到普元公司经过六年的实践，向国际上一流的厂商都会把构件技术作为他们未来SOA产品最核心的一个元素，使得SOA方案有一个更好的解 决体系。

这就是我们认为的SOA的实践之路，包括了服务、构件，有机整合到服务构件跟SOA的统一。在未来的应用系统里，统一的服务系统、统一的流程管理、软件的治理都是回到SCA、SDO这样一个技术进行全面的整合。

有了这样一个构件的技术，就会发现IT规划以及IT实践、IT发展就会有新的元素。SOA可以说是从面向构件开始的，有了面向构件SOA、SCA这 样的技术，IT规划逐步会从软件的应用一级转化到体系级的规划，这也是构件技术、服务技术给大家带来的机会跟挑战。在现有的或者是以前的IT规划中往往都 是以应用系统为核心的，比如今年要建10个应用系统，明年要建20个应用系统。

对于未来以SOA跟SCA为核心的应用系统的建设过程中，我们看到的并不是表面表现出来的应用，而是一个企业里面构件的体系。最重要的也不是我们构 件技术本身，而是从业务方面怎么来分解各项业务，包装成各种各样的构件。因为有了构件，所有的企业应用是能够快路生成、快速变化的。你需要20个应用、 50个应有都可以在同样的一组构件体系里快速生成。

所以面向构件也是未来IT规划的核心。现在在实现IT的管理里也是这个问题，现在有很多项目请了很多集成公司来完成，完成好的东西就是我们需要维护 的应用，以构件为核心，我们可能会请一些集成商帮我们开发一些构件，但是我们需要哪些业务构件？哪些业务构件用什么样的接口这是需要IT部门统一规划的事 情。在统一规划体系上，就逐步地发展了各种各样的流程，审批流程、安全流程等等。所以面向服务让构件更加开放，因为用了服务的技术使得我们的构件可以灵活 多变。

在面向构件SCA的体系里，可以把现在的很多矛盾在这个系统里进行统一，这个矛盾就是现在有一个新的IT系统，我们需要把它完全打掉重来，还是包容 进来，进行重新的包装使用呢？怎样能够把异构的系统整合在一起呢？这都是像SCA的技术解决的问题。因为在我们的系统里可能会发现一些核心的业务系统，像 银行的交易系统、电信的计费系统等等，他们相对而言是比较固定的，原有的系统满足了我们的要求。在这样的系统里就可以把他们包容进来。因为现在新的SCA 的标准跟以前的标准很不一样的是对于跨语言服务的支持。

通过服务的包装，下面具体的实现是JAVA还是C++，还是其他的技术都可以包容进来。但是对于一些营销管理、服务管理等等，正在面临比较重要的决 策跟改变的环境，现有系统比较大程度上是满足不了我们的要求的。在这样的系统里就会以推倒重来为核心。因为如果有真正立足比较好的构件的积累，像US平台 里已经积累了上千个各种各样的构件，很多情况下使用这些基础的构件库快速地开发一个应用软件，比销售服务管理，比我们去维护一个老的系统更省钱、更省时 间，而且效率更高。所以构件包容了每个层次的系统。

面向构件是对开发和整合模式的统一，也是企业知识的规划和重用，同时是应用系统跟业务系统之间完全地同步。所以我们从事了六年多的面向构件的技术， 真正通过SCA、SDO的标准，正在走到一个非常核心的位置。在这个核心位置上就会为未来企业的规划、未来企业的实践、开发跟变化打造非常好的基础。

在我们的架构中，在未来应用软件的过程里，会看到我们的应用软件、我们企业的IT其实是一组一组SOA、SCA的构件包，都是一些服务构件，可能会 是组织机构的构件，会有一组页面控制的管理构件，还会有工作流程的构件，有营销管理的构件，在我们面前都是一组构件，这个构件也许在一个中小型银行里会是 500个构件，在复杂的大的银行也许有一千两千个构件。有了这些基础构件之后就可以快速响应要求。而且服务构件本身还需要具备独特的灵活性，包括对数据变 化的灵活性、对于流程变化的灵活性，通过这些灵活性使得应用软件得到的重用。

通过逆向构件的方法，也是使得IT部门的生产管理得到更高的控制。因为以前通过单纯的手工编码来讲，软件项目的控制是非常困难的。因为在一个软件项 目里如果有几十万行代码很难在某个具体的点来控制今天写了多少行代码作为一个核心的基本控制。构件就让我们把软件开发的过程得到全面的统一。因为不管是在 需求、分析、设计、开发一直到测试发布、维护，大家的沟通语言就是服务构件。不像现在传统的软件开发利，这是影响软件开发效率非常大的一个因素。

在需求时使用的语言、分析所使用的工具、开发所使用的环境、测试发布维护每个阶段大家用的语言都完全不一样，我们很难保证我们开发出来的软件是不是 跟设计一致？我的设计是不是完全包容了我的需求？我的测试是不是包含了我的每一行代码？这些是没有办法回答的，因为每个岗位上人的思想方法、思想和工具都 是不一样的，只有通过服务构件这样的技术，才得到的统一。

因为需求整理就可以通过需求分析逐步形成构件的轮廓。在分析时可以对构件的接口做一个详细的规划，开发是可以对构件的接口进行实现。测试时就可以有 机地分解为对构件接口的测试以及对构件组装的测试。特别是当一个软件上线运行时，并不是看到一台机器上有很多进程在那里运转，而是看到很多构件在里面运 行。每个服务构件都代表了它自己的一个具体意义。比如面向构件系统的开发的话，对软件的监控跟管理就可以面向业务环境来进行。

正是在这样一个过程里，每个进程的分工更加明细，每个人做的事情更加清晰，而且大家的工作中心都是服务构件这样一个统一的概念。这样在软件生产的环 节里就会发现，我们公司可能有一个30人的团队，大家的工作语言是一样的。都是构件，怎样把构件设计出来、开发出来、测试出来、组装出来，怎样把构件在运 行时进行监控和管理。正是这样一个统一模式为软件未来打造了一个非常统一的环境。

比如说在需求分析时，现在一般会跟用户的交流进行记录，可能会用Word或者是Excel进行记录，以前很难说需求跟分析是一致的，通过构件的分 解，我们的需求可以很快地变成构件。对于业务建模也能够快速进行。特别是像US这样一个环境，在这个环境里会有一整套、现成的、小的服务构件，这些小颗粒 的服务构件通过建模的方法可以表达成更高层次的服务构件。这个更高层次的服务构件就可以快速组装成各种各样的应用软件。包括软件的测试、集成等等，我们都 会做很多的内容。

在以前的情况下，我们往往有很多应用项目在开发，第一年可能有20个项目，每个项目完成之后，第二年又来30个项目。随着项目的开发，我们的工作越 来越难。因为新开发的30个系统跟以前的20个系统里有很多重合的部门。但是每个人的理解又不完全一样，所以往往需要对旧的系统和新系统进行改造、改变， 这里面会涉及到很多手工工作。

对于面向构件开发的原理，可能在第一年20个流程应用开发过程中积累出20个构件、30个构件，在第二年开发时就不需要重复开发以前的构建了。通过 积累就可以在未来心目中不断得到好处。也就是说面向构件这样一个技术，实际上会随着应用的不断深入、不断推广，它的使用价值体现会越来越高。

通过面向构件的技术，从结构上就降低了软件工程的复杂度，因为一个应用软件不再是有几十万行、几百万行代码构成，而是由几百个、几千个元素组装而成 的。也就是把应用系统的复杂度下降了一个数量级。从软件工艺到软件生产就打好了一个基础。因为如果每一行代码都靠手工来做的话，每个软件工程师就像艺术家 一样，很难保证他造的两个艺术品是一样的。但是用了构件技术就可以通过构件的包装使得软件生产达到一致性。

在未来的软件，通过面向构件的技术，不是通过代码编写而成，而是通过现有的构件像SCA、SDO等等，通过构造、组装而成的。企业里面的应有也不是 单一的架构，实际上是由很多子系统，很多构件组成而成的，并不是说这个系统里有多少应用在跑。构件子系统有良好的、稳定的使用接口，特别是SCA、SDO 等等能够变成标准化的东西，企业不同部门开发的软件，甚至是一个公司在不同地方开发的软件统统可以标准、进行交付。构件总线，像以构件为核心的技术就会成 为信息服务的中心。

普元六年的实践过程中在服务基础上打造了面向构件的基础，通过构件的组装，第一步完成了快速应用软件子系统的开发，同时再通过应用软件子系统、通过业务流程快速组装成各层的应用。也就是说面向构件这样的技术，是SOA真正落地最重要的元素。谢谢！