什么是 RPC 框架，web service,wsdl,soap

远程过程调用带来的新问题

在远程调用时，我们需要执行的函数体是在远程的机器上的，也就是说，方法是在另一个进程中执行的。这就带来了几个新问题：

Call ID映射。我们怎么告诉远程机器我们要调用Multiply，而不是Add或者FooBar呢？在本地调用中，函数体是直接通过函数指针来指定的，我们调用Multiply，编译器就自动帮我们调用它相应的函数指针。但是在远程调用中，函数指针是不行的，因为两个进程的地址空间是完全不一样的。所以，在RPC中，所有的函数都必须有自己的一个ID。这个ID在所有进程中都是唯一确定的。客户端在做远程过程调用时，必须附上这个ID。然后我们还需要在客户端和服务端分别维护一个 {函数
<--> Call ID} 的对应表。两者的表不一定需要完全相同，但相同的函数对应的Call ID必须相同。当客户端需要进行远程调用时，它就查一下这个表，找出相应的Call ID，然后把它传给服务端，服务端也通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。
序列化和反序列化。客户端怎么把参数值传给远程的函数呢？在本地调用中，我们只需要把参数压到栈里，然后让函数自己去栈里读就行。但是在远程过程调用时，客户端跟服务端是不同的进程，不能通过内存来传递参数。甚至有时候客户端和服务端使用的都不是同一种语言（比如服务端用C++，客户端用Java或者Python）。这时候就需要客户端把参数先转成一个字节流，传给服务端后，再把字节流转成自己能读取的格式。这个过程叫序列化和反序列化。同理，从服务端返回的值也需要序列化反序列化的过程。
网络传输。远程调用往往用在网络上，客户端和服务端是通过网络连接的。所有的数据都需要通过网络传输，因此就需要有一个网络传输层。网络传输层需要把Call ID和序列化后的参数字节流传给服务端，然后再把序列化后的调用结果传回客户端。只要能完成这两者的，都可以作为传输层使用。因此，它所使用的协议其实是不限的，能完成传输就行。尽管大部分RPC框架都使用TCP协议，但其实UDP也可以，而gRPC干脆就用了HTTP2。Java的Netty也属于这层的东西。
所以，要实现一个RPC框架，其实只需要把以上三点实现了就基本完成了。

Call ID映射可以直接使用函数字符串，也可以使用整数ID。映射表一般就是一个哈希表。

序列化反序列化可以自己写，也可以使用Protobuf或者FlatBuffers之类的。

网络传输库可以自己写socket，或者用asio，ZeroMQ，Netty之类。

Netty只是网络通信框架,目的是让你用最少的代码构建出足够支撑网络通信的功能。dubbo默认使用netty作为基础的通信组件。

WebServices到底是什么？

如果简单的说的话，WebServices就是一组函数库，不过这和我们平时概念中的函数库却又有所不同，我们平时所使用的函数库要么是自己写的（在自己的应用程序当中写一组函数库），

要么是调用底层的 API（操作系统 API 如Win32 API），上面的这两种情况有一个共同点，

那就是函数库是位于客户端本地的，比如，您调用 Win32 API的话，就是调用本地操作系统上的函数库，而这里提到 Web 服务也是一组函数库这个概念和上面提到的函数库这个概念的区别就在此处，因为 Web服务看做一组函数库的话，那么这组函数库不是位于本地的，而是位于远程机器上（当然也可以是本地机器中）。

何为 Web 服务？

也就是网络服务，那就是把网络上不知道那个地方的一些函数看做是一组服务，然后我再通过网络就可以使用这些服务。

关于什么是 Web 服务，上面的说法那是山寨版的，稍微正经一点的说法是：

Web 服务是一种部署在 Web 上的对象或者是应用程序组件。

Why WebServices？

为什么需要使用 WebServices呢？这必须根据 WebServices 的特点以及其优势进行分析了。

首先，上面呢，也说了，Web服务的话，就是一组网络上的应用程序组件，

这样的话，您便可以通过在您的应用程序中使用 Web 服务来将您的应用程序提升到服务层面上来。

既然可以看做是一组服务了的话，那么当然就是可以提供给别个（别的应用程序）使用咯。

比如，我可以通过 Web 服务来公开一些接口给别个使用，至于这些要不要收费呢？那就看我心情了，前面举了腾讯 QQ 上查询天气的例子，这个例子呢，就可以在这里来做一个解释了，

在中国，应该只有一个卫星来进行天气预报的吧？腾讯也不可能为了天气预报而专门放个卫星上天吧？

可是腾讯 QQ 又确实是可以查询天气的，这里，便可以通过 Web 服务来解决。

首先，中国气象局应该是有一个卫星的，气象局根据卫星所返回的结果实时发布全国各地的天气状况，并且将这些天气信息以 Web 服务的形式公开，然后呢，腾讯 QQ 便可以通过这个 Web 服务来访问到天气状况了，再将这些天气状况反馈到 QQ 上就 OK 了。

