爱华网“面向服务的架构”表达了一种软件架构的概念，它定义为使用服务来满足软件用户的需求。在SOA环境中，网络上的节点以独立服务的形式将自己的资源开放给网络上其他参与者，其他参与者按照一种标准的方法使用资源。
SOA不是一种具体的架构，它是能够导出某种具体架构的东西。你可以将它叫做一种风格、范式、概念、观点、哲学、或者表示法。这也意味着SOA不是一种可以买到的具体工具或框架。它是一种说法，是一种思考方式，是个价值体系。
为什么SOA？
要理解为什么需要SOA，就必要理解大型分布式系统的特点:
1. 大型系统必须能够处理老系统（引入SOA时，你很难从头开始设计）
2. 大型系统天生就是异质的。他们目的不同，时间各异，新旧程度相差悬殊；大型系统堆积了不同平台，不同的语言，不同的编程范式。
3. 异质性的一大原因是因为大型系统和它们的数据有非常长的生命周期。在这个过程中，它们不断加入新的系统和流程，开发新的业务功能。
4. 大型系统天生是复杂的。而且，人类处理复杂问题的能力也是有限的，通常采取的方法就是分解。
5. 所有者各异。不同的团队、部门、分支机构或公司都可能在维护系统
6. 冗余度。
面对大型系统，SOA接受异质的，SOA正是靠对异质性的承认和支持来处理大系统的。过去人们提出了许许多多的方法，试图消除异质性，解决集成分布式系统碰到的问题。比如，“把所有系统都换成J2EE应用”、“不管哪儿都用CORBA”，“用MQ Sevce“，然而，这些方法都不行，大型系统天生就是异质的，这是事实。也是我们设计大型分布式方案时必须接受的前提。
SOA是新东西么？
SOA没有任何新发明的东西，它是个把现有概念和实践放到一起，用于特定需求的范式。
SOA的改进之一可能体现在如下一点：Web Service引入了一个互操作性的新标准。
SOA另一个重要的方面是对异质性的接受。这一点体现了SOA是一个革命性的方法，不同于以前经常看到的东西哦，过去，相当多的解决方法都是基于同质化想法，然而，只要系统超过一定的规模，同质化就不可能。同质化也无法伸缩，这意味着任何要求同质化的方法迟早会失败。（类似于敏捷编程接受需求不断变更的事实，而不是力图与这个事实抗争）。
核心是什么？
我们已经知道了SOA是一个范式，目的是实现和维护跨越了大型分布式系统的业务流程。那么它的核心是什么？
l 服务
软件开发的艺术就是关于抽象的艺术。抽象可以从不同的角度进行。SOA的抽象集中在问题的业务角度。与业务相对应的SOA概念就是“服务“。本质上，服务就是业务功能的IT体现。SOA的目标就是基于业务规则和功能的抽象来构筑大型分布式系统。我们可以把服务当做自足的业务功能的IT体现，比如”创造一个客户“，“转账”，“打开收音机”，“计算汽车的最佳路线”等。
l 互操作性
处理异质系统时，第一个目标就是能轻松的连接系统。这通常被称为“高互操作性”。虽然，高互操作性不是什么新点子，之前“企业应用集成”EAI就有这样的概念。但是，高互操作性和SOA得开始而非结束。从这个基础出发，实现跨越多个分布式系统的业务功能。
l 松耦合
松耦合是小化依赖，SOA是一个范式，而不是具体方法。多大程度上引入松耦合取决于你自己。
松耦合的形式：
紧耦合
松耦合
物理连接
点对点
通过中介者
通信风格
同步
异步
数据模型
公共复杂类型
只是简单的公共类型
类型系统
强
弱
交互模式
通过复杂的对象树导航
以数据为中心、自足的消息
业务逻辑控制
集中控制
分布式控制
绑定方式
静态
动态
平台
强平台依赖
平台无关
事务性
2PC（两阶段提交）
补偿
部署
同时进行
非同时进行
版本划分
显示升级
隐式升级
SOA要素
我们已经知道了SOA的关键技术概念是：服务、互操作性和松耦合。那么建立SOA所需要做的就是要引入服务、互操作性和松耦合。
但是SOA是买不来的，重要的是以合适的方式引入这些概念。这里面有一些要素，包括基础设施、架构以以及流程。
l 基础设施（ESB）
基础设施使SOA高操作性成为可能的技术部分。SOA范畴的基础设施被称为“企业服务总线”（ESB）。
ESB的关键业一点，它能使得在异质系统间进行服务调用。他的职责包括数据转化、（智能）路由、处理安全和可靠性、服务管理、监测、以及日志。
l 架构
l 流程
大型系统牵涉了许多不同的人和组织。因为通常并不由一个人或少数人控制着所有一切，所以必须建立起适当的过程。这些过程包括：
业务过程建模（BPM）
服务生命周期
模型驱动的软件开发
l 监管
建立起一个大型的SOA项目，你需要处理不同的组织结构，所以理解、监管、管理支持和专研是SOA成功的关键因素。
SOA与WEB Service
许多SOA定义都包括Web Service这个术语。但是，SOA与Web Service不一样，SOA是个范式；Web Service是运用特定实现策略，实现基础设施的可能方法。
REST表述性状态转移：最近，它常被人称为Web Service的替代品，它指的是一个网络架构原则的集合，聚焦于对资源进行简单和无状态访问。RESTful HTTP使用4个基础HTTP方法：GET/PUT/POST/DELETE，对由URL标识出的资源进行无状态的读、写、创建/执行和删除、这种对HTTP协议的自然运用既简单又迅速，并且包含了对诸如缓存这样的典型需求的内生技术支持、所以，对于访问服务器提供的数据或资源来说，这可能是一个很好的方法。
然而，它缺乏对安全性考量。非功能性特性、可组合性的支持，再加上全面铺开的。复杂的SOA基础设施有流程服务、配置、某些场景下读取与写于服务还有不同的粒度，所以，它很难被用作SOA的核心协议。
如果只是想向外部系统提供对数据资源的访问，REST绝对是应该考虑的原则或技术，但是，如果计划建立一个运行分布式业务流程的SOA景观，REST还不是一个可选项。
在很多场合的交流中，常常遇到把SOA和Web Service混用的情况，所以想在这次的Blog里，结合网上的各种观点，谈谈个人对两个概念的理解。用一句话来概括基本的观点就是“SOA不是Web Service，Web Service是目前最适合实现SOA的技术”。 之所以SOA和Web Service被混为一谈，最可能的原因了也就在于此吧。
早在1996年Gartner就前瞻性地提出了面向服务架构的思想(SOA)，该年赫赫有名的Netscape才发布了Navigator 2.0，整个互联网刚刚庆祝超过500,000网站的诞生，网络上的商业应用还是凤毛麟角，Web Service不知为何物，SOA还只是束之高阁的理论概念。直到2000年以后，W3C才成立了相关的委员会，开始讨论Web Service的相关标准;各大厂商一边积极参与标准制定，一边推出了一系列实实在在的产品。新的技术和新的产品出现，SOA找到了可以依托的凭借。随着Web Service技术的推出和应用，SOA的思想被一个个效益显著的信息系统建设项目不断的示范，才逐渐成为现今的热门话题。类似的情况让人联想到爱因斯坦提出来的理论，著名的质量能量转化等式E=mc2，直到人们掌握了核子裂变技术，才成功生产出了原子弹，向世人展示了这个理论等式的巨大威力。
因为现在几乎所有的SOA应用场合都是和Web Service绑定的，所以不免有时候这两个概念混用。不可否认Web Service是现在最适合实现SOA的技术，SOA的走红在很大程度上归功于Web Service标准的成熟和应用普及。因为现在大家基本上认同Web Service技术在几方面体现了SOA的需要：
首先是基于标准访问的独立功能实体满足了松耦合要求：在Web Service中所有的访问都通过SOAP访问进行，用WSDL定义的接口封装，通过UDDI进行目录查找，可以动态改变一个服务的提供方而无需影响客户端的配置，外界客户端是根本不关心访问服务器端的实现。
其次，适合大数据量低频率访问符合服务大颗粒度功能：基于性能和效率平衡的要求，SOA的服务提供的是大颗粒度的应用功能，而且跨系统边界的访问频率也不会象程序间函数调用那么频繁。通过使用WSDL和基于文本(Literal)的SOAP请求，可以实现能一次性接收处理大量数据。
最后，基于标准的文本消息传递为异构系统提供通讯机制：Web Service所有的通讯是通过SOAP进行的，而SOAP是基于XML的，XML是结构化的文本消息。从最早的EDI开始，文本消息也许是异构系统间通讯最好的消息格式，适用于SOA强调的服务对异构后天宿主系统的透明性。
综合上述观点，Web Service不愧为当前SOA的最好选择。然而，就SOA思想本身而言，并不一定要局限于Web Service方式的实现。更应该看到的是SOA本身强调的是实现业务逻辑的敏捷性要求，是从业务应用角度对信息系统实现和应用的抽象。随着人们认识的提高，还会有新技术不断的发明出来，更好的来满足这个要求。就好像在核子裂变之后，人们又发现了威力更加强大的核子聚变。为了要有一个更高的角度来看待问题，SOA和Web Service还是不应该混为一谈。
