WWW.DISSERS.RU

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

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

Pages:     || 2 | 3 |
-- [ Страница 1 ] --

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

Стандартизация информационных технологии в аспекте защиты информации в открытых системах. - М.: МИФИ, 2000. - 135 с.

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

Предназначено для студентов факультетов «Б» и «К» МИФИ, для руководства и адми нистраторов центров защиты информации и для слушателей курсов повышения квалификации сотрудников банковской сферы.

СОДЕРЖАНИЕ Введение 1. Основные элементы технологии открытых систем 1.1. Среда информационных технологий 1.2. Концепция открытых систем 1.3. Роль стандартов в технологии открытых систем. Основные группы стандар тов и организации по стандартизации 2. Переносимость и способность к взаимодействию 2.1. Основные аспекты совместимости систем 2.2. Переносимость 2.3. Способность к взаимодействию 3. Основные модели открытых систем и их развитие 3.1. Классификация моделей 3.2. Базовые стандартные модели 3.2.1. Модель ISO OSI 3.2.2. Модель POSIX OSE 3.3. Модели сред открытых систем 3.4. Модели распределённых систем 3.5. Обобщённые модели открытых распределённых вычислений 3.5.1. Модель RM-ODP 3.5.2. Модель TOGAF 3.5.3. Модель IT DialTone 3.6. Подходы ведущих фирм-производителей к организации распределённых сред 4. Стандарты и модели защиты информации в открытых системах 4.1. Защита информации в модели ISO OSI. Стандарты ISO 4.2. Защита информации в модели POSIX OSE 4.3. Модели защиты информации в документах The Open Group Заключение. Роль стандартизации в развитии информационных технологий ВВЕДЕНИЕ Интенсивное развитие современных технологий обработки данных привело к появлению и развитию сложного комплекса научно-технических дисциплин, получившего название "ин формационные технологии". Под этим термином обычно понимают совокупность научных ме тодов, инженерных, технических приёмов и технологических решений, связанных с процессом обработки информации при помощи электронного оборудования (компьютеров, коммуникаци онных устройств, сетей связи, носителей данных), системного и прикладного программного обеспечения.

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

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

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

• переходом от централизованной к полностью распределённой модели обработки данных;

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

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

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

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

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

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

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

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

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

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

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

В данной работе предпринимается попытка анализа состояния и развития стандартиза ции информационных технологий на современном этапе, связанных преимущественно с поня тиями технологий открытых систем и распределённых вычислительных сред. Работа не ставит целью подробное изложение стандартов и моделей информационных технологий. Здесь рас смотрены главные вопросы, которые позволяют ориентироваться в большом числе документов, выбирать необходимые для решения более конкретных задач. За 1990-е гг. состояние между народной стандартизации информационных технологий существенно изменилось. Количество стандартов многократно возросло, а их качественный состав принципиально изменился, появи лись систематизированные собрания стандартов. К сожалению, отечественные издания по этой тематике довольно малочисленны [2,3,6,7], а столь значительные изменения пока практически не нашли отражения в отечественной литературе. Данная работа пытается восполнить этот пробел: в ней на основе зарубежных публикаций и материалов рассматривается состояние стандартизации на 1999 — 2000 г.

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

Глава 2 посвящена более детальному рассмотрению основных качеств, которыми харак теризуются открытые системы: переносимости и способности к взаимодействию.

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

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

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

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

Глава 1. ОСНОВНЫЕ ЭЛЕМЕНТЫ ТЕХНОЛОГИИ ОТКРЫТЫХ СИС ТЕМ 1.1. Среда информационных технологий Практически любая крупная современная организация (предприятие, учреждение) неза висимо от профиля своей деятельности в той или иной мере осуществляет обработку информа ции, необходимой для функционирования этой организации, т.е. нуждается в информационном обеспечении своей деятельности. Под информационным обеспечением деятельности предпри ятия, учреждения или другой организации понимается создание, организация и обеспечение функционирования такой системы сбора, хранения, обработки и выдачи информации, которая обеспечивала бы предоставление всем подразделениям и должностным лицам организации всей необходимой им информации в требуемое время, требуемого качества и при соблюдении всех устанавливаемых правил обращения с информацией.

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

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

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

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

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

• Разнородность (гетерогенность).

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

• централизованные технологии, мэйнфреймы (mainframe) — многопользовательские многозадачные вычислительные системы высокой производительности с очень развитым набо ром возможностей по обработке информации, пользовательскими сервисами и возможностями управления системой (например, система IBM S/390);

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

• RISC-технологии (reduced instructions set computer) — попытка приблизить производи тельность, достигнутую мэйнфрейм-технологиями, на системах более низкого уровня (POWER, RS/6000);

• системы среднего уровня (midrange systems) — попытка оптимизировать структуру вы числительной системы к требованиям сред приложений с не очень высокими требованиями, например, для среднего бизнеса, промышленных предприятий (VAX, AS/400);

• персональные системы — попытка перенести традиционные технологии обработки данных, ориентированные на бизнес, в повседневную практику индивидуальных пользователей (Intel 80х86, Motorola 600х0, Alpha);

• суперкомпьютеры - многопроцессорные вычислительные комплексы очень высокой производительности, обладающие параллелизмом аппаратной архитектуры и требующие спе циального программного обеспечения, предназначенные, как правило, для решения специаль ных классов задач с очень интенсивными вычислениями (IBM SP1 и SP2, CRAY, NEC, Fujitsu, Hitachi, «Эльбрус» и др.).

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

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

• среды непрограммируемых терминалов (NPT);

• среды локальных сетей (LAN);

• среды глобальных сетей (WAN);

• одно- или многоуровневые серверные среды;

• другие взаимосвязанные системы, в том числе среды со связью "точка — точка".

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

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

Гетерогенность может принимать различные формы:

большое разнообразие техники, используемой на рабочих местах пользователей: рабо чие станции, терминалы, персональные системы, мобильные пользователи и др.;

• различные аппаратные архитектуры и платформы;

• множество операционных систем;

• множество коммуникационных сетей и протоколов;

• многочисленные версии одного и того же аппаратного и программного обеспече ния;

• множество поколений одних и тех же приложении.

Причины гетерогенности в среде информационных технологий многообразны. Они мо гут быть следующими:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• неспособности управлять системой из одной точки, расширять (масштабировать) систему, обнаруживать источники сбоев и неполадок и устранять их;

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

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

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

• переносимости (portability) приложений, данных и пользователей между систе мами;

• способности к взаимодействию (interoperability) между системами, включая управление системами и использование ресурсов множества систем.

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

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

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

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

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

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

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

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

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

