Сергеев А.
Epsylon Technologies

Название Baikonur Web App Server появилось благодаря любопытной аналогии. Байконур - это космодром в Казахстане, с которого запускали и запускают ракеты-носители. Baikonur Web App Server - это сервер для Windows NT и Windows 95, который умеет запускать удаленные приложения.

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

Итак, Baikonur - это одновременно и Web-сервер, и сервер приложений.

Web-сервер работает так:

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

Разработчики давно поняли, что ограничиваться лишь статическими ресурсами - это значит губить идею, и вот появились десятки стандартов для того, чтобы расширить возможности Web-серверов динамически формируемыми ресурсами. Наиболее известные расширения - это стандарты CGI, NS API и ISAPI.

Вот как происходит работа с этими стандартами:

В случае CGI по запросу от браузера стартует CGI-процесс, который и производит динамическую html-страничку, которая, в свою очередь подсовывается серверу. Сервер ее отсылает браузеру, пославшему такой запрос. Выполнение запроса, работающего с CGI, - дело долгое. Ведь для того, чтобы сформировать динамическую страничку, сервер должен стартовать новый CGI-процесс, а после формирования странички - уничтожить его. При массовой бомбардировке сервера запросами возникает проблема производительности.

Интерфейсы ISAPI от Microsoft и NS API от Netscape решают вопросы производительности предоставлением чисто функционального интерфейса к своим серверам. При этом новый процесс не стартует, а построение динамических страниц происходит в потоках (тредах) внутри сервера.

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

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

Однако существует огромная разница перед программированием ресурсов и объектным программированием. Последнее на порядок производительнее.

Очень хороший пример - разница между Borland C++ и Borland C++ Builder. И там, и там все-таки требуется писать код. Однако, скорость производства готовой системы, особенно, если речь идет о системе с применением баз данных, различается чуть ли не раз в десять. Я считаю, что основная причина заключается в различии подходов - в первом случае это программирование ресурсов, а во втором - визуальная сборка при помощи объектов-компонент.

Но что мешает собирать Web-приложения при помощи объектов-компонент? Может, стоит чуть-чуть под другим углом представить себе функционирование Web-системы?

В самом деле, может стоит попробовать?

Давайте вначале попробуем забыть о том, что на свете существует такое понятие, как статический ресурс.

Будем рассматривать пользовательский браузер, как удаленный терминал. Сложный терминал, поддерживающий HTML, JavaScript и даже Java-расширения. Представили? Попробуем применить на практике. Не получается? Мешают технические ограничения существующих серверов? Вот так и появился на свет Baikonur Web App Server.

Из соображений общности можно рассматривать любой статический ресурс как задачу, которая этот статический ресурс подсовывает серверу для дальнейшей передачи таким, какой он есть, без изменений. Или, скажем, изменяя только кодировку. Например, с Win1251 в KOI8-R. Чувствуете возможности?

Дело за малым - сделать такой сервер.

Только теперь, по прошествии значительного времени, я понимаю за какую сложную задачу мы в свое время с энтузиазмом взялись. Ведь функции такого сервера ни много, ни мало, напоминают функции операционной системы. Именно ОС занимается тем, что запускает и освобождает задачи, именно в задачи ОС входит разрешение клинчевых ситуаций, распараллеливание и прочее. Если заглянуть в код сервера, то понимаешь, что только 3 процента кода заняты собственно функциональностью Web, а на остальные 97 ложатся функции управления операционной системой (Windows NT или Windows 95) чтобы все работало так, как задумано. Визуальное программирование серверной логики

Ну, а теперь посмотрим, какие возможности дает такой сервер для разработчика. Мы уже говорили о том, что наивысшую производительность для программиста дает возможность строить свое приложение из компонент, например, из визуальных компонент. Именно так происходит строительство приложения в Borland Delphi или в Borland C++ Builder. Именно так и хотелось бы строить приложения для Baikonur Web App Server в этих инструментах. Все, что для этого требуется, так это то, чтобы визуальная часть приложения строилась из компонент, которые представимы на нашем HTML-терминале.

Назовем такие компоненты HTML-компонентами.

В состав Baikonur Web App Server входят три странички с такими компонентами, которые появляются в Delphi или C++ Builder после инсталляции.

На страничке HTML размещаются HTML-аналоги обычных визуальных компонент Delphi - кнопки, радиокнопки, чекбоксы и элементы, не имеющие аналогов в Delphi - теги, рулеры и т.п. Две компоненты - HTMLControl и HTMLPage являются невизуальными и предназначены для связи приложения с сервером.

На страничке HTML Add размещены полезные компоненты для работы с файлами, а также компонента, реализующая возможности HTML таблицы.

