SOA是一种软件的应用架构方法，它基于面向对象，但又不是面向对象，整体上是面向服务的架构 。SOA由精确的服务定义、松散的构件服务组成，以及业务流程调用等多个方面形成的一整套架构方法 。这话是不是听起来，让人觉得有点晕，我们就细细品读一下 。
SOA的架构思想（一）SOA架构是面向服务的，只不过是基于面向对象
SOA继承了很多面向对象的特点，比如说面向对象的封装，经常代表很多类封装成一个模块，为其他对象调用者提供接口调用，良好的面向对象设计就是暴露接口，隐藏实现，类比到SOA的设计，SOA也需要精准明确地定义好服务接口，具体服务内部的逻辑实现都是隐藏在背后的，只不过有两个很大的区别：
- （1）面向对象的实现都是基于同一个编程语言或平台（同构），但SOA服务彻底隐藏了实现上用何种语言平台的具体细节（异构）
- （2）面向对象的实现其实大部分都是本地方法之间的调用，当然也具备分布式远程方法调用，但SOA是纯粹提供了独立的服务，面向分布式的远程服务调用 。
这个怎么理解呢？因为SOA的服务一旦发布出来，那么就会有很多其他的异构平台服务进行调用，这时候的服务接口修改就不像一个人或者一个小团队之间协作那么容易了，可能涉及到一个大型企业多部门的信息协作，或者对构件已经形成依赖的生态链条 。因此这就牵扯出了SOA另外一个特征，那就是服务接口的粒度一般要设置得比较粗 。若提供过多的服务接口，服务又定义得很细粒度，那么频繁修改是在所难免的 。这一点上就注定了SOA架构适合在较重量的环境下存在 。
那什么是较重量的环境呢？（1）体系健全、制度稳定的重管理型企业，（2）业务逻辑复杂，服务的独立性，开放性需求又大，服务的稳定性也是刚需 。例如：医院信息化系统架构 。
（三）SOA是由松散的构件服务组成
为什么是松散的呢？由上述我们可以了解到SOA的服务接口是粗粒度的，而且组成服务的构件都是独立部署并具有独立的上下文环境，这种形态就是为了降低与其他构件之间的强依赖性 。让每个构件尽可能一次性为客户提供足够的其领域范围的服务 。
例如：通知服务，客户端只要传递过来通知内容即可，到底是通知短信、、站内信等等，这是通知服务与配置库、用户关系库的内部逻辑关系，也可以通过消息从其他服务中获取 。因此SOA服务更倾向于前期就配置好通知渠道、通知用户组的逻辑关系，这种形式就是客户端轻，管理端重 。
上述这种松散的、粗粒度的构建服务例子，就非常符合SOA架构的胃口，可以让每个服务的独立性看起来很不错，提供一个简单的接口外观，而且越少的接口参数，频繁更改的接口的几率就越低，又满足了服务接口的精确要求，以及服务更偏重管理的特点 。
ESB、BPM在SOA中的实现方式SOA架构可以按业务流程调用各个构件服务，这是个什么概念？想要弄清楚这个概念，我们要站在上帝视角去俯视SOA架构了！
如上图所示：这是一种SOA架构的解决方案，与ESB和BPM的基础中间件结合，BPM作为一个业务流程管理平台，很好的将SOA服务通过流程建模的形式，与业务流程逻辑联系在一起 。那么这个过程中，BPM支撑SOA架构的业务流程协作问题，ESB支撑SOA架构的数据交换问题 。这个架构体系是不是看起来就比较完整了！
例如：应急指挥系统中，我们制定一个流程预案，可以由BPM工具进行建模，进行不同独立运行的SOA构件服务进行流程执行调度，并形成流程执行库 。应用执行端，一般就是客户端手动或定时器自动，启动流程引擎实例，流程引擎读取流程模型库，并配合应用管理端的操作，对构件服务实现访问调度，流程引擎调度的这个过程中，SOA的服务构件始终围绕在ESB周围，交换过程数据 。进行物资服务调度、医疗资源服务调度、通讯设备服务调度、对外信息披露服务调用等 。
那么这种架构例子中，大家是不是看得出来非常适合复杂应用系统整合、协作，因为很有可能通讯设备服务提供了C网络通讯包，物资服务是Java平台运行，医疗资源服务又是.Net平台运行，但是大家基于统一的服务规约，提供精确而风格一致的服务接口，那么对于BPM也好，ESB也好，就极大的减少了适配集成的复杂过程，让各种业务和通讯系统，都变成了一项服务，作为SOA整体调度与管理的一枚棋子而存在 。这其实就有点SOA的精髓了 。
WebService的实现方式
往往很多人不太了解SOA的情况下，就会认为Webservice就是SOA，所以这就是为什么先把上面的SOA思想以及架构实现讲讲，大家就能对SOA有个整体全面的理解 。Webservice只是实现SOA构件服务的一种手段，若将其中的换成基于RestFul风格的实现，也是没有问题的 。
WebService又依赖于几种具体的技术规范和协议了，具体描述我就直接引用吧：
SOAP（Simple ObjectAccess Protocol，简单对象访问协议） 定义了服务请求者和服务提供者之间的消息传输规范，SOAP 用 XML 来格式化消息，用 HTTP 来承载消息 。通过 SOAP，应用程序可以在网络中进行数据交换和远程过程调用（Remote Procedure Call， RPC） 。
WSDL（Web ServiceDescription Language，Web 服务描述语言） 是对服务进行描述的语言，它有一套基于 XML 的语法定义 。WSDL 描述的重点是服务，它包含服务实现定义和服务接口定义 。
UDDI（Universal DescriptionDiscovery and Integration，统一描述、发现和集成） 提供了一种服务发布、查找和定位的方法，是服务的信息注册规范，以便被需要该服务的用户发现和使用它 。UDDI 规范描述了服务的概念，同时也定义了一种编程接口 。通过 UDDI 提供的标准接口，企业可以发布自己的服务百思特网供其他企业查询和调用，也可以查询特定服务的描述信息，并动态绑定到该服务上 。
如何通俗地去理解这三大件呢？
还是上个图，看起来舒服一些 。如上图所示：SOA中的服务1需要调用服务2的接口，那么我们就描述一下Webservices方式 。
首先虚线中，也就是开发阶段服务1要去理解服务2的WSDL描述，清楚服务2提供的服务接口是什么样子，描述语言就是XML，服务1的程序就知道需要设置什么参数，返回什么结果 。
然后在运行时服务1要从UDDI服务上，也就是注册发现中心，找到服务2在哪里，由于服务2早已经在UDDI服务中注册，那么服务1就可以获得服务2的路由地址 。再对需要百思特网传递的数据进行SOAP格式编码 。
SOAP是HTTP层之上的一个传输协议，服务1对传递参数进行满足SOAP协议的xml编码和参数发送，形成对服务2的WebService接口调用，服务2接收到SOAP协议数据，进行xml解码，然后再进行内部实现层的逻辑处理，并最终将结果仍然以SOAP方式编码返回给服务1，由服务1再解码数据 。这就完成了WebService的一次请求和响应 。当然了服务1也可以是一个普通的客户端 。
从上述的图示例子中，我们可以看到WebService是通过XML作为中间传递格式，这就兼容了异构平台的数据格式，SOAP协议大部分是基于HTTP协议（SOAP的设计不限于HTTP），这样就兼容了异构平台数据传输 。
因此WebService的技术实现方案就非常符合SOA架构中服务的异构平台兼容性要求（SOAP），并且具备完整规范的服务接口语义描述（WSDL）和服务注册发现管理的规范定义（UDDI） 。
SOA与微服务的优劣对比往往没有对比就没有伤害，因此我们通过SOA架构与微服务架构的对比，来更深刻地认识SOA架构的优势与劣势，同时也能掌握到微服务优劣特征 。
单体向微服务过渡架构
推荐阅读
- 望远镜是不是倍数越高越清楚看的越远 望远镜看的远近跟倍数有关系吗?
- 什么是直播小程序系统 直播类小程序
- 腾讯企业邮箱怎么免费注册 腾讯企业邮箱怎么免费注册
- 适合电脑桌面的高清壁纸 如何下载 电脑壁纸怎样才能下载高清的
- steam游戏在桌面无法显示正确的图标 steam上的游戏图标不显示怎么办
- 今日火箭比赛回放录像在哪直播在线观看 火箭比赛回放哪里可以看
- 英雄联盟大脚怎么用 英雄联盟大脚路径
- 电脑旁放仙人掌可以防辐射吗 电脑旁放仙人掌可以防辐射吗视频
- 怎样拍摄雪景照片 怎样拍摄雪中红梅视频