Существует несколько определений понятия "открытая система" (или "среда открытых систем"). Наиболее известными и широко принятыми являются следующие четыре определе ния, данные Международным институтом инженеров по электронике и электротехнике (IEEE), Всемирной независимой организацией по открытым системам Х/Ореn, международным кон сорциумом OSF и Международным телекоммуникационным союзом ITU.

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

По определению Х/Ореn, открытые системы — это "среда программного обеспечения, сконструированная и реализованная в соответствии со стандартами, которые являются незави симыми от поставщиков и общедоступными".

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

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

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

• понятие "открытая система" относится преимущественно к программному обеспече нию;

• основная цель открытых систем состоит в обеспечении:

а) способности к взаимодействию между гетерогенными системами;

б) переносимости приложений, пользователей и данных между гетерогенными системами;

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

• стандарты играют ключевую роль в открытых системах.

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

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

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

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

Стандарты позволяют замаскировать неоднородность объектов стандартизации, предос тавляя такую модель, которая помогает избежать различий в представлении, описании и реали зации этого объекта. В отсутствии такой модели каждый разработчик был бы вынужден созда вать свою собственную. Таким образом, стандарт уменьшает потенциальную разнородность объекта стандартизации. Как будет видно далее, многие стандарты являются именно абстракт ными моделями различных аспектов обработки данных, например, общеизвестная модель ISO OSI.

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

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

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

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

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

Стандарты де-юре характеризуются следующими особенностями:

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

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

• Продукты появляются позже, чем стандарты (за исключением случаев, когда ут верждён стандарт де-факто).

• Стандарты открыты для всех разработчиков и производителей на равных услови ях.

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

• Эти стандарты определяют долговременные направления развития, независимые от конкретных продуктов и решений.

Стандарты де-факто отмечены следующими особенностями:

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

• Существует опыт применения этих стандартов, хорошо известны их сильные и слабые стороны.

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

• Истинная "открытость" этих стандартов всегда может быть подвергнута сомне нию.

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

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

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

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

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

Различается три типа организаций, разрабатывающих стандарты:

• Национальные и международные организации по стандартизации. К этой категории относятся, например, ISO, IEC, ITU, IEEE (международные), Госстандарт РФ, ANSI, NIST (США) и др. Эти организации являются единственным источником стандартов де-юре, тогда как остальные два типа организаций производят только стандарты де-факто.

• Консорциумы и альянсы фирм-производителей. К этой категории относятся OSF, Unix International, Power-Open и др. Они способствуют созданию стандартов де-факто, распространяя спецификации и технологии на множество производителей. Однако, поддержка технологий та ким образом может быть недостаточной, если она не соответствует требованиям организаций пользователей.

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

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

• Международная организация по стандартизации (ISO — International Organiza tion for Standardization). ISO — международная неправительственная организация. Как записа но в её Уставе, она "осуществляет разработку международных стандартов и координирует дея тельность в области стандартизации с целью содействия взаимному сотрудничеству в важных областях человеческой деятельности: интеллектуальной, научной, технологической и эко номической".

Сейчас в состав ISO входят около 130 государств. Каждое государство участвует в работе ISO через свой националь ный орган стандартизации. Государства могут быть членами, членами-корреспондентами или членами-подписчиками ISO. Ка ждое государство-член ISO возглавляет один или несколько технических комитетов или подкомитетов. Официальными языка ми ISO являются английский, русский и французский. СССР был одним из учредителей ISO в 1946 г.

Сфера ответственности ISO за разработку стандартов охватывает все области техники, за исключением электроники и электротехники (это — прерогатива IEC). Структурно ISO состоит из Технических комитетов (ТС), которые делятся на Подко митеты (SC). Для обеспечения работы по подготовке стандартов внутри подкомитетов образуются Рабочие группы (WG).

Группы, работающие над решением конкретной задачи, называются TF (Task Force). Каждый разрабатываемый стандарт про ходит последовательно несколько стадий:

• NWI — New Work Item;

• WD — Working Draft;

• CD — Committee Draft;

• DIS — Draft International Standard;

• IS — International Standard.

Согласованный проект принимается в качестве стандарта, если за него проголосовало не менее 75% государств членов ISO.

• Международная электротехническая комиссия (IEC — International Electrotechni cal Commission) — специализированная международная организация, которая разрабатывает стандарты, связанные с электроникой, электротехникой и информационными технологиями.

IEC — одна из первых международных организаций, начавших процесс разработки международных стан дартов. Образована в 1906 г. В настоящий момент она дополняет деятельность ISO в области информационных технологий. IEC совместно с ISO сформировала Объединённый технический комитет JTC1 (Joint Technical Com mittee) для координации разработки стандартов по информационным технологиям.

• Международный телекоммуникационный союз (ITU — International Telecommuni cations Union).

ITU — одна из первых международных организаций. Союз был основан в 1865 г., до 1947 г. носил назва ние Телеграфного союза. Сейчас входит в систему органов ООН. Объединяет около 160 стран. В структуру ITU входят Международный консультативный комитет по радиосвязи (ITU-R, до 1993 г. — CCIR) и Международный консультативный комитет по телефонии и телеграфии (ITU-T, до 1993 г. — CCITT). Название последнего было заменено на ITU/TSS (Telecommunications Standard Sector), но более известным остаётся предыдущее. Стандарты ITU официально называются "рекомендациями". Они принимаются на сессиях ITU, которые проходят один раз в четыре года. Разработка стандартов, таким образом, занимает весьма длительное время.

ITU занимается стандартизацией открытых телекоммуникационных сервисов. ITU-T вы пускает 25 серий рекомендаций (обозначаемых буквами латинского алфавита от А до Z), каж дая из которых насчитывает до нескольких десятков или сотен рекомендаций. Наиболее из вестны серии, посвящённые стандартизации взаимодействия открытых систем, сетям ISDN и др. Многие рекомендации ITU были приняты в качестве стандартов ISO.

• Международный институт инженеров по электронике и электротехнике (IEEE — The Institute of Electrical and Electronics Engineers).

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

IEEE разрабатывает три типа спецификаций:

• стандарты — спецификации с предписательными требованиями;

• рекомендованные практики — спецификации действий, процедур и практик, ре комендуемые IEEE;

• руководства — описывают спектр альтернативных возможностей без рекоменда ции определённого подхода.

Два наиболее известных стандарта IEEE: стандарты серии 802 по локальным вычисли тельным сетям и стандарты POSIX.

• Internet Architecture Board (IAB) — неофициальная организация, создающая систему стандартов для среды Internet.

