Понятие прикладных протоколов и серверы приложений (Типы, функции, достоинства и недостатки серверов приложений)

Содержание:

Введение

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

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

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

1) рассмотреть понятие и функции прикладных протоколов,

2) изучить основные виды прикладных протоколов,

3) проанализировать понятие серверов приложений,

4) определить типы, функции, достоинства и недостатки серверов приложений,

5) исследовать модель сервера приложений.

1. Сущность и виды прикладных протоколов

1.1 Понятие и функции прикладных протоколов

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

Рисунок 1 – Прикладной протокол

В этой модели информация проходит от одного уровня к следующему, начиная с Прикладного уровня на передающем хосте, и продолжая идти вниз по иерархии до Физического уровня, а затем переходя через коммуникационный канал к хосту назначения, где информация поднимается в обратном направлении по иерархии, заканчивающейся Прикладным уровнем. Рисунок 1 показывает этот процесс пошагово [11, c.168].

Прикладной уровень, или Седьмой Уровень, является самым верхним уровнем обоих моделей – OSI и TCP/IP. Именно этот уровень предоставляет интерфейс между приложениями, которые мы используем, чтобы общаться, и лежащей в основе коммуникации сети, через которую передаются наши сообщения. Протоколы Прикладного уровня используются для обмена данными между программами, работающими на хостах источника и назначения. Существует множество протоколов Прикладного уровня, а также постоянно разрабатываются новые протоколы [1, c.119].

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

Рисунок 2 – Протоколы прикладного уровня

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

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

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

1.2 Основные виды прикладных протоколов

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

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

Протоколы РОРЗ и SMTP. Прикладные протоколы, используемые при работе с электронной почтой, называются SMTP (Simple Mail Transfer Protocol) и РОРЗ (Post Office Protocol), первый «отвечает» за отправку исходящей корреспонденции, второй — за доставку входящей [2, c.78].

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

Протокол HTTP (Hyper Text Transfer Protocol) обеспечивает передачу с удаленных серверов на локальный компьютер документов, содержащих код разметки гипертекста, написанный на языке HTML или XML, то есть веб-страниц. Данный прикладной протокол ориентирован прежде всего на предоставление информации программам просмотра веб-страниц, веб-браузерам, наиболее известными из которых являются такие приложения, как Microsoft Internet Explorer и Netscape Communicator.

HTTP –это протокол передачи гипертекста. А теперь я приведу наиболее интересные определение HTTP протокола, которые когда-либо встречал.

HTTP протокол – это правила дорожного движения в интернете, только если в жизни люди могут не соблюдать правила дорожного движения и им за это ничего не будет, то несоблюдение правил HTTP протокола ведет к тому, что пользователь не сможет работать в интернете.

Технические характеристики HTTP протокола:

- HTTP протокол работает по технологии клиент-сервер.

- HTTP протокол относится к седьмому уровню модели OSI.

- HTTP протокол относится к семейству протоколов TCP/IP.

- Для передачи данных по протоколу HTTP используется порт 80 TCP или 8080.

- Спецификация протокола RFC 2616.

- Для идентификации ресурса HTTP протокол использует URI (читай про URI в HTTP).

- HTTP протокол не имеет промежуточных состояний между запросом и ответом, конечно, клиент может получить ответ с кодом 100, но это ведь уже ответ, а не промежуточное состояние.

- HTTP протокол синхронный, но позволяет клиенту отправлять несколько запросов подряд, не дожидаясь ответа сервера, при условии, что сервер даст ответы на запросы в том порядке, как они приходили [13, c.94].

Самым распространенным примером клиента HTTP протокола является браузер, вот самые популярные клиенты HTTP протокола:

- Google Chrome;

- Mozilla FireFox;

- Opera;

- Internet Explorer;

- Яндекс Браузер;

- Safari.

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

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

Вот примеры конечных HTTP серверов:

- Apache HTTP Server;

- CERN httpd;

- nginx;

- lighthttod.

Прокси-сервера:

- Squid;

- UserGate;

- nginx [3, c.105].

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

Telnet - это протокол, который предоставляет пользователю возможность работать с удалённым компьютером как со своим собственным. Название его является сокращением от английского термина TELecommunication NETwork.

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

Назначение протокола Telnet заключается в предоставлении достаточно общего, двунаправленного, восьмибитного байт-ориентированного средства связи. Его основная задача заключается в том, чтобы позволить терминальным устройствам и терминальным процессам взаимодействовать друг с другом.

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

