这几天一直在考虑分布式计算的问题，因为之前写过一个IoC框架，所以打算对原来的框架进行扩展，做成一个分布式的容器，该容器的设计目标是：由多个子容器构成一个大的分布式容器，用户不需要知道Bean存在于哪一个容器中，只需知道Bean的ID即可进行调用，对用户来讲，远程容器中的Bean和本地的Bean是没有区别的，容器是非侵入式的，不需要继承任何类或者实现接口。
      最初考虑到比较简单，觉得容器解决的只是容器间的通信问题，我设想的是用户请求远程容器中的Bean时，在本地生成目标接口的一个动态代理，该动态代理通过把参数对象序列化（或者其他方式）后保存在一个调用请求中，然后把调用请求传递给远程容器，远程容器接收到请求后调用容器中的Bean，把返回结果对象序列化后保存在一个调用响应中，然后把调用响应返回给本地容器，由动态代理对象处理后返回。
      真正开始设计之后才发现很多细节问题没有考虑到，比如远程容器中Bean的生存周期（非单例状态的情况下），本地容器中的动态代理对象成为垃圾之后如果保证远程容器中的Bean被回收。我设想的分布式是通过容器间的引用来配置的，比如，容器A引用容器B，那么A可以透明的调用B中的Bean，从简化配置和设计的角度来考虑，如果A引用了B，B又引用了C，应该让A也能够调用C才对，也就是说应该具有传递性，但是很可能存在的情况是容器间存在循环引用，这时如果用户请求了一个不存在的Bean，就会出现死循环的情况。还有容器必须把结果返回给正确的调用者，还有多线程等问题……
      突然想到《非诚勿扰》里的一句台词：老说改进服务质量，怎么改进啊？其实就是细节。