WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 || 3 |

«Запечников С.В. ...»

-- [ Страница 2 ] --

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

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

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

Среди схем именования ресурсов наибольшее значение имеют схема 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). Данная модель, конечно, уступает по полноте и подробности тем, что вводятся в документах организаций по стандартизации, но она позволяет ясно и чётко представить основные функции системы обра ботки данных по поддержке прикладного ПО, ввести понятия сервисов как абстрактного представления компонентов ин формационной системы, широко применяемое в реальных стандартах, обосновать необходимость введения стандартизован ных интерфейсов (п. 2.2) и многоуровневых коммуникационных архитектур (п. 2.3), классифицировать значительную часть стандартов по информационным технологиям. Такая модель создаёт основу для более детального изучения отдельных клас сов программного обеспечения (операционные системы, СУБД, стеки коммуникационных протоколов и др.), даёт возмож ность грамотно классифицировать и определять место в системе практически любого программного продукта.

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

п. 2.2, 2.3:

Переносимость (portability) и способность к взаимодействию (interoperability) упоминаются как необходимые свой ства открытых систем во всех без исключения определениях. Иногда к ним добавляют другие, которые, как правило, являют ся производными от них. В глоссарии к [24] эти два свойства определяются следующим образом (приводится исходный текст на английском языке):

"Portability — (1) The ease with which a system or component can be transferred from one hardware or software environment to another. (2) A quality metric that can be used to measure the relative effort to transport the software for use in another environment or to convert software for use in another operating environment, hardware configuration, or software system environment. (3) The ease with which a system, component, data, or user can be transferred from one hardware or software environment to another."

"Interoperability — (1) The ability of two or more systems or components to exchange and use information. (2) The ability of systems to provide and receive services from other systems and to use the services so interchanged to enable them to operate effectively together. " В данной работе намеренно не рассматриваются в подробностях методы построения, функционирования, управле ния вычислительными сетями и технологии передачи данных, так как этот вопрос представляет из себя отдельную, довольно обширную отрасль информационных технологий. Здесь вычислительные сети затрагиваются только с точки зрения предос тавляемых системам и приложениям сетевых сервисов.

Хорошим руководством по теоретическим основам сетей передачи данных — нижнему уровню сетевых сервисов распределённых систем обработки данных - является книга [I]. В ней, в частности, рассматриваются вопросы многоуровне вой архитектуры вычислительных сетей, управление каналами передачи данных, моделирование задержек в сетях передачи данных, методы доступа к среде передачи, маршрутизация, управление потоками. Теоретические основы организации локаль ных сетей рассматриваются в [4], основные стандарты по локальным сетям можно найти в [5].

Глава 3. ОСНОВНЫЕ МОДЕЛИ ОТКРЫТЫХ СИСТЕМ И ИХ РАЗВИТИЕ 3.1. Классификация моделей Появление очень большого числа стандартов в различных областях информационных технологий привело к необходимости систематизации их в абстрактных логических моделях, отображающих структуру информационной системы на более высоком уровне, облегчающих классификацию, размещение и применение стандартов. Данные модели не имеют целью под робную структуризацию всей информационной системы. Скорее, их задача — выявить принци пы архитектурного построения системного и прикладного программного обеспечения и его размещения по аппаратным компонентам системы обработки данных. Аппаратура при этом вы ступает в качестве своеобразного "фона", "ячеек" для размещения программного обеспечения.

Строгой классификации указанных моделей не существует, но различают несколько ос новных их видов:

• Профиль. Отличается высокой точностью описания, фокусируется на подмножестве взаимосвязанных стандартов или архитектур.

• Архитектура. Характеризуется очень высокой точностью описания всех концепций, отсутствием двусмысленностей, хорошо специфицированными описаниями сервисов и меха низмов их реализации (за исключением деталей реализации).

• Каркасная модель (framework). Имеют более низкую точность, описывают только об щие концепции, не содержат подробных объяснений и детальных спецификаций. Этим поняти ем часто обозначаются модели высокой степени абстракции, описывающие общие соглашения, понятия и методы формирования более конкретных моделей.

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

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

Рис. 7. Классификация моделей открытых систем Указанные модели претерпели несколько этапов своего развития, среди которых можно выделить три основных. До 80-х гг. обработка данных в основном базировалась на централизо ванных архитектурах вычислительных систем. Централизованная архитектура включает в себя операционную систему и взаимодействующие приложения. Операционная система обеспечива ет для приложений все основные системные функции и диктует поведение приложений. В кон це 80-х гг., с развитием распределённой модели вычислений, различными фирмами и организа циями предпринимаются попытки оформить достигнутый уровень понимания структуры и функций распределённых вычислительных систем в абстрактных моделях. Результатом явилось создание ряда независимых моделей, различающихся степенью детализации структуры систем, диапазоном охвата и пр., в различной степени совместимых (или несовместимых) между собой.

Представителями этой "волны" являются модели SAA (System Application Architecture) фирмы IBM, ISO OSI, DNA/NAS фирмы DEC, CAE организации X/Open, Atlas организации Unix Inter national. Некоторые из них оказались не очень удачными, другие, такие как модель OSI, оказали мощное влияние на всё дальнейшее развитие концепции открытых систем. Наконец, следую щий этап (90-е гг.) характеризуется стремлением построить универсальные модели, системати чески обеспечивающие совместимость различных архитектур и формирование открытой среды информационных технологий. Примерами могут служить модели POSIX OSE, XDCS, Network ing Blueprint и Open Blueprint фирмы IBM.

Для характеристики существующих на сегодняшний день моделей их удобно подразде лить на несколько классов (рис. 7) согласно предмету описания и охватываемому ими диапазо ну (в качестве основы для классификации выбрана модель POSIX OSE, использовавшаяся в гл.

2.):

• Структуры, описывающие операционные системы (operating system structures) — это спецификации, созданные преимущественно с целью обеспечения переносимости приложений между различными аппаратными платформами. Примерами таких структур являются OSF/1 и UNIX System V Release 4 (SVR4).

• Коммуникационные архитектуры (communications architectures). Основной их целью является описание порядка обеспечения способности к взаимодействию между системами.

Коммуникационные архитектуры предоставляют формальное определение многоуровневой мо дели взаимодействия вычислительных систем (см. п. 2.3) и определяют стандарты протоколов для каждого уровня. Примерами являются архитектуры OSI, SNA, DNA.

• Каркасные модели сред (environment frameworks). Эти модели охватывают аспекты пе реносимости и способности к взаимодействию одновременно, т.е. полностью специфицируют среду открытых систем. Однако, в общем случае, они не специфицируют взаимосвязи между модулями каркасной модели. Они могут рассматриваться как общие профили вычислительных платформ (АР), так как описывают совокупность общих сервисов и средств управления ресур сами системы и определяют стандарты, которым вычислительные системы должны соответст вовать, чтобы считаться открытыми. Примерами таких моделей могут служить модель САЕ ор ганизации Х/Ореn и модель AES организации OSF.

