Ранее, я работал в компании FutureTrade Rus. которую купила
Interactive Brokers Group о чем официально стало известно 20 ноября 2007 года. Покупка, к сожалению, состоялась по цене гораздо ниже ожидаемой и желаемой. Затем, стало известно о публикации в журнале. Про которую 'злые языки' говорят что она полностью заказная и предназначалась для 'набивания цены' объекту покупки. Трудно оспаривать источники инсайдеровской информации, да и не по мужски это.
Рассмотрим предмет продажи а не флуд вокруг сего факта, более детально с позиции архитектуры. Система в FutureTrade'е имеет полностью Java платформу как на стороне клиента так и на сервере. Бухгалтерские проводки, отчеты, импорты/эксопрты, тоталы и остальной 'backoffice' - рассматриваться не будет.
Архитектура в кубиках
Клиент - Java приложение, которое имеет не только хорошую систему визуализации и всякие полезности для трэйдера, но и обновляется из централизованного репозитория через Java Web Start.
Клиент общается со специализированными серверами frontend'а (которые называются 'Connection Server') по защищенному протоколу поверх TCP/IP. Клиенты имеют различные модули подключения к 'Connection Server'ам. Причем, каждый такой сервер подключения работает с клиентом по своему протоколу. Существовало решение (на тот момент когда я там еще работал) для протоколов: FIX (4.0-4.2), пропраитари протокол поверх TCP/IP и HTTP. Не зависимо от выбора протокола обеспечивается гарантированная доставка сообщений.
Connection Server - Java приложение, которое принимает от клиента сообщения в одном формате по конкретному протоколу и транслирует их во внутренний формат системы с последующей их передачей серверам backend'а (и наоборот). Поддерживает уровень сессии и отвечает за балансировку нагрузки при распределении сообщений между серверами backend'а (которые называются 'Execution Server'). Между серверами фронтенда и бекенда используется RMI/IIOP протокол. Причем, при проектировании я старался объединить приемущества Java удаленных вызовов RMI и транспарантность CORBA протокола. В результате получились быстрые удаленные вызовы лишенные недостатков RMI и использующие все достоинства IIOP.
Execution Server - Java приложение, которое отвечает за маршрутизацию сообщений, их обработку и диспетчеризацию ответов. Имеет бизнесс логику и связь с БД. Видоизменяет оригинальные сообщения пользователя и принимает решание по их дальнейшему распространению. Под сообщениями пользователя подразумеваются различные команды на покупку/продажу еквити, опционов, хомяков... Дальнейшее распространение сводится к передаче результирующего сообщения либо назад к клиенту либо к 'Transceiver' модулю для последующей передачи в точку назначения (NASDAQ,SOES,...). Передача осуществяется также по RMI/IIOP.
Transceiver - Java приложение, обеспечивает функциональность ассиметричную 'Connection Server'у. Получает сообщения в пропраитари формате и транслирует их во внешний формат с поддержкой уровня сессии и секъюрности. Типичный пример - FIX соединение с прайм брокером.
Архитекторы
Сие, как на этапе проектирования так и при дальнейшем развитии осуществлялось моими коллегами. Хоть и заказная статья в журнале 'Мурзилка' совершенно без деталей делает заключение о превосходстве архитектурных решений примененных в FutureTrade (в футуре) они, по крайней мере не ошибаются в неординарности и нестандартности таковых. Те кто построили такую архитектуру - это люди не побоявшиеся инноваций и отвечающие за свои слова и решения. Они не делают примеры из учебников и букварей по J2EE (хотя это они могут), они не строят 'классику' как истребитель в крыльях Люфтваффе под крышей, и мне приятно что я с ними работал!
Борис Беркман - технический директор и координатор всей технологии.
Клиент:
Валерий Иванов, Михаил Яковлев, Дмитрий Тарасов
Connection Server / Execution Server:
Александр Антропов, Павел Абушик
Transceiver:
Евгений Трунов, Алексей Антипин, Михаил Власов
Футура для футуры
Что ждет FutureTrade в ближайшее время? С учетом того, что их новый хозяин имеет много наработок и backend писанный на C++ и заинтересован в клиенте от FutureTrade и его кастомеровской базе, то самой большой глупостью будет потерять тех специалистов которые все это поднимали. Я не буду обсуждать намерения и уж тем более осуждать их. Но если новый хозяин хочет интеграции футуровского клиента со своими серверами, даже в этом случае (если новому хозяину не нужен backend) не нестандартность, но дальновидность архитектуры футуры поможет. Когда новый хозяин захочет клиента от футуры а сервера от себя, потребуется всего лишь подпилить компонент типа 'Connection Server' научив его работать с новым сервером по новому пропраитари протоколу. А заложенная в фундамент архитектуры CORBA позволит легко осуществить взаимодействие между Java Connection Server и C++ Execution Server :) Однако, если новый хозяин выкинет нахрен все наработки футуры и оставит только девелоперов - он потеряет но не проиграет.
Будьте дальновидны, коллеги.
Всегда отвечайте за сой базар и за принятые решения.
Имейте мужество отстаивать крайние решения, а не всеобщий компромис.
