Ну, что вам рассказать про Байконур... на космодроме летная погода

Заканчивалась холодная осень 1998 года. Глаза устали следить за ужимками и прыжками курса доллара. Российский фондовый рынок лежал в реанимации, вероятность летального исхода оставалась высокой. Выжившие заказчики пребывали в ступоре.

   Активизировавшееся было общение с друзьями и знакомыми все больше стало сводиться к стандартному диалогу:
   - Как у вас?
   - Хреново! (Вариант: - Никак.) А у вас?
   - То же самое.

   Ежедневный многочасовый серфинг в Интернете назло провайдеру (я тебе покажу, что такое flat rate, - если уж дозвонился, то не вылезу) тоже начал надоедать.

   Письмо редактора "Компьютерры" Георгия Башилова внесло приятное разнообразие в монотонность праздных будней. Георгий писал, что:
   1) "Компьютерра", повернувшись лицом к российскому производителю, решила подготовить специальный номер (может, даже не один), посвященный российским разработчикам софта.
   2) В связи с этим выход моих статей задерживается на неопределенное время до завершения формирования номера.
   3) Поскольку номер выйдет не раньше середины января, не слабо ли мне подготовить материал о продукте Baikonur от фирмы Epsylon Technologies?

   "Не слабо!" - ответил я, тем более что этот продукт интересовал и меня.

   История знакомства
   Моя первая встреча с тем, что впоследствии стало называться "Baikonur", случилась летом 1996 года, когда я, будучи начальником отдела информационных технологий крупной брокерской фирмы, выбирал платформу и компанию-разработчика для реализации корпоративной информационной системы.

   Фирма Epsylon Technologies была известна мне как основной российский дистрибьютор и консультант по продукции фирмы Borland (ныне Inprise). Через Epsylon шло около 60 процентов продаж борландовских продуктов на российском рынке. К ней как к поставщику Delphi (на этом продукте была изготовлена работавшая в то время версия системы) я и обратился, рассудив, что если они продают продукт и являются ведущими специалистами по нему, то и от прикладной разработки не откажутся.

   Тут я оказался не прав - от разработки они отказались, так как это не соответствовало философии фирмы. Но приехавший на переговоры директор Epsylon Александр Сергеев продемонстрировал на ноутбуке свежее, только что разработанное решение для создания Web-приложений с помощью Delphi. Известное тестовое приложение Delphi (база данных рыбок) работало под Web-браузером, а выглядело и вело себя почти так же, как в родном GUI-интерфейсе. Причем исходный текст приложения, портированного под Web, практически не отличался ни по объему, ни по логике от исходного. Более того: разработка приложения велась в стандартной визуальной среде Delphi с помощью набора компонентов, практически дублирующего стандартный.

   Правда, чтобы все это работало, требовался специальный Web-сервер, также изготовленный Epsylon Technologies.

   Роман с Epsylon у нас не состоялся (мы искали команду для реализации проекта под ключ), но сама идея инструмента для визуальной разработки сложных Web-приложений показалась мне чрезвычайно интересной. Это был, вообще говоря, настоящий прорыв. Значимость его способны оценить те, кто сталкивался с задачей создания "в лоб" сложных Web-приложений, оперирующих с базами данных, и знает, какое это трудоемкое занятие и как плохо при этом работают получившиеся приложения, если не прилагать специальных усилий для их оптимизации.

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

width=300

   Традиционная технология разработки динамических Web-приложений основана на том, что на каждый приходящий от браузера запрос запускается так называемый CGI-скрипт, то есть отдельный с точки зрения операционной системы процесс, получающий параметры запроса и выполняющий необходимые действия по его обработке и формированию HTML-страницы, которая будет возвращена в ответ на запрос.

   В современных Web-серверах существуют разные модификации этого механизма: ISAPI (Information Server API), позволяющий не запускать отдельный процесс, а обращаться к функциям DLL; SSI (Server Side Include) и ASP (Active Server Pages), позволяющие описывать страницы с частично статическим, частично генерируемым содержимым, и др.

   Эти методы позволяют сделать более эффективным работу Web-приложений и облегчить проектирование динамических страниц, но не решают проблему бесконтекстности. По-прежнему нужно определять, как выполнять каждый запрос, то есть какие процедуры и/или задачи нужно запускать и в каком контексте.

   В частности, если используется ASP, то на каждый запрос должны быть порождены все необходимые COM-объекты, установлены соединения с базой данных, исполнены запросы, разорваны соединения с базой, уничтожены COM-объекты. Причем все это должно корректно работать в условиях, когда несколько запросов приходит одновременно. Вся эта кухня работает очень не быстро и требует довольно нетривиального программирования.

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

   При этом Web-сервер играет роль некоторого "коммутатора", связывающего Web-браузер пользователя и работающую в его интересах задачу на сервере. При этом у каждого пользователя может быть своя задача, или одна задача может обслуживать много (ограниченное или неограниченное количество) пользователей.

