LINEBURG


<< Пред. стр.

страница 4
(всего 11)

ОГЛАВЛЕНИЕ

След. стр. >>

• X/Open Transaction Processing Group (XTP). В него входят: нормативная модель обра-
ботки транзакций (X/Open DTP), ТХ — спецификация API между прикладными программами и
менеджером транзакций, ХА — спецификация интерфейса между менеджером транзакций и
менеджерами ресурсов (предоставляет менеджеру транзакций возможность структуризации ра-
боты менеджеров ресурсов внутри транзакции).
• Сервисы печати предназначены для упрощения печати данных на различных типах
носителей и просмотра их пользователем перед печатью. Эта группа включают следующие сер-
висы:
• способность описывать требуемые выходные данные и параметры печати;
• поддержка очередей и множества устройств печати;
• способность специфицировать характеристики задания на печать;
• управление заданиями;
• управление очередями;
• управление шрифтами;
• контроль доступа к устройствам печати;
• поддержка учётной информации и пр.
API для сервисов печати должен включать поддержку указанных сервисов для приложе-
ний и ряда специальных сервисов для администрирования подсистемы печати: конфигурирова-
ние подсистемы, управление доступом к учётной информации и пр.
Среди стандартов по сервисам печати следует выделить ISO 10175 — Document Printing
Application (DPA) и ISO 10180 — Standard Page Description Language (SDPL), основанный на
языке PostScript, а также IEEE PI 003.7 — администрирование печати.
• Сервисы обмена данными поддерживают способность перемещать данные между сис-
темами через внешнюю среду путём записи их на распознаваемый обеими системами носитель
в формате, дающем возможность обеим системам одинаково интерпретировать данные. Разли-
чают два аспекта рассматриваемой проблемы: преобразование кодировки символов из одного
машинного представления в другое и распознавание полученной информации приложениями.
Наиболее значительными являются следующие стандарты по форматам обмена данными:
• ISO 9735 — EDIFACT (Electronic Data Interchange for Administration, Commerce and
Transportation) — набор стандартов, определяющих формат и структуру документов, исполь-
зуемых в делопроизводстве и электронном документообороте.
• ISO 8613 — ODA/ODIF (Open Document Architecture / Open Document Interchange For-
mat) — набор стандартов по структуризации и прозрачному для пользователей обмену слож-
ными составными документами, включающими несколько типов информации: текст, рисунки,
геометрическую графику.
• ISO 8879 — SGML (Standard Generalized Markup Language) — язык представления
структуры, содержания и формата документа.
3. Сервисы человекомашинного взаимодействия — важная группа сервисов, обеспечи-
вающих возможность общения человека с компьютером и форму организации работы пользо-
вателя.
• Сервисы командного интерфейса могут принимать различные формы:
от простой интерпретации введённых пользователем команд до развитого командного
языка, который могут использовать прикладные программы. Эти сервисы требуют обеспечить
API для приложений и интерфейс для внешней среды. По этой причине открытый командный
интерфейс должен предоставлять по крайней мере следующие возможности:
• команды для манипулирования файлами, их содержимым и доступа к ним;
• команды для манипулирования директориями и доступа к ним;
• диспетчеризация команд;
• пакетный режим обработки команд;
• доступ к информации о среде пользователя;
• примитивы языков программирования для написания простых программ на командном
языке.
Основной стандарт в этой области — ISO/IEC 9945-2 (основан на IEEE Р1003.2).
• Сервисы текстового пользовательского интерфейса предоставляют простые средст-
ва общения пользователя с вычислительной системой при помощи ввода и отображения тексто-
вых данных. Исторически это первая форма организации пользовательского интерфейса. Сей-
час она в значительной степени вытеснена графическими интерфейсами.
• Сервисы графического пользовательского интерфейса (GUI — Graphical User Inter-
face) обеспечивают для приложений возможность создавать и манипулировать визуальными
объектами на экранах компьютеров. Пользователи должны иметь единый, легко понятный им
стиль общения с вычислительной системой через такой интерфейс. На сегодняшний день GUI
является общепринятой формой организации пользовательского интерфейса. АР должна иметь
два интерфейса с сервисами GUI:
• API сервиса визуальных объектов (часто также называется "оконный интерфейс") по-
зволяет приложениям использовать сервисы GUI;
• EEI обеспечивает форматы и протоколы обмена данными между сервисами GUI мно-
жества систем и формирование единообразной рабочей среды для пользователей различных
систем.
Среди стандартов на открытые сервисы GUI важное значение имеют протоколы XWin-
dows — это стандарты де-факто, специфицированные и реализованные консорциумом Х/Ореn.
Интерфейсы, основанные на этом стандарте, преобладают среди UNIX-подобных платформ. На
персональных системах стандартами де-факто являются API операционных систем Microsoft
Windows и MacOS.
• Сервисы графики поддерживают работу приложений с графическими объектами —
растровую и векторную графику. Они имеют большое значение для многих типов приложений
и очень развитый набор функций. API сервисов графики должен обеспечивать интерфейс для
доступа приложений к этим сервисам. EEI должен поддерживать форматы и протоколы, необ-
ходимые для управления устройствами, отображения графической информации на удалённых
устройствах и обмена графическими данными между системами.
Ситуация со стандартизацией сервисов графики характеризуется наличием очень боль-
шого количества стандартов, важное место среди которых занимают стандарты ISO.
• Сервисы разработки приложений — это сервисы, которые связаны с обеспечением
жизненного цикла прикладного ПО, и, в особенности, этапа его разработки. Переносимость по-
нимается здесь в двух аспектах. Первый — создание переносимого прикладного ПО. Второй —
обеспечение переносимости в самом процессе создания ПО, когда, например, различные моду-
ли могут создаваться на различных платформах, а компиляция, отладка, тестирование, доку-
ментирование — на других платформах.
Весьма перспективным направлением развития сервисов разработки приложений явля-
ется создание систем автоматизации проектирования программного обеспечения — CASE
(Computer Aided Software Engineering). Соответствующие стандарты в основном находятся в
стадии разработки; среди уже существующих можно отметить стандарты POSIX.
4. Межкатегориальные сервисы. Рассмотренные сервисы АР допускают довольно чёт-
кую, хотя и не единственно возможную, классификацию. Следующая группа сервисов — так
называемые межкатегориальные сервисы. Они принципиально отличается от указанных выше:
• Межкатегориальные сервисы имеют определённое влияние на все остальные сервисы,
которые предоставляются АР. Каждый сервисный компонент должен быть сконструирован с
учётом этих межкатегориальных сервисов.
• Все остальные сервисы предоставляют свои компоненты для того, чтобы межкатегори-
альные сервисы могли эффективно выполнять свои функции.
• Сервисы поддержки национальных особенностей. Данные сервисы подразумевают
учёт особенностей национальных языков, форматов представления числовых величин, дат,
времени и т.п. в различных странах. Они не имеют значительного влияния на структурную ор-
ганизацию системы, поэтому в некоторых моделях они опущены.
Две других категории сервисов, напротив, очень важны для функционирования системы;
с ними связано большое число стандартов.
• Сервисы защиты. Их целью является защита техническими средствами информации,
обрабатываемой в распределённой системе. Сервисы защиты должны быть предусмотрены с
самого начала жизненного цикла системы.. Они должны быть взаимоувязаны со всеми функ-
циями и сервисами, которые предоставляет АР. В силу большого различия в целях, функциях,
размере, сложности, а также разнородности программного и аппаратного обеспечения систем
обработки данных невозможно выработать единого критерия, когда систему следует считать
безопасной.
Каждая система требует формулировки политики безопасности (security policy) для то-
го, чтобы определить, какой уровень защищённости и какие правила разграничения доступа
требуются для информации, обрабатываемой в этой системе. Для осуществления на практике
этой политики могут быть применены механизмы, которые гарантируют желаемый уровень
безопасности. Совокупность всех аппаратных и программных компонентов, с помощью кото-
рых в системе "проводится в жизнь" установленная политика безопасности, носит название
комплекса средств защиты (согласно определению Гостехкомиссии; в оригинале - ТСВ —
trusted computer base). Кроме того, должны существовать некоторые способы оценивания того,
насколько хорошо эти механизмы реализуют заданную политику безопасности. Мы будем рас-
сматривать только те механизмы, которые могут быть реализованы, измерены и оценены с точ-
ки зрения АР, исключая физические, организационные, юридические и пр. средства защиты.
Для обеспечения механизмов, реализующих политику безопасности и оценку их эффек-
тивности, в системе требуется наличие нескольких сервисов:
• сервисы аутентификации;
• механизмы контроля доступа;
• сервисы верификации (т.е. проверки целостности и полноты ресурсов системы);
• сервисы шифрования;
• сервисы аудита;
• средства установления доверия к каналам передачи и узлам обработки данных.
Наиболее важными стандартами, относящимися к сервису защиты в контексте проблемы
обеспечения переносимости, т.е. не затрагивая взаимосвязь систем, являются:
• Стандарт IEEE P1003.6 — специфицирует функциональные требования и стандарты
интерфейса системы для механизмов защиты, аудита и контроля состояния системы. Он вклю-
чает следующие интерфейсы:
• интерфейсы аудита;
• интерфейсы привилегий доступа к объектам;
• интерфейсы дискретционного контроля доступа;
• интерфейсы мандатного контроля доступа.
• ISO/IEC 15408 — Information technology — Security techniques -Evaluation criteria for IT
security (Критерии оценки защищённости продуктов и систем информационных технологий).
Стандарт описывает модель процесса проведения оценки защищённости продуктов и систем,
даёт классификацию функциональных требований к механизмам защиты, специфицирует кри-
терии, по которым производится соотнесение функций защиты, реализованных в системе, тому
или иному уровню гарантий защищённости. Стандарт состоит из трёх частей:
часть 1: Введение и общая модель;
часть 2: Функциональные требования по защите;
часть 3: Требования гарантий защищённости.
• Сервисы административного управления системой. При стандартизации сервисов
административного управления (management) открытыми системами в основном исходят из
предположения о том, что управление производится в распределённой среде. Поэтому, рас-
сматривая свойство переносимости, можно только перечислить требования, которым должна
удовлетворять одна, отдельно взятая вычислительная система:
• управляемость конфигурации процессоров;
• инсталляция и управление программным обеспечением;
• корректный запуск и останов системы;
• лицензирование программного обеспечения;
• управляемость и конфигурирование вычислительной сети;
• управление организацией хранения данных на дисках;
• диспетчеризация заданий;
• администрирование пользователей;
• учётность пользователей и ресурсов;
• управление защитой;
• управление производительностью системы;
• управление ёмкостью носителей данных;
• сервисы резервного копирования и восстановления;
• управление нештатными ситуациями;
• управление системой печати и пр.
Этот перечень показывает, что при создании сервисов управления системой требуется
учитывать, что они должны взаимодействовать практически со всеми остальными сервисами,
ресурсами и объектами АР.