IAB основана в 1992 г. Состоит из двух подразделений: IETF (Internet Engineering Task Force), которая от ветственна за разработку краткосрочных инженерных документов, и IRTF (Internet Research Task Force), которая занимается долгосрочными исследованиями. IAB ведёт работу в девяти функциональных областях: приложения, сервисы Internet, управление сетями, операционные требования, интеграция с OSI, маршрутизация, безопасность, транспортные сервисы, сервисы пользователя.

Наиболее известными документами этой организации является серия так называемых RFC (Request for Comments). RFC различны по своему статусу: некоторые из них являются ут верждёнными стандартами для среды Internet, другие рекомендованы к использованию, но не являются обязательными, третьи вообще служат справочными материалами. Значительная часть из них является стандартами де-факто. RFC создавались с целью определения минималь но необходимого набора спецификаций для обеспечения нормальной работы глобальной ин формационной среды. Сегодня этот "минимум" включает уже более двух с половиной тысяч стандартов.

• The Open Group (TOG) — образована в 1993 г. в результате слияния консорциума OSF и организации Х/Ореn как международная некоммерческая организация с целью содействия развитию технологий открытых систем и открытых распределённых сред. The Open Group за нимает особое положение: можно утверждать, что она находится между первой (официальные органы) и второй (неофициальные) категориями организаций. Она одобряет стандарты де-юре, согласует и разрабатывает стандарты де-факто, и её документы имеют большое влияние на промышленность. Однако, в отличие от промышленных групп и консорциумов, она не внедряет отдельные продукты, технологии или решения фирм-производителей. Многие свои проекты TOG ведёт совместно с официальными организациями по стандартизации, прежде всего ISO.

• Open Software Foundation (OSF) — некоммерческий международный консорциум, в 1993 г. вошедший в состав The Open Group. Это научно-производственная организация, цель которой — создание спецификаций для программного обеспечения открытых систем с целью поддержки различных производителей. Широко известны разработки OSF, которые объединя ют лучшие достижения промышленности: набор спецификаций и исходных кодов для UNIX подобных операционных систем OSF/1, графический интерфейс OSF/Motif, набор сервисов для поддержки распределённых приложений OSF/DCE, набор сервисов для управления системами OSF/DME, модель и спецификация интерфейсов для разработки переносимых приложений в среде открытых систем OSF AES.

• Х/Ореn — всемирная некоммерческая независимая организация по открытым систе мам, основанная в 1984 г. и вошедшая в состав The Open Group в 1993г. Главными разработка ми этой организации являются спецификации САЕ (Common Application Environment) — мо дель и стандартный набор интерфейсов программирования, опубликованные в документах XPG. САЕ основана преимущественно на стандартах де-юре (в т.ч. POSIX) и включает стандар ты де-факто и промышленные стандарты производителей.

• Unix International (UI). В настоящее время эта организация ликвидирована, но во мно гом благодаря ей понятие "открытые системы" ассоциируется с операционными системами UNIX и протоколами TCP/IP.

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

• OMG — Object Management Group;

• NMF — Network Management Forum;

• W3C— World Wide Web Consortium;

и другие.

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

п. 1.1:

В настоящее время многие понятия, связанные с распределённой обработкой данных, не получили ещё однозначного, единообразного толкования. Определения одних и тех же терминов различаются даже в международных стандартах. Опре деления системы обработки данных, (компьютерной) информационной системы, вычислительной системы сформулированы автором на основе обобщения документов [11,14,17,22,24], определение среды — на основе [11,17]. Эти определения не пре тендуют на полноту и научную строгость: они введены только в контексте данной работы. Так, информационная система может пониматься более широко: например, в [Расторгуев С.П. Информационная война как целенаправленное информацион ное воздействие информационных систем. //Информационное общество. — 1997. — №1. — С. 64] под информационной систе мой понимается "система, осуществляющая получение входных данных;

обработку этих данных и/или изменение собственно го внутреннего состояния (внутренних связей/отношений);

выдачу результата либо изменение своего внешнего состояния (внешних связей/отношений)". Определение информационного обеспечения деятельности предприятия заимствовано из [В.А.

Герасименко, А.А. Малюк. Основы защиты информации. —М.,1997. — с. 14,16].

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

Хорошим источником стандартизованных ITU-T (и частично ISO) определений является база данных по определени ям и аббревиатурам в области телекоммуникаций SANCHO (ITU-T Sector Abbreviations and definitions for a telecommunication tHesaurus Oriented database), доступ к которой возможен в сети Internet no адресу: http: //www7. itu. int/sancho.

Этот и следующий параграфы придерживаются в основном плана изложения, принятого в учебном руководстве [20, ch.2], и частично используют материал его пп. 2.3 — 2.9, 2.27 — 2.28. Хорошей, но несколько устаревшей, обзорной работой по технологиям распределённой обработки данных является также [22]: характеристика путей эволюции систем обработки данных, конфигурационных сред составлена по материалам этой книги.

п. 1.2:

Определения открытых систем и среды открытых систем приводятся по следующим источникам: IEEE — [20,21], OSF uX/Open — [20], определение ISO сформулировано в стандарте [12] и эквивалентном ему стандарте ITU-T X.200. В глос сарии к модели TOGAF (версия 5, янв. 2000г.) [24] организации The Open Group определение открытых систем (рекомендован ное вместо определений OSF и Х/Ореn) сформулировано следующим образом (приводится исходный текст на английском язы ке):

"Open system — a system that implements sufficient open specifications for interfaces, services, and supporting formats to en able properly engineered applications software: (a) to be ported with minimal changes across a wide range of systems, (b) to intemper ate with other applications on local and remote systems, and (c) to interact with users in a style that facilitates user portability."

"Open systems environment (OSE) — the comprehensive set of interfaces, services, and supporting formats, plus user aspects for interoperability or for portability of applications, data, or people, as specified by information technology standards and profiles. " n.1.3:

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

ISO (International Organization for Standardization) — http://www.iso.ch/, дополнительно использовалось [21, App. А.З], The Open Group — http: //www. opengroup. org, IEEE— http://www. ieee.org/, ITU— http://www.itu.ch/, IAB — http: / /www. ietf. org, OMG— http://www.omg.org/, Госстандарт РФ— http://www.gost.ru/, http://www.interstandard.gost.ru/ (каталог российских и международных стандартов), NIST (Национальный институт стандартов и технологий США) — http: //www. nist. gov.

В России на начало 2000 г. насчитывается 161 государственный стандарт по классу "Информационная технология".

Несмотря на это количество и состав государственных стандартов РФ по информационным технологиям всё ещё значи тельно уступает международным стандартам ISO/IEC.

Перечни и краткие аннотации стандартов могут быть также получены по следующим адресам: стандарты ISO и ISO/IEC — http://www.iso.ch/cate/cat.html, рекомендации ITU — http://www.itu.int/publications/index.html.

