今天完成的事情：

1  Java 1.4原生rmi demo

黄色是service端需要的文件，红色是client端需的文件，也就是说在client端需要用Person接口，这里直接生成了PersonStub对象。

2  Java 1.5之后 代理对象

黄色是service端，红色是client端需要的文件，client端同样需要demo的接口来生成代理对象。

3  spring rmi demo

同样的黄色是service端需要接口和实现类，然后注册rmi服务，spring直接注册到ioc容器中

红色是client同样需要接口，来生成代理对象。

4  分离原项目

service端：也就是service层、Dao层、bean层、utils

web(client)端：也就是controller层、jsp页面(view层)、utils

具体代码不贴了

贴下注册服务的bean

要对应起来。

成功运行

5  随机访问两台service的问题

service端好解决：配两个不同端口就可以，client(web)端是个问题

看师兄的日报，看到两种解决方法：

在一个client中的spring配置文件中，一次性添加两个端口的service，也就是spring容器加载时，按上面三个rmi service的例子，直接注册6个service的代理对象，然后在controller中AutoAire两次，调用时，用try catch

第2种：写两个 spring 配置文件，每次都重新读取容器

http://www.jnshu.com/daily/49447?dailyType=others&total=84&page=1&uid=14237&sort=0&orderBy=3

这两种方法根本不能用到生产环境中，个人用，实现也不太优雅

延伸：

不引入其他包，写一个拦截器或aop，如果超过规定时间某个service没有响应，认为service挂掉，然后使用spring容器的refresh方法，重新加载。

使用ZooKeeper来注册服务

使用dubbo框架

我也没想到什么好招，关键的一点是这个service是spring容器初始化的时候生成的代理对象，后面抛出错误，如何捕获，然后重新加载？

明天计划的事情：

完成任务8，开始任务9

遇到的问题：

序列化失败

在rmi接口之间传递的数据需要序列话之后才能传递：

这里调用了 /user/login/status 的controller

userServiceImpl是用spring rmi生成的代理对象，所以真正执行时，要把user对象的数据传递给RMI service，所以，这个user类也要可以序列化。

不要在service层和controller层之间传递HttpServletRequest 和HttpServletResponse ，因为这些对象也没有impl序列化接口，无法序列化，会传递失败。

而且从分层的思想来说，也不要传递Request和Response

收获：

不要来回传递Request和Response 把层次搞复杂