• Каркасные модели распределённых систем (distributed systems frameworks). Это моде ли, которые также обеспечивают и переносимость, и способность к взаимодействию одновре менно, но они не только описывают "каркас" из модулей, но и специфицируют связи между ними. Часто они предоставляют альтернативные подходы по включению того или иного модуля в "каркас". Заметим, что эти модели являются надмножествами коммуникационных архитектур в том смысле, что полностью включают их в себя. Примерами таких моделей могут служить модель XDCS организации Х/Ореn, модель Atlas организации Unix International, модель Open Blueprint фирмы IBM, модель OSF DCE.

• Развитие и усложнение последнего типа моделей привело к попыткам создания обоб щённых моделей открытых распределённых вычислений. К ним можно отнести модели высокой степени абстракции, формально описывающие структуру и функционирование распределённых систем, формулирующие основные принципы синтеза, анализа и управления открытыми рас пределёнными системами обработки данных, наборы стандартов и компонентов для конструи рования архитектур систем. Указанные модели являются дальнейшим обобщением трёх основ ных видов логических моделей: профилей, архитектур и каркасных моделей. Модели предыду щего поколения описывали системы масштаба предприятия, но обобщённые модели идут дальше — они универсальны. Они описывают эталон абстрактной информационной системы любого уровня: от локальной до глобальной, всемирного масштаба. Примерами таких моделей являются модель RM-ODP, разработанная ISO и ITU, модель TAFIM Министерства обороны США, модель TOGAF организации The Open Group, модель SPIRIT Platform Blueprint органи зации NCF.

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

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

3.2. Базовые стандартные модели 3.2.1. Модель ISO OSI Модель OSI (Open Systems Interconnection) является классическим примером коммуни кационной архитектуры. Она определяет семиуровневую модель взаимодействия вычислитель ных систем. Модель OSI — старейшая из моделей открытых систем.

Модель изложена в стандарте ISO 7498, состоящем из четырёх частей:

• ISO/IEC 7498-1:1994 Information technology - Open Systems Interconnection — Basic Reference Model: The Basic Model;

• ISO/IEC 7498-2:1989 Information processing systems — Open Systems Interconnec tion — Basic Reference Model — Part 2: Security Architecture;

• ISO/IEC 7498-3:1997 Information technology - Open Systems Interconnection - Ba sic Reference Model: Naming and addressing;

• ISO/IEC 7498-4:1989 Information processing systems — Open Systems Interconnec tion — Basic Reference Model — Part 4: Management framework.

В первой части стандарта определяется базовая нормативная модель (reference model) взаимодействия открытых систем, остальные три части определяют модели безопасности (часть 2), управления (часть 4), именования и адресации (часть 3) в среде открытых систем.

На разработку модели OSI оказали влияние уже существовавшие многоуровневые моде ли, такие как SNA и DNA. Выделение в модели именно семи уровней и разделение функций между ними было до некоторой степени произвольным. Оно явилось попыткой найти опти мальное соотношение между противоречивыми требованиями простоты модели и сложности описываемой структуры и стало "опорной точкой" в формировании сетевых архитектур и опре делении функций вычислительных сетей.

Архитектура OSI довольно абстрактна и охватывает очень широкий круг аспектов: об щие принципы взаимодействия открытых систем, описание каждого из семи уровней, оборудо вание. Модель оперирует элементами архитектуры:

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

Рис. 8. Модель взаимосвязи открытых систем OSI Каждый уровень модели OSI (рис. 8) представляет собой группу взаимосвязанных функ ций обработки данных и связи между системами, которые могут быть выполнены стандартным образом с целью поддержки различных приложений. Каждый уровень обеспечивает хорошо определённый набор сервисов для вышележащего уровня и, в свою очередь, использует серви сы уровня, находящегося ниже его. Таким образом, процесс осуществления связи между систе мами разбивается на отдельные, легко управляемые блоки. Все вместе семь уровней обеспечи вают коммуникационный сервис между оконечными пользователями (end-to-end). Изменения в протоколе любого уровня могут быть выполнены, не затрагивая соседних уровней.

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

• определение сервиса уровня, которое в абстрактной форме описывает доступные извне услуги данного уровня;

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

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

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

Основные функции верхних уровней — следующие:

• Прикладной уровень (уровень 7) обеспечивает приложения необходимым высокоуров невым интерфейсом к нижележащим коммуникационным сервисам с целью обеспечения их связи с приложениями-партнёрами на других системах. К прикладному уровню также принято относить набор специализированных сервисов-приложений, таких как передача файлов, управ ление сообщениями, виртуальный терминал, директориальный сервис и др. Этими сервисами могут, в свою очередь, пользоваться приложения конечного пользователя. В рамках сервисов, стандартизированных ISO, к ним относятся стандарты FTAM, X.400, VT, X.500. Сами прило жения пользователя считаются расположенными над прикладным уровнем.

• Уровень представления данных (уровень 6) предназначен для согласования синтаксиса и семантики данных для использования в процессе передачи данных между системами.

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

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

• Транспортный уровень (уровень 4) обеспечивает надёжную и эффективную доставку данных между любыми двумя абонентами потенциально ненадёжной сети передачи данных, независимо от характеристик и топологии сети.

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

• Уровень звена данных (уровень 2) связан с обменом неструктурированными данными между смежными узлами сети. На этом уровне происходит обмен модулями данных — фрей мами — и обеспечивается обнаружение и исправление ошибок передачи.

• Физический уровень (уровень 1) предоставляет физическое соединение для передачи данных: среду распространения сигнала, интерфейсы, процедуры передачи сигналов по линии связи.

Уровни модели OSI можно сгруппировать в две категории, соответствующие понятиям "транспортный провайдер" (уровни 1 — 4) и "транспортный пользователь" (уровни 5 — 7) — см. п. 2.3.

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

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

На любом национальном рынке крупнейшим потребителем информационных техноло гий наряду с крупными корпорациями часто является правительство государства. Стремление правительств обеспечить соответствие продуктов и изделий информационных технологий, при обретаемых различными подразделениями правительственных органов, текущим международ ным стандартам по взаимодействию открытых систем и тем самым обеспечить по меньшей ме ре некоторую гарантию их совместной работы обусловило появление правительственных про филей взаимосвязи открытых систем. Среди правительственных профилей наиболее широко известны профили GOSIP (Government OSI Profile) Великобритании и США. GOSIP США стал обязательным стандартом в этой стране в 1990 г., после чего почти каждый основной постав щик продуктов и услуг информационных технологий в США объявил о наличии совместимых с GOSIP изделий: локальных и глобальных вычислительных сетей, реализации систем обработки сообщений, передачи файлов и т.д.

