金融信息交換FIX協議的業務實現方法、裝置及系統與流程

2023-06-26 23:16:46 1

本發明涉及網際網路技術領域，尤其涉及一種fix協議的業務實現方法、裝置及系統。

背景技術：

金融信息交換(financialinformationexchange，簡稱fix)協議是一種不受單一實體控制的開放消息標準，能夠被調整組建適應任何一個企業的商務需求，用於促進與安全交易相關的信息交換。fix協議最早用於支持美國國內的委託人間基於直接信息流轉的證券交易，隨著時代的發展，fix協議還進一步增加了衍生工具及其它產品的業務領域，包括集成投資、金融衍生產品及外匯交易等。

基於fix協議標準，交易雙方可以直接進行交易，也可以通過第三方搭建的金融業務平臺(後續簡稱為業務平臺)進行交易。隨著金融市場的不斷開放，大量的小微機構不斷湧現，基於業務平臺的交易方式越來越受到這些機構的關注和青睞。

對於基於業務平臺的交易方式，機構方與業務平臺應當使用相同版本的fix協議。目前，fix協議版本已經從fix1.0發展到fix5.0，其中，fix5.0版本協議又將早先版本中的會話層協議從應用層協議中分離出來，進一步產生了fixtx.y及fixx.y兩個協議版本。現有技術中，業務平臺無法要求或限制機構方使用的協議版本，為保證fix協議的版本兼容，業務平臺就需要搭建所有協議版本的業務環境，並針對不同的協議版本單獨開發交易的業務邏輯。隨著fix協議版本的不斷升級以及業務種類的持續增長，業務平臺側的環境部署成本將會越來越高。

技術實現要素：

本發明提供了一種fix協議的業務實現方法、裝置及系統，能夠解決業務平臺側部署fix業務環境成本過高的問題。

為解決上述問題，第一方面，本發明提供了一種fix協議的業務實現方法，該方法包括：

業務平臺接收發送端發送的fix消息，fix消息由不同類型的業務數據組成，業務數據為字符串形式；

根據業務數據中的業務類型信息在腳本列表中查找與fix消息對應的業務腳本，腳本列表中保存有對應不同fix協議版本的業務腳本，業務腳本包含業務邏輯；

執行業務腳本，按照業務邏輯對業務數據進行處理。

第二方面，本發明還提供了一種fix協議的業務實現方法，該方法包括：

發送端將fix報文封裝為fix消息，fix消息由不同類型的業務數據組成，不包含對應具體fix協議版本的業務邏輯，業務數據為字符串形式；

將封裝後的fix消息發送給業務平臺，以使得業務平臺根據包含業務邏輯的業務腳本對業務數據進行處理。

第三方面，本發明還提供了一種fix協議的業務實現裝置，該裝置包括：

接收單元，用於接收發送端發送的fix消息，fix消息由不同類型的業務數據組成，業務數據為字符串形式；

查找單元，用於根據業務數據中的業務類型信息在腳本列表中查找與fix消息對應的業務腳本，腳本列表中保存有對應不同fix協議版本的業務腳本，業務腳本包含業務邏輯；

執行單元，用於執行業務腳本，按照業務邏輯對業務數據進行處理。

第四方面，本發明還提供了一種fix協議的業務實現裝置，該裝置包括：

處理單元，用於將fix報文封裝為fix消息，fix消息由不同類型的業務數據組成，不包含對應具體fix協議版本的業務邏輯，業務數據為字符串形式；

發送單元，用於將封裝後的fix消息發送給業務平臺，以使得業務平臺根據包含業務邏輯的業務腳本對業務數據進行處理。

第五方面，本發明還提供了一種fix協議的業務實現系統，該系統包括業務平臺及發送端；

業務平臺包括上述第三方面的裝置；

發送端包括上述第四方面的裝置。

藉由上述方案，本發明提供的fix協議的業務實現方法、裝置及系統，能夠對fix報文進行上層抽象封裝，獲得僅保留業務數據但不包含具體業務邏輯的通用類fix消息。通過從fix報文中「剔除」具體業務邏輯的方式，弱化了fix報文中業務的強類型特點，使得fix消息能夠通用於任何一種版本的fix協議。而對於業務邏輯而言，則採用業務腳本的形式獨立於fix協議代碼進行配置，針對不同的fix協議版本開發不同的業務腳本，利用腳本語言「動態配置」、「動態加載」的特點對fix交易業務予以實現。與現有技術相比，本發明實現了業務邏輯與fix協議代碼之間的徹底解耦，使得業務邏輯的實現不再依賴於協議代碼本身，因此業務平臺僅部署一種版本的fix協議就可以實現所有fix協議版本的交易業務，能夠大大降低fix業務環境的部署成本。