Telnet является стандартным протоколом для многих операционных систем, в том числе Windows и Unix-like. Для того, чтобы начать работу с ним, достаточно напечатать в командной строке "telnet". С помощью этой консольной программы можно подключаться к тем компьютерам, где запущен Telnet-сервер (разделение протокола Telnet на клиентскую и серверную часть довольно-таки условно, так как этот протокол обладает симметричностью).

К сожалению, протокол Telnet не блещет безопасностью. В нём не предусмотрены ни шифрование, ни проверка подлинности передаваемых данных, поэтому он представляет собой легкую мишень для киберпреступников. Поэтому в качестве средства управления удалёнными системами (например, серверами) теперь Telnet практически не используется - на смену ему пришёл более современный протокол SSH [14, c.115].

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

Прикладной протокол передачи данных UDP (User Datagram Protocol) используется на медленных линиях для трансляции информации как дейтаграмм.

UDP (User Datagram Protocol — пользовательский дейтаграмм-ный протокол). UDP позволяет приложениям отправлять инкапсулированные IP-дейтаграммы без установления соединений. UDP описан в RFC 768.

С помощью протокола UDP передаются сегменты, состоящие из 8-байтного заголовка, за которым следует поле полезной нагрузки. Два номера портов служат для идентификации конечных точек внутри отправляющей и принимающей машин. Когда прибывает пакет UDP, содержимое его поля полезной нагрузки передается процессу, связанному с портом назначения. В сущности, весь смысл использования UDP вместо обычного IP заключается как раз в указании портов источника и приемника. Без этих двух полей на транспортном уровне невозможно было бы определить действие, которое следует произвести с пакетом. В соответствии с полями портов производится корректная доставка сегментов [4, c.93].

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

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

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

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

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

DNS (Domain Name System — служба имен доменов) — это приложение, которое использует UDP именно так, как описано выше. В двух словах, если программе нужно найти IP-адрес по имени хоста, например, www.vanderboot.ru, она может послать UDP-пакет с этим именем на сервер DNS. Сервер в ответ на запрос посылает UDP-пакет с IP-адресом хоста. Никакой предварительной настройки не требуется, как не требуется и разрыва соединения после завершения задачи. По сети просто передаются два сообщения [15, c.83].

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

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

2.1 Понятие и назначение серверов приложений

Сервер – это специализированный компьютер или же специальное оборудование, которое используется для выполнения каких-либо узкоспециализированных функций, требующих больших вычислительных мощностей. Выполнение узкоспециализированных функций сервера обусловлено использованием специального серверного программного обеспечения [5, c.82].

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

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

Рисунок 3 - Модель "сервер приложений"

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

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

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

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

Бизнес-логика может быть реализована на стороне сервера как целиком (удаленный код), так и частично (распределенный код). В первом случае к серверу могут обращаться терминалы и «тонкие» клиенты и такое взаимодействие соответствует модели «сервер терминалов». «Толстые» и rich-клиенты могут получать компоненты серверного приложения и выполнять их на своей стороне (например javascript, апплеты, flash) [17, c.115].

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

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

- для поддержки новых устройств нужно адаптировать только фронт-энд, не затрагивая прикладную логику;

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

Клиенты могут взаимодействовать с приложениями через API сервера (Java-клиент <—> контейнер сервлетов <—> сервлет). Большую гибкость и универсальность представляет взаимодействие через сторонние сервисы, в первую очередь — через веб-сервер.

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

Но это нечто большее и меньшее одновременно: сервер приложений предоставляет среду, в которой прикладные программы могут работать, независимо от того, что и как именно они делают [6, c.79].

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

- Предоставляет модель контейнера для приложений.

- Предоставляет сервисные услуги для программ.

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

- Соответствует индустриальным спецификациям и стандартам.

Добавим сюда же обслуживание веб-страниц, ввиду реальной востребованности технологий на основе WWW.

По приведенным признакам в рассматриваемую категорию попадают, например, традиционные терминал-серверные системы, технология CGI, контейнеры Java-сервлетов и др.

Серверы терминалов представляют среду для удаленного выполнения программ, в качестве которой выступает сама операционная система. Доступ к ним осуществляется по протоколам удаленного управления (telnet, ssh, RDP, VNC и т. п.) из клиентского ПО (эмулятор терминала, средства управления удаленным рабочим столом и т.п.). Управление запущенной программой выполняется через эмулируемый на клиенте пользовательский интерфейс (текстовый или графический) операционной системы. На серверной стороне взаимодействие программ с ОС реализуется через системные вызовы. Управление также осуществляется средствами операционной системы. Разработка может вестись на любом языке, доступном в конкретной ОС.