Свои собственные профили создали Франция, Швеция, Япония, Австралия, Гонконг, многие другие страны. Значительная часть работ по стандартизации Госпрофиля России взаи мосвязи открытых систем была проведена в 1995 — 99гг.

Следующий международный стандарт устанавливает общую классификацию, принципы построения и документирования профилей:

• ISO/IEC TR 10000-1:1998 — Information technology -- Framework and taxonomy of International Standardized Profiles - Part 1: General principles and documentation framework — общая часть стандарта;

• ISO/IEC TR 10000-2:1998 — Information technology - Framework and taxonomy of International Standardized Profiles — Part 2: Principles and Taxonomy for OSI Profiles — устанавливает принципы построения и классификацию профилей, создавае мых в рамках модели взаимосвязи открытых систем OSI;

• ISO/IEC TR 10000-3:1998 — Information technology - Framework and taxonomy of International Standardized Profiles - Part 3: Principles and Taxonomy for Open System Environment Profiles — устанавливает принципы построения и классификацию профилей, создаваемых в рамках модели сред открытых систем OSE (сп. п. 3.2.2).

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

3.2.2. Модель POSIX OSE Исторически модель POSIX развивалась от разработки интерфейса переносимой опера ционной системы через разработку профилей операционных сред до формулировки модели полноценной среды открытых систем, которая и получила название OSE (Open Systems Envi ronment).

Первая рабочая группа POSIX была образована в IEEE в 1985 г. на основе комитета по стандартизации операционных систем, ориентированного на ОС UNIX. Первоначально POSIX (Portable Operating System Interface for Computer Environments) — набор спецификаций для от крытых систем, разработанный Техническим Комитетом по операционным системам (TCOS) IEEE. Цель POSIX— выработка спецификаций единого, унифицированного, широко поддержи ваемого производителями интерфейса для операционных систем, обладающих свойствами пе реносимости между ними приложений, пользователей и данных. POSIX составляет большой набор документов, разрабатываемых множеством рабочих групп и комитетов. Основной набор соглашений и концепций для этих спецификаций сформулирован в документе IEEE "Guide to the POSIX Open Systems Environment, P1003.0". Он утверждён в качестве международных стан дартов:

• ISO/IEC 9945-1:1996 — Information technology - Portable Operating System Interface (POSIX) — Part 1: System Application Program Interface (API) [C Language];

• ISO/IEC 9945-2:1993 — Information technology -- Portable Operating System Inter face (POSIX) - Part 2: Shell and Utilities.

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

Некоторые результаты их работы утверждены в качестве официальных международных стандартов:

• ISO/IEC 14519:1999 — Information technology - POSIX Ada Language Interfaces — Binding for System Application Program Interface (API) — Realtime Extensions;

• ISO/IEC 15068-2:1999 — Information technology - Portable Operating System Inter face (POSIX) System Administration - Part 2: Software Administration.

Осмысление единства различных сторон разрабатываемой проблемы привело в итоге к формулировке единой нормативной модели (функциональной) среды открытых систем, извест ной как OSE (POSIX Open System Environment Reference Model).

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

либо как интерфейсы (форматы) и протоколы, либо как спецификации, относящиеся к перено симости или способности к взаимодействию.

Модель OSE не является уровневой (рис. 9). Она определяет три категории логических объектов: прикладное ПО (Application Software — AS), платформу приложений (Application Platform — АР) и внешнюю среду (External Environment — ЕЕ) — и два типа интерфейсов меж ду ними: интерфейсы прикладного программирования (Application Programming Interface — API) и интерфейсы внешней среды (External Environment Interface — EEI). Рассмотрим более подробно существо каждого из этих понятий модели.

Прикладное ПО — это часть программного обеспечения системы, специфичная для кон кретного применения пользователя. Она составляется из программ (исполняемых модулей, ко мандных файлов, интерпретируемых записей исходного кода и пр.), данных (рабочих данных пользователя, параметров приложений, установок среды экрана пользователя и пр.) и электрон ной документации (электронных документов, справок помощи (on-line help) и пр., но бумажная документация сюда не включается). Примерами прикладного ПО являются текстовые редакто ры, программы работы с электронными таблицами, программы обработки информации, храня щейся в базах данных, и многие другие программы, являющиеся специфически пользователь скими по отношению к той или иной платформе. Разработка, интерпретация и исполнение не которых специальных видов прикладного ПО может осуществляться при посредстве специали зированных сред, обеспечивающих определённый вид сервиса на платформе, например, систе мы управления базами данных (СУБД), системы автоматизированного проектирования (САПР), системы управления электронными таблицами и т.п. Одно или более приложений могут рабо тать на одной платформе одновременно, так как каждое приложение трактуется как независи мый логический объект.

Платформа приложений — это все остальные элементы системы обработки данных, за исключением прикладного ПО: аппаратное обеспечение, операционная система и другие ком поненты и подсистемы системного ПО. Приложения, требующие ресурсов платформы, запра шивают их путём вызова сервисов через API. Ресурсы, находящиеся вне платформы, запраши вают сервисы через EEI, и наоборот, EEI являются средствами, через которые сервисы дости гают ресурсов внешней среды. Внутренняя структура платформы в модели OSE преднамеренно не рассматривается. Это связано с тем, что в научных и промышленных кругах не существует единого мнения о составе, структуре и взаимосвязях различных модулей платформы.

Внешняя среда — это все компоненты информационной системы, находящиеся за преде лами данной системы обработки данных: пользователи, коммуникационные каналы и средства связи, сменные носители данных, устройства ввода /вывода. Интерфейс между АР и ЕЕ вклю чает форматы данных, интерфейсы и протоколы. По отношению к отдельно взятой вычисли тельной системе все другие вычислительные системы также выступают как объекты внешней среды.

Модель POSIX OSE определяет распределённую среду как множество платформ прило жений, которые могут взаимодействовать посредством коммуникационных механизмов, внеш них по отношению к платформам. Когда приложению необходимо связаться с другим прило жением на другой прикладной платформе, приложение подаёт запросы к своей локальной платформе через API. Так как АР взаимодействуют через коммуникационный интерфейс EEI, локальная АР транслирует эти запросы в соответствующие действия через EEI. OSE также оп ределяет однородный набор стандартных сервисов, предоставляемых пользователям платформ, в соответствии с требованиями спецификаций POSIX о переносимости и способности к взаимо действию. Данная модель делает попытку описать более полный подход к совместимости вы числительных систем, чем подход, основанный на многоуровневых архитектурах типа модели OSI.

Модель принята в качестве международного стандарта ISO/IEC TR 14252:1996 — Infor mation technology - Guide to the POSIX Open System Environment (OSE).

Классификация профилей, которые могут быть построены в рамках модели OSE, опре делена в стандарте ISO/IEC 10000 3.

