SOA 是一个服务组件模型
面向服务方法 关注的是业务，以业务驱动技术，强调 IT 与业务的对齐，以开放标准封装业务流程和已有的应用系统，实现应用系统之间的相互访问。
三个著名的 Web 服务标准和规范：简单对象访问协议(Simple Object Access Protocol，SOAP)、Web 服务描述语言(Web Services Description Language，WSDL)，通用服务发现和集成协议(Universal Discovery Description and Integration, UDDI)。
SOA 架构向更细粒度、更通用化程度发展，就成了所谓的微服务了。SOA 与微服务的区别在于如下几个方面：(1)微服务相比于 SOA 更加精细，微服务更多地以独立的进程的方式存在，互相之间并无影响；(2)微服务提供的接口方式更加通用化，例如 HTTP RESTful 方式，各种终端都可以调用，无关语言、平台限制；(3)微服务更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合。
从服务为中心的视角来看，企业集成的架构可分为 6 类。
业务逻辑服务(Business Logic Service)：包括用于实现业务逻辑的服务和执行业务逻辑的能力，其中包括业务应用服务(Business Application Service)、业务伙伴服务(Partner Service)以及应用和信息资产(Application and Information asset)。
控制服务(Control Service)：包括实现人(People)、流程(Process)和信息(Information)集成的服务，以及执行这些集成逻辑的能力。
连接服务(Connectivity Service)：通过提供企业服务总线提供分布在各种架构元素中服务间的连接性。
业务创新和优化服务(Business Innovation and Optimization Service)：用于监控业务系统运行时服务的业务性能，并通过及时了解到的业务性能和变化，采取措施适应变化的市场。
开发服务(Development Service)：贯彻整个软件开发生命周期的开发平台，从需求分析，到建模、设计、开发、测试和维护等全面的工具支持。
IT 服务管理(IT Service Management): 支持业务系统运行的各种基础设施管理能力或服务，如安全服务、目录服务、系统管理和资源虚拟化。
ESB 的基本特征和能力包括：描述服务的元数据和服务注册管理；在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式、异步模式等；发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些的能力，包括对安全的支持、服务质量保证、可管理性和负载平衡等。
以服务为中心的企业集成通过 应用和信息 访问服务(Application and Information Access Service)来实现对已有应用和信息的集成。它通过各种适配器技术将已有系统中的业务逻辑和业务数据包装成企业服务总线支持的协议和数据格式。通过企业服务总线，这些被包装起来的业务逻辑和数据就可以方便地参与上层的业务流程，从而已有应用系统的能力可以得以继续发挥。
整合客户和业务伙伴(B2C/B2B)——伙伴服务。
以服务为中心的企业集成通过伙伴服务提供与企业外部的 B2B 的集成能力。因为业务伙伴系统的异构性，伙伴服务需要支持多种传输协议和数据格式。在参考架构中，提供如下服务。
社区服务(Community Service): 用于管理和企业贸易的业务伙伴，支持以交易中心(Trade Hub)为主的集中式管理和以伙伴为中心的自我管理。
文档服务(Document Service): 用于支持和业务伙伴交换的文档格式，以及交互的流程和状态管理，支持主流的 RosettaNet、EDI 和 AS1/AS2 等。
协议服务(Protocol Service): 为文档的交互提供传输层的支持，包括认证和路由等。
UDDI 是 Web 服务集成的一个体系框架，包含了服务描述与发现的标准规范。UDDI 规范利用了 W3C 和 Internet 工程任务组织的很多标准作为其实现基础，如 XML、HTTP 和 DNS 等协议。另外，在跨平台的设计特性中,UDDI 主要采用了已经被提议给 W3C 的 SOAP(Simple Object Access Protocol，简单对象访问协议)规范的早期版本。
WSDL(Web Services Description Language，Web 服务描述语言)，是一个用来描述 Web 服务 和 说明如何与 Web 服务通信的 XML 语言。它是 Web 服务的接口定义语言，由 Ariba、Intel、IBM 和 MS 等共同提出，通过 WSDL，可描述 Web 服务的三个基本属性。1)服务做些什么——服务所提供的操作(方法)。2)如何访问服务——和服务交互的数据格式以及必要协议。3)服务位于何处——协议相关的地址，如 URL。
SOAP 是在分散或分布式的环境中交换信息的简单的协议，是一个基于 XML 的协议。它包括 4 个部分：SOAP 封装(Envelop)，定义了一个描述消息中的内容是什么，是谁发送的，谁应当接收并处理它以及如何处理它们的框架；SOAP 编码规则(Encoding Rules)，用于表示应用程序需要使用的数据类型的实例；SOAP RPC 表示(RPC Representation)是远程过程调用和应答的协定；SOAP 绑定(Binding)是使用底层协议交换信息。
SOA 服务用消息进行通信，该消息通常使用 XML Schema 来定义（也称作 XSD，XML Schema Definition）。消费者和提供者，或消费者和服务之间的通信多见于不知道提供者的环境中。服务间的通信也可以看作企业内部处理的关键商业文档。
在一个企业内部，SOA 服务通过一个 扮演目录列表 (Directory Listing)角色的登记处(Registry)来进行维护。应用程序在登记处(Registry)寻找并调用某项服务。统一描述、定义和集成是服务登记的标准。
SOA 对于实现企业资源共享，打破“信息孤岛”的步骤如下：1) 把应用和资源转换成服务。2) 把这些服务变成标准的服务，形成资源的共享。
无状态。以避免服务请求者依赖于服务提供者的状态。
服务注册: 应用开发者，也叫服务提供者，向注册表公布他们的功能。他们公布服务合同，包括 服务身份、位置、方法、绑定、配置、方案和 策略 等描述性属性。实现 SOA 治理最有效的方法之一，是限制哪类新服务可以向主注册表发布、由谁发布以及谁批准和根据什么条件批准。此外，许多注册表包含开发向注册表发布服务可能需要的说明性服务模板。
ESB 本质上是以 中间件 形式支持服务单元之间进行交互的软件平台。各种程序组件以标准的方式连接在该 “总线” 上，并且组件之间能够以格式统一的消息通信的方式来进行交互。
ESB 最大限度上解耦了组件之间的依赖关系，降低了软件系统互连的复杂性。连接在总线上的组件无需了解其他组件和应用系统的位置及交互协议，只需要向服务总线发出请求，消息即可获得所需服务。服务总线事实上实现了组件和应用系统的位置透明和协议透明。技术人员可以通过开发符合 ESB 标准的组件(适配器)将外部应用连接至服务总线，实现与其他系统的互操作。同时，ESB 以中间件的方式，提供服务容错、负载均衡、QoS 保障和可管理功能。
ESB 的核心功能如下。1) 提供位置透明性的消息路由和寻址服务。2) 提供服务注册和命名的管理功能。3) 支持多种消息传递范型(如请求/响应、发布/订阅等)。4) 支持多种可以广泛使用的传输协议。5) 支持多种数据格式及其相互转换。6) 提供日志和监控功能。
微服务的特点如下：
- 复杂应用解耦：
微服务架构将单一模块应用分解为多个微服务，同时保持总体功能不变。应用按照业务逻辑被分解为多个可管理的分支或服务，避免了复杂度的不断积累。每个服务专注于单一功能，通过良好的接口清晰表述服务边界。由于功能单一、复杂度低，小规模开发团队完全能够掌握，易于保持较高的开发效率，且易于维护。
- 独立：
微服务在系统软件生命周期中是独立开发、测试及部署的。微服务具备独立的运行进程，每个微服务可进行独立开发与部署，因此在大型企业互联网系统中，当某个微服务发生变更时无需编译、部署整个系统应用。从测试角度来看，每个微服务具备独立的测试机制，测试过程中不需要建立大范围的回归测试，不用担心测试破坏系统其他功能。因此，微服务组成的系统应用具备一系列可并行的发布流程，使得开发、测试、部署更加高效，同时降低了因系统变更给生产环境造成的风险。
- 技术选型灵活：
微服务架构下系统应用的技术选型是去中心化的，每个开发团队可根据自身应用的业务需求发展状况选择合适的体系架构与技术，从而更方便地根据实际业务情况获得系统应用最佳解决方案，并且每个微服务功能单一、结构简单，在架构转型或技术栈升级时面临较低风险，因此系统应用不会被长期限制在某个体系架构或技术栈上。
- 容错：
在传统单体应用架构下，当某一模块发生故障时，该故障极有可能在整个应用内扩散，造成全局应用系统瘫痪。然而，在微服务架构下，由于各个微服务相互独立，故障会被隔离在单个服务中，并且系统其他微服务可通过重试、平稳退化等机制实现应用层的容错，从而提高系统应用的容错性。微服务架构良好的容错机制可避免出现单个服务故障导致整个系统瘫痪的情况。
- 松耦合，易扩展：
传统单体应用架构通过将整个应用完整地复制到不同节点，从而实现横向扩展。但当系统应用的不同组件在扩展需求上存在差异时，会导致系统应用的水平扩展成本很高。微服务架构中每个服务之间都是松耦合的，可以根据实际需求实现独立扩展，体现微服务架构的灵活性。
在聚合器微服务中，聚合器调用多个微服务实现系统应用程序所需功能，具体有两种形式，一种是将检索到的数据信息进行处理并直接展示；另一种是对获取到的数据信息增加业务逻辑处理后，再进一步发布成一个新的微服务作为一个更高层次的组合微服务，相当于从服务消费者转换成服务提供者。与普通微服务特性相同，聚合器微服务也有自己的缓存和数据库。
链式微服务：客户端或服务在收到请求后，会返回一个经过合并处理的响应，该模式即为链式微服务设计模式。
数据共享微服务：运用微服务架构重构现有单体架构应用时，SQL 数据库反规范化可能会导致数据重复与不一致现象。异步消息传递微服务：目前流行开发 RESTful 风格的 API , REST 使用 HTTP 协议控制资源，并通过 URL 加以实现。
当 SOA 架构师遇到一个十分复杂的企业系统时，首先考虑的应该是如何重用已有的投资而不是替换遗留系统，因为如果考虑到有限的预算，整体系统替换的成本是十分高昂的。
当 SOA 架构师分析原有系统中的集成需求时，不应该只限定为基于组件构建的已有应用程序的集成，真正的集成比这要宽泛得多。在分析和评估一个已有系统体系结构的集成需求时，必须考虑一些更加具体的集成的类型，这主要包括以下几个方面：应用程序集成的需求，终端用户界面集成的需求，流程集成的需求 以及 已有系统信息集成的需求。
SOA 系统中服务粒度的控制是一项十分重要的设计任务。通常来说，对于将暴露在整个系统外部的服务推荐使用 粗粒度 的接口，而相对较细粒度的服务接口通常用于企业系统架构的内部。从技术上讲，粗粒度的服务接口可能是一个特定服务的完整执行，而细粒度的服务接口可能是实现这个粗粒度服务接口的具体的内部操作。
SOA 系统架构中的具体服务应该都是独立的、自包含的请求，在实现这些服务的时候不需要前一个请求的状态，也就是说服务不应该依赖于其他服务的上下文和状态，即 SOA 架构中的服务应该是无状态的服务。当某一个服务需要依赖时，最好把它定义成具体的业务流程（BPEL）。
业务组件模型是一种业务咨询和转型的工具，它根据业务职责、职责间的关系等因素，将业务细分为业务领域、业务执行层次和业务组件。
在 SOA 的实施中，自底而上分析方式的目的是利用已有资产来实现服务，已有资产包括已有系统、套装或定制应用、行业规范或业务模型等。这也可以称为“遗留资产分析”，它的主要思想是：通过建立已有系统所具有的功能模块目录列表，可以方便地发现那些在不同的系统中被重复实现的功能模块以及可以复用的功能模块，从而将这些模块包装成服务发布出来。遗留资产分析的来源一般是原有系统的分析和设计文档，遗留系统分析的结果是可以重用的服务列表。
业务对象是对数据进行检索和处理的组件，是简单的真实世界的软件抽象。业务对象通常位于中间层或者业务逻辑层。
