LINEBURG


<< Пред. стр.

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

ОГЛАВЛЕНИЕ

След. стр. >>

XPG3 — семитомный документ, специфицирующий следующие компоненты системы:
команды и утилиты, набор системных вызовов, язык программирования С, интерфейсы терми-
нала, управление оконным интерфейсом, язык манипулирования данными SQL, языки про-
граммирования COBOL, FORTRAN, Pascal, Ada, транспортные интерфейсы и др. Кроме того,
организация Х/Ореn предусмотрела сертификацию программного обеспечения вычислительных
платформ на соответствие спецификации XPG. Предусмотрено три уровня сертификации:
• Уровень BASE BRAND означает, что система прошла верификацию на наличие
всех обязательных свойств операционной среды по трём спецификациям: коман-
ды и утилиты, набор системных вызовов, язык программирования С.
• Индивидуальная оценка компонентов на уровень соответствия, например, языков
программирования.
• Уровень PLUS BRAND означает полное соответствие с уровнем BASE BRAND и
наличие всех дополнительных необязательных компонент.
XPG4 — пятитомный набор спецификаций и требований по сертификации систем на со-
ответствие этим спецификациям, значительно более подробный по сравнению с документом
XPG3. В документ включено много новых спецификаций по реляционным базам данных, под-
держке спецификаций XWindow, директориальному сервису, сетевым файловым системам,
системам управления сообщениями на основе стандартов серии Х.400, обработке транзакций и
др. Все компоненты объединены в восемь функциональных групп: операционные системы и
языки программирования, управление данными, пользовательский интерфейс, общие средства
межсетевого взаимодействия, средства взаимодействия с мэйнфреймами, средства взаимодей-
ствия с персональными системами, носители данных, дополнительные компоненты.




Рис. 10. Модель САЕ

Проект Single UNIX - дальнейшее развитие предыдущих спецификаций и принципов
сертификации вычислительных платформ. Как известно, UNIX-подобные операционные систе-
мы существуют в большом количестве реализации, созданных разными фирмами и университе-
тами из разных стран, что ослабляет совместимость платформ приложений на основе этих ОС и
ставит вопрос о том, какие именно версии UNIX-подобных ОС считать истинной ОС UNIX. Он
поддерживается многими производителями программного обеспечения. Цель этого проекта -
создание архитектуры и спецификаций интерфейсов для «единого UNIX''a».
Действующей версией документа является спецификация UNIX 98 (версия 2). Выход
версии 3 этого документа намечен на 2001 г.
• Модель AES первоначально преимущественно была связана с определением среды,
поддерживающей переносимость приложений. Модель идентифицирует внутри среды откры-
тых систем шесть функциональных областей: операционные системы, сервисы среды пользова-
теля, сетевые сервисы, сервисы графики, сервисы управления базами данных, языки програм-
мирования. Чтобы соответствовать спецификациям AES, система должна иметь интерфейсы,
перечисленные в информационной базе модели. Модель основывается преимущественно на
стандартах организаций ISO, IEEE, ANSI:
• по операционным системам — стандарты POSIX, XPG BASE BRAND;
• по сервисам среды пользователя — спецификации Х Window, OSF/Motif;
• по сетевым сервисам — избранные сервисы ARPA/BSD, протоколы TCP, IP, SMTP,
TELNET, FTP, некоторые протоколы OSI;
• по сервисам графики — стандарты GKS, PHIGS;
• по сервисам управления базами данных — язык SQL;
• по языкам программирования — Ada, BASIC, С, COBOL, FORTRAN, LISP, Pascal.
Модели XPG и AES не являются конкурирующими, хотя их содержание во многом
идентично. Позднее модель AES фактически стала рассматриваться почти как подмножество
спецификаций XPG. Основная роль рассмотренных моделей на сегодняшний день заключается
в том, что они послужили важной отправной точкой для разработки в рамках объединённой ор-
ганизации The Open Group более совершенных моделей открытых распределённых вычислений,
в которых была достигнута большая степень обобщения и выработана современная точка зре-
ния на проблему организации таких систем.

