基于Spring-DM實現(xiàn)分布式服務(wù)框架(DSF)(一)

          經(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!

          posted on 2008-01-26 23:45 BlueDavy 閱讀(10720) 評論(4)  編輯  收藏 所屬分類: OSGi、SOA、SCA

          評論

          # re: 基于Spring-DM實現(xiàn)分布式服務(wù)框架(DSF)(一) 2008-04-14 17:03 趙斌

          BlueDavy,你好:

          最近正在研究關(guān)于“服務(wù)框架”的內(nèi)容,看了你的系列文章,很受啟發(fā)。上周還和銀狐999就“服務(wù)框架”的內(nèi)容一起進行了研究。我對比了基于標準自己設(shè)計和SCA兩條路線,岑文出正在實施SCA路線,在Tuscany上進行了大量改造,我打算走自己設(shè)計的路線。

          首先一個問題是,你考慮了以自己的方式來實現(xiàn)服務(wù)注冊和服務(wù)查找,為什么不用UDDI呢?我這兩天翻了不少UDDI的資料,感覺UDDI是一個很完整的的體系,從服務(wù)的元數(shù)據(jù)的設(shè)計,訪問UDDI的Java的API,UDDI本身的SOAP支持,都表現(xiàn)出UDDI是一個更標準、更開放、更完整的體系。當然,UDDI也有缺點,就是太過完整了,太麻煩,不如自己設(shè)計服務(wù)的元數(shù)據(jù),弄張表一存那么簡單,但帶來的問題是如何訪問?總不能要求所有訪問你的服務(wù)庫的程序都使用你規(guī)定的私有API吧?個人覺得UDDI是個方向。

          另一個問題是,為什么要把服務(wù)發(fā)布在JNDI上?從客戶端訪問WebService時,只需要知道WSDL就可以了,也就是知道WSDL的URL就可以了,這個WSDL的URL字符串存儲在哪里好像不重要。

          另外,昨天我用CXF做了一些Demo程序,打算用CXF來作為服務(wù)發(fā)布和調(diào)用的實現(xiàn)機制,感覺還是比較方便的,因為CXF本身就是Open Source Service Framework。我再把注冊、查詢、管理等整合進來就可以了。



          期待你的回復(fù),謝謝。



          趙斌

            回復(fù)  更多評論   

          # re: 基于Spring-DM實現(xiàn)分布式服務(wù)框架(DSF)(一) 2008-04-14 18:20 BlueDavy

          @趙斌
          首先,我們面對的需求場景并不同,呵呵,這里講的不是一個通用層面的分布式服務(wù)框架,就像你說的,這里就是要求所有訪問服務(wù)的都必須通過此分布式服務(wù)框架,只是這個分布式服務(wù)框架會提供一定的集成性,例如你可以在spring中直接訪問,可以在ejb中直接訪問等...而你強調(diào)的是服務(wù)的通用性,也就是說客戶端完全可以不用你的框架就實現(xiàn)調(diào)用,所以自然要符合一定的標準。
          第二點,為什么要把服務(wù)發(fā)在JNDI上,因為在這個分布式服務(wù)框架中,壓根就不會支持webservice,所以...不過這塊確實可以調(diào)整,有別的更好的辦法可以去實現(xiàn)。
          :),總而言之,我們面對的應(yīng)用場景不同,所以自然設(shè)計的方向也是會有所不同的。  回復(fù)  更多評論   

          # re: 基于Spring-DM實現(xiàn)分布式服務(wù)框架(DSF)(一) 2008-04-15 15:23 趙斌

          答復(fù)收到,非常感謝。

          我再研究研究,有了思路后會貼上來,再請你指正。

          再次感謝。  回復(fù)  更多評論   

          # re: 基于Spring-DM實現(xiàn)分布式服務(wù)框架(DSF)(一) 2008-04-16 13:20 BlueDavy

          @趙斌
          :),多交流,這樣吧,你私下發(fā)封郵件給我,我們MSN交流好了。
            回復(fù)  更多評論   

          公告

           









          feedsky
          抓蝦
          google reader
          鮮果

          導(dǎo)航

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

          統(tǒng)計

          隨筆分類

          隨筆檔案

          文章檔案

          Blogger's

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 沽源县| 德令哈市| 新营市| 秀山| 恩平市| 信宜市| 井陉县| 闽侯县| 广宗县| 谢通门县| 临潭县| 祁阳县| 海兴县| 赫章县| 石台县| 原平市| 科尔| 兰考县| 津南区| 益阳市| 宁安市| 皮山县| 嘉义县| 满洲里市| 遂川县| 北安市| 荥阳市| 龙川县| 会泽县| 留坝县| 思茅市| 枝江市| 淮滨县| 凤阳县| 安徽省| 萍乡市| 柳河县| 刚察县| 贵溪市| 佛坪县| 临邑县|