几种远程监控通信方式的介绍

一 .RPC

RPC 使用 C/S 方式，采用 http 协议，发送请求到服务器，等待服务器返回结果。这个请求包括一个参数集和一个文本集，通常形成“classname.methodname”形式。优点是跨语言跨平台，C 端、S 端有更大的独立性，缺点是不支持对象，无法在编译器检查错误，只能在运行期检查。

二 .Web Service

Web Service 提供的服务是基于 web 容器的，底层使用 http 协议，类似一个远程的服务提供者，比如天气预报服务，对各地客户端提供天气预报，是一种请求应答的机制，是跨系统跨平台的。就是通过一个 servlet，提供服务出去。

首先客户端从服务器的到 WebService 的 WSDL（网络服务描述语言），同时在客户端声称一个代理类（Proxy Class） 这个代理类负责与 WebService 服务器进行 Request 和 Response 当一个数据（XML 格式的）被封装成 SOAP 格式的数据流发送到服务器端的时候，就会生成一个进程对象并且把接收到这个 Request 的 SOAP 包进行解析，然后对事物进行处理，处理结束以后再对这个计算结果进行 SOAP 包装，然后把这个包作为一个 Response 发送给客户端的代理类（Proxy Class），同样地，这个代理类也对这个 SOAP 包进行解析处理，继而进行后续操作。这就是 WebService 的一个运行过程。

Web Service 大体上分为 5 个层次：

1. Http 传输信道

2. XML 的数据格式

3. SOAP 封装格式（soap 用来描述传递信息的格式）

4. WSDL 的描述方式

5. UDDI UDDI 是一种目录服务，企业可以使用它对 Webservices 进行注册和搜索

三 .RMI（Remote Method Invocation）

RMI 采用 stubs 和 skeletons 来进行远程对象（remote object）的通讯。stub 充当远程对象的客户端代理，有着和远程对象相同的远程接口，远程对象的调用实际是通过调用该对象的客户端代理对象 stub 来完成的，通过该机制 RMI 就好比它是本地工作，采用 tcp/ip 协议，客户端直接调用服务端上的一些方法。优点是强类型，编译期可检查错误，缺点是只能基于 Java 语言，客户机与服务器紧耦合。

来看下基于 RMI 的一次完整的远程通信过程的原理：1. 客户端发起请求，请求转交至 RMI 客户端的 stub 类；

2. stub 类将请求的接口、方法、参数等信息进行序列化；

3. 基于 socket 将序列化后的流传输至服务器端；

4. 服务器端接收到流后转发至相应的 skelton 类；

5. skelton 类将请求的信息反序列化后调用实际的处理类；

6. 处理类处理完毕后将结果返回给 skelton 类；

7. Skelton 类将结果序列化，通过 socket 将流传送给客户端的 stub；

8. stub 在接收到流后反序列化，将反序列化后的 java Object 返回给调用者。

四 .JMS（Java Messaging Service）

JMS 是 Java 的消息服务，JMS 的客户端之间可以通过 JMS 服务进行异步的消息传输。JMS 支持两种消息模型：Point-to-Point（P2P）和 Publish/Subscribe（Pub/Sub），即点对点和发布订阅模型。

JMS 呢，是实现 java 领域远程通信的一种手段和方法，基于 JMS 实现远程通信时和 RPC 是不同的，虽然可以做到 RPC 的效果，但因为不是从协议 级别定义的，因此我们不认为 JMS 是个 RPC 协议，但它确实是个远程通信协议，在其他的语言体系中也存在着类似 JMS 的东西，可以统一的将这类机制称为消 息机制，而消息机制呢，通常是高并发、分布式领域推荐的一种通信机制，这里的主要一个问题是容错。

来看 JMS 中的一次远程通信的过程：

1. 客户端将请求转化为符合 JMS 规定的 Message；

2. 通过 JMS API 将 Message 放入 JMS Queue（点对点）或 Topic（发布 / 订阅）中；

