Файл: Понятие прикладных протоколов и серверы приложений.pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 06.04.2023

Просмотров: 92

Скачиваний: 1

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Введение

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

Сервер приложений — это инфраструктурное программное обеспечение, предназначенное для создания распределенных информационных систем с выделенными службами бизнес-логики, реализованными в виде компонентов, выполняющихся под его управлением. Эти компоненты могут представлять собой COM- или CORBA-объекты либо компоненты Enterprise JavaBeans. Современные серверы приложений позволяют реализовать надежные и устойчивые к сбоям информационные системы за счет поддержки создания кластеров и наличия средств восстановления после сбоев. В настоящее время серверы приложений являются основой многих корпоративных решений с повышенными требованиями к надежности.

Сервер приложений обладает следующими возможностями:

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

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

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

- использование собственного интерпретатора (оболочки) в качестве клиентского процесса по умолчанию. Язык интерпретатора является языком 3-го поколения, основанным на INFORMIX-SPL, с возможностью исполнения любых SQL-операторов. Язык имеет расширенные возможности по использованию пользовательских библиотек. Подробнее см. главу "Язык хранимых процедур".


Глава 1. Протоколы прикладного уровня

1.1 Общие понятия. Протокол. Стек протоколов

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

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

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

Интерфейс определяет совокупный сервис, предоставляемый данным уровнем выше лежащему уровню.

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


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

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

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

Программные средства, реализующие некоторый протокол, также называют протоколом. При этом соотношение между протоколом - формально определенной процедурой взаимодействия, и протоколом - средством, реализующим эту процедуру, аналогично соотношению между алгоритмом решения некоторой задачи и программой, решающей эту задачу. Понятно, что один и тот же алгоритм может быть запрограммирован с разной степенью эффективности. Точно также и протокол может иметь несколько программных реализаций, например, протокол IPX, реализованный компанией Microsoft для Windows NT в виде программного продукта NWLink, имеет характеристики, отличающиеся от реализации этого же протокола компанией Novell. Именно поэтому, при сравнении протоколов следует учитывать не только логику их работы, но и качество программных решений. Более того, на эффективность взаимодействия устройств в сети влияет качество всей совокупности протоколов, составляющих стек, то есть, насколько рационально распределены функции между протоколами разных уровней и насколько хорошо определены интерфейсы между ними.

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


При организации взаимодействия могут быть использованы два основных типа протоколов. В протоколах с установлением соединения (connection-oriented network service, CONS) перед обменом данными отправитель и получатель должны сначала установить логическое соединение, то есть договориться о параметрах процедуры обмена, которые будут действовать только в рамках данного соединения. После завершения диалога они должны разорвать это соединение. Когда устанавливается новое соединение, переговорная процедура выполняется заново. Телефон - это пример взаимодействия, основанного на установлении соединения.

Вторая группа протоколов - протоколы без предварительного установления соединения (connectionless network service, CLNS). Такие протоколы называются также дейтаграммными протоколами. Отправитель просто передает сообщение, когда оно готово. Опускание письма в почтовый ящик - это пример связи без установления соединения.

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

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





Рис.1 Взаимодействие прикладных процессов.

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

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

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

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

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

- согласование и установления прикладного контекста взаимосвязи, 

- обмен прикладными блоками данных, 

- управление режимами взаимосвязи, 

- прекращение взаимосвязи ... 

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




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

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


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

Рис.2 Взаимодействие прикладных процессов.

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

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

- общие;

- специальные. 

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

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

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

Сервисный элемент управления ассоциацией (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]. 
Для иллюстрации организации работы прикладного уровня рассмотрим простой пример, в котором для программы (program) пользователя (user) реализуется возможность доступа к сервису простой электронной почты, т.е. через свою программу пользователь может готовить и пересылать сообщения другому удаленному пользователю, используя специальный прикладной сервисный элемент системы обработки сообщений MHS (Message Handling System). 
    Организация вычислительного процесса для данного приложения показана на рис. 3. 
    Прикладной процесс (Application Process) программы пользователя в данном примере состоит из прикладной сущности (Application Entity), ответственной за реализацию функций взаимосвязи с другими пользователями, и из компоненты, реализующей взаимосвязь прикладного сервисного элемента с локальными ресурсами реальной открытой системы и называемой часто прикладным агентом (Application Agent). 

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



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