Распределённые базы данных

Распределённые базы данных
Введение
Вусловиях современного динамического развития общества и усложнения техническойи социальной инфраструктуры информация становится таким же стратегическимресурсом, как традиционные материальные и энергетические ресурсы [1].Современные информационные технологии, позволяющие создавать, хранить,перерабатывать и обеспечивать эффективные способы представления информационныхресурсов потребителю, стали важным фактором жизни общества и средствомповышения эффективности управления всеми сферами общественной деятельности.Уровень использования информации становится одним из существенных факторовуспешного экономического развития и конкурентоспособности региона как навнутреннем, так и на внешнем рынке.
Осознаниемировым сообществом роли информации как стратегического ресурса стимулировалоразработки новых информационных технологий для получения и переработки большихобъемов информации и ее хранения и предоставления пользователям. Первое местосреди новых технологий занимают сетевые информационные технологии.
Информацияявляется важнейшим стратегическим ресурсом, и наибольший экономический и социальныйуспех сегодня сопутствует тем странам, которые активно используют современныесредства компьютерных коммуникаций и сетей, информационных технологий и системуправления информационными ресурсами. Перенесенные на электронные носителиинформационные ресурсы приобретают качественно новое состояние и становятсяактивными. Доступная для оперативного воспроизводства средствами компьютернойобработки информация является важнейшим фактором социального развития общества.
Внастоящее время наиболее развитые страны мира находятся на завершающей стадиииндустриального этапа развития общества и перехода к следующему,информационному, этапу развития и построения «Информационногообщества» (ИО). Широкое использование информационных технологий исовременных средств доступа к информации открыло принципиально иные возможностипостроения более сбалансированного общества, с существенно большей реализациейиндивидуальных возможностей его членов. «Информационное общество»несет в себе огромный потенциал для улучшения жизни граждан и повышенияэффективности социального и экономического устройства государства. Стоящийперед Россией как и перед всем миром выбор прост: либо использоватьпреимущества зарождающегося ИО, сводя при этом к минимуму возможные потери,либо отдаться во власть революционной стихии, вызванной информационнымкризисом.
ИспользованиеInternet/Intranet технологий при создании информационных ресурсов и построенииинформационных систем различного назначения в последнее время сталодоминирующим в мировом информационном пространстве по следующим причинам [2].Эти технологии:
· Позволяюторганизовать с достаточной простотой для пользователя системы поиска нужнойинформации.
· Предъявляютминимальные требования как с технической стороны так и со стороны программногообеспечения к рабочему месту клиента (клиент работает со стандартнымпрограммным обеспечением и единственным требованием является поддержка работыWWW просмотрщика — браузера одной из последних версий1).
· Поддерживаютраспределенные системы хранения информации и множественные методы ее хранения.
· Поддерживаютработу с практически неограниченным объемом разноплановых данных (текст,графика, изображение, звук, видео, векторные карты и др.).
· Предоставляюттехнологически простой способ администрирования информационных систем с одногорабочего места.
· Поддерживаютудаленные методы редактирования и пополнения информации.
1 Историявопроса
Историясоздания компьютерных информационных систем насчитывает несколько десятилетий.За это время были созданы системы по автоматизации деятельности банков,статистических бюро, промышленных предприятий, контор, агентств по бронированиюи продаже билетов и т.д. Однако бурная деятельность по созданию новых системавтоматизации не только не утихает, но и переживает в последнее время заметноеоживление. Эта ситуация связана с все возрастающим значением систем обработкиинформации для выживания компаний в условиях высокой конкуренции, уменьшениемудельной стоимости таких систем, с развитием технологий обработки и храненияинформации, а также качественным изменением ситуации с развитием технологий передачиданных, в частности Internet.
ПервыеИС создавались для больших ЭВМ и имели унитарную структуру, т.е. представлялисобой по сути одну программу, включающую в себя все функции по хранению данных,их обработке и представлению, а также по контролю доступа к данным со стороныпользователей системы. Такая организация ИС имеет ряд достоинств. Это, вчастности, централизованное хранение и обработка информации, простотаадминистрирования системы, а также очень эффективное использованиевычислительных ресурсов — для выполнения важных задач может быть выделена всямощь вычислительной системы.
Однакообработка информации может быть осуществлена и на другой машине. Такой подходпозволил создать на базе ПК и рабочих станций системы распределенной обработкиинформации. Первыми из этого класса систем стали системы, построенные поархитектуре файл-сервер. Основной особенностью этой архитектуры явился полныйотказ от централизованных вычислений. Файл-сервер выполнял лишь функциихранения данных и не принимал участия в их обработке — эта работа былавозложена на клиентские машины.
Однакоочень скоро стало ясно, что полный отказ от централизованного контроля данныхтаит в себе ряд серьезных проблем. Проблемы эти состоят уже не в отказе отдельныхкомпонентов системы, а в логике их совместной работы. Каждое из приложений,работающее с общими данными должно придерживаться ряда весьма жесткихограничений и соглашений, обеспечивающих целостность информации при ее модификацииразличными модулями системы. На контроль целостности данных приходилось весьмасущественная доля программного кода системы, вычислительного ресурса клиентскихмашин и сетевого трафика, и, тем не менее, оставались проблемы, например сбойна клиентской машине в середине выполнения операции мог привести к рассогласованиюданных.
Выходомиз создавшейся ситуации стала разработка концепции клиент-серверных вычислений,сочетающей в себе преимущества централизованной обработки данных унитарныхсистем с преимуществами распределенных вычислений систем типа файл-сервер.Ключевым отличием архитектуры клиент-сервер от архитектуры файл-сервер являетсяабстрагирование от внутреннего представления данных (физической схемы данных).Теперь клиентские программы манипулируют данными на уровне логической схемы.Они уже не заботятся о построении индексов для ускорения выборки данных, ораспределении данных по файлам, выставлении семафоров на обрабатываемые записии т.д.
Всерутинные функции по хранению, обработке и защите данных на так называемом физическомуровне берет на себя система управления базой данных (СУБД). Со времени своегопоявления СУБД также активно эволюционировали, предлагая различные моделилогического представления данных (иерархические, сетевые, реляционные,объектно- ориентированные). Но суть дела от этого не меняется — программе, выполняющейбизнес-функции ИС, уже не надо заботится о том, как и где хранятся данные,следить за их достаточностью и непротиворечивостью, обеспечивать условия побезопасному совместному пользованию данными несколькими пользователями. Оналишь запрашивает СУБД о предоставлении требуемых данных.
Ещеодним преимуществом использования СУБД и архитектуры клиент-сервер по сравнениюс файл-серверным подходом явилась возможность использовать транзакционныймеханизм манипулирования данными. Этот сервис, предоставляемый сервером данных,позволяет объединять несколько действий по изменению данных в одну неделимуюоперацию (транзакцию). Использование транзакций обеспечивает надежную защитуинформации от программно-аппаратных сбоев как на клиентской, так и на сервернойчасти ИС.
Помимоулучшения работоспособности уже готовых программ, архитектура клиент-сервер существеннооблегчает и процесс создания ИС. Как уже было отмечено, прикладномупрограммисту теперь не надо отвлекаться от описания логики работы системы напроблемы хранения данных, индексации таблиц и т.п. Транзакционный механизмпозволяет не заботится о порядке модификации данных внутри одной транзакции и оспособах восстановления их первоначального состояния при обнаруженииисключительных ситуаций. А это в свою очередь сильно расширяет возможностикомандной иерархической разработки проекта — программисту уже не нужно знатьвнутреннее устройство функций написанных другими людьми — он может простопользоваться ими без риска отказа работоспособности уже отлаженных модулей.Кроме того, использование в прикладных программах логического уровняпредставления данных и использование стандартизованных механизмов запроса кСУБД позволило писать платформо-независимые программы клиентской части ИС.
Итак,использование архитектуры клиент-сервер позволило создавать надежные (в смыслецелостности данных) многопользовательские ИС с распределенной базой данных(РБД), поддерживающие графический интерфейс пользователя (ГИП) на клиентскихстанциях, связанных коммуникационной сетью. Основной составной единицей такихсистем стали РБД.2 Основныепринципы, правила построения и функционирования РБД
РБДсостоит из набора узлов, связанных коммуникационной сетью, основнойзадачей которой является передача данных без ошибок и искажения. Коммуникационнаясеть является ядром информационной сети, обеспечивающим передачу инекоторые виды обработки данных.
Коммуникационнойсети присущи следующие свойства:
· каждыйузел — это полноценная СУБД сама по себе;
· узлывзаимодействуют между собой таким образом, что пользователь любого из них можетполучить доступ к любым данным в сети так, как будто они находятся на егособственном узле.
Каждыйузел сам по себе является СУБД. Любой пользователь может выполнить операции над данными насвоём локальном узле точно так же, как если бы этот узел вовсе не входил враспределённую систему. Распределённую систему баз данных можно рассматриватькак партнёрство между отдельными локальными СУБД на отдельных локальных узлах.
Дадимследующее определение: распределенная база данных — это набор файлов(отношений), хранящихся в разных узлах информационной сети и логическисвязанных таким образом, чтобы составлять единую совокупность данных (связьможет быть функциональной или через копии одного и того же файла) [3].
Распределеннаябаза данных предполагает хранение и выполнение функций управления данными внескольких узлах и передачу данных между этими узлами в процессе выполнениязапросов. Разбиение данных в распределенной базе данных может достигаться путемхранения различных таблиц на разных компьютерах или даже хранения разных частейи фрагментов одной таблицы на разных компьютерах. Для пользователя (илиприкладной программы) не должно иметь значения, каким образом распределеныданные между компьютерами. Работать с распределенной базой данных, если онадействительно распределенная, следует так же, как и с централизованной, т. е.размещение базы данных должно быть прозрачно.
Несмотряна то, что распределенная база данных состоит из нескольких локальных базданных, у пользователя должна сохраняться иллюзия работы с централизованнойбазой данных, что вызывает потребность в использовании некоторого общего представленияо данных — глобальной концептуальной схемы. Определение данных в такойконцептуальной схеме должно быть аналогичным определению в централизованной базеданных.
Отличияначинаются, когда требуется хранить данные в нескольких узлах. Чтобы произвестиразбиение данных, нужно секционировать таблицы глобальной схемы на фрагменты.Существует два типа секционирования: горизонтальное и вертикальное. Присекционировании таблицы по строкам выполняется горизонтальное секционирование,при разбиении по столбцам — вертикальное.
Такимобразом, архитектура распределенной СУБД должна содержать информацию осекционировании исходных таблиц базы данных, что предполагает создание дополнительногоуровня — фрагментного.
Самыйвысший уровень архитектуры распределенной СУБД — это интерфейс прикладной программыи интерфейс процессора запросов.
Взглядна базу данных отдельных пользователей представлен в архитектуре отдельным 1-муровнем, что аналогично внешнему уровню в классической архитектуре СУБД.
Дляреализации и объяснения распределенной природы базы данных выделяются двауровня: фрагментный (см. выше) и уровень распределенного представления.Последний показывает географическое распределение данных по рабочим станциям,расположение экземпляра каждого фрагмента.
1—4уровни архитектуры распределенной СУБД относятся к сетевой СУБД.
Однаковыделяют еще локальные СУБД, где определяют представление данных на каждой рабочейстанции.
Каждыйуровень поддерживает различные представления базы данных; каждый уровеньвзаимодействует только со смежными уровнями представления.
Дляуправления распределенной базой данных создается программный комплекс – системауправления распределенной базой данных (СУРБД).
C.J. Date в 1987 году сформулировал один основной принцип и двенадцать правил,которым, по его мнению, должны следовать распределенные базы данных [4].
Основнойпринцип заключается в «прозрачности распределенности». С точки зренияпользователя информации распределенная БД не должна отличаться от локальной БД.Здесь имеется в виду пользователь, формулирующий запросы к базе данных и получающийрезультаты на своем экране (или принтере). Технология его работы не должназависеть от того, в какой конкретной базе находятся нужные ему данные: в его локальнойбазе, в удаленной базе, все необходимые данные в одной и той же базе или вразличных базах данных.
Фундаментальныйпринцип имеет следствием определённые дополнительные правила или цели. Такихцелей всего двенадцать:
1.  Локальная независимость.Узлы в распределённой системе должны быть независимы, или автономны. Локальнаянезависимость означает, что все операции на узле контролируются этим узлом.
2.  Отсутствие опоры нацентральный узел. Локальная независимость предполагает, что все узлы враспределённой системе должны рассматриваться как равные. Поэтому не должнобыть никаких обращений к «центральному» или «главному» узлу с целью получениянекоторого централизованного сервиса.
3.  Непрерывноефункционирование. Распределённые системы должны предоставлять более высокуюстепень надёжности и доступности.
4.  Независимость отрасположения. Пользователи не должны знать, где именно данные хранятсяфизически и должны поступать так, как если бы все данные хранились на их собственномлокальном узле.
5.  Независимость от фрагментации (дробленияданных на множество мелких разрозненных фрагментов). Система поддерживаетнезависимость от фрагментации, если данная переменная-отношение может бытьразделена на части или фрагменты при организации её физического хранения. Вэтом случае данные могут храниться в том месте, где они чаще всегоиспользуются, что позволяет достичь локализации большинства операций и уменьшениясетевого трафика.
6.  Независимость отрепликации. Система поддерживает репликацию данных, если данная хранимая переменная-отношение —или в общем случае данный фрагмент данной хранимой переменной-отношения —может быть представлена несколькими отдельными копиями или репликами, которыехранятся на нескольких отдельных узлах.
7.  Обработка распределённыхзапросов. Суть в том, что для запроса может потребоваться обращение кнескольким узлам. В такой системе может быть много возможных способов пересылкиданных, позволяющих выполнить рассматриваемый запрос.
8.  Управлениераспределёнными транзакциями (последовательность операций, представляющая собойлогическую единицу работы с данными). Существует 2 главных аспекта управлениятранзакциями: управление восстановлением и управление параллельностьюобработки. Что касается управления восстановлением, то чтобы обеспечитьатомарность транзакции в распределённой среде, система должна гарантировать,что все множество относящихся к данной транзакции агентов (агент —процесс, который выполняется для данной транзакции на отдельном узле) илизафиксировало свои результаты, или выполнило откат. Что касается управленияпараллельностью, то оно в большинстве распределённых систем базируется намеханизме блокирования, точно так, как и в нераспределённых системах.
9.  Аппаратная независимость.Желательно иметь возможность запускать одну и ту же СУБД на различныхаппаратных платформах и, более того, добиться, чтобы различные машиныучаствовали в работе распределённой системы как равноправные партнёры.
10.  Независимость от операционной системы.Возможность функционирования СУБД под различными операционными системами.
11.  Независимость от сети.Возможность поддерживать много принципиально различных узлов, отличающихсяоборудованием и операционными системами, а также ряд типов различныхкоммуникационных сетей.
12.  Независимость от типаСУБД. Необходимо, чтобы экземпляры СУБД на различных узлах все вместеподдерживали один и тот же интерфейс, и совсем необязательно, чтобы это были копии одной итой же версии СУБД.
Локальнаяавтономия означает, что управление данными на каждом из узлов распределеннойсистемы выполняется локально. База данных, расположенная на одном из узлов,является неотъемлемым компонентом распределенной системы. Будучи фрагментомобщего пространства данных, она в то же время функционирует как полноценная локальнаябаза данных; управлен ие ею выполняется локально и независимо от других узловсистемы.
Независимостьот центрального узла означает, что в идеальной системе все узлы равноправны инезависимы, а расположенные на них базы являются равноправными поставщикамиданных в общее пространство данных. База данных на каждом из узловсамодостаточна: она включает полный собственный словарь данных и полностьюзащищена от несанкционированного доступа.
Непрерывныеоперации можно трактовать как возможность непрерывного доступа к данным(известное 24 часа в течение суток, семь дней в неделю) в рамках DDB внезависимости от их расположения и вне зависимости от операций, выполняемых на локальныхузлах. Это качество можно выразить лозунгом данные доступны всегда, а операциинад ними выполняются непрерывно.
Прозрачностьрасположения означает полную прозрачность расположения данных. Пользователь,обращающийся к DDB, ничего не должен знать о реальном, физическом размещенииданных в узлах информационной системы. Все операции надданными выполняются безучета их местонахождения. Транспортировка запросов к базам данныхосуществляется встроенными системными средствами.
Прозрачнаяфрагментация трактуется как возможность распределенного (то есть на различныхузлах) размещения данных, логически представляющих собой единое целое.Существует фрагментация двух типов: горизонтальная и вертикальная. Первая означаетхранение строк таблицы на различных узлах (фактически, хранение строк однойлогической таблицы в нескольких идентичных физических таблицах на различныхузлах). Вторая означает распределение столбцов логической таблицы по несколькимузлам.
Прозрачностьтиражирования (асинхронного в общем случае процесса переноса изменений объектовисходной базы данных в базы, расположенные на других узлах распределеннойсистемы) означает, что тиражирование возможно и достигается внутрисистемнымисредствами.
Обработкараспределенных запросов DDB трактуется как возможность выполнения операцийвыборки над распределенной базой данных, сформулированных в рамках обычногозапроса на языке SQL. Toесть операцию выборки из распределенной базы данных можно сформулировать спомощью тех же языковых средств, что и операцию над локальной базой данных. Оптимизатор распределенных запросов учитывает такие параметры, какразмер таблиц, статистику распределения данных по узлам, объем данных,передаваемых между узлами, скорость коммуникационных линий, структуры храненияданных, соотношение производительности процессоров на разных узлах и т. д. Оталгоритмов работы оптимизатора распределенных запросов впрямую зависит скоростьработы базы данных с такими запросами.
Обработкараспределенных транзакций DDB можно трактовать как возможность выполненияопераций обновления распределенной базы данных (INSERT, UPDATE, DELETE), неразрушающее целостность и согласованность данных. Эта цель достигаетсяприменением двухфазового или двухфазного протокола фиксации транзакций(two-phase commit protocol), ставшего фактическим стандартом обработкираспределенных транзакций. Его применение гарантирует согласованное изменение данныхна нескольких узлах в рамках распределенной, или глобальной транзакции.
Независимостьот оборудования означает, что в качестве узлов распределенной системы могутвыступать компьютеры любых моделей и производителей — от мэйнфреймов доперсоналок.
Независимостьот операционных систем как качество вытекает из предыдущего и означает многообразиеоперационных систем, управляющих узлами распределенной системы.
Прозрачностьсети означает, что спектр поддерживаемых конкретной СУБД сетевых протоколов недолжен быть ограничением системы с распределенными базами данных. Данноекачество формулируется максимально широко: в распределенной системе возможнылюбые сетевые протоколы.
Независимостьот баз данных означает, что в распределенной системе могут мирно сосуществоватьСУБД различных производителей, и возможны операции поиска и обновления в базахданных различных моделей и форматов.распределённая база данные компьютерный3 Проблемы распределенных баз данных
Исходяиз определения Дэйта, распределенную базу данных в общем случае можнорассматривать как слабосвязанную сетевую структуру, узлы которой представляютсобой локальные базы данных. Локальные базы данных автономны, независимы исамоопределены; доступ к ним обеспечивается от различных поставщиков. Связи междуузлами — это потоки тиражируемых данных. Топология DDB варьируется в широкомдиапазоне: возможны варианты иерархии, структур типа звезда и т. д. В целомтопология DDB определяется географией информационной системы и направленностьюпотоков тиражирования данных.
Рассмотримтеперь проблемы реальных распределенных баз данных [5]. Проблемыцентрализованных СУБД существуют и здесь, однако децентрализация добавляет новые:
а)Какова общая модель данных распределенной системы? Мы должны иметь единуюконцептуальную схему всей сети. Это обеспечит логическую прозрачность данныхдля пользователя, в результате чего он сможет формировать запрос ко всей базе,находясь за отдельным терминалом (т. е. как бы работая с централизованной базойданных).
б)Необходима схема, определяющая местонахождение данных в сети. Это обеспечитпрозрачность размещения данных, благодаря которой пользователь может неуказывать, куда переслать запрос, чтобы получить требуемые данные.
в)Распределенные базы данных могут быть однородными или неоднородными поаппаратным и программным средствам. Проблему неоднородности сравнительно легкорешить, если распределенная база является неоднородной по аппаратным средствам,но однородной по программным средствам (одинаковые СУБД в узлах). Если же вузлах распределенной системы используются разные СУБД, необходимы средствапреобразования структур данных и языков. Это должно обеспечить прозрачностьпреобразования в узлах распределенной базы данных.
г)Управление словарями. Для обеспечения всех видов прозрачности в распределеннойбазе данных нужны программы, управляющие многочисленными справочниками илисловарями.
д)Методы выполнения запросов в распределенной базе данных отличаются отаналогичных методов централизованных СУБД, так как отдельные части запроса нужновыполнять в месторасположении соответствующих данных и передавать частичныерезультаты на другие узлы; при этом должна быть обеспечена координация всехпроцессов.
е)В распределенной базе данных нужен сложный механизм управления одновременнойобработкой, который, в частности, должен обеспечивать синхронизацию приобновлениях информации, это гарантирует непротиворечивость данных.
ж)Развитая методология распределения и размещения данных, включая разбиение,является одним из основных требований к распределенной базе данных.
Базаданных физически распределяется по узлам компьютерной информационной системыпри помощи фрагментации и репликации (тиражирования) данных.4 Особенностираспределенных баз данных
Всегодняшнем быстро меняющемся компьютерном мире сосуществуют по крайней меретри основные идеологии: клиент — сервер, Web и распределенные объекты (DCOM,CORBA). Внутри каждого направления также существует большое количество решенийи стандартов от разных производителей. Сегодняшняя ситуация вызывает оченьбольшую озабоченность независимых разработчиков и потребителей: Какуютехнологию выбрать и что будет со мной и моим бизнесом, если я примунеправильное решение? При этом очевидно, что цена ошибки будет весьма высока,кроме того большие средства уже вложены в разработку и эксплуатацию ужесуществующих систем.Клиент-сервер
Термин«клиент-сервер» означает такую архитектуру программного комплекса, вкоторой его функциональные части взаимодействуют по схеме«запрос-ответ». Если рассмотреть две взаимодействующие части этогокомплекса, то одна из них (клиент) выполняет активную функцию, т. е. инициируетзапросы, а другая (сервер) пассивно на них отвечает. По мере развития системыроли могут меняться, например некоторый программный блок будет одновременновыполнять функции сервера по отношению к одному блоку и клиента по отношениюк другому [6].
Любаяинформационная система должна иметь минимум три основные функциональные части — модули хранения данных, модули обработки и модули интерфейса с пользователем.Каждая из этих частей может быть реализована независимо от двух других.Например, не изменяя программ, используемых для хранения и обработки данных,можно изменить интерфейс с пользователем таким образом, что одни и те же данныебудут отображаться в виде таблиц, графиков или гистограмм. Не меняя программпредставления данных и их хранения, можно изменить программы обработки,например изменив алгоритм полнотекстового поиска. И наконец, не меняя программпредставления и обработки данных, можно изменить программное обеспечение дляхранения данных, перейдя, например, на другую файловую систему.
Вклассической архитектуре клиент-сервер приходится распределять три основныечасти приложения по двум физическим модулям. Обычно ПО хранения данных располагаетсяна сервере (например, сервере базы данных), интерфейс с пользователем — настороне клиента, а вот обработку данных приходится распределять междуклиентской и серверной частями. В этом-то и заключается основной недостатокдвухуровневой архитектуры, из которого следуют несколько неприятныхособенностей, сильно усложняющих разработку клиент-серверных систем.
Приразбиении алгоритмов обработки данных необходимо синхронизировать поведениеобеих частей системы. Все разработчики должны иметь полную информацию опоследних изменениях, внесенных в систему, и понимать эти изменения. Этосоздает большие сложности при разработке клиент-серверных систем, их установкеи сопровождении, поскольку необходимо тратить значительные усилия накоординацию действий разных групп специалистов. В действиях разработчиков частовозникают противоречия, а это тормозит развитие системы и вынуждает изменятьуже готовые и проверенные элементы.
Чтобыизбежать несогласованности различных элементов архитектуры, пытаются выполнятьобработку данных на одной из двух физических частей — либо на стороне клиента(«толстый» клиент), либо на сервере («тонкий» клиент, илиархитектура, называемая «2,5- уровневый клиент-сервер»). Каждыйподход имеет свои недостатки. В первом случае неоправданно перегружается сеть,поскольку по ней передаются необработанные, а значит, избыточные данные. Крометого, усложняется поддержка системы и ее изменение, так как замена алгоритмавычислений или исправление ошибки требует одновременной полной замены всехинтерфейсных программ, а иначе могут возникнуть ошибки или несогласованностьданных. Если же вся обработка информации выполняется на сервере (когда такоевообще возможно), то возникает проблема описания встроенных процедур и ихотладки. Дело в том, что язык описания встроенных процедур обычно являетсядекларативным и, следовательно, в принципе не допускает пошаговой отладки.Кроме того, систему с обработкой информации на сервере абсолютно невозможноперенести на другую платформу, что является серьезным недостатком.
Многиесредства быстрой разработки приложений (RAD), которые работают с различнымибазами данных, реализует первую стратегию, т. е. «толстый» клиентобеспечивает интерфейс с сервером базы данных через встроенный SQL.Такой вариант реализации системы с «толстым» клиентом, кроме перечисленныхвыше недостатков, обычно обеспечивает недопустимо низкий уровень безопасности.Например, в банковских системах приходится всем операционистам давать права назапись в основную таблицу учетной системы. Кроме того, данную систему почтиневозможно перевести на Web-технологию, так как для доступак серверу базы данных используется специализированное клиентское ПО.
Рассмотренныевыше модели имеют следующие недостатки.
1. «Толстый»клиент:
· сложностьадминистрирования;
· усложняетсяобновление ПО, поскольку его замену нужно производить одновременно по всейсистеме;
· усложняетсяраспределение полномочий, так как разграничение доступа происходит не подействиям, а по таблицам;
· перегружаетсясеть вследствие передачи по ней необработанных данных;
· слабаязащита данных, поскольку сложно правильно распределить полномочия.
2. «Толстый»сервер:
· усложняетсяреализация, так как языки типа PL/SQL не приспособлены для разработки подобногоПО и нет хороших средств отладки;
· производительностьпрограмм, написанных на языках типа PL/SQL, значительно ниже, чем созданных надругих языках, что имеет важное значение для сложных систем;
· программы,написанные на СУБД-языках, обычно работают недостаточно надежно; ошибка в нихможет привести к выходу из строя всего сервера баз данных;
· получившиесятаким образом программы полностью непереносимы на другие системы и платформы.
Длярешения перечисленных проблем используются многоуровневые (три и более уровней)архитектуры клиент-сервер.
Многоуровневаяархитектура клиент-сервер — разновидность архитектуры клиент-сервер, вкоторой функция обработки данных вынесена на один или несколько отдельныхсерверов. Это позволяет разделить функции хранения, обработки и представленияданных для более эффективного использования возможностей серверов и клиентов.
Частныйслучаи многоуровневой архитектуры — трёхуровневая (трехзвенная) архитектура.
Трёхзвеннаяархитектура предполагает наличие следующих компонентов приложения:клиентское приложение (обычно говорят «тонкий клиент» или терминал),подключенное к серверу приложений, который в свою очередь подключен ксерверу базы данных.
«Тонкийклиент» или Терминал — это интерфейсный (обычно графический)компонент, который представляет собственно приложение для конечногопользователя. Первый уровень не должен иметь прямых связей с базой данных (потребованиям безопасности), быть нагруженным основной бизнес-логикой ихранить состояние приложения (по требованиям надежности). На первыйуровень может быть вынесена и обычно выносится простейшая бизнес-логика:интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений надопустимость и соответствие формату, несложные операции (сортировка,группировка, подсчет значений) с данными, уже загруженными на терминал.
Серверприложений располагается на втором уровне. На втором уровне сосредоточенабо́льшая часть бизнес-логики. Вне его остаются фрагменты, экспортируемыена терминалы, а также погруженные в третий уровень хранимые процедуры итриггеры.
Сервербазы данных обеспечивает хранение данных и выносится на третий уровень.Обычно это стандартнаяреляционная или объектно-ориентированная СУБД. Если третийуровень представляет собой базу данных вместе с хранимымипроцедурами, триггерами и схемой, описывающей приложение в терминахреляционной модели, то второй уровень строится как программный интерфейс,связывающий клиентские компоненты с прикладной логикой базы данных.
Впростейшей конфигурации физически сервер приложений может быть совмещён ссервером базы данных на одном компьютере, к которому по сети подключается одинили несколько терминалов.
В«правильной» (с точки зрения безопасности, надёжности, масштабирования)конфигурации сервер базы данных находится на выделенном компьютере(или кластере), к которому по сети подключены один или несколько серверовприложений, к которым, в свою очередь, по сети подключаются терминалы.
Технологияклиент-сервер по праву считается одним из «китов», на которыхдержится современный мир компьютерных сетей. Но те задачи, для решения которыхона была разработана, постепенно уходят в прошлое, и на сцену выходят новыезадачи и технологии, требующие переосмысления принципов клиент-серверныхсистем. Одна из таких технологий — World Wide Web.
/>/>Многоуровневыеклиент-серверные системы достаточно легко можно перевести на Web-технологию — для этого достаточно заменить клиентскую часть универсальным илиспециализированным браузером, а сервер приложений дополнить Web-сервером и небольшимипрограммами вызова процедур сервера. Реализация этого принципа основана наиспользовании либо HTTP-SQL, либо API (организация динамических приложений настороне сервера), либо Java (JDBC — организация динамических приложений настороне клиента) интерфейсов для формирования запросов пользователя к базамданных или к другим информационным источникам на получение и обработкуинформации.
Следуетотметить и тот факт, что в трехуровневой системе по каналу связи между серверомприложений и базой данных передается достаточно много информации. Однако это незамедляет вычислений, так как для связи указанных элементов можно использоватьболее скоростные линии. Это потребует минимальных затрат, поскольку оба сервераобычно находятся в одном помещении. Таким образом, увеличивается суммарнаяпроизводительность системы — над одной задачей теперь работают два различныхсервера, а связь между ними можно осуществлять по наиболее скоростным линиям сминимальными затратами средств. Правда, возникает проблема согласованностисовместных вычислений, которую призваны решать менеджеры транзакций — новыеэлементы многоуровневых систем./>Менеджеры транзакций
Особенностьюмногоуровневых архитектур является использование менеджеров транзакций (МТ),которые позволяют одному серверу приложений одновременно обмениваться данными снесколькими серверами баз данных. Хотя серверы Oracle имеют механизм выполненияраспределенных транзакций, но если пользователь хранит часть информации в БДOracle, часть в БД Informix, а часть в текстовых файлах, то без менеджератранзакций не обойтись. МТ используется для управления распределеннымиразнородными операциями и согласования действий различных компонентов информационнойсистемы. Следует отметить, что практически любое сложное ПО требуетиспользования менеджера транзакций. Например, банковские системы должныосуществлять различные преобразования представлений документов, т. е. работатьодновременно с данными, хранящимися как в базах данных, так и в обычных файлах,- именно эти функции и помогает выполнять МТ.
Менеджертранзакций — это программа или комплекс программ, с помощью которых можносогласовать работу различных компонентов информационной системы [7]. ЛогическиMT делится на несколько частей:
· коммуникационныйменеджер (Communication Manager) контролирует обмен сообщениями междукомпонентами информационной системы;
· менеджеравторизации (Authorisation Manager) обеспечивает аутентификацию пользователей ипроверку их прав доступа;
· менеджертранзакций (Transaction Manager) управляет распределенными операциями;
· менеджерведения журнальных записей (Log Manager) следит за восстановлением и откатомраспределенных операций;
· менеджерблокировок (Lock Manager) обеспечивает правильный доступ к совместноиспользуемым данным.
Обычнокоммуникационный менеджер объединен с авторизационным, а менеджер транзакцийработает совместно с менеджерами блокировок и системных записей. Причем такойменеджер редко входит в комплект поставки, поскольку его функции (ведениезаписей, распределение ресурсов и контроль операций), как правило, выполняетсама база данных (например, Oracle).
Первыеменеджеры транзакций появились в начале 70-х гг. (например, CICS); с тех порони незначительно изменились идеологически, но весьма существенно — технологически. Наибольшие идеологические изменения произошли вкоммуникационном менеджере, так как в этой области появились новыеобъектно-ориентированные технологии (CORBA, DCOM и т.д.). Из-за бурногоразвития коммуникационных средств в будущем следует ожидать широкогоиспользования различных типов менеджеров транзакций.
Такимобразом, многоуровневая архитектура клиент-сервер позволяет существенноупростить распределенные вычисления, делая их не только более надежными, но иболее доступными. Появление таких средств, как Java, упрощает связь сервераприложений с клиентами, а объектно-ориентированные менеджеры транзакцийобеспечивают согласованную работу сервера приложений с базами данных. Врезультате создаются все предпосылки для создания сложных распределенныхинформационных систем, которые эффективно используют все преимуществасовременных технологий.
Однимиз основных требований к распределенной базе данных остается требование наличияразвитой методологии распределения и размещения данных, включая разбиение.Фрагментация данных
Базаданных физически распределяется по узлам компьютерной информационной системыпри помощи фрагментации и репликации (тиражирования) данных.
Отношения,принадлежащие реляционной базе данных, могут быть фрагментированы нагоризонтальные или вертикальные разделы.
Горизонтальнаяфрагментация реализуется при помощи операции селекции, которая направляеткаждый кортеж отношения в один из разделов, руководствуясь предикатомфрагментации. Например, для отношения Employee (Сотрудник) возможнафрагментация в соответствии с территориальным распределением рабочих местсотрудников.
Тогдазапрос «получить информацию о сотрудниках компании» может быть сформулировантак:
SELECT * FROM employee@donetsk,
employee@kiev
Нарисунке 1 изображен принцип разделения данных при горизонтальной фрагментации.
Нарисунке 2 приведен пример горизонтальной фрагментации.
/>
Рис.1 Горизонтальная фрагментация
/>
Рис.2 Пример горизонтальной фрагментации
Привертикальной фрагментации отношение делится на разделы при помощи операции проекции.Например, один раздел отношения Employee может содержать поля Номер_сотрудника(emp_id), ФИО_сотрудника (emp_name), Адрес_сотрудника (emp_adress), а другой –поля Номер_сотрудника (emp_id), Оклад (salary), Руководитель (emp_chief).
Тогдазапрос «получить информацию о заработной плате сотрудников компании»будет выглядеть следующим образом:
SELECT employee.emp_id,
emp_name,
salary
FROM employee@donetsk,
employee@kiev
ORDER BYemp_id
Нарисунках 3 и 4 изображены сущность и пример вертикальной фрагментации.
/>
Рис.3 Вертикальная фрагментация

