实践经验分享：SOA的关键是服务构造

　　SOA之于企业，无论有多少种产品和解决方案，具体到每一个企业来说，最根本的需求是对企业内部的业务和流程的重构。SOA为企业所能带来的价值，就是基于其内部统一的数据交互接口、将业务分解为独立的模块成为服务、提供统一的服务接口，这样的思想所带来的是能够让企业的IT系统根据业务需求的变化而迅速改进。服务构造的过程，也就是对企业业务流程的分解、独立和流程改进的过程。而这个过程，其实未必和技术有多大的关系，而更多的是与技术无关的业务方面的过程，各种技术和方案其实都可以实现类似的需求。普元在最近的SOA大会中提出“SOA的关键是服务构造”也就是从实践中总结出这样的经验。

　　普元副总裁刘尔洪对SOA做了一个形象的比喻，SOA想解决的问题是软件太大了不灵活，就要把它拆小。小的东西就像积木一样，拼成什么都行，这个拆开的小积木就是服务。问题是服务难做吗?有人说做服务很简单，随便把现有的软件模块打个包，封装一下就是服务。对于这样的观点，刘尔洪认为，关键在于服务用来干什么?可复用的服务才有价值，现在的问题是服务的质量不高，每天做的软件没有考虑到每一块小的软件都建立业务模型、适应不同的环节。

　　另外一个问题就是，服务需要很灵活，只有足够灵活才能够适应变化。灵活对应到实现上就是服务的粒度，这一点对于SOA的实现是一个难以确定的问题。如前文所述的那种通过将软件模块打包封装出来的服务，粒度是非常大的，这样做的问题是复用性很差。刘尔洪说，普元的思想是一直分解到最小的粒度，由一堆最小的构件组合成服务。这样一来服务拼大也行，拼小也行，用这样的方式做出来的服务是很灵活的。对于基于SOA建立大型企业应用，把企业的应用都变成最小粒度的服务组合起来的应用，问题是小粒度的通用性的服务很难做出来，需求经常会发生变化，具体的应用场景也会经常发生变化，如何能够解决这个问题?刘尔洪的答案很简单：就用更小的颗粒解决出来，这是普元一直在提倡的构件，构件拼成服务，服务拼成流程，流程构造出应用，很多应用拼成一个企业。

　　以细粒度的构件去实现独立的服务，可以提高业务流程的灵活性，但与带来的灵活性同时也会带来复杂性，面向对象的设计就是一个很好的例子。越是讲究接口、分解和设计模式，其整体结构就越复杂。构件或服务的粒度越小，其数量就越多，系统内部必然会产生出更多跨服务之间的交互，有了交互就带来依赖关系，这很容易成为一种网状结构。这就产生了一个问题，作为软件开发中基本单位的服务之间存在交叉访问或依赖关系如何解决，如果需求发生了变化需要改服务的实现，而修改后服务在跟原来设计的不同，可能会衍生涉及到更多的服务的修改。

　　一个客户系统的业务分层，有各种分层的方法，但通过平台实现完成之后，每一层互相之间的依赖和引用是受到平台管控的。，任何一个服务发生了变化，通过平台马上可以知道它依赖了哪些服务，而又有哪些服务依赖了它。而服务修改导致的扩散，这种场景也有可能会发生，但在普元实施的几十个项目里，基本没有这样的情况。基础平台中原子级的构件是稳定的，而客户做的是基于这种稳定的构件，而之上的业务基础模块、组织机构、权限管理等在客户那系统里非常稳定，再往上的业务层面，仍然是基于基础平台构建，因此也是相对稳定的。虽然整个系统的稳定需要时间，但不是无法做到的。

　　在提到典型的客户的时候，刘尔洪介绍到，在安徽电信的OSS建设中就使用了普元的产品，而普元的优势也在于服务的构造和业务化的流程。安徽电信的业务系统原来有四千多个流程，而在改造完成之后，在用的只有900个流程，有很多流程都是优化以后废弃掉了。现在很多流程的业务响应时间从原来的两三个月，降低到现在只需要一周。

　　在谈及整个产业的时候，刘飞讲到，传统方式下比较大的厂商都建团队或者组织自己的力量或者组织外部合作伙伴为用户开发解决方案，但是这些解决方案由厂商来提供成本非常高，而且缺乏定制性。而基础平台就好像预制板，在预制板成为行业的必经环节之后，市场中就出现了真空点，此时方案供应商就能够真正给客户带来价值。