Риc.1.1. Вертикальная архитектура системы

В случае горизонтально построенной системы количество интерфейсов (интеграционного кода) будет минимальным. Добавление новой компоненты потребует реализовать дополнительно всего два интерфейса (рис. 1.2).

Рис.1.2 Горизонтальная архитектура системы

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

Количество кода необходимого для интеграции новой задачи при такой архитектуре изменяется в зависимости от проекта от 2 (горизонтальная архитектура) до 2N (вертикальная архитектура) (рис.1.3.).

Риc. 1.3. Гибридная архитектура системы

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

Стандарты используются для достижения следующих целей:

- портируемость приложений - перенос приложений на различные аппаратные платформы, операционные системы, сетевые протоколы;

- интероперабельность - стандарты определяют общие форматы и интерфейсы взаимодействия программных систем;

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

- снижение риска выбора программного продукта - использование стандартов освобождает разработчика от привязанности к конкретному программному продукту;

- увеличение времени жизни системы - соответствие стандартам уменьшает риск быстрого устаревания системы.

Информатизация предприятия происходит неравномерно. Различные производства, цеха и участки оснащаются техническими средствами в разное время, поэтому неизбежно возникает разнородность (гетерогенность) используемых информационных систем, различие в операционных средах и технических средствах (аппаратное обеспечение). Методам построения РИУС, базирующихся на объектно-ориентированных моделях, посвящены работы Л. А. Калиниченко [36 - 41], В. П. Иванникова, К. В. Дышлевого [ 42 ] и многих других исследователей [43, 44 ].

В соответствии с [36] рассмотрим информационную и реализационную неоднородность РИУС, компонентами которых являются различные информационные ресурсы (ИР). Такими ИР являются исполняемые программы, базы данных и знаний, файловые системы, рассматриваемые независимо от аппаратно-программных платформ, их реализации и топологии их размещения в информационно-вычислительной сети.

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

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

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

Любая система после создания противодействует изменениям и имеет тенденцию быстрого превращения в бремя организации (так называемые legacy systems – унаследованные системы, использующие «уставшие» технологии, архитектуры, платформы, а также собственное программное и информационное обеспечение, при проектировании которых не были предусмотрены нужные меры по их пошаговой миграции в новые системы, соответствующие новым требованиям деловых процессов и технологии). Существенно, что в процессе миграции необходимо, чтобы мигрировавшие составляющие системы и оставшиеся компоненты унаследованных систем сохраняли интероперабельность.

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

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

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

Ведущей концепцией построения архитектуры РИУС к настоящему времени стала концепция промежуточного слоя (middleware), которая предполагает сосредоточение родовых служб в специальном слое архитектуры, расположенном между операционной системой и средствами управления компьютерными сетями и прикладными системами, специфическими для конкретных областей применения. К обсуждению основных направлений реализации этой концепции мы переходим в следующем параграфе.

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-объекта для обработки клиентских запросов. Активизация предполагает, что интересующий клиента объект имеет подходящий сервант. Создание серванта может входить в процесс активизации. В отличие от сервантов создание объектов не является предметом активизации и, чаще всего, осуществляется с помощью объектов-фабрик, которые относятся к Службе Жизненного Цикла.

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

Не нашли, что искали? Воспользуйтесь поиском по сайту: