一、SOA概念
1、定义：
SOA，是一个组件模型，面向服务的体系架构，它将应用程序的不同服务通过这些服务之间定义良好的接口和契约联系起来，不涉及底层编程接口和通讯模型。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言，这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互，可以看作是B/S模型、 XML/Web Service技术之后的自然延伸。
2、作用：
SOA将能够帮助软件设计师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。
较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。
|
松耦合
|
| 可从企业外部访问 |
| 随时可用 |
| 粗粒度的服务接口分级 |
| 可重用的服务 |
| 服务接口设计管理 |
| 标准化的服务接口 |
| 支持各种消息模式 |
| 精确定义的服务契约 |
| SOA服务具有平台独立的自我描述XML文档 |
| SOA 服务用消息进行通信 |
| SOA服务通过一个扮演目录列表角色的登记处来进行维护 |
| 每项SOA服务都有一个与之相关的服务品质 |
1、典型案例：
一个服装零售组织拥有 500 家国际连锁店，它们常常需要更改设计来赶上时尚的潮流。 这可能意味着不仅需要更改样式和颜色，甚至还可能需要更换布料、制造商和可交付的产品。 如果零售商和制造商之间的系统不兼容，那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。
2、为何使用SOA：
通过利用 WSDL 接口在操作方面的灵活性，每个公司都可以将它们的现有系统保持现状，而仅仅匹配 WSDL 接口并制订新的服务级协定，这样就不必完全重构它们的软件系统了。这是业务的水平改变，也就是说，它们改变的是合作伙伴，而所有的业务操作基本上都保持不变。
这里，业务接口可以作少许改变，而内部操作却不需要改变，之所以这样做，仅仅是为了能够与外部合作伙伴一起工作。
另一种形式是内部改变，在这种改变中，零售组织决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店，这可以看作是采用店中店的业务模型。这里，虽然公司的大多数业务操作都保持不变，但是它们需要新的内部软件来处理这样的出租安排。尽管在内部软件系统可以承受全面的检修，但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下，SOA 模型保持原封不动，而内部实现却发生了变化。虽然可以将新的方面添加到 SOA 模型中来加入新的出租安排的职责，但是正常的零售管理系统继续如往常一样。
为了延续内部改变的观念，IT 经理可能会发现，软件的新配置还可以以另外的一种方式加以使用，比如出租粘贴海报的地方以供广告之用。这里，新的业务提议是通过在新的设计中重用灵活的 SOA 模型得出的。这是来自 SOA 模型的新成果，并且还是一个新的机会，而这样的新机会在以前可能是不会有的。
改变和 SOA 系统适应改变的能力是最重要的部分。对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。
与开发人员不同的是，架构师的作用就是引起对 SOA 模型大的改变。
这种分工，就是让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起。
它已经有十多年的历史了，通常用 UML，并且描述成 模型驱动的体系结构。
对于面向同步和异步应用的，基于请求/响应模式的分布式计算来说，SOA是一场革命。
一个应用程序的业务逻辑或某些单独的功能被模块化并作为服务呈现给消费者或客户端，这些服务的关键是他们的松耦合特性。例如，服务的接口和实现相独立，应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用，而无须理解服务的底层实现。
举例来说，一个服务可以用.NET或J2EE来实现，而使用该服务的应用程序可以在不同的平台之上，使用的语言也可以不同。.
三、总结
1、SOA优点
服务导向架构并不是一种全新的解决方案，相反SOA是技术与架构的自然进化。
系统架构一直在不断进步，与商业保持高度一致。系统设计师与商家很早就认识到将技术与商业流程相协调的重要性，包括充分应用并合理化技术资源，以及为商业提供更好的支持。
SOA也在一定程度上源于早已有之的企业架构理论。
企业架构对技术进行评估，但是更重要的是，它关注整个企业和全部的商业流程并提供了做出技术决策的背景信息。SOA工具则融合了互联网技术，如HTTP和XML，以及综合技术，如消息总线、转译技术和连接技术。
| 传统架构 | 面向服务架构（SOA） | |
| 设计目标 | 持久的 | 适应变化的 |
| 导向 | 功能导向 | 流程导向 |
| 开发周期 | 长 | 短，增量式开发 |
| 应用结构、面向对象、异构的基础 | 组件和对象 | 服务 |
| 实现内容 | 已知需求 | 抽象实现，随时准备未来发生的变化 |
| 应用 | 应用“孤岛” | 可编排式协同 |
| 耦合 | 紧耦合 | 松耦合，敏捷且适应力强 |
| IT投入 | 大，长期 | 小，短期 |