Общий шлюзовый интерфейс (CGI) — технология доступа к приложениям через веб-сервер. Отличия от сервера терминалов здесь в том, что пользовательский интерфейс предоставляется в виде веб-страниц. Запросы веб-клиентов, обращенные к программам, размещенным в выделенном каталоге (как правило cgi или cgi-bin) перенаправляются на их вход через стандартный поток ввода (stdin). Результаты выполнения в виде гипертекста приложение возвращает веб-серверу через stdout [18, c.79].

Платформа 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.

2.2 Типы, функции, достоинства и недостатки серверов приложений

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

В качестве примеров серверных приложений можно привести:

- любой HTTP сервер, например, сервер Apache или lighttpd;

- сервер баз данных MySQL;

- готовые сборки для веб-разработчика, такие как Denwer или локальный сервер AMPPS [16, c.89].

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

Система IVR (Interactive Voice Response, система интерактивных голосовых меню) позволяют владельцу (арендатору) call-центра более рационально использовать труд операторов. Применение такой функции call-центра, как IVR особенно эффективно в том случае, когда в задачи колл-центра входит предоставление ответов на типовые вопросы абонентов, при этом большая часть поступающей нагрузки обрабатывается автоматизированной системой с элементами самообслуживания пользователей. В последних разработках в этой области применяются системы распознавания речи [6, c.83].

Модуль упреждающего дозвона (PD, Predictive Dialer) делает удобной процедуру организации большого количества исходящих вызовов, например, при проведении телефонного опроса или телемаркетинга. Система PD способна самостоятельно устанавливать соединение с абонентами из заранее составленного списка, а затем передает вызов оператору или на сервер IVR. Таким образом, персонал call-центра обслуживает лишь состоявшиеся вызовы.

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

Сервер обработки сообщений электронной почты и мгновенных сообщений (IM, Instant messaging) позволяет пользователям выбирать максимально удобное средство взаимодействия с ЦОВ. Запросы, как и телефонные вызовы, на обслуживание в систему ACD.

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки:

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

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

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

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

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

· «предприятие — потребитель» ( B 2 C , business - to - consumer ), такие как онлайновая продажа товаров, бронирование билетов и мест в гостиницах, услуги страхования;

· «предприятие — предприятие» ( B 2 B , business - to - business ), такие как виртуальные торговые площадки, позволяющие заключать торговые сделки между предприятиями;

· «предприятие — сотрудник» ( B 2 E , business - to - employer ), такие как корпоративные порталы.

Нередко в корпоративных решениях применяются конфигурации, содержащие несколько серверов приложений. Как правило, подобные решения обладают многозвенной архитектурой, при этом серверы приложений обычно располагаются между сервером баз данных и Web -сервером либо между сервером баз данных и клиентскими приложениями. Нередко функциональность Web -сервера реализуется и в самом сервере приложений [7, c.115].

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

Из технологий, поддерживаемых современными серверами приложений, следует в первую очередь отметить средства интеграции приложений, созданных на различных платформах, в том числе поддержку Web -сервисов, средства разработки приложений, наличие продуктов специализированного назначения, основанных на данном сервере приложений (например, средств управления информационным наполнением), поддержку беспроводных Лидерами рынка серверов приложений на данный момент является компания IBM . Из других наиболее известных продуктов, относящихся к категории серверов приложений, следует отметить серверы компаний Oracle , Sun Microsystems , Borland , Sybase и другие.

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

Сервер приложений это набор физического и программного обеспечения, которое способно обеспечить доступ клиентов к программам, выполняющихся непосредственно на серверном оборудовании. По сути это некий комплект, к которому можно получить доступ при помощи специальных API и обеспечить не только вывод каких-либо данных, но и оптимизировать исполнение программного кода на любых устройствах. Давайте подробней разберемся в том, как работает сервер приложений [20, c.89].

Модель сервера приложений - эта модель, которая является расширением двухуровневой модели и в ней вводится дополнительный промежуточный уровень между клиентом и сервером. Архитектура трехуровневой модели приведена на рис. 10.7. Этот промежуточный уровень содержит один или несколько серверов приложений.

Рисунок 4 -  Модель сервера приложений

В этой модели компоненты приложения делятся между тремя исполнителями:

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

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

- Серверы баз данных в этой модели занимаются исключительно функциями СУБД: обеспечивают функции создания и ведения БД, поддерживают целостность реляционной БД, обеспечивают функции хранилищ данных (warehouse services). Кроме того, на них возлагаются функции создания резервных копий БД и восстановления БД после сбоев, управления выполнением транзакций и поддержки устаревших (унаследованных) приложений (legacy application) [8, c.96].

