基于OSGi实现分布式服务框架历程(二)

基于OSGi实现分布式服务框架历程(二)

在这篇历程中来完成对于JINI的Spike，目标仍然是判断基于JINI实现服务的路由、查找需求的满足度。
JINI是由Sun研究院制定的，其目标就是为了实现分布式的服务，所以在很多地方可以看到它和分布式服务框架是有不少重叠之处的，来先看看它对于需求的满足度，最后再来分析做个总结。
1、怎么实现远程的将服务注册到服务中心？
      在jini中暂时没有找到远程注册服务到服务中心的方法。
      jini的服务需要和服务中心部署在同一台机器上，这个倒是可以通过服务管理中心直接将sar格式的服务部署上去，支持服务的动态管理，不过这是不符合分布式服务框架的需求的。
2、在服务应用端怎么查找服务中心的服务？
      在服务的查找上，Jini采用的方法估计是和JNDI差不多的，不过相对来讲要求就比JNDI高一些，因为它需要依赖它自己的serviceContext才能获取到服务，这点不是很好。
3、有否现成可用的实现？
      目前Jini的实现有好几个，最出名的当然是sun自己的Jini Starter Kit，但对于实现分布式服务框架的话，Newton是个更好的参考。
4、是否支持Cluster？
      由于服务和服务中心是在同一台机器，因此不存在是不是支持Cluster的问题，大不了部署的时候整个cluster中的所有机器都部署一次。
5、可参考的资源有哪些？
      jini可参考的资源主要就是：www.jini.org，通过这里可以找到挺多的jini的资料，比较好的有：
      http://blogs.sun.com/warren/entry/jini_made_easier_writing_a
      http://www.cheiron.org/seven/manual/html/developer/index.html
      http://jan.newmarch.name/java/jini/tutorial/Jini.xml
从服务的注册、查找和路由这三个需求去看，jini能直接满足的就只有查找了，因为我们需要的仅仅是一个注册、路由、查找的机制的框架，而不需要别的附加功能，jini就显得有点和这个需求不是很贴合了，尤其是jini本身就是个功能并不强的服务框架，如果采用它的话会导致还需要进行改造，剥离它的服务那块的机制或者做兼容，而且jini在使用时对于jini本身包的依赖性太强，这对于我们期待的pojo机制而言就挺麻烦了，当然，jini并不是毫无优点，如果大家去看看jini实现框架的那个可视化的服务的监控端，那实在是个很不错的东西，具体了完整的服务生命周期管理（安装、卸载、启动、停止以及目前的运行状态等）的功能。
jndi的简单性和对于需求的贴合性使得它成为了我们用于实现基于OSGi的分布式服务框架的选择。
在选择了jndi作为服务的注册、查找和路由机制后，我们需要逐步的演进基于OSGi的分布式服务框架的设计，在后续的篇章中我们将停留下spike过程，来分析下目前此分布式服务框架的状况。

<< 基于OSGi实现分布式服务框架历程(一)

>> 基于OSGi实现分布式服务框架历程(三)