/>
Рис.5. Пример вертикальной фрагментации
Засчет фрагментации данные приближаются к месту их наиболее интенсивногоиспользования, что потенциально снижает затраты на пересылки; уменьшаются такжеразмеры отношений, участвующих в пользовательских запросах. Однако практическидобиться ускорения выполнения запросов, затрагивающих фрагментированные отношения,очень трудно. Основная проблема состоит в резком расширении пространства поискавариантов выполнения запросов, с которым должен работать оптимизатор запросов.Репликация данных
Второйспособ распределения данных – репликация (рис.6). Репликация (илитиражирование) означает создание дубликатов данных. Репликаты – это множестворазличных физических копий некоторого объекта базы данных (обычно таблицы), длякоторых поддерживается синхронизация (идентичность) с некоторой«главной» копией.
/>
Рис.6. Репликация
Теоретическизначения всех данных в тиражированных объектах должны автоматически инезамедлительно синхронизироваться друг с другом. (На практике это правилообычно несколько ослабляется.) В некоторых системах копии используются исключительнов режиме чтения и обновляются в соответствии с заданным расписанием. В другихсредах допускается модификация отдельных значений в копиях, и эти измененияраспространяются в соответствии с процедурами планирования и координации. Нарисунках 7, 8, 9 показаны различные модели тиражирования.
Прирепликации фрагменты данных тиражируются с учетом спроса на доступ к ним. Этополезно, если доступ к одним и тем же данным нужен из приложений, выполняющихсяна разных узлах. В таком случае, с точки зрения экономии затрат, болееэффективно будет поддерживать копии данных на всех узлах, чем непрерывнопересылать данные между узлами.
/>
Рис.7. Одновременное обновление (с управлением параллелизмом)
 