2.3. Способность к взаимодействию
Конечная цель взаимодействия систем — обеспечение прозрачного доступа к любым ре-
сурсам, несмотря на возможную неоднородность распределённой среды. Способность к взаи-
модействию необходима для поддержки широкого спектра функций систем и прикладных про-
грамм: от сравнительно простых до полнофункциональных сред, объединяющих информаци-
онные системы крупных предприятий. Примерами могут служить следующие функции:
• электронная почта;
• передача файлов из одной системы в другую;
• доступ к приложениям на удалённой системе;
• разделение файлов между несколькими системами;
• разделяемые базы данных;
• сложные приложения, использующие ресурсы на различных системах, целостность ко-
торых гарантируется системой управления распределёнными транзакциями.
Какая бы из этих или иных функций ни использовалась в системе, способность к взаи-
модействию обеспечивает более эффективное использование и уменьшает дублирование ресур-
сов, предоставляет новые пути разработки и распространения прикладного ПО в системе.
Переносимость и способность к взаимодействию скрывают от пользователя различия
между системами и стандартизируют способ их восприятия пользователями, приложениями
или другими системами. Важно отметить, однако, что по существу цель сокрытия различий со-
стоит не в полной их ликвидации или выравнивании, а наоборот, в использовании уникальных
возможностей и характеристик каждой индивидуальной системы. Пользователю только пред-
ставляется образ единой системы.
Способность к взаимодействию обеспечивает несколько дополнительных преимуществ
по сравнению с переносимостью:
• Она позволяет объединять существующие системы с новыми, сохраняя преемст-
венность и инвестиции, уже вложенные в информационную систему.
• Она позволяет разрабатывать распределённые приложения. Это означает, что ка-
ждая из функций приложения может быть выполнена именно на той платформе,
которая наилучшим образом подходит для этого.
• За счёт прозрачного разделения ресурсов среды она создаёт такие условия для
пользователя, что все ресурсы системы кажутся ему доступными локально.
Как уже отмечалось ранее, способность к взаимодействия достигается посредством:
• соединения системы коммуникационными средствами, которые позволяют осу-
ществлять передачу данных между системами;
• введения в систему набора дополнительных сервисов, которые используют ком-
муникационный сервис вычислительной сети.
Действительно, когда системы имеют средства связи между собой: коммуникационные
средства внешней среды, сетевые сервисы платформы приложений — они таким образом обес-
печены средствами обмена сообщениями. Сетевые сервисы не являются специфичными для ка-
кого-либо приложения или типа приложений, работающих в системе. Это общецелевые серви-
сы, такие как адресация, маршрутизация сообщений, обеспечение надёжной их доставки и пр.
Кроме того, для удовлетворения требований различных приложений необходим набор допол-
нительных сервисов. Но для того, чтобы выполнять функции, которые ожидают от приложений
конечные пользователи, приложения должны "уметь" идентифицировать и распознавать среди
всех передаваемых сообщений информацию, относящуюся к тому или иному приложению. К
примеру, при передаче файла сообщения должны содержать имя файла, его атрибуты и данные,
содержащиеся в файле. При выполнении распределённой транзакции менеджеры транзакции
будут обмениваться управляющей информацией о начале и конце транзакции, а также об опе-
рациях, произведённых над данными каждым из них. Очевидно, для того, чтобы системы могли
взаимодействовать на уровне приложений, необходима стандартизация таких сообщений, т.е.
описание форматов и протоколов, которые определяют синтаксис сообщений и правила осуще-
ствления обмена.
Таким образом приходим к необходимости описания "комплекта", набора протоколов
различных уровней (как видно из предыдущих рассуждений — по крайней мере двух).
Под протоколом принято понимать точно определённую последовательность действий, с помощью кото-
рой два или более логических объектов одного уровня совместно решают некоторую общую задачу. Иными сло-
вами, протоколы определяют логику взаимодействия удалённых логических объектов одного уровня.
Подобные многоуровневые наборы протоколов часто называют "стеками протоколов".
Основной принцип описания таких протоколов — информация, имеющая значение для прото-
кола определённого уровня, переносится протоколом нижележащего уровня безотносительно к
содержанию этой информации.
Вернёмся к модели информационной системы, введённой в п. 2.1. При рассмотрении пе-
реносимости обсуждались два типа интерфейсов АР: API и EEI с пользователями и внешними
объектами данных. С точки зрения способности систем к взаимодействию имеет значение дру-
гой компонент — EEI между АР и коммуникационными средствами внешней среды. Коммуни-
кационные средства позволяют одной данной системе рассматривать все другие системы как
часть внешней среды (рис. 6).
Чтобы добиться способности к взаимодействию, необходимо стандартизировать форма-
ты и протоколы обмена сообщениями через EEI, используя коммуникационные средства внеш-
ней среды. Часть EEI, которая управляет такими сообщениями, носит название коммуникацион-
ного интерфейса. Он включает в себя сетевые протоколы и высокоуровневые прикладные про-
токолы, необходимые для поддержки распределённых сервисов. Коммуникационный интер-
фейс — это единственный интерфейс, где две (вероятно, различные) системы непосредственно
контактируют друг с другом. Он позволяет платформам приложений осуществлять взаимный
доступ к ресурсам и предоставлять сервис друг другу, используя сетевые и соответствующие
прикладные протоколы. Способность к взаимодействию обращается к таким функциональным
возможностям, которые не затрагивает переносимость. Так, она организует доступ к тем серви-
сам АР, к которым пользователь или приложение не имеют прямого доступа через API. При
этом не имеет значения, как именно реализуется внутри той или иной системы конкретный вид
сервиса. Он вполне может использовать внутренние особенности и преимущества организации
системы.