На страничке HTML DB размещены HTML-аналоги для работы с базами данных. И устройство у них точно такое же, как и у обычных чувствительных к данным компонент Delphi и C++ Builder.

Идея построения таких компонент понятна - мы хотим строить приложения для исполнения на сервере точно так же, как строили приложения для архитектуры клиент-сервер. Только в архитектуре клиент-сервер вся логика, за исключением хранимых процедур, исполнялась в клиентском приложении. В случае Baikonur логика частично выполняется на сервере приложений, а частично (HTML) передается браузеру удаленного клиента.

И вот тут вступает в действие вторая космическая аналогия - шаттлы.

Каждое из приложений, запущенных под управлением сервера Baikonur, состоит из HTML-компонент и обычных компонент. Каждая HTML-компонента состоит из основной (Object Pascal или C++) и отделяемой (HTML, JavaScript, Java, ActiveX ) части. В момент коннекта (пользователь при помощи браузера послал запрос к серверу) приложение получает уведомление от сервера о том, что надо собирать страничку. Для разработчика все эти действия происходят незаметно - их совершают служебные компоненты. Теперь с текущей активной формы приложения все действующие HTML-компоненты собирают эскадрилью отделяемых частей. Из таких частей приложение собирает текущую версию HTML-странички, и передает ее серверу. Клиентский браузер получает ее от сервера и отображает. Пользователь вводит информацию на поля ввода страничной формы, или производит какие-либо другие действия, и введенные данные возвращаются челноком обратно приложению, которое распределяет полученные данные между объектами приложения.

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

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

А где же тут место для Java? -спросите вы.

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

Однако, было бы глупо отказываться от дополнительных возможностей только ради чистоты идеи.

Вот каким образом расширяется функциональность HTML при помощи JavaScript. Внимательно посмотрим на свойства какого-либо HTML-компонента.

Мы видим несколько свойств с префиксом JS. Эти свойства предназначены для хранения реакции на события, происходящие на клиентском браузере. Реакция на события прописывается при помощи JavaScript.

Например, мы можем определить реакцию на изменение статуса HTML-элемента, например, чекбокса. Стандартно при изменении состояния чекбокса сервер не должен получать уведомления об изменении состояния. Только при нажатии кнопки Submit все изменения, произведенные пользователем в браузере, пересылаются на сервер. Для стандартного HTML шаттл возвращается не сразу, а только набрав фактически оффлайновые изменения. Иногда такой режим не слишком удобен. И его можно изменить при помощи JavaScript.

Это - самое простое, что можно делать при помощи JavaScript.

Еще большей функциональности можно достичь использованием Java апплетов или ActiveX. Примечательно, что все это время архитектура Baikonur помогала достичь ясности при проектировании довольно сложной системы. Вопросы производительности

Может возникнуть довольно каверзный вопрос - а не пришлось ли заплатить за такую ясность производительностью. Так часто бывает; и вопрос для того, кто выбирает технологию для интрасетей, а не для Internet, где производительность может быть смазана плохими линиями, далеко не праздный. Давайте разберемся, из чего складывается производительность всей системы.

Это восемь основных факторов. Начнем перечисление в направлении от клиента к серверу и попытаемся оценить, насколько каждый из них влияет на производительность системы в целом. Пусть пользователь желает поработать с базой данных, опубликованной в Сети.

Первый фактор, с которым пользователь имеет дело - это быстродействие своей собственной машины. Если система существенно использует Java апплеты, то пользователю придется мириться с несовершенством своей персональной техники, и даже компиляторы Just in time вряд ли существенно смогут помочь. При использовании ActiveX производительность возрастает, но зато насущными становятся вопросы безопасности. При использовании технологии только активных страниц первый фактор перестает играть значение, поскольку обработка HTML-страниц (фактор 2) происходит очень быстро и не требует ресурсов от клиентского компьютера.

Фактор 2 (интерпретация HTML-страниц), как уже говорилось, имеет небольшое значение для быстродействия всей системы в целом, однако, если используется совсем уж устаревшая техника (286 или 386 компьютеры), то и он может быть существенным.

Фактор 3 - пропускная способность линии, играет роль в случае модемного соединения, но даже в этом случае количество передавамой информации для технологии HTML-страниц весьма невелико - 1-3Кб, поэтому даже для модемного соединения быстродействие остается психологически приемлемым. Для случая интрасетей затраты на траффик пренебрежимо малы даже тогда, когда в локальной сети одновременно работают сотни пользователей - свои 2 Кб каждый получает с минимальной задержкой, и даже если нагрузить странички несколькими картинками килобайт по 30-40 (для красоты), время отклика остается достаточно быстрым.