Глава 2. ПЕРЕНОСИМОСТЬ И СПОСОБНОСТЬ К ВЗАИМОДЕЙСТВИЮ 2.1. Основные аспекты совместимости систем Как было отмечено в главе 1, основными требованиями к совместимости вычислитель ных систем в сложной среде является переносимость и способность к взаимодействию. Рас смотрим подробнее смысл этих требований, различие между ними, методы их реализации в среде открытых систем. Для этой цели нам потребуется функциональная модель информацион ной системы, которая в дальнейшем будет использоваться для размещения в ней и более под робного рассмотрения стандартов и технологий открытых систем.

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

Переносимость имеет три составляющие.

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

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

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

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

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

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

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

Эти стандарты могут различаться по сложности, по широте охватываемых проблем и относить ся к любому аспекту информационных технологий. Чтобы распознать и позиционировать раз личные стандарты, связанные с переносимостью и способностью к взаимодействию, будем ис пользовать простую модель информационной системы, показанную на рис. 1. За основу в ней берётся модель POSIX OSE, описанная в документе IEEE PI 003.0 "Guide to the POSIX Open Systems Environment", которая подвергается дальнейшей декомпозиции по методике, исполь зуемой в документах фирмы IBM. Выбор модели POSIX OSE объясняется тем, что она является наиболее простой и наиболее общей. Она взята за основу в большинстве других, более сложных моделей. Эта модель не является определяющей по отношению к рассматриваемым далее стан дартам, она — лишь средство классификации стандартов. Методика фирмы IBM была выбрана вследствие того, что она представляется наиболее удобным, объективным и независимым от продуктов конкретных фирм методом описания информационных систем, не нуждающимся в то же время в привлечении сложных структур и понятий. Главное её преимущество заключает ся в том, что она позволяет легко классифицировать стандарты двумя способами:

• во-первых, как интерфейсы программирования (форматы) или протоколы;

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

Основными элементами модели являются блоки и интерфейсы между ними:

1. Прикладное программное обеспечение (AS — Application Software) — представляет программное обеспечение, специфичное для конкретных задач пользователей.

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

Приложения запрашивают ресурсы от платформы посредством вызова сервисов через интерфейс — интерфейс прикладного программирования (API — Application Programming Inter face). Ресурсы, находящиеся вне платформы, запрашивают сервисы через другой интерфейс — интерфейс внешней среды (EEI — External Environment Interface).

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

3. Внешняя среда (ЕЕ — External Environment) — представляет все объекты вне системы, с которыми она взаимодействует каким-либо образом: людей, коммуникационные средства, сменные носители данных и средства ввода/вывода.

Интерфейс между АР и ЕЕ включает в себя форматы данных, коммуникационные про токолы, человекомашинный интерфейс и др.

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

• Внешняя среда. Внешняя среда состоит из трёх типов объектов: пользователей, внеш них объектов данных, коммуникационных средств (хотя разбиение внешней среды именно та ким образом в некотором роде произвольно). Внешние объекты данных включают все устрой ства ввода/вывода и сменные носители данных: гибкие диски, дисковые массивы, принтеры, устройства ввода с перфокарт и т.п. Коммуникационные средства включают каналы связи, ло кальные, глобальные сети и соответствующее коммуникационное оборудование. АР осущест вляет доступ к этим объектам через EEI. Этот интерфейс принимает форму протоколов, форма тов и потоков данных и включает такие аспекты как формат данных, формат экрана, поведение объектов на экране, протоколы обмена данными и т.д.

• Платформа приложений. АР включает аппаратное, системное программное обеспе чение и различные программные подсистемы, например, такие как СУБД, менеджеры транзак ций, графическую подсистему. Следовательно, структура типичной платформы обычно являет ся сложной. Многие модели рассматривают внутреннюю структуру платформу (см. гл. 3). Здесь мы не будем пользоваться фиксированной внутренней структурой, так как среди документов различных организаций и фирм не существует единого мнения по этому вопросу. Для обсужде ния того, как технологии и стандарты АР используются для удовлетворения требований прило жений и внешней среды, удобно выделить в АР четыре класса сервисов (рис.2).

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

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

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

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

Указанные классы сервисов обеспечивают связь между сервисами АР и внешней средой, с которой АР взаимодействует. Три класса сервисов: сервисы человекомашинного взаимодейст вия, сервисы данных и сетевые сервисы —~ связаны с соответствующими классами объектов внешней среды. Четвёртый набор сервисов — внутренние сервисы платформы — позволяет прикладному ПО AS использовать эти сервисы, полагаясь только на ту платформу, на которой эти приложения исполняются. Следует заметить, что взаимосвязь между классами сервисов АР и классами объектов ЕЕ не является однозначной, поэтому на рис. 2 показана единая связь ме жду АР и ЕЕ. Такое разбиение обеспечивает удобство классификации стандартов.

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

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

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

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

Перечисленные три элемента базовой модели достаточны для рассмотрения свойства переносимости. Для рассмотрения способности к взаимодействию и концепции распределён ных систем модель необходимо расширить.

Способность к взаимодействию подразумевает наличие двух или более вычислительных систем и коммуникационных средств между ними. Модель взаимодействующих систем показа на на рис. 3.

Приложения из одной системы могут запрашивать сервисы удалённой платформы, ис пользуя сетевые сервисы, доступные на своей собственной платформе. Например, они могут осуществлять доступ к внутренним или внешним ресурсам на удалённой платформе, взаимо действовать с удалённым приложением или общаться с пользователем удалённой системы. Не обходимое условие для этого — на удалённой платформе должен поддерживаться тот же самый интерфейс сетевого сервиса, т.е. сетевые протоколы и форматы сообщений.

Как уже отмечалось выше, для взаимодействия системы должны не только обмениваться данными, но и одинаково "понимать" выполняемую работу. Для этого необходимы дополни тельные протоколы и форматы, зависящие от характера выполняемой работы. Заметим, что в данном случае приложение "осведомлено" о расположении партнёра (сервиса или другого при ложения), так как, если он находится на удалённой системе, приложение пользуется сетевым сервисом своей АР. Способность к взаимодействию между системами достигается через коммуникационные средства внешней среды.

Каким образом может быть обеспечена переносимость конкретных программных про дуктов? Известны четыре подхода к решению этой проблемы:

• спецификация открытых программных интерфейсов для неограниченного ис пользования разработчиками ПО;

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

• применение стандартных интерфейсов в программных продуктах (SQL, OSF/DCE, POSIX 1003 и пр.) в дополнение к их собственным интерфейсам;

• совмещение двух последних подходов.

