LINEBURG


<< Пред. стр.

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

ОГЛАВЛЕНИЕ

След. стр. >>

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

<< Пред. стр.

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

ОГЛАВЛЕНИЕ

След. стр. >>

Copyright © Design by: Sunlight webdesign