Service Oriented Ambiguity 即面向服务架构， 简称SOA。
SOA的提出是在企业计算领域，就是要将紧耦合的系统，划分为面向业务的，粗粒度，松耦合，无状态的服务。服务发布出来供其他服务调用，一组互相依赖的服务就构成了SOA架构下的系统。
首先，你要知道SOA并不是某一种具体的技术实现，它是一个系统架构的设计思想。这个架构设计思想的提出背景是随着我们的软件系统解决的问题越来越复杂，那么会带来难以维护、难以扩展，容易出错等问题。那么SOA思想的提出就是为了解决这个问题。
举个生活中的例子，随着人们生活水平的提高，出现了越来越多的肥胖人群，肥胖会容易带来一些高血压、糖尿病的发病几率，有人就得出了“减肥”这想法来解决肥胖，减肥不但降低得那些病的几率，还可以让人变得更漂亮。
不同的厂商和个人对SOA有着不同的理解，但从SOA的定义中可以看到几个关键特性：
一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。
SOA的技术实现是什么？继续往下看
1996年SOA的思想被提出，它只是一个理论概念。到了2000年，W3C才成立了相关的委员会，开始讨论Web Service的相关标准，各大厂商一边积极参与标准制定，一边推出了一系列实实在在的产品。新的技术和新的产品出现，SOA找到了可以落地的技术方案。
有人提出节食可以变瘦，一天只吃一顿；有人提出运动可以变瘦，一天跑2000米，“减肥”的想法终于有了具体的实施方案。
你要明白一个关系：SOA不是Web Service，Web Service是实现SOA的一种具体的技术方案。
Web Service的定义：
Web Service是一个平台独立的，低耦合的，自包含的、基于可编程的web的应用程序，可使用开放的XML（标准通用标记语言下的一个子集）标准来描述、发布、发现、协调和配置这些应用程序，用于开发分布式的互操作的应用程序。
Web Service有三个部分组成，分别解答三个问题：
SOAP
Simple Object Access Protocol，即简单对象访问协议， 简称SOAP。
SOAP是基于XML在分散或分布式的环境中交换信息的简单的协议，用于访问网络服务。可使应用程序在 HTTP 之上进行信息交换。
如果你用Wireshark这种网卡级别的抓包工具抓取过SOAP的信息就会发现它传输数据用的HTTP协议。所以，许多人以为SOAP就是HTTP+XML，或者认为SOAP是HTTP的post请求的一个专用版本，遵循一种特殊的XML消息格式。
虽然，我们看到的情况确实如此，但这并不是SOAP本质与全部。当SOAP消息真正需要在网络上实际传输的时候，SOAP消息能够与不同的底层传输协议进行绑定，同时，SOAP消息可以在很多种消息传输模式中使用。包括超文本传输协议（HTTP），简单邮件传输协议（SMTP），多用途网际邮件扩充协议（MIME）。但是，目前SOAP的实现只通过与HTTP进行绑定这么一种。所以，就变成我们看到的这一种样子。
WSDL
Web Services Description Language，即网络服务描述语言，简称WSDL。它是一门基于XML的语言，用于描述Web Services以及如何对它们进行访问。
WSDL格式：
<definitions>
<types>
definition of types........
</types>
<message>
definition of a message....
</message>
<portType>
definition of a port.......
</portType>
<binding>
definition of a binding....
</binding>
</definitions>
WSDL文档主要使用以下几部分组成：
<portType> Web Service执行的操作。<message> Web Service使用的消息。<types> Web Service使用的数据类型。<binding> Web Service使用的通信协议。UDDI
Universal Description, Discovery and Integration"，可译为“通用描述、发现与集成服务”，简称UDDI。
UDDI是一个独立于平台的框架，通过使用Internet来描述服务，发现企业，并对企业服务进行集成。
图：
扩展:
如何开发一个Web Service服务，使用这个项目：
https://pypi.org/project/spyne/
如何调用Web Serveice服务（即接口），参考这个项目：
https://pypi.org/project/suds-jurko
终于把Web Service给你讲清楚了，但是，我要告诉你，Web Service技术过时了。我认为由以下两个原因：
1、技术实现比较麻烦。我用spyne开发过Web Service服务，实现比较麻烦，跟Flask Web框架实现个HTTP接口没法比。
2、数据描述太臃肿，XML描述数据本来就不够简洁，WSDL在XML的基础上定义数据的传输格式就更复杂了。跟JSON这种格式描述数据没法比。
HyperText Transfer Protocol，超文本传输协议，简称HTTP。HTTP是因特网上应用最为广泛的一种网络传输协议。
我想这个我不需要做过多的介绍，但有一个问题你要搞明白，HTTP协议和接口是什么关系？
我举一个生活当中的例子：高速公路和物流是什么关系？ 高速公路规定什么样的工具才能上高速（轮船、飞机机不行），必须带轮子的车，上路之后如何运行，每个车道的时速多少等，车必须按照规则才能在上面运行。 物流是一个模糊的概念，这一般指运输公司运送货物。高速公路只能跑物流吗？当然不是，运输人也可以嘛。物流也不是定走高速公路，走航空的物流也是可以的。高速公路就是HTTP协议，物流就是接口。
启动的Chrome浏览器，打开前端开发者工具，切换到“network”标签，刷新页面。你看到了什么？JS、CSS、Img、media、font、doc、WS、Other等。各种类型的数据，哪个是接口？
JSON
JavaScript Object Notation, JavaScript 对象表示法，简称JSON。JSON是存储和交换文本信息的语法。类似XML。JSON比XML更小、更快，更易解析。
在接口的技术实现上 JSON和HTTP是最佳拍档。它可以更简洁的描述要传输的数据，而且解析也很简单。
物流要运的货物，车厢如何设计节省空间，能装更多的货物，装货/卸货方便。货物是数据，车厢设计就是数据格式。
Representational State Transfer，中文直译感觉不对味，简称REST，如果一个架构符合REST原则，就称它为RESTful架构。
REST只是一个接口设计的风格。
古代的物流叫走镖，走镖是有讲究的，前面有一个喊口号的人叫“趟子手”，例如中原镖局一般喊：“中原镖局，请江湖朋友让个道！” 这江湖规矩，你可以把这种江湖规矩看成REST风格。
比如，一个通过id查询用户信息的接口。
/get_user/?id=1
/user/1/
Remote Procedure Call，远程过程调用。RPC通常特指在一个应用中调用另一个应用的接口而实现的远程调用。
一个RPC框架的实现包含以下部分：
其中，通信部分可使用HTTP协议（七层协议），如 grpc框架使用的就是HTTP2协议；也可以使用TCP/UDP协议（四层协议），如dubbo使用的是TCP协议。
这就好比顺丰快递，他们有自己的一套物流系统，可以走高速，也可以走空运；不仅仅是包含的运送这一项服务，还有上面取件、称重打包，自己的仓储，分拣中心，甚至货物寄丢了还有保险理赔等。你选择了一个rpc框架就相当于选择了一个物流公司的全套服务。
原文：https://www.cnblogs.com/baobao521/p/14684448.html