Веб-платформа обмена финансовой информацией (QuickFix/J)

Я всего несколько дней знаком с FIX, и я был бы признателен за некоторые рекомендации ниже.

Торговая система, подключенная к бирже, может принимать сообщения FIX для целей торговли и запроса рыночных данных. Я пытаюсь создать веб-платформу FIX с помощью QuickFix/J, которая будет предоставлена ​​многочисленным клиентам.

IP-адрес и порт предоставляются для подключения к шлюзу торговой системы, и мне уже предоставлены их действительные теги сообщений.

Я использовал QuickFix/J для создания локального инициатора и акцептора (автономные приложения, а не веб-приложения), чтобы проводить тесты и отправлять сообщения между двумя точками (INITIATOR>ACCEPTOR и ACCEPTOR>INITIATOR), и это отлично работает, и я понял идею (подробнее /less) как сообщения должны работать. Также я экспериментировал, чтобы увидеть, как работают несколько сеансов, и это хорошо работает для меня. (1 акцептор - несколько инициаторов)

Я действительно смущен, когда дело доходит до того, что мне нужно перейти к веб-приложению сейчас. Мои вопросы:

  1. При подключении к предоставленному шлюзу что мне нужно запустить, чтобы отправлять и получать сообщения FIX? инициатор или акцептор или оба? Насколько я понимаю: инициатор будет запущен и подключится к акцептору, так что в этом случае шлюз будет акцептором или нет?

  2. Допустим, я хочу предоставить эту веб-платформу нескольким клиентам, и каждый подключенный клиент будет иметь выделенный сеанс после успешного входа в систему. Если акцептор является фактическим сервером, как он узнает о деталях сеанса клиента? (SenderCompID и TargetCompID)

  3. Текущая архитектура:

    • A dedicated server for running the trading system where the FIX client app will connect to and send/receive messages
    • Веб-приложение создаст сеанс в торговой системе и будет отправлять/получать FIX-сообщения.
    • Предложения по связи между сервером и веб-приложением? Я думал использовать activeMQ для обмена сообщениями между двумя точками. Будет ли это хорошей идеей?

Я знаю, что это слишком много, чтобы спросить, но любое мнение/предложение будет очень признательно.

Спасибо.

Обновления:

  1. Моя самая большая проблема с activeMQ на самом деле связана с управлением сеансом и возможностью разработки такого веб-приложения с использованием amq для отправки/получения сообщений между клиент-AMQ-торговой платформой. Я не использовал amq и quickfix/j в деталях, и я просто хочу убедиться, что это действительно возможно сделать.
  2. Основываясь на вышеизложенном, считаете ли вы, что эта архитектура будет работать нормально? архитектура

java activemq fix-protocol quickfixj
person mario    schedule 03.12.2014    source источник
comment
Вы действительно должны присоединиться к списку рассылки Quickfix/J.   -  person Grant Birchmeier    schedule 03.12.2014
comment
Я полагаю, что activeMQ означает Apache aciveMQ. Это нормально. Предыдущее место, где я работал, использовало ActiveMQ за механизмом FIX для обработки сообщений, что совершенно не связано с механизмом FIX. Каковы ваши опасения по поводу использования activeMQ?   -  person DumbCoder    schedule 04.12.2014
comment
@DumbCoder Спасибо за ваш ответ. Пожалуйста, смотрите мои обновления 1 и 2 в описании   -  person mario    schedule 04.12.2014

Ответы (1)


arrow_upward
4
arrow_downward

  1. Не все контрагенты используют акцепторы, но все те, с которыми я когда-либо работал (около 50), таковы, что вам (вероятно) не нужно будет запускать акцептор.
  2. Обычно у каждого клиента есть своя пара CompID, выдаваемая контрагентом, и именно эти реквизиты (уникально) идентифицируют клиента. По моему опыту, вы обычно создаете отдельное соединение для каждого клиента.
  3. Это зависит от того, какие объемы торгов вы ожидаете, но использование activeMQ кажется жизнеспособным. Я бы подумал, что если вы не работаете с высокочастотной торговлей или большим количеством клиентов, вам понадобится отдельный выделенный сервер. В общем, я использовал проприетарные уровни обмена сообщениями для связи между нашими клиентами и серверами, но это было больше связано с компаниями, в которых я работал, чем с тем, что эти системы не подходили для цели.

Отказ от ответственности: мой опыт связан с разработкой C # и C ++ FIX, поэтому я действительно не знаю активного MQ, но на основе сравнений кажется, что все в порядке.

person MD-Tech    schedule 03.12.2014
comment
Спасибо за ваш ответ MD-Tech. Таким образом, для каждого клиента будет создан новый инициатор с использованием пары CompID, предоставленной контрагентом. Надеюсь, что не будет необходимости запускать акцептор (конечно, я еще раз уточню у контрагента). На данный момент торговля будет не очень частой, и платформа будет использоваться только для нескольких клиентов (надеемся, что торговля в будущем увеличится). Если это произойдет, я вернусь сюда для получения дополнительной информации. - person mario; 05.12.2014