Мегаобучалка Главная | О нас | Обратная связь


Прикладной уровень (общий прикладной сервис).



2018-06-29 636 Обсуждений (0)
Прикладной уровень (общий прикладной сервис). 0.00 из 5.00 0 оценок




 

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

На прикладном уровне осуществляется окончательное и естественное погружение механизмов взаимосвязи, объявленных в модели, в вычислительную среду с ее понятийным построением. Очевидна поэтому потребность в уточненном описании понятия прикладного процесса (application process, AP). Прикладной процесс - это идентифицируемый объект в рамках реальной открытой системы, ведущий обработку информации и ответственный за согласование правил среды своего существования с законами модели ВОС. Прикладной процесс представляется в рамках модели ВОС одним или более прикладными объектами (Application Entity, AE).

Прикладной объект, далее, представляется совокупностью элементов прикладных служб (Application Service Elements, ASE). Такая совокупность, в свою очередь, может быть разделена на набор общих элементов прикладных служб (ОЭПС, ACSE), некоторый набор специальных элементов прикладных служб (СЭПС, SASE), а также элемент, создаваемый разработчиком прикладной системы - элемент пользователя (ЭП, UE), рис.2.5.1.

 

 

 

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

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

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

Каждый элемент прикладной службы требует описания предоставляемых им услуг и поддерживающего их выполнения протокола.

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

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

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

Прикладное взаимодействие базируется на представительном соединении, которое создается и завершается поставщиком общего прикладного сервиса. Поэтому у пользователя сервиса нет необходимости устанавливать представительное соединение прямым выходом на представительный уровень с помощью примитива P-CONNECT. Доступ к ЭСУА, обеспечивающему услугу образования ассоциации, может быть осуществлен опосредованно - вызовом специального элемента прикладной службы (СЭПС) или элемента пользователя, что иллюстрируется структурой связей элементов на рис.2.5.1.

Услуги, предоставляемые ЭСУА. Для управления одной ассоциацией используются следующие услуги: A-ASSOCIATE (Пк-АССОЦИИРОВАНИЕ), A-RELEASE (Пк-ОСВОБОЖДЕНИЕ), A-ABORT (Пк-ПРЕКРАЩЕНИЕ (Пк-РАЗРЫВ)), A-P-ABORT (Пк-Пс-ПРЕКРАЩЕНИЕ (Пк-Пс-РАЗРЫВ)).

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

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

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

В параметрическом отношении общая функциональная ориентация всех трех верхних уровней ЭМВОС (на приложения) проявляется в том, что многие параметры, связанные с примитивами, отображаются непосредственно с одного уровня на другой. На рис.2.5.2 приведена схема, в соответствии с которой осуществляется параметрическая комплектация сеансовой услуги S-CONNECT и представительной услуги P-CONNECT на основе прикладной услуги A-ASSOCIATE.

 

 

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

Протокол управления ассоциацией обеспечивает услуги ЭСУА, опираясь на службу представительного уровня. Использование этой службы может быть двоякое. В случае, если доступна только ее функциональная группа ядра (базовый функциональный блок), то ЭСУА-БДП не используются, а примитивы ЭСУА и представительной службы отображаются друг в друга непосредственно. Если же протокол функционирует в т.н. нормальном режиме, то функциональная группа ядра представительной службы используется для обмена ЭСУА-БДП между равноправными протокольными объектами. Использование дополнительных функциональных групп представительной службы согласовывается между пользователями ЭСУА. Все ЭСУА-БДП (их пять типов) специфицированы с использованием ASN.1.

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

Опишем далее по необходимости кратко еще один общий элемент прикладной службы - управления завершением (присвоением, фиксацией, commitment), параллельностью (соревнованием, concurrency) и восстановлением (recovery) - УЗПВ (CCR).

За рамками рассмотрения пока останутся общие элементы прикладных служб надежной передачи и удаленных операций.

В основе УЗПВ лежит понятие атомарного (неделимого) действия (АД). АД - последовательность операций, выполняемых распределенным приложением, которая обладает следующими свойствами:

- АД прямо или косвенно управляется единственным прикладным объектом;

- на выполнение АД не влияют внешние воздействия;

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

Завершение АД переводит данные, над которыми оно производится, в конечное состояние и завершает взаимосвязь между прикладными объектами по поддержанию службы УЗПВ (прекращает ЗПВ-отношения между ними). Откат (возврат) АД возвращает данные в исходное (начальное) состояние и прекращает ЗПВ-отношение между прикладными объектами.

Управление параллельностью гарантирует, что АД не завершится до тех пор, пока:

