SOA的理解、实践与体会

2007年，在一个偶然的机会投入到了移动集团级全国范围内的大型项目建设，也就是从那里开始了我的SOA职业生涯。至今还一直从事着这样事业，大大小小数十个项目，不乏接触很多系统间集成、很多业务流程梳理，从研发--实施--推广--维护--治理，通过各个环节的不同视角反复推敲SOA的实施究竟为企业信息化产生了多少价值。常思考、多总结的习惯也让自己对SOA有了更深入的一些认识。

认识SOA

         那么什么是SOA呢？SOA的技术体系标准规范是什么呢？SOA的产品家族都有什么功能？roadmap是什么？标准模型是什么？学习成本有多高？最佳实践是什么？是不是找一个技术框架发布或消费调用几个Web Service就叫做SOA了呢？带着这些疑问，查找了很多资料，也得到了很多定义，比如SOA是一门架构方法、SOA是一个组件模型、SOA是一个IT体系结构、SOA是一套设计思想，等等。定义相当的多，或许是不同的书本看问题的角度不同，就像盲人摸象得到了不同结论。而这往往造成雾里看花，貌似总是隔着一层纸，始终看不清，究竟SOA是什么！

         其实看待任何事物是什么的时候，从古至今最为直接的方式无非就三个步骤。第一，认识其外观；第二，了解其特性与功能；第三，分析其使用价值。因此在给SOA下定义之前，我们不妨通过这三个步骤了解一下SOA。

1）第一步洞悉SOA的外观与组成：SOA并不是一个看得见摸得着的软件产品，也不是一套技术体系或标准规范。很多时候，会对SOA和Web Service产生混淆或误解。从本质上来说，SOA是一种架构模式，而Web服务是利用一组标准实现的服务。Web服务是实现SOA的方式之一。那么究竟SOA的外观样貌是什么呢？下图可以对其技术体系结构有所了解：

ü  WSDL，UDDI和SOAP是SOA基础的基础部件。WSDL用来描述服务；UDDI用来注册和查找服务；而SOAP，作为传输层，用来在消费者和服务提供者之间传送消息。

ü  J2EE和.Net都可以构建一个SOA平台，但不仅仅局限以此。技术不是SOA的核心，因此只要符合SOA思想构建的技术平台都可以作为SOA的能力支撑平台。

ü  服务质量Qos是SOA中服务能力的非功能需求，其中很多标准协议用以支持服务的可靠性、安全、事务等。

因此，SOA其实并没有一个标准定义，因此从不同的目的、方向、维度去看待它，显然就会有了一开始盲人摸象给出的定义。

2）第二步掌握SOA的特性与范围：上述已对SOA涉及的技术体系有所认识，发现SOA并不局限与某项特定技术，拥有很多标准体系规范，但却不依赖与底层实现，完全跨系统、垮平台的解决方案，这决定了SOA可以适用于所有IT信息化建设的应用场景，所有的IT信息化的信息化资产也可以被SOA，SOA打破了IT的瓶颈，使得IT可以时刻与业务保持步调一致，随需而变，实现业务敏捷，流程优化，这就是SOA的核心特点。

另外，研究SOA实施范围前，先分析比较分析面向过程和面向对象两种设计思想。前者关注的是以过程执行产生的结果为导向；后者关注的是对象结构和行为，通过对象间协作构建业务应用，以对象的本质、组织、运行的构建方式为导向；而SOA面向服务的架构，并不会推翻面向过程或面向对象的思想，相反正是他们的延伸。它以服务为导向，推崇将能力转化为服务，并发布服务；或者消费服务，将服务转化为能力，这是一个双向的、灵活的IT建设思路。因此，SOA实施范围并没有局限性，在业务系统内可以实施SOA，如组件化开发，以服务能力为单元开发组件，解决组件间的耦合，强化组件间相互自由通信、拼装组合、能力转化、拔插升级；在系统外也可以实施SOA，建设ESB平台，集成与整合各系统间的服务能力，解决系统间的交互通信，简化并提升系统间数据交换、信息共享、流程衔接、业务敏捷的能力。