然后，上面提到了 Web服务是应用程序组件，既然是组件，那么就可以对这个组件重复的进行使用了，

同时可以通过 Web 服务来实现将这个应用程序组件作为一个服务来进行使用，

更为强大的是，可以将多个 WebServices组合成为更为强大的 WebServices ，

并且是通过互联网哦！！！

这也是一大优点啊，

然后呢，最基本的 WebServices是基于 XML 和 HTTP 的

（当然这是最基本的 WebServices ，比如 WebServices 还可以通过 HTTPS 或者是 SMTP 来实现通信），

这又有什么好处呢？很明显，XML 和HTTP 这些都已经是标准了，

不论你是 Java 平台呢，还是 . Net 平台开发出来的（或者是是使用 Web 服务），既然我是使用 XML 和 HTTP 的话，我才懒得鸟你什么 Java 还是 . Net 呢，我也不管你是 Linux 还是 Windows ，这一切都和我 Web 服务无关，

我关注的只是通过 HTTP 协议来传输 XML 就 OK 了，

至于这些 XML 是如何被服务提供者开发出来的或者这些 XML 是如何被服务请求者使用的，这些都和我无关，这里便可以看出 Web 服务的另一个优势了，那就是跨语言跨平台（实现协同工作），所以可以通过 Web 服务来实现不同应用程序和不同平台之间的通信。

Web 服务允许独立于实现服务基于的硬件或者是软件平台和编写服务所用的编程语言使用服务，

根据上面这两点呢，

便可以解决掉最开始提出的使用 Java 开发的应用程序如何和使用 . Net 开发的应用程序之间进行通信这一问题，

同时，也可以解决 Linux 或者是UNIX 和 Windows Server 2008 之间进行连接这一问题了。

最后就是通过使用不同的 Web 服务，也不管 Web 服务是那种编程语言实现的，

我们都可以从不同的平台和操作系统进行访问，从而大大提高了不同应用程序共享数据和应用的能力。

并且 Web服务提供了构建 SOA 所必须得技术基础。

从上面可以看出通过 WebServices解决了我们曾经想都不敢想的问题，这么强大的东西为什么不加以好好利用呢？

           

          

           

WebServices体系结构



在Web 服务的体系结构中，涉及到三个角色，

一个是 Web 服务提供者，一个是 Web 服务中介者，还有一个就是 Web 服务请求者，

同时还涉及到三类动作，即发布，查找，绑定，

Web 服务提供者：

可以发布 Web 服务，并且对使用自身服务的请求进行响应，

Web 服务的拥有者，它会等待其他的服务或者是应用程序访问自己。

Web 服务请求者：

也就是 Web 服务功能的使用者，它通过服务注册中心也就是 Web 服务中介者查找到所需要的服务，

再利用 SOAP 消息向 Web 服务提供者发送请求以获得服务。

Web 服务中介者：

也称为服务代理，用来注册已经发布的 Web服务提供者，并对其进行分类，同时提供搜索服务，

简单来说的话，Web 服务中介者的作用就是把一个 Web 服务请求者和合适的 Web 服务提供者联系在一起，

充当一个管理者的角色，一般是通过 UDDI来实现。

发布：

通过发布操作，可以使 Web服务提供者向 Web 服务中介者注册自己的功能以及访问的接口。

发现（查找）：

使得 Web 服务请求者可以通过 Web 服务中介者来查找到特点的种类的 Web 服务。

绑定：

这里就是实现让服务请求者能够使用服务提供者提供的服务了。

            

          

          

WebServices三种基本元素之 SOAP

SOAP 即 Simple Object AccessProtocol 也就是简单对象访问协议。

SOAP 呢，其指导理念是“唯一一个没有发明任何新技术的技术”，

是一种用于访问 Web 服务的协议。

因为 SOAP 基于XML 和 HTTP ，其通过XML 来实现消息描述，然后再通过 HTTP 实现消息传输。

SOAP 是用于在应用程序之间进行通信的一种通信协议。

因为是基于 XML 和HTTP 的，所以其独立于语言，独立于平台，并且因为 XML 的扩展性很好，

所以基于 XML 的 SOAP 自然扩展性也不差。

通过 SOAP 可以非常方便的解决互联网中消息互联互通的需求，

其和其他的 Web 服务协议构建起 SOA 应用的技术基础。

SOAP 协议的一个重要特点是它独立于底层传输机制，Web 服务应用程序可以根据需要选择自己的数据传输协议，

可以在发送消息时来确定相应传输机制。

由于 HTTP 协议本身的一些特点和局限性，

使得当 SOAP 使用HTTP 绑定的 Web 服务并不能满足某些企业应用的需求。

比如，HTTP 不是一个可靠传输协议，所以有可能在传输过程中出现问题，

然后 HTTP 协议基于Request/Response 模型，也就是说客户端需要在等待响应消息接收完成后才能继续执行，

