Технология Baikonur Web Application Server - архитектура клиент-сервер для Intranet-систем доступа к корпоративным базам данных

Сервер компании Epsylon Technologies

Что такое Baikonur Server.

Baikonur - програмный продукт компании Epsylon Technologies, предназначенный для быстрой разработки приложений, ориентированных на использование Web-браузеров в качестве клиентских мест для доступа к базам данных во внутрикорпоративных сетях Intranet, а также Internet. Собственно Baikonur из себя представляет сервер приложений, частным случаем которого является Web-сервер приложений, в состав поставки входят еще и дополнительные библиотеки для различных средств программирования, в частности, для Borland Delphi (для C++, Java, JavaScript - в старших версиях).

Baikonur Server предназначен для построения как очень простых, так и очень сложных Internet/Intranet систем на платформе Windows NT. Самое простое, что может делать Baikonur Server - это служить в качестве обыкновенного Web сервера, имеющего дело со стандартными HTML-документами. Однако, в отличие от стандартного Web-сервера, основные ресурсы, которыми оперирует Baikonur-сервер - это информационные потоки и задачи. В результате при помощи сервера Baikonur появляется возможность элегантного построения функционально весьма сложных и разветвленных информационных систем.

Информационные системы в архитектуре клиент-сервер.

Системы в архитектуре клиент-сервер устроены так, что исполняемый код одновременно находится и на сервере, и на клиенте. Как правило, серверной стороной выступает какой-либо SQL-сервер, например, от компании Oracle, Informix, Borland, Microsoft, IBM и др., а задачей клиентского места является диалоговая работа с пользователем, формирование запросов, получение и отображение результатов. В настоящее время существуют развитые средства скоростной разработки систем в такой архитектуре. Одним из таких наиболее удачных инструментов является Borland Delphi. Компонентный подход к разработке клиентского места в Delphi существенно ускоряет проектирование всей системы в целом. В Delphi имеются визуальные и невизуальные компоненты. Визуальные компоненты предназначены для проектирования элементов интерфейса, а невизуальные - для сборки из готовых компонент алгоритмической части, включая запросы, обработку таблиц и т.д.
В отличие от систем в архитектуре файл-сервер (концепция разделяемого винчестера), обработка данных в системах с архитектурой клиент-сервер в основном происходит на серверной стороне. Однако клиентское место имеет доступ к метаданным, определяющим структуру таблиц и т.д. Запросы и получение данных в системах с архитектурой клиент-сервер происходит при помощи драйверов данных (в случае Delphi - SQL Links), которые умеют работать с соответствующими SQL серверами, посылая запросы, производя коннект, получая результирующие наборы данных.

Рисунок 1. Классическая архитектура клиент-сервер

Переход в трехзвенную архитектуру при помощи Baikonur Web App Server.

В случае применения Baikonur Web App Server между клиентом и сервером появляется дополнительное звено - сервер приложений. Теперь приложения, изготовленные при помощи средства скоростной разработки (например, Delphi), работают не на клиентской стороне, а под управлением сервера приложений Baikonur. В зависимости от необходимого количества одновременно работающих клиентов, таких серверов может быть несколько. SQL сервер может работать либо на той же машине, где находится сервер приложений, либо быть выделенным в отдельный физический сервер. В случае SQL сервера от компании Borland это может быть даже сервер с другой операционной системой, например, какой-нибудь из наиболее удачных UNIX (Solaris, AIX, HP/UX, Digital UNIX, IRIX).

Собственно клиентское место представляет из себя теперь компьютер с достаточно произвольно выбираемой конфигурацией и операционной системой. Это может быть и Win 3.11, и Macintosh, и UNIX, и OS/2, и Win NT др... Клиентское место может находиться в сети (стек TCP/IP) или связываться с сервером Baikonur через прямое модемное соединение, через провайдера Internet или по специализированной выделенной линии.

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

Рисунок 2. Трехзвенная архитектура Internet/Intranet.

Основные преимущества, достигаемые при переходе в 3-звенную архитектуру.

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