Перечисленные методы в основном применимы и для обеспечения способности к взаи модействию между программными модулями. Кроме того, способность к взаимодействию чаще всего подразумевает уровневую структуру программного обеспечения — тогда, кроме того, по является выбор возможностей реализации этого свойства. Например, если требуется взаимо действие удалённого приложения с СУБД, возможны следующие альтернативы: взаимодейст вие на коммуникационном уровне (непосредственная передача данных приложением через низ коуровневый коммуникационный интерфейс), взаимодействие на уровне менеджера транзакций (последовательное выполнение транзакций) или взаимодействие на уровне СУБД (отработка запроса, написанного на языке манипулирования данными, например, SQL). Один из лучших известных подходов к многоуровневой организации ПО в открытых системах — стандартизо ванный набор интерфейсов для распределённых вычислений модели OSF DCE (см. п.3.4).

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

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

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

Переносимость (portability) и способность к взаимодействию (interoperability) — различные, но взаимодополняющие качества открытых систем. Переносимость может рас сматриваться как временной аспект: она позволяет перемещать ресурсы с одной системы на другую во времени. Способность к взаимодействию может рассматриваться как пространст венное представление качеств открытых систем: она позволяет множеству систем, разделённых в пространстве, сообща использовать ресурсы.

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

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

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

Расширение этого примера на все категории сервисов, предоставляемые АР приложени ям, приводит к концепции распределённой вычислительной системы. Схематическая модель распределённой системы показана на рис. 4. В ранее обсуждавшемся случае взаимодействую щих систем две платформы рассматриваются как разделённые объекты, соединённые коммуни кационными связями. В случае распределённой вычислительной системы они уже рассматри ваются как единая, унифицированная платформа. Это различие имеет значение только с точки зрения приложений. Технически система в обоих случаях может быть одинакова, а формирова ние распределённой вычислительной системы обеспечивается только системным программным обеспечением.

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

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

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

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

пользователи и их приложения не видят общей сложности и неоднородности распределённой системы;

напротив, они видят её как продолжение, расширение своей собственной системы;

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

система допус кает развитие и расширение с ростом требований или расширением задач потребителя;

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

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

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

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

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

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

Рис. 5. Формирование образа единой распределённой системы Таким образом, основными характеристиками распределённой среды являются:

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

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

• лёгкость распределения функций приложений в распределённой вычислительной среде.

2.2. Переносимость Как было установлено в п. 2.1, понятие переносимости обычно рассматривается в трёх аспектах: переносимость приложений, данных и пользователей.

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

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

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

• API сервисов человекомашинного взаимодействия;

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

• API сетевых сервисов;

• API внутренних сервисов платформы.

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

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

Итак, API делают возможным переносимость приложений за счёт стандартизации интерфейсов между AS и АР. Переносимость пользователей и данных достигается за счёт стандартизации форматов и протоколов, используемых между АР и ЕЕ (см. рис. 1,2). Для пользователей эти форматы и протоколы принимают вид, например, форматов экрана, поведе ния объектов на экране, стиля общения с пользователем и т.п. Для данных — это форматы дан ных, в которых они записываются на одной платформе, хранятся на носителе и считываются на другой платформе.

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

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

• API сервиса;

• стандарты по данному виду сервиса.

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

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

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

В группе системных сервисов можно выделить следующие сервисы:

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

• сервисы управления памятью;

• межпроцессные коммуникации (interprocess communications - IPC);

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

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

• сервисы логического именования ресурсов;

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

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

• сервисы конфигурирования системы.

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

Стандарты по API системных сервисов. Наиболее важным стандартом по системным сервисам для открытых систем является документ IEEE POSIX (Portable Operating System Inter face for Computer Environment). Системные сервисы описаны в части 1003.1-1990 этого стан дарта (утверждена в качестве международного стандарта ISO/IEC 9945-1:1990). Эта часть спе цифицирует вызовы к операционной системе со стороны приложений и требуемую функцио нальность при выполнении этих вызовов, номера ошибок, типы данных и пр. Стандарт в значи тельной степени основывается на реализациях UNIX System V и BSD операционных систем UNIX. Однако это не означает, что другие, не UNIX-подобные операционные системы не могут достичь совместимости с POSIX. Они могут обеспечивать POSIX-совместимые сервисы и API в дополнение к существующим в них собственным, как это сделано, например, в OS/400, OpenEdition/MVS, Open VMS.

Х/Ореn разработала спецификацию для API системных сервисов, основываясь на стан дарте POSIX, которая получила название XSH и является частью стандарта XPG4.

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

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

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

Стандарты по сервисом языков программирования. Основной международной орга низацией, занимающейся стандартизацией языков программирования, является ISO. Сущест вуют стандарты или проекты стандартов на следующие языки программирования: Ada, APL, BASIC, С, C++, COBOL, FORTRAN, Modula-2, MUMPS, Pascal, PL/I.

2. Сервисы данных — сервисы, связанные преимущественно с доступом, манипуляцией и обменом данными. Для достижения переносимости приложения должны иметь:

1) единообразный метод доступа к механизмам управления данными;

2) способ управления отдельными транзакциями над этими данными.

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

• Сервисы баз данных. Приложения могут управлять своими собственными данными.

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

• сервисы доступа к данным;

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

• сервисы обеспечения целостности данных;

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

• дополнительные сервисы (создания форм, отчётов, контроля доступа, словари и пр.).

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

Основными и доминирующими стандартами в отношении сервисов БД являются стан дарты ISO 10032:1993 — Reference Model for Data Management (Нормативная модель управле ния данными) и ISO 9075, определяющий SQL (Structured Query Language) — непроцедурный язык манипулирования данными для реляционных СУБД. Расширенная версия SQL определена в спецификации X/Open XPG4. Существует много других версий языка SQL.

Среди интерфейсов, позволяющих обеспечить доступ к СУБД из внешней среды (в ча стности, из других СУБД) выделяется четыре спецификации:

• Remote Database Access (RDA) — стандарт ISO/IEC 9579, поддерживаемый X/Open;

• Distributed Relational Database Architecture (DRDA) — разработка фирмы IBM;

• Open Database Connectivity (ODBC) — разработка фирмы Microsoft, имеющая сильную поддержку в промышленности;

• Integrated Database API — совместная разработка фирм Borland, Novell, WordPerfect.

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

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

• ISO 10026 — OSI Distributed Transaction Processing (OSI-TP). Этот стандарт определяет модель, сервисы и коммуникационные протоколы для распределённой среды обработки тран закций. Основными элементами в модели обработки транзакций являются прикладные про граммы, менеджеры ресурсов, к которым осуществляется доступ, и менеджер транзакций, обеспечивающий основные качества транзакций: неделимость, целостность, блокирование ре сурсов, неизменяемость состояния ресурсов.