而此时如果响应时间过长呢？

基于上面的这些需求，便需要选择合适的传输协议了。

关于这方面的内容的话，有点深奥了，有兴趣的可以去看看 IBM 的一些关于这方面内容的介绍。

还有一点需要提及一下，那就是 SOAP 是可以绕过防火墙的，将来将会作为 W3C 的标准进行发展。

            

          

          

WebServices三种基本元素之 WSDL

WSDL 即Web Services Description Language也就是 Web 服务描述语言。

是基于 XML的用于描述 Web 服务以及如何访问 Web 服务的语言。

服务提供者通过服务描述将所有用于访问 Web服务的规范传送给服务请求者，

要实现 Web服务体系结构的松散耦合，服务描述是一个关键，

不管是请求者还是服务提供者，通过服务描述便可以不必了解对方的底层平台，编程语言等，

服务描述与底层的 SOAP 基础结构相结合，

足以封装服务请求者的应用程序和服务提供者的 Web服务之间的这个细节。

WSDL 描述了
Web服务的三个基本属性：

（1）服务所提供的操作

（2）如何访问服务

（3）服务位于何处（通过 URL 来确定就 OK 了）

        

       

    

WebServices三种基本元素之 UDDI

UDDI 即 Universal Description，Discovery and Integration，也就是通用的描述，发现以及整合。

WSDL 呢，用来描述了访问特定的 Web 服务的一些相关的信息，可以在互联网上，

或者是在企业的不同部门之间，如何来发现我们所需要的 Web 服务呢？

而 Web 服务提供商又如何将自己开发的 Web 服务公布到因特网上，

这就需要使用到 UDDI 了，UDDI的话，是一个跨产业，跨平台的开放性架构，

可以帮助 Web 服务提供商在互联网上发布 Web 服务的信息。

UDDI 呢是一种目录服务，企业可以通过 UDDI 来注册和搜索 Web 服务。

简单来时候话，UDDI 就是一个目录，只不过在这个目录中存放的是一些关于 Web 服务的信息而已。

并且 UDDI 通过SOAP 进行通讯，构建于 . Net 之上。

        

           

开发 Web服务的方式

（1）开发阶段：

        实现一个 Web 服务，使这个 Web 服务能响应和接收 SOAP 消息，

      （这个呢，其实可以通过 Visual Studio 来帮助实现），

       定义好逻辑模块（这个 Web 服务总要干点事情吧），

       然后再撰写 WSDL 文件（这个呢，开发工具会自动生成的，不需要人工撰写了）

（2）部署阶段：

       指定 Web 服务的传输协议，将 Web 服务注册到相应服务描述部署文件（这些也是可以由工具来自动完成的）

（3）发布阶段：

       将 Web 服务的接口和调用的地址公开给客户端调用，

       常用的发布方式为基于 Web 提供的WSDL 的链接，当然 UDDI 也是一个选择。

         

          

     

总结一下 WebServices的优点

其实呢，前面介绍的都是关于 WebServices 的优点，在这里就只是浅要的总结一下了。

首先，WebServices 是基于 Internet 和异构平台的应用，

这样便可以方便的实现通过网络来通信，同时可以实现在不同的平台之间共享数据。

然后就是，WebServices 是基于 XML 和HTTP 的，

也就是基于标准和开放的，基于 XML 的话，扩展性自然好，自然跨语言。

基于 HTTP 的话，自然跨平台了。

最后，再回忆一下 WebServices 是一种应用程序组件吧，这样便可以将 WebServices 重复使用了。

      谈谈 WebServices 的缺点

首先就是由于 XML 文件的难以解析，所以在使用 Web 服务的时候，会消耗较多的 CPU 和内存资源，

而后，SOAP 是基于XML 的，所以在网络传输中传输的是 XML 文件，

但是由 XML 文件相比于二进制文件来说，要大很多，自然就会消耗更多的网络资源了。

而后，由于通过 WSDL 解耦了Web 服务提供者和请求者，且 SOAP 消息时从发送者向接收者单向传送的，

这在一定程度上造成了 WebServices 是一种无状态服务，

尽管现在在 . Net 中可以通过 Session 来实现在客户端和服务端共享一些数据，

但是单单依靠 Session 来实现客户端和服务端的状态交互也太牵强了吧

WebServices 在数据绑定上也存在一些缺陷，

因为所有的数据在传输中都是使用的 XML 来实现的，

因此，需要在二进制数据和 XML 之间进行一个转换（通过序列化和反序列化来实现），

而在转换过程中有可能出现语义丢失的情况。

最后就是 WebServices 的技术要求相对比较高，

因为涉及到底层的 HTTP 协议以及SOAP ，WSDL 和UDDL 这三大平台元素，

所以学习的曲线也是比较长的，

当然，在 . Net 中可以通过 Visual Studio 非常快速和简单的开发和访问一个 Web 服务，

但这只限于在简单的使用上，而对于本质的东西，是比较难的。