Министерство Образования РМ.
Экономическая Академия Молдовы
Факультет Кибернетики, Статистики и Информатики
Кафедра Кибернетики и Экономической Информатики
Реферат
по Электронной коммерции
тема: «Информационная система обмена финансовой информацией посредством FIX сообщений»
Выполнил:
ст-т 1 курса, гр. MI 121m
Binkovski Alexandr
Научный руководитель:
профессор, доктор хабилитат академических наук
Bolun Ion
Кишинэу 2012
Содержание
1. Введение. 3
2. Информационная система FIX сообщений, как средство передачи финансовой информации 4
3. Техническая спецификация информационной системы, построенной на FIX протоколе. 4
Структура FIX сообщения. 8
Длина FIX сообщения. 9
Расчёт контрольной суммы FIX сообщения. 10
Виды FIX сообщений по содержанию.. 10
4. Функциональные составляющие информационной системы FIX сообщений. 11
Установка соединения. 11
Проверка целостности FIX сообщений. 11
Механизм переотправки сообщений. 11
Проверка состояния FIX соединения. 12
Сброс порядковых номеров FIX сообщений. 12
Закрытие сессии FIX соединения. 13
Установление сессии после сбоя. 13
5. Функционирование системы FIX сообщений. 14
Топология сети. 15
6. Библиотеки готовый программных модулей. 17
7. Заключение. 18
Библиография: 19
1. Введение
Пожалуй, одним из достижений, сравнимым с изобретением радио, телевидения, атомной бомбы, является создание в конце XX века Всемирной сети Интернет, которая стала в новом тысячелетии не только средством для общения людей, но и силой, способной влиять на устоявшиеся традиции, геоэкономические и геополитические интересы глобального мироустройства. Интернет - наиболее динамично развивающаяся среда информационного обмена в истории человечества. Современные возможности доступа к Интернету с мобильных телефонов и устройств (мобильный Интернет), с телеприемника, а также обмен информацией через сеть других устройств, расширяют круг пользователей.
Бурное развитие привело к тому, что сеть Интернет стала приобретать новые качественные функции, диверсифицируясь в «киберпространство», наполненное не только информацией, но современными технологиями ведения бизнеса. Сегодня можно говорить о том, что Интернет стал основой для развития нового направления в экономической науке и практике, которое можно назвать «Интернет-экономикой». Интернет-экономика имеет транснациональный характер и является эффективным инструментом внешнеэкономической деятельности и глобального развития рынка товаров и услуг.
Одним из элементов Интернет-экономики является «электронная коммерция», наиболее динамично развивающаяся в последние 2-3 года. Что такое «электронная коммерция»? Один из возможных вариантов определения: это любая форма деловых взаимоотношений с использованием сетей передачи данных и современных информационных технологий бизнеса, а не путем физического обмена или прямого физического контакта друг с другом. «Электронная коммерция» в общем смысле покрывает все формы деловых операций, осуществляемых с помощью электронных средств и использующих телекоммуникационные сети передачи данных. Такие операции проводятся между компаниями-производителями и потребителями товаров и услуг или между компаниями и государственными организациями и физическими лицами. «Электронная коммерция» объединяет в себе широкий спектр видов деятельности и включает в себя единый ряд компонентов и единый технологический цикл.
Разнообразие проводимых операций обеспечивает рекламу и продвижение товаров и услуг, изучение конъюнктуры рынка, электронные торги и платежи, доставку и послепродажную поддержку поставленных товаров и услуг. Все коммерческие операции, включая оформление заказа, доставки, выставления счетов и их оплату, могут быть осуществлены между производителем и покупателем продукции через сеть Интернет независимо от их месторасположения. [1]
В начале пути своего развития, электронновычислительные сети стоили достаточно дорого, поэтому одними из первых, кто смог по достоинству оценить их преимущества, были крупные финансовые учереждения. Понимая перспективы использования сетей ЭВМ, появилась идея их использования в электронных биржевых торгах. Так, в 1992 году для передачи информации о торгах акциями между компаниями Fidelity Investments и Salomon Brothers был создан Financial Information eXchange (FIX) protocol (протокол обмена финансовой информацией), который по сей день является стандартом де-факто среди крупных торговых он-лайн площадок.
2. Информационная система FIX сообщений, как средство передачи финансовой информации
Financial Information eXchange (FIX) protocol (протокол обмена финансовой информацией) - протокол передачи данных, являющийся международным стандартом для обмена данными между участниками биржевых торгов в режиме реального времени. Изначально создан в 1992 г. для передачи информации о торгах акциями между компаниями Fidelity Investments и Salomon Brothers. В настоящее время широко используется торговыми системами для обмена финансовыми данными и совершения транзакций.
Протокол FIX поддерживается большинством крупнейших банков и электронными трейдинговыми системами, а также крупнейшими биржами мира. [2]
3. Техническая спецификация информационной системы, построенной на FIX протоколе
FIX протокол служит для обмена данными в торговых сессиях между трейдинговыми системами. Подобно XML, он является самоописывающим.[2]
В данный момент, с точки зрения структуры FIX сообщений, существует два основных типа – это обычное FIX сообщение, состоящее из пар «тег=значение», разделённых специальным символом (ASCII кодом SOH — Start of Header (0x01)) и FIXML сообщение, построенное по подобию XML. При торговле ценными бумагами обмен данными обычно производится множеством небольших сообщений, поэтому чаще всего предпочтение отдаётся обычным FIX сообщениям, которые и будут рассмотрены далее.
FIX – первоначально являлся протоколом сессионного уровня поверх TCP, однако позднее был реализован и поверх UDP.
Исторически, развитие FIX протокола проходило начиная с версии 1.0 и, на данный момент последней версией является 5.0/FIXT 1.1. Существуют фреймворки с открытыми исходными кодами для передачи данных по протоколу, с версиями 4.0-4.4, 5.0.
Однако, в данный момент самой популярной версией, попрежнему является 4.4, поэтому она будет взята за основу при описании FIX протокола.
Технологический процесс инициирования сделки представлен на рисунке 3.1
Рисунок 3.1 – Инициирование сделки
Как видно из рисунка, система обмена FIX сообщениями представляет собой процесс постоянного обмена информацией между менеджером по инвестициям с одной стороны, и брокером/диллером – с другой. Сюда можно отнести:
· Предложение
· Заказ
· Подтверждение заказа
· Отказ
· Отчёт о выполнении (частичном выполнении)
Далее идёт процесс заключения сделки, представленный на рисунке 3.2
Рисунок 3.2 – Процесс заключения сделки
После получения сообщения о подтверждении заключения сделки уже невозможно отказаться от обязательств, взятых на себя во время осуществления данной сделки.
Структура информационная подсистема FIX представлена на рисунке 3.3
Рисунок 3.3 – ИС FIX
Рассмотрим принцип работы информационной системы FIX на простом примере:
Клиентское приложение при запуске создаёт административное сообщение LogIN(A), предназначеное для инициирования создания подключения к серверу. Сообщение создаётся согласно словарю текущей спецификации FIX сообщений. Расчитывается его длина и контрольная сумма, после чего производится отправка сообщения через сетевой интерфейс, который в случае необходимости осуществляет шифрование отправляемых данных.
Со стороны сервера, firewall (сетевой интерфейс) принимает сообщения строго с заданных IP адресов, прослушивая только определённые порты, номера которых знают только клиенты. Сетевой интерфейс обеспечивает получение сообщений только от указанных отправителей и, последующую расшифровку сообщения, его сохранение в буфер для последующей обработки. Далее сообщение проверяется на соответствие спецификации FIX, что включает в себя:
· Проверка порядкового номера сообщения
o Если номер меньше ожидаемого, это свидетельствует о серьёзном программном сбое и сессия прерывается.
o Если номер больше ожидаемого, текущее сообщение отбрасывается и запускается функция восстановления потерянных сообщений
· Проверка длины сообщения и контрольной суммы
o В случае несовпадения, сообщение просто отбрасывается
· Проверка структуры FIX сообщения, согласно имеющейся спецификации
o Проверка обязательных полей. В случае, если сообщение не проходит проверку успешно, клиенту отправляется сообщение об ошибке
В случае, если всё впорядке, сервер инициирует создание и отправку ответного LogON(A) сообщения, процесс обработки, которого аналогичен описанному ранее со стороны клиентского приложения.
Структура FIX сообщения
Любое FIX сообщение состоит из множества пар (групп) «тег=значение», разделённых специальным символом ASCII (код в Java “\001”), где номер тега определяет тип значения передаваемой информации в данной паре.
FIX сообщение состоит из flat ASCII символов (7 бит) и <SOHO> разделителя тегов.
По структуре, сообщение состоит из трёх основных обязательных элементов:
· Заголовок (header)
· Содержание (body)
· Трейлер (trailer)
Рисунок 3.4 – основные структурные элементы FIX сообщения
Для каждого из структурных элементов существуют обязательные поля (О) и необязательные (Н). В содержании теги могут находиться в любой последовательности, а в заголовке и трейлере, часть полей только в строго заданной последовательности.
Так, например в заголовке, первым всегда должен быть тег, описывающий версию используемого FIX протокола, вторым – поле, описывающее длину сообщения, всегда третьим идёт тег с типом сообщения.
Таблица 4.1 – Описание обязательных полей заголовка (header) FIX сообщения
Тег | Имя поля | Обязательное | Комментарии |
8 | BeginString | Да | Содержит версию протокола, всегда незашифрованное, первое поле в сообщении. В нашем случае, будет содержать следующее значение «8=FIX.4.4» |
9 | BodyLength | Да | Длина сообщения, |
35 | MsgType | Да | Тип сообщения, |
49 | SenderCompID | Да | Идентификатор отправителя, |
56 | TargetCompID | Да | Идентификатор получателя, |
34 | MsgSeqNum | Да | Номер сообщения (принципы нумерации сообщений будут рассмотрены позднее) |
52 | SendingTime | Да | Время отправки сообщения |
Стандартный трейлей состоит всего из трёх полей, где обязательным является только последнее, необходимое для проверки контрольной суммы сообщения.
Таблица 4.2 – Описание обязательных полей трейлера FIX сообщения
Тег | Имя поля | Обязательное | Комментарии |
93 | SignatureLength | Нет | Длина подписи, |
89 | Signature | Нет | Подпись |
10 | CheckSum | Да | Контрольная сумма |
Длина FIX сообщения
Длина FIX сообщения равна числу символов в сообщении, за исключением поля контрольной суммы (тег=10).
Расчёт контрольной суммы FIX сообщения
Контрольная сумма является остатком от деления на 256 суммы всех десятичных представлений символов сообщения, до тега контрольной суммы (|10=).
Например, если сумма десятичных представлений всех символов сообщения равна 274, то значение контрольной суммы будет равно 18 (256+18=274).
Простой пример кода, для расчёта контрольной суммы будет выглядеть следующим образом [4]:
char *GenerateCheckSum( char *buf, long bufLen )
{
static char tmpBuf[ 4 ];
long idx;
unsigned int cks;
for( idx = 0L, cks = 0; idx < bufLen; cks += (unsigned int)buf[ idx++ ] );
sprintf( tmpBuf, "%03d", (unsigned int)( cks % 256 ) );
return( tmpBuf );
}
Виды FIX сообщений по содержанию
По содержанию, различают два вида FIX сообщений административные (administrative) и уровня приложения (application).
Административными являются все системные сообщения, отсылаемые для создания, поддержания и закрытия сессии, комманды для повторного получения потерянных сообщений и др., полный список приведён в таблице 4.3.
Таблица 4.3. Виды административных сообщений [6]
№ | Название | Описание |
1 | Logon | Передается в обоих направлениях. Инициирует сессию и соединение |
2 | Logout | Передается в обоих направлениях. Инициирует или подтверждает разрыв соединения |
3 | Resend Request | Передается в обоих направлениях. Указывает на необходимость повторной передачи сообщений в определенном интервале номеров. Поддерживается, но не является необходимой частью протокола |
4 | Sequence Reset | Передается в обоих направлениях. Используется при повторной пересылке для пропуска административных сообщений |
5 | Test Request | Передается в обоих направлениях. Используется для контроля состояния соединения. Требует ответа в виде маркированного сообщения Heartbeat |
6 | Heartbeat | Передается в обоих направлениях в целях контроля состояния соединения |
7 | Reject | Передается в обоих направлениях. Указывает на неверно переданное или неизвестное сообщение, пришедшее от другой стороны |
4. Функциональные составляющие информационной системы FIX сообщений
Установка соединения
Для установки FIX соединения c сервером FIX клиент должен отправить сообщение Logon (A), в котором указаны логин и пароль (SenderCompID и Password) к торговой системе, с порядковым номером, равным единице. Если сообщение Logon (A) корректное и сервер авторизовал пользователя, то клиент получает ответное Logon (A) сообщение, которое подтверждает установку FIX соединения. После этого акцептор и инициатор FIX соединения синхронизируют свои сообщения посредством проверки порядковых номеров (MsgSeqNum (34)) перед тем, как отправить какое-нибудь сообщение.
Если сообщение Logon (A) не корректное или если торговая система не авторизовала пользователя, тогда сервер отправляет FIX клиенту Logout (5) сообщение, в котором указывает причину отклонения установки соединения.
Примечание: Каждый новый торговый день FIX клиент должен отправлять сообщение Logon (A) с порядковым номером 1. При повторном подключении к серверу в течение дня FIX клиент должен отправлять сообщение Logon (A) с порядковым номером, который больше на 1, чем у последнего сообщения в исходящем логе.
Проверка целостности FIX сообщений
Проверка целостности сообщения производится двумя способами: проверка длины сообщения и соответствие контрольной суммы сообщения.
В случае, если всё совпадает, сообщение отправляется в следующий модуль обработки данных, происходит инкрементация счётчика полученных/ожидаемых сообщений (+1).
В случае наличия ошибки, рекомендуется сообщение просто отбросить, ожидая следующее «целое» сообщение, при получении которого будет выявлено расхождение полученного и ожидаемого номеров сообщений, в связи с чем произойдёт инициализация модуля восстановления пропущенных сообщений (“Gap filling”).
Примечание: Контрольная сумма равна остатку от деления на 256 суммы всех символов сообщения в бинарном виде, за исключением поля контрольной суммы.
Механизм переотправки сообщений
В процессе инициализации или после того, как FIX соединение было неожиданно разорвано, может возникнуть ситуация, когда одна из сторон (или сервер или FIX клиент) получает сообщение, у которого порядковый номер больше, чем ожидается. Ожидаемым порядковым номером входящего сообщения считается такой, который больше на 1, чем у последнего сообщения во входящем логе. В этом случае сторона, получившая такое сообщение должна инициировать механизм переотправки, отправив сообщение Resend Request (2), в котором должен быть указан диапазон порядковых номеров пропущенных сообщений (BeginSeqNo, EndSeqNo). Например, порядковый номер последнего полученного FIX клиентом сообщения до потери связи равно 5, а после восстановления связи, сервер прислал сообщение с порядковым номером 10. Это значит, что FIX клиент пропустил/потерял с 6 по 9 сообщения. Для получения этих сообщений FIX клиент должен сформировать Resend Request (2) сообщение с BeginSeqNo (7) = 6 и EndSeqNo (16) = 9.
Если одна из сторон получила сообщение с установленным или незаполненным флагом PossDupFlag, у которого порядковый номер меньше, чем ожидается, то это свидетельствует о серьезной ошибке. В этом случае рекомендуется закрыть сессию и обратиться к администратору.
*В реализации QuickFIX случае, если при авторизации (A) номер отправленого сообщения больше ожидаемого, связь разрывается со стороны сервера и клиентским приложением отсылается новое LogOn (A) сообщение c номером сообщения (34) большим на единицу, чем в преведущей попытке.
Проверка состояния FIX соединения
Сообщение Heartbeat (0) используется для мониторинга статуса FIX соединения и определения пробелов в порядковых номерах сообщений, например, в случае потери входящих сообщений. В период неактивности, т. е. если в FIX сессии не было отправлено никаких данных на протяжении определенного интервала времени (HeartBtInt (108), заданного в секундах), то FIX приложение формирует и отправляет противоположной стороне сообщение типа Heartbeat (0) , чтобы проверить статус соединения. Промежуток времени, через который периодически формируется Heartbeat (0) сообщение, определяется FIX клиентом в Logon (A) сообщении (поле HeartBtInt (108)). При этом сервер должен скопировать значение HeartBtInt (108) поля с Logon (A) сообщения и вернуть его в ответном Logon (A) сообщении. Это значит, что инициатор и акцептор сессии должны использовать одно и то же значение HeartBtInt (108).
Если инициатору Heartbeat (0) сообщения не приходит в ответ ни одно сообщение на протяжении определенного промежутка времени (HeartBtInt (108), заданного в секундах + "некоторое приемлемое время передачи"), тогда он должен сформировать Test Request (1) сообщение. Если и на Test Request (1) сообщение не получен ответ в течение определенного периода времени (HeartBtInt (108), заданного в секундах + "некоторое приемлемое время передачи"), тогда считается, что соединение потеряно и нужно предпринимать меры пл восстановлению подключения.
Сброс порядковых номеров FIX сообщений
Каждый день перед началом торгового дня приложение автоматически сбрасывает порядковые номера сообщений. Это значит, что каждый новый день порядковые номера сообщений начинаются с 1.
Примечание: обычно сброс номеров сообщений инициализируется со стороны сервера.
В течение торгового дня FIX клиент может запросить сброс порядковых номеров сообщений (MsgSeqNum (34)) с помощью сообщения Logon (A) с установленным флагом ResetSeqNumFlag (ResetSeqNumFlag = Y). Рекомендуется перед сбросом порядковых номеров отправить сообщение Test Request (1) и дождаться ответного Heartbeat (0) сообщения. Это выполняется инициатором для того, чтобы убедиться в том, что он получил все отправленные ему сообщения, т. е. ни одно сообщения не пропущено. После получения ответного Heartbeat (0) сообщения FIX клиент отправляет сообщение Logon (A) в эту же сессию c MsgSeqNum (34) = 1 и ResetSeqNumFlag (141) = 'Y'. Серверное приложение должено ответить таким же сообщением Logon (A) с MsgSeqNum (34) = 1 и ResetSeqNumFlag (141) = 'Y'. После этого сброс порядковых номеров считается успешно завершенным и каждое последующее сообщение от любой из сторон будет иметь порядковый номер 2.
На протяжении торгового дня, в случае, если серверное приложение не может корректно повторно отправить пропущенные клиентом сообщения в ответ на Resend Request (2) сообщение, например, в случае, если произошел сбой и некоторые потерянные сообщения нельзя восстановить, тогда серверное приложение предлагает увеличить порядковый номер сообщений (с возможной потерей данных) и продолжить с него, т. е. формирует сообщение Sequence Reset (2) с GapFillFlag (123) = N (Sequence Reset) и NewSeqNo (36) = <новый порядковый номер>.
Примечание: Если клиент инициировал запрос сброса порядковых номеров в течение торгового дня, то все накопленные сервером и еще не доставленные сообщения не будут доставлены клиенту.
Закрытие сессии FIX соединения
Корректным завершением/закрытием FIX сессии считается обмен Logout (5) сообщениями между инициатором и акцептором. Другие способы закрытия/обрыва сессии должны рассматриваться как некорректные и такие, которые приводят к ошибке.
Рекомендуется перед отправкой Logout (5) сообщения убедиться в том, что ни одно сообщение не потеряно и не пропущено. Для этого инициатор закрытия сессии отправляет сообщение Test Request (1) и ждет ответного Heartbeat (0) сообщения.
Перед тем, как разорвать соединение, инициатор завершения сессии должен подождать подтверждающее Logout (5) сообщение от акцептора. Это дает возможность акцептору убедиться в отсутствии потери сообщений или выполнить запрос переотправки пропущенных сообщений, если это необходимо. Сессия также может быть завершена, если через соответствующий период времени акцептор не прислал ответ на Logout (5) сообщение.
После отправки Logout (5) сообщения, инициатор завершения сессии не должен посылать никакого сообщения пока акцептор завершения сессии не попросил это сделать посредством сообщения Resend Request (2).
Установление сессии после сбоя
Имеют место следующие механизмы переустановки сессии:
1. Если при разрыве связи не произошло потери логов на стороне клиента, то для восстановления сессии и получения сообщений, накопленных на сервере, рекомендуется следующая последовательность действий:
a. Отправить Logon (A) сообщение с порядковым номером (MsgSeqNum (34)), который больше на 1, чем у последнего сообщения в исходящем логе;
b. Если в ответ получено Logon (A) сообщение с порядковым номером (MsgSeqNum (34)) больше, чем ожидается, тогда отправить на сервер Resend Request (2) сообщение c указанием диапазона порядковых номеров потерянных сообщений.
c. Сервер отправит клиенту все сообщения из указанного диапазона порядковых номеров и продолжит нормальную работу.
2. При возникновении серьезной ошибки, приводящей к частичной или полной потере клиентом логов, рекомендуется использовать один из следующих способов восстановления сессии:
a. 1 способ:
i. Отправить Logon (A) сообщение, в котором MsgSeqNum (34) = 1 и ResetSeqNumFlag (141) = 'Y';
ii. После установления сессии запросить статус всех интересующих заявок сообщением Order Status Request (H);
b. 2 способ:
i. Отправить Logon (A) сообщение, в котором MsgSeqNum (34) = 1;
ii. Если в ответ полученно Logout (5) сообщение с Text (58) = “MsgSeqNum too low, expecting X but received Y”, тогда отправить Logon (A) сообщение, в котором MsgSeqNum (34) = X.
iii. Отправить на сервер сообщение Resend Request c указанием диапазона порядковых номеров потерянных сообщений.
iv. Сервер отправит клиенту все сообщения из указанного диапазона порядковых номеров и продолжит нормальную работу.
3. Для получения информации о статусах отдельных заявок рекомендуется отправлять на сервер сообщения типа Order Status Request c указанием их номеров ClrOrdID или OrderID.
4. При недоступности основного сервера нужно:
1. Подключиться к резервному серверу;
2. Если FIX клиент подключается первый раз к этому серверу в этот торговый день - Отправить Logon (A) сообщение, в котором MsgSeqNum (34) = 1, TargetCompID (56) = <идентификатор резервного сервера>. В этом случае резервный сервер отправит клиенту все сообщения, накопленные с начала торгового дня.
3. Если FIX клиент уже подключался к этому серверу в этот торговый день - Отправить Logon (A) сообщение (34) с порядковым номером, который больше на 1, чем у последнего сообщения в исходящем логе для сессии с этим сервером и TargetCompID (56) = <идентификатор резервного сервера>; резервный сервер отправит клиенту все сообщения, накопленные с момента отключения клиента от этого сервера.
5. Функционирование системы FIX сообщений
В общем виде, процесс обмена финансовой информацией в FIX системе представляет из себя два потока данных: входящих и исходящих сообщений (административных и пользовательских), как представлено на рисунке 5.1.
Рисунко 5.1 – Схема потоков FIX сообщений
Схема бизнесс-процесса между диллером и брокером, без посредников представлена на рисунке 5.1. В общем виде, подключение реализовано в сети экстранет между двумя информационными системами обмена FIX сообщениями. ИС FIX производит обработку сообщений их дальнейшую передачу в систему управления заказами, откуда они доступны брокерам.
Топология сети
Рисунок 5.2 – Схема взаимодействия двух информационных систем посредством FIX
Подключение между клиентом и поставщиком услуг (биржей) осуществляется посредством выделенных линий и/или сети Интернет, как представлено на рисунке 5.3. Для создания подключения обе стороны обмениваются данными об IP адресах и портах, с помощью которых будет осуществлена передача информации и они добавляются в исключения firewall-а. Так же, в самом FIX сообщении указывается имя принимающей и отправляющей стороны, таким образом, исключается возможность подмены или перехвата сообщений. Чаще всего, для того, чтобы гарантировать конфиденциальность отправляемых данных, дополнительно используется SSL/TSL шифрование, как показано на рисунке 5.4.
SSL/TSL шифрование обеспечивает простейший способ расшифровки сообщений, получаемых от FIX сервера и шифрования сообщений, отсылаемых серверу FIX.
Рисунок 5.3 – Топология сети
Рисунок 5.4 – SSL/TSL шифрование
6. Библиотеки готовый программных модулей
Существует множество библиотек готовых программынх модулей и приложений, работающих на FIX протоколе. Большая их часть платная, некоторые предоставляются в пользование торговыми площадками, однако есть довольно крупный проект с открытыми исходными кодами, на основе которого, даже имеются коммерческие решения – это quickFIX (сайт проекта http://www. quickfixengine. org/).
Реализации quickFIX фрейморка для версий FIX 4.0~5.0 доступны на следующих языках:
· C++ - http://www. quickfixengine. org/download
· .NET - http://www. quickfixn. org/
· Python
· Ruby
· Java - http://www. quickfixj. org/
По имеющейся информации активными являются три проекта, получившие самое большое распространение - это версии на Java, С# (.NET) и С++.
7. Заключение
В данной научной работе были изучены первые информационные системы, основанные на принципах электронной коммерции, в частности, посредством передачи FIX сообщений, появившиеся ещё в 1992 году.
Был подробно изучен стандарт передачи финансовых данных посредством FIX протокола, используемый на большинстве современных торговых площадок, принципы его работы, а так же библиотеки готовых модулей с открытыми исходными кодами, на которых может быть построена информационная система электронной коммерции.
В данной работе не были затронуты аспекты передачи данных (сетевой интерфейс), так как это не являлось основной целью данной работы, однако были представлены обобщающие схемы топологии сети, шифрования и передачи данных.
Для библиотеки программных модулей QuickFIXj сетевым интерфейсом является Apache Mina, версия 1.7. Она является очень гибкой и надёжной, однако, в отличии от версии 2.0, не поддерживает подключение посредством прокси серверов с возможностью авторизации (например, SOCKS5). Из-за сущесственных концептуальных изменений в версии 2.0, переход QuickFIXj на новую версию сетевого интерфейса будет осуществлён не так скоро.
Библиография:
№ | Описание | Ссылка |
1 | Электронная коммерция | http://info-tehnologii. ru/ |
2 | FIX протокол, краткое описание | http://ru. wikipedia. org/ |
3 | Официальный сайт спецификации FIX протокола | http://www. fixprotocol. org/ |
4 | Пример кода программы для расчёта контрольной суммы FIX сообщения | fix-44_VOL-2_w_Errata_20030618.pdf Спецификация FIX протокола, версии 4.4, стр. 26 |
5 | QuickFIXj | http://www. quickfixj. org/ |
6 | Частичный перевод спецификации | http://rts. micex. ru/ |
7 | Никита Налютин, презентация «Тестирование систем электронной торговли ценными бумагами, использующих протокол FIX», Deutsche Bank | |
8 | Материалы из официальных презентаций: · FIX and FIXML Training Class 20010226 · FIX and FIXML Training Class 20010226 · FIX and FIXML Training Class 20010226 · FIX and FIXML Training Class 20010226 | http://www. fixprotocol. org/specifications/TechResources-Training |
Основные порталы (построено редакторами)