1.3. Распределенные объектные архитектуры

Традиционный структурный подход к проектированию КИС предполагает последовательную реализацию основных этапов разработки системы: системный анализ, построение функциональных моделей, системный проект, проектирование программных модулей, отладка программных модулей и объединение в целостную систему, тестирование и внедрение программного продукта.

Применение CASE-технологий и средств позволяет значительно сократить сроки разработки КИС и снизить вероятность появления ошибок за счет автоматического контроля создаваемых диаграмм, автоматической генерации структуры сервера БД и программного кода клиентских приложений.

В то же время обнаруживаются следующие недостатки таких технологий и средств:

– программные коды клиентских приложений генерируются на основе реляционной структуры БД;

– возникают проблемы перехода от табличных структур БД к требуемым экранным формам приложений, что затрудняет разработку программ со сложной бизнес-логикой;

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

Обозначенные проблемы позволяют решить объектно-ориенти­рован­ные методы разработки РИУС [45]–[48].

Данные методы обладают следующими преимуществами:

– возможно эффективное построение гетерогенных распределенных ИС вследствие того, что объект-сервер инкапсулирует от клиента детали реализации предоставляемого сервиса;

– объектно-ориентированные КИС могут развиваться эволюционно, путем модернизации отдельных объектов, не затрагивая остальные части системы, что снижает затраты на сопровождение и риск капиталовложений;

– использование механизма унаследованных приложений позволяет включать разработанные ранее приложения в распределенную среду через объекты-оболочки (wrappers);

– объектно-ориентированные КИС обладают свойством независимости объектов от размещения, вызов объектов осуществляется стандартным образом и не зависит от коммуникационного программного обеспечения;

– обеспечивается масштабируемость КИС и возрастает их отказоустойчивость за счет репликации объектов;

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

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

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

– архитектура Группы управления объектами (ObjectManagementGroup,OMG), определяется как «Общая архитектура брокера объектных запросов» (CommonobjectrequestBrokerArchitecture,CORBA);

– система вызовов удалённых методов Java(RemoveMethodInvocation,RMI);

– модель распределённых компонентных объектов Microsoft(DistributedComponentObjectModel,DCOM).

В апреле 1989 г. был создан консорциум Object Management Group (OMG), членами которого сейчас являются более 800 ведущих компьютерных компаний, таких как Sun, DEC, IBM, HP, Motorola и т. д. Задачей консорциума стала разработка спецификаций и стандартов, позволяющих строить распределенные объектные системы в гетерогенных средах. Появление такого стандарта должно облегчить процесс внедрения распределенных, объект­ных технологий в разработку приложений для различных отраслей производства. Необходимая спецификация была разработана OMG и получила название Object Management Architecture (OMA) [49].

Рис. 1.4. Архитектура управления объектами (OMA)

OMA состоит из четырех основных компонентов, представляющих собой спецификации различных уровней поддержки приложений (рис. 1.4) [50]–[52]:

 архитектура брокера запросов объектов (CORBA – Common Object Request Broker Architecture) устанавливает базовые механизмы взаимодействия объектов в гетерогенной сети;

 сервисы объектов (Object services) являются основными системными службами, используемыми разработчиками для создания приложений;

 универсальные средства (Common Facilities) ориентированы на поддержку пользовательских приложений, таких как электронная почта, средства печати и т. д.;

 объекты приложений (Application Objects) предназначены для решения конкретных прикладных задач.

Спецификация Common Object Request Broker Architecture (CORBA) лежит в основе любого компонента, разработанного OMG. CORBA определяет механизм, обеспечивающий взаимодействие приложений в распределенной среде.

Главными компонентами стандарта CORBA являются:

– объектный брокер запросов (Object Request Broker);

– язык определения интерфейсов (InterfaceDefinitionLanguage);

– объектный адаптер (Object adapter);

– репозиторий интерфейсов (Interface Repository).

