Вынесение прикладной логики в отдельный уровень представляет разработчикам дополнительную гибкость в создании распределенных информационных систем. Размещение и выполнение программ на стороне сервера снижает требования к аппаратному обеспечению клиентов и уменьшает проблемы обеспечения совместимости в гетерогенной сетевой среде.
Сервер приложений - это сервисная программа, которая обеспечивает доступ клиентов к прикладным программам, выполняющимся на сервере. Сервер приложений обычно выделяется как среднее звено (рис. 1) в трехуровневой клиент-серверной архитектуре (3-tier):
Модель "сервер приложений"
- Первый уровень, интерфейсный, как правило, графический (GUI).
- Средний уровень, исполнимый программный код, размещенный обычно на выделенном сервере.
- Третий уровень, фоновый - базы данных. Сюда же относятся, унаследованные средства доступа к данным и управления транзакциями.
В сетевой среде сервер приложений является посредником между фронт-энд ами клиентов и серверами баз данных.
Бизнес-логика может быть реализована на стороне сервера как целиком (удаленный код), так и частично (распределенный код). В первом случае к серверу могут обращаться терминалы и «тонкие» клиенты и такое взаимодействие соответствует модели «сервер терминалов». «Толстые» и rich-клиенты могут получать компоненты серверного приложения и выполнять их на своей стороне (например javascript, апплеты, flash).
Мобильный софт
Задачи, решаемые серверами приложений хорошо иллюстрируются на примере мобильных сервисов. Возможности мобильных устройств изначально ограничены физическими размерами и временем автономной работы (остальные ограничения, в основном, вытекают из этих двух). Мобильное приложение разрабатывается с учетом этих ограничений, но так как софт для телефона должен быть адаптирован для использования на конкретной модели, то процесс разработки усложняется. Разделив мобильное приложение на клиентскую (представление данных) и серверную (прикладная логика) части, разработчик получает следующие возможности:
- урезанная по функционалу клиентская часть получается менее требовательной к ресурсам;
- для поддержки новых устройств нужно адаптировать только фронт-энд, не затрагивая прикладную логику;
- изменения в программе (расширение функциональности, исправление ошибок и т. п.) выполняются на сервере приложений и распространяются на всех клиентов.
Клиенты могут взаимодействовать с приложениями через API сервера (Java-клиент <-> контейнер сервлетов <-> сервлет). Большую гибкость и универсальность представляет взаимодействие через сторонние сервисы, в первую очередь - через веб-сервер.
Понятие сервера приложений традиционно связывают с платформой Java, указывая на то, что сервер Java-приложений представляет реализацию спецификации сервлетов, возможно в виде JSP, и еще некоторые сервисные услуги, в первую очередь соединение с базой данных.
Но это нечто большее и меньшее одновременно: сервер приложений предоставляет среду, в которой прикладные программы могут работать, независимо от того, что и как именно они делают.
Поэтому, чтобы ответить на вопрос, является ли (и в какой степени) некое сервисное ПО сервером приложений, стоит сравнить его заявленные функции со списком атрибутов, присущих этой категории:
- Предоставляет модель контейнера для приложений.
- Предоставляет сервисные услуги для программ.
- Обеспечивает управление приложениями и/или представляет средства их разработки.
- Соответствует индустриальным спецификациям и стандартам.
- Добавим сюда же обслуживание веб-страниц, ввиду реальной востребованности технологий на основе WWW.
Реализации
По приведенным признакам в рассматриваемую категорию попадают, например, традиционные терминал-серверные системы, технология CGI, контейнеры Java-сервлетов и др.
Унаследованные решения
Серверы терминалов представляют среду для удаленного выполнения программ, в качестве которой выступает сама операционная система. Доступ к ним осуществляется по протоколам удаленного управления (telnet, ssh, RDP, VNC и т. п.) из клиентского ПО (эмулятор терминала, средства управления удаленным рабочим столом и т.п.). Управление запущенной программой выполняется через эмулируемый на клиенте пользовательский интерфейс (текстовый или графический) операционной системы. На серверной стороне взаимодействие программ с ОС реализуется через системные вызовы. Управление также осуществляется средствами операционной системы. Разработка может вестись на любом языке, доступном в конкретной ОС.
Общий шлюзовый интерфейс (CGI) - технология доступа к приложениям через веб-сервер. Отличия от сервера терминалов здесь в том, что пользовательский интерфейс предоставляется в виде веб-страниц. Запросы веб-клиентов, обращенные к программам, размещенным в выделенном каталоге (как правило cgi или cgi-bin) перенаправляются на их вход через стандартный поток ввода (stdin). Результаты выполнения в виде гипертекста приложение возвращает веб-серверу через stdout.
Серверы Java-приложений
Платформа Java является индустриальным стандартом, позволяющим создавать из унифицированных компонентов интероперабельные программные решения для самых разных систем, в которых может быть запущена виртуальная машина Java (JVM).
Контейнер сервлетов - один из архитектурных компонентов J2EE, представляющий окружение для выполнения сервлетов. Сервлет - это Java-приложение, выполняющееся на стороне сервера (в отличие от апплета). Контейнер сервлетов может работать как полноценный самостоятельный сервер, но чаще используется (интегрируется) совместно с другим серверным ПО. Обеспечивает обмен данными между сервлетом и клиентами, берёт на себя выполнение таких функций, как создание программной среды для функционирующего сервлета, идентификацию и авторизацию клиентов, организацию сессии для каждого из них.
Концепция сервлет-контейнера позволяет создавать как универсальные, так и специализированные серверы приложений (например, для мобильных сервисов).
Примером реализации контейнера сервлетов является Apache TomCat, который используется в таких серверах приложений как Apache Geronimo, JBoss, GlassFish, IBM WebSphere Application Server (WAS).
Другие решения
Компания Microsoft представляет собственные решения для поддержки бизнес-логики и сервисной инфрастуктуры на основе ОС Windows Server и технологии.NET Framework. Основным средством разработки является язык C#.
Язык python, получивший популярность во многом благодаря Google, является основным средством разработки для сервера веб-приложений Zope.
Для сценариев на языке PHP, широко используемом для создания веб-сайтов, компания Zend Technologies (разработчик самого языка PHP) создала сервер приложений Zend Server.
Серверы приложений: плюсы и минусы
Преимущества
Целостность кода и данных
Размещение бизнес-логики на выделенном сервере или ограниченном числе серверных компьютеров гарантирует доступ к обновленному и модернизированному ПО для всех клиентов. Это исключает риск доступа и управления данными из устаревших и, возможно, несовместимых программ.
Централизованное управление
Изменения в конфигурации прикладных программ, такие как, например, смена сервера баз данных, выполняются централизованно.
Безопасность
Централизованные средства, через которые поставщик услуг (сервис-провайдер) может управлять доступом к данным и компонентам приложения, позволяют выполнять проверку подлинности потенциально ненадежных клиентов в среднем слое и не затрагивать уровень базы данных.
Производительность
Сервер приложений может решать задачи балансировки сетевого трафика и распределения нагрузки между другими физическими серверами системы.
Общая стоимость владения
Совокупность перечисленных выше преимуществ, а в дополнение к ним перераспределение затрат на оборудование с клиентской на серверную сторону, может привести к экономии средств для организации. Так же на снижении общей стоимости владения может отразиться практика аренды программного обеспечения. Справедливости ради нужно отметить, что стоимость самого серверного ПО, а также затраты на его внедрение и сопровождение могут быть весьма высокими.
Недостатки
Централизация
Системы, построенные на основе сервера приложений, имеют один основной недостаток, присущий всем централизованным решениям - «падение» сервера приведет к недоступности программ для всех клиентов. К тому же эффекту приведут и неполадки в сетевом подключении.
Защита информации
Эта проблема, в принципе, актуальна для любых сетевых решений, использующих для передачи данных инфраструктуру публичных сетей.
Постоянный адрес этой страницы:
Для расширения возможностей клиент-серверного взаимодействия в рамках протокола HTTP помимо создания на клиентской стороне расширений стандартных возможностей, предоставляемых языками разметки и браузерами, можно также разрабатывать на стороне веб-сервера приложения , плагины и сценарии , расширяющие возможности самого веб-сервера.
Плагин ( plug - in) - независимо компилируемый программный модуль , динамически подключаемый к основной программе, предназначенный для расширения или использования ее возможностей. Обычно выполняются в виде разделяемых библиотек.
Сценарий (скрипт , script ) - программа , которая автоматизирует некоторую задачу, которую пользователь выполняет вручную, используя интерфейсы программы.
Стандарт CGI
Круг задач, решаемых Web-сервером, ограничен. В основном он сводится к поддержке НТТР-взаимодействия и доставке клиенту Web-документов. Любые "нестандартные" действия реализуются с помощью специальной программы, которая взаимодействует с веб-сервером и клиентом. Это взаимодействие подчиняется определенным правилам.
Основной набор таких правил - стандарт CGI (Common Gateway Interface - интерфейс общего шлюза), который определяет порядок запуска программы на компьютере-сервере, способы передачи программе параметров и доставки результатов ее выполнения клиенту. Программа , написанная по правилам CGI , называется CGI -сценарием ( script CGI ), хотя это не означает, что на сервере не может выполняться двоичный файл .
Благодаря этому интерфейсу для разработки приложений можно использовать любой язык программирования , который располагает средствами взаимодействия со стандартными устройствами ввода/вывода. Такими возможностями обладают также сценарии для встроенных командных интерпретаторов операционных систем.
Выполнение любой программы (в том числе CGI -сценария) можно условно разделить на пять этапов.
- Запуск программы.
- Инициализация и чтение выходных данных.
- Обработка данных.
- Вывод результатов выполнения.
- Завершение программы.
Различия между CGI -сценарием и консольным приложением касаются первого, второго и четвертого этапов выполнения.
Каждый раз, когда веб-сервер получает запрос от клиента , он анализирует содержимое запроса и возвращает соответствующий ответ :
- файл , находящийся на жестком диске, то сервер возвращает в составе ответа этот файл ;
- Если запрос содержит указание на программу и необходимые для нее аргументы , то сервер исполняет программу и результат ее работы возвращает клиенту.
CGI определяет:
- каким образом информация о сервере и запросе клиента передается программе в форме аргументов и переменных окружения ;
- каким образом программа может передавать назад дополнительную информацию о результатах (например о типе данных) в форме заголовков ответа сервера.
В подавляющем большинстве случаев запуск CGI -сценария осуществляется щелчком на кнопке Submit , сформированной с помощью дескриптора , который находится на HTML -странице между
. Не зная назначения атрибутов action и method , невозможно понять, как происходит вызов программы и передача параметров .Значением атрибута action дескриптора
Если сценарий вызывается из формы, ему передаются те данные, которые пользователь ввел с помощью интерактивных элементов, отображаемых на веб-странице - передача информации CGI -сценарию осуществляется в два этапа: сначала браузер передает данные веб-серверу, затем веб- сервер передает их сценарию.
В большинстве случаев кроме кнопки Submit форма содержит другие интерактивные элементы, каждый из которых имеет имя ( атрибут NAME ) и значение ( атрибут VALUE , либо последовательность символов, введенная пользователем). Из имен элементов и их значений формируется строка параметров, которая имеет следующий формат.
имя=значение&имя=значение& . . . &имя=значение
Каждый параметр представляет собой имя управляющего элемента и его значение , разделенные знаком равенства, а несколько таких пар объединяют строку с помощью символа " & ". Если в состав имени или значения входит символ " & " или " = ", то подобные символы кодируются последовательность знака процента " % ", за которым следуют две шестнадцатеричные цифры, определяющие код символа . Так, например, последовательностью " %21 " кодируется восклицательный знак " !". Как правило, при передаче параметров трехсимвольными последовательностями заменяются все знаки, кроме латинских букв, цифр и символа пробела (последний заменяется знаком " + ").
Таким образом, перед использованием строки параметров ее надо декодировать. Алгоритм декодирования чрезвычайно прост и включает в себя следующие действия:
- Выделить из строки параметров пары имя = значение .
- Выделить из каждой пары имя и значение .
- В каждом имени и каждом значении заменить символы " + " пробелами.
- Каждую последовательность из символа " % " и двух шестнадцатеричных и преобразовать в ASCII-символ.
Атрибут method дескриптора