3. 如为 JMS Queue，则发送中相应的目标 Queue 中，如为 Topic，则发送给订阅了此 Topic 的 JMS Queue。

4. 处理端则通过轮训 JMS Queue，来获取消息，接收到消息后根据 JMS 协议来解析 Message 并处理。

几种远程监控方式的比较

一、RPC 与 RMI

（1）RPC 跨语言，而 RMI 只支持 Java。

（2）RMI 调用远程对象方法，允许方法返回 Java 对象以及基本数据类型，而 RPC 不支持对象的概念，传送到 RPC 服务的消息由外部数据表示 （External Data RepresentaTIon，XDR） 语言表示，这种语言抽象了字节序类和数据类型结构之间的差异。只有由 XDR 定义的数据类型才能被传递， 可以说 RMI 是面向对象方式的 java RPC 。

（3）在方法调用上，RMI 中，远程接口使每个远程方法都具有方法签名。如果一个方法在服务器上执行，但是没有相匹配的签名被添加到这个远程接口上，那么这个新方法就不能被 RMI 客户方所调用。在 RPC 中，当一个请求到达 RPC 服务器时，这个请求就包含了一个参数集和一个文本值，通常形成“classname.methodname”的形式。这就向 RPC 服务器表明，被请求的方法在为 “classname”的类中，名叫“methodname”。然后 RPC 服务器就去搜索与之相匹配的类和方法，并把它作为那种方法参数类型的输入。这里的参数类型是与 RPC 请求中的类型是匹配的。一旦匹配成功，这个方法就被调用了，其结果被编码后返回客户方。

二、JMS 和 RMI

采用 JMS 服务，对象是在物理上被异步从网络的某个 JVM 上直接移动到另一个 JVM 上（是消息通知机制）

而 RMI 对象是绑定在本地 JVM 中，只有函数参数和返回值是通过网络传送的（是请求应答机制）。

RMI 一般都是同步的，也就是说，当 client 调用 Server 的一个方法的时候，需要等到对方的返回，才能继续执行 client 端，这个过程调用本地方法感觉上是一样的，这也是 RMI 的一个特点。

JMS 一般只是一个点发出一个 Message 到 Message Server，发出之后一般不会关心谁用了这个 message。

所以，一般 RMI 的应用是紧耦合，JMS 的应用相对来说是松散耦合应用。

三、Webservice 与 RMI

RMI 是在 tcp 协议上传递可序列化的 java 对象，只能用在 java 虚拟机上，绑定语言，客户端和服务端都必须是 java

webservice 没有这个限制，webservice 是在 http 协议上传递 xml 文本文件，与语言和平台无关

四、Webservice 与 JMS

Webservice 专注于远程服务调用，jms 专注于信息交换。

大多数情况下 Webservice 是两系统间的直接交互（Consumer 《--》 Producer），而大多数情况下 jms 是三方系统交互（Consumer 《- Broker -》 Producer）。当然，JMS 也可以实现 request-response 模式的通信，只要 Consumer 或 Producer 其中一方兼任 broker 即可。

JMS 可以做到异步调用完全隔离了客户端和服务提供者，能够抵御流量洪峰； WebService 服务通常为同步调用，需要有复杂的对象转换，相比 SOAP，现在 JSON，rest 都是很好的 http 架构方案；（举一个例子，电子商务的分布式系统中，有支付系统和业务系统，支付系统负责用户付款，在用户在银行付款后需要通知各个业务系统，那么这个时候，既可以用同步也可以用异步，使用异步的好处就能抵御网站暂时的流量高峰，或者能应对慢消费者。）

JMS 是 java 平台上的消息规范。一般 jms 消息不是一个 xml，而是一个 java 对象，很明显，jms 没考虑异构系统，说白了，JMS 就没考虑非 java 的东西。但是好在现在大多数的 jms provider（就是 JMS 的各种实现产品）都解决了异构问题。相比 WebService 的跨平台各有千秋吧。