SOA（service-oriented architecture面向服务的体系结构）是这近年来IT届炙手可热的关键词，也是玄而又玄的名词（好像谁的嘴边不挂上SOA就不IT了）。

　　对SOA，Gartner的定义：客户端/服务器的软件设计方法，一项应用由软件服务和软件服务使用者组成……SOA与大多数通用的客户端/服务器模型的不同之处，在于它着重强调软件组件的松散耦合，并使用独立的标准接口。

　　Service-architecture.com的定义：本质上是服务的集合。服务间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数。

　　Looselycoupled.com的定义：按需连接资源的系统。在SOA中，资源被作为可通过标准方式访问的独立服务，提供给网络中的其他成员。与传统的系统结构相比，SOA规定了资源间更为灵活的松散耦合关系。

　　IBM的定义：向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

　　维基百科的定义：面向服务的体系结构（Service-oriented architecture）是构造分布式系统的应用程序的方法。它将应用程序功能作为服务发送给最终用户或者其他服务。

　　百度百科的定义：面向服务的体系结构（Service-Oriented Architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。

　　是否你已经看晕了，是不是很高深、很晦涩、很……

　　此外，在详细的解释中你还会发现更多的数据总线、元数据、粒度、松耦合等也同样很高深、很晦涩、很……的词语来进行解释。

　　因此，笔者在很长一段时间内只有保持缄默，同时多听、多看、多问。

　　近日笔者在与某工程界朋友聊天时，无意间又谈到了SOA，他的观点让我茅塞顿开，所谓SOA无疑是软件行业的又一成功概念炒作，其实质无外乎是软件行业标准化进程中的自救行为，是软件行业自己“补课”而已，而并非什么划时代的东西（不可否认的是的确有了不小的进步）。

　　目前看来，通过SOA是不可能实现供应商们所吹嘘的，并且专家们所意念的：只要软件SOA了一方面可以实现系统的柔性；另一方面可实现异构系统之间的无缝集成！

　　为说清楚这个论点，先将话题转到工程界。

　　工程界经过多年的积累，在标准化方面应该已经形成了一个相对完整的体系。一张图纸要从设计到正真能下到车间进行加工，需经过设计、校对、审核、标准化、批准等审批环节，不同的企业的流程不太一样，但无论怎么变，流程怎么调整，有一个环节是必不可少的，那就是标准化！

　　标准化的工作核心有两方面：一方面是审核在设计过程中是否按照规范的要求进行设计，目的是用标准化的语言让所有工程师看懂；另一方面是在设计过程中是否尽量相关零部件的重用性，即尽量多的选用标准件，避免重复加工，节省成本，便于后续的维修维护，实现以最少内部多样化来实现最大的外部多样化（这也是大批量定制的核心思想）。

　　同时企业在标准件的形成过程中也是非常严谨的，有着非常规范的程序，并且以企业标准的形式下发；在企标的基础上可能会成为行业标准；在行业标准的基础上形成国家标准。当然国家标注的制订会遵循国际标注。

　　反观软件的开发过程，虽然也有软件工程、也有CMM体系，但重心在与在流程方面进行规范，通过需求确认、概要设计、详细设计、编码、单元测试、集成测试、系统测试、维护等环节来控制软件的质量。

　　但标准化环节呢？没有！

　　于是千人千面、单人多面（受个人心情、工作状态的影响非常大）！这样如何能保证最终所加付的产品的质量？如何能保证2.0版就一定比1.0版强呢？于是就无休止的补丁、升级来弥补设计过程的缺陷。一个旧的问题解决了，N个新的问题冒出来了；甚至就的问题还未解决、新的问题接踵而来；更为关键的是，根本无法检查问题究竟是如何产生的。

　　如果这种事情发生在工程界，很简单，召回、赔偿、破产！但在IT界却完全变了游戏规则，美名其曰：为客户提供优质的服务，并堂而皇之的笑纳了价值不菲的维护服务费。

　　笔者在大放一通厥词之后，言归到SOA上。

　　SOA中的“服务”无外乎是我们理解中的标准件；服务间彼此“通信”也就是我们所理解的零部件之间的配合关系；其中内部的逻辑关系也就是我们常说的控制。

　　工业产品是通过不同的配合关系实现各零部件之间的装配，通过液压、电子等装置实现其控制；同样在软件行业中通过“通信”实现“服务”之间的联系，通过逻辑关系实现对业务的控制。

　　因此，即便是目前工业产品的标准化程度已经非常高的前提下，但也只能在有限的条件下实现配置，同样软件系统也不可能天马行空实现柔性，只可能实现在有限条件状况下的局部配置。

　　不同的工业产品之间可实现不同体系架构之间的集成，是因为在整个工程界已经建立了一个大家共同遵循的标准体系，而且在实际过程中严格执行；那么现在软件行业在还未形成业界所共识的同一标准体系（充其量还限定在“企标阶段”，甚至还远远没有达到），目前就吹嘘可实现异构系统之间无缝集成，只能是自欺欺人。

　　一个工业产品要满足最终的要求，关键在于零部件的质量、装配关系的合理性和液压、电子等装置先进性，在这些条件满足的基础上，还会考虑个系统之间的强度、干涉、电磁干扰等，同时还会考虑可制造、环保等因素；同样软件产品能要实现提升，就必须在服务、通讯和逻辑关系上下功夫同时，也要考虑系统的健壮性和便捷的维护性等，因此软件业在标准化的道路上还要经历漫长的磨练！