Все, что мы говорили до сих пор, касалось только быстродействия клиентского соединения. Все остальные факторы, а для интрасетей и предыдущий пункт, касаются многопользовательской работы - фактически задачи массового обслуживания. Насколько быстродействие сервера велико для того, чтобы обслужить одновременно сотни пользовательских коннектов? На этот вопрос хорошо подходить с позиции сравнения. Существуют достаточно удачные пакеты для тестирования Web серверов, например, пакет WebBench от концерна Ziff-Davis. Результаты предварительных испытаний показывают, что Baikonur Web App Server в режиме keep-alive показывает 25 процентное преимущество над самым быстрым из на сегодня известных Web-серверов для Windows NT. В режиме коннект-дисконнект при выборке статических ресурсов (статических HTML-страниц) , быстродействие у Baikonur Web App Server ниже, и механизм этого замедления понятен - у Baikonur Web App Server отсутствует кэш для статических страниц. В Baikonur Enterprise такой кэш уже введен, и все становится на свои места.

В случае, когда мы работаем с задачей массового обслуживания, критичным становится и интерфейс между сервером и процессом, генерирующим динамические страницы. В случае CGI быстродействие такой связи более, чем неудовлетворительно. В случае ISAPI или NS API связь устроена совсем по-другому, и работает заметно быстрее. Линк же между приложением и Baikonur-сервером устроен максимально быстро, поэтому замедление на этом участке пренебрежимо мало.

Быстродействие серверной логики. В случае Baikonur логика сервера формулируется на языке Object Pascal или C++, а затем компилируется при помощи оптимизирующего компилятора Borland. Согласитесь, что такая логика должна исполняться существенно быстрее, чем написанная при помощи интерпретатора Perl или JavaScript или VB или любого другого интерпретатора. Кроме того, компиляторы Borland позволяют параллелить исполнение участков кода в потоках (тредах), что позволяет значительно увеличить быстродействие всей системы в целом.

Теперь мы переходим к факторам, на быстродействие которых Baikonur уже не может оказывать влияния - поскольку определяется оно выбранным инструментом. И для случая Delphi, и для случая C++ Builder линк к базе данных построен по одинаковой технологии - это IDAPI и SQL -линк. Фактически это представляет собой обрамленный в Delphi-компоненту родной линк к соответствующей базе данных. Для Oracle - это SQL Net, для DB/2 - CAE, для Informix - On Net PC. Можно использовать и ODBC, но, как правило, связь при помощи IDAPI и SQL Link работает заметно быстрее. Мы видим, что и в этом случае выбран максимально производительное решение.

Остался последний фактор - быстродействие БД. В данном случае мы оставляем выбор разработчику. Выбирать есть из чего. Данные могут храниться как в формате персональной БД (Paradox, dBase, FoxPro, Access) или в распространенных SQL-серверах (Oracle, Informix, Sybase, MS SQL, Borland IB, DB/2). Все другие форматы доступны через ODBC драйверы. Вообще говоря при такой схеме работы база данных может располагаться и на физически другом сервере.

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

Очень трудно сравнивать. Фактически для того, чтобы сравнить какую-либо из известных технологий, надо постараться построить максимально корректный аналог системы, которая испытывается на Baikonur. Знаете, после того, насколько быстро система строится при помощи визуальных компонент для Baikonur Web App Server, неуклюжесть других технологий просто раздражает. Хотя, конечно, я пристрастен.

Мы получили совершенно невероятные цифры, поэтому правильно было бы дождаться результатов независимого сравнения. Скажу лишь, что быстродействие системы с использованием БД, публикуемой при помощи технологии Baikonur, не менее чем в 10 раз (а то и больше) лучше, чем все то, с чем мы экспериментировали еще. Но обязательно сделайте скидку на субъективный характер исследований!

В голову приходят любопытные соображения. При затратах на серверное оборудование 2-3 тыс долларов и $300 на приобретение Baikonur Web App Server вы получаете в придачу стоимость еще по меньшей мере девяти компьютеров, что составляет $18000. Не правда ли, забавные цифры? Выигрыш $15000 - это существенно, не так ли? Затраты на информационную интрасистему

Если уж мы стали обсуждать вопросы экономические, стоит рассмотреть и другие аспекты экономии при построении корпоративной системы на основе технологии интрасетей с использованием Baikonur. Следующее, что приходит в голову, что в лицензионной политике нет оплаты (и ограничений!) за одновременное количество подключений. Клиентское место обходится в стоимость браузера (сколько стоит браузер?). Можно не производить upgrade существующего клиентского железа (кажется, выше говорилось что-то про 386?). Нужен только сервер помощнее.

Стоп! А насколько мощным должен быть сервер? Не здесь ли и находится мышеловка, поджидающая любителей бесплатного сыра?

