Ирина Эланс

Автор который поможет с любыми образовательными и учебными заданиями

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

Оглавление

Введение 3

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

Преимущества серверов приложений 4

Архитектура клиент-сервер: двухзвенная и трехзвенная 5

Двухзвенная архитектура 5

Преимущества 6

Недостатки 6

Многоуровневая архитектура клиент-сервер 7

Трехзвенная архитектура 7

Обзор архитектуры 7

Достоинства 8

Недостатки 9

Пример трёхзвенной архитектуры клиент-сервер 9

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

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

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

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

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

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

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

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

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

Инсталляция и администрирование пользовательских библиотек 18

Обмен данными между интерпретатором ASPL и внешними хранимыми процедурами 18

Создание пользовательских библиотек 19

Использование пользовательских библиотек 20

Заключение 22

Список литературы 23

Введение

Сервер приложений — это инфраструктурное программное обеспечение, предназначенное для создания распределенных информационных систем с выделенными службами бизнес-логики, реализованными в виде компонентов, выполняющихся под его управлением. Эти компоненты могут представлять собой COM- или CORBA-объекты либо компоненты Enterprise JavaBeans. Современные серверы приложений позволяют реализовать надежные и устойчивые к сбоям информационные системы за счет поддержки создания кластеров и наличия средств восстановления после сбоев. В настоящее время серверы приложений являются основой многих корпоративных решений с повышенными требованиями к надежности.

Сервер приложений обладает следующими возможностями:

открытый интерфейс с клиентом на уровне строк, что позволяет организовать взаимодействие с клиентом, работающим на любой программной/аппаратной платформе, на которой существуют средства разработки приложений для TCP/IP;
возможность асинхронной работы клиента и клиентского процесса на сервере приложений. Это позволяет устранить проблемы, связанные с нестабильностью сети, организовать параллельное исполнение нескольких процессов для одного клиента и т.п;
возможность использования в качестве клиентских процессов любых исполняемых модулей. Это позволяет клиентам иметь специализированные модули для различных задач;
использование собственного интерпретатора (оболочки) в качестве клиентского процесса по умолчанию. Язык интерпретатора является языком 3-го поколения, основанным на INFORMIX-SPL, с возможностью исполнения любых SQL-операторов. Язык имеет расширенные возможности по использованию пользовательских библиотек. Подробнее см. главу "Язык хранимых процедур".

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

Сервер приложений (англ. application server) — это программная платформа (software framework), предназначенная для эффективного исполнения процедур (программ, механических операций, скриптов), которые поддерживают построение приложений. Сервер приложений действует как набор компонентов, доступных разработчику программного обеспечения через API (Интерфейс прикладного программирования), который определен самой платформой.

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

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

Преимущества серверов приложений

Целостность данных и кода

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

Централизованная настройка и управление

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

Безопасность

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

Поддержка транзакций

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

Архитектура клиент-сервер: двухзвенная и трехзвенная

Двухзвенная архитектура

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

Рис.2.1.1. Пример двухуровневой архитектуры.

Преимущества

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

Недостатки

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

Многоуровневая архитектура клиент-сервер

Многоуровневая архитектура клиент-сервер — разновидность архитектуры клиент-сервер, в которой функция обработки данных вынесена на один или несколько отдельных серверов. Это позволяет разделить функции хранения, обработки и представления данных для более эффективного использования возможностей серверов и клиентов.

Частные случаи многоуровневой архитектуры:

Трёхуровневая архитектура

Трехзвенная архитектура

В компьютерных технологиях трёхуровневая архитектура, синоним трёхзвенная архитектура (англ. three-tier или Multitier architecture) предполагает наличие следующих компонентов приложения: клиентское приложение (обычно говорят «тонкий клиент» или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных (рис.2.2.1).

Рис. 2.2.1. Пример трёхуровневой архитектуры.

Обзор архитектуры

Клиент — это интерфейсный (обычно графический) компонент, который представляет первый уровень, собственно приложение для конечного пользователя. Первый уровень не должен иметь прямых связей с базой данных (по требованиям безопасности), быть нагруженным основной бизнес-логикой (по требованиям масштабируемости) и хранить состояние приложения (по требованиям надежности). На первый уровень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции (сортировка, группировка, подсчет значений) с данными, уже загруженными на терминал.
Сервер приложений располагается на втором уровне. На втором уровне сосредоточена бо́льшая часть бизнес-логики. Вне его остаются фрагменты, экспортируемые на терминалы (см.выше), а также погруженные в третий уровень хранимые процедуры и триггеры.
Сервер базы данных обеспечивает хранение данных и выносится на третий уровень. Обычно это стандартная реляционная илиобъектно-ориентированная СУБД. Если третий уровень представляет собой базу данных вместе с хранимыми процедурами, триггерами и схемой, описывающей приложение в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий клиентские компоненты с прикладной логикой базы данных.

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

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

Достоинства

По сравнению с клиент-серверной или файл-серверной архитектурой можно выделить следующие достоинства трёхуровневой архитектуры:

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

Недостатки

Недостатки вытекают из достоинств. По сравнению c клиент-серверной или файл-серверной архитектурой можно выделить следующие недостатки трёхуровневой архитектуры:

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

Пример трёхзвенной архитектуры клиент-сервер

Компоненты трёхзвенной архитектуры, с точки зрения программного обеспечения реализуют определенные сервера БД, web-сервера и браузеры. Место любого из этих компонентов может занять программное обеспечение любого производителя. Ниже представлено описание взаимодействия компонентов трехуровневой архитектуры клиент-серверного приложения. Сервер БД представлен MySQL-сервером; сервер приложений технологиями: ADO.NET, ASP.NET и web-сервером IIS; роль клиента выполняет любой web-браузер.

Браузер клиента 1-> Сервер IIS 2-> Исполняющая среда ASP.NET 2.0 3-> Провайдер данных ADO.NET 2.0 4-> Сервер MySQL 5-> Провайдер данных ADO.NET 2.0 6-> Исполняющая среда ASP.NET 2.0 7-> Сервер IIS 8-> Браузер клиента

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 отправляет содержимое сгенерированной страницы клиентскому браузеру.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Команда для идентификации и аутентификации клиента при работе с сервером приложений

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

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

или

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 */

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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