Модель "сервер приложений"

1. Первый уровень, интерфейсный, как правило, графический (GUI).

2. Средний уровень, исполнимый программный код, размещенный обычно на выделенном сервере.

3. Третий уровень, фоновый — базы данных. Сюда же относятся, унаследованные средства доступа к данным и управления транзакциями.

В сетевой среде сервер приложений является посредником между фронт-эндами клиентов и серверами баз данных.

Бизнес-логика может быть реализована на стороне сервера как целиком (удаленный код), так и частично (распределенный код). В первом случае к серверу могут обращаться терминалы и «тонкие» клиенты и такое взаимодействие соответствует модели «сервер терминалов». «Толстые» и 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.

Серверы приложений: плюсы и минусы

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

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

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

Централизованное управление

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

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

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

Производительность

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

Общая стоимость владения

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

Недостатки

Централизация

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

Защита информации

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

Общий доступ к сетевым ресурсам.

1. Служба общего доступа (sharing)

2. Протоколы общего доступа

   • SMB/CIFS

   • NFS

   • DFS

3. Низкоуровневые средства общего доступа. Протокол DAFS

Служба общего доступа (sharing)

Компьютерная сеть по определению представляет собой распределенную систему. Ее предназначение — совместная работа пользователей. Такая работа подразумевает доступ к сетевым ресурсам, как то файлы и каталоги, принтеры и т.д. Для пользователя обращение к сетевым ресурсам должно быть прозрачным, т.е.:

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

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

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

Указанные возможности предоставляют специальные протоколы общего доступа. Наиболее распространенными из них являются SMB/CIFS для ОС Windows и NFS, используемый в UNIX-подобных системах.

Протоколы общего доступа

SMB/CIFS

SMB (Server Message Block) — это протокол, предложенный IBM для организации общего доступа к файлам, принтерам, последовательным портам, почтовым ячейкам (mail slots), именованным каналам (named pipes) и API сетевых компьютеров. Протокол SMB может быть использован поверх сетевых протоколов стека TCP/IP, а также поверх ряда других сетевых протоколов.

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

В 1992 году появилась Samba — свободная реализация протокола SMB для UNIX-подобных операционных систем. Поскольку Microsoft не публиковала спецификации SMB и дополнений к нему, создателю Samba Эндрю Триджеллу (Andrew Tridgell) пришлось провести обратную разработку протокола на основе анализа пакетов.

Продвижение протокола SMB обеспечила корпорация Microsoft, включив его поддержку в свои продукты. В сетевой среде Microsoft Windows SMB являлся основным протоколом прикладного уровня для работы с ресурсами ЛВС. Он предназначен для выполнения функций общего доступа к файлам и принтерам, авторизации пользователей и обмена сообщениями.

Протокол SMB представляет четыре вида севисов:

• Управление сессиями. Создание, поддержание и разрыв логического канала между рабочей станцией и сетевыми ресурсами файлового сервера.

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

• Сервис печати. Рабочая станция может ставить файлы в очередь для печати на сервере и получать информацию об очереди печати.

• Сервис сообщений. SMB поддерживает простую передачу адресных и широковещательных сообщений по локальной сети.

Если режим управления сеансами в SMB прозрачен для пользователя, то остальными сервисами пользователь может управлять непосредственно с помощью команды net (см. net /? в консоли ОС Windows).

Рис. 1. NetBIOS/SMB

Для управления сессиями протокол SMB изначально использовал NetBIOS в реализации NetBEUI (NetBIOS Extended User Interface) — расширенный пользовательский интерфейс дейтаграммной передачи NetBIOS, рассчитанный на сети порядка 20-200 рабочих станций. Сети, основанные на протоколе NetBEUI, легко реализуются, но их трудно расширять, так как протокол NetBEUI не маршрутизируемый.

Для использования SMB в сетях с более сложной топологией в NetBIOS была добавлена поддержка транспортных протоколов TCP (NBT, NetBIOS over TCP), IPX, DECNet и Xerox Networking (XNS) (рис. 1)