/>
Рис.8 Распространенные обновления
Основнойпроблемой репликации данных является то, что обновление любого логическогообъекта должно распространяться на все хранимые копии этого объекта. Трудностивозникают из-за того, что некоторый узел, содержащий данный объект, может бытьнедоступен (например, из-за краха системы или данного узла) именно в моментобновления. В таком случае очевидная стратегия немедленного распространенияобновлений на все копии может оказаться неприемлемой, поскольку предполагается,что обновление (а значит и исполнение транзакции) будет провалено, если одна изкопий будет недоступна в текущий момент.
/>
Рис.9. Запланированная синхронизация дубликатов только для чтения
В современныхСУБД функции репликации выполняет, как правило, специальный модуль – сервертиражирования данных, называемый репликатором (так устроеныСУБД CA – OpenIngress и Sybase).В Informix-OnLine Dynamic Server репликатор встроен в сервер,вOracle для использования репликации необходимо приобрести дополнительнуюопцию Replication Option.
Спецификациямеханизмов репликации зависит от используемой СУБД. Простейший вариант –использование “моментальных снимков” (snapshot).Каталог распределенной системы
Важнымкомпонентом структуры логического уровня РБД является сетевой каталог,который обеспечивает эффективное выполнение основных функций управления РБД исодержит всю информацию, необходимую для обеспечения независимости размещения,фрагментации и репликации. Существует несколько вариантов хранения системногокаталога. Ниже перечислены некоторые из этих вариантов.
1.Централизированныйкаталог. Весь каталог храниться в одном м месте, т.е. на центральном узле.
2.Полностью реплицированный каталог. Весь каталог полностью хранится на каждомузле.
3.Секционированный каталог. На каждом узле содержится его с собственный каталогдля объектов, хранимых на этом узле. Общий каталог я является объединением всехразъединенных локальных каталогов.
4. Комбинацияпервого и третьего вариантов. На каждом узле с содержится его собственныйкаталог (как в п.3), кроме того, на одном центральном узле хранитсяунифицированная копия всех этих локальных каталогов (как в п.1).
Длякаждого подхода характерны определенные недостатки и проблемы. В первомподходе, очевидно, не достигается «независимость от центральногоузла». Во втором утрачивается автономность функционирования, поскольку приобновлении каждого каталога это обновление придется распространять на каждыйузел. В третьем выполнение не локальных операций становится весьма дорогостоящим(для поиска удаленного объекта потребуется в среднем осуществить доступ кполовине имеющихся узлов). Четвертый подход более эффективен, чем третий(для поиска удаленного объекта потребуется осуществить доступ толькок одному удаленному каталогу), но в нем снова не достигается«независимость от центрального узла».5 Internet/Intranetтехнологии
ИспользованиеInternet/Intranet технологий при создании информационных ресурсов и построенииинформационных систем различного назначения в последнее время сталодоминирующим в мировом информационном пространстве по следующим причинам. Этитехнологии [2]:
Позволяюторганизовать с достаточной простотой для пользователя системы поиска нужнойинформации.
Предъявляютминимальные требования как с технической стороны так и со стороны программногообеспечения к рабочему месту клиента (клиент работает со стандартнымпрограммным обеспечением и единственным требованием является поддержка работыWWW просмотрщика — браузера одной из последних версий1).
Поддерживаютраспределенные системы хранения информации и множественные методы ее хранения.
Поддерживаютработу с практически неограниченным объемом разноплановых данных (текст,графика, изображение, звук, видео, векторные карты и др.).
Предоставляюттехнологически простой способ администрирования информационных систем с одногорабочего места.
Поддерживаютудаленные методы редактирования и пополнения информации.
 
