Преподаватель который помогает студентам и школьникам в учёбе.

Понятие прикладных протоколов и серверы приложений (Характеристика понятия прикладных протоколов)

Содержание:

ВВЕДЕНИЕ

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

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

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

Объектом исследования выступают прикладные протоколы и серверы приложений, а предметом – понятие прикладных протоколов и серверы приложений.

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

охарактеризовать понятие прикладных протоколов;
изучить общие принципы организации функционирования прикладных протоколов (OSI);
рассмотреть примеры прикладных протоколов, среди которых такие протоколы, как ICMP, FTP, HTTP, POP и SMTP, SLIP;
проанализировать понятие сервера приложений;
рассмотреть характерную реализацию серверов приложений;
дать характеристику серверам приложений со стороны преимуществ и недостатков.

Для реализации исследования за основу были взяты труды таких известных исследователей проблемы, как Олифер В. Г., Олифер Н. А., Хант К., Блэк Ю. и Новиков Ю.В.

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

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

Характеристика понятия прикладных протоколов

Необходимо различать понятия сетевых приложений и протоколов прикладного уровня. Протоколы прикладного уровня являются частью (хотя и весьма большой) сетевых приложений. Рассмотрим два примера. Web является сетевым приложением, позволяющим пользователям получать web-документы по запросу и состоящим из множества компонентов, включая стандарт формата документов (HTML), браузеры (Netscape Navigator, Microsoft Internet Explorer и др.), web-серверы (например, Apache, Microsoft или Netscape), протоколы прикладного уровня. Протокол прикладного уровня для web носит название протокола передачи гипертекста (HyperText Transfer Protocol, HTTP) и описывает формат и порядок обмена сообщениями между клиентом и сервером (RFC 2646). Таким образом, HTTP является лишь частью web-приложения.

В качестве второго примера рассмотрим приложение электронной почты. Электронная почта Интернета также состоит из множества компонентов: почтовых серверов, содержащих почтовые ящики пользователей, программ для просмотра и создания электронных писем, стандартов, описывающих структуру электронных писем, протоколов прикладного уровня, регламентирующих порядок обмена сообщениями серверов между собой и с оконечными системами пользователей, а также интерпретацию полей, из которых состоят электронные письма. Основным протоколом прикладного уровня для электронной почты является протокол простой передачи сообщений (Simple Mail Transfer Protocol, SMTP). Как мы видим, SMTP (RFC 2821) – лишь часть (хотя и достаточно большая) структуры приложений электронной почты^[1].

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

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

Некоторые из протоколов прикладного доступа (HTTP, SMTP и др.) являются официально документированными в RFC. Это означает, что если разработчик нового браузера будет следовать стандарту, то браузер сможет получать документы с любого web-сервера, построенного по этому же стандарту. Тем не менее, существует множество протоколов прикладного уровня, которые не стандартизированы и при этом используются для поддержки коммерческих продуктов. В частности, это характерно для Интернет-телефонии^[2].

Общие принципы организации и функционирования прикладных протоколов (OSI)

Прикладной уровень является наивысшим уровнем в эталонной модели OSI RM и единственным средством доступа прикладных процессов к функциональной среде OSIE.

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

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

Совокупность средств, с помощью которых выполняются все элементы взаимодействия процессов, называется прикладной ассоциацией (Application Association)^[3].

Примерами таких элементов взаимодействия являются:

идентификация и аутентификация прикладных процессов,
согласование и установления прикладного контекста взаимосвязи,
обмен прикладными блоками данных,
управление режимами взаимосвязи,
прекращение взаимосвязи^[4]

Взаимодействие прикладных процессов осуществляется посредством обмена прикладными протокольными блоками данных (Application Protocol Data Unit - APDU).

Протокольные блоки данных

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

Различаются две категории прикладных сервисных элементов:

общие;
специальные.

Общие прикладные сервисные элементы (Common Application Service Elements - CASE) обеспечивают услуги общесистемного характера, которые обычно используются большинством прикладных процессов.

Специальные элементы прикладных услуг (Special Application Service Elements - SASE) ориентированы на удовлетворение требований узкоспециализированных применений^[5].

Общие прикладные сервисные элементы

Сервисный элемент управления ассоциацией (Association control service element – ACSE) [X.217, X.227].
Сервисный элемент надежной передачи (Reliable transfer service element – RTSE) [X.218, X.228].
Сервисный элемент удаленной операции (Remote operations service element – ROSE) [X.219, X.229, X.881, X.882].
Сервисный элемент фиксации, параллельности и восстановления (Commitment, Concurrency and Recovery service element - CCRSE) [X.852].

