基于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！
今天是 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！