пятница, 18 января 2008 г.
среда, 5 декабря 2007 г.
Про футуру и архитектуру
Ранее, я работал в компании 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 :) Однако, если новый хозяин выкинет нахрен все наработки футуры и оставит только девелоперов - он потеряет но не проиграет.
Будьте дальновидны, коллеги.
Всегда отвечайте за сой базар и за принятые решения.
Имейте мужество отстаивать крайние решения, а не всеобщий компромис.
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 :) Однако, если новый хозяин выкинет нахрен все наработки футуры и оставит только девелоперов - он потеряет но не проиграет.
Будьте дальновидны, коллеги.
Всегда отвечайте за сой базар и за принятые решения.
Имейте мужество отстаивать крайние решения, а не всеобщий компромис.
понедельник, 19 ноября 2007 г.
myPicturetown upgraded to 1.2
http://www.mypicturetown.com
Задеплоили новую версию (1.2)
Из улучшений:
- багофикс
- перфоманс подтюнили
- красивостей (удобностей) добавили
Задеплоили новую версию (1.2)
Из улучшений:
- багофикс
- перфоманс подтюнили
- красивостей (удобностей) добавили
пятница, 16 ноября 2007 г.
Ошибка в JDBC 3 драйвере к PostgreSQL
Пользовали JDBC 3 драйвер версии 8.0.39 к PostgreSQL 8.1 и наблюдали странную картину. Если делать запись в поле типа timestamp без тайм зоны то записанное значение иногда отличается на 1 час от того которое там должно быть.
Почему иногда:
Записи дат и времени до 2037 года и через драйвер и SQL скриптом с консоли приводят к одинаковым результатам и ошибки не возникает. Для дат и времени после 2057 года наблюдается такая картина. Зимнее время - записывается без ошибок. Летнее время на 1 час отстает. Пишем '2057-06-20 15:47:42.625' через драйвер получаем в базе '2057-06-20 14:47:42.625'. Если тоже записать через SQL консоль - ошибок нет.
Обновили драйвер до версии postgresql-8.1-410.jdbc3.jar - ошибки записи пропали, все работает.
Коллеги, будьте внимательны!
Почему иногда:
Записи дат и времени до 2037 года и через драйвер и SQL скриптом с консоли приводят к одинаковым результатам и ошибки не возникает. Для дат и времени после 2057 года наблюдается такая картина. Зимнее время - записывается без ошибок. Летнее время на 1 час отстает. Пишем '2057-06-20 15:47:42.625' через драйвер получаем в базе '2057-06-20 14:47:42.625'. Если тоже записать через SQL консоль - ошибок нет.
Обновили драйвер до версии postgresql-8.1-410.jdbc3.jar - ошибки записи пропали, все работает.
Коллеги, будьте внимательны!
среда, 14 ноября 2007 г.
Нервные клетки заставят восстанавливаться
Восстановление спинного мозга может стать возможным уже в ближайшем будущем. Учёные выяснили, что естественную регенерацию в данном случае останавливает сам мозг. И научились отключать этот механизм. Осталось научиться включать обратный.Современные клеточные технологии позволяют замещать дефекты практически всех тканей человеческого организма. Однако нервная ткань до сих пор оставалась непостижимой для тканевых инженеров. Теперь выясняется, что для её восстановления растить что-то в пробирке может и не понадобиться.
Далее...
Подписаться на:
Сообщения (Atom)