Рис. 9. Модель POSIX OSE Для информационных нужд правительства США был создан профиль на основе модели OSE, который получил название профиля переносимости прикладных программ (Application Portability Profile). Он изложен в документе: Application Portability Profile. The U.S. Government Open Systems Environment Profile. Ver. 3.0. NIST Special Publication 500-230, 1996.

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

3.3. Модели сред открытых систем Если вычислительные системы полностью соответствуют спецификации POSIX 1003.1, это ещё не означает, что они образуют полноценную среду открытых систем с адекватным на бором сервисов и интерфейсов, которая может служить готовой базой для построения решений для потребителя. Модели сред открытых систем обращаются к проблеме построения открытой системы в комплексе. Примерами моделей, которые специфицируют полную среду открытых систем, являются модель САЕ (Common Application Environment) организации Х/Ореn и модель AES (Application Environment Specification) организации OSF.

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

• Модель САЕ (рис. 10) описана в документе XPG, разрабатывавшемся организацией Х/Ореn с 1984 г. Первая версия документа (XPG3) появилась в 1989 г., вторая версия (XPG4) — в 1992 г., последняя редакция документа— XPG5. Графическое изображение модели достаточ но условно и схематично, основную часть документа составляют спецификации. Впоследствии модель САЕ и спецификации XPG стали частью большого проекта организации The Open Group по выработке единой стандартной спецификации для всех операционных систем семейства UNIX и критериев оценки на соответствие ОС этим спецификациям (т.е. оценки того, является ли ОС «настоящей UNIX» или нет), который получил название Single UNIX.

Наименование документа первоначально расшифровывалось как Х/Ореn Portability Guide, но позднее такую трактовку названия было рекомендовано не использовать, так как со держание документа вышло за рамки проблемы обеспечения переносимости, а аббревиатура сохранена только в качестве идентификатора документа. XPG и его компоненты разработаны на основе кооперации и консенсуса между организациями пользователей, поставщиками вы числительных систем, организациями по стандартизации. Он включает спецификации, осно ванные как на стандартах де-юре, так и на стандартах де-факто.

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) различных сервисов каждой вычислительной платформы, входящей в распределённую систему, и достижения соглашений относительно этих свойств гетерогенность распределённой системы может быть структурирована контролируемым образом. Иными словами, все предос тавляемые пользователю и приложениям услуги распределённой системы оказываются струк турированными по категориям сервисов. Такого же принципа придерживаются и другие модели открытых распределённых вычислений.

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

Понятие "стандарты открытой распределённой обработки данных" (ODP — Open Dis tributed Processing standards) определяется в ISO 10746 как модель RM-ODP и те стандарты, ко торые прямо или косвенно согласуются с ним. Открытая распределённая обработка данных (open distributed processing)— распределённая обработка, сконструированная в соответствии со стандартами ODP. Система открытой распределённой обработки данных (ODP system)— сис тема, которая согласуется с требованиями стандартов ODP.

Основным содержанием модели RM-ODP является:

• разделение спецификации систем открытой распределённой обработки данных на пять так называемых "точек зрения" (viewpoints), упрощающих описание слож ных систем;

• набор общих средств описания систем с каждой из этих "точек зрения"— так на зываемые "языки" (languages);

• инструментарий для спецификации инфраструктуры распределённых систем че рез обеспечение так называемой "прозрачностей распределения" (distribution transparencies) — эти качества являются выборочными, для каждой конкретной системы могут достигаться только те из них, которые необходимы;

• принципы оценки соответствия систем критериям ODP. Современные распреде лённые системы обработки данных являются, как правило, сложными системами.

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

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

В соответствии с моделью RM-ODP система открытой распределённой обработки дан ных может быть описана с пяти "точек зрения":

• организационной (enterprise), которая рассматривает систему с точки зрения приклад ных целей её деятельности (бизнес-процессов);

• информационной, которая рассматривает систему с точки зрения информации, которую необходимо хранить и обрабатывать в системе — этот взгляд интересует аналитика при созда нии информационного наполнения системы;

• вычислительной, которая рассматривает систему как набор объектов, которые взаимо действуют через интерфейсы, т.е. производит функциональную декомпозицию системы;

• инженерной, которая рассматривает механизмы, поддерживающие распределённый характер системы — этот взгляд интересует системного программиста;

• технологической, которая детально рассматривает компоненты, из которых конструи руется распределённая система (аппаратное и программное обеспечение) — этот взгляд необ ходим системному интегратору при выборе технологий для создания работающей и экономиче ски эффективной системы обработки данных.

Дополнительно в модели описываются так называемые "функции ODP". Это собрания функций, требуемых от открытых распределённых систем обработки данных для поддержания нужд инженерной и вычислительной точек зрения. Основные группы функций — следующие:

функции управления, координации, обработки транзакций, репликации данных, защиты. По следние делятся на семь групп: функции контроля доступа, аудита, аутентификации, целостно сти, конфиденциальности, неотказуемости и управления ключами. Они детально рассматри ваются в стандарте ISO 10181 — OSI Security Frameworks for Open Systems и стандарте ISO 11770 — Security techniques — Key management.

Каждая "точка зрения" — это абстрактный взгляд, который охватывает вся систему в це лом. Они должны рассматриваться как "проекции" определённых свойств, определённых сто рон единого целого. Все "точки зрения" объединяет единый подход объектного моделирования, описанный в первой части стандарта.

Вторая часть стандарта содержит определение концепций и аналитический каркас для нормализованного описания произвольной распределённой системы обработки данных — это описательная модель.

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

2 — это предписательная модель.

Часть 4 содержит формализованную концепцию моделирования ODP. Каждая "точка зрения" интерпретируется в терминах различных стандартизованных формальных описатель ных методик. В этой же части стандарта устанавливается взаимосвязь с другой объектной мо делью — CORBA, разработанной организацией Object Management Group.

3.5.2. Модель TOGAF Модель TOGAF (The Open Group Architectural Framework) — документ, разрабатывае мый международной организацией The Open Group. TOGAF на сегодняшний день — наиболее полно представленная модель открытых распределённых вычислений. Фактически в ней обоб щается опыт всех предыдущих поколений моделей, которые могут быть выведены из неё как частные случаи. И, что особенно важно, TOGAF формулирует принцип невозможности по строения единой универсальной архитектуры для всех открытых систем, тем самым объясняя многообразие созданных моделей.

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

Основой модели TOGAF являются модель POSIX OSE, модель XAF организации Х/Ореn и модель управ ления информацией TAFIM Министерства обороны США. Вторая версия TOGAF появилась в 1996 г., третья — в 1997 г., четвёртая — в 1998 г. В конце 1999 г. вышла пятая редакция модели.

Модель TOGAF представляет больший интерес с инженерной точки зрения, чем очень абстрактная и формальная модель RM-ODP.