/>
Рис10. Взаимодействие с БД через Интернет
Основойпостроения информационных систем с использованием Intranet технологии являетсяорганизация системы доступа к информации через WWW сервис Internet.Internet технология позволяет оперативно управлять и актуализироватьинформацию, хранящуюся в базах данных через просмотрщик (браузер) WWW страниц (рис.10).
Основнойпринцип, заложенный в Intranet технологию создания информационных ресурсов ипостроения информационных систем, заключается в разделении вычислительныхресурсов как между многочисленными серверами, расположенными в различных концахсети, так и между серверами и клиентами (компьютер на котором работает конечныйпользователь). Реализация этого принципа основана на использовании либоHTTP-SQL (формирование SQL запросов к БД с WWW сервера), либо API (организациядинамических приложений на стороне сервера), либо Java (JDBC — организациядинамических приложений на стороне клиента) интерфейсов для формированиязапросов пользователя к базам данных или к другим информационным источникам наполучение и обработку информации.
Internetтехнология позволяет удачно сочетать возможности гипертекстового оформленияинформации c использованием возможностей современных СУБД. Причем со стороныклиента полностью унифицируются запросы на поиск и представление информации, атакже получение аналитических справок и данных из информационных систем.
Вместес тем рассматриваемые технологии позволяют использовать в сетевом режиме ужеимеющиеся базы данных, не затрачивая при этом средства на их унификацию и приведениек единому стандарту. Основные затраты здесь направлены только насоответствующие описания баз данных и запросов для HTTP-SQL интерфейса или длясервера обработки транзакций, при этом базы данных могут находится на различныхмашинах, расположенных на произвольном расстоянии друг от друга. Использованиеданной технологии позволяет решать весь спектр задач, присущий информационнойсистеме, включая удаленный ввод и редактирование данных.
Математическоеобеспечение для организации HTTP-SQL интерфейса является свободнораспространяемым как для MS Windows NT систем, так и для некоммерческих UNIXплатформ. СУБД можно использовать либо имеющиеся в наличии, либо приобретатьсетевые (например, Informix, Oracle, MS SQL).
Любаяинформационная система, построенная на основе клиент-серверных Интернеттехнологий, должна содержать следующие серверные компоненты:
шлюз-сервер,управляющий правами доступа к информационной системе;
WWW-сервер;
сервербаз данных;
серверприложений и(или) сервер обработки транзакций.
ВзаимодействиеWWW сервера с базами данных может быть организовано двумя способами:
черезсервер транзакций (см. рис.11);
черезAPI интерфейс WWW сервера или сервера приложений (см. рис.12,13 ).
Использованиекоммерческих серверов транзакций, подразумевает организацию более менеестандартного интерфейса, а использование API приложений дает полную волюразработчикам
/>
Рис11. Взаимодействие с БД с использованием сервера транзакций