上述說明僅是本發明技術方案的概述，為了能夠更清楚了解本發明的技術手段，而可依照說明書的內容予以實施，並且為了讓本發明的上述和其它目的、特徵和優點能夠更明顯易懂，以下特舉本發明的具體實施方式。

附圖說明

通過閱讀下文優選實施方式的詳細描述，各種其他的優點和益處對於本領域普通技術人員將變得清楚明了。附圖僅用於示出優選實施方式的目的，而並不認為是對本發明的限制。而且在整個附圖中，用相同的參考符號表示相同的部件。在附圖中：

圖1示出了本發明實施例提供的第一種fix協議的業務實現方法的流程圖；

圖2示出了本發明實施例提供的第二種fix協議的業務實現方法的流程圖；

圖3示出了本發明實施例提供的第三種fix協議的業務實現方法的流程圖；

圖4示出了本發明實施例提供的對非標準fix協議進行解析的方法流程圖；

圖5示出了本發明實施例提供的第一種處理fix消息的交互圖；

圖6示出了本發明實施例提供的第二種處理fix消息的交互圖；

圖7示出了本發明實施例提供的第一種fix協議的業務實現裝置的組成框圖；

圖8示出了本發明實施例提供的第二種fix協議的業務實現裝置的組成框圖；

圖9示出了本發明實施例提供的第三種fix協議的業務實現裝置的組成框圖；

圖10示出了本發明實施例提供的fix協議的業務實現系統的示意圖。

具體實施方式

下面將參照附圖更詳細地描述本公開的示例性實施例。雖然附圖中顯示了本公開的示例性實施例，然而應當理解，可以以各種形式實現本公開而不應被這裡闡述的實施例所限制。相反，提供這些實施例是為了能夠更透徹地理解本公開，並且能夠將本公開的範圍完整的傳達給本領域的技術人員。

本發明實施例公開了一種fix協議的業務實現方法，如圖1所示，該方法包括：

101、業務平臺接收發送端發送的fix消息。

發送端一般為機構方，例如證券交易所、期貨交易所的客戶端等，發送端向業務平臺發送封裝好的fix消息，該fix消息的內容為字符串形式，涉及不同類型的業務數據，例如交易金額、交易時間、買賣雙方id、業務類型、消息長度等。實際應用中，現有fix協議中的所有數據域(或稱為欄位)均可作為本實施例中的業務數據使用，並且，在現有fix協議允許的範圍內，交易雙方自定義的數據域也可以作為所述業務數據使用，本實施例不對業務數據的種類和數量進行限制。

本步驟中接收的fix消息是經過發送端進行上層抽象封裝後的消息，與現有實現方式不同的是，現有fix報文中除了攜帶有各種數據域之外，還會攜帶有針對具體交易業務的業務邏輯，這些業務邏輯本質上是對各種數據域的約束控制信息。例如對於業務「買進股票」而言，其具體的約束 控制信息至少包括：確定買入對象(哪只股票)、判斷股票價格是否達到預設價位、買入幾手股票、如何發起買進操作等。由於fix報文中的業務邏輯涵蓋了實現交易業務的具體約束控制條件，因此現有技術中的fix報文被稱為是一種強類型的報文。與此同時，正是由於fix報文中存在具體的業務邏輯，而受fix協議版本差異影響，即使是同一個交易業務，不同fix協議版本對應的業務邏輯也會有所不同，因此現有技術需要針對不同fix協議版本單獨開發業務邏輯。而在本實施例中，業務邏輯被從fix報文中解耦出去，以腳本語言的形式單獨配置在業務平臺側。對於fix報文而言，發送端將其中的數據域(業務數據)抽象成一個通用的類，獲得字符串形式的業務數據。這種通用類型的業務數據可以適用於任何fix協議版本。

102、業務平臺根據業務數據中的業務類型信息在腳本列表中查找與fix消息對應的業務腳本。

每一個業務腳本都記錄有一個對應具體fix版本的具體業務邏輯，腳本列表是一種用於查找業務腳本的索引性文件，其中記錄有業務類型與業務腳本之間的映射關係。當接收到fix消息後，業務平臺根據其中的業務類型信息在腳本列表中查找對應的業務腳本，以實現相應的業務邏輯。

進一步的，考慮到同一個業務邏輯會存在對應不同fix協議版本的業務腳本，為進行精確查找，業務平臺還可以從業務數據中提取協議版本信息，將協議版本信息與業務類型信息相結合查找業務腳本。與此對應的，腳本列表中應當增加一個維度信息，即協議版本信息，從而記錄業務類型、協議版本以及業務腳本三者之間的映射關係。