3.4. Модели распределённых систем
Основная цель организации распределённой системы обработки данных, как было уста-
новлено в п. 2.1,— формирование образа единой системы для любого пользователя и любого
приложения системы с консистентным набором API и EEI к сервисам распределённой системы.
Эти сервисы слишком обширны и многочисленны, чтобы их можно было реализовать в
одном компоненте распределённой системы. Следовательно, система должна иметь модульную
структуру. Для того чтобы специфицировать компоненты распределённой системы и взаимо-
связи между ними, создаются каркасные модели распределённых систем. Компоненты такой
модели носят название "менеджеры ресурсов", или "сервисные модули". (Модели распределён-
ных систем, как правило, оперируют абстрактными понятиями высокого уровня, не связанными
с технической реализацией компонентов в вычислительных системах.) Один или несколько
взаимосвязанных и взаимодействующих менеджеров ресурсов обеспечивают реализацию сер-
висов, которые распределённая система предоставляет через API и EEI. Иными словами, дан-
ный класс моделей описывает внутреннюю структуру компонента "сервисы распределённой
системы" на рис. 5.
Приложения и пользователи не ощущают физического расположения ресурсов системы,
и это качество сохраняется независимо от составляющего систему аппаратного, программного
обеспечения и сетей передачи данных. Это делает возможным построение такой системы обра-
ботки данных, в которой ресурсы, сервисы, менеджеры ресурсов и элементы приложений были
бы распределены между отдельными вычислительными системами и в полной мере использо-
вали преимущества каждой отдельной системы.
Модели распределённых систем являются надмножествами коммуникационных архи-
тектур в том смысле, что последние полностью включаются в них. Но, в отличие от архитектур,
модели распределённых систем определяют не просто форматы и протоколы, но также API,
обеспечивающие переносимость и способность к взаимодействию. Кроме того, модели по срав-
нению с коммуникационными архитектурами проводят более чёткую границу между функция-
ми транспортного провайдера и транспортного пользователя, так как выделяют их в различные
компоненты. Некоторые модели предоставляют возможности выбора коммуникационных архи-
тектур.
Особенность каркасных моделей распределённых систем заключается в том, что они не
вводят новых стандартов, а, подобно профилям, пользуются набором уже существующих стан-
дартов де-юре и де-факто и определяют взаимосвязи между ними.
• Модель XDCS (X/Open Distributed Computing Services) опубликована в 1992 — 93 гг.,
за основу для неё взяты спецификации XPG. Основная цель — описать распределённую среду
обработки данных, а именно: сервисы, требуемые в распределённой среде, взаимосвязи между
сервисами, интерфейсы программирования к этим сервисам, протоколы и форматы данных для
обеспечения взаимодействия вычислительных систем.
Структура XDCS слагается из трёх основных компонентов (рис. 11):
• четырёх уровней сервисов;
• качеств, которые прилагаются ко всем аспектам всех уровней сервисов (изображены на
рис. кольцом);
• способности взаимодействовать с существующими системами. XDCS содержит описа-
ние каждого из перечисленных выше компонентов, взаимосвязи между ними и перечисляет
поддерживаемые стандарты по протоколам, форматам данных и интерфейсам программирова-
ния.




Рис. 11. Модель XDCS