Организациявзаимодействия с базами данных, использованием API, возможна по одной изприведенных на рис.12,13 схеме.
На рис.3 представленастандартная схема формирования информационной системы, основанная как наиспользовании активных программ на сервере и стандартных средств доступа к БДкак, например, Windows-NT ODBC интерфейс доступа к БД со стороны сервера и JDBCJava интерфейс доступа к БД со стороны клиента.
/>/>/>
Рис12. Использование API интерфейса WWW сервера
Схема,изображенная на рис.4, соответствует информационной системе использующейсервер приложений.
/>
Рис13. Использование сервера приложений и API интерфейса WWW сервера
Вслучае размещения базы данных на разных машинах, находящихся в различныхлокальных сетях, необходимо строить доверительные базы с обязательным применениемшлюзов для обеспечения прав доступа (см. рис.14 ).
/>
Рис14. Организация доверительных БД — работа через машину-посредник (шлюз)
Заключение
Воснове любых технологических потрясений лежит простой экономический расчет:выгодно — невыгодно. В основе нынешней ситуации в развитии распределенныхсистем также лежит экономическое обоснование — стоимость передачи данных посети становится меньше стоимости вычислений на клиентской машине и этатенденция имеет устойчивый характер. Взрывной рост Internet, который многиесвязывают с «демократическими свободами» или развитием новой технологииимеет в своей основе все тоже простое экономическое обоснование — этатехнология экономически выгодна. Отсюда проистекают и те изменения в миретехнологий свидетелями которых мы являемся: стремительный рост пропускнойспособности каналов (Internet — 2, новые более быстрые модемы, спутниковыеканалы для домашнего пользователя ), присутствие в сети большинства корпорацийи масс медиа, электронная коммерция и банки … На основе этих технологий вырослиновые направления бизнеса, а распространенность Internet растет темпаминевиданными в отрасли (быстрее телефонии и телевидения).
Однако,если присмотреться поближе к этой технологии, то в ней нет ничего революционного,за исключением того, как уже известные решения применены в новой области. Давноизвестны языки разметки (TeX), протоколы передачи данных (TCP) и удаленныхсервисов (NSF, POP), распределенные транзакции (мониторы транзакций),платформопереносимые языки (С, Perl) и т.д.
Весьсекрет новых решений в заложенной изначально совместимости, опирающейся наоткрытые стандарты. Именно поэтому основная битва идет вокруг стандартов, чтобыне декларировали «участники забега». Решения, основанные настандарте, являются экономически выгодными, т.к. гарантируют возврат инвестицийчтобы не происходило на рынке.
Втоже время сама технология пока достаточно слаба, как и любая технология вначале своего пути. Требования к системным ресурсам не уменьшились. Однако, какуже было показано в основе революции лежит общая экономия средств, которая принынешней дешевизне компьютерных ресурсов и дороговизне человеческих получаетсявесьма значительная.
Созданиереальных прикладных систем на основе Internet технологии, в свою очередь,катализировало изменения в самой технологии. Впервые ставится под вопроснеобходимость священной коровы — Операционной Системы. Чрезвычайно фетишизированнаяусилиями Microsoft ОС, тем не менее, всего лишь служебная функция необходимаядля выполнения реальных приложений (недаром Sun и Oracle заключили кросслицензионноесоглашение, позволяющее встраивать функции ОС в СУБД и СУБД в ОС).
Значительнопересмотрены и другие концепции, казавшиеся незыблемыми. К примеру, технологияклиент — сервер построена на обращении клиента к серверу по частному протоколу(SQL Net в случае). Находящийся на стороне сервера listener обеспечиваетсоединение и обработку запроса. Возникает вопрос — а почему к СУБД можно обращатьсятолько по одному специальному протоколу? Ведь при построении приложения вInternet приходится несколько раз проводить преобразование протоколов http вSGI (Perl, сервлеты и т.п.) и затем в SQL. Когда можно просто поручитьlistener'у иметь возможность обрабатывать запросы по http, POP3, IMAP4, NFS идругим. Подобная концепция реализованная в Oracle8i позволяет реальнопревратить реляционную СУБД в хранилище информации в Internet. Подобные решениякардинальным образом переворачивают наши представления о правильно построеннойинформационной системе, но это неизбежная дань за участие в очереднойтехнологической революции.
Подходкорпорации Oracle основан на полном признании сложившихся стандартов и ихинтеграцию (тоже на основе стандартов). Для Oracle вопрос не ставится как«или» клиент-сервер «или» Web «или»распределенные объекты, решение Oracle являются объединением лучших черттехнологий клиент-сервер (мощность, устойчивость, транзакции), Web (легкостьраспространения и управления, тонкий клиент) и распределенных объектов(компонентное программное обеспечение, интеграция решений от разныхпроизводителей и распределение задачи по всем компьютерам в сети). Такаяинтеграция возможна на основе стандартов CORBA 2.0 (Архитектура ДиспетчераОбъектных Запросов), HTTP/HTML, IIOP (Internet Inter Object Protocol),COM/DCOM (стандарт Microsoft) и Java.
Воснове подхода Oracle лежит WRB (Диспетчер Объектных Запросов Web), связанный сWeb сервером и управляющий всеми объектами в сети. Такие объекты могут располагатьсяна сервере приложений (любом сервере в сети), в базе данных (используя всевозможности Базы Данных Oracle 7 и особенно объектные расширения Oracle 8) илина клиентской части (браузере). При этом все объекты (картриджи) предоставляютДиспетчеру Объектных Запросов свой интерфейс и после этого могут вызывать другдруга, создавать новые экземпляры объектов и т.д. Управление объектами, ихустановка, секретность, регулировка загрузки серверов и др. возможностиобеспечиваются WRB. Такая архитектура называется Архитектура СетевыхВычислений.
Такимобразом любое приложение используемое в Архитектуре Сетевых Вычисленийстановится независимым от языка программирования (Java, C/C++, SQL, VisualBasic и др.), независимым от типа архитектуры (клиент-сервер, web) и может бытьлегко интегрировано с любым другим приложением (картриджем), даже разработаннымдругим производителем.
Подобныйподход позволяет разрабатывать любые приложения для Web. При этом страницы HTMLне существуют до появления запроса пользователя и генерятся в видепоследовательности команд HTML по запросу пользователя и содержат только туинформацию, которая запрашивалась в запросе. Дальнейшим расширением«виртуальных» HTML страниц по запросу является использование Javaapplets передаваемых на браузер, создающие интерфейс аналогичный интерфейсуэкранных клиент-сервер с аналогичной функциональностью и поддержкой транзакцийи секретности (SSL 3.0).
Имеяв своем арсенале Web сервер с функциональностью недостижимой при другихподходах Oracle также предлагает средства разработки приложений уровня предприятия.Это Designer/2000 — лучшее на сегодня CASE решение, которое теперь имеетгенератор не только для клиент-сервер, но и для Web, Developer/2000 — мощноесредство разработки приложений, устанавливаемое как картридж на сервереприложений (под управлением WRB) и автоматически генерящее полный набор Javaапплетов для работы на браузере, Sedona — мощное объектно-ориентированное средстводля создания и управления распределенными объектами.
Система,построенная по технологии распределенных объектов, состоит из набора компонент(объектов), взаимодействующих друг с другом. При этом объекты, как правило,разбросаны по сети и выполняются отдельно друг от друга.
/>
Рисунок1: Модель распределенных объектов
/>
DCOMи CORBA основываются на коммуникации типа клиент-сервер. Запрашивая сервис,клиент вызывает метод, реализуемый удаленным объектом, действующим в ролисервера. Сервис, предоставляемый объектом, инкапсулируется с помощьюинтерфейса, определенного на языке IDL. Именно собственный язык IDL являетсяодной из изюминок CORBA. Вообще, существуют три различных языка описаний пододним и тем же названием: OMG IDL (очевидно, используется в CORBA), MicrosoftIDL (разработан для технологии DCOM, но в силу двоичного представления объектовне играет в этой технологии ключевой роли) и OSF IDL. Однако, по сравнению сDCOM, CORBA имеет ряд существенных отличий.
ТехнологияCORBA изначально проектировалась для создания распределенных систем. В силуэтого сервер объектов и клиентские программы, в отличие от COM/DCOM, втехнологии CORBA, как правило, располагаются на разных машинах. Взаимодействиемежду клиентом и сервером происходит следующим образом. В процессе клиентаимеется объект-посредник, именуемый stub (или Client-Side Stab). Он является полномочнымпредставителем сервера и исполняет функции, во многом сходные с функциямиобъекта Proxy в технологии DCOM. Именно к stub при помощи интерфейса объектаобращается программа-клиент так, как будто stub и являет собой объект. Далееstub перенаправляет запрос клиента к особому объекту, который действует такжена машине клиента. Этот объект называется ORB (Object Required Broker, брокеробъектных запросов). Получив запрос, ORB формирует широковещательное сообщениево внешнюю сеть. На это сообщение откликается один из объектов Smart Agent,который функционирует на одном из компьютеров сетевого окружения (локальнаясеть или Интернет). Smart Agent знает, где расположены соответствующие серверыобъектов (фактически это как бы виртуальный сетевой каталог, гдезарегистрированы некоторые серверы), и перенаправляет запрос на нужный сервер.На сервере пакет запроса принимает еще один объект ORB, который дешифруетзапрос и пересылает его следующему объекту — BOA (Basic Object Adapter, базовыйадаптер объектов). Роль объекта BOA заключается в фильтрации, кэшированиизапросов и, соответственно, разграничении доступа к объекту сервера. Еслизапрос пропущен BOA, то он попадает в объект сервера skeleton. При этом вадресном пространстве сервера создается требуемый объект, skeleton помещаетаргументы вызова в стек объекта и реализует собственно вызов. Используя объектBOA, skeleton также регистрирует созданный серверный CORBA-объект с помощьюSmart Agent, а также сообщает о доступности, факте создания и о готовностиобъекта принимать запросы клиента. Далее следует обратная связь по описаннойцепочке объектов
Какойвыход из этой ситуации? Каждая компания предлагает свое частное решение уверяя,что оно наилучшее. К счастью это уже не первый случай революционной ситуации вкомпьютерной индустрии и мы можем учесть уроки предыдущих кризисов. Опытпоказывает, что выигрывают те, кто выбирает общепризнанные стандарты.
Литература
 
1. Е.Н. Коровин.Методология прогнозирования и оптимального управления территориальнораспределенными социально-экономическими системами на основе трансформацииинформации и многовариантного моделирования: Дис.… д-ра техн. наук:05.13.01, 05.13.10 Воронеж, 2005 356 с. РГБ ОД, 71:06-5/194
2. Ю.И. />Шокин,А.М. Федотов  Информационные технологии. Internet // Вычислительныетехнологии Том 2, N 3, 1997.
3 M. TamerOzsu, Patrick Valduriez. Distributed and parallel database systems. //Открытые системы. # 4/1996.
4. Date C.J. 1987. What isdistributed database? InfoDB, 2:7
5. Г.М. Ладыженский.Технология «клиент-сервер» и мониторы транзакций. //Открытыеинформационные системы
6. В.И. Коржов, Многоуровневые системыклиент-сервер // Сети, #06/1997
7. В.А. Гладцын, К.В. Кринкин,В.В. Яновский. Сервис-ориентированная архитектура, стандарты, алгоритмы, протоколы.—СПб.: Издательство СПбГЭТУ «ЛЭТИ», 2006;