首页 > 代码库 > 设计模式之代理模式(Proxy Pattern)_远程代理解析
设计模式之代理模式(Proxy Pattern)_远程代理解析
一.什么是代理模式?
顾名思义,代理就是第三方,比如明星的经纪人,明星的事务都交给经纪人来处理,明星只要告诉经纪人去做什么,经纪人自然会想办法去做,做完之后再把结果告诉明星就好了
本来是调用者与被调用者之间的直接交互,现在把调用者与被调用者分离开,由代理负责传递信息来完成调用
二.代理模式有什么用?
代理模式是一个很大的模式,所以应用很广泛,从代理的种类就能看出来了:
远程代理:最经典的代理模式之一,远程代理负责与远程JVM通信,以实现本地调用者与远程被调用者之间的正常交互
虚拟代理:用来代替巨大对象,确保它在需要的时候才被创建
保护代理:给被调用者提供访问控制,确认调用者的权限
此外还有防火墙代理,智能引用代理,缓存代理,同步代理,复杂隐藏代理,写入时复制代理等等,都有各自特殊的用途
P.S.远程代理是最基础的代理模式,有必要单独拿出来说说,所以本文对其作以详细解释,其余代理会在补充的博文中详述
三.远程代理
有些事情不用代理也能轻松解决,但有些事情必须得依靠代理来完成,比如要调用另一台机器上的一个方法,我们可能就不得不用代理
远程代理的内部机制是这样的:
解释一下,Stub是“桩”也有人称之为“存根”,代表了Server对象
Skeleton是“骨架”(不知道为什么叫“桩”和“骨架”,当然,也没必要知道),代表了Client
Stub明明在客户那边,为什么不是客户的代理而是服务的代理?因为客户是要与服务器交互,现在服务在远程JVM中,无法交互,所以用Stub来代表Server,调用Stub就等同于调用Server(内部通信机制对Client透明,对Client来说,调用Stub和直接调用Server没什么区别,而这正是代理模式的优点之一)
具体流程是这样的:
- Client向Stub发送方法调用请求(Client以为Stub就是Server)
- Stub接到请求,通过Socket与服务端的Skeleton通信,把调用请求传递给Skeleton
- Skeleton接到请求,调用本地Server(听起来有点奇怪,这里Server相当于Service)
- Server作出对应动作,把结果返回给调用者Skeleton
- Skeleton接到结果之后通过Socket发送给Stub
- Stub把结果传递给Client
P.S.第2步与第5步都需要通过Socket通信,相互传递的东西都必须在发送前序列化,接收后反序列化,这也就解释了为什么Server中的public方法返回值都必须是可序列化的
四.远程代理的实现
有两种方式可以实现远程代理:
- 自定义Stub与Skeleton(实现其内部通信)
- 利用Java支持的RMI(Remote Method Invocation)来实现,可以省去很多麻烦,但不容易弄明白内部原理
首先给出自定义方式的例子,有一篇关于这个的博文很不错,就擅自记录下了链接,点我跳转>>
原文给出了一个完整的例子,因此这里不再赘述,给原文补充一个伪类图,方便理解:
(不要问我类图为什么这么画,说了是“伪”类图。。)
仔细看看原文的话不难理解远程代理,Stub和Skeleton负责通信,类似于用Socket编写的聊天程序,除此之外没什么特别的
-------
下面给出利用Java支持的RMI来实现代理模式,能够明显的感受到隐藏了很多细节
首先要定义远程接口:
package ProxyPattern;import java.rmi.RemoteException;/** * 定义服务接口(扩展自java.rmi.Remote接口) * @author ayqy */public interface Service extends java.rmi.Remote{ /* 1.方法返回类型必须是可序列化的Serializable * 2.每一个方法都要声明异常throws RemoteException(因为是RMI方式) * */ /** * @return 完整的问候语句 * @throws RemoteException */ public String greet(String name) throws RemoteException;}
注意:服务接口中public方法的返回类型必须是可序列化的(换言之,自定义的返回类型必须实现Serializable接口),而String类型已经实现了Serializable接口
为什么要定义这样一个扩展自java.rmi.Remote的接口?API文档中给出了清晰的解释:
The Remote
interface serves to identify interfaces whose methods may be invoked from a non-local virtual machine. Any object that is a remote object must directly or indirectly implement this interface. Only those methods specified in a "remote interface", an interface that extends java.rmi.Remote
are available remotely.
说白了就是为了告诉编译器:我们的Service对象可以被远程调用,仅此而已
-------
定义好了远程接口,当然还需要一个具体实现:
package ProxyPattern;import java.rmi.RemoteException;import java.rmi.server.UnicastRemoteObject;/** * 实现远程服务(扩展自UnicastRemoteObject并实现自定义远程接口) * @author ayqy */public class MyService extends UnicastRemoteObject implements Service{ /** * 用来校验程序版本(接收端在反序列化是会验证UID,不符则引发异常) */ private static final long serialVersionUID = 1L; /** * 空的构造方法,只是为了声明异常(默认的构造方法不会声明异常) * @throws RemoteException */ protected MyService() throws RemoteException { } @Override public String greet(String name) throws RemoteException { return "Hey, " + name; }}
P.S.服务继承UnicastRemoteObject类是为了自动生成Stub类(UnicastRemoteObject封装了具体生成细节,我们省去了一个类的工作量)
-------
服务端有了服务还不够,我们需要一个Server帮助我们启动RMI注册服务,并注册远程对象,供客户端调用:
package ProxyPattern;import java.net.MalformedURLException;import java.rmi.Naming;import java.rmi.RemoteException;import java.rmi.registry.LocateRegistry;/** * 实现服务器类,负责开启服务并注册服务对象 * @author ayqy */public class Server { public static void main(String[] args){ try { //启动RMI注册服务,指定端口为1099 (1099为默认端口) LocateRegistry.createRegistry(1099); //创建服务对象 MyService service = new MyService(); //把service注册到RMI注册服务器上,命名为MyService Naming.rebind("MyService", service); } catch (RemoteException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (MalformedURLException e) { // TODO Auto-generated catch block e.printStackTrace(); } }}
注意,除了使用LocateRegistry.createRegistry()方式开启服务外,还可以用命令行方式开启(rmiregistry命令),效果一样
服务端代码到这里就完成了,就像Socket聊天程序一样,我们需要写两部分代码,Server与Client
-------
下面开始做客户端的实现,非常简单,就像一个测试类:
package ProxyPattern;/* 参考资料: * 1.JAVA RMI怎么用 * http://blog.csdn.net/afterrain/article/details/1819659 * 2.RMI内部原理 * http://www.cnblogs.com/yin-jingyu/archive/2012/06/14/2549361.html * */import java.rmi.Naming;/** * 实现客户类 * @author ayqy */public class Client { /** * 查找远程对象并调用远程方法 */ public static void main(String[] argv) { try { //如果要从另一台启动了RMI注册服务的机器上查找MyService对象,修改IP地址即可 Service service = (Service) Naming.lookup("//127.0.0.1:1099/MyService"); //调用远程方法 System.out.println(service.greet("SmileStone")); } catch (Exception e) { System.out.println("Client exception: " + e); } }}
P.S.我们直接用Naming.lookup()来获取Stub对象(没错,是Stub,真正的对象还在另一台机器上呢,当然拿不到,这里得到的只是Service的Stub代理),再调用代理的方法获取结果
注意这个细节:
//如果要从另一台启动了RMI注册服务的机器上查找MyService对象,修改IP地址即可Service service = (Service) Naming.lookup("//127.0.0.1:1099/MyService");
虽然只是一句话,但隐藏了两个细节:
- 客户端必须知道服务接口Service,这里由于是在本地同一个package下,所以不用关心,在真正应用中Client与Server是分离的,所以Client需要拿到一份Service接口的Copy,否则无法调用
- 客户端必须知道服务器的IP和端口号(通信嘛,没有这个可不行)
-------
忙活了半天了,看看运行结果(先运行Server,再运行Client):
P.S.利用Java支持的RMI来实现远程代理部分,参考的资料是别人的一篇博文,里面解释的更详细一些
P.S.至于命令行方式启动RMI注册服务,太麻烦了,而且需要先生成Stub类,不建议用这种方式,具体操作细节,上面的链接博文中也有详细介绍,不再赘述
注意:直到我们亲眼看到测试结果为止,始终没有自定义Stub与Skeleton类,不是吗?对,没错,它们确实存在,只是被RMI隐藏起来了(据说Java1.5之后RMI中没有了Skeleton,甚至更高的版本中连Stub都没有了。。不过这都没关系,我们已经清楚了最原始的远程代理)
五.总结
回过头去想一想远程代理做了些什么:
- 拦截并控制方法调用(这也是代理模式最大的特点,最典型的,防火墙代理。。)
- 远程对象的存在对客户是透明的(客户完全把Stub代理对象当做远程对象了,虽然客户有点好奇为什么可能会出现异常。。)
- 远程代理隐藏了通信细节
当我们需要调用另一台机器(JVM)上指定对象的方法时,使用远程代理是一个不错的选择。。
设计模式之代理模式(Proxy Pattern)_远程代理解析