漫谈RPC

        什么是rpc? 注意，这个c是call的意思。rpc就是爱迪生时代，我和你之间要打电话，我们之间要牵一根电话线；你和他之间要打电话，你们之间也要牵一根线，自己要负责铺线和维修。这太麻烦了。
        什么是.net平台和j2ee容器呢? 好比是我买了手机入网，只管用就好了。通信如何发起如何实现，那是平台的事情。tuxedo之类的应用服务器呢? 很可惜，不是和开发与运行平台绑定的，而且是基于自身的通信协议，所以需要繁琐的开发和部署，生产效率太低----如果tuxedo和com服务器是手机的话，就好比你在打电话之前，你要搜索小区里面的频段，确定时间片，建立信道，发送一堆指令和基站联系，成功了以后，按照通信网的字节标准编辑一条短信到消息信道! 这可不是买手机的人想干的事情。而.net开发出来的webService根本就没有这个问题，所有的程序就当是本机的好了，通信的过程根本就不用去管，.net framework运行环境打理好了一切，不再需要一堆代码去连服务器了。中间代码是自描述的，soap服务的xml也是自描述的。.net平台真正做到了网络就是计算机----而提出这个口号的sun，很讽刺的是，更本就没有打算把网络透明搬到计算机上来。开发工具就是语言，就是手机键盘敲字表达我自己的思想，而你的服务具体是如何提供的，这不是我应该关心的吧。有人说，我是高手，我用汇编来写应用服务! 等俺有了钱，俺也这么干一回，但是现在绝对不是。如果一个工具提供者不能让用户集中思想于问题的解决，而是处理和这个工具本身相关的一堆问题，那么这个工具就是糟糕的，所谓大拙若巧，其实还是拙。
        谁应该关注rpc? 不是使用平台的，而是利用rpc来开发一个更高层平台的人。rpc不是用来解决问题的，rpc本身就是一个问题如何解决的问题。简单的说，rpc就是客户端+客户端中间通信层+服务器端通信层+服务器端应用。通信层就是服务器的客户端和服务端，负责通信，和业务的封装打包以及数据的拆包拼接；而不是业务本身。业务本身是部署在服务器上的: 这么看来，似乎所有的DBMS都可以看成上应用服务器了，我写一个C程序连接Oracle，执行一个pl/sql请求，服务器端执行了一个存储过程返回我一个结果，我的C程序里面打印出来。者不就是rpc要做的么。那么所谓的MSIDL，Corba的IDL，等等，只不过是一种另类的sql方言而已，要做的事情是一样的。而一个一个的rpc服务，就是一个个的存储过程，结果的返回依赖服务器的通信模块。当然，rpc关心的不是数据，而是程序。谁知道那一天，现有的这些DBMS会变成通用的应用服务器呢。
        甚至于广义的说，C程序printf("%d",a+b)都算是一个rpc操作: 操作系统是服务端，C程序是客户端，#include就是引入了一个idl文件，a+b是请求了一个cpu的系统调用，返回的结果给C程序，再请求一个系统调用，操作系统输出printf的内容----这个printf不也是一个call? 而所谓的远程存储，云存储，只不过是把电线拉长了，隔了一堵墙，再聘用了一个保安而已，还可以玩更多的花招，商业模式而已。这一切都只不过是同一个概念的不同实现而已，形而上学层面上，意义是相同的。电子计算机的本质，从图灵和诺伊曼时代开始，到现在一点都没有改变过。
        我如果画一个图来表示rpc的调用流程，那么你把图上面的文字擦干净保留那些箭头和方框，再去填上操作系统的运行流程，或者填上cpu的电路运行流程，甚至填上麦当劳的厨师和服务生的交互过程，这个图都是一样有效的。
        想想当年RMS在一台PDP7上面开发自由软件时候: 他需要在另外一台机器上，用交叉编译工具，编译一个PDP能运行的2进制程序，用磁带机导入到PDP上面----这个helloworld程序算法部署成功了。后来PC有了硬盘，那么开发的结果立即产生了"部署"的效应，可以执行了。而现在则是把网络的距离屏蔽掉，让底层的联网功能来网络部署好像就是本地磁盘一样。这些事情之间，真的有多么的不一样么: 当我用手机的时候，我是不需要知道移动的网络究竟是如何铺设的。
        因为程序是自描述的，配置文件，注册表，都是多余的了。com/corba技术的淘汰只是时间问题。
        神只有一个，有人喊上帝，有人喊安拉，有人喊主，而已。