• в системе с применением Baikonur Web App Server не накладываются жесткие ограничения на тип операционной системы и мощность клиентского рабочего места. В то время как в клиент-серверных системах минимальные требования к рабочему месту - 16Mb ОЗУ, а если используется другой тип операционной системы, разработчикам приходится дублировать разработку клиентской части для другой операционной системы. Применение Baikonur позволяет использовать стандартные Internet-браузеры для оснащения клиентского места, работающие при минимуме оперативной памяти на клиентском рабочем месте.
• Клиентские рабочие места могут работать с сервером Baikonur удаленно, не подвергаясь существенной переделке, в то время как стандартный клиент-серверный подход не является настолько отработанным, чтобы клиентское рабочее место легко без изменения могло работать в удаленном режиме. В случае Baikonur различные практические вопросы при использовании удаленного рабочего места (типа "что произойдет, если случится обрыв линии, сохранится ли контекст задачи, существует ли возможность присоединиться к уже запущенным задачам с другого рабочего места", как решить проблему удаленного администрирования, вопросы помех на линии, вопросы доступа как через модемный пул, так и через Internet, вопросы безопасности данных, вопросы насыщенности сетевого траффика и т.д.) решаются без особых трудностей, поскольку исторически Internet-технологии в первую очередь решали именно эти задачи, и именно в этих вопросах накоплен наибольший опыт.
• Система с использованием Baikonur легко масштабируется от небольшой системы уровня рабочей группы до системы масштаба нескольких тысяч одновременно работающих рабочих мест. Все это может быть произведено без существенной переделки системы простым увеличением мощности аппаратуры сервера приложений или использованием нескольких серверов приложений.
• Лицензионная политика для SQL-серверов и для Web-серверов, к которым относится в этом вопросе и Baikonur Web App Server, существенно отличается. При покупке SQL-сервера предприятие обязано оплатить лицензии на каждое рабочее место, одновременно работающее с сервером. В случае Baikonur Web App Server оплачивается только лицензия на сервер. Различные версии Baikonur рассчитаны на различную суммарную нагрузку. В случае, если с базой данных одновременно работает 200 человек, реальное количество одновременных коннектов Baikonur сервера к SQL-серверу может быть в десятки раз меньше, поэтому возникает реальная возможность сэкономить средства при реализации крупного корпоративного проекта.
• В том случае, когда количество установленных рабочих мест в системе с архитектурой клиент-сервер переваливает за несколько десятков, у администратора системы начинаются серьезные проблемы с администрированием такого количества рабочих мест. Как правило, корпоративная информационная система находится в постоянном развитии, и существует необходимость следить за тем, чтобы на все рабочие места была установлена свежая верия клиентского приложения, вовремя переинсталлировать ее и т.д. При увеличении рабочих мест свыше сотни становится физически невозможным вовремя обновлять клиентские приложения, а при наличии еще и удаленных рабочих мест администрирование системы превращается в вечную головную боль технического персонала предприятия. Следует также учитывать стоимость такого администрирования в масштабах предприятия, наличие нерабочего времени для каждого рабочего места (технический перерыв), возможную неработоспособность всей системы в случае работы несовместимых версий клиентского приложения и т.п.

• Функциональная расширяемость системы на основе Baikonur сервера. В Baikonur Web App Server реализована технология динамической смены протоколов. Одним из наиболее употребимых протоколов Baikonur является интернетовский протокол http 1.1. Однако, технология динамической смены протоколов позволяет управлять информационными потоками, предназначенными не только для пересылки гипертекстовых страничек по Internet. Это могут быть потоки информации, предназначенные для передачи голосовой информации, почтовых сообщений, просто файлов, видеоинформации, мониторинговой информации, результатов измерений и т.д. Можно использовать уже принятый соответствующий стандарт или придумать и реализовать собственный. Такая беспрецедентная возможность расширения функциональности системы абсолютно нехарактерна для клиент-серверных продуктов прежнего поколения.
• Секретность и безопасность. В клиент-серверных системах прежнего поколения принято, что клиентское приложение имеет доступ к метаданным системы. Практика показывает, что при такой схеме работы весьма сложно обеспечить стопроцентную безопасность всей информационной системы. Кроме того, только немногие клиент-серверные продукты обеспечивают шифрование данных на лету при передаче их по сети.