width=300

   Но такой подход немедленно порождает новые проблемы: задачи нужно запускать, когда в них возникает потребность, и убивать, когда потребность исчезает (например, пользователь отпал). Сервер должен уметь определять, какой из пришедших запросов какой задаче адресовать. И наконец, нужно иметь средства разработки задач, запущенных под управлением такого Web-сервера.

   Все это и было реализовано в продукте, продемонстрированном Epsylon Technologies.

   В декабре 1996 года эта разработка получила имя Baikonur и статус продукта. Продукт состоял из двух частей:

собственно Baikonur Web Application Server, умеющего запускать приложения, взаимодействовать и управлять ими, и

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

   Baikonur состоит из ядра и набора драйверов-обработчиков протоколов.
   Основными понятиями, которыми оперирует Baikonur Web Application Server, являются пользователь, сессия, приложение и протокол.
   Пользователь инициирует сессию по некоторому допустимому протоколу. Ядро сервера определяет тип протокола и обращается к обработчику соответствующего протокола. Обработчик идентифицирует пользователя принятыми для данного протокола методами и определяет, какое приложение должно его обслуживать.
   Ядро предоставляет широкий набор функций, которые могут быть использованы при разработке драйвера протокола, и стандартный интерфейс подключения. Поэтому набор драйверов протоколов легко расширяем. В настоящее время поддерживаются FTP, HTTP, DAAP, IIOP, LDAP, POP3, SMTP, IMAP4 и ряд других протоколов.
   Определив протокол и приложение и идентифицировав сессию, сервер создает так называемый блок управления подключением, и для данного пользователя запускается приложение (или присоединяется уже запущенное). Для запущенного приложения создается так называемая информационная магистраль (то есть канал подключения к серверу), через которую приложению приходят запросы на обслуживание и уходят ответы. Приложения могут быть одно- и многопользовательскими.
   Многопользовательские приложения должны самостоятельно хранить специфический контекст для каждого пользователя (если таковой имеется). Сервер сообщает многопользовательскому приложению все, что знает о пользователе, а так же о появлении новых пользователей и исчезновении старых. Эти сигналы приложение обрабатывает самостоятельно. Впрочем, это облегчено соответствующей реализацией компонентов, из которых собирается приложение.
   Сервер управляет всеми запущенными приложениями и TCP/IP-сессиями, обрабатывая прерывание и возобновление сессий, "слеты" и зависания приложений, находящихся под его контролем, и сам убивает приложения, оставшиеся без пользователей.
   Сервер умеет балансировать нагрузку. Поскольку многопользовательские приложения, как правило, не являются реентерабельными, то, не закончив обработку одного запроса, приложение не может начать обработку другого. Поэтому, если запросов к одному приложению много и обрабатываются они заметное время, имеет смысл запустить приложение в нескольких экземплярах, чтобы распределением времени между ними занималась операционная система.
   Сервер реализован с использованием многопоточной технологии, что позволяет достигать очень высокой производительности. Каждая пользовательская сессия и запущенное приложение ведется своей "нитью". Приложение, "отдав" серверу ответ на запрос, сразу освобождается для обработки следующих запросов. Далее отправкой ответа через сеть занимается "нить", ответственная за сессию.
   Все это позволяет серверу Baikonur работать в условиях массового обслуживания с очень высокой производительностью. Так, при испытаниях, проведенных фирмой Intel, на сервере с четырьмя процессорами Pentium и 512 Мбайт оперативной памяти успешно имитировалось 10 тыс. одновременно работающих пользователей, запустивших 700 приложений.

   Следующая моя встреча с Baikonur произошла весной 1998 года на форуме РОЦИТ. За обеденным столом я обменялся визитками с сотрудником Epsylon Technologies Андреем Чесноковым. Увидев на его визитке надпись "руководитель проекта Baikonur", я решил проявить эрудицию и сказал, что с Байконуром знаком, что это космодром в Казахстане и заодно система для разработки сложных Web-приложений на Delphi. Чесноков поморщился и сообщил, что на самом-то деле Baikonur - это телекоммуникационный многопротокольный монитор транзакций, а Delphi и Web-серверы - это так, дань конъюнктуре. Чем заинтриговал меня чрезвычайно, так как про мониторы транзакций я слышал, но глубоко с ними не разбирался, а причем тут "телекоммуникационный и многопротокольный", для меня вообще было загадкой. Продолжения этот разговор тогда не получил.

   Время от времени до меня доходила информация, что Baikonur используется Центральным банком, компанией "Лукойл", "Аэрофлотом", "Онэксим-банком", еще кем-то. Время от времени я поглядывал новости на Web-сервере Epsylon (www.demo.ru).

   Следующий шаг - JAT и Taxxi
   Летом 1998 года появились пресс-релизы о новом продукте компании Epsylon, названном JAT (Java Application Terminal). Вкратце, это такое Java-приложение, которое умеет отрисовывать картинки, передаваемые ему Baikonur-сервером от задачи, работающей на сервере.

