会場 1 は特定のメッセージを使用して、たとえば市場データを要求できますが、会場 2 は同じタスクに別のメッセージを使用できます。これをマッピングする最良の方法は何ですか?任意の提案をいただければ幸いです
さらに、マッピングを簡単にするために、追加のフィールドを会場メッセージに追加することは賢明ですか?
取引所がこのタスクをどのように実行するかについて、誰か洞察を提供できますか? 複数の会場に接続されている取引所は、各会場の仕様を解析して変換する必要があります。
会場 1 は特定のメッセージを使用して、たとえば市場データを要求できますが、会場 2 は同じタスクに別のメッセージを使用できます。これをマッピングする最良の方法は何ですか?任意の提案をいただければ幸いです
さらに、マッピングを簡単にするために、追加のフィールドを会場メッセージに追加することは賢明ですか?
取引所がこのタスクをどのように実行するかについて、誰か洞察を提供できますか? 複数の会場に接続されている取引所は、各会場の仕様を解析して変換する必要があります。
残念ながら、FIX の柔軟な性質により、これは簡単な作業ではありません。 私のもう 1 つの回答は、FIX バージョン間の変換が実行できない理由と、同じ FIX バージョンを使用する 2 つの会場が実際に根本的に互換性を持たない理由について詳しく説明しています。
私の経験では、実際には会場ごとにカスタム アダプターを作成する必要があります。1 つの方法は、アプリが使用する会場に依存しないデータ オブジェクトのセットを作成し、オブジェクトと会場との間の FIX メッセージ間の変換を実装することです。アプリは、コンバーターを単なる汎用インターフェイスとして認識します。対象の会場が 4.2 なのか 4.4 なのか、あるいはその他のものなのかを知る必要はありません。
たとえば、メソッドを使用して GenericNewOrder クラスと IConverter インターフェイスを作成できますSendNewOrder(GenericNewOrder)
。IConverter には、VenueAConverter や VenueBConverter など、各会場の実装があります。VenueAConverter は VenueA に適した新しい注文メッセージを作成し、VenueBConverter は VenueB に適した注文メッセージを作成します。新しい会場を追加する必要がある場合は、新しい IConverter を実装するだけです。
それが私が思いついた最高のパターンです。
(あなたのような質問は、実際には QuickFIX メーリング リストで頻繁に出てきます。)