广义的远程通讯技术包括：RPC，WebService，RMI，JMS，EJB，JNDI
一、概念解释
RPC：远程过程调用，广义的RPC和与MQ并列属于系统间的交互方式，跨平台，通过http通信，通信的过程相当于http远程传送参数（串行化技术），本质上是一个请求相应模型。特征为隐藏底层通信细节，不需要直接处理Socket通讯和Http通信
- rpc的实现：理论上来说WebService，gRPC，dubbo，微博Motan，thrift都是广义RPC技术的实现。
CORBA：面向对象的编程体系规范，分布式系统，跨语言，对标RMI（竞争关系）。
- CORBA的实现：omniORB，TAO。
SOAP：简单对象访问协议，微软联合厂商对xml-rpc标准化，soap协议就是联合标准化的结果，而且微软抢先完善了soap协议，推出了webservice。对象访问协议指的是使用XML描述web service的信息（URI/类/参数/返回值），理论上SOAP就是一段xml
WebService：属于广义rpc的一种（常见的广义rpc实现还有xml-rpc和json-rpc），支持异构系统间的交互， 支持不同语言的通信，使用http通信，通过serlvet提供XML格式的数据，是SOAP协议的封装，WSDL是它的描述方式。
- 基于SOAP实现WebService：引入JAX-WS规范(java实现soap的一个规范，为了简化基于soap的java开发，使用jax-ws可以让开发者不编写任何生产和处理soap的代码，jax-ws运行时会将api的调用转换为soap的消息)基于jax-ws的开发框架有ApacheAxis2和ApacheCXF（结合spring，是常用框架）
- 基于REST的实现WebService：对应有JAX-RS规范，基于jax-rs的框架有ApacheWink，Jersey，Spring REST
WSDL：webservice描述语言，描述SOAP协议的，也是段XML
RMI：远程调用对象，其实是java实现了RPC的一组接口
- 实现：没有框架，本身就是这种技术的实现
JMS：MQ
EJB：大型分布式，rmi-iiop协议
- 直接对标spring体系：因为EJB是官方指定的标准，各个容器厂商都会不予余力的开发新版本来支持EJB标准，因此符合EJB的规范的容器，一般能适应企业的方方面面，而开源的spring结构体系就是个不统一的标准，你不能将spring+structs的架构迁移到spring+WebWork，更不能轻易将Spring+hibernate迁移到Spring+iBatis，但是因为EJB的标准问题，可以在WebSphere，WebLogic和JBOSS之间切换。因为EJB的过于重量级和难以使用，相当于民间开发了一套技术（spring）来覆盖了官方的EJB所提供的技术。
二、广义RPC发展历程
- 广义RPC的技术发展历程
以下按照时间顺序排序- CORBA
- DCOM，COM+
- JAVA RMI
- .net remoting
- XML-RPC，SOAP，WebService(冗余数据多，处理速度慢)
- Hessian（二进制，官方只提供了java的实现）
- JSON-RPC（没有统一实现）
- Microsoft WCF，WebAPI（微软技术整合）
- ZeroC Ice，Thrift，GRPC
下图为技术发展简图：
下载.png
三、狭义RPC技术框架
由于目前跨内存调用的普遍性,RPC往往代称更加具体的基于底层协议二进制流的RPC框架,与WebService最大的不同就是： 狭义的RPC基于二进制流的序列化和反序列化,故不能够提供跨语言的服务,但是比基于文本解析的WebService更加高效。
狭义RPC框架一般需要高性能的网络框架，如Netty，Mina，高性能的序列化反序列化框架，寻址方式，如果是带会话的RPC，还要有会话和状态保持功能。
当下XML-RPC，SOAP，WebService技术的缺陷：
- 冗余数据太多，处理速度太慢。
- RPC 风格的 Web Service 跨语言性不佳，而 Document 风格的 Web Service 又太过难用。
- Web Service 没有解决用户的真正问题，只是把一个问题变成了另一个问题。
- Web Service 的规范太过复杂，以至于在 .NET 和 Java 平台以外没有真正好用的实现，甚至没有可用的实现。
- 跨语言跨平台只是 Web Service 的一个口号，虽然很多人迷信这一点，但事实上它并没有真正实现。