本實施例中，需要開發人員預先編寫各種業務腳本，業務平臺可以允許開發人員針對某個版本的fix協議開發對應各種業務邏輯的不同業務腳本，也可以允許開發人員針對某個具體的業務邏輯開發對應各個fix協議版本的不同業務腳本。實際應用中，為實現業務邏輯的按需定製，業務平臺還可以向機構方開放用於開發業務腳本的應用程式接口(applicationprogramminginterface，簡稱api)，以接收機構方開發的業務腳本。

需要說明的是，腳本語言是一種輕量化的動態語言，開發腳本語言所消耗的時間成本及計算機資源遠遠小於在fix協議代碼中開發業務邏輯的 消耗。因此相對現有技術而言，本實施例除了可以減少部署協議版本數量以外，還能夠通過配置腳本語言的方式進一步降低fix協議的部署成本。

103、業務平臺執行業務腳本，按照業務邏輯對業務數據進行處理。

通常情況下，業務腳本可以保存在資料庫伺服器中，當在資料庫中查找到需要的業務腳本後，業務平臺將其放入到緩存中，通過刷新緩存的方式對業務腳本進行動態加載。

通常，業務邏輯的實現會使用到不同的業務數據，例如在商品交易過程中，至少需要買賣方id、商品id、商品價格等業務數據。選擇何種業務數據做何種方式的處理，這是由業務腳本中的業務邏輯決定，或者說是由業務邏輯中的約束控制信息決定，本實施例不對執行業務腳本使用的業務數據的種類和數量進行限制。

實際應用中，某些交易業務是在業務平臺側完成的，而有些交易業務則需要通過業務平臺傳遞給作為接收端的機構方進行實現(例如議價)。對於後者情況，業務平臺在執行完步驟103之後還需要將處理後的fix消息發送給接收端。

進一步的，本發明實施例還公開了一種fix協議的業務實現方法，如圖2所示，該方法包括：

201、發送端將fix報文封裝為fix消息。

圖2所示方法主要應用於發送端一側，將傳統的fix報文進行上層抽象封裝，獲得一個通用類的fix消息。由於fix消息中只包含字符串形式的業務數據，而不包含對應具體fix協議版本的業務邏輯，因此該fix消息可以通用於任何版本的fix協議。

同時，業務邏輯被寫入到提前開發的業務腳本中，並配置到業務平臺側，以使得業務平臺根據包含業務邏輯的業務腳本對業務數據進行處理。

202、發送端將封裝後的fix消息發送給業務平臺。

本發明實施例提供的方法，能夠將fix報文中的業務邏輯解耦到業務平臺側的業務腳本中實現。由於業務邏輯中的約束控制信息在形式和內容上，因fix協議版本的不同而有所差異，因此當fix消息中剩餘有通用類型的業務數據而不再包含具體的業務邏輯時，fix消息就不會再受fix協 議版本的限制，可以適用於任何版本的fix協議中。相對現有技術而言，本實施例能夠提高fix協議版本的兼容性減少部署的fix協議版本數量，並由此降低fix業務環境的部署成本。

進一步的，作為對上述圖1和圖2所示方法的細化，本發明實施例還提供了一種fix協議的業務實現方法，如圖3所示，該方法包括：

301、發送端將fix報文封裝為fix消息。

發送端將fix報文封裝成通用類的fix消息。具體的，發送端從fix報文的報文頭及報文體中提取字符串，組裝成通用類的fix消息。發送端根據預設的報文頭長度截取報文頭，然後根據報文頭內容解析出報文體長度，並根據報文體長度截取報文體的字符串，最後將截取的字符串組裝成fix消息。

實際應用中，發送端可以但不限於將fix報文封裝為message類fix消息。

302、發送端將封裝後的fix消息發送給業務平臺。

根據現有的fix協議規定，fix報文的收發雙方應當在一個會話(session)中進行通信。在建立好會話後，發送端調用已有的發送方法將fix消息發送給業務平臺，例如使用靜態方法sendtotarget進行發送。

303、業務平臺根據業務數據中的業務類型信息在腳本列表中查找與fix消息對應的業務腳本。

如前所述，消息收發雙方需要基於同一個會話進行通信。發送端在發送fix消息的同時還會將本次會話的會話id一同進行發送，由業務平臺根據該會話id在會話列表中找出對應的會話，然後在該會話中進行後續流程。

現有技術中fix報文中的業務數據是以數據域的形式存在的，即以鍵值對的形式存在。本實施例中的業務數據同樣是以鍵值對的形式存在，下表示出了fix協議規定的部分鍵值對(tag-value)：