Наличие большого количества сетевых протоколов в разных операционных системах потребовало разработки спецификации сетевых соединений. Семиуровневая модель Open System Interсonnection (OSI) обеспечивает описание сервисов, которые каждый уровень должен предоставлять для реализации соединения (рис. 1.5). Низший уровень – физический, определяет доступ к физической линии. Уровень данных обеспечивает достоверную передачу данных по физической линии. Сетевой уровень имеет дело с установкой соединения и маршрутизацией. Транспортный уровень отвечает за достоверную передачу до точки назначения. Уровень сессий обеспечивает управление соединением. Уровень представлений описывает синтаксис данных и обеспечивает прозрачность для приложений. Последний уровень – уровень приложений – обеспечивает соответствующие сетевые функции для конечного пользователя.

Рис. 1.5. Семиуровневая модель сетевого взаимодействия OSI

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

Язык описания интерфейсов OMG IDL позволяет определить интерфейс, независимый от языка программирования, используемого для реализации.

Высокий уровень абстракции CORBA в семиуровневой модели OSI позволяет программисту не работать с низкоуровневыми протоколами.

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

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

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

Рис. 1.6. Схема работы объектного брокера запросов

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

Рис. 1.7. Статический и динамический способы взаимодействия объектов с использованием ORB

Вызов операций разделяемого объекта-сервера может быть сделан статическим (IDL stub) и динамическим (Dynamic Invocation Interface) способами. Интерфейсы описываются, используя язык определения интерфейсов, получивший название OMG Interface Definition Language. В случае статического вызова описания интерфейсов отображаются в программный код на языках С, С++, Smalltalk. Информация об интерфейсах объектов может быть получена клиентом двумя способами: статически (compile time) и динамически (runtime). Интерфейсы могут быть также указаны с помощью службы репозитория интерфейсов (Interface Repository). Этот сервис представляет интерфейсы как объекты, обеспечивая доступ к ним в время работы приложения (runtime режиме).

Главная функция объектного адаптера, используемого для реализации объекта, – предоставление доступа к сервисам объектного брокера ORB. Объектный адаптер обеспечивает все низкоуровневые средства для связи объекта с его клиентами. Основными задачами объектного адаптера являются: генерация ссылок на удаленные объекты; вызов метода объекта, определенного в IDL; обеспечение безопасности взаимодействия; активация и деактивация объектов; установление соответствия между ссылками на удаленные объекты (proxy) и реальными экземплярами объектов; регистрация объектов.

Спецификация OMG CORBA определяет базовый объектный адаптер, который должен быть реализован во всех брокерах запросов. Basic Object Adapter (BOA) – это набор интерфейсов для создания ссылок на удаленные объекты, регистрации объектов, авторизации запросов и активизации приложений. Роль базового объектного адаптера в архитектуре CORBA иллюстрируется рис. 1.8.