Рис. 6. Базовая модель взаимодействующих систем

Заметим, что для достижения способности к взаимодействию нет необходимости стан-
дартизировать API — только соответствующие форматы и протоколы. Также для этого не нуж-
ны стандарты на те сервисы, которые являются внутренними для АР, и те части EEI, которые
взаимодействуют с внешними объектами данных и пользователями. Однако из этого правила
есть исключение: стандартизация API сетевых сервисов способствует обеспечению взаимодей-
ствия на более высоком уровне. Тогда появляется возможность ввести в состав платформы
приложения, работающие с сетевыми сервисами, а их услугами уже могут пользоваться осталь-
ные приложения.
Установив необходимость многоуровневой организации взаимодействия открытых сис-
тем, рассмотрим более подробно основные преимущества такого подхода:
• Многоуровневая организация есть частный случай модульности — это позволяет
легче понимать структуру системы.
• Протоколы различных уровней в стеке и виды передаваемой ими информации в
основе своей независимы друг от друга. Несмотря на то, что каждый уровень вы-
полняет свою работу по указанию вышестоящего уровня, способ выполнения за-
проса не имеет значения для сделавшего запрос.
• Уровневые сервисы всегда включают некоторый сервис по транспортировке дан-
ных, который предоставляется верхним уровням. Это означает, что, хотя каждому
объекту некоторого уровня кажется, что он взаимодействует с объектом того же
уровня, на самом деле перемещение данных по всем уровням, кроме самого ниж-
него, происходит "вертикально". И только нижний уровень действительно пере-
мещает данные "горизонтально".
Отметим теперь основные принципы многоуровневого взаимодействия:
• Взаимодействие по принципу сервисов и протоколов. Каждый уровень взаимодействия
предоставляет сервисы уровню, расположенному над ним, и сам, в свою очередь, пользуется
сервисами уровня, расположенного под ним. Сервис определённого уровня доставляется по-
средством протокола этого уровня. Уровень, запросивший сервис, не видит протокол нижнего
уровня. Таким образом, протоколы образуют каскад сервисов, предоставляемых с верхнего
уровня до нижнего.
• Мультиплексирование. Множество объектов верхнего уровня могут параллельно ис-
пользовать сервис нижнего уровня. Множество сервисов различного качества и различной
функциональности могут предоставляться на каждом уровне по соглашению между партнёра-
ми.
• Свобода выбора протокола. Каждый уровень может выбирать свой собственный про-
токол независимо от других уровней. Кроме того, чёткое разделение функций между уровнями
допускает дальнейшую декомпозицию уровня на подуровни, вставку протоколов "поверх" и
"внизу" уровня,
• Качество сервиса. Каждый отдельный уровень может предлагать альтернативные воз-
можности реализации сервиса, гарантированно определяющие некоторые его свойства или па-
раметры, например, скорость, надёжность соединения.
• Адресация. Любая форма коммуникации требует какой-либо подходящей формы адре-
сации. На каждом уровне формат адресации является частью соответствующего протокола.
• Виды соединений. Различают два вида организации взаимодействия в протоколах: с ус-
тановлением соединения и без установления соединения. В первом случае для передачи серии
сообщений устанавливается выделенное соединение, которое обеспечивает подтверждение дос-
тавки, обнаружение ошибок, повторную передачу и восстановление порядка следования сооб-
щений. Примером связи с установлением соединения являются услуги телефонной сети. Во
втором случае каждое сообщение передаётся независимо от остальных, содержит полную ин-
формацию об адресах отправителя и получателя и в принципе может передаваться по различ-
ным маршрутам. В общем случае такая форма передачи сообщений является ненадёжной, но
быстрой. Она может приводить к потере, возникновению ошибок в сообщениях, изменению
порядка их следования или повторным передачам. Это, однако, может быть выявлено и исправ-
лено средствами верхних уровней. Пример такой связи — почтовая служба.
• Ограниченность связей. Объекты взаимодействуют между собой на одном уровне "го-
ризонтально" по протоколам, потоки данных движутся "вертикально" (за исключением самого
нижнего уровня). Каждый уровень добавляет управляющую информацию, специфичную для
протокола этого уровня. На самом нижнем уровне, таким образом, передаётся сложный конг-
ломерат данных. Каждый уровень при такой форме связи "видит" только смежные с ним уров-
ни.
Классическим примером многоуровневой модели взаимодействия вычислительных сис-
тем является семиуровневая модель взаимосвязи открытых систем, описанная в стандарте
ISO/IEC 7498 — Information technology — Open Systems Interconnection — Basic Reference
Model, известная как модель OSI (см. п. 3.2.1).
Кроме указанной, существует ещё большое количество многоуровневых моделей взаи-
модействия вычислительных систем и соответствующих им стеков протоколов: DNA (Digital
Network Architecture), AppleTalk, SNA (System Network Architecture), TCP/IP и др. Вследствие
несовместимостей между различными моделями добиться способности к взаимодействию на
практике — существенно более сложная задача, чем это может показаться теоретически. Для
этого требуется организовать "мосты" между различными моделями (стеками протоколов) и
сделать их существование прозрачным для пользователей и приложений. Более того, историче-
ски не существовало единого и чёткого разделения протоколов на указанные уровни. Поэтому
различные стеки протоколов не обязательно согласуются между собой по разбиению на уровни,
выполняемым на этих уровнях функциям и даже по числу уровней. Всё это порождает опреде-
лённую зависимость протоколов верхних уровней от нижних для каждого конкретного стека
протоколов.
Вторым необходимым условием взаимодействия систем, как уже отмечалось, является
введение в систему набора распределённых сервисов приложений, которые используют сетевые
сервисы АР и расширяют таким образом свои собственные сервисы. Распределённые сервисы
удобно рассматривать, придерживаясь той же классификации, что и сервисы локальной плат-
формы:
• распределённые сервисы платформы;
• распределённые сервисы данных;
• распределённые сервисы человекомашинного взаимодействия.
В качестве примеров сервисов из соответствующих групп можно привести:
• вызов удалённых процедур;
• передача файлов;
• удалённый вход в систему.
Дополнительно рассматриваются межкатегориальные сервисы. Такое представление со-
гласуется с концепцией единой, распределённой системы, где все аспекты взаимодействия ме-
жду отдельными системами регулируются внутри АР.
Часто протоколы, соответствующие в стеке коммуникационных протоколов сетевым
сервисам и распределённым сервисам приложений, называют соответственно транспортными
провайдерами (transport provider) и транспортными пользователями (transport user). Первые
обеспечивают базовые, не зависящие от приложений, функции по доставке сообщений через
сеть. Вторые строятся на сетевых сервисах и расширяют сервисы АР в распределённых систе-
мах. В коммуникационных моделях они примерно соответствуют или отождествляются с сами-
ми приложениями.
Сейчас понятие распределённой вычислительной среды часто ассоциируется с моделью
вычислений «клиент - сервер». Эта модель означает совместную обработку запросов, подавае-
мых клиентом (как правило, программой), т.е. просителем услуг, серверу (как правило, тоже
программе), т.е. поставщику услуг, который обрабатывает запросы и возвращает результаты
клиенту.
Известно несколько других моделей организации вычислений, получавших развитие на
различных этапах эволюции распределённых вычислений: централизованная, хост-модель
(host-based), модель "ведущий - ведомый" (master - slave), модель разделения устройств (shared
device processing), одноранговая модель (peer-to-peer). Но наибольшее распространение получи-
ла именно клиент-серверная модель: она является самой оптимальной в условиях неоднородной
распределённой вычислительной среды с дисбалансом вычислительных мощностей.
Однако, клиент-серверная обработка предъявляет и определённые архитектурные требо-
вания: наличие надёжной связи между клиентами и серверами, разделение логики прикладных
программ между клиентом и сервером, координация взаимодействий между клиентом и серве-
ром, инициируемых клиентом, контроль сервера над сервисами и данными, которые запраши-
ваются клиентами, разрешение сервером конфликтующих запросов клиентов.
Основные преимущества клиент-серверных вычислений включают возможности широ-
кого включения в распределённые вычислительные относительно маломощных вычислитель-
ных систем, снижения сетевого графика (т.к. обработка данных приближается к источнику дан-
ных), использования графического пользовательского интерфейса, поддержки стандартов от-
крытых систем.
Клиент-серверные вычисления в распределённой вычислительной среде прочно связаны
с концепцией "middleware". Этот термин является сокращением и может быть интерпретирован
как "программное обеспечение среднего уровня". Идея дополнения системного ПО этим ком-
понентом возникла из естественного стремления сократить трудоёмкость разработки приклад-
ного ПО для работы в клиент-серверной модели. Middleware - это соединяющий уровень ком-
муникационного ПО между физической сетью передачи данных и приложениями пользователя,
выполняющего функции транспортного пользователя, в общем случае эквивалентное уровням 5
и 6 модели OSI (см. п. 3.2.1). Со стороны приложений это ПО содержит упрощающие програм-
мирование высокоуровневые API, которые "экранируют" разработку прикладного ПО от слож-
ных коммуникационных протоколов на нижних уровнях. Используя инструменты и продукты
middleware, программисты могут сфокусироваться на создании собственно логики приложений,
не разрабатывая при этом сложные коммуникационные протоколы и интерфейсы.
С появлением более сложных моделей открытых распределённых вычислений и посто-
янным расширением состава ПО, который можно отнести к "среднему уровню", концепция
middleware стала "поглощаться" этими моделями.
1. Сетевые сервисы. Функция сетевых сервисов — предоставление общих услуг по
транспортировке между системами сообщений, посылаемых приложениями. Сетевые сервисы
могут быть в свою очередь подразделены на две группы согласно тому, видимы или нет они для
транспортных пользователей.
К сервисам, видимым приложениями напрямую, относятся: установление и разрыв со-
единения с партнёром, управление качеством сервиса для передачи данных, выбор функций со-
общения о состоянии сети. Но даже эти сервисы могут быть скрыты от приложений в некото-

<< Пред. стр.

страница 4
(всего 11)

ОГЛАВЛЕНИЕ

След. стр. >>

Copyright © Design by: Sunlight webdesign