• X/Open Transaction Processing Group (XTP). В него входят: нормативная модель обра ботки транзакций (X/Open DTP), ТХ — спецификация API между прикладными программами и менеджером транзакций, ХА — спецификация интерфейса между менеджером транзакций и менеджерами ресурсов (предоставляет менеджеру транзакций возможность структуризации ра боты менеджеров ресурсов внутри транзакции).

• Сервисы печати предназначены для упрощения печати данных на различных типах носителей и просмотра их пользователем перед печатью. Эта группа включают следующие сер висы:

• способность описывать требуемые выходные данные и параметры печати;

• поддержка очередей и множества устройств печати;

• способность специфицировать характеристики задания на печать;

• управление заданиями;

• управление очередями;

• управление шрифтами;

• контроль доступа к устройствам печати;

• поддержка учётной информации и пр.

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

Среди стандартов по сервисам печати следует выделить ISO 10175 — Document Printing Application (DPA) и ISO 10180 — Standard Page Description Language (SDPL), основанный на языке PostScript, а также IEEE PI 003.7 — администрирование печати.

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

Наиболее значительными являются следующие стандарты по форматам обмена данными:

• ISO 9735 — EDIFACT (Electronic Data Interchange for Administration, Commerce and Transportation) — набор стандартов, определяющих формат и структуру документов, исполь зуемых в делопроизводстве и электронном документообороте.

• ISO 8613 — ODA/ODIF (Open Document Architecture / Open Document Interchange For mat) — набор стандартов по структуризации и прозрачному для пользователей обмену слож ными составными документами, включающими несколько типов информации: текст, рисунки, геометрическую графику.

• ISO 8879 — SGML (Standard Generalized Markup Language) — язык представления структуры, содержания и формата документа.

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

• Сервисы командного интерфейса могут принимать различные формы:

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

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

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

• диспетчеризация команд;

• пакетный режим обработки команд;

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

• примитивы языков программирования для написания простых программ на командном языке.

Основной стандарт в этой области — ISO/IEC 9945-2 (основан на IEEE Р1003.2).

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

• Сервисы графического пользовательского интерфейса (GUI — Graphical User Inter face) обеспечивают для приложений возможность создавать и манипулировать визуальными объектами на экранах компьютеров. Пользователи должны иметь единый, легко понятный им стиль общения с вычислительной системой через такой интерфейс. На сегодняшний день GUI является общепринятой формой организации пользовательского интерфейса. АР должна иметь два интерфейса с сервисами GUI:

• API сервиса визуальных объектов (часто также называется "оконный интерфейс") по зволяет приложениям использовать сервисы GUI;

• EEI обеспечивает форматы и протоколы обмена данными между сервисами GUI мно жества систем и формирование единообразной рабочей среды для пользователей различных систем.

Среди стандартов на открытые сервисы GUI важное значение имеют протоколы XWin dows — это стандарты де-факто, специфицированные и реализованные консорциумом Х/Ореn.

Интерфейсы, основанные на этом стандарте, преобладают среди UNIX-подобных платформ. На персональных системах стандартами де-факто являются API операционных систем Microsoft Windows и MacOS.

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

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

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

Весьма перспективным направлением развития сервисов разработки приложений явля ется создание систем автоматизации проектирования программного обеспечения — CASE (Computer Aided Software Engineering). Соответствующие стандарты в основном находятся в стадии разработки;

среди уже существующих можно отметить стандарты POSIX.

4. Межкатегориальные сервисы. Рассмотренные сервисы АР допускают довольно чёт кую, хотя и не единственно возможную, классификацию. Следующая группа сервисов — так называемые межкатегориальные сервисы. Они принципиально отличается от указанных выше:

• Межкатегориальные сервисы имеют определённое влияние на все остальные сервисы, которые предоставляются АР. Каждый сервисный компонент должен быть сконструирован с учётом этих межкатегориальных сервисов.

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

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

Две других категории сервисов, напротив, очень важны для функционирования системы;

с ними связано большое число стандартов.

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

Каждая система требует формулировки политики безопасности (security policy) для то го, чтобы определить, какой уровень защищённости и какие правила разграничения доступа требуются для информации, обрабатываемой в этой системе. Для осуществления на практике этой политики могут быть применены механизмы, которые гарантируют желаемый уровень безопасности. Совокупность всех аппаратных и программных компонентов, с помощью кото рых в системе "проводится в жизнь" установленная политика безопасности, носит название комплекса средств защиты (согласно определению Гостехкомиссии;

в оригинале - ТСВ — trusted computer base). Кроме того, должны существовать некоторые способы оценивания того, насколько хорошо эти механизмы реализуют заданную политику безопасности. Мы будем рас сматривать только те механизмы, которые могут быть реализованы, измерены и оценены с точ ки зрения АР, исключая физические, организационные, юридические и пр. средства защиты.

Для обеспечения механизмов, реализующих политику безопасности и оценку их эффек тивности, в системе требуется наличие нескольких сервисов:

• сервисы аутентификации;

• механизмы контроля доступа;

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

• сервисы шифрования;

• сервисы аудита;

• средства установления доверия к каналам передачи и узлам обработки данных.

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

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

• интерфейсы аудита;

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

• интерфейсы дискретционного контроля доступа;

• интерфейсы мандатного контроля доступа.

• ISO/IEC 15408 — Information technology — Security techniques -Evaluation criteria for IT security (Критерии оценки защищённости продуктов и систем информационных технологий).

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

часть 1: Введение и общая модель;

часть 2: Функциональные требования по защите;

часть 3: Требования гарантий защищённости.

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

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

• инсталляция и управление программным обеспечением;

• корректный запуск и останов системы;

• лицензирование программного обеспечения;

• управляемость и конфигурирование вычислительной сети;

• управление организацией хранения данных на дисках;

• диспетчеризация заданий;

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

• учётность пользователей и ресурсов;

• управление защитой;

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

• управление ёмкостью носителей данных;

• сервисы резервного копирования и восстановления;

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

• управление системой печати и пр.

Этот перечень показывает, что при создании сервисов управления системой требуется учитывать, что они должны взаимодействовать практически со всеми остальными сервисами, ресурсами и объектами АР.

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

• электронная почта;

• передача файлов из одной системы в другую;

• доступ к приложениям на удалённой системе;

• разделение файлов между несколькими системами;

• разделяемые базы данных;

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

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

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

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

• Она позволяет объединять существующие системы с новыми, сохраняя преемст венность и инвестиции, уже вложенные в информационную систему.

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

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