Рис. 1.8. Схема получения запроса

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

 Служба уведомления объектов о событии (EventNotificationService). Служба обеспечивает извещение заинтересованных объектов о происходящих в системе событиях. Объект может выступать в качестве «производителя» или «потребителя» некоторого события. Для обеспечения асинхронного взаимодействия множества производителей событий с множеством их потребителей используются специальные объекты – «каналы событий», которые являются стандартными объектамиCORBA. Сами события объектами не являются.

 Служба жизненного цикла объектов (Object Lifecycle Service). Служба поддерживает создание, удаление, копирование и перемещение объектов. Для создания объектов используются специальные объекты «фабрики объектов» (object factories). Для определения положения таких объектов используется понятие локатора фабрики (factory finder). Для локаторов определена операция поиска, которая возвращает последовательность соответствующих фабрик. Клиенты задают локатор фабрик как параметр в операциях создания, копирования и перемещения. Такой подход к копированию и перемещению объектов обеспечивает независимость от ORB и механизма хранения. Операция удаления определяется для любого объекта, поддерживающего базовый интерфейс службы жизненного цикла. Модель удаления обеспечивает различные механизмы поддержки целостности ссылок. Поддерживается «поверхностное» и «глубокое» копирование.

 Служба именования объектов (Name Service). Служба обеспечивает отображение между именами и объектами (связывание имен). Связывание имени всегда определяется относительно некоторого контекста именования. Контекст именования – это объект, который содержит множество связываний имен, и каждое имя в нем уникально. Несколько имен могут связываться с объектом в одном или различных контекстах одновременно. Необязательно, однако, чтобы все объекты были именованными. Поскольку контекст подобен другим объектам, он также может быть связан с именем в некотором контексте именования. При этом формируется направленный граф именования с узлами, представляющими контексты. Такой граф допускает более сложные имена для обращения к объекту. Если задан контекст, последовательность имен определяет путь в графе именования. Служба поддерживает распределенные объединения пространств именования.

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

 Служба управления конкурентным доступом (Concurrency Control Service). Поддерживает конкурентный доступ к одному или более объектам со стороны одного или более объектов. Интерфейс службы позволяет выполнять вычисления в рамках транзакции (автоматическое освобождение блокировок по завершении транзакции – commit или abort) либо нетранзакционно (ответственность за своевременное разблокирование ложится на пользователя). Служба управления конкурентным доступом гарантирует правильную последовательность транзакционных и нетранзакционных вызовов по отношению друг к другу. Служба управления конкурентным доступом используется совместно со Службой управления транзакциями для координации выполнения конкурентных транзакций.

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

 Служба объектных связей (Relationships Service). Служба обеспечивает средства для создания, удаления, навигации и управления связями между объектами. Служба определяет два новых вида объектов: связь и роль. Роль представляет CORBA-объект в некоторой связи. Объект-связь создается на основании множества ролей, передаваемого в фабрику связей. На связях можно задавать и проверять ограничения типа и кардинальности, при нарушении которых возникают исключительные ситуации. Служба не вводит новую систему типов. Для представления связей и ролей используется система типов IDL. Интерфейсы связей и ролей могут расширяться дополнительными атрибутами и операциями. Служба позволяет связывать так называемые немутабельные объекты.

 Служба транзакций (TransactionService). Служба предоставляет гарантию того, что вычисления поддерживают некоторые или все присущие транзакциям ACID свойства (атомарность, непротиворечивость, изолированность, постоянство). Транзакционная служба поддерживает два вида транзакций: плоские (flat) и гнездовые (nested). Клиент может посылать заявки к множеству объектов, размещенных в различных узлах сети, в рамках области действия транзакции. Поддержка таких распределенных транзакций требует от ORB возможности передачи «контекста транзакции» с каждой заявкой.

 Служба изменения объектов (Change Management Service). Поддерживает идентификацию и согласованную эволюцию объектов. Сюда входит управление версиями существующих объектов, связанными наборами или конфигурациями объектов, и преобразованиями между соответствующими представлениями объектов.

 Служба лицензирования (Licensing Service). Служба обеспечивает среду для спецификации и управления лицензионной политикой.

 Служба объектных свойств (Properties Service). Позволяет связывать с объектом динамически создаваемые атрибуты. Посредством интерфейса, определенного службой, информация может быть связана с состоянием объекта (например, его заголовком или датой). Свойства являются динамическими эквивалентами атрибутов CORBA. Служба позволяет определять имена свойств, перечислять их, задавать им значения, получать значения по именам и удалять их.

 Служба объектных запросов (Object Query Service). Осуществляет операции над наборами объектов. Операции имеют основанную на предикатах декларативную спецификацию и могут возвращать наборы объектов как результат. Служба запросов не должна нарушать инкапсуляцию объектов. Далее служба запросов рассматривается детальнее.

 Служба безопасности объектов (Object Security Service). Контролирует доступ к объектам. Данная служба действует в пределах всей распределенной системы. Безопасность имеет дело с такими понятиями, как конфиденциальность и целостность информации, ответственность пользователей за свои действия, доступность информации. Дополнительные возможности в обеспечении безопасности могут предоставляться Общими средствами, использующими ядро системы безопасности, реализуемое службой безопасности.

 Служба объектного времени (Time Service). Поддерживает механизм синхронизации в распределенной системе.

Помимо рассмотренных, имеется также ряд служб, которые впоследствии были связаны с другими компонентами OMA (Общими средствами и Брокером). Так, к Общим средствам отнесены организация архивов (archive service), резервное копирование (backup service) и восстановление (restore service), операционный контроль (operational control service). К функциям ORB отнесены поддержка репозитория реализаций (implement­ation repository), инсталляция и активизация объектов и реализаций (installation and activation service), поддержание репозитория интерфейсов (interface repository), обеспечение механизма дублирования информации (replication service), запуск объектных служб (startup services service).