Интегрирование самых различных систем в единую систему. Существует очевидная тенденция для всех основных производителей программного обеспечения выпускать Internet/Intranet версию своего программного обеспечения. С учетом этой тенденции появляется возможность объединять программные пакеты от большинства производителей в единую систему, дописывая недостающие части в виде exe-модулей, запускаемых под управлением Baikonur-сервера.

Внутренняя архитектура сервера приложений Baikonur.

Рассмотрим, как устроента система на основе сервера Baikonur. На рисунке показаны основные элементы системы. Удаленные и неудаленные клиенты 1-N обслуживаются одинаковым образом, никаких различий для них не делается. Каждый запрос, поступающий от клиентского браузера на TCP-порт, обслуживается листенером - подзадачей обслуживания коммуникационного порта, который фактически является монитором соединений (коннектов), а затем попадает на парсер, который разбирает запрос и идентифицирует клиента. При возникновении соединения листенер инициирует работу IP-менеджера, который обслуживает подзадачи сессий клиентов. Парсер принимает решение, генерировать ли ему новую подзадачу сессии клиента, или переключить информационный поток от клиента к его задаче. Таким образом информационный поток попадает от клиентского браузера именно туда, куда необходимо. Идентификация клиента позволяет избежать потери контекста при переключении между задачами. На передаче информационного потока задаче обработка не заканчивается. Библиотека HTML-компонент, написанная для Delphi, устроена так, что базовый компонент, присутствующий в каждой задаче (THTMLControl), умеет воспринимать поток информации, передаваемый ему с сервера Baikonur. Этот поток воспринимается, и раздается активным визуальным компонентам для обработки. При передаче информации от приложения клиенту все происходит в обратном порядке, с тем лишь исключением, что коннект уже установлен, клиентский браузер идентифицирован. Поэтому остается лишь собрать информацию с визуальных компонент, собрать ее в один поток и передать обратно на клиента.

Рисунок 3

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

Рисунок 4

Визуальное построение Internet/Intranet приложения при помощи Borland Delphi.

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

Пример 1. Рыбки.

Те, кто уже имел дело с инструментальными средствами компании Borland, прекрасно знают этот пример, который Borland предоставляет для всех своих визуальных инструментов. Рыбки (Fish Facts) - это база данных с информацией об аквариумных рыбках с их внешним видом (картинка), описанием (memo-поле), и несколькими характеризующими записями.

Borland включает пример с этой базой данных во все свои инструменты. Такой пример шел в составе Paradox, Visual dBase, Delphi и C++. Компания Epsylon Technologies включает аналогичный пример в поставку библиотеки визуальных HTML-компонент для Delphi.

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

Для начала поместим стандартные невизуальные объекты TDataSource и Ttable на форму. Эти невизуальные элементы позволяют осуществить коннект с источником данных уже на этапе проектирования. TDataSource и TTable входят в стандартную поставку Delphi, так что мы не делаем пока что ничего необычного для стандартного цикла дельфийской разработки.

Настроим эти элементы. Свойство TableName невизуального объекта Table1 установим в Biogif.db. Это имя нашей базы данных в парадоксовском формате. В качестве источника данных

можно установить и любой SQL-сервер, например Oracle или MS SQL, но пока что мы не будем этого делать - сделаем пример как можно проще. Теперь сделаем активным соединение, для чего установим свойство Active в True. Элемент DataSource1 настроим на Table1, установив свойство DataSet в Table1.

Теперь можно подключать визуальные компоненты. Если бы нашей целью было создать обычное приложение, мы бы воспользовались стандартными элементами, находящимися на странице DataControls в палитре компонент. Однако, мы хотим создать Internet/Intranet приложение, поэтому надо выбирать страницу DB HTML.

Рисунок 5. HTML компоненты для работы с базами данных.

Выберем оттуда, и разместим, как нам нравится, на форме элементы THTMLDBGif, THTMLNavigator, THTMLDBGrid, THTMLDBText и THTMLDBEdit. Для всех мы сейчас сделаем одну и ту же операцию. Мы настроим свойство DataSource на DataSource1, а затем выберем для свойства DataField соответствующее поле из нашей базы данных (для всех, кроме HTMLDBGrid1 и HTMLNavigator - для них указание полей не требуется). И все заработало!

Мы увидели появление данных в таблице, картинки - в поле для картинки, содержимое поля - в поле для редактирования.