width=300

   Чтобы понять, что это такое и зачем это нужно, вспомним об эволюции Интернет-приложений. Толчок нынешнему развитию Интернета дало появление HTTP, Web-серверов и Web-браузеров. Но простота "pure web" интерфейса скоро стала тормозом на пути развития Интернет-приложений. Развитие языков скриптов (Java script, VB script), новые версии HTML, новые протоколы (ShockWare и др.), средства доставки и запуска приложений на компьютеры пользователей (Java, ActiveX) стремятся к одной цели - возможности создавать Интернет-приложения, по удобству интерфейса не уступающие традиционным GUI-приложениям и при этом пользующиеся всеми преимуществами работы в глобальной распределенной сети. Предельным выражением этой тенденции являются специальные загружаемые приложения, использующие собственные протоколы и серверы и рассматривающие Интернет только как транспортную среду.

   Можно по-разному проектировать интерфейс и распределять логику приложения между частью, работающей на сервере, и частью, работающей на компьютере пользователя. Критериями здесь является удобство интерфейса, объем сетевого трафика, создаваемого приложением, трудоемкость действий, необходимых для запуска приложений, сложность разработки и администрирования. Эти критерии зачастую противоречат друг другу. Минимальный трафик и самый удобный интерфейс у специализированного приложения, наиболее трудоемкого в установке, разработке и администрировании, - и максимальный трафик и самый примитивный интерфейс у чистого Web-приложения, стартующего моментально с любого компьютера и наиболее простого в администрировании.

   JAT - это некоторый разумный компромисс между указанными выше критериями. На компьютер пользователя должно быть загружено небольшое (порядка 100 Кбайт) Java-приложение, которое не содержит никакой бизнес-логики и поэтому поддерживает все приложения, разработанные под JAT. При этом компьютер пользователя занимается только отрисовкой интерфейса, передаваемого с сервера, и передачей на сервер событий, инициированных действиями пользователя.

   Интерфейс представлен множеством объектов, отрисовкой каждого из которых занимается отдельный Java-класс. В случае отсутствия у клиента Java-класса, ответственного за отрисовку некоторого типа объекта, появившегося в новом приложении, он автоматически подгружается с сервера. По сети идут только изменения свойств объектов, за счет чего трафик удается делать исчезающе малым. Разработчики утверждают, что большинство JAT-приложений нормально работают на скорости соединения 4800 бит/с.

   Протокол JAT формально инкапсулирован в HTTP, хотя, естественно, не имеет смысла для обычных браузеров.

