1.1 面向服务架构的必然性

面向服务这一概念源于1996年Gartner所涉及的SOA，这里也包括SO（I Service-oriented Integration）。顾名思义，SOA是面向服务架构，而SOI是面向服务的整合。一般而言，在现有企业级应用中，SOA与SOI同时共存。面向服务的关键是建立一套标准的架构体系，而这一体系不受制于某一特定的技术或业务模式。当信息技术的交互变得日益普及化、标准化及产品化时，面向服务的架构风格显得尤为重要。简言之，SOA是一种架构风格或架构模式。那么，企业应用为何要如此强调SOA架构呢？

1.1.1 阿凡提的兔子汤

在阿凡提的故事中，他和猎人朋友一起打了只兔子，美餐一顿后还有所剩。一天以后，有人来说，他是朋友的朋友，阿凡提于是请他喝了剩下的兔子汤。过了几天，又有人跑来，说他是朋友的朋友的朋友，于是阿凡提就请那人喝了一碗水，说这是“兔子的汤的汤的汤”。这个故事说明，凡事是有层级化的，不可能充分扁平化，就如部队里连长也许能关心全体战士，同他们交流感情，而营长就很难与全营战士沟通了。同样道理，当一个企业的系统发展到一定层面后，更新管理终将遭遇力所不能及的地步，从而思考如何进行架构转型。

从信息技术的发展历史来看，我们从四十多年前CICS（Customer Information Control System）系统包罗展现（Map操作）、逻辑（Program操作）及数据（VSAM/文件/缓存）的一体机，到如今以业务为导向的企业应用。我们从单层系统到二层、多层系统，到分布式系统，再到系统整合。我们从小到大，从基本到高层，从简单到复杂，从单一到聚合。我们从面向程序过程到面向对象，到基于组件、基于业务应用（ERP），再到面向服务化及框架化（如图1-1所示）。这是一个必然的发展趋势，其原因如下。

（1）应用技术上，编程模式、语言、技术及工具不断变化更新及趋于多样化。

（2）业务上，各个行业、部门、组织间，直接或间接地日益关联协作。

（3）用户体验上，简便的操作、随需而生的应用及可以定制化的界面不再局限于单一的应用。

（4）信息获取方式上，全球化、网络化的格局成为主流，等等。

SOA的应运而生正是满足了这种趋势：换位思考扁平化的孤岛系统，将日趋复杂的IT应用，经由组件化、服务化/框架化的整合，变得相对简单易用。

目前，SOA还处于发展阶段（根据Gartner Hype Cycle 2012, SOA已经处于实用阶段，在技术上处于浪潮平原期），企业对SOA必须具有前瞻性。在企业IT的初级阶段，应用SOA或不应用SOA往往感觉不出太大效益。只有在企业IT规模发展到相当程度时，竖井式应用的弊端造成应用拓展维护困难，SOA的价值才会凸显出来。反过来说，SOA能够帮助企业未雨绸缪未来的业务整合，同时顺应IT应用网络化、商业化的趋势。许多大型企业或网站的IT架构发展进程充分说明了这一点。所以说，层级化的SOA现在是将来也将是应对这一变化趋势的一贴良方。

1.1.2 秦始皇的度量“衡”

提到SOA的通用性及标准性，我们常会引用秦始皇统一度量衡的故事。在企业IT应用层面，我们自然会想到应用组件的通用性。在相对独立的应用中，一般不需要设计使用SOA服务。当某一应用或组件需要对外使用或重复使用时，或需要屏蔽特定的实现技术时，SOA服务才具有意义。通用性是采用SOA的必要原因之一，而SOA的重用性区别于组件的通用性在于其广泛接受的统一接口标准。这也是秦始皇统一度量衡的意义所在。

SOA的通用性还体现在其架构设计。SOA的架构重在网络化、客户化及整合化。其考量的重点不在于某一个应用，而是应用的对外使用或是应用间的关联。对于相当规模的某种行业或某种交互形式，往往可以设计出具有相当通用性的SOA架构。虽然基于组件的架构同样可以具有通用性，但它局限于某一特定的技术，而且范围也较小。相对而言，SOA架构层次较高，其通用性包含服务化与标准化，通过业务组件分解，较易与业务对齐。