Неужели все уже готово? Нет, требуется сделать еще несколько операций. Давайте наведем красоту на все это хозяйство, настраивая свойства Align и Color в соответствующих компонентах.

Рисунок 6. Страница HTML компонент.

В дополнение еще разместим элемент THTMLButton и пропишем реакцию приложения на нажатие кнопки. В Инспекторе Объектов мы увидим только одно событие, которое можно обрабатывать у кнопки HTMLButton1 - событие OnClick. Дважды кликнем мышкой и получим шаблон процедуры-обработчика события. Все, что нам надо сделать по нажатию кнопки "Close" - это закрыть приложение. Что мы и запишем между строками begin и end - "HtmlControl1.UserClose;" . C точки зрения разработчика-программиста, мы написали вызов метода UserClose у элемента HTMLControl1. С точки зрения разработчика мы написали нечто невразумительное, ибо этого элемента в проекте пока еще нет. Если бы мы начали трансляцию, компилятор выдал бы ошибку в этой строке.

Рисунок 7. Текст процедуры-обработчика события нажатия кнопки.

То есть, чтобы избежать ошибки, нам требуется поместить на форму соответствующий элемент.

На самом деле, чтобы добиться работоспособности приложения в Internet, мы обязаны поместить и настроить, как минимум два элемента - THTMLControl и THTMLPage. Компонент THTMLControl требуется один на приложение, и может быть помещен на главную форму, компонент THTMLPage требуется класть по одному на каждую новую страницу формы. Смысл этих элементов вот в чем:

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

Вторым очень важным элементом является THTMLPage. В его функции входит раздача и передача информации, полученной от клиентского браузера или передаваемой клиентскому браузеру, но касающейся конкретных элементов на HTML странице. В принципе, мы можем не делать никаких дополнительных настроек этих элементов и удовольствоваться тем, что установлено по умолчанию.
А вот теперь пора транслировать! После трансляуции мы получаем модуль .exe, который надо поместить в соответствующую рабочую директорию Baikonur.

Рисунок 8. Вид проекта в design time.

Если у вас в качестве рабочей машины стоит машина с установленным Windows NT Workstation, то вы можете весь интернет получить на одном рабочем месте. У вас может быть одновременно быть установлен сервер Baikonur один, или несколько браузеров. Давайте проверим работоспособность всей системы.

Итак: при работающем сервере Baikonur мы запускаем браузер и указываем ему в качестве URL следующую строку: "http://myserveraddress/project1.exe". При этом запрос на ресурс приходит серверу Baikonur, тот находит только что изготовленный нами исполняемый файл и запускает его на исполнение. Стартовав, приложение project1.exe коннектится к базе данных, получает данные и динамически формирует соответствующую HTML - страницу.

Посмотрите, все действительно работает! При нажатии на кнопки навигатора мы перемещаемся на следующие записи в базе данных, при нажатии на кнопку Close приложение закрывается.

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

Теперь загрузитесь заново и дайте запрос на ваше приложение "http://myserveraddress/project1.exe"

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

Полезнейшее свойство, особенно, если вы имеете дело с ненадежным модемным соединением!

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

А где же HTML? - скажете вы. Можно заметить, что мы изготовили приложение, динамически генерирующее HTML-страницы, абсолютно не зная HTML. Однако, если хочется создавать изысканно выглядящие Internet-приложения, HTML придется освоить. Вы можете создавать свои собственные HTML-компоненты, или подправлять внешний вид страниц, генерируемый вашим приложением, расставляя вручную в шаблоне соответствующие теги HyperText Markup Language.

Библиотека Delphi HTML Controls может не содержать какого-либо элемента, который поддерживает какой-нибудь из браузеров. Например, в библиотеке отсутствует элемент <marquee>, поддерживаемый Microsoft Internet Explorer'ом. Для того, чтобы поместить такой тег на форму нужно воспользоваться компонентом HTMLLabel. Необходимо произвести следующую последовательность действий: поместите HTMLLabel в нужное место на форме, установить свойство Preformat в False, в свойстве Caption указать '<marquee> Это текст бегущей строки </marquee>'

В Microsoft Internet Explorer этот элемент отобразится в виде бегущей строки.

