「面向服务的架构（SOA）」优点是SOA架构可以按业务流程调用各个构件服务，与ESB和BPM的基础中间件结合，通过流程建模的形式，与业务流程逻辑联系在一起。能应用的领域就是帮助传统企业集成异构的老系统。
一、「面向服务的架构（SOA）」优点与应用领域
优点
SOA架构可以按业务流程调用各个构件服务，与ESB和BPM的基础中间件结合，BPM作为一个业务流程管理平台，很好的将SOA服务通过流程建模的形式，与业务流程逻辑联系在一起。那么这个过程中，BPM支撑SOA架构的业务流程协作问题，ESB支撑SOA架构的数据交换问题。
例如：应急指挥系统中，我们制定一个流程预案，可以由BPM工具进行建模，进行不同独立运行的SOA构件服务进行流程执行调度，并形成流程执行库。应用执行端，一般就是客户端手动或定时器自动，启动流程引擎实例，流程引擎读取流程模型库，并配合应用管理端的操作，对构件服务实现访问调度，流程引擎调度的这个过程中，SOA的服务构件始终围绕在ESB周围，交换过程数据。进行物资服务调度、医疗资源服务调度、通讯设备服务调度、对外信息披露服务调用等。
那么这种架构例子中，大家是不是看得出来非常适合复杂应用系统整合、协作，因为很有可能通讯设备服务提供了C++网络通讯包，物资服务是Java平台运行，医疗资源服务又是.Net平台运行，但是大家基于统一的服务规约，提供精确而风格一致的服务接口，那么对于BPM也好，ESB也好，就极大的减少了适配集成的复杂过程，让各种业务和通讯系统，都变成了一项服务，作为SOA整体调度与管理的一枚棋子而存在。
应用领域
帮助传统企业集成异构的老系统。
说到 SOA 就必须提到 ESB（Enterprise Service Bus），即企业服务总线。传统企业各种历史遗留的老系统对外提供的服务接口标准不统一，比如协议有的用 HTTP 有的用 JMS，数据格式有的用 XML 有的用 JSON 还有直接二进制的。ESB 就是要完成各种协议和数据格式的互相转换，让各个异构服务可以方便地相互调用，但是各种协议和数据格式的转换工作量可能很大，ESB 本身容易成为性能瓶颈，所以 SOA 的 ESB 设计也是无奈之举。
互联网行业通常比较年轻，没有那么多历史包袱。就算有，技术部往往也有大量的财力人力做重构，所以 SOA 和 ESB 这种东西就比较遥远。
到这里就避不开那个经典的问题了，SOA 和 微服务有什么区别？可以从两个方面去对比。
1、SOA 是对多个系统做整合，更多考虑的是兼容已有的系统；而微服务是将一个系统做拆分，要考虑高内聚低耦合，轻量灵活、快速迭代。
2、Martin Fowler 说微服务是“聪明的终端，愚蠢的管道”（Smart Endpoints and Dumb Pipes），其中的“Dump Pipes”就是与 ESB 对比的，因为 ESB 知道的事情太多了，而微服务的 Pipes 仅仅做消息传递，使用的是轻量且风格统一的接口（比如 HTTP Restful），无须在接口层进行 SOA 的 ESB 那样的复杂处理。
延伸阅读：
二、SOA的架构思想
1、首先SOA架构是面向服务的，只不过是基于面向对象。SOA继承了很多面向对象的特点，比如说面向对象的封装，经常代表很多类封装成一个模块，为其他对象调用者提供接口调用，良好的面向对象设计就是暴露接口，隐藏实现，类比到SOA的设计，SOA也需要精准明确的定义好服务接口，具体服务内部的逻辑实现都是隐藏在背后的，只不过有两个很大的区别：
（1）面向对象的实现都是基于同一个编程语言或平台（同构），但SOA服务彻底隐藏了实现上用何种语言平台的具体细节（异构）
（2）面向对象的实现其实大部分都是本地方法之间的调用，当然也具备分布式远程方法调用，但SOA是存粹提供了独立的服务，面向分布式的远程服务调用。2、其次SOA的服务定义是精确的，这个怎么理解呢？因为SOA的服务一旦发布出来，那么就会有很多其他的异构平台服务进行调用，这时候的服务接口修改就不像一个人或者一个小团队之间协作那么容易了，可能涉及到一个大型企业多部门的信息协作，或者对构件已经形成依赖的生态链条。因此这就牵扯出了SOA另外一个特征，那就是服务接口的粒度一般要设置的比较粗。若提供过多的服务接口，服务又定义的很细粒度，那么频繁修改是在所难免的。这一点上就注定了SOA架构适合在较重量的环境下存在。