Сервисы SMB, работающие в среде TCP/IP, используют различные порты (стандартные названия портов подчеркивают тесную связь SMB с NetBIOS):

netbios-ns 137/tcp # NETBIOS Name Service

netbios-ns 137/udp

netbios-dgm 138/tcp # NETBIOS Datagram Service

netbios-dgm 138/udp

netbios-ssn 139/tcp # NETBIOS session service

netbios-ssn 139/udp

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

1. Доступ на уровне ресурсов. Ограничения накладываются серверной стороной на каталоги общего доступа. Каждый сетевой каталог может быть защищен паролем и клиент должен указать этот пароль для получения доступа к файлам из общего каталога.

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

Привязка к NetBIOS ограничивало использование SMB небольшими локальными сетями. Первая причина — отсутствие в NetBIOS понятия сети как такового и средств перенаправления трафика (маршрутизации). Вторая — в принятой схеме адресации: имя ресурса, по сути, строка из 15 символов, плюс байт типа ресурса: сервер, контроллер домена и т.д. Естественно, такая одноранговая система именования не годится для интернета.

Для устранения этих ограничений в последних версиях SMB использовался протокол NBT (NetBIOS over TCP), работавший поверх стека TCP/IP.

CIFS создавался совместно разра­бот­чика­ми Samba Team, неза­виси­мым сооб­щест­вом и Microsoft. После того как про­то­кол CIFS был пред­став­лен как откры­тый стан­дарт, Microsoft прекратила финан­сирова­ние про­екта и сотрудничество с Samba Team, а поддержка CIFS в переработке Microsoft для совместимости с прежними версиями SMB была включена в ОС Windows 2000.