另外，SOA的通用性体现在不局限于某一厂商产品框架技术。SOA以独立于技术的架构为主导，在此基础上，可以利用具体厂商的产品技术或应用框架。例如，微软（Microsoft）的BizTalk、WCF或Dynamics；甲骨文（Oracle）的Fusion中间件或SOA套件；IBM的中间件系列；普元的EOS等。当然，每个厂商的SOA侧重点不同。例如，微软主要侧重于Web服务集成或开发端的SOA，并在特定的平台上运行这些服务；IBM侧重于中间件的应用整合；SAP则重于应用管理集成套件等。

本书主要从架构的角度考虑SOA，这与设计或产品技术是不同的思维方式。SOA的真正意义不在于技术，而是架构优先的SOA构建部署方法。通用性的架构设计才是企业级应用整合的关键所在，同时企业应用产品化的通用设计也便于SOA的推广与价值实现。

1.1.3 达尔文的“适变”理论

达尔文曾说过：“能够生存下来的不是最强的，也不是最聪明的，而是最能适应变化的”。同样，对于企业应用系统，其生命力在于其适应变化的能力。也就是说，不依赖于代码改变而由整体架构形成的系统适变性（Adaptability）或灵活性（Flexibility）。适变性是SOA的首要目标，其很大程度取决于其架构设计，关键表现在业务服务模块的设计、服务的依赖关系，服务粒度及服务接口的定义、业务及流程服务的定制化等在本书所强调的架构设计要素。相对于面向组件的灵活性要求，SOA的灵活性更强调企业级业务的灵活性，例如，跨域系统间接口调用的灵活性，或易于最终用户配置的灵活性，而这种灵活性是通过应用的服务层来实现的，而非下层的应用组件。但是，服务层也取决于组件层。一个完善的SOA架构是服务层与组件层灵活性的有机结合。

同时，SOA以业务为导向，其成功与否，很大程度上取决于最终用户对应用或系统的使用便捷程度，也就是易用性。易用性表现在容易上手、个性化配置、触摸或拖拉式操作、信息接口无缝转换等。当然，易用性与灵活性具有相当程度的关联。SOA的易用性不仅取决于可视化服务的界面设计，而且取决于服务视图及接口的关系配置。SOA易用性的受益者包括应用架构设计人员。

1.1.4 高尔的成功系统定律

高尔定律（Gall' s Law）表明：任何一个成功的复杂系统永远是源于一个成功的简单系统（A complex system that works is invariably found to have evolved from a simple system that worked）。

同样，对于企业应用系统的集成，永远是由简单的系统衍生而来。没有基本的应用系统模块，也就无所谓系统集成。由于SOA并非是一种技术或技术框架，并非适用于所有的信息系统应用。对于某一层面的IT架构或场景，例如，如果系统不是以整合为目的，而强调性能、安全、业务逻辑应用化等，SOA可能会是一个错误的选择。值得注意的是，SOA是基于传统应用之上的应用整合架构，其成功意义在于服务化、虚拟化的架构设计，而非SOA技术本身。所以，只有企业的IT发展到一定层面，SOA才有意义。例如下面所示。

● 当企业已经进入ERP阶段，并使用服务化的方式来整合梳理系统及业务，粗粒度的服务能带来规范和效益。

● 当企业将其应用或系统作为服务对外暴露时，实现网络化或产品化的战略。

● 当企业具有一定规模的复杂系统，并且处于异构环境，或者在与异构环境交互时，必须使用SOA标准。

● 当SOA的服务层给系统性能带来负面影响时，企业的财力或技术资源能够补偿这种一定程度的性能耗损。

● 当企业IT负责人员具有一定的SOA的思维方式及掌握基本的SOA技能时。

● 当企业领导足够重视应用整合，优先规范IT系统应用的灵活性及重用性，并付诸于长期规划时。

参见 "When Not to Use an SOA", Jason Bloomberg

总之，企业在具有一定的应用系统规模前，或在考虑或采用ERP系统前，虽然可以使用服务模块的方式或暴露使用服务，但须依循高尔定律，逐渐过渡到SOA，不能一蹴而就。在设计或整合复杂系统时，必然要大量地使用现有的、逐渐积累起来的系统组件及资产，并且，所构建的系统越复杂，限制条件越多，就越有SOA的必要。而只有当SOA的标准、分布环境进入成熟阶段，SOA价值才能充分体现。无论如何，SOA企业应用整合的架构方法是企业最终走向成熟的不二之选。