96年Gartner提出SOA，目的是让企业业务更加敏捷，软件系统变得更有弹性，使企业能快速响应需求的变化，这样的目的是有当时背景的。经济全球化要求企业的业务具备更大的灵活性，比以往能更快地响应市场变化，业务快速变化则要求软件系统具备更大的弹性，而对于企业已经普遍存在的遗留系统来说，这无疑是办不到的，不但办不到，而且遗留系统本身还存在信息孤岛问题。从资源利用的角度，企业为实现利益最大化，遗留系统的问题需要解决，新建系统的弹性更需要解决，就在这样的环境下SOA被提出来，而且越炒越热，从最初基于SOA思想的实现原则、架构模型、参考模型等等一路走来，直到目前的编程模型。OSOA在今年2月份将SCA标准提交给OASIS，到2009年初，SCA将由现在的行业标准变成真正的国际标准。而企业对SOA寄予厚望，同样对SOA的投资也越来越庞大，如IBM现在每年在SOA上的投入多达10亿美元。SOA正由幕后真正的走到台前。
SOA曾经也默默无闻
SOA提出后，限于当时的环境与技术，仅停留在思想层面，直至2003年前后，WebServices异常火爆，SOA才在应用层面有了一片实验田，但SOA成了WebServices的上层模型，几乎等同于WebServices。2003年到2005年，SUN JCP也在酝酿着被称为SOA切入点的JBI，作为ESB构建的核心标准，但IBM与BEA却在历次投票中均弃权，理由是JBI不能真正实现SOA，结果JBI在日后也逐渐销声匿迹，虽然ESB仍然被认为是SOA的重要组成。而在2005底，业内四大巨头IBM、BEA、ORACLE、SAP共同发起成立了OSOA厂商联盟，致力于开发语言中立的SOA编程模型，并且随着SUN在2006年7月份的加入，OSOA厂商已达18家，SOA编程模型，SCA与SDO，成为实现SOA的行业事实标准。
到底该如何理解SOA
有人认为SOA并不是什么新概念，从RPC、IPC直至分布式计算的CORBA、DCOM等，几乎都带有SOA的影子，只是实现角度与方式的差别。那么SOA到底该如何理解？其本质究竟有何吸引人之处？从诞生到成长，SOA被赋予太多的使命与含义，以至长时间里SOA都不能准确定义，直到今天，才渐渐清晰。
开始的时候，SOA只是个方法，是个架构模型
开始的很长一段时间里，SOA只是个方法，是指导企业实现业务敏捷性及建设弹性软件系统的架构模型，引用Bloomberg 的SOA实现原则：
1、 业务驱动服务，服务驱动技术。
2、 业务敏捷是基本的业务需求。
3、 一个成功的SOA总在变化之中。
可以看出，SOA的核心围绕着业务敏捷性展开。业务敏捷性是指企业对变更快速而有效地响应、并且利用变更来得到竞争优势的能力。在当下越来越激烈的市场竞争中，企业为了生存决不会放弃任何能够提高自身竞争实力的机会，业务敏捷性也是如此。实现业务敏捷性首先要求业务本身就具备敏捷性，业务本身就能够对变更快速而有效的响应，这其实是企业管理建设上考虑的事情，涉及到如何使企业信息流通通畅、业务流程重组优化、资源合理配置等等一系列问题，最本质的作法是企业从自身来发现问题所在并改正。
业务具备敏捷性后，接下来考虑的才是通过弹性软件系统来更好的表达业务敏捷性，这应该属于软件方法论的范畴，而这当中的探索可以说历经了软件的整个发展过程，一直探寻的本质其实是信息世界与现实世界间映射关系的建设，也就是如何用软件系统更好的表达现实当中的业务，即现在大家经常说的业务建模。
那么到底如何能够用软件系统来更好的表达现实当中的业务呢？我相信这将会是业内永久的话题。从结构化方法，面向对象方法，直到现在的面向服务方法，随着计算机硬件及网络的发展，世界经济环境的发展，软件系统本身也在不断的发展变化，但其目标却一直没有变化过，那就是更好的描述现实世界并且提升。
SOA秉承的也是这一目标，只是更多了一个考虑：如何应对出现的各种变化，而这些变化主要集中在两个方面：现实世界的发展变化、软件系统本身的发展变化。现实世界的不断变化，要求软件系统能够适应这种变化，软件系统本身也在不断地发展变化，要求新建软件系统能够兼顾遗留软件系统，而只有建设自身就在不断变化的软件系统，才能应对现实世界的不断变化，只有建设技术实现无关的软件系统，才能实现新建软件系统与遗留软件系统的兼顾。引用一句很有哲理的话就是：世界上唯一不变的就是变化。这就是SOA要解决的问题。变化是软件系统建设决不可回避的问题。
SOA的本质还是业务建模，服务只是业务模型的形式
从上面可以看出，SOA架构模型的本质其实还是业务建模，侧重于为应对变化而需要敏捷性的业务建模，至于服务只是业务模型暴露出来的形式，以统一的服务形式描述业务模型。业务的变化是在模型内部的变化，业务敏捷性反映在业务建模的敏捷性上，而服务则解决敏捷业务间的互操作问题。由此可以看出服务只是业务的包装形式，这种形式只要可以解决互操作问题，而可以不问形式到底是什么。这就是为什么有人说：从RPC、IPC直至分布式计算的CORBA、DCOM等，几乎都带有SOA的影子。从SOA架构模型来理解，它们只是服务的形式，服务形式发展历史上经历的技术成熟阶段的产物。目前阶段的SOA肯定也不会是终极形式，只能说是到目前为止最为成熟的形式而已。
话题说到这里，其实应该是分为两个话题了，那就是：具有业务敏捷性的业务建模与技术形式最为成熟的服务。
第一个话题在目前其实也是有成熟的国际标准化组织在推动的，这就是OMG下的MDA，Model Driver Architecture，面向服务架构，这也是目前的热门话题，并且已经出现了研究分支，如DSM，Domain Specific Modeling，领域特定建模。这里涉及到一个软件生产力的问题，从汇编语言到Basic语言，软件生产力提高了400%，而从Basic往后，如C++、Java，软件生产力提高不足20%，究其原因何在：抽象程度不够，而业务建模被认为是提高抽象程度的有效手段。业务建模从另外的角度看仍然具备绝对的重要性。鉴于这篇文章的主题是关于SOA的话题，这个话题我们暂且不表。
但在这里，笔者认为需要提到一点的是：为实现业务敏捷性，业务建模与服务形式存在交叉，即当业务模型以统一的服务形式暴露出来后，便可以通过组装模型组装具有统一服务形式的业务模型，以期实现更大范围的业务敏捷性，这也是目前SOA研究范畴中非常重要的部分，即以统一的服务 形式为基础，通过组装模型，实现更大范围的业务敏捷性。SOA架构模型包含以统一的服务形式为基础通过组装模型实现更大范围的业务建模。
在这里还需要提到一点的是，2005年前后出现的针对遗留系统的整合技术，笔者认为只是一种过渡技术，是SOA服务形式探索道路上的阶段性产物。整合解决的是软件系统间的互联互通问题，而SOA的组装模型并不局限于此，所以两种技术针对遗留系统的解决方案也不尽相同：组装必须首先以遗留系统的服务化改造为基础，然后以统一的服务形式进行组装，而整合则无此必要步骤。在这里笔者也不展开来讨论了。
服务的特征
那么技术形式最为成熟的服务到底是一个什么样子呢？截至目前为止，这一服务形式还在研究与制定当中，这里不能妄下结论。但服务所具备的特征却是在业界有共同认识的。服务具备的特征归纳为如下几点：
1、 服务自治。自治隐藏了服务封装、服务具备明确的边界且独立运行的特点。服务接口是服务与外界交流沟通的唯一途径，通过服务接口封装服务的内部实现，通过服务接口发布服务自己具有的功能，通过服务接口实现服务间的调用，而并不依赖环境上下文，服务接口以内的变化绝对不会影响到接口以外，接口以外的变化也不会影响到接口以内，而服务接口使用统一的表达形式，描述服务具备的功能性与非功能性的能力与特点及服务使用方式，服务接口是服务与外界的明确边界。服务接口以内则独立地维护与运行。
2、 服务松耦合。松耦合隐藏了服务位置透明、基于传输协议的消息交换等特点。有人认为松耦合应该从多个纬度来理解，因为松耦合在这些纬度上均有表现。这些纬度包括：
a) 时间，时间上的松耦合可以使交互双方不必在同一时间进行通讯，即服务使用者发出请求即可，服务提供者发出回复即可。
b) 位置，位置上的松耦合可以使交互双方在不作任何改变的情况下而适应双方可能在物理地址的变化。
c) 接口，接口上的松耦合使交互双方可以绑定到特定接口，也可以绑定到通用接口，如果是通用接口，所有该接口的使用者都能与该接口的提供者进行通讯。
d) 查找，查找上的松耦合使服务使用者可以通过明确的物理或逻辑位置来找到服务提供者并使用它，也可以通过在注册机构或目录服务中查找来匹配服务提供者并使用它。
e) 其他纬度还包括：类型、版本、基数等等，Carlos Perez的文章均有提到。
3、 服务互操作。互操作隐藏了服务环境异构、服务复用等特点，服务使用服务接口作为边界隔离服务内部的环境异构，通过多协议接口实现服务间通讯协议的环境异构，从而实现异构环境下服务互操作，并以此为基础实现服务复用。
以上只是归纳总结了服务所具备的主要特征，当然服务肯定也存在其他特征，但这里不再累述。
从上面的分析可以看出，SOA架构模型是指导企业实现业务敏捷性的指导原则与建设弹性软件系统进行体系结构设计的方法。在方法论层面，SOA无疑是赢得了众多的喝彩。
顺应发展潮流的SOA参考模型与SOA参考架构
于是在2006年10月，OASIS发布了SOA参考模型，虽然仅是个指导企业实现SOA的抽象框架，且在实际SOA实现中起不到多少具体作用，但却是在思想认识上第一次旗帜鲜明的进行了统一，其积极意义不言而喻。
SOA参考模型回答的是：SOA是什么等这样的问题，它秉承了业内对SOA的普遍认识，统一了SOA相关术语及其语义，同时明确了SOA各组成部分间的关系，为企业SOA实践提供了系统的理论指导。
接下来，在SOA参考模型的基础之上，在2007年年内，预计OASIS会提出SOA参考框架，所以在目前阶段SOA参考模型更多的是解释SOA的概念与组成，而未来的SOA参考架构则侧重于SOA如何实现。OASIS标准起草委员会负责人James Bryce Clark谈到：SOA参考架构不是一种标准，更多的将会是以实例的方式来指导SOA实践。
SOA不是WebServices
SOA在方法论上逐渐成熟成为转向应用的充要条件，而WebServices的适时出现，促成了SOA的初次体验。在SOA的发展历程上不得不提的便是WebServices。曾经在很长一段时间里，WebServices被认为就是SOA，而历史走到今天，回过头来再看，SOA却不是WebServices，而且二者也已渐行渐远。
WebServices可以追溯到HP在上世纪90年代末期的分布式计算研究项目，E-Speak，使用Http协议提供XML数据，将互联网系统作为电子服务。紧接着出现的是XML-RPC与ebXML，前者由UserLand领导，后者则由OASIS与UN/CEFACT共同开发和维护，他们都在探索一种技术中立的、基于分布式计算解决互联互通互操作问题的方案。这些技术其实是WebServices发展道路上的必然产物。
SOAP可以视为XML-RPC的升级，改善了Verbosity与Data Typing，同样出自UserLand，并于1999年下半年正式发布。而IBM、MicroSoft、Ariba等厂商在早期WIDL、SDL、SCL、DISCO、NASSL、ADS等规范的基础上最终形成了WebServices描述语言WSDL和WebServices通用描述、发现与集成协议UDDI。这样WebServices协议栈中主要协议都已形成。2001年4月，W3C WebServices研讨会，WSWS，正式召开，讨论WebServices发展规划，如何构建WebServices协议栈，包括Qos、安全、流程及事务等标准，这标志着WebServices标准化正式开始。但随着2000年以科技股为代表的纳斯达克股市的崩盘和互联网泡沫的破灭，业内艰难时期来临，企业为生存而挣扎，直到2002年，情况才有所好转。在这期间，唯一能打动客户的方案无疑就是是如何节约成本，而这正是WebServices所具备的优点：成本低廉的集成方案。所以这一时期被认为是WebServices的黄金时期，至2003年，WebServices更火爆异常。
但IT界独有的快节奏却也使WebServices的问题早早暴露：协议栈并不能保证互操作，并且标准化也不能降低异构环境下系统间的差异，WebServices成本低廉的集成方案更难以降低业务变化的长期成本。到后来，WebServices组织分化，各自发布并维护标准、规范，标准化组织主要有两个，分别是W3C与OASIS，前者发布了SOAP与WSDL，后者则负责维护UDDI，业内厂商联盟WS-I，则致力于解决环境异构下标准互操作问题。
SOA不是WebServices，首先因为SOA早于WebServices出现，如上面提到的，SOA在开始的很长时间里只是个方法，并且致力于解决业务敏捷性，所以SOA极力寻找一种技术中立的实现，至90年代末期，即WebServices协议栈标准开始形成，并且基于被各大厂商认为会成为理想消息协议的XML，所以在那个时期，业内认为WebServices就是SOA。但SOA解决业务敏捷性的目标是没有变过的，所以当后来WebServices基于标准的集成方案并不能达成SOA业务敏捷性目标的时候，二者的分开便是不可避免的了。所以会有人说：WebServices只是目前最适合实现SOA的技术。而SOA却不是WebServices。WebServices基于标准的应用编程接口，缺乏SOA的松耦合、位置透明等特征，更不能实现业务敏捷性，并且WebServices服务难以管理。
JBI插曲
在2003年到2005年，SUN JCP也在酝酿着被称为SOA切入点的JBI，作为ESB构建的核心标准，但IBM与BEA却在历次投票中均弃权，理由是JBI不能真正实现SOA。紧接着2005年底，IBM、BEA、ORACLE、SAP等共同发起成立了OSOA厂商联盟，制定SCA与SDO规范，其中SCA就是针对IBM、BEA认为不能实现SOA的JBI的，所以JBI的没落不可避免，而目前SOA编程模型，SCA与SDO，已然是行业事实标准了。
SOA编程模型
SOA编程模型从业务需求出发，以开放的服务组件与动态交互技术为基础，将松耦合的服务组件快速组装成业务流程，完成业务活动，从而实现软件系统业务敏捷性。而SCA与SDO则是相互关联的规范，SCA关注业务逻辑，SDO侧重于业务数据。
SCA主要描述面向服务的计算环境里服务组件与组装模型的实现方法，强调服务组件与平台及服务组件之间的关联，并描述怎样通过已有的技术、平台甚至组件来实现服务组件，确定统一、通用的服务组件接口及其语义，建立服务组件间松耦合的交互环境，并定义服务组件组装模型。开放的服务组件与服务组件组装模型技术独立、平**立、语言独立，厂商们可以在不同平台上使用不同技术和语言来实现。
服务组件组装模型的目标是融合实现服务组件以及实现服务组件间访问方法的广泛技术。对于服务组件而言，不仅涉及不同的编程语言，而且也涉及到这些编程语言的架构及运行环境。对于访问方法而言，组装模型允许使用常用的通讯与访问技术，包括WebServices，消息及RPC等。组装模型允许使用多种技术来实现，包括Java，C++，Bpel，Php，Javascript，Xquery，Sql等。
服务组件组装模型组装起来的应用系统，既可以包括全新定制的服务组件，也可以包括存在于现有系统中的业务逻辑。这些现有的业务逻辑，作为应用系统的一部分而进行复用。组装模型涉及了服务组件的组装和服务组件的创建，并且也涵盖了现有应用系统功能的复用。
SDO则是高度抽象的业务数据模型，主要描述业务数据对象及其内部各种粒度的数据对象之间的关联，以统一的方式访问或操作不同类型的数据源，并进行持久化。SDO提供连接器，可以通过不同方式且环境透明地与多种数据源交互，目前已支持的数据源有关系数据库、XML文档及其它，同时还提供诸如连接池、缓存、断开连接时数据访问等高级特性。另外，SDO还提供中介转换器，可以根据业务语义定义完整的业务模式，并提供对象图表，与连接器交互，完成数据持久化工作。SDO可以充分提高数据管理的效率。
从上面的分析可以看出，SOA编程模型从较高的抽象层次上对SOA架构模型做了技术中立的实现，并从业务驱动的角度，以简洁、通用且技术开放的服务组件及组装方式更贴切的表达业务需求，使开发人员脱离开底层技术实现的细节，更多的关注于业务逻辑的分析设计，而软件系统架构却不失开放性、灵活性等等特征，在业务数据处理方面则以统一的方式管理多种类型的数据源，充分提高数据管理的效率。
SOA不仅是技术范畴，更是商业战略，是帮助企业不断进化的途径，用以构建以解决业务问题为中心的软件系统，旨在全面帮助企业充分利用现有IT资产，提高效率、降低成本、实现业务敏捷性与创新。
OSOA在今年2月份将SCA标准提交给OASIS，到2009年初，SCA将由现在的行业标准变成真正的国际标准。
SOA的新技术之争悄然进行
2006年底，SDO2.1发布，2007年3月，SCA1.0发布，标志着SOA实现真正提上日程，而业内各大巨头早已着手于SOA实现。
IBM推出SOA产品包括其ESB、基于WebSphere的Process Server与Business Modeler、Rational产品等。BEA也将其三个主要产品线，Aqualogic、WebLogic和Tuxedo，调整为基于SOA架构的MicroServices Architecture。Oracle推出SOA Suite包括Fusion Middleware、BPEL、ESB、RulesEngine等众多产品。
新一轮的新技术竞争早已悄然开始，而SOA无疑将会引领下个十年。