發送端在對fix消息進行解析後，獲得其攜帶的業務數據。其中，一個鍵值對對應一個類型的業務數據。

在解析出鍵值對後，業務平臺查找業務類型的鍵值對，從中獲取交易業務的業務類型信息，然後根據該業務類型信息在腳本列表中查找與fix消息對應的業務腳本。

進一步的，由於業務平臺涉及交易業務眾多，為避免重複或混淆，業務平臺還可以結合發送者id、消息類型(應用層消息或會話層消息)甚至會話id一同查找業務腳本。

304、業務平臺執行業務腳本，按照業務邏輯對業務數據進行處理。

業務平臺將查找到的業務腳本放入緩存，通過刷新緩存的方式加載業務腳本，實現相應的業務邏輯。

實際應用中，fix協議涉及的業務邏輯可以分為兩大類：一類是針對具體交易對象/具體交易場景的特定業務邏輯，這類業務邏輯在不同交易對象 或不同交易場景中的通用性較差，需要針對具體情況單獨開發，包括但不限於是報文內容解析(涉及不同的解析規則)、報文欄位校驗(是否非空、金額格式、金額大小等)、報文欄位轉換(日期格式轉換、金額格式轉換、幣種標識轉換等)、籤名驗籤、返回碼轉換、冪等控制、流量控制等。

另一類是所有機構方均可以使用的業務邏輯，這一類業務邏輯主要用於建立、保障、註銷通信雙方之間的底層通信過程，當然也包括較為通用的交易業務的業務邏輯，其適用於任何業務類型的業務邏輯。較為典型的業務邏輯包括會話層的心跳管理、網路測試、消息重傳、消息駁回、序號復位、註銷、登錄驗證等，以及應用層的撤單請求、駁回撤單、執行報告、狀態請求、狀態檢查、下新單等。

對於特定的業務邏輯，將其以業務腳本的形式配置到業務平臺，通過執行步驟304予以實現。而對於通用的業務邏輯而言，則無需針對不同的機構方重複配置業務腳本，在開發fix業務環境時，直接將通用業務邏輯寫入業務平臺側的協議代碼中。通過後續步驟305至步驟307進行實現。由於通用業務邏輯適用於所有的業務類型，使用過程中無需修改，因此不會增加fix業務環境的維護成本。

305、業務平臺根據業務數據中的消息類型信息判斷fix消息的消息類型。

業務平臺根據key為「msgtype」的鍵值對獲得fix消息的消息類型，該消息類型包括「應用層消息」及「會話層消息」兩種。針對不同的消息類型，業務平臺選擇執行後續步驟306或步驟307。

306、若消息類型為應用層消息，則業務平臺調用應用層方法執行應用層的通用業務邏輯。

業務平臺調用application類中的toapp方法或fromapp方法執行應用層的通用業務邏輯。toapp方法或fromapp方法的區別在於，如果是對待發送給接收端的fix消息進行處理，則調用toapp方法，如果是對接收到的fix消息進行處理，則調用fromapp方法。

307、若消息類型為會話層消息，則業務平臺調用會話層方法執行會話層的通用業務邏輯。

業務平臺調用application類中的toadmin方法或fromadmin方法執行應用層的通用業務邏輯。toadmin方法或fromadmin方法的區別在於，如果是對待發送給接收端的fix消息進行處理，則調用toadmin方法，如果是對接收到的fix消息進行處理，則調用fromadmin方法。

實際應用中，發送和接收fix消息的會話序號是各自分別維護的，管理待發送和已接收消息的消息隊列也是相互獨立的，因此業務平臺可以根據fix消息的會話序號選擇調用toapp/toadmin還是fromapp/fromadmin。

本實施例將步驟305至步驟307置於步驟304之後僅為便於表述，實際應用中業務平臺在接收到fix消息後，也可以首先執行步驟305至步驟307然後再執行步驟303至步驟304，或者，同時執行步驟305至步驟307以及步驟303至步驟304。

在本實施例的一種實現方式中，可以將欄位校驗、基於會話序號的漏傳校驗等通用的校驗業務寫入到fix協議代碼中，通過會話層方法的調用予以實現。

進一步的，業務平臺還可以將下述幾種新的通用業務邏輯寫入到fix協議代碼中，通過會話層方法執行：

1、重置序號邏輯

現有fix協議標準中存在序號保護機制，消息發送方會在發送的消息中添加一個會話序號，對於消息接收方而言，如果當前接收消息的序號與前一個接收消息的序號不連續，則說明兩消息之間存在漏傳的消息，需要觸發消息重傳機制。而如果序號連續，則發送方再次發送消息時會將上一個消息的序號加1，作為下一個消息的會話序號使用。