Каждый из четырёх уровней сервисов имеет множество компонент, которые отображают
менеджеры ресурсов, обеспечивающие сервисы определённого типа.
Сервисы операционной системы. Их назначение — обеспечить на каждой платформе
распределённой системы единообразную базу для формирования среды открытых систем в ви-
де единого набора системных интерфейсов, команд и утилит. Модель поддерживает специфи-
кации XSH, POSIX.l, POSIX.2.
Коммуникационные сервисы служат для обеспечения надёжной, не зависящей от техни-
ческой реализации сетей, связи между узлами в распределённой системе, позволяющей прило-
жениям обмениваться данными независимо от сетевых протоколов, форматов, топологии сети и
коммуникационного оборудования. Коммуникационные сервисы включают два компонента:
сетевые сервисы и сервисы межпроцессного взаимодействия. Модель поддерживает две ком-
муникационные архитектуры: OSI и ТСРЛР, а также API для доступа к соответствующим про-
токолам: X/Open XTI и ХАР.
Сервисы распределения обеспечивают для системного и прикладного ПО базовый набор
сервисов по поддержке функций распределённой среды, которые не могут быть достигнуты с
использованием сервисов операционной системы и коммуникационных сервисов. Это меха-
низмы защиты, административного управления системами, синхронизации времени и директо-
риальный сервис. Они существенно отличаются от аналогичных, поддерживаемых локальными
системами в отдельности.
Прикладные сервисы предоставляют поддержку для разработки распределённого при-
кладного ПО. В эту группу входят:
• распределённые файловые сервисы: поддерживаются стандарты NFS, DFS, XFTAM;
• сервисы управления сообщениями: поддерживаются стандарты Х.400, XMHS;
• сервисы обработки транзакций: поддерживаются стандарты ТХ, ХА;
• сервисы управления данными: поддерживаются стандарты X-ISAM, SQL, RDA,
X-SAG;
• сервисы оконного интерфейса: поддерживается спецификация XWindows.
Понятия "качеств сервисов" относятся ко всем четырём уровням сервисов. Они включа-
ют такие категории как безопасность, доступность, управляемость и интернационализация.
XDCS — это каркасная модель. Она не специфицирует конкретные технологии и про-
дукты, реализующие их, не поддерживает никаких конкретных производителей вычислитель-
ных систем, не требует никакой конкретной операционной системы.
• Модель UNIX International's Atlas в настоящее время не имеет практического значения
и представляет лишь исторический интерес. Так, именно при разработке этой модели было
сформулировано положение о том, что ни один производитель не может за приемлемую цену
снабдить потребителя всеми элементами системы обработки данных. Кроме того, она послужи-
ла базисом для модели XDCS. Однако графическое представление модели Atlas (рис. 12) замет-
но отличается от модели XDCS. Модель в основном опирается на технологические решения,
принятые в семействе UNIX-подобных операционных систем.
Модель имеет многоуровневую структуру. Внутри каждого из уровней находятся сер-
висные компоненты. Atlas специфицирует стандарты для компонент, а для некоторых из них —
и конкретные технологии или продукты. Эти технологии не предполагают полного исключения
других возможных реализации тех же сервисов, а скорее служат руководством.
Уровни модели включают следующие сервисы:
• Базовые сервисы операционной системы обеспечивают возможность интеграции ос-
новных версий операционной системы UNIX при условии обратной совместимости с предыду-
щими версиями этой операционной системы. Базовыми технологиями для реализации сервиса
выбраны UNIX System V Release 4.1 ES с расширенными функциями защиты данных и UNIX
System V Release 4.0 MP с поддержкой мультипроцессирования.
• Коммуникационные сервисы включают поддержку коммуникационных архитектур OSI
и ТСР/IР.
• Системные сервисы обеспечивают единообразие, требуемое в распределённой среде, и
аналогичны соответствующим сервисам XDCS.
• Сервисы приложений обеспечивают поддержку для распределённых приложений. В
качестве базовых технологий выбраны сетевая файловая система SunSoft NFS для файловых
сервисов и USL Tuxedo для обработки транзакций.
• Сервисы защиты включают аутентификацию на базе технологии Kerberos, шифрова-
ние, контроль доступа и др.
• Сервисы межсистемного взаимодействия. Их цель — обеспечить способность к взаи-
модействию между различными системами и коммуникационными архитектурами.
• Прикладные инструменты. Это средства для разработки прикладного ПО, такие как
средства автоматизации разработки (CASE-системы), языки программирования.
Рис. 12. Модель UI-Atlas