Общие средства заполняют концептуальное пространство между ORB и объектными службами, с одной стороны, и прикладными объектами – с другой. Таким образом, ORB обеспечивает базовую инфраструктуру, Объектные службы – фундаментальные объектные интерфейсы, а задача Общих средств – поддержку интерфейсов сервисов высокого уровня, которые, впрочем, могут включать специализацию Объектных служб. Таким образом, операции, представляемые Объектными службами, предназначены, в частности, для использования Общими средствами и прикладными объектами. Реализуется это посредством наследования стандартных интерфейсов. Рассматриваемая ниже архитектура Общих средств также является предварительной и при уточнении должна согласовываться с общей архитектурой OMG. Общие средства подразделяются на две категории: «горизонтальные» и «вертикальные» наборы средств.

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

Далее кратко рассматривается набор средств, вошедших в предварительные спецификации архитектуры Общих средств OMG [53]–[55].

Средства поддержки пользовательского интерфейса (User Interface Common Facilities). Средства поддержки пользовательского интерфейса включают средства, облегчающие прикладному программисту разработку интерфейсов прикладных систем. Сюда входят: средства управления представлением объектов (печать, вывод объектов на экран и т. п.); поддержка интерактивных средств описания объектов; механизмы хранения и представления подсказок (help) при разработке прикладных систем.

Средства управления информацией (Information Management Common Facilities). Информация может храниться как в структурированном виде в базах данных, так и в виде текстов, изображений и т. п. Средства управления информацией включают:

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

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

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

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

Средства управления системой (System Management Common Facili­ties) включают:

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

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

– инструментальные средства, обеспечивающие общие интерфейсы для сбора, управления и распространения данных о конкретных ресурсах системы;

– средства обеспечения безопасности системных ресурсов, также поддерживающие соответствующие общие интерфейсы;

– средства управления коллекциями объектов, позволяющие опрашивать коллекции и применять операции к их элементам;

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

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

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

Средства управления задачами (Task Management Common Facilities). В набор средств управления задачами входят:

– средства поддержки потоков работ (workflow), обеспечивающие управление и координацию объектов, представляющих некоторый рабочий процесс;

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

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

Вертикальные общие средства (Vertical Common Facilities) предназначены для использования в качестве стандартных для обеспечения интероперабельности в специфических прикладных областях. Сюда входят:

– средства работы с изображениями, включающие IDL-спецификации для доступа и обработки изображений;

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

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

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

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

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

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

Для связи между брокерами в гетерогенной сети был разработан протокол General Inter ORB Protocol (GIOP), стандартизирующий низкоуровневое представление данных и множество форматов сообщений. Этот протокол предоставляет возможность портировать приложения, обеспечивая минимальную зависимость от транспортного уровня передачи данных. Internet Inter ORB Protocol (IIOP) определяет обмен сообщениями в формате GIOP, используя TCP/IP-соединения. Этот протокол разработан для использования любыми объектными брокерами, реализованными на основе протокола IP. Однако при необходимости они могут содержать и другие реализации протокола GIOP, например, на основе протокола IPX/SPX. На рис. 1.9 показана иерархия спецификаций взаимодействия брокеров запросов по стандарту CORBA.

Рис. 1.9. Иерархия спецификаций взаимодействия брокеров запросов

В стандарте CORBA3 произошли существенные изменения в архитектуре объектных брокеров. Впервые введенный в стандартеCORBA2.2 портируемый объектный адаптер (POA–PortableObjectAdapter) стал одним из основных усовершенствованных элементов серверной части [56], [57].

Разработчиками стандарта был определен ряд новых понятий, связанных с жизненным циклом объектов. CORBA-объект– виртуальный объект, расположенный на брокере объектных запросов, посылающий запросы к другим CORBA-объектам – серверным объектам и получающий запросы от других CORBA-объектов – клиентов. В контексте запроса от клиента такой объект называют целевым (target object). Обращение к нему осуществляется по объектной ссылке (object reference).

Идентификатор объекта (object ID) – уникальное имя объекта внутри его объектного адаптера. Он представляет собой последовательность байт, которая ассоциируется с объектом в момент его создания и обеспечивается либо программным приложением, либо РОА. Идентификатор объекта не обязан быть уникальным для сервера, так как на сервере объект известен под своей объектной ссылкой.