Документ состоит из четырёх основных частей. Первая часть — "введение" — описыва ет ключевые принципы, положенные в основу архитектуры современных информационных систем вообще и подхода модели TOGAF в частности. Вторая часть — "Метод разработки ар хитектур" (ADM — Architecture Development Method) — является ядром модели TOGAF. Она описывает шаги, которым необходимо следовать в разработке архитектуры любой информаци онной системы, содержит принципы конструирования архитектуры, формально описывает цикл разработки системы. ADM опирается на другую важную составляющую модели — "Фундамен тальную архитектуру" (TOGAF Foundation Architecture), которая изложена в одноимённой третьей части документа. Четвёртая часть документа — "Информационная база ресурсов" (Re source Base) — описывает набор инструментов и методик, доступных для использовании при практическом применении модели TOGAF и, в частности, методов ADM. Кроме того, документ содержит многочисленные приложения, примеры практического применения модели TOGAF, сравнение её с другими моделями.

Рассмотрим кратко те части документа, которые представляют наибольший интерес:

концепцию организационного континуума (ЕС), нормативную техническую модель и метод де композиции систем на так называемые "архитектурные взгляды".

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

Модель TOGAF утверждает: непрактично пытаться описать единую, универсальную ар хитектуру для открытых информационных систем. Неверно было бы строить одну архитектуру для всех целей и пытаться рассматривать информационную систему с одной точки зрения даже внутри одного предприятия, не говоря уже о существенно более сложных, глобальных инфор мационных системах. Существует непрерывное и бесконечное множество — континуум архи тектур, которые конструируются из каркасной модели посредством набора более узких моделей и строительных блоков. Такую каркасную модель под названием "архитектурный каркас" (ar chitectural framework —AF) описывает TOGAF.

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

Организационный континуум (ЕС — enterprise continuum) — комбинация двух взаимо связанных и взаимодополняющих друг друга концепций (рис. 15):

континуума архитектур (architecture continuum — А С) и континуума решений (solutions contin uum — SC). Под континуумом архитектур понимается широкий диапазон, непрерывное мно жество различных типов архитектур, которые могут быть синтезированы для всевозможных информационных систем на различных этапах их разработки, конструирования, выбора состав ных частей и моделей. Континуум архитектур отображает поступательное движение от абст рактного к конкретному, которое имеет место при создании архитектуры каждой информа ционной системы, на основе последовательной детализации и перехода от предельно общей модели (такой как TOGAF TRM) к архитектуре реальной информационной системы. В этом множестве архитектурных моделей может быть (условно) выделено несколько "опорных то чек":

• Фундаментальные архитектуры (foundation architectures — FA) — это архитектуры функций, которые поддерживаются всеми общесистемными архитектурами вместе взятыми (см. далее), т.е. все потенциально возможные функции, которые может выполнять какая бы то ни было информационная система. Иными словами, FA описывают полную вычислительную среду. Примером FA является фундаментальная архитектура самой модели TOGAF.

• Общесистемные архитектуры (common systems architectures — CSA) — это архитекту ры, которые руководят выбором и интеграцией определённых сервисов из FA для создания ар хитектуры, полезной для решения широкого класса взаимосвязанных задач: архитектура защи ты, архитектура административного управления, сетевая архитектура и т.п. Каждая из них не полна, если рассматривается с точки зрения общей функциональности информационной систе мы, но полна в рамках определённой проблемы: обеспечение безопасности информации, управ ляемости системы, организация телекоммуникационной среды и т.п. Решения, реализующие каждую такую архитектуру, составляют "строительные блоки" информационной системы. Они оказываются совместимыми с другими "строительными блоками" и могут быть использованы в любых комбинациях для создания функционально полных информационных систем. Примером служит архитектура модели IT DialTone, описывающая глобальную информационную среду на базе сети Internet (см. п. 3.5.3). Кроме того, The Open Group работает над несколькими архитек турными моделями такого класса, связанными с административным управлением системами, беспроводными коммуникациями, защитой данных.

• Индустриальные архитектуры (industry architectures — IA) — архитектуры, которые руководят интеграцией общесистемных компонентов (компонентов из архитектур класса CSA) с компонентами архитектур из класса IA и созданием целевых решений для потребителя внутри определённой отрасли, например, для банковской сферы, нефтехимической, газовой промыш ленности, авиакомпаний и т.д.

• Архитектуры организаций (organization architectures — ОА) описывают и руководят окончательным развёртыванием компонентов информационной системы, из которых слагается необходимое решение для определённой организации. Компоненты могут приобретаться поль зователем в виде готовых решений, соответствующих архитектурам перечисленных выше клас сов, либо разрабатываться им самим.

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

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

• Системные решения — это реализации CSA, составляемые из набора продуктов и ус луг, которые могут быть определённым образом оценены или сертифицированы на соответст вие некоторым требованиям или задачам, сформулированным в CSA, например, на соответствие критериям защищённости информации, высокой производительности и т.п.

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

• Решения для организаций — это реализации ОА, которые обеспечивают требуемые функции для данной, конкретной организации. Они содержат наибольшее количество неповто римого, уникального содержания, чтобы максимально полно отвечать требованиям всех дело вых процессов, должностных лиц и потребителей данной организации (предприятия, учрежде ния). Они могут сочетать внутри себя массовые, стандартные продукты и системы информаци онных технологий с единичными, разрабатываемыми под нужды одной, единственной ор ганизации.

Фундаментальная архитектура TOGAF — это архитектура общих сервисов и функций, обеспечивающих базис, на котором могут быть синтезированы более специфичные архитекту ры и архитектурные элементы. Она состоит из трёх компонент: нормативной технической мо дели (Technical Reference Model — TRM), информационной базы стандартов (Standards Informa tion Base — SIB) и информационной базы строительных блоков (Building Blocks Information Base — BBIB). TRM обеспечивает классификацию и моделирование общих сервисов платфор мы. SIB представляет собой базу данных стандартов. Она может быть использована для опреде ления конкретных сервисов и других компонент специфичной архитектуры, которая выводится из общей фундаментальной архитектуры TOGAF. Наконец, BBIB содержит информацию о строительных блоках, которые могут быть использованы в конструировании архитектур.

TRM и SIB не являются строго обязательными для любой информационной системы. Потребитель вправе выбирать или разрабатывать такую техническую модель своей системы и такие правила её организации, которые лучше всего удовлетворяют его запросам. TRM и SIB, специфицированные The Open Group, отображают сложив шуюся общемировую практику создания крупномасштабных информационных систем. TRM — достаточно общая модель, поэтому она может быть рекомендована как каркасная модель информационной системы в подавляющем большинстве случаев, за исключением, быть может, специализированных закрытых информационных систем: бор товых систем, систем управления технологическими процессами. При условии, если техническая модель и набор используемых стандартов совместимы между собой, TOGAF ADM остаётся действительным, каковы бы ни были их особенности.

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

