SOA是一种软件的应用架构方法，它基于面向对象，但又不是面向对象，整体上是面向服务的架构。SOA由精确的服务定义、松散的构件服务组成，以及业务流程调用等多个方面形成的一整套架构方法。 这话是不是听起来，让人觉得有点晕，我们就细细品读一下。
（一）SOA架构是面向服务的，只不过是基于面向对象
SOA继承了很多面向对象的特点，比如说面向对象的封装，经常代表很多类封装成一个模块，为其他对象调用者提供接口调用，良好的面向对象设计就是暴露接口，隐藏实现，类比到SOA的设计，SOA也需要精准明确地定义好服务接口，具体服务内部的逻辑实现都是隐藏在背后的，只不过有两个很大的区别：
（二）SOA的服务定义是精确的
这个怎么理解呢？因为SOA的服务一旦发布出来，那么就会有很多其他的异构平台服务进行调用，这时候的服务接口修改就不像一个人或者一个小团队之间协作那么容易了，可能涉及到一个大型企业多部门的信息协作，或者对构件已经形成依赖的生态链条。因此这就牵扯出了SOA另外一个特征，那就是服务接口的粒度一般要设置得比较粗。若提供过多的服务接口，服务又定义得很细粒度，那么频繁修改是在所难免的。这一点上就注定了SOA架构适合在较重量的环境下存在。
那什么是较重量的环境呢？（一）体系健全、制度稳定的重管理型企业，（二）业务逻辑复杂，服务的独立性，开放性需求又大，服务的稳定性也是刚需。例如：医院信息化系统架构。
（三）SOA是由松散的构件服务组成
为什么是松散的呢？由上述我们可以了解到SOA的服务接口是粗粒度的，而且组成服务的构件都是独立部署并具有独立的上下文环境，这种形态就是为了降低与其他构件之间的强依赖性。让每个构件尽可能一次性为客户提供足够的其领域范围的服务。
例如：通知服务，客户端只要传递过来通知内容即可，到底是通知短信、、站内信等等，这是通知服务与配置库、用户关系库的内部逻辑关系，也可以通过消息从其他服务中获取。因此SOA服务更倾向于前期就配置好通知渠道、通知用户组的逻辑关系，这种形式就是客户端轻，管理端重。
上述这种松散的、粗粒度的构建服务例子，就非常符合SOA架构的胃口，可以让每个服务的独立性看起来很不错，提供一个简单的接口外观，而且越少的接口参数，频繁更改的接口的几率就越低，又满足了服务接口的精确要求，以及服务更偏重管理的特点。
SOA架构可以按业务流程调用各个构件服务，这是个什么概念？想要弄清楚这个概念，我们要站在上帝视角去俯视SOA架构了！
如上图所示：这是一种SOA架构的解决方案，与ESB和BPM的基础中间件结合，BPM作为一个业务流程管理平台，很好的将SOA服务通过流程建模的形式，与业务流程逻辑联系在一起。那么这个过程中，BPM支撑SOA架构的业务流程协作问题，ESB支撑SOA架构的数据交换问题。这个架构体系是不是看起来就比较完整了！
例如：应急指挥系统中，我们制定一个流程预案，可以由BPM工具进行建模，进行不同独立运行的SOA构件服务进行流程执行调度，并形成流程执行库。应用执行端，一般就是客户端手动或定时器自动，启动流程引擎实例，流程引擎读取流程模型库，并配合应用管理端的操作，对构件服务实现访问调度，流程引擎调度的这个过程中，SOA的服务构件始终围绕在ESB周围，交换过程数据。进行物资服务调度、医疗资源服务调度、通讯设备服务调度、对外信息披露服务调用等。
更多好内容，请关注：破作文 - pozuowen.com