設計理念: 1. 資訊單位在對資訊源界接資訊後,往往因為各種原因需要2份以上的同源資訊作為使用 2. 資訊源通常以Account與專線來限制使用及強化品質,因此同源資訊會因為授權數量而成本增加且頻寬不足亦須增加成本擴充頻寬 3. 資訊源的通訊技術普遍不佳,系統也不穩,因此在界接應用的過程中會造成許多設計上的負擔 4. 如同物流需求產生運輸業,因此資料流當然也要有對應的優秀傳輸架構來承接 5. 如同運送雞蛋如果保護不夠平穩會有破損,如果保鮮設計不佳運輸又沒效率則會產生臭蛋,資料傳輸也是需要一樣的穩定與效率及保證完整 6. 如果以上諸項都深入您心坎,一定能了解RawData資訊架構是如何的不可或缺,不但於成本上充分節約,更能產生無價的客戶信賴與依賴 7. 不論是交易還是行情,是生技還是醫療,對系統而言都是資訊沒有差別,只要有資訊同步上效率穩定及正確完整的需求皆合適於本架構設計與規劃 架構特點:
B. 資訊源為TCP Socket的架構方式 可參閱 TcpRDS1. 傳輸採加密壓縮,兼具私密性與安全性,並支援SSL模式可透過Proxy建立連線 2. 以即時為主,壓縮為輔,資料傳遞速度遠優於其他系統 3. 使用頻寬省,視承載資訊內容與資料量,以台灣期貨交易所之資料為例,使用頻寬為原始資料的一半(約47%) 4. 高效能低負載,採用高效先進的程式技術,可執行模組皆小於100KB,頂多百多K,對PC等級要求甚低 5. 穩定度高,不像其他系統常常掛掉或每天要關掉重開,還怪你的PC不夠好 6. Packet化的設計方式,不用浪費功夫在處理Stream的切割處理動作,可見API範例程式 7. IP架構方式,各程式間可分可合,視實際頻寬與負載或需求可作各種變化調整與對應 8. 不論哪一種資訊源,架構皆完全相同,資訊處理方式也都一樣 9. 另可搭配提供RDGS為可註冊選擇資訊的服務程式,RDTS則涵蓋註冊與系統資料架構之資料回補機制 10. 透過RDGS與RDTS可建構成各種簡繁之資料路由架構系統,可進行分流/分析/處理/合流之各種組合(當今之雲端概念) 11. 使用WTFC API,可供資訊接收端開發即時資訊再應用之相關程式 12. 此架構為最基礎之應用,只要有接於下圖中所示的資訊源,皆能直接使用此平台上的程式與模組 應用實例: 1. 台灣期貨交易所 2. ComStock資訊應用 3. 國際金融資訊應用 A. 資訊源為Multicast的架構方式 可參閱 URDS (適用範圍: TSE/2, OTC/2, TFE, Systex F1, CME-SBE, CME-FAST, 任意Multicast)  (適用範圍: Abula MPX, ComStock RTU/DataHub, Shanghai Gaoying DS, Systex IX, SSE/SZSE VDE STEP/FAST, Kway MDS/OBGateway)  C. 資訊源為DDE Server的架構方式 可參閱 DdeRDS (適用範圍: XQ|Quote, DynQuote|IX, EXCEL, 任何符合前述DDE規格的DDE Server資訊來源) 架構完全同A.與B. 只是Converter的部分由 DdeRDS 程式所取代 D. 可立即可取代原架構服務舊有的現行AP   (一) RDGS-TFE (Raw-Data Gateway Server for TFE) 中間三格Report檢視窗口,可以用來檢視Client註冊的情形, 由左至右依序為 Format Report, Handle Report, Symbol Report Format Report 可了解各種資料格式分別有幾個Client註冊 Symbol Report 可了解各種商品分別有幾個Client註冊 雙擊 Format Report 或 Symbol Report, 則由 Handle Report 顯示哪些Client註冊了所點擊的項目 (二) RDTS-TFE (Raw-Data Terminal Service for TFE) 新增此程式是為之後進一步的開發, 此程式涵蓋RDGS-TFE功能,用法則相同, 但是已增加了Current Status Kernel (程式於記憶體中的資料處理與記憶的核心,爾後縮寫CurStatus) 中間三格Report檢視窗口則改用來檢視CurStatus的資料, 由左至右依序為 Symbol Report, Order Report(I080), Trade Report(I020) Symbol Report 可檢視所有程式執行後收到過的所有商品PROD-ID 雙擊 Symbol Report 則可由 Order Report 與 Trade Report 中檢視點擊項目的所有欄位資料(如尚未收到任何資訊則為空白) 而記憶的資料為依之前註冊電文格式中的需求欄位而設立, 這可用來與AP對報價也能提供之後的應用程式回補商品的最後報價資訊 (或於註冊同時進行回補, 當然要先設定電文格式, 回補與即時的資料是必須有所區分的), 目前程式可經由其上方的輸入窗口中輸入 Save 按[Enter] 將資料存檔供參考, 檔名分別為 TFE_I020.dbx 和 TFE_I080.dbx 檔案格式是遵守DBF檔的定義處理,但檔案資料內容為交易所BCD Raw-Data Format (無法用EXCEL開啟) DBF定義以下Tag I020 1000 : PROD-ID
(INFORMATION-TIME對報價結果而言並無存在意義,所以未保存)1001 : MatchTime 1002 : PQ_Trade" 1003 : MatchTotalQty 1004 : MatchBuyCnt 1005 : MatchSellCnt I080 1000 : PROD-ID
(PQ_ 是指 Price/Quantity)1101 : PQ_Buy1 1102 : PQ_Buy2 1103 : PQ_Buy3 1104 : PQ_Buy4 1105 : PQ_Buy5 1201 : PQ_Sell1 1202 : PQ_Sell2 1203 : PQ_Sell3 1204 : PQ_Sell4 1205 : PQ_Sell5 當然所有Tag都可以依需求重新定義, 一般下單後台應是對FIX相當熟悉,所以也可依現有使用的FIX欄位作依據設定Tag 這樣也可以便於以後與其他系統的配合, 而DBF檔還會有更多的衍生應用, 最主要是可以運用Data Cell Systems(DES)的DbfTS快速建立架構佈局, 這邊則先不贅述 |
資訊系統/架構/產品 > 架構範例 >