基于Spring-DM实现分布式服务框架(DSF)(一)

经过上篇分析分布式服务框架的blog后,正式对之前的基于OSGi实现分布式服务框架的系列改名(顺便把分布式服务框架改为使用DSF缩写),因为已经决定基于Spring-DM来实现,为什么呢,而且为什么一定要是Spring-DM,而不直接说Spring呢?
今天是Spring-DM 1.0 release的大好日子,,不容易呀,做了这么久,具体怎么样还没来得及细看,不过之前有用过1.0 m2,已经觉得很不错了,相信1.0 release更不会失望。
在我眼里看来,Spring是个很大的东西,其实DSF需要的基础的东西并不多,但又希望保持微核性和扩展性,插件化、具备良好扩展支持的框架无疑是最佳的选择,OSGi无疑是个好的选择,但基于OSGi要自己去实现的东西实在是太多了,Spring-DM则是能满足我以上两点需求的最佳选择,既有了插件化的框架,又有了很多可用而且是很强大的东西,尤其是Spring在本地调用和远程调用的透明化提供了优秀的设计支持和指导,例如Spring提供的HessianServiceExporter、JNDIObjectFactoryBean等等,而且Spring和OSGi结合后,就可以根据需求来选择自己所需的Spring的那些增强功能了,不用每次都抱着整个巨大的Spring,当然,目前Spring还没完全剥离好,等Spring-DM 1.1后会好很多。
在之前的分析分布式服务框架的blog中,已经说到其实实现DSF简明扼要的说就是:高效的存储、查找策略+高效的通讯策略+满足需求的服务模型+强大的集成能力,其实这里面最重要的呢,又是强大的集成能力,为什么呢,因为呢,前两个关键点都是有挺多的可选方案的,需要根据系统运行的情况来做出不同的选择,这个时候就要求DSF具备很好的集成能力,使得可以很方便的进行不同实现方案的切换,这点Spring已经向世人证明了很多次了,鉴于这些原因Spring-DM荣幸的入选成为DSF的选择。 
来看看基于之前的那篇分析分布式服务框架的blog以及选择了Spring-DM后,DSF变成什么样了:

是不是觉得和之前的DSF的图有很多的不同的地方,至于为什么会变成这样,可以去看看分析分布式服务框架的blog,不在此细说,在此会详细的介绍下目前DSF第一个版本V 0.7,也就是上图中的每个部分:
先全局的说下,仍然是分为服务应用端和服务中心,但是从图中可以看出,服务查找和调用的机制和以前的有所不同,在DSF中服务仅把其元信息直接在服务中心进行注册, 此元信息会由服务中心写入分布式的缓存DB:MemcacheDB中,当服务应用端进行服务调用时,它将直接访问MemcacheDB来查找到目标服务的访问机制,然后直接和目标服务应用端进行通讯,而不经过服务中心路由,这里要稍微说下为什么采用MemcacheDB,其实就是解决DSF中所说的高效的存储、查找机制,当然,里面其实还有个细节,就是cluster的考虑,可以想想,如果目标服务的元信息是直接缓存在服务应用端的话,那么当目标服务元信息发生改变时,那通知起来是件非常麻烦的事,所以干脆找个支持cluster持久和高效缓存的东西,还好有了MemcacheDB,当然,其实你也可以根据你所面对的应用的实际需求来定,例如,你的目标服务压根就不可能存在元信息变化的现象,那完全可以直接把目标服务的元信息缓存到服务应用端(甚至这步可以在部署期直接完成),这些等DSF做到后期版本后,可以考虑机制调整的支持,但在V 0.7中将会采用图示的方案。
经过机制的改变后,服务中心就变得非常简单了,而且压力是非常的小,它将来更多的需要承担服务的管理和监控的职责,逐步的会压力增大,这里就不去过多的讲它了,还是来看看服务应用端,其实也就是V 0.7需要干的活了:
1、服务查找
      这个服务查找就是负责和MemcacheDB通讯的了,根据服务模型进行服务的过滤查找,只是要考虑以后切换为其他查找方式(如基于分布式文件系统、服务查找后本地缓存等)的支持,由于是基于Spring-DM的,不会有什么问题。
2、发布服务
      参考Spring的ServiceExporter来实现,在V 0.7中,暂时只提供jndi的方式,jndi server采用jboss jnp,而以Hessian、Webservice的方式发布,都是Spring直接就支持的,:),只是当服务应用端不是采用Spring实现时,需要做个集成策略的实现。