由此可見，隨著通信過程的不斷深入，通信雙方使用的會話序號將不斷遞增，當會話序號的數值超過系統或資料庫支持的最大上限時，系統因無法識別該會話序號而容易出現錯誤重傳等問題。為防止會話序號超過系統上限，本實施例給出了一種重置序號的通用業務邏輯並通過會話層方法予以實現。具體的，業務平臺根據系統支持的最大上限值設定一個預設的序號最大值，通常該序號最大值小於系統的最大上限值，實際應用中可以將序號最大值設定為系統最大上限值的70％到95％。例如當系統最大上限 值為99萬時，可以將序號最大值設置為90萬。

在執行重置序號邏輯時，業務平臺判斷當前消息的會話序號是否到達預設的序號最大值。如果到達序號最大值則會話序號重置為0，以使得後續從0開始繼續累加；如果未到達序號最大值則不作任何處理。

本實施例中，通過會話層的重置序號邏輯可以防止消息的會話序號超出系統或資料庫支持的最大上限，能夠有效避免因會話序號溢出導致的系統異常。

2、拒絕交易邏輯

當對會話序號進行重置時，可能因為機構方不受理，或者系統自身的異常原因導致重置失敗，此時為避免會話序號超出系統或資料庫支持的最大上限值，業務平臺可以通過會話層方法實現拒絕交易邏輯，拒絕對當前的fix消息進行處理，由此消除會話序號進一步累加的可能性。

3、清除隊列邏輯

在現有fix協議的重傳機制中，如果會話序號不連續，則會將當前消息放在一個消息隊列中進行緩存，並通知發送端重新發送漏傳序號對應的消息。此時發送端後續發送的當前消息之後的所有消息都需要緩存在消息隊列中，因此消息隊列存在內存溢出風險。本實施例中，業務平臺可以通過清除隊列邏輯對消息隊列的大小進行監控，若消息隊列佔用的緩存超過預設的緩存閾值，則清除消息隊列中緩存的fix消息，以保證系統的穩定高可用。實際應用中，緩存閾值可以根據系統的內存大小按照比例設置，本實施例對其具體數值不作限制。

進一步的，在本實施例中，當機構方新增fix業務時，業務平臺還可以獲取包含新增fix業務邏輯的業務腳本，並將獲取的業務腳本添加到腳本列表中，由此完成新增業務邏輯的添加。本實施例將業務邏輯以腳本語言的形式配置在業務平臺側，當需要新增業務邏輯時，只需要將新開發的業務腳本配置在業務平臺側即可，無需對fix協議代碼進行修改。與現有技術相比，大大提高了增加業務邏輯的靈活性和便捷性，更加便於機構方自定義個性化的交易業務。

與此類似的，當需要從業務平臺中刪除某些業務邏輯時，只需要更加 業務類型查找到對應的業務腳本，然後將該業務腳本從腳本列表中刪除即可，同樣無需改動fix協議代碼，使用起來方便靈活。

進一步的，考慮到實際應用中，部分機構方因不願頻繁重置會話序號等原因並未使用標準的fix協議報文進行通信。對於使用非標準fix協議報文的機構方，為保證其交易業務的實現，本實施例中業務平臺還可以針對不同非fix協議報文的封裝規則預先開發不同的報文解析器，當接收到非fix協議報文時，業務平臺根據其封裝規則選擇對應的報文解析器，並通過報文解析器對非fix協議報文的數據流進行解析，獲得業務數據。

實際應用中，證券公司的資產查詢交易就是使用非標準fix協議報文實現的，採用非標準fix協議主要是考慮到降低序號的增長速度，因為用戶查詢資產的頻率會明顯高於交易的頻率，因此資產查詢必然會導致會話序號的快速增長，從而導致頻繁重置的情況發生。對於非標準fix協議報文，由於其封裝規則與通用類fix消息的封裝規則不同，因此使用通用的解析手段並不能將底層的二進位數據流解析正確解析為字符串形式的數據。本實施例中，通過定製開發的報文解析器可以實現非標準fix協議報文的正確解析，從而保證業務邏輯的實現。具體的，通過報文解析器解析非標準fix協議報文的流程如圖4所示：

401、按照約定好的報文頭長度截取報文頭。

業務平臺按照封裝規則中規定的報文頭長度，從非標準fix協議報文的數據流中截取報文頭。該報文頭長度可以由業務平臺預先與機構方(發送端)約定獲得。

402、根據報文頭獲得報文類型以及報文體長度信息。

獲得報文頭後，就可以從中獲得報文類型、報文體長度等欄位信息。業務平臺根據報文體長度信息執行步驟403，截取報文體。