CIFS (Common Internet File System) — это открытый стандартный протокол (см. CIFS) на основе SMB, который обеспечивает доступ к файлам и сервисам на удаленных компьютерах в сетях TCP/IP. В отличие от SMB, основным транспортом для CIFS является протокол TCP. Для серверов CIFS зарегистрированы порты 445/TCP и 445/UDP (microsoft-ds # Microsoft Naked CIFS, см. /etc/services)

CIFS обеспечивает функциональность похожую на FTP (File Transfer Protocol), но предоставляет клиентам улучшенный (похожий на прямой) контроль над файлами. Основные возможности CIFS приведены втаблице 1.

Табл. 1. Возможности протокола CIFS

Возможность	Описание
Доступ к файловой системе	Поддержка файловых операций, таких как открытие, чтение, запись, поиск и закрытие файла или каталога
Блокировка файлов и записей	Неблокирующие приложения не имеют доступа к заблокированному файлу или записи.
Безопасное кэширование (опережающее чтение (read-ahead) и отложенная запись (write-behind))	Поддерживается одновременный доступ на чтение/запись файла множеством клиентов
Уведомления об изменении файла	Приложения могут регистрироваться на сервере для получения уведомлений об изменениях в файлах или директориях
"Переговоры" о версии протокола	Когда клиент и сервер устанавливают первый сетевой контакт, они обмениваются информацией о версии протокола (диалекте), который будет использоваться. Разные диалекты могут включать новые типы сообщений, а также отличия в форматах от других диалектов.
Расширенные атрибуты	Поддерживаются атрибуты, не относящиеся к атрибутам файловой системы. Такие, например, атрибуты как имя автора, могут быть добавлены к встроенным системным атрибутам файла (дата создания, дата модификации и проч.)
Распределенные реплицируемые виртуальные тома	Протокол поддерживает многотомную виртуальную файловую систему, в которой все "поддеревья" файловой иерархии для клиента выглядят как одно целое. CIFS прозрачно для пользователя обрабатывает доступ к физически перемещенным или реплицированным элементам такой файловой системы.
Независимость от серверов распознавания имен	Клиенты могут использовать любой механизм распознавания имен. К примеру, серверы DNS могут использоваться для получения доступа к файловым ресурсам сервера через Internet.
Пакетные запросы	Множественные файловые запросы могут быть "упакованы" в одно сообщение, что сокращает время ожидания ответа сервера. Пакетная обработка возможна даже тогда, когда последующие запросы зависят от результатов выполнения предыдущих.
Поддержка символов Unicode	Строки в формате Unicode могут использоваться в именах файлов, ресурсов и учетных записях пользователей.

Сетевая файловая система NFS

NFS (Network File System, сетевая файловая система) — это стандарт, который включает описание распределенной файловой системы и сетевого протокола для работы с ней. Первая спецификация NFS была разработана компанией Sun в 1989 году и предназначалась для использования только в UNIX. Позже реализации клиентской и серверной частей стали распространенными и в других системах. Текущая версия (на момент написания этого материала) имеет название NFS v4 и является открытым стандартом (RFC 3010).

Эта система позволяет пользователю работать с удаленными данными так же, как с локальными — то есть абсолютно прозрачно. Не считая, естественно, временных задержек.

Протокол NFS, как и SMB/CIFS, использует клиент-серверную модель взаимодействия. В ранних версиях NFS для транспортирования данных использовался UDP-протокол, в современных — используется TCP. Сервис NFS работает на следующих зарегистрированных портах:

nfs 2049/tcp # Network File System - Sun Microsystems

nfs 2049/udp # Network File System - Sun Microsystems

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

NFS является «родной» файловой системой для UNIX и соответствует логике файловых операций этой операционной системы. Это относится как к пространству имен файлов, так и к поддерживаемым файловым атрибутам. Поддержка NFS имеется у всех популярных систем на основе UNIX.

Рис. 2. Организация NFS в соответствии с сетевой моделью OSI.

Структура NFS включает три компонента разного уровня:

• Прикладной уровень (собственно NFS) — это вызовы удаленных процедур (rpc), которые и выполняют необходимые операции с файлами и каталогами на стороне сервера.

• Функции презентационного уровня выполняет протокол XDR (eXternal Data Representation), который является межплатформенным стандартом абстракции данных. Протокол XDR описывает унифицированную, каноническую, форму представления данных, не зависящую от архитектуры вычислительной системы. При передаче пакетов RPC-клиент переводит локальные данные в каноническую форму, а сервер проделывает обратную операцию.

• Сервис RPC (Remote Procedure Call), обеспечивающий запрос удаленных процедур клиентом и их выполнение на сервере, представляет функции сеансового уровня.

Процедура подключения сетевого ресурса средствами NFS называется «экспортированием». Клиент может запросить у сервера список представляемых им экспортируемых ресурсов. Сам сервер NFS, в отличие от, например, сервера SMB, не занимается широковещательной рассылкой списка своих экспортируемых ресурсов.

В зависимости от заданных опций, экспортируемый ресурс может быть смонтирован «только для чтения», можно определить список хостов, которым разрешено монтирование, указать использование защищенного RPC (secureRPC) и пр. Одна из опций определяет способ монтирования: «жесткое» (hard) или «мягкое» (soft).

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

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

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

С точки зрения безопасности первые реализации NFS были крайне слабы: аутентификация выполнялась, по сути, только по ip-адресу клиента. Использование NIS не намного увеличивало защищенность системы. В версиях NFS 3 и 4 эти вопросы были переработаны путем добавления поддержки списков доступа (ACL), защищенного rpc и ряда других решений, которые позволили сертифицировать NFS в минобороны США.

Общий доступ в смешанной сети

Сервис NFS идеально подходит для сетей на основе UNIX, так как поставляется практически со всеми версиями этой операционной системы. Более того, поддержка NFS реализована на уровне ядра UNIX. К сожалению, использование NFS на клиентских компьютерах с Windows создает определенные проблемы, связанные с необходимостью установки специализированного и довольно дорогого клиентского ПО. В таких сетях использование средств разделения ресурсов на основе протокола SMB/CIFS, в частности ПО Samba, выглядит более предпочтительным.

Низкоуровневые средства общего доступа. Протокол DAFS