3、调用服务
      参考Spring的ObjectFactoryBean实现,由于V 0.7只有JNDI、Hessian方式,Spring已经分别提供了JNDIObjectFactoryBean和HessianProxyFactoryBean,所以这块暂时不用去考虑了。
      在后续版本中这块需要在缓存等方面多加考虑。
4、和服务应用端的集成
      在V 0.7中暂时假设服务应用端也是基于Spring的,所以就暂时不考虑集成的问题了。
OK,到此为止,剩下的两个工作就是:
1、服务元信息模型
      服务元信息模型完全参考OSGi Service。
      在V 0.7中将只支持xml方式描述服务元信息模型的注册,这里需要完成的就是将xml解析为元信息模型。
2、服务管理端
      V 0.7仅提供服务列表的查看、服务注册、元信息修改以及卸载。
V 0.7需要做的就是把DSF的架子搭好,保证好基于DSF的Scable的可行性,当然,其实service本身也是要考虑Scable的(如service操作的资源等)才行,在后续0.7-->1.0的过程中将会从细节加以改进,如支持更多的通讯协议、支持更多种服务应用端的集成、提高性能等。
Let's move toward V 0.7!

posted on 2008-01-26 23:45 BlueDavy 阅读(10364) 评论(4)  编辑  收藏 所属分类: OSGi、SOA、SCA

评论

# re: 基于Spring-DM实现分布式服务框架(DSF)(一) 2008-04-14 17:03 赵斌

BlueDavy,你好:

最近正在研究关于“服务框架”的内容,看了你的系列文章,很受启发。上周还和银狐999就“服务框架”的内容一起进行了研究。我对比了基于标准自己设计和SCA两条路线,岑文出正在实施SCA路线,在Tuscany上进行了大量改造,我打算走自己设计的路线。

首先一个问题是,你考虑了以自己的方式来实现服务注册和服务查找,为什么不用UDDI呢?我这两天翻了不少UDDI的资料,感觉UDDI是一个很完整的的体系,从服务的元数据的设计,访问UDDI的Java的API,UDDI本身的SOAP支持,都表现出UDDI是一个更标准、更开放、更完整的体系。当然,UDDI也有缺点,就是太过完整了,太麻烦,不如自己设计服务的元数据,弄张表一存那么简单,但带来的问题是如何访问?总不能要求所有访问你的服务库的程序都使用你规定的私有API吧?个人觉得UDDI是个方向。

另一个问题是,为什么要把服务发布在JNDI上?从客户端访问WebService时,只需要知道WSDL就可以了,也就是知道WSDL的URL就可以了,这个WSDL的URL字符串存储在哪里好像不重要。

另外,昨天我用CXF做了一些Demo程序,打算用CXF来作为服务发布和调用的实现机制,感觉还是比较方便的,因为CXF本身就是Open Source Service Framework。我再把注册、查询、管理等整合进来就可以了。



期待你的回复,谢谢。



赵斌

  回复  更多评论   

# re: 基于Spring-DM实现分布式服务框架(DSF)(一) 2008-04-14 18:20 BlueDavy

@赵斌
首先,我们面对的需求场景并不同,呵呵,这里讲的不是一个通用层面的分布式服务框架,就像你说的,这里就是要求所有访问服务的都必须通过此分布式服务框架,只是这个分布式服务框架会提供一定的集成性,例如你可以在spring中直接访问,可以在ejb中直接访问等...而你强调的是服务的通用性,也就是说客户端完全可以不用你的框架就实现调用,所以自然要符合一定的标准。
第二点,为什么要把服务发在JNDI上,因为在这个分布式服务框架中,压根就不会支持webservice,所以...不过这块确实可以调整,有别的更好的办法可以去实现。
:),总而言之,我们面对的应用场景不同,所以自然设计的方向也是会有所不同的。  回复  更多评论   

# re: 基于Spring-DM实现分布式服务框架(DSF)(一) 2008-04-15 15:23 赵斌

答复收到,非常感谢。

我再研究研究,有了思路后会贴上来,再请你指正。

再次感谢。  回复  更多评论   

# re: 基于Spring-DM实现分布式服务框架(DSF)(一) 2008-04-16 13:20 BlueDavy

@赵斌
:),多交流,这样吧,你私下发封邮件给我,我们MSN交流好了。
  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 

公告

 









feedsky
抓虾
google reader
鲜果

导航

<2008年1月>
303112345
6789101112
13141516171819
20212223242526
272829303112
3456789

统计

随笔分类

随笔档案

文章档案

Blogger's

搜索

最新评论

阅读排行榜

评论排行榜