Сервант – серверная программа, написанная на каком-либо из языков программирования и реализующая CORBA-объект. Это может быть набор функций, представляющих состояние объекта или реализации определенных классов серверного приложения (на C++ или Java). Сервант написан на том же программном языке, что и приложение, и является программной реализацией объекта CORBA.

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

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

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

Временные объекты– это объекты, чей жизненный цикл ограничен процессом или даже объектным адаптером, который их создал.

Деактивизация– действие, обратное активизации, останов CORBA-объ­екта, разрыв связки между объектом и сервантом, в общем случае без разрушения объекта. В дальнейшем CORBA-объект может быть вновь активизирован. Разрушение CORBA-объекта обязательно вызывает деактивизацию.

Инкарнация(воплощение) – это связывание серванта с CORBA-объек­том для обработки клиентского запроса. Инкарнация материализует в серванте виртуальный CORBA-объект. В отличие от активизации инкарнация относится не к объекту, а к его серванту.

Эфемеризация– в противоположность инкарнации – разрушение связки «CORBA-объект – сервант» со стороны серванта. Так же как инкарнация, эфемеризация является операцией серванта.

Карта активных объектов(Active Object Map) – таблица объектного адаптера, в которой он ведет реестр активных CORBA-объектов и связанных с ними сервантов. Первые представлены в карте своими идентификаторами.

Объектный адаптер должен выполнять следующие операции:

– создавать CORBA-объекты и их объектные ссылки;

– демультиплексировать запросы на каждый серверный CORBA-объ­ект;

– коммутировать запросы к соответствующему серванту, который обеспечивает реализацию серверного CORBA-объекта;

– активизировать и деактивизировать CORBA-объекты и, соответственно, выполнять инкарнацию и эфемеризацию соответствующих сервантов.

POAподдерживает следующие модели активизации серверных объектов.

 Точная (explicit) активизация – регистрация сервантов для CORBA-объектов напрямую в серверной программе посредством прямого обращения к POA.

 Активизация по требованию. В серверном программном приложении регистрируется менеджер сервантов, который и вызывает POA, когда получает запрос для CORBA-объектов, которые еще не активизированы. Менеджер сервантов в этом случае осуществляет одно из следующих действий:

– инкарнирует сервант, если нужно, и регистрирует его в POA, который затем передает соответствующие запросы напрямую серванту, минуя менеджер;

– пересылает запрос другому объекту;

– отвечает POA, что CORBA-объект разрушен (destroyed).

 Безусловная активизация. Сервант активизируется без уведомления об этом POA.

 Сервант по умолчанию. Сервант по умолчанию (default servant) используется для запросов к тем CORBA-объектам, которые еще не активизированы и не зарегистрированы в менеджере сервантов. Такие серванты особенно полезны, когда используется DSI (Dynamic Skeleton Interface), что­бы инкарнировать все CORBA-объекты без привлечения менеджера сервантов.

Для связок «сервант – объект» POA также предлагает различные модели:

– каждый CORBA-объект активизируется своим сервантом;

– POA позволяет одному серванту инкарнировать несколько CORBA-объектов (происходит экономия серверных ресурсов);

– активизация сервантов только по требованию клиента при наличии запроса.

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

– для каждого запроса создается отдельный поток;

– для каждого объекта создается отдельный поток;

– для всех запросов создается один общий поток;

– создается пул потоков фиксированного размера для обработки всех запросов.

Выбор конкретной потоковой политики зависит от программных приложений распределенной среды. На более высоком уровне ORB CORBA 3 предоставляет две модели многопоточности:

– ОRВ-управляемая – сам ОRВ выбирает подходящую модель работы с потоками, и обработка запросов ведется параллельно;

– однопотоковая модель гарантирует, что все запросы для всех объектов в РОА будут обрабатываться в одном потоке. Обработка запросов ведется последовательно.

Таким образом, модели CORBA 3 предоставляют широкие возможности для управления объектами распределенной информационной среды.

Новые спецификации сообщений в CORBA 3 включают асинхронный метод вызова (AMI–AsynhronousMethodInvocation), где определены две новые модели:

– обратный вызов (callback) – каждый вызов клиента в качестве параметра содержит объектную ссылку на специальный объект, управляющий такими вызовами, который и получает отклик от целевого объекта. Этот объект клиентской части перенаправляет его соответствующему клиенту;

