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