• Модель IBM Open Blueprint стала основой стратегии фирмы IBM по построению от-
крытой распределённой среды. Это глубоко продуманная и исключительно тщательно разрабо-
танная логическая модель. Она представляет собой итог важного этапа поиска подходов к орга-
низации распределённых сред.
Структура Open Blueprint позволяет сети различных систем функционировать как
единый модуль, как распределённая операционная система. Локальная система рассматривается
как часть распределённой сети, а сеть рассматривается как единая система. Распределенная вы-
числительная система состоит из множества систем, соединённых друг с другом и взаимодей-
ствующих между собой через сеть.
Сервисы на каждой системе управляют ресурсами совместно через сеть таким же обра-
зом, как обычная операционная система управляет ресурсами отдельной вычислительной сис-
темы. Каждый узел в сети может быть структурирован в соответствии с моделью Open
Blueprint. Каждый сервис на конкретной вычислительной системе должен быть доступен при-
ложениям со всех остальных вычислительных систем. Эквивалентные сервисы на каждой ло-
кальной системе работают совместно для поддержки общей распределённой сетевой среды.
Для соответствия требованиям открытости компоненты модели Open Blueprint должны
строго придерживаться стандартов при разработке элементов API, форматов и протоколов, ко-
торые позволяют различным программам выполняться на одних и тех же или разных вычисли-
тельных системах для совместной работы.
Основной структурный элемент Open Blueprint — менеджер ресурсов — набор про-
грамм, которые определяют состояние, управляют и обеспечивающих доступ к некоторому на-
бору ресурсов. Управление ресурсами — это логическая концепция. Менеджеры ресурсов пре-
доставляют набор интерфейсов, в том числе API, через которые могут быть выполнены опера-
ции над их ресурсами. Примерами менеджеров ресурсов являются файловая система, сервер
печати, менеджер баз данных и др.
Управляемые ресурсы могут быть распределены среди множества серверов в гетероген-
ной сети. Менеджеры ресурсов подразделяются на локальные и распределённые. Локальный
менеджер ресурсов - это менеджер, управляющий ресурсами, размещёнными на конкретной,
единичной системе в сети. Распределённый менеджер ресурсов взаимодействует со многими
системами. Он включает в себя клиентскую часть, которая поддерживает интерфейсы, исполь-
зуемые для запроса сервиса, и серверную часть, которая выполняет операции над ресурсами,
необходимые клиентской части. Работа распределенного менеджера ресурсов представляет со-
бой взаимодействие клиентской и серверной частей. Клиентская часть может выполнять неко-
торые вычисления и может определять, какая часть сервера должна обслуживать запрос, под-
держивает множество протоколов, необходимых для работы в гетерогенной среде. Серверная
часть может обрабатывать запрос самостоятельно или передавать его другому менеджеру ре-
сурсов. Клиентская и серверная части взаимодействуют посредством определенных про-
токолов, использующих сервисы модели Open Blueprint. Приложения, поддерживаемые систе-
мой, могут быть сконфигурированы так, что будут содержать только клиентские части распре-
делённого менеджера ресурсов (обычная конфигурация рабочей станции конечного пользова-
теля). Менеджеры ресурсов могут быть объединены в наборы, которые и будут поддерживать
гетерогенные среды. Причем любой из менеджеров ресурсов в наборах может быть заменен без
изменения в программах, которые его используют.
Сервисы модели сгруппированы в несколько классов и функционально разделены по не-
скольким уровням (рис. 13):
• нижний уровень — сетевые сервисы — включает: физическую сеть, сигнальную и
управляющую систему сети, предназначенную для управления работой соединений в сети,
транспортную систему, которая обеспечивает поддержку протоколов для передачи информации
от одной системы к другой, таких как TCP/IP, SNA/APPN, NETBIOS, IPX, интерфейс CTS
(Common Transport Semantics) как средство организации гетерогенных сетей;
• средний уровень — сервисы распределенной системы — включает коммуникационные
сервисы (communication services) для создания и поддержки механизмов взаимодействия частей
распределённых приложений, сервисы управления объектами (object management services) для
управления локальными и удаленными объектами в гетерогенной среде, распределённые серви-
сы (distribution services): директориальный, сервис управления транзакциями, сервис времени и
сервис защиты;
• верхний уровень — приложения, и сервисы поддержки приложений (application ena-
bling services) — включает сервисы представления (presentation services) — механизмы взаимо-
действия между пользователями и приложениями, сервисы доступа к данным (data access ser-
vices), сервисы поддержки приложений и групповой работы (application/workgroup services),
средства разработки приложений (development tools).
Указанные три группы сервисов распределённой платформы поддерживаются сервисами
локальных операционных систем и средствами управления системой.
Сервис локальной операционной системы (Local Operating System Services) представляет
собой локальный менеджер ресурсов, который поддерживает сервисы распределённого менед-
жера ресурсов. Локальный менеджер ресурсов предназначен для управления ресурсами на ло-
кальной машине, такими как центральный процессор и периферийные устройства. Фактически,
операционная система, построенная в соответствии с моделью, будет представлять собой имен-
но такую службу, осуществляя при этом возложенные на нее функции. В соответствии с моде-
лью Open Blueprint служба управления локальной системой должна обеспечивать и поддержи-
вать следующие функции: управление задачами, поддержка и управление конфигурацией,
управление системой защиты, управление работой приложений, поддержка работы системных
журналов и обработка событий в системе, управление средствами доступа к ресурсам.Средства
административного управления системами (Systems Management) обеспечивают и поддер-
живают механизмы, которые позволяют системным администраторам и автоматизированным
процедурам управлять сервисами в распределенной среде.
Рис. 13. Модель Open Blueprint

Для реализации распределённой системы согласно этой модели на практике необходимо
выбрать конкретные технологии для каждой функции или компонента в архитектуре. Не суще-
ствует, однако, взаимно однозначного соответствия между компонентами модели OpenBlueprint
и конкретными продуктами. Блоки модели в общем случае содержат множественные компо-
ненты и не относятся к конкретным продуктам. В настоящий момент есть много продуктов
корпорации IBM, а также других фирм, которые могут выполнять требуемые функции.
• Модель OSF DCE (Distributed Computing Environment) отличается от до сих пор рас-
сматривавшихся моделей распределённых систем. Во-первых, она является более узкой: опре-
деляет только набор сервисов, составляющих инфраструктуру для разработки и функциониро-
вания гетерогенных распределённых вычислительных сред. Во-вторых, DCE — не только набор
спецификаций, но также и программный продукт, реализующий их. Тем самым. DCE является
примером "middleware", т.е. прототипом слоя программного обеспечения "среднего уровня",
который в уровневой модели находится выше системного ПО локальной системы, но ниже
прикладного ПО и обеспечивает функциональность распределённой системы. Большинство
других моделей (в том числе XDCS, UI-Atlas, IBM Open Blueprint) включает спецификации
DCE для ключевых сервисов распределённой системы: защита информации, время, система
именования и директорий. DCE формирует ядро технологий распределённых сервисов в этих
моделях.
Ценность модели DCE — в том, что в ней был не только чётко сформулирован полный
набор распределённых сервисов различных уровней (рис. 14), но и выбраны оптимальные пути
их практической реализации в программных продуктах.
На самом нижнем уровне DCE обеспечивает механизм управления нитями, позволяю-
щий распараллеливать процессы, вовлекая даже такие системы, которые не поддерживают ме-
ханизм нитей. Для реализации этого механизма выбрана архитектура СМА (Concert Multi-thread
Architecture) фирмы DEC. Для межпроцессного взаимодействия DCE использует вызов удалён-
ных процедур (реализация — NCS (Network Computing System) RPC 2.0 фирмы Hewlett-
Packard). Для обеспечения взаимодействия с другими системами используется механизм
sockets.
На более высоком уровне располагаются сервисы распределённой системы, которые
включают сервис времени, директориальный сервис и сервис именования. В модели выбраны
следующие реализации соответствующих сервисов:
DECdts (разработка DEC), Dir-X (основанная на Х.500 разработка Siemens-Nixdorf),
DECdns (сервис доменных имён, разработанный DEC с добавлениями Массачусетского техно-
логического института). Также предусмотрена возможность включения дрих сервисов в буду-
щем.
Чтобы распределённая система могла функционировать в защищённой среде, преду-
смотрены сервисы защиты, представленные в DCE сервисом аутентификации на основе систе-
мы Kerberos v.5, разработанной Массачусетским технологическим институтом с расширениями
фирмы Hewlett-Packard. Этот сервис является обязательным компонентом любой среды, по-
строенной по модели DCE.
В модели также определён набор необязательных сервисов. Он включает распределён-
ную файловую систему (в пакете выбрана AFS — Andrew File System — разработка Transarc
Corp.), поддержку персональных систем и бездисковых рабочих станций. Также предусмотрена
возможность добавления в будущем других факультативных возможностей.
Сервис административного управления на самом деле не существует как единый блок.
Он реализован в форме некоторого набора возможностей управления, включаемых в каждый
компонент модели.
Модель и поддерживающие её продукты DCE стали стандартом де-факто в промышлен-
ности и реализованы на большом количестве платформ с операционными системами MVS,
Open VMS, AIX, OS/2, Windows и др.




