Java Service Request Broker 簡介

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

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

JSRB 大致架構如下:

JSRB SERVICE 特性/訪問方式

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

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

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



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




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



SERVICE的嵌套調用
SVC1 調用SVC2 并獲得SVC2的返回數據.







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


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


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


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



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