經(jīng)過上篇
分析分布式服務(wù)框架的blog后，正式對之前的基于OSGi實現(xiàn)分布式服務(wù)框架的系列改名(順便把分布式服務(wù)框架改為使用DSF縮寫)，因為已經(jīng)決定基于Spring-DM來實現(xiàn)，為什么呢，而且為什么一定要是Spring-DM，而不直接說Spring呢？
今天是
Spring-DM 1.0 release的大好日子，
，不容易呀，做了這么久，具體怎么樣還沒來得及細看，不過之前有用過1.0 m2，已經(jīng)覺得很不錯了，相信1.0 release更不會失望。
在我眼里看來，Spring是個很大的東西，其實DSF需要的基礎(chǔ)的東西并不多，但又希望保持微核性和擴展性，插件化、具備良好擴展支持的框架無疑是最佳的選擇，OSGi無疑是個好的選擇，但基于OSGi要自己去實現(xiàn)的東西實在是太多了，Spring-DM則是能滿足我以上兩點需求的最佳選擇，既有了插件化的框架，又有了很多可用而且是很強大的東西，尤其是Spring在本地調(diào)用和遠程調(diào)用的透明化提供了優(yōu)秀的設(shè)計支持和指導(dǎo)，例如Spring提供的HessianServiceExporter、JNDIObjectFactoryBean等等，而且Spring和OSGi結(jié)合后，就可以根據(jù)需求來選擇自己所需的Spring的那些增強功能了，不用每次都抱著整個巨大的Spring，當然，目前Spring還沒完全剝離好，等Spring-DM 1.1后會好很多。
在之前的
分析分布式服務(wù)框架的blog中，已經(jīng)說到其實實現(xiàn)DSF簡明扼要的說就是：高效的存儲、查找策略+高效的通訊策略+滿足需求的服務(wù)模型+強大的集成能力，其實這里面最重要的呢，又是強大的集成能力，為什么呢，因為呢，前兩個關(guān)鍵點都是有挺多的可選方案的，需要根據(jù)系統(tǒng)運行的情況來做出不同的選擇，這個時候就要求DSF具備很好的集成能力，使得可以很方便的進行不同實現(xiàn)方案的切換，這點Spring已經(jīng)向世人證明了很多次了，鑒于這些原因Spring-DM榮幸的入選成為DSF的選擇。
來看看基于之前的那篇
分析分布式服務(wù)框架的blog以及選擇了Spring-DM后，DSF變成什么樣了：
是不是覺得和之前的DSF的圖有很多的不同的地方，至于為什么會變成這樣，可以去看看
分析分布式服務(wù)框架的blog，不在此細說，在此會詳細的介紹下目前DSF第一個版本V 0.7，也就是上圖中的每個部分：
先全局的說下，仍然是分為服務(wù)應(yīng)用端和服務(wù)中心，但是從圖中可以看出，服務(wù)查找和調(diào)用的機制和以前的有所不同，在DSF中服務(wù)僅把其元信息直接在服務(wù)中心進行注冊， 此元信息會由服務(wù)中心寫入分布式的緩存DB：MemcacheDB中，當服務(wù)應(yīng)用端進行服務(wù)調(diào)用時，它將直接訪問MemcacheDB來查找到目標服務(wù)的訪問機制，然后直接和目標服務(wù)應(yīng)用端進行通訊，而不經(jīng)過服務(wù)中心路由，這里要稍微說下為什么采用MemcacheDB，其實就是解決DSF中所說的高效的存儲、查找機制，當然，里面其實還有個細節(jié)，就是cluster的考慮，可以想想，如果目標服務(wù)的元信息是直接緩存在服務(wù)應(yīng)用端的話，那么當目標服務(wù)元信息發(fā)生改變時，那通知起來是件非常麻煩的事，所以干脆找個支持cluster持久和高效緩存的東西，還好有了MemcacheDB，當然，其實你也可以根據(jù)你所面對的應(yīng)用的實際需求來定，例如，你的目標服務(wù)壓根就不可能存在元信息變化的現(xiàn)象，那完全可以直接把目標服務(wù)的元信息緩存到服務(wù)應(yīng)用端(甚至這步可以在部署期直接完成)，這些等DSF做到后期版本后，可以考慮機制調(diào)整的支持，但在V 0.7中將會采用圖示的方案。
經(jīng)過機制的改變后，服務(wù)中心就變得非常簡單了，而且壓力是非常的小，它將來更多的需要承擔(dān)服務(wù)的管理和監(jiān)控的職責(zé)，逐步的會壓力增大，這里就不去過多的講它了，還是來看看服務(wù)應(yīng)用端，其實也就是V 0.7需要干的活了：
1、服務(wù)查找
這個服務(wù)查找就是負責(zé)和MemcacheDB通訊的了，根據(jù)服務(wù)模型進行服務(wù)的過濾查找，只是要考慮以后切換為其他查找方式(如基于分布式文件系統(tǒng)、服務(wù)查找后本地緩存等)的支持，由于是基于Spring-DM的，不會有什么問題。
2、發(fā)布服務(wù)
參考Spring的ServiceExporter來實現(xiàn)，在V 0.7中，暫時只提供jndi的方式，jndi server采用jboss jnp，而以Hessian、Webservice的方式發(fā)布，都是Spring直接就支持的，:)，只是當服務(wù)應(yīng)用端不是采用Spring實現(xiàn)時，需要做個集成策略的實現(xiàn)。
3、調(diào)用服務(wù)
參考Spring的ObjectFactoryBean實現(xiàn)，由于V 0.7只有JNDI、Hessian方式，Spring已經(jīng)分別提供了JNDIObjectFactoryBean和HessianProxyFactoryBean，所以這塊暫時不用去考慮了。
在后續(xù)版本中這塊需要在緩存等方面多加考慮。
4、和服務(wù)應(yīng)用端的集成
在V 0.7中暫時假設(shè)服務(wù)應(yīng)用端也是基于Spring的，所以就暫時不考慮集成的問題了。
OK，到此為止，剩下的兩個工作就是：
1、服務(wù)元信息模型
服務(wù)元信息模型完全參考OSGi Service。
在V 0.7中將只支持xml方式描述服務(wù)元信息模型的注冊，這里需要完成的就是將xml解析為元信息模型。
2、服務(wù)管理端
V 0.7僅提供服務(wù)列表的查看、服務(wù)注冊、元信息修改以及卸載。
V 0.7需要做的就是把DSF的架子搭好，保證好基于DSF的Scable的可行性，當然，其實service本身也是要考慮Scable的(如service操作的資源等)才行，在后續(xù)0.7-->1.0的過程中將會從細節(jié)加以改進，如支持更多的通訊協(xié)議、支持更多種服務(wù)應(yīng)用端的集成、提高性能等。
Let's move toward V 0.7！