Как уже отмечалось ранее, способность к взаимодействия достигается посредством:

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

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

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

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

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

Таким образом приходим к необходимости описания "комплекта", набора протоколов различных уровней (как видно из предыдущих рассуждений — по крайней мере двух).

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

Подобные многоуровневые наборы протоколов часто называют "стеками протоколов".

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

Вернёмся к модели информационной системы, введённой в п. 2.1. При рассмотрении пе реносимости обсуждались два типа интерфейсов АР: API и EEI с пользователями и внешними объектами данных. С точки зрения способности систем к взаимодействию имеет значение дру гой компонент — EEI между АР и коммуникационными средствами внешней среды. Коммуни кационные средства позволяют одной данной системе рассматривать все другие системы как часть внешней среды (рис. 6).

Чтобы добиться способности к взаимодействию, необходимо стандартизировать форма ты и протоколы обмена сообщениями через EEI, используя коммуникационные средства внеш ней среды. Часть EEI, которая управляет такими сообщениями, носит название коммуникацион ного интерфейса. Он включает в себя сетевые протоколы и высокоуровневые прикладные про токолы, необходимые для поддержки распределённых сервисов. Коммуникационный интер фейс — это единственный интерфейс, где две (вероятно, различные) системы непосредственно контактируют друг с другом. Он позволяет платформам приложений осуществлять взаимный доступ к ресурсам и предоставлять сервис друг другу, используя сетевые и соответствующие прикладные протоколы. Способность к взаимодействию обращается к таким функциональным возможностям, которые не затрагивает переносимость. Так, она организует доступ к тем серви сам АР, к которым пользователь или приложение не имеют прямого доступа через API. При этом не имеет значения, как именно реализуется внутри той или иной системы конкретный вид сервиса. Он вполне может использовать внутренние особенности и преимущества организации системы.

Рис. 6. Базовая модель взаимодействующих систем Заметим, что для достижения способности к взаимодействию нет необходимости стан дартизировать API — только соответствующие форматы и протоколы. Также для этого не нуж ны стандарты на те сервисы, которые являются внутренними для АР, и те части EEI, которые взаимодействуют с внешними объектами данных и пользователями. Однако из этого правила есть исключение: стандартизация API сетевых сервисов способствует обеспечению взаимодей ствия на более высоком уровне. Тогда появляется возможность ввести в состав платформы приложения, работающие с сетевыми сервисами, а их услугами уже могут пользоваться осталь ные приложения.

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

• Многоуровневая организация есть частный случай модульности — это позволяет легче понимать структуру системы.

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

• Уровневые сервисы всегда включают некоторый сервис по транспортировке дан ных, который предоставляется верхним уровням. Это означает, что, хотя каждому объекту некоторого уровня кажется, что он взаимодействует с объектом того же уровня, на самом деле перемещение данных по всем уровням, кроме самого ниж него, происходит "вертикально". И только нижний уровень действительно пере мещает данные "горизонтально".

Отметим теперь основные принципы многоуровневого взаимодействия:

• Взаимодействие по принципу сервисов и протоколов. Каждый уровень взаимодействия предоставляет сервисы уровню, расположенному над ним, и сам, в свою очередь, пользуется сервисами уровня, расположенного под ним. Сервис определённого уровня доставляется по средством протокола этого уровня. Уровень, запросивший сервис, не видит протокол нижнего уровня. Таким образом, протоколы образуют каскад сервисов, предоставляемых с верхнего уровня до нижнего.

• Мультиплексирование. Множество объектов верхнего уровня могут параллельно ис пользовать сервис нижнего уровня. Множество сервисов различного качества и различной функциональности могут предоставляться на каждом уровне по соглашению между партнёра ми.

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

• Адресация. Любая форма коммуникации требует какой-либо подходящей формы адре сации. На каждом уровне формат адресации является частью соответствующего протокола.

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

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

Классическим примером многоуровневой модели взаимодействия вычислительных сис тем является семиуровневая модель взаимосвязи открытых систем, описанная в стандарте ISO/IEC 7498 — Information technology — Open Systems Interconnection — Basic Reference Model, известная как модель OSI (см. п. 3.2.1).

Кроме указанной, существует ещё большое количество многоуровневых моделей взаи модействия вычислительных систем и соответствующих им стеков протоколов: DNA (Digital Network Architecture), AppleTalk, SNA (System Network Architecture), TCP/IP и др. Вследствие несовместимостей между различными моделями добиться способности к взаимодействию на практике — существенно более сложная задача, чем это может показаться теоретически. Для этого требуется организовать "мосты" между различными моделями (стеками протоколов) и сделать их существование прозрачным для пользователей и приложений. Более того, историче ски не существовало единого и чёткого разделения протоколов на указанные уровни. Поэтому различные стеки протоколов не обязательно согласуются между собой по разбиению на уровни, выполняемым на этих уровнях функциям и даже по числу уровней. Всё это порождает опреде лённую зависимость протоколов верхних уровней от нижних для каждого конкретного стека протоколов.

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

• распределённые сервисы платформы;

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

• распределённые сервисы человекомашинного взаимодействия.

В качестве примеров сервисов из соответствующих групп можно привести:

• вызов удалённых процедур;

• передача файлов;

• удалённый вход в систему.

Дополнительно рассматриваются межкатегориальные сервисы. Такое представление со гласуется с концепцией единой, распределённой системы, где все аспекты взаимодействия ме жду отдельными системами регулируются внутри АР.

Часто протоколы, соответствующие в стеке коммуникационных протоколов сетевым сервисам и распределённым сервисам приложений, называют соответственно транспортными провайдерами (transport provider) и транспортными пользователями (transport user). Первые обеспечивают базовые, не зависящие от приложений, функции по доставке сообщений через сеть. Вторые строятся на сетевых сервисах и расширяют сервисы АР в распределённых систе мах. В коммуникационных моделях они примерно соответствуют или отождествляются с сами ми приложениями.

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

Известно несколько других моделей организации вычислений, получавших развитие на различных этапах эволюции распределённых вычислений: централизованная, хост-модель (host-based), модель "ведущий - ведомый" (master - slave), модель разделения устройств (shared device processing), одноранговая модель (peer-to-peer). Но наибольшее распространение получи ла именно клиент-серверная модель: она является самой оптимальной в условиях неоднородной распределённой вычислительной среды с дисбалансом вычислительных мощностей.

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

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

