1.3. Распределенные объектные архитектуры
Традиционный структурный подход к проектированию КИС предполагает последовательную реализацию основных этапов разработки системы: системный анализ, построение функциональных моделей, системный проект, проектирование программных модулей, отладка программных модулей и объединение в целостную систему, тестирование и внедрение программного продукта.
Применение CASE-технологий и средств позволяет значительно сократить сроки разработки КИС и снизить вероятность появления ошибок за счет автоматического контроля создаваемых диаграмм, автоматической генерации структуры сервера БД и программного кода клиентских приложений.
В то же время обнаруживаются следующие недостатки таких технологий и средств:
программные коды клиентских приложений генерируются на основе реляционной структуры БД;
возникают проблемы перехода от табличных структур БД к требуемым экранным формам приложений, что затрудняет разработку программ со сложной бизнес-логикой;
сохраняются недостатки традиционного структурного подхода при обнаружении ошибок на заключительных стадиях проектирования.
Обозначенные выше проблемы позволяют решить объектно-ориентированные методы разработки РИУС [45, 46, 47, 48].
Данные методы обладают следующими преимуществами:
возможно эффективное построение гетерогенных распределенных ИС, вследствие того, что объект-сервер инкапсулирует от клиента детали реализации предоставляемого сервиса;
объектно-ориентированные КИС могут развиваться эволюционно, путем модернизации отдельных объектов, не затрагивая остальные части системы, что снижает затраты на сопровождение и риск капиталовложений;
использование механизма унаследованных приложений позволяет включать разработанные ранее приложения в распределенную среду через объекты-оболочки (wrappers);
объектно-ориентированные КИС обладают свойством независимости объектов от размещения, вызов объектов осуществляется стандартным образом и не зависит от коммуникационного программного обеспечения;
обеспечивается масштабируемость КИС и возрастает их отказоустойчивость за счет репликации объектов;
использование открытых стандартов обеспечивает независимость ИС от конкретных платформ, программных продуктов и фирм-производителей.
КИС, включающая в себя множество взаимосвязанных удалённых программных объектов, называется распределённой объектной системой.
К настоящему времени сложились три основные конкурирующие технологии создания распределённых объектных систем:
архитектура Группы управления объектами (Object Management Group, OMG), определяется как «Общая архитектура брокера объектных запросов» (Common object request Broker Architecture, CORBA);
система вызовов удалённых методов Java (Remove Method Invocation, RMI);
модель распределённых компонентных объектов Microsoft (Distributed Component Object Model, 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, 51, 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);
язык определения интерфейсов (Interface Definition Language);
объектный адаптер (Object adapter);
репозиторий интерфейсов (Interface Repository).
Наличие большого количества сетевых протоколов в разных операционных системах, потребовало разработки спецификации сетевых соединений. Семиуровневая модель Open System Interсonnection (OSI) обеспечивает описание сервисов, которые каждый уровень должен предоставлять для реализации соединения (рис.1.5). Низший уровень - физический, определяет доступ к физической линии. Уровень данных обеспечивает достоверную передачу данных по физической линии. Сетевой уровень имеет дело с установкой соединения и маршрутизацией. Транспортный уровень отвечает за достоверную передачу до точки назначения. Уровень сессий обеспечивает управление соединением. Уровень представлений описывает синтаксиса данных и обеспечивает прозрачность для приложений. Последний уровень - уровень приложений - обеспечивает соответствующие сетевые функции для конечного пользователя.
Концептуально CORBA относится к уровням приложений и представлений. Она обеспечивает возможность построения распределенных систем и приложений на самом высоком уровне абстракции в рамках стандарта OSI. С её помощью возможно изолировать клиентские программы от низкоуровневых, гетерогенных характеристик информационных систем. Характерные особенности разработки по технологии CORBA заключаются в следующем.
Язык описания интерфейсов OMG IDL позволяет определить интерфейс, независимый от языка программирования, используемого для реализации.
Рис.1.5. Семиуровневая модель сетевого взаимодействия OSI
Высокий уровень абстракции CORBA в семиуровневой модели OSI позволяет программисту не работать с низкоуровневыми протоколами.
Программисту не требуется информация о реальном месте расположения сервера и способе его активации.
Разработка клиентской программы не зависит от серверной операционной системы и аппаратной платформы.
Объектная модель CORBA определяет взаимодействие между клиентами и серверами. Клиенты - приложения, которые запрашивают сервис. Серверы – приложения, предоставляющие сервисы. Объекты-серверы содержат набор сервисов, разделяемых между многими клиентами. Операция указывает запрашиваемый сервис объекта-сервера. Интерфейсы объектов есть описание множества операций, которые могут быть вызваны клиентами данного объекта. Реализации объектов - приложения реально исполняющие сервисы, запрашиваемые клиентами.
Спецификация CORBA разработана для обеспечения возможности интеграции совершенно различных объектных систем. На рис. 1.6. показана схема работы объектного брокера.
Рис.1.6. Схема работы объектного брокера запросов
Его задачей является предоставление механизма выполнения запроса, сделанного клиентом: поиск объекта, к которому относится данный запрос, передача необходимых данных, подготовка объекта к обработке. Интерфейс, с помощью которого клиент может запрашивать выполнение необходимых операций, не зависит от местонахождения объекта и языка программирования, с помощью которого он реализован. Клиент может запрашивать выполнение операций с помощью ORB несколькими способами. На рис.1.7. показаны способы возможного взаимодействия объектов.
Вызов операций разделяемого объекта-сервера может быть сделан статическим (IDL stub) и динамическим (Dynamic Invocation Interface) способом. Интерфейсы описываются, используя язык определения интерфейсов, получивший название OMG Interface Definition Language. В случае статического вызова описания интерфейсов отображаются в программный код на языках С, С++, Smalltalk. Информация об интерфейсах объектов может быть получена клиентом двумя способами: статически (compile time) и динамически (runtime). Интерфейсы могут быть также указаны с помощью службы репозитория интерфейсов (Interface Repository). Этот сервис представляет интерфейсы, как объекты, обеспечивая доступ к ним в время работы приложения (runtime режиме).
Главная функция объектного адаптера, используемого для реализации объекта, - предоставление доступа к сервисам объектного брокера ORB. Объектный адаптер обеспечивает все низкоуровневые средства для связи объекта с его клиентами. Основными задачами объектного адаптера являются: генерация ссылок на удаленные объекты; вызов метода объекта, определенного в IDL; обеспечение безопасности взаимодействия; активация и деактивация объектов; установление соответствия между ссылками на удаленные объекты (proxy) и реальными экземплярами объектов; регистрация объектов.
Рис.1.7. Статический и динамический способы взаимодействия объектов с использование ORB
Спецификация OMG CORBA определяет базовый объектный адаптер, который должен быть реализован во всех брокерах запросов. Basic Object Adapter (BOA) - это набор интерфейсов для создания ссылок на удаленные объекты, регистрации объектов, авторизации запросов и активизации приложений. Роль базового объектного адаптера в архитектуре CORBA иллюстрируется рис.1.8.
Рис.1.8. Схема получения запроса
В настоящее время OMG приняты или находятся в процессе формирования спецификации следующих служб:
Служба Уведомления Объектов о Событии (Event Notification Service). Служба обеспечивает извещение заинтересованных объектов о происходящих в системе событиях. Объект может выступать в качестве «производителя» или «потребителя» некоторого события. Для обеспечения асинхронного взаимодействия множества производителей событий с множеством их потребителей используются специальные объекты – «каналы событий», которые являются стандартными объектами 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. Интерфейсы связей и ролей могут расширяться дополнительными атрибутами и операциями. Служба позволяет связывать так называемые немутабельные объекты.
Служба Транзакций (Transaction Service). Служба предоставляет гарантию того, что вычисления поддерживают некоторые, или все присущие транзакциям 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 отнесены поддержка репозитория реализаций (implementation repository), инсталляция и активизация объектов и реализаций (installation and activation service), поддержание репозитория интерфейсов (interface repository), обеспечение механизма дублирования информации (replication service), запуск объектных служб (startup services service).
Общие Средства заполняют концептуальное пространство между ORB и объектными службами с одной стороны, и прикладными объектами, с другой. Таким образом, ORB обеспечивает базовую инфраструктуру, Объектные Службы - фундаментальные объектные интерфейсы, а задача Общих Средств - поддержка интерфейсов сервисов высокого уровня, которые, впрочем, могут включать специализацию Объектных Служб. Таким образом, операции, представляемые Объектными Службами, предназначены, в частности, для использования Общими Средствами и прикладными объектами. Реализуется это посредством наследования стандартных интерфейсов. Рассматриваемая ниже архитектура Общих Средств также является предварительной и при уточнении должна согласовываться с общей архитектурой OMG. Общие Средства подразделяются на две категории: "горизонтальные" и "вертикальные" наборы средств.
"Горизонтальный" набор средств определяет операции, используемые во многих системах и не зависящие от конкретных прикладных систем. "Вертикальный" набор средств представляет технологию поддержки конкретной прикладной системы (вертикального сегмента рынка, включающего здравоохранение, производство, управление финансовой деятельностью, САПР и т.д.). При этом возможна эволюция Общих Средств, связанная с миграцией вертикальных средств, которые оказываются общими для ряда прикладных систем, в набор горизонтальных средств. Следует отметить, что грань между Объектными Службами и Общими Средствами, также как и между Общими Средствами и прикладными объектами, не является жестко фиксированной. Она может изменяться вместе с развитием объектной технологии. Архитектурные требования определения Общих Средств аналогичны требованиям, которые должны выполняться при определении Объектных Служб.
Ниже кратко рассматривается набор средств, вошедших в предварительные спецификации архитектуры Общих Средств OMG [53, 54, 55].
Средства поддержки пользовательского интерфейса (User Interface Common Facilities). Средства поддержки пользовательского интерфейса включают средства, облегчающие прикладному программисту разработку интерфейсов прикладных систем. Сюда входят: средства управления представлением объектов (печать, вывод объектов на экран и т.п.); поддержка интерактивных средств описания объектов; механизмы хранения и представления подсказок (help) при разработке прикладных систем.
Средства управления информацией (Information Management Common Facilities). Информация может храниться как в структурированном виде в базах данных, так и в виде текстов, изображений и т.п. Средства управления информацией включают:
средства информационного моделирования. Традиционно средства моделирования определяются как средства структурирования данных, средства манипулирования данными и средства поддержки целостности информации. В объектной парадигме данные и операции моделируются единообразно в рамках общей системы типов;
средства хранения и поиска информации. Речь идет об обеспечении высокоуровневых спецификаций хранения и поиска иформации для широкого класса прикладных систем. Главными проблемами здесь являются отсутствие стандартов для доступа к информационным системам (даже SQL существует в разных версиях), а также стандартных средств метаописания запрашиваемой информации;
средства кодирования и представления данных, формирующие самый нижний уровень моделирования информации. Эти средства должны обеспечивать, в частности, сжатие и декомпрессию данных, а также преобразование между внутренним и каноническим представлением;
средства поддержки коллекций объектов, предназначенные для обеспечения единообразного способа создания и манипулирования наиболее общими видами коллекций, используемых в компьютерных системах (множества, очереди, стеки, списки, бинарные деревья и т.п.), независимо от объектов, входящих в коллекции.
Средства управления системой (System Management Common Facilities) включают:
средства управления дисциплиной манипулирования объектами. При этом администратор имеет возможность определять значения атрибутов объектов по умолчанию и правила корректной модификации этих значений, а также группировать ресурсы с заданной дисциплиной манипулирования;
средства управления качеством служб, позволяющие выбрать необходимый уровень доступности, производительности, надежности и восстанавливаемости системы;
инструментальные средства, обеспечивающие общие интерфейсы для сбора, управления и распространения данных о конкретных ресурсах системы;
средства обеспечения безопасности системных ресурсов, также поддерживающие соответствующие общие интерфейсы;
средства управления коллекциями объектов, позволяющие опрашивать коллекции и применять операции к их элементам;
средства управления экземплярами, определяющие базовые операции для манипулирования экземплярами объектных типов. Сюда, в частности, входят средства для организации произвольных логических ассоциаций объектов;
средства настройки объектов, позволяющие модифицировать объекты для обеспечения более комфортной среды, сохраняя при этом корректность типов и существующих объектных ссылок;
средства управления событиями, обеспечивающие активный режим выполнения операций.
Средства управления задачами (Task Management Common Facilities). В набор средств управления задачами входят:
средства поддержки потоков работ (workflow), обеспечивающие управление и координацию объектов, представляющих некоторый рабочий процесс;
средства управления агентами. Система агентов является одним из верхних уровней представления семантики взаимодействия компонентов, основанного на архитектуре OMG. Средства управления агентами призваны, в частности, облегчить процесс интеграции унаследованных систем;
средства управления сообщениями, поддерживающие коммуникации высокого уровня для разработчиков прикладных интероперабельных систем.
Вертикальные общие средства (Vertical Common Facilities) предназначены для использования в качестве стандартных для обеспечения интероперабельности в специфических прикладных областях. Сюда входят:
средства работы с изображениями, включающие IDL-спецификации для доступа и обработки изображений;
средства поддержки международной информационной супермагистрали, реализующие коммерческие операции, поиск информационных ресурсов, проведение телеконференций и т.п. в среде супермагистрали;
средства поддержки прикладных систем для бизнеса и производства (контроль качества продукции, САПР, маркетинг, финансы, операции с банковскими счетами и т.д.);
распределенные моделирующие средства, включающие управление авиаперевозками, ситуационное моделирование для военных и игровых целей и т.д.;
средства поддержки разведывательных работ и производства в газовой и нефтяной промышленности. Следует отметить, что по инициативе ряда ведущих компаний данной отрасли, в 1991 году была начата работа по созданию стандартов, которые позволили бы повысить эффективность информационного обеспечения предприятий. Эти работы учитываются OMG при выработке стандартов соответствующих общих средств;
средства поддержки разработки прикладных систем, включающие средства анализа, разработки, построения и развития информационных систем предприятий.
Начиная со стандарта CORBA 2.0, вводятся механизмы одновременного сосуществования в распределённой объектной среде нескольких (возможно, разнотипных) объектных брокеров и определяются механизмы их взаимодействия.
Для связи между брокерами в гетерогенной сети был разработан протокол General Inter ORB Protocol (GIOP), стандартизирующий низкоуровневое представление данных и множество форматов сообщений. Этот протокол предоставляет возможность портировать приложения, обеспечивая минимальную зависимость от транспортного уровня передачи данных. Internet Inter ORB Protocol (IIOP) определяет обмен сообщениями в формате GIOP, используя TCP/IP соединения. Этот протокол разработан для использования любыми объектными брокерами, реализованными на основе протокола IP. Однако, при необходимости, они могут содержать и другие реализации протокола GIOP, например, на основе протокола IPX/SPX. На рисунке 1.9 показана иерархия спецификаций взаимодействия брокеров запросов по стандарту CORBA.
Рис.1.9. Иерархия спецификаций взаимодействия брокеров запросов
В стандарте CORBA 3 произошли существенные изменения в архитектуре объектных брокеров. Впервые введенный в стандарте CORBA 2.2 портируемый объектный адаптер (POA – Portable Object Adapter) стал одним из основных усовершенствованных элементов серверной части [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 – Asynhronous Method Invocation), где определены две новые модели:
обратный вызов (callback) – каждый вызов клиента в качестве параметра содержит объектную ссылку на специальный объект, управляющий такими вызовами, который и получает отклик от целевого объекта. Этот объект клиентской части перенаправляет его соответствующему клиенту.
голосование (polling). Для этой модели IDL был расширен новым типом данных: Poller valuetype, который наследуется от нового типа данных, определенного в спецификациях Передача Объекта по Значению. Клиент использует специальный Poller метод, чтобы получать информацию о статусе своего вызова: подготовил ли сервер ответ и если да, то считать отклик.
Асинхронный метод вызова является весьма полезным при создании агентно-ориентированных систем, поскольку позволяет обеспечит автономные действия программных агентов.
Спецификация модели составного объекта (Component Object Model, COM) является одним из стандартов OLE (Object Linking and Embedding). OLE позволяет увеличить степень интеграции программных модулей и приблизиться к созданию множества взаимозаменяемых компонентов ПО. Общим во всех стандартных соединениях OLE является то, что все они входят в модель составного объекта OLE, которая является объектно-ориентированной спецификацией для определения интерфейсов взаимодействующих компонентов.
Существует две основных концепции программирования OLE:
1). чтобы использовать OLE, необходимо в первую очередь связаться с библиотекой OLE;
2). перед расшифровкой возвращаемого значения функций типа HRESULT, необходимо определить успешной или нет была попытка установления соединения.
После соединения с библиотекой OLE у модуля есть выбор: соединиться с интерфейсом OLE (стать клиентом интерфейса OLE), или сделать интерфейс OLE доступным для других (стать сервером интерфейса OLE).
Интерфейсы OLE (OLE interfaces) создаются на базе спецификации модели составного объекта (Component Object Model), и поэтому называются интерфейсами модели составного объекта или СОМ-интерфейсами [46, 58].
СОМ обеспечивает описание фундаментальных связей, которые необходимы между поставщиком интерфейса (interface provider) и пользователем интерфейса (interface user).
Интерфейсы одновременно являются контрактами на услуги, бинарными соединениями между поставщиками услуг и пользователями этих услуг, и механизмом, поддерживающим соединения между процессами и между машинами. Эти элементы связываются посредством набора основополагающих функций ядра (ОС Windows), которые разделяются всеми интерфейсами.
Интерфейс представляет собой контракт на услуги, поставляемые одним компонентом – «сервером» и используемые другим – «клиентом». Единственный код, соответствующий определению интерфейса, состоит из списка прототипов функций – возвращаемых значений функций, имён функций и их параметров. Контракт задаёт то, какие услуги предоставляются, но не как они предоставляются. Детали реализации инкапсулированы (incapsulated) внутри поставщика услуги.
По своей сути бинарная реализация интерфейса является массивом указателей их функций. Сервер для интерфейса данного типа реализует конкретные функции и строит массив указателей на функции. Клиент ожидает доступа к функциям сервера через такой массив.
Специальным соединением, которым сервер обеспечивает клиентов, является указатель на массив указателей на функции (pointer to an array of function pointers). Для клиента бинарный интерфейс остаётся массивом функций, независимо от того, действует ли соединение клиент/сервер в одном процессе (in-process), или в пределах нескольких процессов, или в рамках сети. Когда сервер работает со своим клиентом в одном процессе, один массив функций связывает воедино вызовы от клиента и функции в сервере.
При вызове сервера извне (out-of-process), клиент по-прежнему видит только массив функций. Запросы от других процессов обслуживают два типа серверов: локальные серверы (local servers), которые действуют с клиентом в разных адресных пространствах одной машины, и удалённые серверы (remote servers), которые действуют на разных машинах. Для вызывающей программы отличие между локальными и удалёнными услугами незаметно, так как сервер обеспечивает соединение через границу процессов или сетей.
Основные функции поддержки для удалённого соединения выполняют библиотеки OLE.
В адресном пространстве процесса-клиента создаётся массив функций и соединяется с набором передающих функций-посредников (proxy functions), которые упаковывают параметры вызова для пересылки их принимающему интерфейсу в адресном пространстве сервера. В адресном пространстве сервера набор получающих функций-заглушек (stub functions) распаковывает оболочку и вызывает настоящие функции сервера. Которые и используют переданные параметры.
Упаковка, пересылка и распаковка, выполняемая функциями-посредниками и заглушками называется формированием (marshaling). OLE по умолчанию обеспечивает поддержку для всех определённых в OLE интерфейсов, использующих механизм встроенных вызовов удалённых процедур (remote procedure call, RPC) для вызовов между процессами и между компьютерами. В случае определения пользовательского интерфейса у него отсутствует встроенная поддержка удалённого вызова. Поэтому для реализации удалённого пользовательского интерфейса в OLE имеется два варианта. Первый вариант предполагает описание интерфейса на языке определения интерфейса (Interface Definition Language, IDL) и компиляцию этого описания компилятором Microsoft IDL. Этот компилятор создаёт коды proxy и stub функций, которые встраиваются в DLL.
Второй вариант предполагает самостоятельное управление всеми аспектами формирования, что позволяет использовать любой механизм передачи (разделяемую память, сообщения Windows, именованные каналы связи, RPC и т. д.). Этот случай называется «пользовательским формированием» (custom marshaling).
Таблица функций интерфейса 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 поддерживает объекты с множественными интерфейсами и предоставляет стандартный метод Query Interface (…) для навигации между ними, то в CORBA подобная конструкция отсутствует.
Каждый интерфейс в CORBA наследуется от CORBA: Object, конструктор которого выполняет ряд общих действий, таких как регистрация объекта, генерация объектной ссылки, обработка серверной функции заглушки (skeleton). В DCOM такие функции явно выполняются серверной программой или динамически средствами библиотек DCOM.
В DCOM транспортный протокол (маршаллинг) обязательно связан с RPC, в CORBA же реализуются различные транспортные протоколы. К тому же технология DCOM ориентирована на операционные системы Windows (в основном), в то время как спецификации CORBA определяют архитектуру межплатформенного взаимодействия.
Достоинством технологии DCOM является то, что стоимость создаваемых с её помощью распределённых информационных систем относительно невелика (точнее стоимость прямых затрат на приобретение ПО). В качестве регистрационной БД используется реестр Windows, поддержка DCOM в виде соответствующих библиотек присутствует в системе Windows NT и доступна бесплатно для Windows 95/98. Сервисы, выполняющие поиск одной из нескольких реализаций сервера для данного клиента в DCOM отсутствуют, поскольку местоположение реализации сервера фиксируется при настройке DCOM для конкретного клиента.
Но существует ряд проблем разработки и эксплуатации распределённых систем на базе СОМ. При разработке СОМ-серверов для доступа к данным, обслуживающих нескольких клиентов, требуется создавать многопоточный многопользовательский сервис, который предъявляет повышенные требования к аппаратному обеспечению. Создание серверных объектов по запросу клиентов требует значительных ресурсов оперативной памяти и времени, что становится заметно при промышленной эксплуатации распределённых систем, когда удалённые модули данных обслуживают большие объёмы информации из множества таблиц.
Определённые проблемы представляет обработка распределённых транзакций, которая усложняет создание клиентских приложений и порождает соответствующие требования к аппаратному обеспечению рабочих станций.
Проблемы авторизованного доступа к СОМ-сервисам в рамках традиционной СОМ-технологии полностью возлагается на разработчиков этих сервисов и системных администраторов, конфигурирующих компоненты DCOM.
Для решения этих проблем компанией Microsoft разработана технологи СОМ+, реализованная в виде продукта Microsoft Transaction Server (MTS), который представляет собой сервис, обеспечивающий централизацию использования серверов автоматизации, управление транзакциями и совместное использование несколькими клиентами соединения с БД независимо от реализации сервера. Версия MTS 2.0 входит в состав NT Option Pack (можно получить на web-сайте Microsoft и доступна для Windows NT и Windows 95/98, хотя некоторые возможности MTS (например, управление удалёнными объектами) реализованы только в версии NT Option Pack для Windows NT.
Метод Java RMI (Java Remote Method Invocation) – метод удаленных вызовов Java позволяет объектам, запущенным на одной виртуальной машине (Java Virtual Machine) вызывать методы на объекте, запущенном (выполняющемся) на другой Java VM, таким образом обеспечивая связь между удаленными программами, написанными на языке Java [59, 60, 61].
RMI-приложение обычно содержит две отдельные программы: сервер и клиент. Типичное серверное приложение создает некоторые удаленные объекты, делает доступными ссылки на них и ждет обращений клиентов к этим удаленным объектам. RMI обеспечивает механизм с помощью которого сервер и клиент связываются и передают информацию друг другу.
Приложение может использовать один из двух механизмов получения ссылок на удаленные объекты. Приложение может зарегистрировать удаленные объекты в регистре RMI, или может передавать и возвращать ссылки на удаленные объекты как часть своей нормальной операции. Детали установления связи между удаленными объектами скрываются RMI, для программиста процесс выглядит как стандартный вызов метода Java.
Уникальной характеристикой RMI является возможность загрузки исполняемого кода (bytecodes) как объектного класса, если класс неопределен в виртуальной машине получателя. Таким образом обеспечивается передача объекта по значению, а не только по ссылке.
RMI передает объекты в их уникальном содержании, так что поведение этих объектов не изменяется при получении удаленной виртуальной машиной. Это позволяет изменять поведение приложения динамически, что является очень важным свойством с позиций построения распределенных интеллектуальных систем.
Построение распределенного приложения средствами RMI включает следующие шаги: разработка и реализация компонентов приложения (определение удаленных интерфейсов, реализация удаленных объектов, реализация клиентов); компиляция исходных файлов и создание заглушек (stubs); создание доступных сетевых классов (classes network); запуск приложения (запуск регистра удаленных объектов RMI, запуск сервера и клиента). Подробности этого процесса читатель может найти в [62].
Несомненным достоинством RMI является ясность процесса построения распределенных приложений с точки зрения программной идеологии.
В настоящее время происходит сближение подходов, используемых консорциумом OMG (идеология CORBA) и корпорацией Sun (Java RMI). Модель построения серверных компонентов Enterprise Java Beans (EJB) интегрируется с конструкцией CORBA, при этом для взаимодействия удаленных объектов может использоваться как ORB, так и RMI API, функционирующие через протокол IIOP. CORBA обеспечивает необходимые системные службы, а EJB поддерживает интероперабельность программных объектов.
Java RMI не является в полном смысле брокером запросов к объектам, хотя и поддерживает многие функции ORB. В отличие от CORBA спецификация RMI разработана ещё недостаточно глубоко и ориентирована только на один язык программирования Java, который также весьма молод по отношению к другим языкам. В то же время язык Java пользуется сейчас большой популярностью, активно продвигается многими компаниями на программно-информационном рынке и обеспечивает полную независимость от используемой платформы.