QuickFIX即金融信息交換協定，全稱Financial Information exchange，是適用於實時證券、金融電子交易開發的數據通信標準。它是由國際FIX協會組織提供的一個開放式協定。
基本介紹
- 中文名：QuickFIX
- 外文名：QuickFIX
- 類型：協定
- 定義：金融信息交換協定
協定簡介,代碼功能,
協定簡介
它是由國際FIX協會組織提供的一個開放式協定，目的是推動國際貿易電子化的 進程，在各類參與者之間，包括投資經理、經紀人，買方、賣方建立起實時的電子化通訊協定。FIX協定由FIX protocol, Ltd(FPL)所有並維護。FIX 協定的目標是把各類證券金融業務需求流程格式化，使之成為一個個可用計算機語言描述的功能流程，並在每個業務功能接口上統一交換格式，方便各個功能模組的 連線。目前，歐、美主要已開發國家都是FIX協會的成員。
FIX協定在歐美和亞洲地區的套用主要集中在買賣意向、成交揭示、交易定單、執行報告、結算劃撥和市場新聞等信息交換上。
QuickFIX是FIX協定的一個免費實現，包含C++, .NET, Python, Ruby四個版本。
代碼功能
QuickFIX/J 是實現了FIX協定所有版本及其功能的開源軟體，100%使用JAVA實現。
QuickFixJ代碼功能主要有兩大部分，一部分是Fix協定數據的解析，另外一部分是客戶端跟伺服器端建立連線並維持回話，傳輸數據。
QuickFix/J傳輸功能部分
QuickFix/J的連線管理和傳輸功能是基於MINA框架實現的。MINA是Apache旗下的一個網路套用框架，能夠幫助大家輕鬆的開發高性能、高擴展性的網路程式。它使用NIO在傳輸協定（比如TCP/IP，UDP/IP）之上提供了抽象的、事件驅動的、異步處理的API。
網路數據在QuickFix/J中的流向：ConnectTask -> ioConnector.connect(sockAddress, ioHandler) -> MINA建立和伺服器端的通信。收到網路數據，ioConnector觸發相應事件，並把事件交給ioHandler(InitiatorIoHandler)的processMessage -> processMessage中調用eventHandlingStrategy.onMessage(quickfixSession, message) ，將訊息向外回調 -> SingleThreadedEventHandlingStrategy.onMessage(quickfixSession, message) 將收到的訊息入隊(enQueue)到eventQueue -> SingleThreadedEventHandlingStrategy.blockInThread中啟動單獨的後台執行緒，依次從eventQueue取出訊息處理，向session回調 -> SessionMessageEvent.quickfixSession.next(message) -> quickFixSession.next根據msgType判斷回調 ->逐層回調 (verify -> veriry -> fromCallback -> fromAdmin/fromApp)，從fromAdmin/fromApp(msg, sessionID)回調用戶處理邏輯。
客戶化FIX解析
- 在QuickFix/J的設計中，為了解除message factory和相應的協定的解析代碼的耦合關係，quickfix.DefaultMessageFactory會在runtime時使用reflection動態發現解析協定的代碼。因此，如果你有自定義的數據字典，並且已經根據該字典生成了解析該協定的代碼，請別忘記在DefaultMessageFactory中加入相應協定的訊息工廠discoverFactory(beginString, factoryClassName)。
- DefaultMessageFactory有兩個主要功能，一個是創建Message（根據beginString和msgType），另一個是創建Group（根據beginString、msgType和correspondingFieldID）。相應的，根據數據字典生成的解析協定的代碼中，當然有MessageFactory了，而且這個MessageFactory當然會創建Message和Group。
- DefaultMessageFactory創建Message時，首先根據beginString查找相應版本的訊息工廠，找到了則create相應的Message，否則new一個默認的quickfix.Message。
- MessageCracker的用法。當自動生成解析協定的代碼之後，肯定會生成對應版本的MessageCracker。仔細閱讀這個新生成的MessageCracker，你會發現其中有很多的onMessage方法內部沒有實現，並且加入了默認的throw new UnsupportedMessageType();語句。在實際使用中，用戶需要創建自己的Application，並且extends quickfix.MessageCracker implements quickfix.Application。由於Override，這些throw new UnsupportedMessageType自然會被禁止。
如果用戶需要取到Message中的內容，做相應的業務邏輯，首先在用戶的Application.fromApp中crack(message, sessionId)，crack類似message cracker的工廠，它根據message header選擇相應的message cracker，然後回調相應的onMessage。onMessage正好在用戶Application中Override實現。 - 客戶化協定的客戶端Initiator實現總結
a) 創建處理類，extends MessageCracker implements quickfix.Application implements quickfix.ApplicationExtended
b) 在fromApp中添加crack(message, sessionId);
c) 對需要處理的訊息實現相應的onMessage
d) 創建SocketInitiator實例，填入客戶化的application，messageStoreFactory，settings，logFactory，messageFactory。
e) start initiator。 - 如果想把收到的每個訊息單獨存成一個檔案備份，比如dbf之類的，該如何實現？
a) 方案1. 實現自己的MessageStore。QuickFix/J中提供了現成的FileStore，可以將所有的訊息存入同一個檔案中。
b) 方案2. 在Application的fromApp接口中，獲取相應的Message，提取所需要素，存檔。
兩個方案的比較：方案2減少了一次從String到Message的解析，效率應該更高。因為MessageStore的輸入是StringMessage，需要再次解析才能得到Message。 - FIX標準協定中規定了訊息(Message)應該都至少有一個欄位(Field)，如果在客戶化自己的FIX協定解析時，發現某些Message沒有欄位，則需要解除QuickFix/J中對這個條件的限制，具體在quickfix.Dictionary。
- 在QuickFix/J的實現中，關於不同版本的協定都有這樣一個假設，就是如果Fix版本號小於等於"FIX.4.4"則是一種邏輯，大於FIX4.4是一種邏輯。那么就需要注意在客戶化時你定義的協定版本（即FIX的beginString）是多少，是不是從字元串比較的角度看小於等於"FIX.4.4"。如果不是，則需要在諸多的地方更改QuickFix/J的邏輯
- QuickFix/J在實現中，心跳設定（HeartBtInt）由客戶端（Initiator）決定，而STEP協定則規定心跳由伺服器端（Acceptor），這需要修改DefaultSessionFactory.create(sessionID, settings)中關於角色和HeartBtInt的設定。並且還需要修改Session.nextLogon(message)中登入之後讀取HeartBtInt並設定到state中的邏輯。
