隨筆 - 59, 文章 - 4, 評(píng)論 - 184, 引用 - 7

          導(dǎo)航

          <2005年11月>
          303112345
          6789101112
          13141516171819
          20212223242526
          27282930123
          45678910

          公告

          除非特別說明,所有文章均為本blog作者原創(chuàng),如需轉(zhuǎn)載請(qǐng)注明出處和原作者,如用于商業(yè)目的,需跟作者本人聯(lián)系。

          加入我的交際圈:


          常用鏈接

          我參與的團(tuán)隊(duì)

          隨筆分類(55)

          隨筆檔案(59)

          blog友人

          積分與排名

          • 積分 - 149526
          • 排名 - 417

          最新評(píng)論

          閱讀排行榜

          【ESB專題】之三 - Message Construction及其相關(guān)模式


          在前面的關(guān)鍵組件中我們提到了Messages。當(dāng)兩個(gè)應(yīng)用想要交換數(shù)據(jù),他們將數(shù)據(jù)包裝在一個(gè)message中。但是一個(gè)Message Channel不能傳輸原始數(shù)據(jù),它只能傳輸包含在一個(gè)message中的數(shù)據(jù)(即傳輸特定格式的數(shù)據(jù))。

           

          Message在消息系統(tǒng)中處于信息載體的位置,而在ESB中,還消息識(shí)別、序列以及生存周期等職責(zé)。

           

          Message的結(jié)構(gòu)涉及以下幾個(gè)模式:

          l         Command Message      

          l         Document Message      

          l         Event Message

          l         Request-Reply

          l         Return Address

          l         Correlation Identifier

          l         Message Sequence

          l         Message Expiration

          l         Format Indicator

           

          創(chuàng)建和發(fā)送一個(gè)Message產(chǎn)生以下幾個(gè)問題:

           

          消息意圖 Message最終是為了運(yùn)送一些數(shù)據(jù),但是發(fā)送者可能有其他目的,比如它希望接受者使用消息做些事情。它可以發(fā)送一個(gè)Command Message,指定它希望調(diào)用的接受者上的函數(shù)或方法。發(fā)送者告訴接受者運(yùn)行那些代碼。發(fā)送者可以發(fā)送一個(gè)Document Message來傳送它的數(shù)據(jù)結(jié)構(gòu)到接受者。發(fā)送者發(fā)送數(shù)據(jù)到接受者,但是不指定接受者應(yīng)該做什么。

          或者它可以發(fā)送一個(gè)Event Message,通知接受者發(fā)送者那里有一個(gè)改變。發(fā)送者不應(yīng)告訴接受者應(yīng)該怎樣適應(yīng)這個(gè)改變,而只應(yīng)提供通知。

           

          返回一個(gè)應(yīng)答 當(dāng)一個(gè)應(yīng)用發(fā)送一個(gè)消息,它通常期望得到一個(gè)回應(yīng)來確定消息被處理并提供一個(gè)結(jié)果。這是一個(gè)Request-Reply場(chǎng)景。Request通常是一個(gè)Command Message,而應(yīng)答是一個(gè)包含返回值或異常的Document Message。請(qǐng)求者應(yīng)該在請(qǐng)求中指定一個(gè)Return Address來告訴應(yīng)答者使用哪個(gè)通道來傳回應(yīng)答。請(qǐng)求者可能在一個(gè)處理過程中發(fā)送多個(gè)請(qǐng)求,所以應(yīng)答應(yīng)該包含一個(gè)Correlation Identifier來指出這個(gè)應(yīng)答對(duì)應(yīng)哪個(gè)請(qǐng)求。

          有兩個(gè)Request-Reply場(chǎng)景需要注意;它們都包含了一個(gè)Command Message請(qǐng)求和一個(gè)對(duì)應(yīng)的Document Message應(yīng)答。在第一個(gè)場(chǎng)景中,Message RPC,請(qǐng)求不但要調(diào)用應(yīng)答者的函數(shù),而且期望一個(gè)返回值。這是RPC。另一個(gè)場(chǎng)景中,Message Query,請(qǐng)求者執(zhí)行一個(gè)查詢;應(yīng)答者執(zhí)行查詢并在應(yīng)答中返回結(jié)果。這是遠(yuǎn)程查詢。

           

          大量的數(shù)據(jù) 有時(shí)應(yīng)用想要傳送大量的數(shù)據(jù)結(jié)構(gòu),放入一個(gè)單獨(dú)的message里面不是很合適。在這種情況下,將他們分解成可管理的消息塊并將他們作為Message Sequence發(fā)送。這些消息必須按順序發(fā)送,以便接受者能夠充足原始數(shù)據(jù)結(jié)構(gòu)。

           

          慢速消息 消息系統(tǒng)的一個(gè)問題是發(fā)送者通常不知道接受者要多久才能接受到消息。然而,消息的內(nèi)容可能是時(shí)間敏感的,所以如果消息在某一時(shí)間內(nèi)沒有被接受,它將被忽略并取消。在這種情況下,sender應(yīng)該使用Message Expiration來指定一個(gè)到期時(shí)間。如果消息系統(tǒng)在規(guī)定時(shí)間內(nèi)無法傳輸一個(gè)消息,應(yīng)該將它取消并刪除到Dead Letter Channel中。同樣的一個(gè)receiver接受到一個(gè)超出該時(shí)間點(diǎn)的消息,也要取消該消息。

           

          總之,只選擇使用消息是不夠的。使一個(gè)消息工作的其他決定性因素來自于消息所要完成的任務(wù)。

           

          posted on 2005-11-19 20:31 fisher 閱讀(1418) 評(píng)論(6)  編輯  收藏 所屬分類: Programing

          評(píng)論

          # 【ESB專題】之三 - Message Construction及其相關(guān)模式 [TrackBack]  回復(fù)  更多評(píng)論   

          當(dāng)兩個(gè)應(yīng)用想要交換數(shù)據(jù),他們將數(shù)據(jù)包裝在一個(gè)message中。但是一個(gè)Message Channel不能傳輸原始數(shù)據(jù),它只能傳輸包含在一個(gè)message中的數(shù)據(jù)(即傳輸特定格式的數(shù)據(jù))。

          [引用提示]fisher on csdn 引用了該文章, 地址: http://blog.csdn.net/flyingbug/archive/2005/11/19/533102.aspx
          2005-11-19 20:39 | fisher on csdn

          # re: 【ESB專題】之三 - Message Construction及其相關(guān)模式  回復(fù)  更多評(píng)論   

          好文,我也正想研究EAI平臺(tái),其中ESB則是EAI平臺(tái)的核心,期待你的后文,
          另:能否多講一些有關(guān)IBM MQ的消息中間件,在大型企業(yè)應(yīng)用中,往往都采用的是MQ渠道,畢境簡(jiǎn)單的基于SOAP連接的WEB SERVICE擁有先天缺陷---無法共享連接.
          2005-11-21 11:23 | langds

          # re: 【ESB專題】之三 - Message Construction及其相關(guān)模式  回復(fù)  更多評(píng)論   

          呵呵,沒用過MQ,所以沒辦法寫關(guān)于MQ的內(nèi)容了
          我想SOAP的好處是基于XML的標(biāo)準(zhǔn)提供了互通的平臺(tái),并且它在消息轉(zhuǎn)換、元數(shù)據(jù)交換以及安全方面都提供了標(biāo)準(zhǔn)的做法,我認(rèn)為SOAP是一個(gè)很有前途的集成手段
          SOAP的缺陷是由Http協(xié)議的基于請(qǐng)求的、無狀態(tài)的特性決定的,這也沒辦法
          但是可以通過一些設(shè)計(jì)模式來適當(dāng)?shù)母淖冞@種狀態(tài),比如使用Cache
          或硬性的保持一個(gè)通知連接等機(jī)制
          2005-11-21 21:55 | fisher

          # re: 【ESB專題】之三 - Message Construction及其相關(guān)模式  回復(fù)  更多評(píng)論   

          是的,不論怎么樣,在SOA應(yīng)用架構(gòu)下,基于SOAP協(xié)議的交互的確是相當(dāng)重要的,因此才出現(xiàn)了面向消息的SOA實(shí)現(xiàn),這就會(huì)在ESB里的消息通迅模式里解決.而IBM的MQ則是比較好的方案了
          2005-11-22 10:04 | langds

          # re: 【ESB專題】之三 - Message Construction及其相關(guān)模式  回復(fù)  更多評(píng)論   

          呵呵,我個(gè)人感覺Message Queue并非什么神奇的技術(shù),而且也不是普遍適用的技術(shù)
          其實(shí)真正通用的整合標(biāo)準(zhǔn)就只有兩個(gè):Http和Socket
          SOAP是Http上的技術(shù),Socket則是十年前的整合標(biāo)準(zhǔn)
          無論使用哪一種都一樣

          基于Socket的整合的中間件我都是自己寫的,所以我沒有用過MQ
          只要通訊基礎(chǔ)框架寫的好,支持什么樣協(xié)議我想都不是大問題^_^
          2005-11-22 10:12 | fisher

          # re: 【ESB專題】之三 - Message Construction及其相關(guān)模式  回復(fù)  更多評(píng)論   

          MQ還是很好用的,值得研究一下。高率,穩(wěn)定,事務(wù)保證,簡(jiǎn)單的開發(fā)接口,優(yōu)點(diǎn)不少,
          2007-03-09 16:03 | linan
          主站蜘蛛池模板: 玛纳斯县| 新蔡县| 青铜峡市| 洪洞县| 库伦旗| 澳门| 黄平县| 贺州市| 读书| 白城市| 丽江市| 神池县| 右玉县| 盘山县| 白山市| 宣化县| 班玛县| 乐都县| 荔浦县| 五指山市| 望谟县| 哈密市| 古丈县| 台安县| 札达县| 武宣县| 方山县| 蓬溪县| 香河县| 建水县| 平和县| 德阳市| 慈溪市| 沅陵县| 西畴县| 平定县| 嘉荫县| 射阳县| 五指山市| 海丰县| 汕尾市|