– голосование (polling). Для этой модели IDL был расширен новым типом данных: Poller valuetype, который наследуется от нового типа данных, определенного в спецификациях Передача объекта по значению. Клиент использует специальный Poller-метод, чтобы получать информацию о статусе своего вызова: подготовил ли сервер ответ, и если да, то считать отклик.

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

Спецификация модели составного объекта (ComponentObjectModel,COM) является одним из стандартовOLE(ObjectLinkingandEmbedding).OLEпозволяет увеличить степень интеграции программных модулей и приблизиться к созданию множества взаимозаменяемых компонентов ПО. Общим во всех стандартных соединенияхOLEявляется то, что все они входят в модель составного объектаOLE, которая является объектно-ориенти­рованной спецификацией для определения интерфейсов взаимодействующих компонентов.

Существует две основных концепции программирования OLE:

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

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

После соединения с библиотекой OLEу модуля есть выбор: соединиться с интерфейсомOLE(стать клиентом интерфейсаOLE) или сделать интерфейсOLEдоступным для других (стать сервером интерфейсаOLE).

Интерфейсы OLE(OLEinterfaces) создаются на базе спецификации модели составного объекта (ComponentObjectModel) и поэтому называются интерфейсамимодели составного объекта, илиСОМ-интерфейсами[46], [58].

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

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

Интерфейс представляет собой контракт на услуги, поставляемые одним компонентом – «сервером» и используемые другим – «клиентом». Единственный код, соответствующий определению интерфейса, состоит из списка прототипов функций – возвращаемых значений функций, имён функций и их параметров. Контракт задаёт то, какие услуги предоставляются, но не как они предоставляются. Детали реализации инкапсулированы (incapsulated) внутри поставщика услуги.

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

Специальным соединением, которым сервер обеспечивает клиентов, является указатель на массив указателей на функции (pointertoanarrayoffunctionpointers). Для клиента бинарный интерфейс остаётся массивом функций независимо от того, действует ли соединение клиент/сервер в одном процессе (in-process), или в пределах нескольких процессов, или в рамках сети. Когда сервер работает со своим клиентом в одном процессе, один массив функций связывает воедино вызовы от клиента и функции в сервере.

При вызове сервера извне (out-of-process) клиент по-прежнему видит только массив функций. Запросы от других процессов обслуживают два типа серверов: локальные серверы (localservers), которые действуют с клиентом в разных адресных пространствах одной машины, и удалённые серверы (remoteservers), которые действуют на разных машинах. Для вызывающей программы различие между локальными и удалёнными услугами незаметно, так как сервер обеспечивает соединение через границу процессов или сетей.

Основные функции поддержки для удалённого соединения выполняют библиотеки OLE.

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

Упаковка, пересылка и распаковка, выполняемые функциями-посред­никами и заглушками, называются формированием (marshaling).OLEпо умолчанию обеспечивает поддержку для всех определённых вOLEинтерфейсов, использующих механизм встроенных вызовов удалённых процедур (remoteprocedurecall,RPC) для вызовов между процессами и между компьютерами. В случае определения пользовательского интерфейса у него отсутствует встроенная поддержка удалённого вызова. Поэтому для реализации удалённого пользовательского интерфейса вOLEимеется два варианта. Первый вариант предполагает описание интерфейса на языке определения интерфейса (InterfaceDefinitionLanguage,IDL) и компиляцию этого описания компиляторомMicrosoftIDL. Этот компилятор создаёт кодыproxy- иstub-функций, которые встраиваются вDLL.

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

Таблица функций интерфейса OLEсодержит два рода функций: базовые функции интерфейса и специализированные функции интерфейса.

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

В реестре Win95 данные, относящиеся к компонентамOLE, находятся вHKEY_CLASSES_ROOT. Имеется три типа системных элементов реестра, каждый из которых является корневым и имеет собственную иерархию:Typelib,InterfaceиCLSID. ИерархияTypelibидентифицирует положение инсталлированных в данный момент библиотек типов, которые являются базами данных, описывающими содержимое компонентовOLE. Используемая для поддержки автоматизации библиотека типов описывает прототипы функций для всех поддерживающих интерфейсов и включает в себя ссылки на файлы подсказки.

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

