没人比我更懂RMI(上)
前言
每篇鸡汤:
万事开头难,当走出第一步你会发现,其实事情并没有你想象的那么糟糕
文章可能稍微有点长,一定要耐心看完 o.0
RMI概念
本来想把官方对RMI的概念贴在开头的,突然想了想开头就整臭长臭长的文字,谁顶得住。其实总的来说用一句话就可以概括。
——RMI就是负责远程调用对象的。
既然提到了远程调用对象,肯定不是调用自己本地的对象。先给大家举个生活中的例子渗透一下概念:
比如你在北京上学,你女神在西安,并且你想通过发送信息给女神告白。
你想告白,得通过手机发送信息(相当于调用远程方法;但是调用方法之前会先创建
Stub(sun.rmi.registry.RegistryImpl_Stub)
)这个stub
就相当于你的手机;也就是说,你并不能直接面对面告诉女神,而手机只是你传递信息的一种媒介,相当于是一个代理。然后你给女神里发了个信息,在你刚呼出的一瞬间,手机会将你的呼出信号交给三大运营商(相当于
stub
会将Remote
对象传递给远程引用层(java.rmi.server.RemoteRef)
并创建java.rmi.server.RemoteCall(远程调用)
对象。)三大运营商会帮你找到你的女神。运营商在收到你的信号后会将你这个呼出的动作转换成其他形式的信号进行传输(
RemoteCall
序列化RMI服务名称
、Remote
对象。)然后运营商通过自己架设的线路进行通信(
RMI客户端
的远程引用层
传输RemoteCall
序列化后的请求信息通过Socket
连接的方式传输到RMI服务端
的远程引用层
。)在找到对方之后,对方手机会立刻响铃(
RMI服务端
的远程引用层(sun.rmi.server.UnicastServerRef)
收到请求会请求传递给Skeleton(sun.rmi.registry.RegistryImpl_Skel#dispatch)
;这个Skeleton
就相当于女神的手机)此时对方手机会将之前用其他形式传输的信号,转变为人能看懂的文字(
Skeleton
调用RemoteCall
反序列化RMI客户端
传过来的序列化。)对方查看手机(Skeleton)信息,并用手机给你进行回复:“你是个好人”(
Skeleton
处理客户端请求:bind
、list
、lookup
、rebind
、unbind
,如果是lookup
则查找RMI服务名
绑定的接口对象,序列化该对象并通过RemoteCall
传输到客户端。)你收到信息,并看到是女神给你的回复,非常激动!(
RMI客户端
反序列化服务端结果,获取远程对象的引用)你双击信息打开进一步查看内容(
RMI客户端
调用远程方法,RMI服务端
反射调用RMI服务实现类
的对应方法并序列化执行结果返回给客户端。)结果看到女神送给你的“好人卡”(
RMI客户端
反序列化RMI
远程方法调用结果。)
在代码实现之前我们还需要明白一个在RMI中扮演着重要角色的”注册中心“,他在服务端创建。
我们知道java远程对象是基于socket来进行传输的,有socket就要有端口。
举个例子:
服务端现在有一个名为A的远程对象。现在你是客户端,你并不知道服务端把这个A开放在对应的哪个端口。就算你知道了A的开放端口。服务其上还有B、C、D……..难道你要记住每个远程对象的端口吗?很明显这是不现实的。
那么这个时候,就要用到我们的注册中心。他的作用就是将自己绑定在服务端的某个端口(默认1099)这样你只需要记住一个端口,他会帮我们记住这100个远程对象对应的开放端口。当客户端进行调用的时候,只需要告诉注册中心,我要找A,那么注册中心就会告诉你A所对应的端口。有点像交换机和路由器的原理。
在了解这个重要概念以后,我们再来接着往下看RMI具体是如何实现的。
RMI具体代码实现如下:
服务端代码:
1 |
|
1 |
|
1 |
|
客户端代码:
1 |
|
1 |
|
首先在服务端创建远程对象的时候”IRemoteObj remoteObj = new RemoteObjImpl();
“这一句代码,我们来分析一下他都干了什么
- 因为我们继承了
UnicastRemoteObject()
,所以首先会来到他父类的构造方法处并进行赋值0
。
- 随后会将传入的参数赋值给
port
,相当于给port
传入默认值0,如果传入0后续会将远程对象发布在随机的端口上。
- 这也就是是我们之前代码中如果继承了这个类就不需要再次调用,如果不继承则需要手动调用
- 跟进
UnicastServerRef()
- 在进行跟进
LiveRef()
因为他会调用他的构造方法,所以我们直接看构造方法
第一个参数和最后一个参数很好理解,中间的这个参数是什么呢?我们还需要再次跟进
- 我们可以看到它的返回值是
TCPEndpoint
所以很明显这里是处理网络请求的类。
- 跟进发现,接收两个参数一个
host
一个port
。
- 然后我们跟到
LiveRef
发现他恰好就接收这三个参数,而且从下方参数信息也可以看到它接收到了对应的参数。到这一直是封装封装。而真正处理网络请求的就是TCPTransport
,并最后将的结果放入LiveRef
- 之后会创建代理,细心的同学已经发现了,为什么服务端创建了stub?stub不是客户端的代理吗?
解答:stub是客户端的代理没错,但是客户端是通过stub来进行远程调用的。他整个的流程是先在服务端创建好stub,然后放在注册中心,客户端创建stub,然后去注册中心找对应的server端stub,找到以后再用server端的stub来操作server端Skeletion。
- 之后会创建他的类加载器、接口、调用处理器,而调用处理器里面的值还是之前的
LiveRef
- 可以看到这里已经把stub的端口从之前的初始值
0
变成了随机的端口,发布在注册中心,并记录server端。
这里只是简单的跟一下服务端原创对象的创建过程,让大家清楚的看到,服务端在创建对象的时候,实际上都干了什么。具体细节感兴趣的同学可以自己跟一下。
接下来我们再跟一下创建注册中心Registry r = LocateRegistry.createRegistry(1099);
看看他都干了什么
- 创建注册中心,接收参数端口。
- 跟进,发现底层创建了
LiveRef
和UnicastServerRef
。服务端创建原创对象的时候也是这样的操作。
- 唯一的不同是他创建的这个远程对象是永久的远程对象,而我们之前自定义的远程对象是一个临时的对象。可以看到,后面还是在服务端创建stub给客户端来进行调用。
- 可以看到注册中心创建的stub他是由
froname
创建的,之前创建远程对象的stub实际上是靠动态代理的调用处理器创建的。他们两个的创建方式不一样。
- 之后会将创建好的远程对象放进
table
当中
然后服务端最后一步将远程对象绑定在注册中心这一步比较简单,我们就不跟了。(不是我懒,是今天天气不好,不适合调试)
至此我们把服务端整个RMI的流程简单分析了一遍,现在大家都应该清楚他们每一步到底干了什么。
RMI反序列化
从RMI设计角度来讲,基本分为三层架构模式来实现RMI,分别为RMI服务端,RMI客户端和RMI注册中心,如下图所示。
他们之间可以相互两两通信。由于RMI在网络传输数据是需要对数据进行序列化和反序列化的。那么这个时候我们其实就可以利用他反序列化从而进行利用。
这里先提一嘴,我下一篇文章在出利用吧,主要不是我懒,是我怕文章太长,使得大家阅读枯燥无味。