Специальные элементы прикладных услуг

Сервисный элемент передачи и управления файлами (File Transfer, Access and Management – FTAM) [ISO/IEC 8571:1989].
Сервисный элемент передачи и управления заданиями (Job Transfer and Management – JTM) [ISO/IEC 8831].
Сервисный элемент виртуального терминала (Virtual Terminal Service, Basic Class) [ISO/IEC 9040].
Сервисный элемент удаленного доступа к базам данных (Remote Database Access - RDA) [ISO/IEC 9579-1, ISO/IEC 9579-2].
Сервисный элемент распределенной обработки (Distributed Transaction Processing - TP) [X.861].
Сервисный элемент сетевого управления (Common management information service) [X.710]^[6].

Для иллюстрации организации работы прикладного уровня рассмотрим простой пример, в котором для программы (program) пользователя (user) реализуется возможность доступа к сервису простой электронной почты, т.е. через свою программу пользователь может готовить и пересылать сообщения другому удаленному пользователю, используя специальный прикладной сервисный элемент системы обработки сообщений MHS (Message Handling System).

Прикладной процесс (Application Process) программы пользователя в данном примере состоит из прикладной сущности (Application Entity), ответственной за реализацию функций взаимосвязи с другими пользователями, и из компоненты, реализующей взаимосвязь прикладного сервисного элемента с локальными ресурсами реальной открытой системы и называемой часто прикладным агентом (Application Agent)^[7].

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

Далее сообщение, используя стек протоколов модели OSI с первого по шестой уровень (этот стек представлен на рисунке поставщиком представительного сервиса (presentation service provider)), передается в виде прикладного протокольного блока данных (APDU) конечной системе-адресату. При получении сообщения конечной системой оно через сервисный элемент MHS будет передано локальному агенту, который после анализа этого сообщения запишет его в локальную файловую систему (file storage), точнее в почтовый ящик (mail folder), и проинформирует программу пользователя-получателя о поступлении сообщения^[8].

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

Протокол ICMP

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

Протокол Internet (IP) используется для обработки датаграммы, передаваемой между хост-компьютерами в системе объединенных сетей, называемой Catenet. Устройства, осуществляющие соединение различных сетей, называются шлюзами. Для обеспечения управления шлюзы общаются друг с другом посредством протокола Gateway to Gateway Protocol (GGP). Порой шлюз или хост-компьютер, получающий данные, обменивается информацией с хост-компьютером, отправляющим эти данные. Именно для таких целей используется данный протокол - протокол контрольных сообщений Internet (ICMP). ICMP использует основные свойства протокола Internet (IP), как если бы ICMP являлся протоколом более высокого уровня. Однако фактически ICMP является составной частью протокола Internet и должен являться составной частью каждого модуля IP^[9].

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

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

Сообщения ICMP протокола, как правило, оповещают об ошибках, возникающих при обработке датаграмм. Чтобы проблемы с передачей сообщений не вызывали появление новых сообщений, чтобы это в свою очередь не привело к лавинообразному росту количества сообщений, циркулирующих в сети, констатируется, что нельзя посылать сообщения о сообщениях. Также констатируется, что ICMP сообщения можно посылать только о проблемах, возникающих при обработке нулевого фрагмента в сегментированной датаграмме (нулевой фрагмент имеет нуль в поле смещения фрагмента)^[10].

Протокол FTP

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

Протокол передачи файлов (File Transfer Protocol – FTP) – это стандартный механизм для копирования файла от одного хоста другим [19]. Передача файлов от одного компьютера к другому – это одна из большого числа общих задач, выполнение которой ожидается от организованной сети и взаимодействия между сетями^[11].

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

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

FTP использует два заданных порта: порт 21 для управления и порт 20 для передачи данных.

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

FTP

Рисунок 2 FTP

Соединение передачи сигналов управления остается открытым в течение всей интерактивной сессии FTP. Соединение передачи данных каждый раз открывается командой, чтобы вызвать передаваемый файл, и затем закрывается, когда файл передан. Другими словами, когда пользователь начинает FTP-сессию, соединение для передачи сигналов управления открывается. Пока оно открывается, соединение для передачи данных может быть открыто и закрыто много раз, если передается несколько файлов^[12].