Компоненты СОМ состоят из исполняемого кода, распространяемого в виде динамически компонуемых библиотек (DLL) или ЕХЕ-файловWin32.

Компоненты СОМ удовлетворяют определённым ограничениям:

– они полностью независимы от языка программирования;

– могут распространяться в двоичной форме;

– их можно модернизировать, не нарушая работы старых клиентов;

– они являются прозрачно перемещаемыми. Компонент в сети рассматривается так же, как и компонент на локальном компьютере.

IDL в СОМ заимствован из RPC OSF (Open Software Foundation).

Сходство технологий CORBAиDCOMпроявляется в том, что они обе основываются на коммуникации клиент – сервер. Различие же проявляется в том, что еслиDCOMподдерживает объекты с множественными интерфейсами и предоставляет стандартный методQueryInterface(…) для навигации между ними, то вCORBAподобная конструкция отсутствует.

Каждый интерфейс в CORBAнаследуется отCORBA:Object, конструктор которого выполняет ряд общих действий, таких как регистрация объекта, генерация объектной ссылки, обработка серверной функции заглушки (skeleton). ВDCOMтакие функции явно выполняются серверной программой или динамически средствами библиотекDCOM.

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

Достоинством технологии DCOMявляется то, что стоимость создаваемых с её помощью распределённых информационных систем относительно невелика (точнее, стоимость прямых затрат на приобретение ПО). В качестве регистрационной БД используется реестрWindows, поддержкаDCOMв виде соответствующих библиотек присутствует в системеWindowsNTи доступна бесплатно дляWindows95/98. Сервисы, выполняющие поиск одной из нескольких реализаций сервера для данного клиента, вDCOMотсутствуют, поскольку местоположение реализации сервера фиксируется при настройкеDCOMдля конкретного клиента.

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

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

Проблемы авторизованного доступа к СОМ-сервисам в рамках традиционной СОМ-технологии полностью возлагается на разработчиков этих сервисов и системных администраторов, конфигурирующих компоненты DCOM. Для решения этих проблем компаниейMicrosoftразработана технологи СОМ+, реализованная в виде продуктаMicrosoftTransactionServer(MTS), который представляет собой сервис, обеспечивающий централизацию использования серверов автоматизации, управление транзакциями и совместное использование несколькими клиентами соединения с БД независимо от реализации сервера. ВерсияMTS2.0 входит в составNTOptionPack(находится наweb-сайтеMicrosoftи доступна дляWindowsNTиWindows95/98), хотя некоторые возможностиMTS(например, управление удалёнными объектами) реализованы только в версииNTOptionPackдляWindowsNT.

Метод JavaRMI(JavaRemoteMethodInvocation) – метод удаленных вызововJava– позволяет объектам, запущенным на одной виртуальной машине (JavaVirtualMachine), вызывать методы на объекте, запущенном (выполняющемся) на другойJavaVM, таким образом обеспечивая связь между удаленными программами, написанными на языкеJava[59]–[61].

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

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

Уникальной характеристикой RMIявляется возможность загрузки исполняемого кода (bytecodes) как объектного класса, если класс не определен в виртуальной машине получателя. Таким образом обеспечивается передача объекта по значению, а не только по ссылке.

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

Построение распределенного приложения средствами RMIвключает следующие шаги: разработка и реализация компонентов приложения (определение удаленных интерфейсов, реализация удаленных объектов, реализация клиентов); компиляция исходных файлов и создание заглушек (stubs); создание доступных сетевых классов (classesnetwork); запуск приложения (запуск регистра удаленных объектовRMI, запуск сервера и клиента). Подробности этого процесса читатель может найти в [62].

Несомненным достоинством RMIявляется ясность процесса построения распределенных приложений с точки зрения программной идеологии.

В настоящее время происходит сближение подходов, используемых консорциумом OMG(идеологияCORBA) и корпорациейSun(JavaRMI). Модель построения серверных компонентовEnterpriseJavaBeans(EJB) интегрируется с конструкциейCORBA, при этом для взаимодействия удаленных объектов может использоваться какORB, так иRMIAPI, функционирующие через протоколIIOP.CORBAобеспечивает необходимые системные службы, аEJBподдерживает интероперабельность программных объектов.

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