Пять основных элементов TRM: прикладное ПО (AS), платформа приложений (АР), ком муникационная инфраструктура, интерфейс платформы приложений (Application Platform Inter face — API), интерфейс коммуникационной инфраструктуры (Communications Infrastructure In terface — CII).

Как и в модели OSE, в TOGAF TRM не рассматривается конкретная структура платфор мы приложений. Основное отличие, однако, состоит в том, что последняя специфицирует пол ный набор стандартных сервисов из двенадцати групп сервисов, которые могут предоставлять ся платформой приложениям в любой потенциально возможной информационной системе. Реа лизация того или иного сервиса в конкретной системе определяется целями и задачами этой системы. Кроме того, определяются понятия "качества сервисов". Они применяются ко всем категориям сервисов и влияют на способ реализации и взаимодействия этих сервисов в кон кретной информационной системе. Качества сервисов, размещённые по четырём категориям, описывают свойства, которые должны быть обеспечены однородно и взаимосвязанно через все категории сервисов, например, безопасность сервисов.

Рис. 16. Нормативная техническая модель TOGAF "Внешняя среда" в ранних версиях модели TOGAF понималась точно так же, как и в мо дели OSE. Это — все внешние объекты, с которыми АР обменивается информацией, причём обмен производится через ЕЕ1. В дальнейшем (очевидно, под влиянием модели IT DialTone — см. п. 3.5.3) под "внешней средой" стала подразумеваться прежде всего коммуникационная ин фраструктура, к которой "подключена" рассматриваемая информационная система. Вероятно, это можно мотивировать следующим образом. Предполагается, что в подавляющем большин стве случаев информационные системы не являются изолированными. Они имеют выход во "внешний мир", в том числе в сеть Internet — одну для всех пользователей информационных систем. Все же остальные объекты внешней среды: пользователи и средства обмена данными — свои для каждой информационной системы. К тому же пользователи рассматриваются во всех моделях информационных систем опосредованно — постольку, поскольку они сами явля ются "средствами" хранения, ввода/вывода и обработки информации, а средства обмена дан ными имеют на сегодняшний день существенно меньшее значение, чем коммуникационные средства.

В TRM даётся детальная классификация сервисов АР. Перечислим основные группы, по которым размещаются сервисы в модели.

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

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

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

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

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

• Сервисы пользовательского интерфейса предназначены для человеко-машинного взаимодействия и включают текстовый интерфейс, графический интерфейс, сервисы печати, "помощь" в режиме on-line и др. сервисы.

• Сервисы размещения ресурсов и директориальные сервисы (location and directory) включают сервисы именования и адресного поиска ресурсов, директориальные сервисы, серви сы фильтрации информации, регистрации и учёта.

• Сервисы программной инженерии (software engeneering) — это инструменты для разра ботки и поддержки сложных комплексов ПО: языки программирования, сервисы связывания объектного кода, средства автоматизации проектирования ПО (CASE-системы), сервисы проек тирования пользовательского интерфейса, сервисы отображения интерфейсов с языков про граммирования на сервисы АР и др.

• Сервисы обработки транзакций предназначены для поддержки обработки информации в транзакциях в режиме on-line.

• Сервисы защиты — это особая группа сервисов, так называемые межкатегориальные сервисы. Такое название они получили потому, что механизмы их реализации могут быть ча стью множества сервисов различных категорий. Эта категория включает в себя сервисы иден тификации и аутентификации, сервисы контроля точек входа в систему, сервисы аудита, серви сы контроля доступа, объектные сервисы контроля доступа, сервисы обеспечения неотказуемо сти, сервисы шифрования, сервисы обеспечения доверенных каналов связи (trusted communica tion services), сервисы доверенного восстановления данных (trusted recovery services), сервисы управления защитой. Сервис шифрования является основой ряда других сервисов, таких как сервисы идентификации и аутентификации, сервисы контроля доступа, сервисы контроля точек входа в систему и др.

• Сервисы административного управления системами и сетями. Их назначение — эф фективное управление ресурсами информационной системы для достижения целей среды от крытых систем. В эту группу входят сервисы управления пользователями, конфигурацией, про изводительностью, доступностью и надёжностью системы, учётом деятельности пользователей, безопасностью системы, сервисы управления сетями, дисками, печатью, резервным копирова нием и восстановлением информации, инсталляцией и лицензированием ПО, ёмкостью памяти и некоторые другие.

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

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

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

Объектное обеспечение сервисов не выделяется как отдельная категория в TRM, так как все индивидуальные объектные сервисы включены в различные другие сервисные категории.

Объектные сервисы обеспечивают способы создания, размещения, именования объектов и свя зывания их в распределённой среде.

Модель выделяет следующие категории "качеств", присущих сервисам:

• доступность, куда входят понятия управляемости, обслуживаемости, производитель ности, надёжности, восстанавливаемости, удобства размещения сервисов;

• гарантированность, куда включаются безопасность, целостность и уровень доверия к системе;

• используемость (лёгкость действий пользователей);

• адаптируемость, а именно способность к взаимодействию, масштабируемость, пере носимость, расширяемость функций системы.

Очень важным элементом модели является SIB — это систематизированное собрание большого числа стандартов, наработанных за долгие годы различными международными орга низациями, апробированных или широко принятых в промышленности, выбранных членами The Open Group в качестве ядра для реализации открытых информационных систем. В SIB все стандарты классифицированы по категориям сервисов, соответствующих TRM.

Так как современные информационные системы являются сложными системами, для описания тех или иных аспектов системы используются различные средства, различные инст рументы описания (ср. с моделью RM-ODP — п. 3.5.1).

Исторически сложилось несколько довольно самостоятельных отраслей, связанных с информационными технологиями. В связи с этим модель TOGAF вводит несколько так назы ваемых "взглядов" (views) на информационную систему. Напомним, что в RM-ODP также есть понятия "точек зрения" (viewpoints), под которыми понимается "набор концепций, структур и правил, формирующих соответствующий язык [описания]": организационной, информацион ной, вычислительной, инженерной и технологической. "Точки зрения" RM-ODP не вполне сов падают со "взглядами" модели TOGAF. Более корректно, по-видимому, сравнивать их с раз личными уровнями детализации, которые используются моделью TOGAF для описания "строи тельных блоков".

Функциональный взгляд (function view) рассматривает операционные аспекты системы, отталкиваясь от описания существующей среды информационных технологий и требований к функциям системы. Это взгляд со стороны специалиста в той предметной области, нужды ко торой обслуживает система.

Взгляды на реализацию (implementation views)— это описание строения системы с точки зрения различных специалистов по информационным технологиям:

• Взгляд на административное управление системой (management view) — это рассмот рение системы с точки зрения лиц, ответственных за её эксплуатацию: долгосрочное планиро вание целей деятельности информационной системы, оперативно-диспетчерское управление, конфигурирование и администрирование ПО и др.

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