width=300

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

   Таким образом, JAT - это следующий прорыв Epsylon Technologies, позволяющий промышленным образом не только разрабатывать Интернет-приложения, как обычные, но и создавать приложения, которые на компьютере пользователя ведут себя так же, как и стандартные GUI-приложения.

   Следующий шаг не заставил себя долго ждать. Осенью 1998 года общественности был предложен специализированный клиент, названный Taxxi. Он работает с теми же приложениями и по тому же протоколу, что и JAT, но в 10-20 раз быстрее. Платой за это является зависимость от операционной среды (сейчас Taxxi имеется только для Windows-сред) и необходимость инсталляции. При этом сам Taxxi не включает в себя телекоммуникационных функций, используя для этой цели телекоммуникационные возможности ядра сервера Baikonur (который тоже должен быть установлен на компьютере пользователя). Впрочем, размеры всего этого хозяйства позволяют без особых проблем скачать его через сеть (Taxxi - менее 400 Кбайт, Personal Baikonur - менее 1 Мбайт).

   В принципе, той информации, которой я располагал, было вполне достаточно для написания небольшой статьи. Но у меня не шли из головы слова о "многопротокольном сервере транзакций". Кроме того, на сервере не удалось найти практически никакой информации о success story продукта, его предыстории, позиционировании на рынке и планах компании.

   Поэтому, получив заказ на статью, я созвонился с Андреем Чесноковым и отправился в знакомый многим "Демо-центр" Epsylon, что на улице Нарвской неподалеку от станции метро "Водный стадион".

   История проекта
   До 1995 года Epsylon спокойно продавала продукты фирмы Borland, а ее программисты занимались тестированием, разработкой примеров и прочей деятельностью по обеспечению пользователей.

   Взрывообразный рост Интернета поставил на повестку дня вопрос присутствия Epsylon в Web-пространстве. Было решено создать не только презентационный сайт фирмы, но и большой, интересный игорный сайт: как маркетинговый, а в перспективе и коммерческий проект. Заодно это позволило бы программистам повысить квалификацию и протестировать имеющиеся технологии разработки Интернет-приложений.

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

   Поискав на рынке инструментария и не найдя ничего подходящего, специалисты Epsylon Technologies констатировали наличие рыночной ниши средств быстрой разработки Web-приложений. В это же время в Epsylon пришла группа программистов, занимавшихся разработкой систем асинхронного межпроцессорного обмена данными в транспьютерных сетях и телекоммуникационным монитором "Обь" на мэйнфреймах EC.

Телекоммуникационными мониторами на IBM'овских мэйнфреймах назывались системы, позволяющие задаче общаться с интерактивным терминальным оборудованием. Они не были органической частью операционной системы - последняя изначально ориентировалась на режим пакетной обработки. Монитор предоставлял задаче набор вызовов, с помощью которого происходило ее общение с терминалом, при этом не раскрывая задаче особенностей конкретных устройств. Наиболее известные мониторы - CICS (IBM) и Compleet (Software AG).
"Обь" - оригинальная отечественная разработка. Кроме своего собственного интерфейса она поддерживала стандартные еэсовские телекоммуникационные методы доступа (протоколы) БТМД и ОТМД и огромный терминальный парк - несколько десятков типов устройств. "Обь" была широко распространена в СССР, под ней работало 40 процентов всех машин ЕС, против 15 процентов - под CICS. "Обь" была существенно менее требовательна к ресурсам, чем CICS, имела более удобный интерфейс разработчика и поддерживала гораздо больше типов терминалов, включая редкие тогда персоналки.

   После этого проект обрел конкретные очертания: телекоммуникационный монитор транзакций для протоколов, базирующихся на TCP/IP, и соответствующие библиотеки для разработки в его среде.

   Самой трудной задачей этого этапа, по словам Андрея Чеснокова, было создание команды проектировщиков из системных программистов старой школы и "борландовских" программистов, - слишком уж разное у тех и других профессиональное мировоззрение. Но именно сплав "старой школы", воспитанной в традициях многозадачных и хорошо структурированных операционных систем IBM'овских мэйнфреймов и сохранившей навыки борьбы за эффективность, - с разработчиками, привыкшими к RAD-инструментам, позволил обеспечить уникальное на сегодняшний день сочетание удобства разработки приложений и производительности, отличающее Baikonur.

   17 декабря 1996 года была выпущена первая "коробочная" версия. К этому времени уже несколько компаний-разработчиков лицензировали у Epsylon эту технологию.

   Летом 1998 года был запущен игровой сайт www.games.demo.ru, где несколько карточных игр наглядно демонстрировали технологии Baikonur. По словам Чеснокова, игры были реализованы буквально за несколько недель программистом-практикантом. Спустя месяц трафик сервера резко увеличился. Анализ показал, что большая часть обращений идет из США, причем от пользователей приставок Web-TV. Потом начали приходить письма с благодарностями - в основном от инвалидов. Оказалось, что это один из немногих сайтов, где с приемлемой скоростью работают игры, в которые можно играть с приставок, а эти приставки американская служба социального обеспечения широко раздавала по программе социальной помощи инвалидам.

   После этого игры были быстро "заточены" под Web-TV (в них используется язык чуть более богатый, чем стандартный HTML); впрочем, сохранена возможность их работы и в стандартном HTML.

   Сейчас сервер генерирует 7 процентов мирового трафика Web-TV (число посетителей перевалило уже за 180 тысяч). За те четыре часа, что я провел в "Демо-центре", на сервере побывало более двух тысяч пользователей, сгенерировавших свыше 120 тыс. хитов. Сервер за это время отгрузил порядка 200 Мбайт. И все это на Pentium 133 c 64 Mбайт памяти!

   К сожалению, получить подробную информацию о том, где и для чего используется сегодня технология Baikonur, мне не удалось. Сами авторы располагают далеко не полной информацией о конечных проектах, не говоря уж о том, что не всегда имеется санкция на раскрытие этой информации от разработчиков конечных продуктов.

   Во всяком случае, уже продано более трехсот лицензий. Среди покупателей много известных российских компаний, две американские, четыре немецкие и две французские. В течение последних месяцев с www.demo.ru ежемесячно отгружается более трехсот копий trial-версии Baikonur Web Application Server.