Протокол HTTP

HTTP (HyperText Transfer Protocol - RFC 1945, RFC 2616) - протокол прикладного уровня для передачи гипертекста.

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

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

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

Все программное обеспечение для работы с протоколом HTTP разделяется на три основные категории:

Серверы – поставщики услуг хранения и обработки информации (обработка запросов).
Клиенты – конечные потребители услуг сервера (отправка запросов).
Прокси-серверы для поддержки работы транспортных служб.

Основными клиентами являются браузеры, например: Internet Explorer, Opera, Mozilla Firefox, Netscape Navigator и другие. Наиболее популярными реализациями веб-серверов являются: Internet Information Services (IIS), Apache, lighttpd, nginx. Наиболее известные реализации прокси-серверов: Squid, UserGate, Multiproxy, Naviscope.

"Классическая" схема HTTP-сеанса выглядит так:

Установление TCP-соединения.
Запрос клиента.
Ответ сервера.
Разрыв TCP-соединения^[14].

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

Протоколы POP и SMTP

Электронная почта существуют уже более двух десятилетий: до 1990 года она использовалась преимущественно в научных организациях, в 90-е - получила широкую известность и стала использоваться повсеместно. По самым скромным оценкам в мире более 50 миллионов человек пользуются услугами электронной почты. В целом же трафик электронной почты занимает только 3.7% всего сетевого. Как и любой форме коммуникаций, электронной почте присущ определенный стиль и набор соглашений. В частности, общение по электронной почте носит неформальный и демократичный характер.

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

Развитие технологии Internet привело к появлению современных протоколов для обмена сообщениями, которые предоставляют большие возможности для обработки писем, разнообразные сервисы и удобство в работе. Так, например, протокол SMTP, работающий по принципу клиент-сервер, предназначен для отправки сообщений с компьютера к адресату. Обычно доступ к серверу SMTP не защищается паролем, так что можно использовать для отправки писем любой известный сервер в сети. В отличие от серверов для отправки писем, доступ к серверам для хранения сообщений защищается паролем. Поэтому необходимо использовать сервер или службу, в которой существует учётная запись. Эти серверы работают по протоколам POP и IMAP, которые различаются способом хранения писем.

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

Протокол IMAP удобен тем людям, которые пользуются постоянным подключением к сети. Сообщения, поступившие на адрес, также хранятся на сервере, но, в отличие от POP3, при проверке почты сначала будут загружены только заголовки сообщений. Само письмо можно будет прочитать после выбора заголовка сообщения (оно загрузиться с сервера). Ясно, что при коммутируемом соединении работа с почтой по этому протоколу приводит к неоправданным потерям времени^[16].

Одна из наиболее популярных сетевых услуг – это электронная почта (e-mail). TCP/IP протокол, который поддерживает сообщения электронной почты в Интернете — это простой протокол электронной почты (SMTP — Simple Mail Transfer Protocol). Он описывает систему команд и соглашений для посылки сообщений к другим компьютерным пользователям, основанную на адресах электронной почты. SMTP обеспечивает обмен почтовыми сообщениями между пользователями одной и той же или различных компьютерных сетей. Система поддерживает:

посылку одиночных сообщений одному или более получателям;
посылку сообщений, включающих в себя текст, голосовые сообщения, видео или графические материалы;
посылку сообщений для пользователей сетей, не входящих в Интернет^[17].

Протокол SLIP

Протокол SLIP (Serial Line Internet Protocol) позволяет использовать протокол TCP/IP при подключении через последовательный порт. К этому порту может быть подключен либо модем, либо выделенная асинхронная телефонная линия (leased asynchronous line) какого-либо вида. Разумеется, при таком подключении требуется близко расположенный SLIP-сервер с соответствующими телефонными номерами. Многие университеты и коммерческие организации предоставляют доступ к SLIP-серверу за умеренную плату.

В настоящий момент имеется две основные программы, работающие с протоколом SLIP: программы dip и slattach. Обе программы предназначены для того, чтобы установить соединение SLIP через последовательное устройство. Для осуществления соединения SLIP необходимо воспользоваться одной из этих программ; просто позвонив на номер сервера одной из коммуникационных программ (например, kermit) и выполнив команды ifconfig и route, того же результата достичь не удастся. Дело в том, что программы dip и slattach выдают специальное обращение обращение ioctl() к системе, которое перехватывает управление последовательным устройством и начинает использовать его для подключения SLIP^[18].

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

