LINEBURG


<< Пред. стр.

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

ОГЛАВЛЕНИЕ

След. стр. >>

рых формах коммуникаций, например, при вызове удалённых процедур — RPC (Remote Proce-
dure Call). Другие сервисы, невидимые для приложений, относятся к нижним уровням стека
протоколов. Они обычно связаны с физическими аспектами сети:
• сообщение об ошибках и восстановление после ошибок;
• сегментация сообщений в пакеты установленного в сети размера и их повторная сбор-
ка;
• директориальные сервисы, которые обеспечивают преобразование символических
имён сетевых ресурсов в адреса;
• многопутевая маршрутизация, которая позволяет сообщениям передаваться различны-
ми маршрутами от точки отправления до точки получения;
• физический доступ к узлам сети;
• управление потоками, включая средства обнаружения состояний переполнения и регу-
лирования интенсивности трафика.
Нижний уровень модели (транспортный провайдер) часто рассматривают как состоящий
из двух подуровней:
• Уровень сети передачи данных — нижний уровень, ответственный за управление гра-
фиком, передающимся от узла к узлу внутри единичной физической сети передачи данных
(subnetwork). Примерами сетей передачи данных являются сети Х.25, локальные сети стандар-
тов IEEE 802-x, Frame Relay, ATM, двухточечные линии связи.
Сети передачи данных можно классифицировать по следующим признакам:
• по используемой технологии передачи данных:
• образование соединений;
• метод разделения канала;
• по территориальной распределённости и связанным с этим особенностям организации:
• локальные (LAN — local area network);
• глобальные (WAN — wide area network);
• городские и сети среднего уровня (MAN — metropolitan area network). Существует
большое количество стандартов по технологиям, связанным с организацией сетей передачи
данных. Однако, они не имеют прямого отношения к достижению основных качеств открытой
среды: переносимости и способности к взаимодействию. Скорее, они служат отправной точкой
для разработки таких стандартов.
• Межсетевой уровень — верхний (из двух) уровень транспортного провайдера, ответст-
венный за формирование единой логической сети (internetwork) из совокупности физических
сетей передачи данных (subnetworks). Этот уровень обеспечивает формирование единого ад-
ресного и маршрутного пространства, которое накладывается на все нижележащие сети переда-
чи данных, но в то же время не зависимо ни от одной определённой сети передачи данных.
Межсетевой уровень позволяет строить единую, прозрачную для пользователя логическую сеть
из множества взаимно соединённых локальных и глобальных сетей.
Конечной целью объединения сетей является обеспечение надёжной и прозрачной дос-
тавки сообщений между любыми системами через множество промежуточных систем, незави-
симо от объединяемых сетей. Другими словами, формируется транспортная система, которая
компенсирует любые различия во входящих в неё сетях, чтобы обеспечить необходимый уро-
вень сервиса для приложений. Иногда такой компенсации не требуется, но транспортная систе-
ма всегда обеспечивает не зависящий от сети передачи данных данных коммуникационный ме-
ханизм между двумя оконечными взаимодействующими системами. С точки зрения приложе-
ний она гарантирует, что сообщения успешно достигнут другой системы.
Модели взаимодействия вычислительных систем и соответствующие им стеки протоко-
лов, такие как OSI, SNA, DNA, не специфицируют API к своим сетевым сервисам. Это и не тре-
буется: способность к взаимодействию уже может быть обеспечена за счёт единства протоко-
лов и форматов данных. Однако, определение и использование стандартных API для сетевых
сервисов содействует упрощению разработки и развёртывания в системе распределённых при-
ложений, так как обеспечивает более высокоуровневое взаимодействие между системами.
Этим, в частности, объясняется широкое распространение протоколов TCP/IP.
Наиболее известными стандартами на API для доступа к транспортным сервисам явля-
ются:
• Интерфейс сокетов (socket interface), берущий начало из версии UNIX
BSD;
• XSOCKET, стандартизованный X/Open;
• TLI (Transport Layer Interface), частично основанный на socket, а частично
на стандарте ISO 8072 по транспортному сервису;
• XTI (X/Open Transport Interface) — базируется на TLI, может поддержи-
вать несколько стеков протоколов: OSI, TCP/IP, NetBIOS, SNA.
Несколько иной подход представляет технология MPTN (Multiprotocol Transport Net-
working), разработанная IBM и принятая X/Open. Она компенсирует неоднородности в функ-
циональности различных транспортных протоколов за счёт введения дополнительного уровня
над транспортным уровнем — CTS (Common Transport Semantics). MPTN позволяет "смеши-
вать" в произвольной комбинации транспортные провайдеры и транспортные пользователи, де-
лая приложения независимыми от используемых сетевых протоколов. Следовательно, прило-
жения могут использовать транспортную систему, отличную от той, которая "ассоциирована" с
высокоуровневыми прикладными протоколами.
2. Сервисы распределённой платформы. Любая прикладная программа включает три
компонента: логику приложения, сервисы данных и сервисы представления информации. Логи-
ка приложения выполняет специфические для конкретного приложения функции и реализуется
с помощью системных сервисов и сервисов языков программирования. Сервисы данных при-
ложения выполняют операции ввода/вывода, требуемые приложением. Сервисы представления
приложения управляют взаимодействием с пользователем. Эти компоненты эквивалентны со-
ответствующим сервисам в рассматриваемой модели. Если приложение становится распреде-
лённым, существует три возможности "расщепления" приложений согласно перечисленным
компонентам:
• Разделение сервиса представления. Распределение приложения заключается в распре-
делении сервиса представления — все остальные компоненты работают на одной локальной
платформе. В этом случае приложение не осведомлено о том, что оно работает в распределён-
ной среде, так как имеет доступ к сервисам представления на своей локальной платформе. Рас-
пределённый характер приложения выражается, например, в процедуре удалённого входа в
систему (remote login) или распределённом графическом интерфейсе пользователя (GUI).
• Разделение сервиса данных. В этом случае приложение также не имеет представления о
том, что данные или ресурсы печати являются удалёнными. Приложение имеет доступ к серви-
сам данных так, как если бы они были локальными для приложения.
• Разделение логики приложения. В этом случае различные функции приложения выпол-
няются на удалённых друг от друга платформах, поэтому для взаимодействия между компонен-
тами приложения требуется та или иная форма коммуникаций. Эта форма распределения наи-
более значима для распределённых систем, так как позволяет достичь наибольших преиму-
ществ (выигрыш в производительности, параллельная обработка, наиболее полная загрузка
процессоров и т.д.).
Все три случая имеют похожие требования, и все так или иначе используют коммуника-
ционные сервисы. Различаются они только в том, что в первых двух случаях коммуникацион-
ные возможности задействуются системой, а в последнем случае их использование является
заботой приложения.
Распределённое приложение в последнем случае, очевидно, сталкивается с необходимо-
стью определённой координации функционирования своих компонентов. Основными требова-
ниями со стороны распределённых приложений являются обеспечение возможности связи ме-
жду компонентами приложения, обеспечение возможности обнаружения компонент в распре-
делённой системе и обеспечение синхронизации работы компонент приложения.
Сервисы распределённой платформы — это расширения внутренних сервисов платфор-
мы, рассмотренных в п. 2.2, перенесённые в распределённую среду. Они предоставляют основ-
ные механизмы распределения приложений, обеспечивают функции по координации распреде-
лённой работы приложений. Часто они также носят название «сервисы распределения». Сооб-
разно основным требованиям приложений в распределённой среде можно выделить три класса
таких сервисов:
• сервисы межпроцессного взаимодействия;
• сервисы именования ресурсов;
• сервисы времени.
• Сервисы межпроцессного взаимодействия. Существует три основные модели органи-
зации взаимодействия между программами:
• Диалоговая (conversational) модель. Приложения общаются друг с другом посредством
посылки вызовов: «установить соединение», «послать сообщение», «принять сообщение»,
«разрушить соединение» и пр. Это форма связи с установлением соединения.
Наиболее известными стандартами, в которых определяются диалоговая модель комму-
никаций, являются ISO 10026 — OSI Distributed Transaction Processing и архитектура АРРС
(Advanced Program-to-Program Communication) фирмы IBM.
• Вызов удалённых процедур (RPC — Remote Procedure Call). Эта модель является рас-
ширением традиционного метода вызова процедур в языках программирования. Вызов удалён-
ной процедуры заключается в однократном обмене сообщениями между вызывающей и вызы-
ваемой процедурами, как при локальном вызове. При этом использование коммуникационных
сервисов происходит невидимо для обеих процедур. RPC может иметь место как с установле-
нием соединения, так и без него. Но с точки зрения приложения он является синхронной фор-
мой коммуникаций, так как оба партнёра должны быть активны в одно и то же время, а вызы-
вающая процедура приостанавливается на время выполнения удалённой. Эта форма коммуни-
каций обычно ассоциируется с моделью вычислений "клиент/сервер".
Основными стандартами по вызову удалённых процедур являются:
- Sun RPC;
- OSF RPC, являющийся основой OSF DCE (Distributed Computing Environment);
- OSI RPC — стандарт ISO 11578.
• Очереди сообщений (message queuing). При этой форме взаимодействия один из про-
цессов помещает свои сообщения в очередь, другой извлекает их оттуда. Это форма коммуни-
каций без установления соединения.
Существует проект международного стандарта по этому виду коммуникаций --ISO/IEC
DIS 10026-7 Information technology - Open Systems Interconnection — Distributed transaction proc-
essing — Part 7: Message queueing.
• Сервисы именования ресурсов. Сервисы именования ресурсов и директориальные сер-
висы являются критичными для распределённой среды, так как размещение и обнаружение ре-
сурсов в ней намного сложнее, чем в локальной системе.
Необходимым условием является присвоение всем объектам, ресурсам и приложениям в
распределённой среде уникальных глобальных имён. Такие имена должны быть аппаратно- и
архитектурно - независимыми. Другими словами, необходима единая логическая схема имено-
вания ресурсов, с помощью которой можно обращаться к любому объекту или ресурсу, сущест-
вующему в системе.
Другое требование состоит в том, что директориальный сервис должен самостоятельно
отображать логические имена на реальные адреса объектов. Для этого необходимо определять
местоположение объекта и предоставить подходящий коммуникационный протокол для досту-
па к нему.
Среди схем именования ресурсов наибольшее значение имеют схема ISO, являющаяся
частью модели OSI, и доменная система имён (DNS — Domain Name System), используемая в
Internet (RFC 1034, RFC 1035). Основным стандартом на директориальный сервис является ре-
комендация Х.500 и её эквивалент ISO 9594. Х/Ореn специфицировала стандарт на API для дос-
тупа к директориальному сервису Х.500 — XDS (X/Open Directory Services). Спецификация
OSF DCE Directory Service обеспечивает механизм для совмещения обоих стандартов: DNS и
Х.500.
• Распределённые сервисы времени. В локальной системе обычно существует единст-
венный системный таймер, услугами которого могут пользоваться все приложения. Однако, в
распределённой среде, состоящей из множества вычислительных систем, различные системы
вследствие многих причин (разница хода часов, задержки передачи в сети и пр.) могут иметь
различные значения текущего времени. Для обеспечения нормальной работы приложений ино-
гда необходима синхронизация показаний таймеров на всех системах, входящих в рас-
пределённую среду. Существуют следующие стандарты де-факто на распределённый сервис
времени: DCE Distributed Time Service и RFC-1119 (Network Time Protocol).
Реализация сервисов распределённой платформы отличается от реализации внутренних
сервисов локальной АР. Если в локальной среде они представляются соответствующими эле-
ментами программного обеспечения: операционной системой, трансляторами, СУБД и пр., то в
распределённой среде соответствующие сервисы реализуются специально назначенными для
выполнения определённых функций аппаратно-программными системами — серверами, напри-
мер, директориальными серверами, серверами времени. Система может выполнять роль сервера
для нескольких сервисов одновременно, а может одновременно служить сервером для одного
сервиса и быть клиентом другого.
3. Распределённые сервисы данных соответствуют разбиению приложений по сервисам
данных. Они являются естественным расширением соответствующих сервисов в локальной
среде.
Выделяют следующие группы сервисов данных:
• сервис обмена данными;
• сервис передачи файлов;
• сервис управления сообщениями (электронная почта);
• распределённый файловый сервис;
• сервис распределённых баз данных;
• распределённый сервис печати;
• сервис распределённой обработки транзакций.
• Сервис обмена данными. Общим условием для реализации всех вышеперечисленных
сервисов является требование представления данных в едином формате — синтаксисе, "понят-
ном" всем приложениям и всем платформам. Это даёт возможность передавать и корректно ин-
терпретировать данные, взятые с одной платформы, на другой платформе. Основными стандар-
тами по синтаксису данных являются ISO/IEC 8824 — Information technology — Open Systems
Interconnection - Specification of Abstract Syntax Notation One (ASN.l) и ISO/IEC 8825 — Informa-
tion technology — Open Systems Interconnection — Specification of Basic Encoding Rules for Ab-
stract Syntax Notation One (ASN.l).
• Сервис передачи файлов. Передача файлов является одним из основных способов раз-
деления данных между взаимодействующими системами. Сервис передачи файлов подразуме-
вает, что всякий раз, когда приложение требует данные, которые, как оказывается, хранятся на
другой системе, файл с этими данными целиком копируется с удалённой системы на локаль-
ную. Приложение может работать с переданным файлом и при необходимости имеет возмож-
ность возвратить его обратно, внеся на локальной системе изменения в содержание файла. Сер-
вис передачи файлов в распределённой среде может сталкиваться с существованием множества
различных файловых систем и методов доступа к файлам.
Обычно сервис передачи файлов подразумевает, что существует пользователь или при-
ложение, которое управляет передачей файла между двумя системами. Этот пользователь, как
правило, размещается на системе-получателе. Передача файла включает два вида взаимодейст-
вия: управляющие операции, которые выполняются пользователем или приложением (контроль
доступа, выбор файла,управление файлами и атрибутами файлов) и протокол передачи файлов.
Файловые системы обеих взаимодействующих систем должны представляться как некоторое
условное хранилище файлов в форме, одинаково интерпретируемой обеими системами. Для
доступа к реальным данным каждая система должна "спроецировать" этот образ на реальную
файловую систему.
Существует два основных стандарта по сервису передачи файлов:
• стандарт де-юре ISO 8571 — Information processing systems — Open Systems Inter-
connection — File Transfer, Access and Management (FTAM);
• стандарт де-факто RFC 959 — File Transfer Protocol (FTP), используемый в стеке
протоколов TCP/IP.
Стандарты ISO по сравнению со стандартами RFC обладают значительно большей функциональностью,
но дополнительные функции приводят к значительно более объёмному и сложному программному коду при реа-
лизации и большим "накладным расходам" при исполнении этого кода системой. К тому же на практике обычно
используется лишь небольшое подмножество этих функций. Это замечание остается справедливым и при сравне-
нии многих других соответствующих стандартов ISO и RFC.
• Сервисы управления сообщениями. Сервис управления сообщениями имеет следую-
щие основные характерные черты.
• Для доставки сообщений используется метод "хранения и продвижения" (store-
and- forward). Это означает, что пользователи не устанавливают между сбой не-
посредственно сеанс связи, а взаимодействуют с сервисом управления сообще-
ниями, передавая ему поручения по пересылке сообщений. Локальная и удалён-
ные системы совместно несут ответственность за посланное отправителем сооб-
щение и гарантируют его доставку, даже если в текущий момент отсутствует со-
единение с удалённой системой-получателем или она является неактивной. Сер-
вис управления сообщениями — асинхронная форма коммуникаций без установ-
ления соединения.
• В отличие от сервиса передачи файлов отправитель и получатель здесь — это ко-
нечные пользователи (люди или прикладные программы), а не файловые систе-
мы.
• Сервис предусматривает специальные возможности для групповой и широкове-
щательной рассылки сообщений, ведения "адресной книги" и пр.
• Сервис предусматривает пересылку различных видов сообщений: обычного тек-
ста, файлов, сложных документов, факсов и пр.
• Сервис управления сообщениями не интересуется содержанием передаваемых
сообщений.
Термин "управление сообщениями" означает способность сервиса обеспечивать про-
зрачную пересылку по информационной системе любого сообщения, независимо от конкретно-
го его типа. Интерпретация и использование сообщений возлагается на прикладные программы,
которые пользуются этим сервисом. Частным случаем систем управления сообщениями являет-
ся электронная почта. Она задумана как аналог обычной почтовой системы для работы с элек-
тронными документами и используется для доставки текстовых сообщений (возможно, с при-
соединёнными к ним файлами) от одного пользователя (программы) к другому.
Существует две основные группы стандартов по сервису управления сообщениями:
• стандарт де-юре ISO/IEC 10021 — Message Handling Systems (MHS) и их эквива-
лент — серия стандартов Х.400;
• стандарты де-факто RFC 821, RFC 822 — Simple Mail Transfer Protocol (SMTP),
используемый в стеке протоколов TCP/IP. SMTP использует для адресации до-
менную систему имён DNS.
• Распределённые файловые сервисы обеспечивают прозрачный доступ к файлам неза-
висимо от их физического расположения в распределённой системе. Основное их отличие от
сервиса передачи файлов — в том, что вместо передачи целого файла от одной системы к дру-
гой передаются только те его части, которые необходимы для выполнения конкретной опера-
ции. Распределённые файловые сервисы часто также называют прозрачным доступом к файлам
(TFA — transparent file access). Распределённые файловые сервисы могут обеспечивать такие
возможности как управление параллельным доступом, контроль доступа и пр.
Основным стандартом де-юре является ранее упомянутый OSI FTAM, определяющий в
том числе возможность прозрачного доступа к файлам. Среди стандартов де-факто наибольшее
значение имеют SunNFS, используемый с протоколом TCP/IP, OSF/DCE Distributed File Service
(DFS), распределённая файловая система UNF (Universal File System) сетевой ОС Novell Net-
Ware.
• Сервисы распределённых баз данных. Рассмотренные до сих пор сервисы обеспечи-
вают доступ к файловым системам, считая файлы неструктурированным набором данных, где
любая интерпретация содержания файлов производится самим приложением. Базы данных
обеспечивают для приложений функции более высокого уровня, определяя внутреннюю струк-
туру данных и высокоуровневый механизм для хранения и доступа к данным, не касаясь их фи-
зической организации.
При организации сервисов баз данных в распределённых средах необходимо решить
проблемы пересылки запросов к БД и получения ответов через множество разнородных систем,
а также согласовывать состояние БД на различных системах. Данные, которые запрашивает
приложение, могут располагаться либо на локальной системе, либо на удалённой, либо быть
распределёнными, т.е. составляться из данных, находящихся на нескольких системах. Имея в
виду различия в моделях и структуре БД и множество различных СУБД, сервис должен обеспе-
чить стандартизованную и прозрачную работу пользователя с распределёнными БД.
Основными стандартами по данному сервису являются:
• ISO/IEC 9579 — Information technology — Open Systems Interconnection -- Remote
Database Access;
• Distributed Relational Database Architecture (DRDA), — спецификация, разрабо-
танная фирмой IBM.
• Распределённые сервисы печати организуют работу пользователя по печати докумен-
тов в распределённых средах, обеспечивая тот же набор услуг, что и на локальной системе. Ос-
новной стандарт по распределённому сервису печати — ISO/IEC 10175 — Information technol-
ogy — Text and office systems — Document Printing Application (DPA).
• Сервисы распределённой обработки транзакций. В п.2.2 уже рассматривалась мо-
дель распределённой обработки транзакций и указывалось, что для обеспечения переносимости
необходима спецификация интерфейсов между элементами модели и с приложениями. С точки
зрения взаимодействия систем необходима стандартизация того элемента, который обеспечива-
ет связь между системами, участвующими в транзакции — менеджера транзакций. Основным
международным стандартом является ISO 10026 — Information technology - Open Systems Inter-
connection - Distributed transaction proccesing (OSI-TP). Организация X/Open стандартизировала
API для доступа приложений к сервису, удовлетворяющему стандарту OSI-TP. Этот интерфейс
носит название ХАР-ТР.
4. Распределённые сервисы человекомашинного взаимодействия соответствуют раз-
биению распределённых приложений в части сервиса представления. Основная задача — при-
ложение и пользователь должны казаться друг другу расположенными локально несмотря на
различия в системах. Поддержка человекомашинного взаимодействия в неоднородных средах
требует стандартного набора протоколов для переноса данных сервиса представления.
Распределённые сервисы человекомашинного взаимодействия характеризуются тем, что
часть функций представления выполняется локально на системе пользователя, а часть — уда-
лённо, на той системе, где выполняется приложение. Каждый из распределённых сервисов че-
ловекомашинного взаимодействия соответствует аналогичному локальному сервису, но прини-
мает иные формы:
• локальный командный интерфейс превращается в интерфейс для удалённого ис-
полнения команд (распределённую оболочку);
• символьный интерфейс пользователя обычно превращается в сервис удалённого
терминала, или удалённого входа в систему;
• GUI, обеспечивающий доступ к приложению через сеть, носит название распре-
делённого оконного интерфейса.
• Распределённая оболочка. В распределённой среде пользователь должен иметь ко-
мандный доступ к сервисам операционных систем, отличных от той, которая установлена на
его локальной системе, без необходимости регистрации на каждой удалённой системе. Этот
сервис включает следующие функции:
• выполнение команд оболочки на удалённой системе;
• выполнение пакетных заданий с обеспечением прозрачности;
• контроль доступа к системам и ресурсам.
Основной стандарт по сервисам оболочки — IEEE 1003.2 (его эквивалент--ISO/IEC
9945-2:1993 Information technology - Portable Operating System Interface (POSIX) - Part 2: Shell
and Utilities).
• Удалённый терминал. Символьный интерфейс для удалённого входа в систему часто
также называют виртуальным терминалом. Этот сервис должен обеспечивать возможность вхо-
да в систему с различного оборудования и через различные транспортные системы.
Существует два основных стандарта по данному сервису:
• модель OSI Virtual Terminal (VT), изложенная в стандартах ISO/IEC 9040:1997 —
Information technology — Open Systems Interconnection — Virtual Terminal Basic
Class Service и ISO/IEC 9041 — Information technology — Open Systems Intercon-
nection — Virtual Terminal Basic Class Protocol;
• протокол TELNET из стека TCP/IP.
• Распределённый графический интерфейс. Протоколы, специфицирующие распреде-
лённый графический интерфейс, должны поддерживать выполнение более сложных операций,
чем просто чтение/запись в случае виртуального терминала. В неоднородной среде протокол
должен поддерживать различные типы устройств ввода/вывода и быть прозрачным для прило-
жений. Основные стандарты де-факто основаны на системе X-Window.
5. Межкатегориальные сервисы в распределённой среде являются расширением анало-
гичных сервисов локальной платформы. Рассмотрим два основных класса межкатегориальных
сервисов: управления системой и безопасности — в аспекте взаимодействия систем. Управле-
ние системой и безопасность оказывают значительное влияние на все части распределённой
системы и требуют единообразного подхода.
• Сервисы административного управления распределёнными системами являются
критичными для нормального функционирования распределённой системы. Как и в локальной
среде, сервисы управления включают в себя много аспектов, такие как управление конфигура-
цией сети, управление нештатными ситуациями, управление производительностью, инсталля-
цию программного обеспечения и др. Но задача управления осложняется тем, что в гетероген-
ной системе присутствует различное аппаратное обеспечение, операционные системы, сети пе-
редачи данных; приложения используют различные методы доступа к ресурсам и т.д.
Основным стандартом де-юре по административному управлению распределёнными
системами служит модель управления OSI, изложенная в стандарте ISO/IEC 7498-4:1989 Infor-
mation processing systems - Open Systems Interconnection - Basic Reference Model - Part 4: Man-
agement framework. Основными элементами этой модели являются:
• менеджер — процесс, который получает и отслеживает управляющую информацию и
вызывает операции управления;
• агент — процесс, который выполняет операции управления по команде менеджера и
передаёт менеджеру информацию для принятия решений по управлению;
• управляемый объект — представляет управляемые ресурсы. Собрание сведений об
управляемых ресурсах называется управляющей информационной базой MIB (Management In-
formation Base).
Модель получает развитие в следующем наборе стандартов ISO:
• ISO/IEC 9595 — Information technology — Open Systems Interconnection -- Common
management information service (CMIS);
• ISO/IEC 9596 — Information technology — Open Systems Interconnection -- Common
management information protocol (CMIP) — определяет протокол прикладного уровня для пере-
дачи управляющей информации;
• ISO/IEC 10040 — Information technology — Open Systems Interconnection — Systems
management overview;
• ISO/IEC 10164 — Information technology — Open Systems Interconnection — Systems
Management;
• ISO/IEC 10165 — Information technology — Open Systems Interconnection — Manage-
ment Information Services — Structure of management information. Аналогом стандартов ISO в
стеке протоколов TCP/IP являются:
• протокол SNMP — аналог CMIP;
• RFC 1155 — структура управляющей информации;
• RFC 1213 — структура MIB.
Среди других стандартов по административному управлению системами следует отме-
тить:
• стратегию управления распределёнными системами DME (Distributed Manage-
ment Framework) организации X/Open;
• модель управления административной информацией CIM (Common Information
Model) организации The Open Group.
Многие ведущие фирмы-производители также специфицируют свои подходы к управле-
нию распределёнными системами и API к сервисам управления.
• Сервисы защиты. Сервис защиты в распределённой (в особенности, неоднородной)
среде имеет много аспектов и включает много механизмов защиты: идентификация и аутенти-
фикация, целостность, конфиденциальность данных, контроль доступа и авторизация, неотка-
зуемость, аудит, административное управление сервисом защиты и пр. Распределённый харак-
тер системы добавляет много дополнительных угроз безопасности по сравнению с локальными
системами. Так, особенностями распределённых систем являются невозможность обеспечить
физическую безопасность системы в целом и, как правило, открытость коммуникационных ка-
налов.В силу высокой сложности проблемы существует большое количество стандартов по ор-
ганизации сервиса защиты в распределённой среде. Основные группы этих стандартов рассмат-
риваются в гл. 4. В целом в настоящее время наблюдается стремление к интегрированному ре-
шению проблем защиты информации в распределённой вычислительной среде.
Ссылки и замечания к гл. 2:
п. 2.1:
Гл. 2 во многом основана на материалах [20, ch. 3,4,5] как одного из наиболее удачных руководств по концепции от-
крытых систем: из этой работы заимствованы базовая модель информационной системы, методика её декомпозиции и клас-
сификация сервисов базовой модели. За основу модели берётся стандарт POSIX std 1003.0 - 1995 — The IEEE Guide to the
POSIX Open System Environment (POSIX.O). Данная модель, конечно, уступает по полноте и подробности тем, что вводятся в

<< Пред. стр.

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

ОГЛАВЛЕНИЕ

След. стр. >>

Copyright © Design by: Sunlight webdesign