ГЛАВА 4
Распределенные системы
Общая тенденция развития систем управления базами данных показывает, что распределенные системы получают все большее развитие и распространение. Этому способствует как мировая глобализация, которая приводит к ускорению процессов централизации и децентрализации информационных систем, так и технический прогресс в области хранения и передачи данных. Растут объемы и быстродействие накопителей информации. Все большей становится доля оптоволоконных каналов связи, которые позволяют передавать огромные массивы данных с невиданной до сих пор скоростью. Кроме того, ширится выпуск персональных домашних компьютеров и ноутбуков. Все это вкупе с прогрессирующим снижением стоимости коммуникационных услуг ведет к росту количества удаленных рабочих групп (офисов), а также расширению числа работников, выполняющих свои функции вне своего офиса или основного рабочего места. Эти факторы и способствуют развитию распределенных систем и, соответственно, распределенных баз данных.
По общему мнению, Россия и другие страны СНГ, обладая большой территорией, просто обречены на создание и развитие информационных систем на основе распределенных баз данных. Не секрет, что практически все преуспевающие средние и крупные региональные компании имеют свои представительства в Москве и/или Петербурге. Поэтому при управлении такими ' предприятиями не обойтись без сложных корпоративных распределенных информационных систем.
Практика показывает, что обычно решение вопроса создания корпоративной ИС ищется в уже достаточно освоенной и всем знакомой плоскости клиент-сервер на базе локальной сети с централизованной базой данных.
Выбирается одна из популярных многопользовательских СУБД и доступные средства для быстрой разработки приложений (как правило, это пара Interbase/Delphi). Создается система, включающая в себя одну или несколько баз данных, а также набор обращающихся к ней (к ним) приложений, реализующих прикладные функции, необходимые конечному пользователю. Данная технология весьма неплохо работает в ограниченном масштабе, например, в рамках одного офиса или нескольких удаленных рабочих групп-филиалов, связанных с головным предприятием. Однако время не стоит на месте, компания расширяется и выходит на тот уровень, когда новые задачи требуют децентрализации хранения и обработки данных и, соответственно, качественного скачка в развитии информационной системы. В этом случае технология клиент-сервер, реализованная на основе централизованной базы данных, уже не может удовлетворить новых потребностей. Информационная система становится неработоспособной и ее приходится фактически создавать заново. Очевидно, что обычные системы "клиент-сервер" могут развиваться только по эволюционному экстенсивному пути в ограниченном масштабе и становятся неэффективными, когда экстенсивные пути развития исчерпывают свои возможности. Затраты на модификацию и сопровождение такой системы в критический момент становятся сравнимыми с затратами на создание новой системы. Выходом из тупика может служить применение распределенных баз данных (БД).
В зависимости от архитектуры, можно выделить локальные и распределенные БД. Все части локальной БД размещаются на одном компьютере, а распределенной — на нескольких. Исторически, развитие баз данных, как локальных, так и распределенных, шло от иерархических моделей к сетевым и реляционным.
Первые иерархические и сетевые СУБД были созданы в начале 60-х годов прошлого века. Причиной послужила необходимость управления огромным количеством записей, связанных друг с другом, как правило, иерархическим образом (обслуживание выборов, переписей населения, моделирование ядерных испытаний, погодных и геологических явлений, информационное обеспечение космических полетов и т. д.). Причиной выбора иерархической модели во многом послужило ее подобие уже имевшимся и хорошо отработанным и освоенным на практике многочисленным массивам информации на неэлектронных носителях (банки данных, картотеки, досье, справочники). Среди реализованных на практике СУБД этого типа следует отметить системы IMS (Information Management System) компании IBM, а также TDMS (Time-Shared Date Management System) компании Development Corporation; Mark IV Multi — Access Retrieval System компании Control Data Corporation; System — 2000 разработки SAS-Institute.
Отношения в иерархической модели данных организованы в виде совокупностей деревьев, где дерево — структура данных, в которой тип сегмента потомка связан только с одним типом сегмента предка (рис. 4.1).
Рис. 4.1. Иерархическая модель БД
В терминологии баз данных, это адекватно наличию жестких связей "один-к-одному" или "один-ко-многим" между записями. К недостаткам и ограничениям иерархической модели данных можно отнести: отсутствие явного разделения логических и физических характеристик модели, что выражается в жесткой привязке БД к носителю-информации, потребность в дополнительных затратах и ухищрениях для описания неиерархических связей, что обуславливает низкую гибкость модели, не позволяющую ей эволюционировать в изменяющихся условиях.
Сетевая модель данных — это представление сетевыми структурами типа запись данных, связанных отношениями "один-к-одному" или "один-ко-многим" (рис. 4.2). Основная идеология и стандартные требования к этой модели были разработаны комитетом Database Task Group (DTBG) на рубеже 60—70-х годов. Впервые сетевая архитектура была реализована в СУБД Integrated Data Store (IDS) компании General Electric и IDMS компании Computer Associates.
Рис. 4.2. Сетевая модель БД
В отличие от иерархической модели, в сетевой допускается наличие нескольких связей от сегмента-потомка к сегментам-предкам.
Сетевая модель допускает также использование в базах данных связей "многие-ко-многим". Это позволяет устранить многие недостатки иерархической модели, такие как: низкую приспособленность к описанию данных неиерархической структуры и слабую гибкость при развитии системы.
Реляционная модель была описана в 1970—1971 годах в работах Е. Ф. Кодда. Она основана на процедурном языке обработки таблиц данных и языке запросов. В сетевой и иерархической моделях использовались жесткие физические подходы к связыванию записей из разных файлов путем применения физических указателей или адреса на диске. Такие базы существенно затрудняют и ограничивают операции над данными. Кроме того, является очевидным, что иерархические и сетевые базы данных весьма чувствительны к аппаратным изменениям. Перенос данных с одного накопителя на другой, или вообще Изменение числа приводит к необходимости внимательно и кропотливо изменять адреса в связях записей на новые. Также такие модели чувствительны к реструктуризации самой базы (добавление или удаление новых полей приводит к изменению физических адресов записей). Все эти проблемы преодолела реляционная модель, основанная на логических отношениях данных. Именно реляционная модель породила все современные известные СУБД, ее детищем является SQL, благодаря использованию реляционной модели возможно создание распределенных баз данных.
Под распределенной БД (Distributed DataBase — DDB) обычно подразумевают базу данных, включающую фрагменты из нескольких баз данных, которые располагаются на различных узлах сети компьютеров, и, возможно, управляются различными СУБД. Распределенная база данных выглядит с точки зрения пользователей и прикладных программ как обычная локальная база данных. В этом смысле слово "распределенная" отражает способ организации базы данных, но не ее внешнюю характеристику.
Согласно принципам, изложенным в трудах известного ученого Дэйта (С. J. Date), можно выделить 12 основных требований к распределенной базе данных (они же являются основными признаками):
Рассмотрим каждое из этих требований подробнее.
Это качество означает, что управление данными на каждом из узлов распределенной системы выполняется локально. База данных, расположенная на одном из узлов, является неотъемлемым компонентом распределенной системы. Будучи фрагментом общего пространства данных, она, в то же время, функционирует как полноценная локальная база данных. Управление ею выполняется локально и независимо от других узлов системы.
Вытекает из свойства локальной автономии. В идеальной системе все узлы равноправны и независимы, а расположенные на них базы являются равноправными поставщиками информации в общее пространство данных. База данных на каждом из узлов самодостаточна и может функционировать при отсутствии других узлов. Она включает собственный полный словарь данных и полностью защищена от несанкционированного доступа.
В распределенных БД поддержка целостности и согласованности данных, в свете предыдущих требований, представляет собой довольно сложную проблему. Синхронное и согласованное изменение данных в нескольких локальных БД, составляющих распределенную базу данных, достигается, как правило, применением протокола двухфазной фиксации транзакций. Кроме согласования и верификации данных, этот протокол может выполнять защиту от сбоев в системе в критических случаях (обрыв связи, например). Если распределенная БД однородна — т. е. на всех узлах данные хранятся в формате одной базы и на всех узлах функционирует одна и та же СУБД, то используется механизм двухфазной фиксации транзакций для конкретной СУБД. В случае же неоднородности распределенной БД, для обеспечения согласованных изменений в нескольких базах данных, используют менеджеры распределенных транзакций. Это, однако, возможно, если участники обработки распределенной транзакции (СУБД, функционирующие на узлах системы), поддерживают ХА-интерфейс, определенный в спецификации DTP консорциума Х/Ореn. ХА-интерфейс имеют, например, Informix, Microsoft SQL Server, Oracle, Sybase, CA-Openlngres.
Если в распределенной БД предусмотрено тиражирование (репликация) данных, то это сразу предъявляет дополнительные жесткие требования к дисциплине поддержки целостности данных на узлах, куда направлены тиражируемые потоки. Проблема состоит в том, что изменения в данных могут инициироваться как локально — на данном узле, так и извне, посредством тиражирования. Неизбежно возникают конфликты по изменениям, которые необходимо отслеживать и разрешать.
Это качество можно трактовать как возможность непрерывного доступа (формат 24x7 — доступ 24 часа в сутки 7 дней в неделю) в рамках распределенной БД к данным вне зависимости от их расположения и операций, выполняемых на локальных узлах. Одним словом, данные доступны всегда, а операции над ними могут выполняться непрерывно.
Это свойство означает полную прозрачность расположения данных. Пользователь, обращающийся к распределенной БД, ничего не должен знать о реальном (физическом) размещении данных в узлах информационной системы. Все операции над данными выполняются без учета их местонахождения. Передача и обработка запросов к базам данных осуществляется встроенными системными средствами.
Прозрачность расположения в реальных продуктах должна поддерживаться соответствующими механизмами, реализованными в рамках конкретной СУБД или проекта в целом. При этом разработчики СУБД придерживаются различных подходов. Типичным решением данной задачи является использование так называемых синонимов (Alias) баз данных.
Это свойство трактуется как возможность распределенного (т. е. на различных узлах, а не в одном месте) размещения данных, логически представляющих собой единое целое. Существует фрагментация двух типов: горизонтальная и вертикальная. Первая означает хранение строк одной таблицы на различных узлах (фактически, хранение строк одной логической таблицы в нескольких идентичных физических таблицах на различных узлах). Вторая означает распределение столбцов логической таблицы по нескольким узлам (типичный пример реализации — SQL-запрос из нескольких физически обособленных таблиц).
Тиражирование данных — это асинхронный (в общем случае) процесс переноса изменений объектов исходной базы данных в базы, расположенные на других узлах распределенной системы. В данном контексте независимость
тиражирования означает возможность переноса изменений между базами данных средствами, невидимыми пользователю распределенной системы. Данное свойство означает, что тиражирование возможно и достигается внутрисистемными средствами.
Принципиальная характеристика тиражирования данных (Data Replication — DR) заключается в отказе от физического распределения, привязки данных. Суть репликации состоит в том, что любая база данных (как для СУБД, так и для работающих с ней пользователей) всегда является локальной; данные размещаются локально на том узле сети, где они обрабатываются; все транзакции в системе завершаются локально.
Тиражирование данных — это асинхронный перенос изменений объектов исходной базы данных в базы, принадлежащие различным узлам распределенной системы. Функции тиражирования выполняет, как правило, специальный модуль СУБД — сервер тиражирования данных, называемый репли-катором (СУБД CA-Openlngres и Sybase). В других СУБД (Informix-OnLine Dynamic Server) регашкатор встроен в сервер или поставляется опционально (Oracle). Специфика механизмов репликации данных зависит от используемой СУБД. Один из простейших вариантов репликации — использование так называемых "моментальных снимков" (Snapshot) — сохранение на разных узлах копий той или иной таблицы в определенный момент времени; данные копии периодически (раз в неделю, например) подлежат обновлению.
Детали тиражирования данных полностью скрыты от прикладной программы; ее функционирование никак не зависит от работы репликатора, который целиком находится в ведении администратора базы данных. Следовательно, для переноса программы в распределенную среду с тиражируемыми данными не требуется ее модификация.
Синхронное обновление распределенных БД и технология репликации данных — в определенном смысле, антиподы. Краеугольный камень первой — синхронное завершение транзакций одновременно на нескольких узлах распределенной системы, т. е. синхронная фиксация изменений в распределенной БД. Ее "ахиллесова пята" — жесткие требования к производительности и надежности каналов связи. Если база данных распределена по нескольким территориально удаленным узлам, объединенным медленными и ненадежными каналами связи, а число одновременно работающих пользователей составляет сотни и выше, то вероятность того, что распределенная транзакция будет зафиксирована в обозримом временном интервале, становится чрезвычайно малой. В таких условиях (характерных, кстати, для большинства отечественных организаций) обработка распределенных данных практически невозможна.
Технология репликации данных не требует синхронной фиксации изменений, что является, несомненно, ее сильной стороной. В действительности далеко не во всех задачах требуется обеспечение идентичности БД на различных узлах в любое время. Достаточно поддерживать тождественность данных лишь в определенные критические моменты времени (генерация суточного, недельного, месячного, годового отчета). Можно накапливать изменения в данных в виде транзакций в одном узле и периодически копировать эти изменения на другие узлы.
Налицо преимущества распределенной технологии. Во-первых, данные всегда расположены там, где они обрабатываются — следовательно, скорость доступа к ним существенно увеличивается. Во-вторых, передача только операций, изменяющих данные (а не всех операций доступа к удаленным данным), да еще к тому же в асинхронном режиме позволяет значительно уменьшить трафик. В-третьих, со стороны исходной базы для принимающих баз репликатор выступает как процесс, инициированный одним пользователем, в то время как в физически распределенной среде с каждым локальным сервером работают все пользователи распределенной системы, конкурирующие за ресурсы друг с другом. Наконец, в-четвертых, никакой продолжительный сбой связи не в состоянии нарушить передачу изменений. Дело в том, что тиражирование предполагает буферизацию потока изменений (транзакций); поэтому после восстановления связи передача возобновляется с той транзакции, на которой тиражирование было прервано.
В то же время технология репликации данных не лишена недостатков. Например, невозможно полностью исключить конфликты между двумя версиями одной и той же записи. Такой конфликт может возникнуть, когда, вследствие все той же асинхронности, два пользователя на разных узлах исправят одну и ту же запись в тот момент, пока изменения в данных из первой базы еще не были перенесены во вторую. При проектировании распределенной среды с использованием репликации данных необходимо предусмотреть возможность возникновения конфликтных ситуаций и запрограммировать репликатор на какой-либо вариант их разрешения. В этом смысле применение DR-технологии — наиболее сильная угроза целостности распределенных баз данных.
При использовании механизмов репликации данных также остро стоит вопрос совместимости разнородных локальных баз данных, составляющих исходную БД. Зачастую штатные средства тиражирования в составе данной конкретной БД позволяют переносить данные в однородную базу. Ответом стало появление продуктов, выполняющих тиражирование между разнородными базами данных. Здесь развитие технологий пошло по двум путям. Первый — создание средств унифицированного доступа к данным (стандарт ODBC — Open DataBase Connectivity). Очевидный недостаток ODBC — недоступность для приложения многих полезных механизмов каждой конкретной СУБД, поскольку они могут быть использованы в большинстве случаев только через расширения SQL в диалекте языка данной СУБД, но в стандарте ODBC эти расширения могут не поддерживаться. Другой подход - это создание шлюзов, позволяющих приложениям оперировать над базами данных в ином формате так, как будто это собственные базы данных. Задача шлюза — организация доступа к унаследованным БД и служит для решения задач согласования форматов баз данных при переходе к какой-либо одной СУБД. Шлюзы можно рассматривать как средство, облегчающее миграцию, но не как универсальное средство межоперабельности в распределенной системе. Вообще, универсального рецепта решения задачи межоперабельности в этом контексте не существует — все определяется конкретной ситуацией, историей информационной системы и массой других факторов.
Обработка распределенных запросов
Это свойство распределенной БД трактуется как возможность выполнения операций выборки, сформулированных в рамках обычного запроса на языке SQL. To есть операцию выборки из распределенной базы данных можно сформулировать с помощью тех же языковых средств, что и операцию над локальной базой данных.
Обработка распределенных запросов — задача, более сложная, нежели обработка локальных запросов, и она требует интеллектуального решения с помощью особого компонента — оптимизатора распределенных запросов. Предположим, у нас имеется распределенная база данных, размещенная на двух узлах. Пусть, таблица detail хранится на одном узле, а таблица main — на другом. Размер первой таблицы — 2000 строк, размер второй — 200 строк (множество товаров поставляется небольшим числом поставщиков). Допустим, что выполняется запрос:
SELECT detail_name, main_name, main _address
FROM detail, main WHERE detail, main _number = main, main _number ...;
Тогда результирующая таблица представляет собой объединение таблиц
detail и main, выполненное по столбцу detail.main_number (внешний ключ) И main.main _number (первичный ключ).
Данный запрос является распределенным, т. к. затрагивает таблицы, принадлежащие различным локальным базам данных. Для его нормального выполнения необходимо иметь обе исходные таблицы на одном узле. Следовательно, одна из таблиц должна быть передана по сети. Очевидно, что это должна быть таблица меньшего размера, т. е. таблица main. Таким образом, оптимизатор распределенных запросов должен учитывать такие параметры, как размер таблиц, статистику распределения данных по узлам, объем данных, передаваемых между узлами, скорость коммуникационных линий, структуры хранения данных, соотношение производительности процессоров на разных узлах и т. д. От алгоритмов работы оптимизатора распределенных запросов впрямую зависит скорость работы базы данных с такими запросами.
Обработка распределенных транзакций
Это качество распределенных баз данных можно трактовать как возможность выполнения операций обновления БД, не разрушающее целостность и согласованность данных. Эта цель достигается применением двухфазного протокола фиксации транзакций, ставшего фактическим стандартом обработки распределенных транзакций. Его применение гарантирует согласованное изменение данных на нескольких узлах в рамках распределенной (или, как ее еще называют, глобальной) транзакции.
Это свойство означает, что в качестве узлов распределенной системы могут выступать компьютеры любых моделей и производителей — от мэйнфреймов до персональных компьютеров и даже ноутбуков.
Независимость от операционных систем
Это качество вытекает из предыдущего и означает многообразие операционных систем, управляющих узлами распределенной системы.
Доступ к любым базам данных может осуществляться по сети. Спектр поддерживаемых конкретной СУБД сетевых протоколов не должен быть ограничением системы с распределенными базами данных. Это качество формулируется максимально широко — в распределенной системе возможны любые сетевые протоколы.
Это качество означает, что в распределенной системе могут мирно сосуществовать СУБД различных производителей, и возможны операции поиска и обновления в базах данных различных моделей и форматов. Локальные базы данных, составляющих распределенную БД, автономны, независимы и самоопределены; доступ к ним обеспечивается СУБД, в общем случае от различных поставщиков. Связи между узлами — это потоки тиражируемых данных. Топология распределенных БД может варьироваться в широком диапазоне. В целом топология БД определяется географией информационной системы и направленностью потоков тиражирования данных.
Не все из вышеперечисленных требований могут выполняться одновременно. Всем требованиям сразу может удовлетворить, пожалуй, только достаточно идеализированная, а потому и практически бесполезная база данных. В особенности это касается последнего пункта — независимости от программного обеспечения БД. Не все СУБД различных производителей могут мирно сосуществовать в рамках одного проекта. Поэтому при выборе средств реализации необходимо достаточное внимание уделять вопросам совместимости. В последнее время с развитием новых программных средств создания БД (Delphi, например) или развития новых технологий (CORBA), этот вопрос становится менее острым.
Распределенные системы — это системы клиент-сервер. Существует, по меньшей мере, три модели клиент-сервер:
Первые две модели являются двухзвенными и не могут рассматриваться в качестве базовой модели распределенной системы. Третья модель — трехзвенная. Она (как и все многозвенные модели) хороша тем, что в ней интерфейс работы с пользователем полностью независим от компонента обработки данных. Собственно, трехзвенной ее можно считать постольку, поскольку в ней явно выделены:
Middleware — это главный компонент трехзвенных распределенных систем. Он выполняет функции управления транзакциями и коммуникациями, транспортировки запросов, управления именами и иные функции.
Существует фундаментальное различие между технологией типа "сервер запросов—клиент запросов" и трехзвенными технологиями. В первом случае клиент явным образом запрашивает данные, зная структуру базы данных (имеет место так называемая "поставка данных" клиенту). Клиент передает СУБД, например, SQL-запрос, а в ответ получает данные. Осуществляется жесткая связь типов, для реализации которой все СУБД используют закрытый SQL-канал. Он строится двумя процессами: SQL/Net на компьютере-клиенте и SQL/Net на компьютере-сервере и порождается по инициативе клиента оператором connect. Канал называется закрытым в том смысле, что невозможно, например, написать программу, которая будет шифровать SQL-запросы по специальному алгоритму или другим образом будет вмешиваться в процесс передачи данных между клиентским и серверным приложением.
В случае трехзвенной схемы клиент явно запрашивает один из сервисов (предоставляемых прикладным компонентом), например, передавая ему некоторое сообщение, и получает ответ также в виде сообщения. Клиент направляет запрос во внешнюю среду, ничего не зная о месте расположения сервиса. Имеет место так называемая "поставка функций" клиенту.
Важно
Для клиента сама база данных видна исключительно посредством набора сервисов. Более того, он вообще ничего не знает о ее существовании, т. к. все операции над базой данных выполняются внутри сервисов.
Таким образом, речь идет о двух принципиально разных подходах к построению информационных систем клиент-сервер. Двухзвенная архитектура на сегодняшний день может считаться достаточно устаревшей и, в связи с развитием распределенных информационных систем, постепенно отходит на второй план. И если для быстрого создания несложных приложений с небольшим числом пользователей этот метод подходит как нельзя лучше, то при построении корпоративных распределенных информационных систем он абсолютно непригоден в силу вышеперечисленных причин.
В настоящее время для построения распределенных информационных систем имеются широко распространенные технологии CORBA и DCOM. В основном технологии CORBA и DCOM сходны. Они обе предоставляют распределенную объектную инфраструктуру для прозрачного взаимодействия распределенных объектов. В то же время каждая из этих технологий имеет свои особенности, которые мы и рассмотрим ниже.
Технология COM (Component Object Model) и ее вариант для распределенных систем DCOM (Distributed Component Object Model) была разработана компанией Microsoft. DCOM является расширением технологии СОМ и включает в себя среду распределенных вычислений DCE (Distributed Computing Environment) и механизм удаленного вызова процедур (RFC — Remote Procedure Calling).
Философия СОМ заключается в следующем: программа-клиент использует при своей работе объект (объекты) некоторой другой программы (сервера) так, словно эти объекты являются частью самого клиента. Основную роль при этом играет интерфейс объектов. Под интерфейсом объекта подразумевается поименованное множество функционально связанных методов (операций) объекта. Интерфейс может формироваться, как правило, при помощи IDL (Interface Definition Language), специального C++ — подобного языка описания интерфейсов. Клиент получает именно интерфейс затребованного объекта. Сервер же представляет собой программу, содержащую, кроме всего прочего, еще один или несколько объектов СОМ. Сервер СОМ может создавать реализации объектов из нескольких классов, каждый из которых представляет различные варианты поведения объекта. СОМ-клиент взаимодействует с СОМ-сервером через указатель на интерфейс и использует этот указатель для вызова методов сервера.
При этом клиент и сервер могут сосуществовать и взаимодействовать тремя различными способами.
1. Клиент и сервер исполняются на одном компьютере в рамках единого процесса (рис. 4.3). Именно такой вариант реализован в Windows 98. Именно так Delphi строит программы, использующие ActiveX-компоненты. В этом случае сервером СОМ- объектов является некоторая dll-библиотека. Взаимодействие между клиентом и сервером происходит при помощи интерфейса объекта в едином адресном пространстве.
Рис. 4.3. Клиент и сервер СОМ в одном процессе
2. Клиент и сервер запускаются на одной машине в рамках разных процессов (рис. 4.4). Это тоже имеет место при функционировании Windows 98. Однако подобный способ более часто встречается при инкапсуляции (встраивании) объектов одних программ в другие (вставка объекта в Microsoft Word, например). Здесь между клиентом и сервером имеется два промежуточных звена. На стороне клиента функционирует объект Proxy. Его задача — при обращении клиента к СОМ-объекту формировать пакет вызова к серверу, а также принимать данные от сервера и реализовывать, таким образом, интерфейс объекта. Объект Proxy является уполномоченным агентом сервера в среде клиента. В адресном пространстве сервера работает другой посредник — stub (переводится по-разному: заглушка, приемник, поглотитель), stub принимает запросы от одного или нескольких клиентских объектов Proxy, помещает их в стек и вызывает нужные методы объектов на сервере, а затем отправляет клиенту полученный результат.
Рис. 4.4. Клиент и сервер СОМ в разных процессах одной машины
3. Клиент и сервер — разные программы на различных компьютерах в составе сети (рис. 4.5). Причем эти компьютеры могут быть аппаратно несовместимы и работать под управлением различных операционных систем. Этот вариант, очевидно, и представляет собой технологию DCOM. Передача данных между компьютерами происходит путем использования стандартных протоколов, например TCP/IP.
Рис. 4.5. Технология DCOM
Таким образом, становится очевидным, что DCOM являет собой типичный пример двухзвенной распределенной архитектуры. При этом он обладает всеми достоинствами и недостатками подобной архитектуры.
СОМ содержит все элементы, необходимые для построения распределенной системы:
Все составные части прекрасно соответствуют друг другу в рамках модели СОМ. Уникальной возможностью СОМ является универсальная технология доступа к базам данных — OLE DB/ADO.
Потенциально технологию СОМ могут поддерживать самые различные языки программирования. Добавление некоторых расширений, библиотек или мастеров в систему разработки позволит использовать для работы с СОМ любой язык программирования. В настоящий момент наиболее широко используются, как правило, Visual Basic, C++ и Delphi. Серьезные проблемы возникли пока лишь при использовании языка Java. Компания Microsoft добилась прекрасного взаимодействия Java с СОМ только путем отказа от переносимости таких Java-программ на другие виртуальные машины Java. Вообще, следует отметить, что уровень стандартизации для СОМ достаточно слаб.
Технология СОМ реализована на высоком уровне абстракции — все вопросы низкого уровня, такие как взаимодействие с операционной системой или сетевыми средствами, спрятаны от прикладного программиста. Таким образом, реализуются свойства сетевой прозрачности, аппаратной независимости и независимости от операционных систем.
Компонентная модель Microsoft, базирующаяся на СОМ-технологии, в своей основе имеет двоичную структуру объектов. Это не вызывает никаких проблем при ориентации на одну платформу и операционную систему. Безусловным достоинством такой модели является простота создания компонентов с использованием различных языков программирования. С другой стороны, такая компонентная модель неизбежно связана с определенными ограничениями и недостатками, в частности в разрезе межплатформенного взаимодействия.
Эта технология предусматривает возможность создания локальной базы данных, хранящей информацию о СОМ-объектах, их интерфейсах, методах и т. д. для сервера приложений СОМ. Такая база данных называется библиотекой типов (type library). Использование библиотек типов не является обязательным для OLE, хотя это необходимо в технологии ActiveX. Для получения информации из библиотеки типов пользователь должен явно импортировать ее, для чего необходимо выбрать соответствующую запись реестра Windows на конкретном компьютере.
Обычно объявления на языке IDL при работе с СОМ не являются существенной частью спецификации проекта, т. к. IDL-спецификации играют вспомогательную роль в СОМ- технологии вследствие ее базирования на двоичном стандарте объектов. Кроме того, язык Microsoft IDL не очень развит с точки зрения объявления типов данных, из которых строится программа.
Объекты СОМ всегда рассматривались (и продолжают рассматриваться) как серверные объекты, которые просто реализуют тот или иной набор методов. Различные объекты, реализующие один и тот же интерфейс и созданные с помощью обращения к одной и той же библиотеке классов, не отличаются друг от друга. Объектная ссылка, которую получает клиент, является указателем на интерфейс и при этом не содержит информации о конкретном объекте. Другими словами, СОМ оперирует объектами, не имеющими состояния. В общем случае, если клиент, используя одну и ту же объектную ссылку, в цикле вызвал десять раз один и тот же метод, то он не может быть уверен, что он обратился к одному, а не к двум, пяти или десяти различным объектам. Естественно, объекты без состояния не имеет смысла хранить дольше, чем существует сервер приложений, в котором они были созданы. Такие объекты применительно к распределенным системам называются временными (transient). СОМ-объект — это конкретная переменная C++, Visual Basic или Pascal, находящаяся в оперативной памяти и существующая, пока работает создавший ее сервер приложений. Она может быть создана по запросу клиента или заранее (например, с помощью Microsoft Transaction Server — MTS). Задача программиста — при работе с СОМ сопоставить с объектом какое-либо состояние. Этого можно добиться различными способами:
Технология СОМ поддерживает как статический, так и динамический способ взаимодействия клиента и сервера. Под динамическим способом понимается подход, когда проверка возможности реализации сервером нужного метода, а также все необходимые действия по выполнению удаленного вызова выполняются на этапе работы клиентского приложения, а не на этапе его компиляции. При статическом вызове эти действия выполняются именно на этапе компиляции. Разумеется, статический способ предпочтительнее во всех отношениях (когда он возможен вообще). Для его использования сервер СОМ должен создать и экспортировать библиотеку типов, которая затем импортируется клиентом и используется как часть клиентского процесса.
COM/DCOM демонстрирует очень высокую производительность. Разумеется, производительность существенно зависит от того, какой способ — статический или динамический — вы используете.
Проблемы обеспечения масштабируемости не были заложены в фундамент технологии, и поэтому существенным препятствием для создания масштабируемых приложений является очень жесткая связь между клиентом и сервером (объект, т. е. совокупность ресурсов на сервере, не может быть удален, пока клиент явно не укажет, что этот объект больше не нужен). В реальных проектах необходимо управлять состоянием объектов, и это затрудняет создание масштабируемых приложений, т. к. это обязанность не технологии СОМ, а программиста. Сильной стороной СОМ является гибкая модель управления потоками. Основным инструментом, повышающим уровень масштабируемости СОМ-систем, является MTS.
Устойчивость к сбоям СОМ-систем находится на не слишком высоком уровне, в том числе из-за уже упомянутой излишне жесткой привязки клиентов и серверов друг к другу. Основным средством обеспечения устойчивости к сбоям (оно же средство управления нагрузкой серверов) является диспетчер, который позволяет перенаправлять вызовы клиента на различные серверы приложений СОМ.
Сервером транзакций в СОМ является MTS. Сервер приложений СОМ должен быть написан в специальном стиле для того, чтобы иметь возможность взаимодействовать с MTS. MTS позволяет достаточно гибко управлять режимами выполнения транзакций в системе и поддерживает двухфазное завершение транзакций. Одним из существенных недостатков схемы управления транзакциями СОМ является необходимость явной передачи контекста транзакции в качестве -аргумента при вызове удаленных методов. Такая схема не является ни эффективной, ни гарантирующей от ошибок, особенно при вовлечении в транзакцию большого количества объектов.
В настоящий момент система безопасности СОМ базируется на системе безопасности Windows NT/Windows 2000. Кроме того, предусмотрена защита данных при их передаче с использованием Socket Security Layer (SSL). Отдельная проблема — обеспечение безопасности при передаче компонентов ActiveX с использованием протокола HTTP. Здесь используется система электронных подписей, лицензий, сертификатов. Клиент может выполнять код только того компонента, который пришел с авторизованного сервера.
Основой взаимодействия через Интернет при работе с DCOM являются расширения возможностей протокола HTTP, выполненные Microsoft. Браузеры Microsoft (Internet Explorer 3.0 и выше) позволяют выполнять код ActiveX-компонентов, полученных с Web-серверов.
Кроме того, необходимо отметить, что технология DCOM изначально ориентировалась на системы, построенные на базе операционных систем Windows, и поэтому она как нельзя лучше подходит для создания распределенных систем именно на основе продуктов Microsoft (например, Windows 98 целиком реализована на основе технологии СОМ). В этом плане СОМ является замкнутой и "самодостаточной" системой. Если вы желаете решить свои проблемы, используя функциональность Microsoft Office, то СОМ как нельзя лучше подходит для этих целей. СОМ-приложения способны функционировать только под управлением Windows. Ни ActiveX, ни сервер транзакций MTS не способны работать нигде, кроме этой платформы.
Технология СОМ очень проста для разработки небольших приложений и чрезвычайно сложна, как инструмент создания комплексных систем. Она содержит большое количество узких мест: отсутствие состояния объектов, низкая устойчивость к сбоям. Технология не является объектно-ориентированной в классическом смысле этого слова, что в общем случае не способствует простоте ее использования. Достоинством технологии является комплексность и универсальность подходов в рамках СОМ-модели, а также тот факт, что данная технология достаточно хорошо освоена программистами.
Таким образом, технологию COM/DCOM можно порекомендовать для построения распределенных систем среднего масштаба, с не очень большим числом узлов, и других систем с некритичными нагрузками.
CORBA (Common Request Broker Architecture) — архитектура для построения распределенных объектных приложений. Была предложена некоммерческой организацией — консорциумом OMG (Object Management Group), состоящей из нескольких сотен (!) ведущих компаний из отрасли разработки программного обеспечения (включая таких гигантов, как Microsoft и Borland/Inprise). Первая спецификация CORBA появилась еще в далеком 1991 году.
Целью разработчиков CORBA было создание механизмов межплатформенного взаимодействия приложений в распределенных системах. Можно поразиться дальновидности OMG — ведь в середине — конце 80-х годов XX века распределенные системы не играли той впечатляющей роли в компьютерной индустрии, как сейчас. Кроме того, расширение экспансии Intel и Microsoft ставило под угрозу само наличие разнообразия аппаратно-программных платформ. Тем не менее, в сложившейся обстановке работы были продолжены, причем результаты были настолько успешны, что даже всемогущий Microsoft счел нужным присоединиться к консорциуму разработчиков, чтобы держать руку на пульсе развития новой перспективной технологии.
Как и DCOM, CORBA основывается на коммуникации типа клиент-сервер. Запрашивая сервис, клиент вызывает метод, реализуемый удаленным объектом, действующим в роли сервера. Сервис, предоставляемый объектом, инкапсулируется с помощью интерфейса, определенного на языке IDL. Именно собственный язык IDL является одной из изюминок CORBA. Вообще, существуют три различных языка описаний под одним и тем же названием: OMG IDL (очевидно, используется в CORBA), Microsoft IDL (разработан для технологии 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, а также сообщает о доступности, факте создания и о готовности объекта принимать запросы клиента. Далее следует обратная связь по описанной цепочке объектов (рис. 4.6).
Рис. 4.6. Технология CORBA
Как видно из описания, CORBA реализует собой типичную многозвенную (здесь — трехзвенную) архитектуру. В роли Middleware — программного обеспечения промежуточного слоя — здесь выступает объект Smart Agent. Обычно при практической реализации программа, выполняющая Действия Smart Agent, устанавливается на выделенную машину в корпоративной сети или на несколько машин в сети Интернет. При создании серверов они регистрируются на ДОСТУПНЫХ Smart Agent.
CORBA значительно более строго и формально подходит к механизмам обмена и передаче данных. Передача данных между компонентами ORB и smart Agent происходит при помощи специального протокола UDP (Ultrawide Data Protocol), который загружает сеть значительно меньше, чем протокол TCP/IP — тем самым происходит некоторая экономия системных ресурсов.
Таким образом, CORBA представляет собой более приспособленную для создания распределенных систем технологию. Наличие трехзвенной архитектуры позволяет значительно повысить надежность системы. Если в сетевом окружении объекты Smart Agent установлены на нескольких различных компьютерах, то маловероятно, что все эти компьютеры одновременно выйдут из строя. Если в каком-нибудь из серверов объектов произошел сбой, то Smart Agent оценит ситуацию и либо повторит вызов, либо передаст запрос другому серверу, реализующему нужный объект.
Благодаря трехзвенной архитектуре и наличию развитого языка создания интерфейсов IDL, технология CORBA позволяет создавать истинные кросс-платформенные информационные системы. Клиентские программы, программное обеспечение Middleware и серверы могут работать на разных аппаратных платформах под управлением различных операционных систем. В языке OMG IDL, лежащем в основе CORBA, представлены даже некоторые возможности объектно-ориентированного программирования, такие как: инкапсуляция данных, полиморфизм и наследование. IDL CORBA поддерживает множественное наследование. Для достижения тех же целей DCOM позволяет объекту иметь несколько интерфейсов. OMG IDL также позволяет определить исключения. В то же время не стоит понимать IDL как язык программирования. В нем целиком и полностью отсутствуют какие-либо вычислительные функции. Это исключительно язык описаний. Именно это и позволяет легко производить отображение конструкций IDL на языки программирования клиентского ПО и достигнуть межплатформенного взаимодействия (двоичный интерфейс объектов СОМ фактически препятствует переносу данной технологии из среды Windows на другие платформы). Пример описания интерфейса билетной кассы кинотеатра приведен в листинге 4.1.
Листинг 4.1. Пример описания интерфейса на языке IDL
Struct Place
{
char row;
unsigned long seat
};
interface Office
{
readonly attribute unsigned long NumOf Seats
float GetPrise (in Place chosen Place)
}
Как видно из листинга, синтаксис IDL очень похож на синтаксис C++.
Еще одним важным достоинством CORBA является полностью объектная структура технологии. Понятие "объекта" в CORBA принципиально отличается от своего СОМ-аналога. Объект CORBA не является переменной языка программирования и в общем случае время его существования не связано со временем работы серверных или клиентских приложений. CORBA-объект не занимает никаких ресурсов компьютера — оперативной памяти, сетевых ресурсов и т. п. Эти ресурсы использует только так называемый servant ("сервант"), который является "инкарнацией" одного или нескольких CORBA-объектов. Именно сервант является переменной языка программирования. Пока не существует сервант, сопоставленный с конкретным объектом CORBA, этот объект не может обслуживать вызовы клиентов, но, тем не менее, он существует. Результатом создания объекта (при этом совершенно не обязательно, что создается и сопоставляется с этим объектом соответствующий сервант) является так называемая "объектная ссылка" CORBA, которая сопоставлена с этим, и только с этим объектом, и это сопоставление остается корректным в течение всего срока существования CORBA-объекта. Объектная ссылка CORBA правильно интерпретируется ORB от любого производителя программного обеспечения. После уничтожения CORBA-объекта все объектные ссылки на него навсегда теряют смысл. С помощью объектной ссылки клиент вызывает методы объекта, при этом инкарнациями этого объекта могут быть различные серванты (но не более одного одновременно), которые физически могут находиться даже на различных компьютерах. Все CORBA-объекты, в отличие от технологии СОМ, не обезличены, а создаются с параметром, задающим имя для их экземпляров. Это позволяет клиенту найти конкретный экземпляр объекта по имени. Клиент, который при попытке подключиться к объекту не указывает его имя, получит ссылку на произвольный экземпляр запрашиваемого объекта с любого сервера в сети. Такой вариант удобен, когда в CORBA-системе имеется механизм балансировки загрузки серверов. Возможна организация "долгоживущих объектов", информация о создании и функционировании которых сохраняется, и такие объекты можно возродить после перезапуска сервера объектов или на другом подобном сервере объектов. Именно долгоживущие объекты регистрируются при помощи BOA в службах smart Agent. Именно такие объекты нуждаются в уникальных идентификаторах. Наряду с долгоживущими объектами возможно существование так называемых транзистентных или временных объектов, которые живут только в течение того или иного процесса и прекращают свое функционирование с прекращением работы породившего их сервера. Объект СОМ может рассматриваться как достаточно примитивный частный случай объекта CORBA — как по своим возможностям, так и с точки зрения его цикла жизни.
CORBA имеет очень развитую сервисную часть. Только для поиска серверных объектов по различным критериям можно использовать 4 различных сервиса CORBA. OMG стремится к максимальной стандартизации вспомогательных возможностей CORBA.
CORBA имеет аналог библиотеки типов СОМ — это так называемый Репо-зитарий Интерфейсов (Interface Repository). Чтобы оценить принципиальную разницу в подходе CORBA по сравнению с СОМ, достаточно сказать, что ' Репозитарий Интерфейсов CORBA сам представляет собой объект CORBA со всеми вытекающими из этого возможностями. Помимо Репозигария Интерфейсов, CORBA использует Репозитарий Реализаций (Implementation Repository), который представляет собой базу данных, содержащую информацию о серверах приложений CORBA.
В отличие от COM, CORBA с самого начала рассматривалась как технология создания масштабируемых систем. Разделение собственно объектов CORBA и их сервантов, схемы соответствия между ними, характеристики объектных адаптеров, модели управления потоками и соединениями, схемы активации серверов приложений, универсальные решения по сохранению состояния объектов, автоматическое управление контекстом транзакций и безопасности — все это очень способствует решению данной проблемы.
CORBA имеет несколько более высокий уровень устойчивости к внутренним сбоям за счет большей изоляции клиентов и серверов (органическое свойство трехзвенных систем), автоматического сохранения состояния объектов, более мощной и продуманной схемы управления транзакциями (включая автоматический откат транзакций по тайм-ауту), а также автоматической привязки объектной ссылки и конкретного объекта CORBA.
Управление транзакциями берет на себя так называемый Сервис Управления Транзакциями CORBA (Object Transaction Service, OTS). Он является существенно более гибкой, продуманной и формализованной системой, чем MTS в технологии COM/DCOM, и содержит все необходимое в рамках CORBA-модели. Серверы приложений CORBA и OTS запускаются и работают независимо друг от друга. Важной особенностью CORBA является тесное взаимодействие OTS и ORB, что обеспечивает автоматическое распространение контекста транзакций в многопоточной распределенной среде. Спецификация CORBA предусматривает (необязательную) поддержку вложенных транзакций.
Работа над Сервисом Безопасности CORBA (Security Service) продолжалась в течение 2 лет, спецификация была принята в 1996 г. Сервис безопасности позволяет обеспечить уровень безопасности В2 (уровень, близкий к высшему уровню защиты, который используется в государственных учреждениях). Предусмотрена идентификация пользователя, списки прав доступа к ресурсам, система аудита и многое другое. Особенно приятно, что разработчик не должен явно взаимодействовать с этим сервисом — это задача для ORB. Основная нагрузка возложена на системных администраторов.
Спецификации CORBA не оговаривают использование Интернета в качестве особого случая. Интеграция CORBA и Интернета выполняется естественным образом — за счет использования протокола ПОР (Interner/Intranet Object Protocol), построенного поверх TCP/IP. URL-имена могут быть использованы в качестве имен для службы именования CORBA. На практике производители программного обеспечения предоставляют расширения CORBA, упрощающие работу с Интернетом (VisiBroker URL Naming Service) или решающие те или иные проблемы — например, "обход" ограничений, накладываемых на апплеты Java, используемых в качестве CORBA-клиентов (например, Borland/Visigenic GateKeeper).
Скорость и удобство разработки CORBA-систем сильно зависит от используемой технологии. До недавнего времени традиционным способом создания распределенных систем, основанных на CORBA, являлось использование Java-технологий — Enterprise JavaBeans и так называемых Application Server, например, BEA WebLogic и Inprise Application Server. Использование этих технологий позволяет чрезвычайно быстро создавать высокоэффективные, масштабируемые, транзакционные серверы приложений. Клиентская часть таких систем может быть написана на любом языке программирования, поддерживающим объекты CORBA. Поддержка технологии CORBA появилась с выходом четвертой и была существенно расширена в пятой версии популярного средства программирования Delphi фирмы Borland/Inprise. Это дало еще один мощный и очень популярный инструмент разработки распределенных информационных систем. Delphi 5 поддерживает все необходимые CORBA-компоненты, а также включает детально разработанную справочную систему (правда, на английском языке) по объектам CORBA. Все это, включая удобства самого Delphi, как системы разработки приложений, делает процесс создания CORBA-приложений исключительно быстрым и удобным.
В качестве недостатков технологии CORBA обычно приводят ее чрезмерную сложность. Действительно, двухзвенная архитектура DCOM несколько проще. Программисту, использующему CORBA, необходимо знать большое количество интерфейсов из различных сервисов, правильно использовать возможности объектных адаптеров и многое другое. Поскольку CORBA использует различные схемы отображения IDL на разные языки программирования, то разработчику в общем случае надо знать их особенности для наиболее широко используемых языков. Сложность CORBA является закономерной платой за ее огромные возможности в плане надежности, безопасности, масштабируемости и межплатформенного взаимодействия.
Технология CORBA носит существенно более общий, передовой и универсальный характер, чем COM/DCOM, что заложено в ее фундаменте. Тем не менее, DCOM и CORBA демонстрируют примерно одинаковую, очень высокую производительность. Выбор той или иной технологии диктуется характеристиками проектируемой информационной системы. Для создания распределенных систем малого и среднего масштаба, функционирующих под управлением Microsoft Windows (такая система наиболее соответствует потребностям большей части предприятий СНГ), лучше всего подходит технология DCOM. Здесь главный выигрыш состоит в относительной простоте и отлаженности технологии. Кроме того, в этом случае появляется возможность использования всей мощи и функциональности Microsoft Office и других продуктов Microsoft. При разработке среднемасштабных и крупных информационных систем, особенно таких, в которых компоненты могут быть удалены на значительные расстояния, и/или работать на разных аппаратно-программных платформах, а также систем, нуждающихся в высокой степени надежности, рекомендуется использовать CORBA, т. к. даваемые этой технологией преимущества с лихвой компенсируют некоторую сложность разработки и сопровождения приложений.
При этом следует учитывать фактор возможности развития информационной системы. Масштабируемость во многом зависит от качества разработки проекта, продуманности принимаемых решений и квалификации менеджеров проекта и разработчиков. При прочих равных условиях технология CORBA имеет в этом плане большие преимущества по сравнению с СОМ.