Применение серверов приложений в сетях NGN

В сетях NGN серверы приложении принимают участие в предоставлении различных дополнительных коммуникационных и информационных услуг пользователям этих сетей и применяются для управления со стороны пользователя предоставлением услуги. Условно весь спектр возможных услуг можно разделить на четыре класса:

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

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

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

- услуги, специфичные для широкополосных сетей связи (видео по заказу, игры по заказу, интерактивное телевидение и т. п.).

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

Помимо предоставления услуги, сервер приложений отвечает за управление конфигурированием услуги со стороны пользователя в интерактивном режиме. Учитывая, что современные пользовательские терминалы сетей NGN обладают графическим пользовательским интерфейсом (SIP-телефоны) и что с сервером приложений может взаимодействовать любой компьютерный терминал (ПК, КПК, смартфон и т.п.), сервер приложений должен быть способен взаимодействовать с пользователем посредством графического интерфейса.

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

- файловые серверы - неорганизованное хранилище информации с общим доступом;

- информационные или серверы баз данных - организованное хранилище информации с определенной логикой доступа;

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

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

- где и как хранится информация;

- где и как обрабатывается информация;

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

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

Клиенты сервера приложения в зависимости от их функциональности делятся на «тонких» и «толстых» (в терминах модели «клиент-сервер»). Функциональность клиента определяется степенью обработки пользовательского ввода, степенью обработки информа­ционного контента и правилами формирования пользовательского интерфейса (интерфейса отображения или представления информации). Каждый из этих факторов, определяющих функциональность клиента, можно условно разделить на несколько градаций (методов реализации). Для упрощения ссылок этим градациям будут даваться условные названия. Пользовательский ввод может обрабатываться следующим образом:

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

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

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

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

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

- физическим отображением - за формирование пользовательского интерфейса отвечает сервер приложения, а клиент его только физически отображает (например, попиксельное или посимвольное отображение). Преимуществом является то, что к возможностям клиентского терминала предъявляются минимальные требования, а недостатком – то, что создается большая нагрузка на сервер и канал передачи. Помимо этого, имеется очень высокая чувствительность к задержкам в сети с точки зрения восприятия интерфейса пользователем;

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

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

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

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

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

Функциональность клиента определяется сочетанием классифицированных выше факторов. В соответствии с этим сочетанием клиент приобретает те или иные плюсы и минусы. Условно клиентов по функциональности можно разделить на следующие основные типы:

- терминальный - для обработки пользовательского ввода используется последовательный метод: пользовательский интерфейс формируется методом физического отображения, и никакая обработка информационного контента на стороне клиента не производится;

- web-клиент - пользовательский ввод обрабатывается групповым образом, формирование пользовательского интерфейса выполняется методом компиляции по инструкциям, и обработка информационного контента на стороне клиента не производится;

- апплет (Applet) - для пользовательского ввода может использоваться метод обработки групповым образом или же метод с дополнительной обработкой: пользовательский интерфейс формируется методом компиляции на сервере. По степени обработки информа­ционного контента на стороне клиента ограничений нет. Она обычно определяется типом приложения, но общей практикой является использование ограниченной обработки на стороне клиента;

- программный - пользовательский ввод обрабатывается групповым методом с дополнительной обработкой; формирование пользовательского интерфейса выполняется по методу компиляции на клиенте: информационный контент обычно подвергается значительной обработке.

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

Взаимодействие между клиентом и сервером приложений может осуществляться посредством любого стандартного протокола информационного обмена в компьютерных сетях (Telnet, SNMP, LDAP, FТР, НТТР, RРС и т.п.) или специального (специфичного для приложения или технологии разработки) протокола поверх транспортного уровня (например, поверх TCP/IP или UDP/IP), или поверх вышеуказанных стандартных протоколов, или посредством группы протоколов, а не одного какого-либо протокола. Выбор протоколов взаимодействия определяется потребностями конкретного приложения, т.е. зависит от типа клиента, вида информационного контента, используемых технологий разработки приложений и т.п. Сегодня наиболее часто в качестве базового протокола взаимодействия используется НТТР, так как он обладает достаточной функциональностью для приложений «клиент-сервер» и при этом обеспечивает прозрачную (беспрепятственную) передачу пользовательского графика поверх любых сетей.

Логика взаимодействия между серверным и клиентским процессами приложения обычно строится на базе модели «вызова удаленной процедуры» (RРС), так как это значительно облегчает процесс разработки приложения и упрощает логическое представление приложения в виде единого целого, выполняющего в единой среде исполнения.

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

- СОМ, DCOM, OLE;

- СОRВА;

- SOAP XML, UDDI WSDL.

Самой перспективной на сегодняшний день объектной технологией является SOAP XML, так как она наиболее универсальна, основывается на международных стандартах и имеет обширную поддержку со стороны различных производителей программного обеспечения. Эта технология чаще всего используется для создания web-сервисов (серверный процесс) и для обеспечения их взаимодействия с клиентским процессом. В качестве клиента в этом случае обычно выступает апплет или «активный» web-клиент. Как говорилось ранее, для работы данных клиентов требуется специальная среда исполнения. В основном используются только J2ЕЕ (Java SUN) и «.NET Framework» (Microsoft) среды исполнения, так как они базируются на открытых стандартах и поддерживаются большинством производителей программного обеспечения.

В компьютерных сетях взаимодействие между клиентом и сервером происходит напрямую или при посредничестве специализированных серверов (ргоху и т.п.). В сетях NGN такое взаимодействие осуществляется при участии программного коммутатора (SХ - SoftSwitch). Программный коммутатор в этом случае выполняет следующие функции:

- аутентификации и авторизации, как клиента, так и сервера приложений (АS – Application Server);

- учета (accounting) предоставленных услуг, трафика, времени соединения и т.п.;

- управления соединением между клиентом и сервером, а также другими соединениями, предусмотренными логикой приложения (услуги);

- управления сетевыми экранами (FW - FireWall) при взаимодействии с другими сетями, например, когда сервер приложений и клиент находятся в разных сетях;

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

На рис. 2.10 представлена возможная логическая схема информационных потоков между различным оборудованием NGN сети при взаимодействии клиента сети с сервером приложений. Через программный коммутатор обычно проходят только потоки управления, а потоки, связанные с передачей информационного контента приложения, проходят помимо него. В качестве протокола взаимодействия между программным коммутатором и сервером приложений, а также между коммутатором и абонентом сети наиболее перспективным считается использование протокола SIP и его расширения.

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

- сервер приложений обрабатывает запросы клиента и. взаимодействуя с сервером баз данных (DВ), ассоциированным с программным коммутатором, вносит необходимые изменения в базы данных. Коммутатор, в свою очередь, взаимодействует с сервером баз данных (обычно посредством протокола LDАР) и предоставляет клиенту сети запрошенную услугу с заданными параметрами. Недостатком данного сценария является то, что структура базы данных должна быть известна обоим устройствам, т.е. теряется универсальность и гибкость взаимодействия;

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

Рис. 2.10. Организация уровня предоставления услуг и управления услугами

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

- сервер приложений обрабатывает запросы клиента и управляет программным коммутатором в процессе предоставления услуги. Подобное взаимодействие аналогично взаимодействию SSР с SСР в интеллектуальных сетях связи. В этом случае в качестве протокола взаимодействия может использоваться протокол INАР.

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