- не завершатся все АД, которые обрабатывали те же данные до их периода использования рассматриваемым АД;

- никаких изменений значений данных в течение их периода использования не произойдет, за исключением тех, которые планируются данным АД.

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

Управление восстановлением гарантирует правильное выполнение АД даже при наличии отказов прикладных объектов и среды передачи.

Установление ЗПВ-отношения подразумевает разделение его участников на ведущего (старшего) (прикладной объект, инициировавший ЗПВ-отношение) и ведомого (младшего) (прикладной объект, принявший ЗПВ-отношение). АД, вовлекая в свой ход множество прикладных объектов, образует дерево атомарного действия, ветвями которого являются ЗПВ-отношения, развивающиеся на существующих двунаправленных ассоциациях. Таким образом, АД охватывает множество ведущих и ведомых, причем среди ведущих существует источник АД - корень АД. В ходе развития АД один и тот же прикладной объект может иметь несколько вхождений в дерево АД, причем в различных качествах, рис.2.5.5.

 

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

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

 

 

Эта схема обеспечения свойства атомарности действует при соблюдении следующих условий:

- в фазе завершения АД не должно существовать возможностей изменения ее результатов;

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

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

- если ведомый сообщил о своей готовности завершить действие, то он не может отказаться от требования выполнить завершение;

- ведомый может отказаться от завершения в любое время вплоть до момента выдачи своего согласия на него;

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

Корень несет ответственность за завершение или возврат. Имя корня используется для идентификации АД в целях управления параллельностью.

Содержательная сторона АД определяется прикладными процессами и ЭПС, которые манипулируют вовлеченными в действие данными в рамках АД от момента начала действия и до момента завершения, рис.2.5.6. УЗПВ лишь обеспечивает средства для индикации АД и управления им. Вовлеченные в АД прикладные процессы сами, локально, решают вопрос о том, какие шаги следует предпринять, чтобы обеспечить неукоснительное выполнение правил атомарного действия, как об этом говорилось ранее на примере механизма управления параллельностью.

Перед инициацией АД ведущий прикладной объект с помощью ЭСУА устанавливает ассоциацию с каждым из ведомых. После этого с помощью услуги УЗПВ C-BEGIN ведущий устанавливает с каждым из ведомых ЗПВ-отношение. Дерево АД всякий раз при этом приобретает еще одну ветвь. Отказ партнера образовать ЗПВ-отношение выполняется с помощью услуги C-REFUSE. Действие C-BEGIN связано с установлением главной точки синхронизации в рамках используемой ассоциации.

Вслед за услугой C-BEGIN прикладной пользователь может обращаться к другим прикладным услугам, что, собственно, и определяет сущность (содержательную сторону) вводимого АД.

Помимо указанных двух, в состав услуг УЗПВ входят услуги C-PREPARE, C-READY, C-COMMIT, C-ROLLBACK, C-RESTART. Примитивы трех последних услуг используются в разных ситуациях при завершении ЗПВ-отношения. В целом сервисные ЗПВ-последовательности развиваются в рамках ассоциаций, образованных приложениями. В каждый момент на ассоциации может существовать лишь одна сервисная ЗПВ-последовательность.

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

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

Протокол УЗПВ применяется в тех случаях, когда другие прикладные протоколы вызывают его процедуры, используя примитивы службы УЗПВ. Он специфицирует УЗПВ-БДП в терминах ASN.1, а также указывает, каким образом эти БДП отображаются в представительные БДС. Количество типов УЗПВ-БДП - десять основных и шесть вспомогательных. Особенность протокола УЗПВ заключается в том, что его процедуры используют представительный сервис для обеспечения своих функций наряду со специальными прикладными протоколами. Отсюда исходит требование к тем приложениям, которые пользуются ЗПВ-сервисом. Представительные контексты таких приложений должны содержать абстрактный синтаксис, описывающий УЗПВ-БДП. Включение такого представительного контекста осуществляется в момент образования приложением соответствующей ассоциации или непосредственно перед началом АД путем инициации представительной услуги P-ALTER-CONTEXT.

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


 



2018-06-29 636 Обсуждений (0)
Прикладной уровень (общий прикладной сервис). 0.00 из 5.00 0 оценок









Обсуждение в статье: Прикладной уровень (общий прикладной сервис).

Обсуждений еще не было, будьте первым... ↓↓↓

Отправить сообщение

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



©2015-2024 megaobuchalka.ru Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. (636)

Почему 1285321 студент выбрали МегаОбучалку...

Система поиска информации

Мобильная версия сайта

Удобная навигация

Нет шокирующей рекламы



(0.007 сек.)