在这篇历程中来完成对于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实现分布式服务框架历程(三)