0

  1. FIX 形式からビジネス固有の標準形式に、またはその逆に変換するコンバーターを作成する必要があります。FIX4.2 用の quickfixj エンジンが表示された場合、受信したアプリケーション メッセージは Java オブジェクト形式 (quickfix.fix42.NewOrderSingle) であるため、コンバーターはおそらく標準オブジェクトで getfields および setfields を使用するか、beanutil、dojo マッピングを使用する必要があります。 FIXMLの登場???? xsd および xml 形式を知る必要はありません。情報はオブジェクト形式で受信されます。FIX5.0でも同じですか?? または、xml 形式を処理するためにパーサー (JAXB) を作成する必要がありますか? それとも、情報は常にオブジェクト形式で受信されますか?

  2. FIX 4.x と FIX 5.0 の違いは何ですか? セッション層とアプリケーション層を構成するものは??

  3. 高可用性、FIX エンジンのパフォーマンスについて説明している優れた Web サイトはありますか? 注文状態管理？

ありがとう

ありがとう。それにかんする

  • クエリ 1 -> カウンターパーティが FIXML メッセージを期待している場合、FIX エンジンはこれをどのように処理しますか? トランスポート層が xml 形式を処理するには、どのような設定が必要ですか? FIXML メッセージを解析して構築する最良の方法は何ですか? JAXBのようなxsdsを使用していますか??

quickfix.MessageCrackerクイックフィックスが表示された場合 -> クラスimplements を拡張した場合quickfix.Application、メソッド シグネチャ

public void onMessage(quickfix.fix42.NewOrderSingle order, SessionID sessionID) throws FieldNotFound, UnsupportedMessageType, IncorrectTagValue

オブジェクト形式で表示 ->quickfix.fix42.NewOrderSingle

  • Query3 について -> パフォーマンス測定、高可用性、FIX ホスティングのネットワーク トポロジーに適したサイトはありますか?

よろしく

4

1 に答える 1

0

1) 相手方が FIXML メッセージを送信しない場合、FIXML メッセージを処理する必要がある場合、またはそれらを無視/拒否する場合は、FIXML メッセージを処理する必要はありません。どのように対処するかは、相手方とのユーザー レベルの契約に記載する必要があります。FIX4.2 は、リンゴやオレンジとは異なり、FIX5.0 と大きく異なるわけではありません。Quickfix には、メッセージ構成用の XML 構成ファイルが必要です。

 

2)標準仕様。処理しているメッセージに期待されるすべての違いを知る必要はありません。また、多くの場合、カスタマイズのために独自のフィールドを追加します。

 

3) 商用および社内の FIX エンジンは、それに関与する資金と人員のおかげで、間違いなく Quickfix よりも効率的です。ただし、それらの料金を支払う必要があります。それらすべてを使用せずに、異なる FIX エンジンを比較したりベンチマークしたりすることは非常に困難です。そして、それをどのように使用するかが重要な要素です。変更せずにアルゴリズム取引に Quickfix を使用することは決してないため、使用法は非常に重要です。そのため、ベンチマークの数値は、ひとつまみの塩で取得する必要があります。

于 2012-07-24T15:26:37.853 に答える