403、根據報文體長度截取報文體。

在截取報文體的過程中，業務平臺需要多次判斷截取的報文體是否足夠長，即截取的報文體是否達到報文體長度。如果達到該長度則停止截取，否則繼續讀取數據流直至達到報文體長度或數據流讀取完畢。

404、組裝報文頭及報文體，以字符串形式返回給上層。

在對對應報文頭、報文體的數據流進行截取後，將數據流組裝成字符串形式的數據，並返回給上層。由上層將字符串拆分成一個個鍵值對，在進行欄位校驗後完成業務數據的提取。

進一步的，在本實施例的另一種實現方式中，業務平臺在對接收的fix消息進行處理後，還可以將處理後的fix消息發送給接收端。通常，除了能夠在業務平臺側實現的交易業務外，還有一部分交易業務需要基於機構雙方共同完成，例如價格詢盤/還盤等。這種情況下，業務平臺需要將一方機構(發送端)發送的fix消息進行處理後，發送給另一方機構(接收端)。本發明實施例後續將分別針對平臺接收消息及發送消息兩個過程，對fix業務的實現過程進行介紹。

進一步的，在本實施例的最後一種實現方式中，業務平臺還可以採用分布式網絡架構，通過多個計算節點對接收的fix消息進行分布式處理，其中，每個計算節點處理至少一個會話的fix消息。在會話初始階段，可以以會話id為依據，通過哈希算法對會話進行負載均衡，以使得每個計算節點負責數量相同或近似相同的會話。當新增會話時，可以選擇會話數量最少的計算節點進行分配，也可以在會話數量相同的情況下，為最近進行過會話註銷的計算節點分配新增會話，本實施例不對分布式結構中的計算節點數量、會話分配方式以及節點上負載的會話數量進行具體限制。

在上述實現方式中，採用分布式網絡結構除了可以提高計算效率、減輕單臺計算節點負荷之外，還可以使每個計算節點獨立管理各自的會話序號，從而支持會話序號的橫向擴展，由此解決序號順序發送帶來的性能瓶頸。

下面給出本發明實施例的兩種應用場景：

第一，業務平臺向外部發送fix消息

本場景中，業務平臺接收發送端發送的fix消息，對fix消息進行處理後發送給接收端。具體的，如圖5所示，該場景流程包括：

1、發送端封裝fix消息，並調用靜態方法sendtotarget將fix消息發送給業務平臺。

2、業務平臺根據消息中攜帶的會話id查找對應的會話。

3、業務平臺根據消息中攜帶的業務類型信息查找並執行對應的groovy腳本。

通過groovy腳本對fix消息進行處理，實現腳本中的業務邏輯。

4、業務平臺根據消息中攜帶的消息類型信息判斷fix消息的類型。

若為會話層消息，則調用會話層的toadmin方法對fix協議進行處理，實現會話層的通用業務邏輯；

若為應用層消息，則調用應用層的toapp方法對fix協議進行處理，實現應用層的通用業務邏輯。

5、業務平臺調用對象iosessionresponder將處理後的fix消息發送給接收端。

對象iosessionresponder對象是由initiatoriohandler初始化得到的。

6、業務平臺與發送端將自身保存的會話序號加1。

第二，業務平臺接收外部發送的fix消息

本場景中，業務平臺接收發送端發送的fix消息，並對fix消息進行處理。具體的，如圖6所示，該場景流程包括：

1、業務平臺通過對象initiatoriohandler對發送端的socket套接字進行異步非阻塞式監聽。

2、當接收到發送端發送的fix消息時，業務平臺調用類eventhandlingstrategy將消息加入到消息隊列blockingqueue中。

3、業務平臺調用類eventhandlingstrategy重複性的從blockingqueue中讀取fix消息。

4、業務平臺根據消息中攜帶的會話id查找對應的會話。

5、業務平臺檢查會話序號是否連續。

如果會話序號連續則執行後續步驟，否則要求發送端重新發送正常序號範圍內的fix消息。

6、業務平臺根據消息中攜帶的業務類型信息查找並執行對應的groovy腳本。

通過groovy腳本對fix消息進行處理，實現腳本中的業務邏輯。

7、業務平臺根據消息中攜帶的消息類型信息判斷fix消息的類型。

若為會話層消息，則調用會話層的fromadmin方法對fix協議進行處理，實現會話層的通用業務邏輯；

若為應用層消息，則調用應用層的fromapp方法對fix協議進行處理，實現應用層的通用業務邏輯。

8、業務平臺與發送端將自身保存的會話序號加1。

