Серверы приложений

• 1 — браузер клиента отправляет HTTP-запрос;
• 2 — на стороне сервера служба Web Internet Information Services (web-сервер IIS) определяет тип запрашиваемого ресурса, и для случая запроса *.aspx (расширение файлов страниц ASP.NET) загружает соответствующее ему (запросу) расширение Internet Server Aplication Programming Interface (ISAPI). Для страниц aspx это расширение isapi_aspnet.dll. IIS также осуществляет идентификацию и авторизацию пользователя от которого поступил запрос. В свою очередь расширение isapi_aspnet.dll загружает фабрику обработчиков ASP.NET. Далее, фабрика обработчиков создает объектную модель запрашиваемой страницы и обрабатывает действия пользователя.
• 3 — в ходе генерации ответа приложению ASP.NET может потребоваться обращение к БД, в этом случае используя библиотеки классов провайдера данных ADO.NET 2.0, выполняющая среда обращается к серверу БД;
• 4 — провайдер данных ADO.NET 2.0 передает запрос на операцию с БД серверу MySQL;
• 5 — сервер MySQL осуществляет обработку запроса, выполняя соответствующие операции с БД ;
• 6 — провайдер данных ADO.NET 2.0 передает результаты запроса объекту страницы;
• 7 — объект страницы с учетом полученных данных осуществляет рендеринг графического интерфейса страницы и направляет результаты в выходной поток;
• 8 — сервер IIS отправляет содержимое сгенерированной страницы клиентскому браузеру.

3. Общая схема серверов приложений

Сервер приложений "Смарагд" может поставляться в одном из двух вариантов: базовом и расширенном. В базовом варианте поставляется только ядро сервера приложений (описание ядра сервера приложений см. в разделе "Ядро сервера приложений"). В расширенном варианте вместе с ядром сервера поставляется внешний интерпретатор языка ASPL (описание языка ASPL см. в главе "Язык хранимых процедур").

Общая схема сервера приложений показана на рис. 3.1.

 
Рис. 3.1. Схема сервера приложений

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

Для управления работой сессий и  ядра, а также для выполнения определенных административных операций существует специальный набор команд для ядра сервера приложений. Подробнее об этих командах см. в разделе "Интерфейс сервера приложений".

Общая схема взаимодействия клиента  и сервера приложений следующая.

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

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

1. Ядро сервера приложений

Ядро сервера приложений представляет собой непосредственно сервер приложений и набор административных утилит для управления им. Функциями ядра являются задачи управления сессиями пользователя, сбор и предоставление информации о состоянии процессов  пользователя администратору. Как описывалось  выше, к задачам по управлению сессиями относятся задачи создания новой  сессии, подключения к текущей  сессии, отключения от нее, завершения текущей (или указанной администратором) сессии, управление аутентификацией пользователей, изменение приоритетов сессий.

2. Клиентский процесс сервера

Клиентский процесс сервера  приложений - это, в общем виде, произвольный исполняемый файл, работающий через  стандартный ввод/вывод. В расширенном  варианте поставки сервера существует интерпретатор языка ASPL, который может использоваться как клиентский процесс.

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

4. Интерфейс сервера приложений

Взаимодействие клиента  и сервера приложений базируется на протоколе TCP/IP и организуется в  виде обмена текстовыми строками (пакетами). Интерфейс клиента с сервером приложений является двухуровневым:

• на нижнем уровне клиент самостоятельно устанавливает TCP/IP-соединение с сервером приложений и обменивается с ним мнемоническими командами;
• на верхнем уровне взаимодействие производится с помощью средств конкретной системы разработки приложений.

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

1. Структура клиентского пакета

В общем виде структура  клиентского пакета может быть записана в виде (рис.4.1.1):

Рис. 4.1.1. Общий формат пакета клиента.

Сигнатура пакета - стандартный 4-байтовый неизменяемый префикс пакета ("ASIF").

Длина пакета - беззнаковое  длинное целое, показывающее размер тела пакета в байтах.

Тип пакета - однобайтовый символ, который принимает значение 'C' или 'D'.

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

Пакеты клиента делятся  на 2 вида:

1. Пакеты с данными (тип пакета - 'D'), которые содержат информацию для клиентского процесса, работающего на сервере приложений.
2. Командные пакеты (тип пакета - 'C') содержат команды администрирования и организации работы клиента с сервером приложений. Более подробно см. разд. "Язык команд сервера приложений".

2. Язык команд сервера приложений

Элементы языка - это команды, которые делятся на следующие  классы:

• команды поддержки связи и авторизации клиента, обеспечивающие организацию сессий для работы клиентов с сервером приложений:
• Команда для идентификации и аутентификации клиента при работе с сервером приложений

LI <имя_клиента> <пароль>

• Команда "начать сессию"

BS

или

BS <имя запускаемого файла>

• Команда ES - закончить сессию.
• Команда DS - отключение сессии с сохранением ее идентификатора.
• Команда для включения сессии с соответствующим идентификатором:

AS <идентификатор_сессии>

• команды удаленного администрирования сервера приложений позволяют получать информацию о клиентах и их задачах на сервере приложений:
• Команда LU - показать список клиентов.
• Команда LT - показать список задач.

Рассмотрим примеры пакетов  клиентов с использованием выше- перечисленных  команд:

• ASIF13CLI user1 pwd1 /* для команды LI, где
• user1 - имя клиента,
• pwd1 - пароль */
• ASIF2CBS или ASIF12CBS file1.exe /* для команды BS, где
• file1.exe - имя файла */
• ASIF2CES /* для команды ES */
• ASIF2CDS /* для команды DS */
• ASIF7CAS id_s /* для команды AS, где
• id_s - идентификатор сессии*/
• ASIF2CLU /* для команды LU */
• ASIF2CLT /* для команды LT */

5. Хранимые процедуры сервера приложений

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

Следует отличать хранимые процедуры баз данных и хранимые процедуры сервера приложений. Хранимые процедуры баз данных создаются SQL-оператором CREATE PROCEDURE на языке SPL. Они являются неотъемлемой частью базы данных и хранятся непосредственно в рамках СУБД в пространстве данных конкретной базы данных.

Хранимые процедуры сервера  приложений создаются в рамках сервера  приложений и делятся на два класса:

• внутренние хранимые процедуры (текстовые, скриптовые);
• внешние хранимые процедуры (двоичные, библиотечные).

Далее, если это специально не оговорено, под термином хранимая процедура понимается внутренняя хранимая процедура. Термин внешняя хранимая процедура всегда записывается полностью.

1. Внутренние хранимые процедуры

Внутренние хранимые процедуры  создаются на языке хранимых процедур сервера приложений ASPL .

Для каждого пользователя сервера приложений существует три  класса доступных ему функций  и процедур:

• стандартные функции сервера приложений (математические и пр.);
• хранимые процедуры общего использования (общие хранимые процедуры);
• пользовательские хранимые процедуры (частные хранимые процедуры).

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

Подробнее язык хранимых процедур описан в разд. "Язык хранимых процедур сервера приложений".

2. Внешние хранимые процедуры

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

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