<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    笨笨的思想片斷

    零碎片斷,雜七雜八。
    posts - 25, comments - 79, trackbacks - 0, articles - 0

    Java Service Request Broker簡介

    Posted on 2007-12-12 00:15 笨笨 閱讀(2724) 評論(1)  編輯  收藏 所屬分類: Java Service Request Broker

    Java Service Request Broker 簡介

    Java Service Request Broker(JSRB)是一個 Java/C/C++ 的開源項目
    Project URL http://jsrb.sourceforge.net

    項目目標按照優(yōu)先順序依次是:
    1 高效,透明的通訊框架,屏蔽本地/遠程網(wǎng)絡(luò)架構(gòu)的復雜性(高效來源于基于poll/epoll的NIO通訊框架,透明來源于多個JSRB Server之間的動態(tài)級聯(lián)機制).
    2 高效率,穩(wěn)定的服務(wù)請求處理機制(高效來源于服務(wù)端為C語言實現(xiàn),穩(wěn)定來源于對服務(wù)進程的不間斷監(jiān)控和自動重啟動機制)
    3 分布式事務(wù)處理能力(JSRB 作為分布式事務(wù)管理器,初步實現(xiàn)了DTP XA協(xié)議,還在開發(fā)過程中).
    4 客戶端語言中立(語言無關(guān)通訊協(xié)議,客戶端提供Java或C API庫).

    JSRB 大致架構(gòu)如下:



    JSRB SERVICE 特性/訪問方式

    1 SERVICE 無狀態(tài),通過二進制數(shù)據(jù)傳遞輸入輸出數(shù)據(jù)
    2 運行時,可以有多個SERVICE實現(xiàn)進程, JSRB會平衡調(diào)度這些進程.

    SERVICE支持同步/異步兩種訪問方式:
    SERVICE之間也支持forward和嵌套調(diào)用兩種方式

    同步訪問SERVICE:
    Response Data = JsrbConection.syncCall("SERVICE NAME",Request Data);
    當客戶端從syncCall中返回時,它已經(jīng)獲得SERVICE的返回數(shù)據(jù)



    異步訪問SERVICE
    long key = JsrbConnection.asyncCall("SERVICE",Request Data);
    ...
    Response Data = JsrbConnection.fetchReply(key);
    客戶端可以提交服務(wù)請求后,過一段時間再去嘗試獲取數(shù)據(jù), 便衣客戶端同時提交多個服務(wù)請求,增加并發(fā)性.




    SERVICE FORWARD
    客戶端訪問SVC1, SVC1完成后將該請求forward到SVC2, SVC2完成后直接返回客戶端數(shù)據(jù).



    SERVICE的嵌套調(diào)用
    SVC1 調(diào)用SVC2 并獲得SVC2的返回數(shù)據(jù).







    一般問題:
    1 為什么會選擇用Java 實現(xiàn)Service Request Broker
    答: Java跟C語言相比, 代碼執(zhí)行速度其實并不慢. 我們一般感覺J2EE 應用慢,主要是由于IO(特別是socket和JDBC)慢造成的.
    Java 在多線程編程, 開發(fā)的方便性方面比C/C++強.
    JSRB在實現(xiàn)過程中,自行定義和實現(xiàn)了一套NIO框架, 增加了對于Linux epoll(Edge Triggered Mode)的支持, 同時為了實現(xiàn)與C進程的高效通訊,自行實現(xiàn)了Sysv IPC和創(chuàng)建子進程方面的Native代碼.


    2 為什么要用C實現(xiàn)業(yè)務(wù)代碼,作為Service的實現(xiàn)語言.
    從企業(yè)端的應用來看, 企業(yè)應用必定要跟數(shù)據(jù)庫打交道, 實際上C語言訪問數(shù)據(jù)庫要比Java訪問數(shù)據(jù)庫快1到兩個數(shù)量級. 甚至可以說, J2EE應用響應的大部分的延遲時間都耗費在JDBC上.
    從大型項目的實施經(jīng)驗來看, 將這部分代碼放在C進程中, 盡管要多付出通訊方面的代價,總體還是要比純Java的方案快得多.


    3 為什么分布式事務(wù)的優(yōu)先級最低
    從大型項目的實施經(jīng)驗來看, 分布式事務(wù)由于運行代價過高, 業(yè)務(wù)系統(tǒng)中用到的概率很小(基本上直接用數(shù)據(jù)庫的事務(wù)). 對于CICS/TUXEDO應用而言,首先還是將CICS/TUXEDO 作為一個高效/穩(wěn)定的通訊和服務(wù)請求處理排隊框架來用.
    如果真要有分布式的交易的需求,一般采用流水對帳+沖正處理方式解決.


    4 為什么選擇無狀態(tài)方式實現(xiàn)SERVICE
    無狀態(tài)是提高并發(fā)效率, 實現(xiàn)透明故障遷移的最佳方式. Server端資源有限,為并發(fā)的成千上萬個用戶同時維護狀態(tài)是非常困難的,這樣也會造成集群實現(xiàn)的困難.
    由于Client端是有狀態(tài)的,所以這在實現(xiàn)上其實問題不大.



    今后得空還會慢慢寫更多文檔介紹JSRB的一些組件的實現(xiàn)方式和特性.


    Feedback

    # re: Java Service Request Broker簡介[未登錄]  回復  更多評論   

    2008-01-27 06:56 by 哈哈
    想法其實不錯,不過有些說法需要實踐來證明。上來就說“ Java跟C語言相比, 代碼執(zhí)行速度其實并不慢”,“實際上C語言訪問數(shù)據(jù)庫要比Java訪問數(shù)據(jù)庫快1到兩個數(shù)量級”缺乏稅賦力。

    其實我反而覺得j2ee訪問數(shù)據(jù)庫慢不完全因為jdbc,更多的是數(shù)據(jù)庫本身就慢,設(shè)計有問題或者查詢策略有問題。
    還有一個瓶頸就是對象序列化。目前應用最廣的webservice可以說也是最緩慢最消耗資源的,相對的就得到了對各種平臺的良好兼容和支持。
    j2ee應用還有一個大毛病就是太費內(nèi)存,當然換來的是程序的可靠性,平臺無關(guān)性。

    分布式事務(wù)我沒那么多經(jīng)驗,就不發(fā)表太多評論。
    你說的JSRB可能確實不錯,不過我認為還需要再進行論證。至少從閱讀了本文之后還沒真正感覺到太多驚喜。

    我覺得現(xiàn)在的企業(yè)應用大多會吧降低程序和設(shè)計復雜度放在首位。如果這方面做的比較好可能更吸引人。

    "業(yè)務(wù)系統(tǒng)中用到的概覽很小"中的概覽是不是概率?
    主站蜘蛛池模板: 亚洲视频在线免费观看| 国产大片91精品免费观看男同| 亚洲男人av香蕉爽爽爽爽| 亚洲国产精品网站在线播放| 成人免费在线观看网站| 久久久久久久久免费看无码| 亚洲成AV人网址| 在线看亚洲十八禁网站| 免费人成在线观看播放国产| 亚洲国产成人私人影院| 精品国产日韩亚洲一区在线| 国产精品免费电影| 香蕉视频免费在线播放| 久久久久久精品免费看SSS| 777亚洲精品乱码久久久久久 | 国产一区二区视频免费| 亚洲AV无码男人的天堂| 亚洲毛片不卡av在线播放一区| 一级毛片免费在线观看网站| 亚洲熟妇无码另类久久久| 亚洲av永久无码精品网址| 国产精品免费小视频| 国产成人无码精品久久久久免费| 无码中文在线二区免费| 亚洲精品乱码久久久久久中文字幕| 日韩免费高清播放器| 亚洲 另类 无码 在线| 亚洲人成网站色在线观看| 四虎成人免费网址在线| 亚洲字幕在线观看| 嫩草成人永久免费观看| 亚洲福利秒拍一区二区| 国产一区视频在线免费观看| 国内精品免费视频精选在线观看| 亚洲精品午夜视频| 国产一区二区三区免费在线观看| 国产精品免费久久| 激情亚洲一区国产精品| 精品亚洲视频在线观看| 男女超爽刺激视频免费播放| 产传媒61国产免费|