在上述場景中，業務腳本採用groovy語言開發。groovy是一種基於java虛擬機的敏捷動態語言，可以無縫集成所有已經存在的java對象和類庫，採用groovy語言結合java環境進行開發更為方便。實際應用中，業務腳本還可以但不限於使用jpython、jruby等同樣基於java虛擬機的語言進行實現，本實施例對此不作限制。

進一步的，作為對上述圖1及圖3所示方法的實現，本發明實施例還提供了一種fix協議的業務實現裝置。該裝置主要位於業務平臺側，如圖7所示，該裝置包括：接收單元71、查找單元72以及執行單元73；其中，

接收單元71，用於接收發送端發送的fix消息，fix消息由不同類型的業務數據組成，業務數據為字符串形式；

查找單元72，用於根據業務數據中的業務類型信息在腳本列表中查找與fix消息對應的業務腳本，腳本列表中保存有對應不同fix協議版本的業務腳本，業務腳本包含業務邏輯；

執行單元73，用於執行業務腳本，按照業務邏輯對業務數據進行處理。

進一步的，接收單元71接收的fix消息為封裝成通用類的fix消息。

進一步的，如圖8所示，該裝置還包括：

寫入單元74，用於將通用業務邏輯寫入業務平臺側的協議代碼中，通用業務邏輯為適用於任何業務類型的業務邏輯。

進一步的，如圖8所示，該裝置還包括判斷單元75，用於在接收發送端發送的fix消息之後，根據業務數據中的消息類型信息判斷fix消息的消息類型；

執行單元73，用於當消息類型為應用層消息時，調用應用層方法執行應用層的通用業務邏輯；

執行單元73還用於當消息類型為會話層消息時，調用會話層方法執行 會話層的通用業務邏輯。

進一步的，執行單元73用於：

當通用業務邏輯為會話層的重置序號邏輯時，若會話序號到達預設的序號最大值，則將會話序號重置為0；

當通用業務邏輯為會話層的拒絕交易邏輯時，若會話序號重置失敗，則拒絕處理fix消息；

當通用業務邏輯為會話層的清除隊列邏輯時，若消息隊列佔用的緩存超過預設的緩存閾值，則清除消息隊列中緩存的fix消息。

進一步的，如圖8所示，該裝置還包括：

獲取單元76，用於當新增fix業務時，獲取包含新增fix業務邏輯的業務腳本；

添加單元77，用於將獲取的業務腳本添加到腳本列表中。

進一步的，如圖8所示，該裝置還包括：

選擇單元78，用於當接收到非fix協議報文時，根據非fix協議報文的封裝規則選擇報文解析器；

解析單元79，用於通過報文解析器對非fix協議報文的數據流進行解析，獲得業務數據。

進一步的，如圖8所示，該裝置還包括：

發送單元710，用於將處理後的fix消息發送給接收端。

進一步的，該裝置用於通過多個計算節點對接收的fix消息進行分布式處理，其中，每個計算節點處理至少一個會話的fix消息。

進一步的，作為對上述圖2及圖3所示方法的實現，本發明實施例還提供了一種fix協議的業務實現裝置。該裝置主要位於發送端側，如圖9所示，該裝置包括：處理單元91及發送單元92；其中，

處理單元91，用於將fix報文封裝為fix消息，fix消息由不同類型的業務數據組成，不包含對應具體fix協議版本的業務邏輯，業務數據為字符串形式；

發送單元92，用於將封裝後的fix消息發送給業務平臺，以使得業務平臺根據包含業務邏輯的業務腳本對業務數據進行處理。

進一步的，處理單元91用於將fix報文封裝成通用類的fix消息。

進一步的，處理單元91用於從fix報文的報文頭及報文體中提取字符串，組裝成通用類的fix消息。

進一步的，作為對上述圖3所示方法的實現，本發明實施例還提供了一種fix協議的業務實現系統。如圖10所示，該系統包括業務平臺101及發送端102，其中：

業務平臺101包括如圖7或圖8所示的裝置；

發送端102包括如圖9所示的裝置。

本發明實施例提供的fix協議的業務實現裝置及系統，能夠對fix報文進行上層抽象封裝，獲得僅保留業務數據但不包含具體業務邏輯的通用類fix消息。通過從fix報文中「剔除」具體業務邏輯的方式，弱化了fix報文中業務的強類型特點，使得fix消息能夠通用於任何一種版本的fix協議。而對於業務邏輯而言，則採用業務腳本的形式獨立於fix協議代碼進行配置，針對不同的fix協議版本開發不同的業務腳本，利用腳本語言「動態配置」、「動態加載」的特點對fix交易業務予以實現。與現有技術相比，本發明實施例實現了業務邏輯與fix協議代碼之間的徹底解耦，使得業務邏輯的實現不再依賴於協議代碼本身，因此業務平臺僅部署一種版本的fix協議就可以實現所有fix協議版本的交易業務，能夠大大降低fix業務環境的部署成本。