Нам осталось проверить последнее - действительно ли нашу базу данных с информацией о рыбках можно рассматривать при помощи браузеров от различных производителей? На рынке в основном конкурируют два браузера - Netscape Navigator и Microsoft Internet Explorer. В старшие версии сервера Baikonur компания Epsylon Technologies включает браузер Ariadna компании AMSD. Давайте проверим, что у нас получилось.

Рисунок 9. Внешний вид приложения в Microsoft Explorer.

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

Значительные отличия можно найти, исследуя.

Пример 2. Рассылка оперативной информации.

Этот пример иллюстрирует очень полезный режим, который, к сожалению, поддерживает на сегодня только Netscape Navigator. Поэтому, когда вы будете запускать пример приложения с названием multi.exe, воспользуйтесь браузером от компании Netscape.

Обычно, когда вы работаете с каким-либо браузером, ваш сеанс работы представляет собой последовательность соединений и разъединений (connect и disconnect), как показано на рис.11.
Если вы будете запускать изготовленный нами пример с рыбками, и еще несколько ваших коллег также попробуют одновременно с вами убедиться в том, что ваш пример работает, обращаясь к серверу с запросом "http://myserveraddress/multi.exe", то для каждого клиентского запроса будет создано отдельное приложение (см. Рис 12)

Рисунок 12. Запуск однопользовательского приложения

Приложение multi.exe работает в несколько ином режиме. Как только ваш Netscape Navigator соединился с сервером, запросив "http://myserveraddress/multi.exe", сервер запускает приложение multi.exe и не разрывает соединение, как происходит обычно. Приложение multi.exe периодически (раз в секунду) рассылает сформированный им информационный экран всем пользователям, подключившимся к программе. В отличие от примера с рыбками, приложение multi.exe является многопользовательским. Это означает, что если оно уже было запущено под управлением сервера Baikonur, то каждый следующий клиент, набирая "http://myserveraddress/multi.exe", не вызывает нового запуска приложения, а подключается к уже существующему. Приложение Multi.exe фактически является многопользовательским, или, говоря другими словами, многопользовательским прикладным сервером.

Рисунок 13. Многопользовательское приложение

Разберемся с тем, что все-таки делает multi.exe. Multi.exe, будучи один раз запущенным, занимается тем, что генерирует синусоиду, накладывая на уровень сигнала еще и кое-какой шум. Одновременно с генерацией программа строит график значений синусоиды и рассылает полученную HTML-страничку всем клиентам, кто к ней подключился. Очевидно, что прикладной пользы от сервера multi.exe нет никакой. Однако, если вам понадобится строить систему, в которой клиентам необходимо оперативно получать постоянно меняющуюся информацию, программу multi можно будет взять за основу.

Рисунок 14. В многопользовательском приложении динамически формируемая страничка рассылается каждому подключенному пользователю.

Заметьте, тем не менее, что в программе multi.exe пользователи не взаимодействовали между собой. А можно ли организовать такое взаимодействие?

Пример 3. CHAT-сервер.

Да, конечно же, можно. В набор примеров в коробке с Baikonur Web App Server for Delphi входит и такой пример. Это пример построения многопользовательского специализированного сервера для организации многоканальных разговоров в Internet. В данном случае все клиенты так же, как и в предыдущем примере, будут находиться в постоянном соединении с сервером, но сервер попутно еще и принимает строки, вводимые каждым клиентом, а затем рассылает их всем, находящимся в соединении. Таким образом, все видят ход беседы, находясь в самых разных местах земного шара.

Заключение.

Конечно, в рамках статьи изложить все особенности продукта и технологии невозможно. Мы рассказали об архитектуре, затронули стратегические вопросы архитектуры клиент-сервер, и показали на примерах, как можно строить приложения различного типа при помощи достаточно необычного подхода к архитектуре клиент-сервер. Но лучше один раз увидеть, чем сто раз услышать. Компания Epsylon Technologies в то время, когда писалась статья, планировала выпустить 5 версий сервера Baikonur. Самый младший, Baikonur Free Web App Server, предназначается для бесплатного ознакомления с продуктом и представляет из себя полнофункциональный сервер, правда, с ограниченной нагрузочной способностью. Его можно без ограничений загрузить с корпоративного сервера компании Epsylon Technologies. Добро пожаловать в новые технологии!

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