3）第三步分析SOA的价值与收益：SOA倡导以面向服务的方式应对IT系统建设，这就好比活字印刷术。IT信息技术抽象的一个个服务，就好比一个个汉字，本身已经具备一定能力；而这些服务就如同汉字一样还可以通过组合拼装的方式构建成短语，形成另一个上层的流程能力；还以短语与字的组合方式构建成文章，形成顶层的应用能力。这样，可以实现快速的业务敏捷，IT随需而动，打破传统构建系统的维护难、变更难、升级扩容难，需求的变化映射产生IT的变化不再是从前那样牵一发动全身的窘境，而是通过服务组装、拆卸、再组合的过程即可快速适应业务需求的变化，实时把握用户的需求，市场的选择。而且随着SOA的大行其道，服务资产库中服务的注册目录不断增加，但是重复本身的重复开发却在不断的减少，更多的情形是组合复用的情况，在投资成本降低的同时，业务支撑的能力却在不断增强。而一切都得益于SOA，因为SOA的思想将IT的能力抽象为服务，并且可以复用，或是使遗留资产焕发生机重新利旧，减少投资，避免重复生产，使得IT与业务对齐，快速适应业务敏捷的变化与IT资产的映射。

实践SOA

2007年，我们投入了SOA项目的实践。其初衷是为了实现资源共享、系统整合、资产复用，打破传统“竖井式”的模式构建孤立的业务系统，构建企业架构的动态、柔性的整合与集成。但是，EAI这种成熟的商业产品的功能也是以此为目标，它设计核心也是将基于各种不同平台、用不同方案建立的异构应用集成的一种方法和技术。EAI通过建立底层结构，来联系横贯整个企业的异构系统、应用、数据源等，完成在企业内部的ERP、CRM、SCM、数据库、数据仓库，以及其他重要的内部系统之间无缝地共享和交换数据的需要。然后我们为什么没有使用EAI这种成熟的产品，而是选择了SOA呢？原因在于EAI是通过应用服务器中间件作为粘合剂来连接企业内外各种业务相关的异构系统、应用以及数据源，从而满足企业内部应用系统之间信息共享的需要。其核心本质是建立以消息通信为基础的管道，打通业务系统间的交互，构建一个个通信桥梁。因此，EAI只完成了系统间通信，却没有解决灵活的应用整合需求，实际的业务还是需要由业务系统内部的完成，当需求发生变迁时，核心业务逻辑处理还是需要业务系统发生重大变革，并且还需要考虑变革后对桥梁那头的其他业务系统的影响。而SOA相对于EAI而言，服务的颗粒度显然要比以消息通信为基础的管道要细，业务系统的核心业务逻辑抽象成为一个个服务发布注册到SOA平台，业务系统或业务系统间的业务变革可以由服务级粒度变更或者重新组装编排，从点到线、线到面、面成体的全方位集成和整合，快速适应业务需求变化，而这是EAI望尘莫及的。

经过很多年的SOA实践，我们发现已经为客户积累了很多业务服务和技术服务，当有新系统建设或遗留系统改造扩容时，我们会发现很多技术服务（如日志服务、缓存服务、搜索引擎服务）、很多业务服务（基础数据服务、校验检查服务、认证服务、业务规则服务）已经可以存在，并且完全可以利旧复用，无需再次重复建设，新的需求只需要关注新的业务实现，而不再像从前那样一切重新开始。因此，在我们实施SOA以后，往往会在业务建模完成后，架构设计开始前，增加一个服务识别与梳理的环节。自定向下的过程中，进行流程建模、流程分解、接口识别；自底向上的过程中，进行服务目录发现、遗留资产利旧、现有流程重组。通过这一环节的分析梳理工作的执行，为新增需求的建设规划拟定实施方案和开发方式，最大程度下减少重复开发、降低成本，节约投资，以短、平、快的方式满足业务需求。

理解SOA

通过SOA实践的逐步深入，SOA的价值也日渐明显。信息系统的建设，需求漫天的变更，不再是大刀阔斧的重来，而是随着服务资产投资，变得日趋灵活和敏捷。同时，随着SOA能力成熟度的不断演进，SOA完成了部门内、部门间、甚至企业间的业务整合，这时候会发现信息系统的建设不再局限于某一特定环境，所有信息、资源、技术、设施、资产都是公开共享的，在这些基础条件下构建一个顶层的端到端大流程价值链已是水到渠成，通过SOA的实施打通了企业的所有信息化建设，信息可控、流程可控、业务可控，为企业后续的商业智能分析、战略决策提供了坚实的基础。