Отметим, что эта модель обладает большей гибкостью, чем двухуровневые модели. Наиболее заметны преимущества модели сервера приложений в тех случаях, когда клиенты выполняют сложные аналитические расчеты над базой данных, которые относятся к области OLAP-приложений. (On-line analytical processing.) В этой модели большая часть бизнес-логики клиента изолирована от возможностей встроенного SQL, реализованного в конкретной СУБД, и может быть выполнена на стандартных языках программирования, таких как C, C++, SmallTalk, Cobol. Это повышает переносимость системы, ее масштабируемость.

Функции промежуточных серверов могут быть в этой модели распределены в рамках глобальных транзакций путем поддержки XA-протокола (X/Open transaction interface protocol), который поддерживается большинством поставщиков СУБД.

Заключение

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

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

К протоколам прикладного уровня, обеспечивающим доступ к информационным ресурсам Internet, относятся: протокол эмуляции терминала Telnet; протоколы электронной почты SMTP, UUCP; протоколы распределенных файловых систем – NNTP, Gopher, FTP.

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

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

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

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

1. Алтухов Е.В. Основы информатики и вычислительной техники: Учебное пособие. – М.: Высш. Школа, 2015. – 303 с.
2. Введение в операционные системы. - СПб.: БХВ-Петербург, 2014. - 624 с.
3. Веретенникова Е.Г., Петрушина С.М., Савельева Н.Г. Информатика: Учебное пособие. Серия «Учебный курс». – Ростов н/Д: Издательский центр «МарТ», 2014. – 416 с.
4. Вычислительные системы, сети и телекоммуникации: Учебник / Под ред. А.П. Пятибратова. – М.: Финансы и статистика, 2013. – 521 с.
5. Информатика. Базовый курс. 2-е издание / Под ред. С.В. Симоновича. – СПб.: Питер, 2016. – 640 с.
6. Информационные системы и технологии в экономике и управление: Учебник для бакалавров /В.В. Трофимов. – М.: Юрайт, 2012 – 521 с.
7. Иртегов Дм. Введение в операционные системы /Иртегов Дм., - СПб. :БХВ-Петербург, 2012. - 624 с
8. Новожилов О. П. Информатика: учеб.пособие для бакалавров /Новожилов О. П., - М. :Юрайт, 2014. - 564 с.
9. Олифер В. Г. Сетевые операционные системы: учеб. пособие для вузов по спец. "Информатика и вычислительная техника" /Олифер В. Г., Олифер Н. А. - СПб. :Питер, 2012. - 544 с.
10. Основы современных компьютерных технологий: учеб. пос. для высш. и средн. учеб. заведений технич. и экономич. спец. под ред. А. Д. Хомоненко 2-е изд. - СПб.: КОРОНА-принт, 2016. - 448 с.
11. Острейковский В. А. Информатика: учебник для вузов. - М.: Высш. школа, 2012. - 511 с.
12. Партыка Т. Л. Операционные системы, среды и оболочки: учеб. пособие для СПО - М.: ФОРУМ ; ИНФРА-М, 2013. - 400 с
13. Попов В.Б. Основы компьютерных технологий. – М.: Финансы и статистика, 2014 – 656 с.
14. Партыка Т. Л. Операционные системы, среды и оболочки : учеб. пособие для СПО /Партыка Т. Л., Попов И. И. - М. :ФОРУМ ; ИНФРА-М, 2013. - 400 с.
15. Синицын С. В. Операционные системы : учеб. для вузов /Синицын С. В., Батаев А. В., Налютин Н. Ю. - М. :Академия, 2015. - 304 с.
16.  Столлингс Вильям Операционные системы. Внутреннее устройство и принципы проектирования /Столлингс Вильям, - М. :Вильямс, 2012. - 848 с.
17. Таненбаум, Э. Распределенные системы: Принципы и парадигмы / Э. Таненбаум, М. Стеен. - СПб: Питер, 2013 - 877c.
18. Томас Р. Операционная система UNIX : руководство для пользователей / Томас Р., Йейтс Дж. пер. с англ. В. В. Леонаса ; под ред. И. Г. Шестакова - М.: ИНФРА-М, 2015. - 352 с.
19. Хлебников А. А. Информатика: учеб. для СПО /Хлебников А. А., - Ростов н/Д :Феникс, 2016. - 507 с.
20. Ясенев, В.Н. Информационные системы и технологии в экономике: учебное пособие / В.Н. Ясенев. - перераб. и доп.- М.: ЮНИТИ, 2014 – 560c.