在上述實施例中，對各個實施例的描述都各有側重，某個實施例中沒有詳述的部分，可以參見其他實施例的相關描述。

可以理解的是，上述方法及裝置中的相關特徵可以相互參考。另外，上述實施例中的「第一」、「第二」等是用於區分各實施例，而並不代表各實施例的優劣。

所屬領域的技術人員可以清楚地了解到，為描述的方便和簡潔，上述描述的系統，裝置和單元的具體工作過程，可以參考前述方法實施例中的對應過程，在此不再贅述。

在此提供的算法和顯示不與任何特定計算機、虛擬系統或者其它設備固有相關。各種通用系統也可以與基於在此的示教一起使用。根據上面的 描述，構造這類系統所要求的結構是顯而易見的。此外，本發明也不針對任何特定程式語言。應當明白，可以利用各種程式語言實現在此描述的本發明的內容，並且上面對特定語言所做的描述是為了披露本發明的最佳實施方式。

在此處所提供的說明書中，說明了大量具體細節。然而，能夠理解，本發明的實施例可以在沒有這些具體細節的情況下實踐。在一些實例中，並未詳細示出公知的方法、結構和技術，以便不模糊對本說明書的理解。

類似地，應當理解，為了精簡本公開並幫助理解各個發明方面中的一個或多個，在上面對本發明的示例性實施例的描述中，本發明的各個特徵有時被一起分組到單個實施例、圖、或者對其的描述中。然而，並不應將該公開的方法解釋成反映如下意圖：即所要求保護的本發明要求比在每個權利要求中所明確記載的特徵更多的特徵。更確切地說，如下面的權利要求書所反映的那樣，發明方面在於少於前面公開的單個實施例的所有特徵。因此，遵循具體實施方式的權利要求書由此明確地併入該具體實施方式，其中每個權利要求本身都作為本發明的單獨實施例。

本領域那些技術人員可以理解，可以對實施例中的設備中的模塊進行自適應性地改變並且把它們設置在與該實施例不同的一個或多個設備中。可以把實施例中的模塊或單元或組件組合成一個模塊或單元或組件，以及此外可以把它們分成多個子模塊或子單元或子組件。除了這樣的特徵和/或過程或者單元中的至少一些是相互排斥之外，可以採用任何組合對本說明書(包括伴隨的權利要求、摘要和附圖)中公開的所有特徵以及如此公開的任何方法或者設備的所有過程或單元進行組合。除非另外明確陳述，本說明書(包括伴隨的權利要求、摘要和附圖)中公開的每個特徵可以由提供相同、等同或相似目的的替代特徵來代替。

此外，本領域的技術人員能夠理解，儘管在此所述的一些實施例包括其它實施例中所包括的某些特徵而不是其它特徵，但是不同實施例的特徵的組合意味著處於本發明的範圍之內並且形成不同的實施例。例如，在下面的權利要求書中，所要求保護的實施例的任意之一都可以以任意的組合方式來使用。

本發明的各個部件實施例可以以硬體實現，或者以在一個或者多個處理器上運行的軟體模塊實現，或者以它們的組合實現。本領域的技術人員應當理解，可以在實踐中使用微處理器或者數位訊號處理器(dsp)來實現根據本發明實施例的發明名稱(如確定網站內連結等級的裝置)中的一些或者全部部件的一些或者全部功能。本發明還可以實現為用於執行這裡所描述的方法的一部分或者全部的設備或者裝置程序(例如，電腦程式和電腦程式產品)。這樣的實現本發明的程序可以存儲在計算機可讀介質上，或者可以具有一個或者多個信號的形式。這樣的信號可以從網際網路網站上下載得到，或者在載體信號上提供，或者以任何其他形式提供。

應該注意的是上述實施例對本發明進行說明而不是對本發明進行限制，並且本領域技術人員在不脫離所附權利要求的範圍的情況下可設計出替換實施例。在權利要求中，不應將位於括號之間的任何參考符號構造成對權利要求的限制。單詞「包含」不排除存在未列在權利要求中的元件或步驟。位於元件之前的單詞「一」或「一個」不排除存在多個這樣的元件。本發明可以藉助於包括有若干不同元件的硬體以及藉助於適當編程的計算機來實現。在列舉了若干裝置的單元權利要求中，這些裝置中的若干個可以是通過同一個硬體項來具體體現。單詞第一、第二、以及第三等的使用不表示任何順序。可將這些單詞解釋為名稱。