Рис. 14. Модель OSF DCE

3.5. Обобщённые модели открытых распределённых вычислений
3.5.1. Модель RM-ODP
Модель RM-ODP (Reference Model of Open Distributed Processing) — совместное усилие
ISO и ITU-T по разработке общей основы для стандартизации открытых распределённых вы-
числений. Модель изложена в серии стандартов ISO 10746 и эквивалентных им стандартах ITU-
T из серии Х.900:
• ISO/IEC 10746-1:1998 (ITU-T X.901) — Information technology -- Open Distributed
Processing — Reference model: Overview;
• ISO/IEC 10746-2:1996 (ITU-T X.902) Information technology - Open Distributed
Processing — Reference Model: Foundations;
• ISO/IEC 10746-3:1996 (ITU-T X.903) Information technology - Open Distributed
Processing -- Reference Model: Architecture;
• ISO/IEC 10746-4:1998 (ITU-T X.904) Information technology - Open Distributed
Processing — Reference Model: Architectural semantics.
Цель этого стандарта — создание каркасной архитектуры для модели открытых распре-
делённых вычислений. Архитектура основывается на точных концепциях, выведенных из су-
ществующих разработок различных фирм по распределённой обработке данных и, насколько
это возможно, на использовании формальных описательных приёмов. Данный стандарт пред-
ставляет также интерес как источник терминологии в области открытой распределённой обра-
ботки данных.
Распределённая обработка данных в стандарте определяется как обработка информации,
при которой дискретные компоненты системы обработки данных могут быть размещены в раз-
личных местах, причём коммуникации между компонентами могут вносить задержку в обра-
ботку или быть ненадёжными.
Распределённым системам присущи следующие характеристики:
• удалённость — компоненты распределённой системы могут быть "распылены" в про-
странстве, взаимодействия между ними могут быть либо локальными, либо удалёнными;
• параллелизм — любой компонент распределённой системы может быть активен (может
выполняться) параллельно с любым другим компонентом;
• отсутствие глобального состояния — глобальное состояние распределённой системы
не может быть точно зафиксировано и описано;
• частичная ненадёжность — любой компонент распределённой системы может отка-
зать независимо от любых других компонентов;
• асинхронность — коммуникации и активность процессов не управляются едиными
глобальными часами, взаимосвязанные изменения в распределённой системе не обязательно
происходят одновременно.
Распределённые системы могут пересекать границы организаций и подчиняться различ-
ным техническим условиям. Это обычно приводит к отсутствию единого центра управления и,
как следствие, придаёт им дополнительные характеристики:
• гетерогенность — означает, что нет гарантии, что компоненты распределённой систе-
мы строятся, используя одни и те же технологии, причём набор различных технологий может
изменяться со временем;
• автономность — различные части системы находятся в ведении нескольких (многих)
автономных органов контроля и управления, без единой координации между ними;
• эволюционность — за период своего жизненного цикла открытая распределённая сис-
тема обычно сталкивается со многими изменениями, которые вызываются техническим про-
грессом, изменением целей деятельности предприятий, новыми типами приложений;
• мобильность — источники информации, обрабатывающие узлы, пользователи (и даже
их рабочие места) могут быть физически перемещаемы по системе, программы и данные также
могут передвигаться между узлами системы.
Чтобы отвечать указанным требованиям, стандарты открытой распределённой обработ-
ки должны позволять строить системы в соответствии со следующими принципами:
• Открытость — свойство, включающее переносимость и способность к взаимодейст-
вию (в смысле ранее введённых понятий).
• Интегрируемость означает, что различные системы и ресурсы могут внедряться в це-
лую систему без значительных дополнительных затрат и разработок. Это свойство включает,
например, возможность интеграции систем с различными архитектурами, различных ресурсов с
различной производительностью. Оно направлено на решение проблемы гетерогенности.
• Гибкость — свойство поддержки эволюции системы, включая существование и про-
должение работы в системе компонентов предыдущих поколений. Гибкость включает в том
числе возможность динамической переконфигурации без остановки работы всей системы. Это
требование направлено на решение проблемы мобильности.
• Модульность — структурное свойство системы, означающее, что части системы авто-
номны, но взаимосвязаны. Это — основа гибкости.
• Федеративность — свойство объединяемых систем, находящихся в различных адми-
нистративных и технических доменах, достигать некоторой единой цели.
• Управляемость — свойство мониторируемости, возможности контроля и управления
ресурсами системы для поддержания определённой её конфигурации, обеспечения качества
сервисов и учётности ресурсов.
• Обеспечение качества сервиса — свойство системы отвечать заданному набору требо-
ваний по качеству предоставляемых пользователям услуг: времени ответа, доступности уда-
лённых ресурсов, надёжности, устойчивости к сбоям и пр.
• Безопасность — свойство, гарантирующее, что услуги, предоставляемые системой, и
данные, хранящиеся в системе, защищены от неавторизованного доступа.
• Прозрачность — свойство маскировать от приложений детали и различия в механиз-
мах: гетерогенность аппаратного и программного обеспечения, расположение и размещение
компонентов, механизмы для достижения требуемого качества сервисов в условиях сбоев в
системе и др. Оно используется для преодоления проблем, вызванных распределённым харак-
тером системы.
Средствами реализации указанных принципов в стандарте ISO 10746 названы общие
сервисы системы. Принцип их выделения в системе также сформулирован в стандарте: посред-
ством группировки вместе свойств (в смысле предоставляемых ими услуг, полезных качеств —
features) различных сервисов каждой вычислительной платформы, входящей в распределённую
систему, и достижения соглашений относительно этих свойств гетерогенность распределённой
системы может быть структурирована контролируемым образом. Иными словами, все предос-
тавляемые пользователю и приложениям услуги распределённой системы оказываются струк-
турированными по категориям сервисов. Такого же принципа придерживаются и другие модели
открытых распределённых вычислений.
Стандарт также утверждает, что не может быть создана единая, общая инфраструктура,
которая обеспечивает абсолютно все свойства, требуемые от распределённых систем. Таким
образом, возникает необходимость выбирать компоненты, которые формируют инфраструкту-
ру, отвечающую требованиям различных видов приложений. Следовательно, необходима также

<< Пред. стр.

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

ОГЛАВЛЕНИЕ

След. стр. >>

Copyright © Design by: Sunlight webdesign