經過上篇
分析分布式服務框架的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！