Давайте-ка разберемся с этим вопросом поподробнее. Итак, пусть в нашей корпоративной системе 250 пользователей. Каждый пользователь запустит по одному приложению. Каждое приложение отъедает примерно по 1.5-2 Мб оперативной памяти. Получаются солидные цифры! На сервере надо всего ничего - 250х2Мб=500 Мб оперативной памяти! И еще вопрос, сколько требуется дополнительной памяти, выделяемой сервером на каждое клиентское подключение.

Как же обстоит дело в действительности?

Начнем в обратной последовательности. На каждый клиентский коннект сервер выделяет 9 кб под служебные буферы. Ни больше ни меньше.

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

То есть существует возможность использования приложений в режиме - каждому клиенту - своя копия приложения. Но существует режим и такой - все клиенты взаимодействуют с одной копией приложения, а приложение для каждого клиента выполняется в новом потоке (треде).

Давайте посмотрим, как можно превратить однопользовательское приложение в многопользовательское.

Для того, чтобы превратить однопользовательское приложение в многопользовательское, надо установить свойство MultiUser равным True. Тогда приложение будет динамически выделять свой набор экземпляров объектов при подсоединении нового пользователя. Конечно, программирование многопользовательского приложения требует большей аккуратности от разработчика, ведь ему нужно всегда держать в голове тот факт, что одновременно к его программе могут обращаться сотни пользователей.

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

Стоит упомянуть о существенном снижении затрат на программирование и администрирование корпоративной системы. На клиентский компьютер ничего, кроме браузера, не устанавливается, а следовательно, и не ПЕРЕустанавливается по мере развития корпоративной системы, а такая система всегда живет и развивается. Сопровождение 20 компьютеров - это уже адский труд, а о сотнях персональных рабочих мест и говорить не приходится.

Второй аспект - это стоимость разработки и сопровождения системы. Baikonur не предполагает переучивать программистов разработчиков и осваивать новую инструментальную среду. Разработка ведется в таких распространенных и доступных инструментах, как Borland Delphi и Borland C++ Builder. Это массовые инструменты, и квалифицированных специалистов по ним существует в достатке.

Третий аспект касается тех предприятий, которые уже вели клиент-серверные проекты на Delphi. Перенос такого проекта происходит достаточно просто, и положительный опыт уже имеется.

Я уже говорил о том, что информационную систему реально можно построить на базе 300-долларовой версии Baikonur. Однако следует заметить, что в данном случае разработчики в России получают шанс доступа к сервису, который раньше был только доступен в Соединенных Штатах, поскольку именно там производится основное количество инструментальных средств. Корпоративные разработчики в США имели возможность получить более плотный контакт с фирмой-производителем инструментальных средств на основе контракта, предполагающего тесное взаимодействие прикладных и инструментальных разработчиков. В рамках такого контракта фирмой-производителем производится курирование корпоративной разработки и дополнительная передача новых технологий. Теперь такая форма взаимодействия доступна и в России, поскольку Epsylon Technologies - российская компания. В каком направлении идет разработка новых версий Baikonur

С момента выхода коммерческой версии продукта в конце декабря 1996 года мы почувствовали всплеск интереса к нашим технологиям. Реализованы или находятся в стадии реализации крупные корпоративные проекты, полным ходом работают учебные курсы, на которых слушатели осваивают тонкости работы с продуктом. Новый учебный центр в Софии (Болгария) также проводит курсы по Baikonur Web App Server.

Нашими заказчиками стали Лукойл, Белый дом, Сбербанк, Аэрофлот, Гос Дума, ОНЭКСИМ банк, Мин. Связи, Мин Обороны, Ростелеком, Акционерная Русская Телефонная Компания, Роспак и другие организации и коммерческие фирмы.

Совсем недавно компания Borland открыла русскоязычный сайт http://www.demo.ru, который также работает на основе Baikonur Enterprise Web App Server.

Конечно же, работа над продуктом не прекращалась.
12 апреля 1996 года мы выпустили новую версию Baikonur Web App Server 1.1. Эта версия стала работать значительно быстрее, увеличилось количество компонент и дополнительных утилит. Добавлены протоколы Finger и FTP.

Завершена разработка Baikonur Enterprise Web App Server, близка к завершению версия Baikonur SuperServer.

Основные изменения касаются добавления возможности с двумя новыми протоколами - IIOP (протокол для взаимодействия объектов CORBA) и SMTP(протокол электронной почты), а также визуальной технологии написания своих собственных клиентов с использованием CORBA

Кроме того, существенно расширено количество полезных утилит и визуальных компонент, входящих в комплект продукта.

Обо всех новых разработках вы можете узнать на сайте Epsylon Technologies - http://www.demo.ru.

Вопросы автору