• Взгляд на строение программного обеспечения (builder's view) охватывает те стороны создания и функционирования информационной системы, которые важны для разработчиков ПО: переносимость, способность к взаимодействию, методы разработки сложных программных систем и пр.

• Взгляд на управление данными (data management view) изучает процессы хранения, дос тупа, обработки, архивации, передачи данных, в том числе средства и методы систематизиро ванного хранения и управления данными, защиту, администрирование данных.

• Пользовательский взгляд (user view) включает эргономические аспекты работы пользо вателя: удобство, простоту видения системы, среду работы пользователей.

Физические взгляды (physical views) — это взгляды на систему с точки зрения физиче ской её организации и размещения в пространстве:

• Взгляд на организацию вычислений (computing view) — это множество различных спо собов, которыми программные и аппаратные компоненты могут быть собраны в работоспособ ную структуру. Здесь рассматриваются различные модели организации вычислений: «клиент - сервер», иерархическая, одноранговая («peer-to-peer»), объектная модель, мобильные вычисле ния.

- Коммуникационный взгляд (communications view) рассматривает географический аспект организации системы, её коммуникационную инфраструктуру. Последняя рассматривается здесь с двух позиций:

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

- логически — как состоящая из пяти архитектурных уровней на базе расширенной мо дели ISO/OSI: уровня передачи (transmission level) — ниже физического уровня модели OSI, уровня сетевых переключений (network switching level) — с 1-го по 3-й уровень OSI, уровня обмена данными (data exchange level) — с 4-го по 7-й уровни модели OSI, сервисов прикладно го уровня модели OSI и уровня прикладных программ.

3.5.3. Модель IT DialTone IT DialTone — это каркасная модель архитектуры глобальной информационной системы для бизнес-приложений на базе общей коммуникационной инфраструктуры глобального мас штаба: глобальных телекоммуникационных сетей, виртуальных частных сетей (VPN), откры тых общедоступных сетей, в пределе — на основе сети Internet. Эта модель представляет инте рес прежде всего как первая попытка теоретического описания глобальной информационной среды, сформировавшейся на базе всемирной сети Internet (рис. 17).

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

Каждая информационная система предоставляет своим пользователям определённый на бор ресурсов и услуг. Для систем различного масштаба он различен. Строение и функциониро вание каждой из них подчиняется своему набору условий. Для предприятия это может быть по литика управления, политика безопасности предприятия. В масштабах предприятий-партнёров (например, в пределах одной отрасли, одного объединения предприятий) — соглашения и дого вора. В масштабах сети Internet — законы, международные соглашения, стандарты. Выделение таких "ступеней" вполне обоснованно: они проявляются и в объёме информационных потоков, и в структуре хранимых данных, и в организации управления, и в методах и средствах защиты информации. Так, для самого нижнего уровня организации, соответствующего отделу предпри ятия, лаборатории, небольшой группе работников, чаще всего представленного локальной се тью, характерно наличие общих единых баз данных, средств совместной (групповой) работы над проектами, схожий состав программного, а часто и аппаратного обеспечения рабочих мест пользователей. Для информационных систем больших организационных структур (крупная корпорация, министерство, отрасль промышленности, банковская система) характерны боль шая территориальная распределённость, гетерогенность среды информационных технологий, отсутствие едино- Рис. 17. Модель информационной среды на основе сети Internet Модель IT DialTone, как отмечалось в п. 3.5.2, является примером общесистемной архи тектуры и согласована с моделью TOGAF. Основной магистралью для передачи данных в гло бальной информационной системе, согласно модели IT DialTone, является глобальная комму никационная инфраструктура (IT DialTone Core Infrastructure), — совокупность некоторого, возможно, большого или даже неопределённого числа взаимосвязанных и взаимодействующих между собой глобальных, региональных и локальных коммуникационных сетей. Ком муникационная инфраструктура характеризуется следующими качествами:

• Повсеместностью. Она должна предоставлять одни и те же или схожие возможности в любой точке подключения к ней. Все пользователи должны иметь возможность использовать её одинаковым или почти одинаковым образом.

• Единообразием базовых услуг. Нет необходимости в том, чтобы она обеспечивала большое количество разнообразных возможностей для своих пользователей: достаточно огра ниченного набора услуг, который предоставляется всем единообразно. Например, фрагмент информации должен передаваться точно по обозначенному адресу за предсказуемый период времени при условии обеспечения надёжности и безопасности доставки. На базе этих услуг можно сформировать все остальные возможности.

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

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

На сегодняшний день наиболее полно удовлетворяет перечисленным условиям комму никационная архитектура TCP/IP, которая стала стандартом в масштабах сети Internet.

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

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

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

В остальном архитектура модели IT DialTone похожа на модель TOGAF: она включает нормативную архитектурную модель (Architecture Reference Model — ARM) — (в TOGAF — TRM), SIB и ADM являются общими для обеих моделей. Согласно ARM, компоненты среды IT DialTone разделяются на три блока:

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

• сервисы распределённой системы предоставляют услуги, которые создают условия для "прозрачной" работы приложений;

• коммуникации и платформы формируют основание, на котором строятся распределён ные среды.

Термин "платформа" употребляется в литературе в различных значениях. В модели IT DialTone платформа определяется как самодостаточный (минимальный) набор функциональ ности, который должен быть представлен необходимо зависимыми между собой компонентами.

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

Несколько отличается состав категорий сервисов, предоставляемых системой (рис. 18):

• сервисы представления и взаимодействия с пользователем;

• сервисы интеграции ПО;

• сервисы управления информационными потоками;

• сервисы безопасности;

• сервисы управления;

• директориальные сервисы и сервисы размещения ресурсов;

• сервисы данных;

• сервисы распределённых вычислений;

• коммуникационные сервисы;

• сервисы платформ.

Приложения подразделяются на два класса: бизнес-приложения и инфраструктурные.

Функции бизнес-приложений выходят за рамки модели IT DialTone и потому в ней не рассмат риваются. Инфраструктурные приложения обеспечивают общецелевые бизнес-функции, бази руясь на сервисах инфраструктуры. С течением времени некоторые бизнес-приложения имеют тенденцию переходить в разряд инфраструктурных, а те, в свою очередь, в разряд сервисов сис темы.

Многие положения модели IT DialTone оказали влияние на развитие модели TOGAF, в основном её пятой версии.

Рис. 18. Нормативная архитектурная модель IT DialTone 3.6. Подходы ведущих фирм-производителей к организации распределённых сред Мы не будем подробно останавливаться на моделях и решениях, предложенных даже ведущими фирмами-производителями и поставщиками решений в области информационных технологий: эти фирмы очень динамично развиваются, и информация об их разработках до вольно быстро устаревает. Документы организаций по стандартизации отличаются гораздо большей стабильностью и преемственностью. Кроме того, документы фирм зачастую бывают необъективны, так как прежде всего имеют целью продвижение на рынок и рекламу своих соб ственных разработок. Актуальную информацию по разработкам крупных фирм всегда можно получить, обратившись к страницам соответствующих фирм в сети Internet.

В целом среди различных фирм наблюдается два различных подхода к разработке архи тектур распределённых сред: "от моделей" и "от продуктов".

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

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

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

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

Корпорация IBM традиционно являлась одним из ведущих идеологов открытых распре делённых вычислений. В разное время фирмой IBM предпринимались в различной степени удачные попытки теоретически сформулировать концепцию распределённых вычислительных сред.

В п. 3.4 уже рассматривалась основная модель распределённых вычислительных сред Open Blueprint, предложенная фирмой в 1994 г. Это очень удачная модель распределённых вы числительных систем масштаба предприятия, богатая различными возможностями. В ней впер вые были сформулированы многие важные принципы распределённых вычислений. Ей пред шествовала «промежуточная» модель Networking Blueprint. Ещё ранее фирмой предлагалась модель SAA (System Applications Architecture), которая оказалась неудачной, так как не явля лась архитектурой (см. выше), а лишь содержала перечень продуктов и поддерживаемых фир мой типов платформ.

Разработки фирмы IBM опираются на мощную технологическую базу: несколько типов аппаратно-программно платформ (мэйнфреймы S/390, системы среднего уровня AS/400, рабо чие станции RS/6000 с UNIX-подобной операционной системой AIX, персональные системы), несколько линий программных продуктов (WebSphere, VisualAge, DB2, MQSeries, SecureWay, Lotus, Tivoli).

В 1998 — 99 гг. IBM одной из первых сформулировала концепцию глобальной инфор мационной среды для электронного бизнеса, которая в документах фирмы получила название NCF - Network Computing Framework.

Корпорацией DEC (Digital Equipment Corp.) до её поглощения корпорацией Compaq ве лась большая работа по формированию принципов и моделей организации распределённых вы числительных сред масштаба предприятия. Модель корпорации DEC получила название NAS — Network Application Support. Она появилась в 1987г., была одной из первых подобных архи тектур, к 1993 г. модель была тщательно разработана. NAS — полновесная, хотя и не такая яс ная и исчерпывающая как Open Blueprint, архитектура, которая позволила строить открытые, масштабируемые распределённые среды. Именно в документах DEC появился и стал широко использоваться термин "middleware" для обозначения ПО среднего уровня, реализующего сер висы распределённой платформы. В дальнейшем многие компоненты модели NAS были "взяты на вооружение" корпорацией Microsoft, в том числе при разработке операционной системы Windows NT.

Фирма Hewlett-Packard не заявляла официально о создании архитектуры распределён ных вычислительных сред. Она декларирует подход, основанный на решениях для конкретных организаций, которые включают продукты фирмы HP. На самом деле при создании своих ре шений HP пользуется моделью, которая имеет название EOSA (Emerging Open Systems Archi tecture), её создание относится к 1992 — 95 гг.

Фирма Novell также разрабатывала свою модель ПО распределённой вычислительной среды масштаба предприятия, которая имела название AppWare, но фирма отказалась от неё в 1994 г. и сконцентрировалась на разработки сетевой ОС Novell NetWare.

Фирма Apple выдвинула в 1989 г. модель VITAL (Virtually Integrated Technical Architec ture Lifecycle), которая не претендует быть целостной архитектурой распределённой среды, а скорее посвящена организации клиент-серверных вычислений внутри такой среды. Примени мость этой модели также ограничена поддержкой решений для конкретных предприятий. Мо дель не придерживается до конца принципов открытости: она представляет собой смесь откры тых и неспецифицированных интерфейсов. В разработке решений фирма Apple поддерживала связь с DEC.

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

В 1992 — 95 гг. модель архитектуры программного обеспечения Microsoft носила назва ние WOSA (Windows Open Services Architecture). В рамках этой модели архитектура Microsoft может быть представлена как сумма имеющихся продуктов линии Windows с поддержкой спе цификации OLE. Эта модель, однако, не могла считаться полноценной архитектурой для рас пределённых систем масштаба предприятия. Она охватывала далеко не все типы сервисов: в основном те, которые требуются в офисных приложениях. Впоследствии она была замещена единым стандартным интерфейсом OLE (Object Linking and Embedding) для взаимодействия приложений между собой и с сервисами операционной системы. Сейчас OLE — это целостная компонентная технология, в которую на нижнем уровне входит СОМ (Component Object Model) — не зависящий от языка программирования, двоичный стандарт для обеспечения способности к взаимодействию программных компонент. Название OLE сохранено только как аббревиатура, не наполненная смыслом.

В настоящее время стратегия фирмы Microsoft обеспечения совместимости своих про граммных продуктов с изделиями других фирм основывается на четырёхуровневой модели: ин теграции сетей, данных, приложений и управления. ПО фирмы Microsoft включает ряд базовых стандартов, обеспечивающих способность к взаимодействию, таких как поддержка коммуника ционной архитектуры TCP/IP, эмуляция удалённого терминала, поддержка протоколов FTP, HTTP, Telnet, интеграция системы доменных имён (DNS), имеются дополнительные продукты для взаимодействия с ОС семейства UNIX, NetWare. Совместимость данных обеспечивается за счёт использования интерфейса ODBC (Open DataBase Connectivity), что позволяет разработчи кам приложений иметь доступ к данным безотносительно и конкретным базам данных или ОС, на которых они работают. Совместимость управления системами достигается на основе прото кола SNMP из стека ТСРЛР. Вероятно, решающее значение для Microsoft имеет такой аспект открытости как переносимость пользователей. Семейство ОС Windows сохраняет и совершен ствует хорошо разработанный пользовательский интерфейс. Постепенно расширяется диапазон вычислительных систем, на которых работают ОС семейства Windows, ранее преимущественно рассчитанные на персональные компьютеры для офисной работы.

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

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

Ссылки и замечания к гл. 3:

п. 3.1:

За основу классификации моделей взята классификация из [23, ch.3], которая расширена с учётом моде лей, появившихся за последние годы (1995 — 2000 гг.). Диаграммы с изображением графических моделей архитек тур (рис. 7 — 12, 14 в пп. 3.1 — 3.4) приводятся, с небольшими изменениями, по этой работе с переводом названий всех компонентов моделей на русский язык. При написании данного параграфа использованы также материалы [19].

п. 3.2:

Наряду с реферативным изложением каждой модели в пп. 3.2 — 3.5 даётся краткий обобщённый анализ каждого класса моделей и взаимосвязей между ними.

Характеристика модели взаимосвязи открытых систем ISO OSI [12] составлена по материалам сборни ка [3], а также [20, пп. 7.6 — 7.8;

23, п. 3.4.1].

Pages:     | 1 || 3 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.