FIX-движок (FIX-engine) — это компонент торговой системы, обеспечивающий связь с другими системами по протоколу FIX. Этот компонент отвечает за преобразование внутренних структур приложения в исходящие FIX-сообщения и за конвертацию входящих FIX-сообщений во внутренние структуры данного приложения.
Помимо этого FIX-движок отвечает за все процедуры создания сессии и обеспечения ее работы: проверки контрольных сумм, валидности, определения последовательности сообщений, восстановление сессии после потери связи с повторной передачей пропущенных сообщений и прочее. То есть за все технические нюансы связи, о которых прикладное приложение не должно знать.
Ниже я привожу в качестве иллюстрации пример соединения между клиентом (Customer) и брокером (Broker/Dealer). FIX-система клиента включает в себя множество компонентов, но исходящая сессия поддерживается под-компонентом, который на схеме обозначен как «FIX Engine«, то же самое происходит на стороне брокера.
Брокер
У брокера FIX-движок входит в состав систем связи с рынком (market connectivity), связи с клиентами (client connectivity), внутренние связи между различными компонентами инфраструктуры.
Транспортом для передачи сообщений протокола FIX может быть как TCP/IP или UDP/IP через обычные сокеты, или через какой-то messaging middleware, например, JMS (или какая-то его коммерческая реализация, например, Tibco EMS) или протоколы TibcoRV или AMPS.
Хочу отметить, что для передачи данных между внутренними системами брокера совсем не обязательно использовать FIX. Для этого подойдет любой протокол, например, Simple Binary Encoding или даже JSON, XML, или Protocol Buffers. FIX в таком случае будет использоваться только для обмена данными с внешними системами.
При реализации FIX-протокола брокер придерживается определенной спецификации FIX и расширяет ее своими дополнительными тегами (custom tags). Эта спецификация нужна для того, чтобы разработчики внутренних систем брокера знали, на каком языке системы должны говорить друг другом. Для поддержки связи клиентов с брокером используется специальная книга Rule of Engagement (aka RoE), в которой написано, какой вариант FIX-протокола брокер поддерживает и как клиент должен устанавливать связь с брокером. Здесь контроль находится полностью на стороне брокера. Наиболее часто используется протокол FIX 4.4 и уже редко где — FIX 4.2. Новейший протокол FIX 5.0 пока не так распространен.
В исключительных случаях для каких-то очень важных клиентов брокер может внести изменение в свой FIX-протокол, чтобы, например, разрешить присутствие определенного тега в сообщении от клиента или для передачи ему какой-то дополнительной информации в своих сообщениях.
Совершенно другая ситуация в реализации FIX-протокола при подключении брокера к торговым площадкам (trading venue). Здесь каждая биржа диктует свои правила, и брокеру надо адаптировать свою реализацию для подключения к множеству рынков. Отсюда вывод: реализация FIX-протокола должна быть очень гибкой, чтобы в нее можно было легко вносить изменения. Потому брокеры и предпочитают разрабатывать FIX-движок самостоятельно.
Инвесторы
FIX-engine входит в состав order management system (OMS), обеспечивает связь с различными брокерами и торговыми площадками. OMS преобразовывает операции менеджера фонда с портфелями в списки ордеров, а потом трейдер инвестора отправляет эти ордера на исполнение по своему усмотрению, правилам и предпочтениям. Без FIX-движка трейдеру бы пришлось передавать свои приказы по телефону или по факсу.
Так как OMS для инвесткомпаний поставляют сторонние программные компании, они же и пишут FIX-движки для этих OMS.
Биржи
FIX-движок на биржах — это часть шлюзов (gateways) биржи. Если биржа предоставляет соединение по FIX-протоколу, у нее всегда есть в публичном доступе своя спецификация, в которой указано, какую версию FIX она поддерживает, и какие дополнительные теги в сообщениях она ожидает.
Кто создает FIX-движки
Так как FIX протокол является стандартом де-факто передачи ордеров между участниками торгов, хочешь не хочешь, а без FIX-движка не обойдешься.
Как только FIX-протокол получил популярность, сразу появились первые коммерческие реализации FIX-протокола. Первый известный мне коммерческий движок — Coppelia — был создан компанией Javelin Technologies в марте 2000 года. В марте 2001 года эта компания представила новый движок под названием Appia. Оба движка были написаны на Java, что было весьма необычно в те времена: использование «тормозной» Java в финансовых приложениях было в новинку. В 2002 году Javelin был куплен компанией NYFIX, а та в 2009 году стала потом частью NYSE Technologies.
Пишут сами
Крупные брокерские конторы и инвестиционные банки пишут движки сами, потому что без FIX невозможно существование их бизнеса. Самописный движок проще контролировать, оптимизировать, модифицировать под экзотические нужды. Такой движок входит как правило в корпоративный программный фреймворк, на основе которого строятся все остальные системы. Делается это для того, чтобы под каждую новую систему не писать новый движок с нуля, для обеспечения единообразия во всех внутренних системах брокера. Соответственно, если основа написана на Java, то и все остальные системы будут строиться на Java.
Инвестиционные компании FIX-движки не пишут, а пользуются либо сторонними коммерческими разработками, которые входят в состав их OMS, либо — open source реализации. Лишь те компании, которые пишут latency sensitive приложения, пишут свой FIX-движок, оптимизированный под low-latency.
Используют Open source
QuickFIX является самой известной реализацией FIX-движка с открытыми исходниками. Реализаций несколько: на Java — QuickFIX/J, на Go — QuickFIX/Go и на .NET — QuickFIX/n. Благодаря открытым исходникам вы можете заглянуть внутрь движка и посмотреть, как все работает. Для своих игрушечных проектов я использую QuickFIX/J. Особой производительностью движок похвастаться не может, но для создания простых утилит и демо в качестве хобби — вполне годится.
Существует множество и других реализаций, но QuickFIX — самая популярная из них. По сути, сегодня нет смысла писать самому что-то подобное, разве только в качестве хобби или экспериментов. Если же руки уж очень тянутся, лучше вносите свой вклад в улучшение QuickFIX.
FIX Orchestra
Для облегчения согласования особенностей FIX между клиентом и брокером, между брокером и биржей была предложена спецификация FIX Orchestra. С помощью FIX Orchestra создается спецификация, которая может быть прочитана компьютером, и на основании разбора этой спецификации может быть создан движок и написаны тесты, для проверки его работы. Цель FIX Orchestra — избежать ошибок, пропусков и разночтений со стороны разработчиков при составлении и чтении текстов спецификаций. Это также значительно упрощает и ускоряет процесс разработки, улучшает качество кода и защищает разработчиков от ошибок.