RPC编程：Hessian RPC一个老的RPC框架（一）

一：Hessian RPC

1：Hession RPC一个老的RPC框架

Hessian RPC是一个非常老的RPC框架，2010年以前还是非常棒的。现在没人用的原因是因为它不符合现在新的这些潮流：注册中心，熔断，服务管理等等。但是RPC当中几个核心的内容：网络通讯、协议、序列化、代理是全部包含的。

2：老，为什么还要研究？

纯粹的RPC，只解决了RPC中的上述四个核心问题。
Hessian他的序列化方式在Dubbo还在使用，Dubbo当中的Hession是阿里定制的(Hession Lite) Dubbo默认启动的。

3：Hession RPC概念

1：Resin服务器的伴生产品。
2：一个基于Java语言设计的RPC框架，只支持Java编程语言，也就是服务的调用者和提供者都得是Java开发的服务。这些可不是废话，我们一些新的RPC技术（gRPC，Thrift）支持多种编程语言。
3：序列化协议是二进制的。
4：官网： http://hessian.caucho.com/doc/

二：Hessian RPC设计思想

1：Hession依赖于服务器

Hessian RPC作为Resin服务器的伴生产品。作为服务端来讲，Hessian在运行过程中依赖的就是我们的Tomcat服务器，或者Resin，他因为是Resin的伴生产品，他依赖于我们线程的Web服务器即可。这样的话，就不需要我们处理协议问题，因为服务器本身使用的是Http协议，刚才我们提到了Hessian的协议是二进制的，Http协议也是可以走二进制，在他的请求体中走二进制。我们说是Http协议是文本协议，但是Http协议（消息体）也是可以走二进制的。

2：Hession服务提供者必须为Service定义接口

有了服务器之后，我们服务的提供者我们需要提供服务，也就是我们的Service，也就是我们原来开发的Service。只不过我们使用Hessian进行调用的话，我们的Service必须定义接口（Interface）我们去给他的接口去定义实现类。为什么有这样的要求呢？

3：为什么必须定义接口？

服务调用者，也就是Java客户端的Service，服务的提供者也就是服务端的Service。

我们忽略了一个问题：我们的服务调用者，调用服务的时候，我们必须在服务的调用端必须要做代理，如果我们使用JDK做代理的话，必须要实现相同的接口。从广义的代理上来讲，我们可以使用CgLib的继承关系来做代理，理论上是没有任何问题的，只不过Hessian使用的较早，当时CgLib不是特别流行，导致Hessian内部只使用JDK作为代理。

4：必须使用Serializable接口

本质上，这是定义了序列化方式。

5：服务的发布

A：服务的提供者

服务端如何将服务发布出去，让调用者知道服务端提供了那些服务？Hessian当中可没有注册中心，服务管理这一说。是通过Hession为我们提供的一个Servlet使用的。

我们如何基于Servlet发布一个服务，让调用者可知呢？只需要在web.xml当中进行配置一下就行了。具体内容，在编码中我们会写的。

这里需要注意的是，我们现在的请求的是二进制的，走Http二进制的数据，所以Hession只能走Post请求。

B：服务的调用者

代理的这个事，不需要我们来开发了，Hessian帮我们开发了一个工具类，HessianProxyFactory这个类即可，但是我们需要提供两个要素：具体的Service.class和URL

基于服务提供方的Service.class我们可以做代理，拿到了URL之后，我们可以发送请求。

服务端，我们开发了Service的接口，我们的客户端也得使用服务的接口，所以这个服务的接口需要做成公共模块，也就是Maven当中的Common模块。