Если сравнивать технологию Baikonur с конкурирующими продуктами, оказывается, что существует три традиционно различающихся класса таковых:

Web-серверы приложений - Netscape (ex-Kiwa), Oracle, Sun (NetDynamics), Progress, Haht, BlueStone, Appitivity, ColdFusion и др.;

терминальные серверы со сверхтонкими клиентами - Citrix WinFrame, Microsoft Hydra и др.;

мониторы транзакций - IBM CICS, BEA Tuxedo, MTS и др.
   К сожалению, в коротком обзоре невозможно рассказать обо всем, чем отличается Baikonur от вышеперечисленных групп. Более того, мониторы транзакций и Web-серверы приложений все очень разные, основаны на разных концепциях, имеют разную функциональность и, в конечном счете, имеют довольно мало общего, поэтому сравнивать нужно с каждым конкретным продуктом.
   Но, по утверждениям специалистов Epsylon, проводивших такой анализ, в каждом случае сравнение с Baikonur обнаруживает множество крупных и мелких различий, как правило, осложняющих разработку и/или увеличивающих сетевой трафик приложения и почти всегда снижающих стойкость сервера к нагрузке.
   Для выбранной предметной области (сложные Интернет-приложения, рассчитанные на массовое обслуживание) эти количественные по своей природе различия в трудоемкости разработки и требованиям к производительности аппаратного сервера быстро переходят в качество, зачастую выводя проект за границы реализуемости при разумных затратах.
   Кроме того, Baikonur является перспективной платформой для разработки того, что обычно называется instant communications (общепринятый русский перевод отсутствует) - продуктов, обеспечивающих прямое (не опосредованное серверами) мгновенное взаимодействие клиентов друг с другом. Примером такого средства является широко известная программа ICQ (Mirabilis, ныне AOL).
   Все реализованные в Baikonur механизмы где-то да встречаются, но по сочетанию набора реализованных функций, потенциалу расширения, скорости разработки приложений и способности держать нагрузку технология Baikonur, по-видимому, уникальна и не имеет прямых конкурентов.

   Все это, конечно, замечательно, но самое интересное ждало меня впереди.

   Интернет-3
   Оказалось, что, не ограничиваясь ролью поставщика хорошего инструментального средства, Epsylon нацелилась ни больше ни меньше как на реформирование Интернета!

   Идеологической подоплекой стало утверждение о том, что сочетание производительности, компактности и легкости разработки приложений, достигаемое с помощью средств разработки семейства Baikonur, способно кардинально изменить лицо Интернета, породив то, что директор Epsylon Александр Сергеев называет "Интернет-3".

   Интернет-3 характеризуется

широким использованием полнофункциональных "сверхтонких" клиентов (типа Taxxi), способных работать на любых мобильных устройствах и обеспечивать работу с приложениями любой сложности;

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