Клиент-серверные вычисления в распределённой вычислительной среде прочно связаны с концепцией "middleware". Этот термин является сокращением и может быть интерпретирован как "программное обеспечение среднего уровня". Идея дополнения системного ПО этим ком понентом возникла из естественного стремления сократить трудоёмкость разработки приклад ного ПО для работы в клиент-серверной модели. Middleware - это соединяющий уровень ком муникационного ПО между физической сетью передачи данных и приложениями пользователя, выполняющего функции транспортного пользователя, в общем случае эквивалентное уровням и 6 модели OSI (см. п. 3.2.1). Со стороны приложений это ПО содержит упрощающие програм мирование высокоуровневые API, которые "экранируют" разработку прикладного ПО от слож ных коммуникационных протоколов на нижних уровнях. Используя инструменты и продукты middleware, программисты могут сфокусироваться на создании собственно логики приложений, не разрабатывая при этом сложные коммуникационные протоколы и интерфейсы.

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

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

К сервисам, видимым приложениями напрямую, относятся: установление и разрыв со единения с партнёром, управление качеством сервиса для передачи данных, выбор функций со общения о состоянии сети. Но даже эти сервисы могут быть скрыты от приложений в некото рых формах коммуникаций, например, при вызове удалённых процедур — RPC (Remote Proce dure Call). Другие сервисы, невидимые для приложений, относятся к нижним уровням стека протоколов. Они обычно связаны с физическими аспектами сети:

• сообщение об ошибках и восстановление после ошибок;

• сегментация сообщений в пакеты установленного в сети размера и их повторная сбор ка;

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

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

• физический доступ к узлам сети;

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

Нижний уровень модели (транспортный провайдер) часто рассматривают как состоящий из двух подуровней:

• Уровень сети передачи данных — нижний уровень, ответственный за управление гра фиком, передающимся от узла к узлу внутри единичной физической сети передачи данных (subnetwork). Примерами сетей передачи данных являются сети Х.25, локальные сети стандар тов IEEE 802-x, Frame Relay, ATM, двухточечные линии связи.

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

• по используемой технологии передачи данных:

• образование соединений;

• метод разделения канала;

• по территориальной распределённости и связанным с этим особенностям организации:

• локальные (LAN — local area network);

• глобальные (WAN — wide area network);

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

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

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

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

Модели взаимодействия вычислительных систем и соответствующие им стеки протоко лов, такие как OSI, SNA, DNA, не специфицируют API к своим сетевым сервисам. Это и не тре буется: способность к взаимодействию уже может быть обеспечена за счёт единства протоко лов и форматов данных. Однако, определение и использование стандартных API для сетевых сервисов содействует упрощению разработки и развёртывания в системе распределённых при ложений, так как обеспечивает более высокоуровневое взаимодействие между системами.

Этим, в частности, объясняется широкое распространение протоколов TCP/IP.

Наиболее известными стандартами на API для доступа к транспортным сервисам явля ются:

• Интерфейс сокетов (socket interface), берущий начало из версии UNIX BSD;

• XSOCKET, стандартизованный X/Open;

• TLI (Transport Layer Interface), частично основанный на socket, а частично на стандарте ISO 8072 по транспортному сервису;

• XTI (X/Open Transport Interface) — базируется на TLI, может поддержи вать несколько стеков протоколов: OSI, TCP/IP, NetBIOS, SNA.

Несколько иной подход представляет технология MPTN (Multiprotocol Transport Net working), разработанная IBM и принятая X/Open. Она компенсирует неоднородности в функ циональности различных транспортных протоколов за счёт введения дополнительного уровня над транспортным уровнем — CTS (Common Transport Semantics). MPTN позволяет "смеши вать" в произвольной комбинации транспортные провайдеры и транспортные пользователи, де лая приложения независимыми от используемых сетевых протоколов. Следовательно, прило жения могут использовать транспортную систему, отличную от той, которая "ассоциирована" с высокоуровневыми прикладными протоколами.

2. Сервисы распределённой платформы. Любая прикладная программа включает три компонента: логику приложения, сервисы данных и сервисы представления информации. Логи ка приложения выполняет специфические для конкретного приложения функции и реализуется с помощью системных сервисов и сервисов языков программирования. Сервисы данных при ложения выполняют операции ввода/вывода, требуемые приложением. Сервисы представления приложения управляют взаимодействием с пользователем. Эти компоненты эквивалентны со ответствующим сервисам в рассматриваемой модели. Если приложение становится распреде лённым, существует три возможности "расщепления" приложений согласно перечисленным компонентам:

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

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

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

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

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

Сервисы распределённой платформы — это расширения внутренних сервисов платфор мы, рассмотренных в п. 2.2, перенесённые в распределённую среду. Они предоставляют основ ные механизмы распределения приложений, обеспечивают функции по координации распреде лённой работы приложений. Часто они также носят название «сервисы распределения». Сооб разно основным требованиям приложений в распределённой среде можно выделить три класса таких сервисов:

• сервисы межпроцессного взаимодействия;

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

• сервисы времени.

• Сервисы межпроцессного взаимодействия. Существует три основные модели органи зации взаимодействия между программами:

• Диалоговая (conversational) модель. Приложения общаются друг с другом посредством посылки вызовов: «установить соединение», «послать сообщение», «принять сообщение», «разрушить соединение» и пр. Это форма связи с установлением соединения.

Наиболее известными стандартами, в которых определяются диалоговая модель комму никаций, являются ISO 10026 — OSI Distributed Transaction Processing и архитектура АРРС (Advanced Program-to-Program Communication) фирмы IBM.

• Вызов удалённых процедур (RPC — Remote Procedure Call). Эта модель является рас ширением традиционного метода вызова процедур в языках программирования. Вызов удалён ной процедуры заключается в однократном обмене сообщениями между вызывающей и вызы ваемой процедурами, как при локальном вызове. При этом использование коммуникационных сервисов происходит невидимо для обеих процедур. RPC может иметь место как с установле нием соединения, так и без него. Но с точки зрения приложения он является синхронной фор мой коммуникаций, так как оба партнёра должны быть активны в одно и то же время, а вызы вающая процедура приостанавливается на время выполнения удалённой. Эта форма коммуни каций обычно ассоциируется с моделью вычислений "клиент/сервер".

Основными стандартами по вызову удалённых процедур являются:

- Sun RPC;

- OSF RPC, являющийся основой OSF DCE (Distributed Computing Environment);

- OSI RPC — стандарт ISO 11578.

• Очереди сообщений (message queuing). При этой форме взаимодействия один из про цессов помещает свои сообщения в очередь, другой извлекает их оттуда. Это форма коммуни каций без установления соединения.

Существует проект международного стандарта по этому виду коммуникаций --ISO/IEC DIS 10026-7 Information technology - Open Systems Interconnection — Distributed transaction proc essing — Part 7: Message queueing.

Pages:     || 2 | 3 |



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

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