Программа dip может быть использована также для конфигурирования системы Linux в качестве SLIP-сервера. При этом другие компьютеры могут звонить на данный компьютер и подключаться к сети через вторичное подключение Ethernet (secondary Ethernet connection). Для более полной информации об этом следует обратиться к соответствующим документам и экранной документации к программе dip.

Подключение SLIP кардинально отличается от подключения Ethernet тем, что в "сети" присутствует всего два компьютера: SLIP-клиент (ваш компьютер) и SLIP-сервер. По этой причине соединение SLIP часто называется соединением "точка-точка" ("point-to-point" connection). Обобщение этой идеи под названием "протокол PPP" (Point to Point Protocol) также реализовано в системе Linux^[19].

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

По сути, конфигурирование подключения SLIP напоминает конфигурированию сетевой заглушки или адаптера Ethernet. Основные отличия обсуждаются ниже. Для ознакомления надо прочесть предыдущий раздел, посвященный конфигурированию основных файлов, относящихся к протоколу TCP/IP, и затем прочесть про отличия в данном разделе^[20].

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

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

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

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

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

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

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

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

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

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

Мобильный софт

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

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

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

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

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

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

Предоставляет модель контейнера для приложений.
Предоставляет сервисные услуги для программ.
Обеспечивает управление приложениями и/или представляет средства их разработки.
Соответствует индустриальным спецификациям и стандартам.
Добавим сюда же обслуживание веб-страниц, ввиду реальной востребованности технологий на основе WWW^[23].

Реализация серверов приложений

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

Унаследованные решения

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

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

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

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

Контейнер сервлетов — один из архитектурных компонентов J2EE, представляющий окружение для выполнения сервлетов. Сервлет — это Java-приложение, выполняющееся на стороне сервера (в отличие от апплета). Контейнер сервлетов может работать как полноценный самостоятельный сервер, но чаще используется (интегрируется) совместно с другим серверным ПО. Обеспечивает обмен данными между сервлетом и клиентами, берёт на себя выполнение таких функций, как создание программной среды для функционирующего сервлета, идентификацию и авторизацию клиентов, организацию сессии для каждого из них^[25].

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

Примером реализации контейнера сервлетов является 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^[26].

Серверы приложений: преимущества и недостатки

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

Для достижения данной цели были выполнены следующие задачи:

охарактеризовано понятие прикладных протоколов;
изучены общие принципы организации функционирования прикладных протоколов (OSI);
рассмотрены примеры прикладных протоколов, среди которых такие протоколы, как ICMP, FTP, HTTP, POP и SMTP, SLIP;
проанализировано понятие сервера приложений;
рассмотрена характерная реализация серверов приложений;
дана характеристика серверам приложений со стороны преимуществ и недостатков.

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

Блэк Ю, Сети ЭВМ: протоколы, стандарты, интерфейсы / Ю. Блэк; перев. с англ. - М.: МИР
Высокопроизводительные сети. Энциклопедия пользователя / Марк А. Спортак и др.; перев. с англ. - Киев, ДиаСофт, 1998
Крейнак Д., Хебрейкен Д. «Энциклопедия ИНТЕРНЕТ». Санкт-Петербург, 2010
Лапонина О.Р.«Основы сетевой безопасности: криптографические алгоритмы и протоколы взаимодействия» М.: ИНТУИТ.ру, 2005. – 608 с.
Ливингстон Б., Штрауб Д. «Компьютер у вас дома», Москва 2001 г.
Медведовский И.Д., Семьянов П.В., Леонов Д.Г.Атака на Internet 2-е изд., перераб. и доп. –М.: ДМК, 1999.
Немет Э., Снайдер Г., Сибасс С., Хейн Т.Р.UNIX: руководство системного администратора: Пер. с англ. –К.: BHV
Новиков Ю.В., Кондратенко С.В. «Основы локальных сетей» М.: ИНТУИТ.ру, 2005. – 355 с.
Олифер В.Г., Олифер Н.А. «Компьютерные сети. Принципы, технологии, протоколы» СПб.: Питер, 2005. – 864 с.
Олифер В.Г., Олифер Н.А. «Основы сетей передачи данных» М.: ИНТУИТ.ру, 2005. – 176 с.
Паркер Т., Сиян К., TCP/IP. Для профессионалов. 3-е издание / Паркер Т., Сиян К. –СПб.: Питер,2004
Рендалл Н. «Кластеризация серверов». PC Magazine № 2, 1998 г.
Хант К., Персональные компьютеры в сетях TCP/IP / Хант К.; перев. с англ. - BHV-Киев, 1997.

Олифер В.Г., Олифер Н.А. «Компьютерные сети. Принципы, технологии, протоколы» СПб.: Питер, 2005. –702 с ↑
Новиков Ю.В., Кондратенко С.В. «Основы локальных сетей» М.: ИНТУИТ.ру, 2005. – 312 с. ↑
Олифер В.Г., Олифер Н.А. «Основы сетей передачи данных» М.: ИНТУИТ.ру, 2005. – 98 с. ↑
Олифер В.Г., Олифер Н.А. «Основы сетей передачи данных» М.: ИНТУИТ.ру, 2005. – 103 с. ↑
Хант К., Персональные компьютеры в сетях TCP/IP / Хант К.; перев. с англ. - BHV-Киев, 1997, 134 с. ↑
Хант К., Персональные компьютеры в сетях TCP/IP / Хант К.; перев. с англ. - BHV-Киев, 1997, 141с. ↑
Ливингстон Б., Штрауб Д. «Компьютер у вас дома», Москва 2001 г., 187 с. ↑
Ливингстон Б., Штрауб Д. «Компьютер у вас дома», Москва 2001 г., 193с. ↑
Блэк Ю, Сети ЭВМ: протоколы, стандарты, интерфейсы / Ю. Блэк; перев. с англ. - М.: МИР, 234 с. ↑
Блэк Ю, Сети ЭВМ: протоколы, стандарты, интерфейсы / Ю. Блэк; перев. с англ. - М.: МИР, 238 с. ↑
Новиков Ю.В., Кондратенко С.В. «Основы локальных сетей» М.: ИНТУИТ.ру, 2005. – 312 с. ↑
Новиков Ю.В., Кондратенко С.В. «Основы локальных сетей» М.: ИНТУИТ.ру, 2005. – 317 с ↑
Паркер Т., Сиян К., TCP/IP. Для профессионалов. /Паркер Т., Сиян К. –СПб.: Питер,2004, 217 с. ↑
Паркер Т., Сиян К., TCP/IP. Для профессионалов. /Паркер Т., Сиян К. –СПб.: Питер,2004, 225 с. ↑
Паркер Т., Сиян К., TCP/IP. Для профессионалов. /Паркер Т., Сиян К. –СПб.: Питер,2004, 231 с. ↑
Паркер Т., Сиян К., TCP/IP. Для профессионалов. /Паркер Т., Сиян К. –СПб.: Питер,2004, 243 с. ↑
Олифер В.Г., Олифер Н.А. «Основы сетей передачи данных» М.: ИНТУИТ.ру, 2005. – 124 с. ↑
Хант К., Персональные компьютеры в сетях TCP/IP / Хант К.; перев. с англ. - BHV-Киев, 1997, 342 с. ↑
Хант К., Персональные компьютеры в сетях TCP/IP / Хант К.; перев. с англ. - BHV-Киев, 1997, 356 с. ↑
Паркер Т., Сиян К., TCP/IP. Для профессионалов. 3-е издание / Паркер Т., Сиян К. –СПб.: Питер, 134 с. ↑
Немет Э., Снайдер Г., Сибасс С., Хейн Т.Р.UNIX: руководство системного администратора: Пер. с англ. –К.: BHV ↑
Ливингстон Б., Штрауб Д. «Компьютер у вас дома», Москва 2001 г, 249 с. ↑
Ливингстон Б., Штрауб Д. «Компьютер у вас дома», Москва 2001 г, 256 с. ↑
Крейнак Д., Хебрейкен Д. «Энциклопедия ИНТЕРНЕТ». Санкт-Петербург, 2010, 187 с. ↑
Крейнак Д., Хебрейкен Д. «Энциклопедия ИНТЕРНЕТ». Санкт-Петербург, 2010, 195 с. ↑
Медведовский И.Д., Семьянов П.В., Леонов Д.Г.Атака на Internet 2-е изд., перераб. и доп. –М.: ДМК, 1999. ↑
Олифер В.Г., Олифер Н.А. «Основы сетей передачи данных» М.: ИНТУИТ.ру, 2005. – 123 с ↑
Олифер В.Г., Олифер Н.А. «Основы сетей передачи данных» М.: ИНТУИТ.ру, 2005. – 127 с. ↑