- •Государственный комитет рф по высшему образованию
- •0. Введение.
- •0.1. Идея общей интеграции.
- •0.2. Взаимодействие на уровне процедур.
- •0.3. Распределенные объекты.
- •0.4. Почему corba.
- •1. Поддержка на различных платформах.
- •2. Устойчивость стандарта.
- •3. Сложность освоения.
- •4. Поддержка повторного использования кода.
- •1. Постановка задачи.
- •1.1. Классические объекты.
- •1.2. Распределенные объекты в терминах спецификации corba.
- •1.3. Требования, предъявляемые к orb-у.
- •2. СпецификацияCorba.
- •2.1. Объектная модель.
- •2.2. Обзор архитектурыCorba.
- •2.3. Пример Брокеров Объектных Запросов.
- •3. Структура системы.
- •3.1. Уточнение деталей реализации.
- •3.2. Структура ядра системы.
- •3.3. Структура библиотеки.
- •3.4.Структура подсистемы обработки запросов.
- •3.5. Входные и выходные данные.
- •4. Протокол обменаGiop.
- •4.1. Особенности и цели протокола.
- •4.2. Обзор протоколаGiop.
- •4.3. Синтаксис Общего Представления Данных -cdr.
- •4.4. Формат сообщений протокола giop.
- •4.5. Транспорт для протоколаGiop.
- •4.6. Реализация взаимодействия по протоколуGiop.
- •4.7. Поддержка протоколаGiop в рамках отображения дляObject Pascal.
- •5. Разработка отображения для языкаObject Pascal.
- •5.1. Множественное наследование.
- •5.2. Статические экземпляры классов.
- •Initialization
- •Initialization
- •6. Технология написания и отладки приложений, работающих с распределенными объектами.
- •6.1. Этапы разработки программы.
- •6.2. Технология написания сервера объекта.
- •6.3. Технология написания клиента объекта.
- •6.4. Отладочные возможности библиотеки.
- •7. Пример программы, работающей с распределенными объектами.
- •7.1. Последовательность действий при создании объекта.
- •7.2. Объект библиотека.
- •7.3. Сервер объекта.
- •7.3. Клиент объекта.
- •7.4. Окончательный результат.
- •8. Анализ конкурентоспособности программного продукта.
- •8.1. Введение.
- •8.2. Ситуация на рынке.
- •8.3. Программные продукты - конкуренты.
- •8.4. Основные понятия.
- •8.5. Параметры для оценки эффективности.
- •8.6. Расчет эффективности.
- •8.7. Цена.
- •8.8. Конкурентоспособность.
- •8.9. Выводы и прогнозы.
- •9. Вопросы эргономики и их решение для создания комфортных условий труда программистов.
- •9.1. Введение.
- •9.2. Рабочее место программиста.
- •9.3. Вредные факторы, присутствующие на рабочем месте и их классификация.
- •9.4. Вредные производственные воздействия.
- •9.5. Эргономические требования.
- •9.6. Эргономика окружающей среды.
- •9.7. Экологическая безопасность.
- •9.8. Выводы.
2.2. Обзор архитектурыCorba.
Обобщенная Архитектура построения Брокеров Объектных Запросов разработана для поддержки интеграции самых разнообразных объектных систем. СпецификацияCORBA устанавливает принципы создания Брокеров Объектных Запросов, которые и допускают такую интеграцию. На рисунке 2-2 приведена общая схема выполнения запроса посредствомORB-а.
Рисунок 2-2. Схема выполнения запроса.
Запрос посылается от клиента к серверу. Клиентэто приложение, или нечто другое, выполняющее операцию над объектом, ареализация объекта- это код и данные, которые на самом деле выполняют эту операцию.ORB способен выполнить все действия, необходимые для нахождения реализация указанного объекта, подготовке этой реализации к обработке запроса и передаче данных, относящихся к запросу. Интерфейс, предоставляемый клиенту абсолютно не зависит от местоположения реализации объекта, языка программирования, на котором он написан или каких-либо других аспектов, не влияющих на определение интерфейса для данного объекта. Более подробно схема Брокера Объектных Запросов показана на рисунке2-3.
Для выполнения запроса клиент может использовать Интерфейс Динамического Выполнения запросов или объект-заглушку, созданный по описанию интерфейса и специфичный для данного объекта. Также клиент может напрямую работать с некоторыми функциями ORB-а.
Реализация объекта получает вызов через механизм обратных вызовов из сгенерированного статического скелета, либо обработчика динамических запросов. При выполнении запроса, и вообще в произвольное время реализация объекта может делать вызовы к Адаптеру Объектов либо Брокеру Объектных Запросов.
Рисунок 2-3. Структура Брокера Объектных Запросов.
Брокер Объектных Запросов хранит информацию о доступных объектах, доступных операциях, их параметрах в хранилище описаний (интерфейсов) объектов. Информация, относящаяся к местоположению, типу и прочая информации, связанная с реализацией объектов, находится в хранилище информации о реализациях объектов. На самом деле эти два хранилища могут быть хранить информацию в одном месте. Хранилище описаний объектов заполняется автоматически на основании описания интерфейса, сделанного на языке IDL, либо программным образом вызовом соответствующих функций. Хранилище информации о реализации объекта заполняется при инсталляции данной реализации.
Рисунок 2-4 показывает, каким образом информация, находящаяся в обоих хранилищах становится доступна клиенту и реализации объекта. Интерфейс должен быть либо определен в хранилище описаний, либо иметь соответствующееIDL-описание, на основании этого описания компилятор создает исходный код для объекта-заглушки, находящегося у клиента и для скелета реализации объекта.
Информация, которая находится в каждом из хранилищ может быть произвольно изменена в любой момент времени с помощью методов, обеспечиваемых реализацией ORB-а. Однако, неосторожное изменение, сделанное во время работы может привести нарушить целостность информации, находящейся в каждом из хранилищ и сделать невозможным дальнейшее функционированиеORB-а.
Рисунок 2-4. Взаимодействие хранилищ, клиента и реализации.
Брокер Объектных Запросов.
При определении конкретной архитектуры Брокер Объектных Запросов вовсе необязательно должен быть реализован как один компонент, но каждая реализация должна реализовывать три категории операций:
Операции, которые одинаковы для всех реализаций ORB-а.
Операции, специфичные для конкретного объектного типа.
Операции, специфичные для отдельных видов реализаций объектов.
Различные реализации ORB-а могут поддерживать различные виды реализаций, а различные адаптеры объектов могут обеспечивать различные наборы сервисов для клиента и реализаций.
Ядро Брокера Объектных Запросов обеспечивает основные механизмы для манипуляций объектами и выполнения запросов. Спецификация CORBA предназначается для поддержки различных механизмов реализации объектов, поэтому структура ядра не определяется. Вместо этого задается набор интерфейсных функций, которые должны присутствовать в каждой реализацииORB-а и тем самым маскируют отличия между различными реализациями Брокеров Объектных Запросов.
Клиенты.
Клиент имеет доступ к ссылке на объект и могут выполнить некоторые операции на объектом, ссылку на который они имеют. Клиент знает только логическую структуру объекта, соответствующую его интерфейсу. Хотя далее везде под клиентом будет пониматься процесс, инициирующий вызов для какого-то объекта, важно понимать, что определение клиент справедливо только относительно конкретного объекта. Например, реализация одного объекта может быть клиентом других объектов.
Вообще говоря, клиенты имеют доступ к операциям ORB-а через отображение для соответствующего языка программирования, что переносит понятиеORB-а непосредственно на уровень программирования внутри конкретного языка. Клиент должен быть максимально переносимым и должен функционировать под управлением произвольногоORB-а, поддерживающего соответствующее отображения без изменения исходного текста программы. Клиенты ничего не знают о реализации объекта, какой Брокер Объектных Запросов используется для доступа к этому объекту или какой Адаптер Объекта используется реализацией.
Реализации объектов.
Реализация объекта обеспечивает само понятие объекта, обычно задавая данные для конкретного экземпляра объекта и код для выполнения методов объекта. Часто реализация будет использовать другие объекты или вспомогательные программы для обеспечения функционирования объектов. В некоторых случаях выполнение операции над объектом влечет некие побочные действия не над объектами.
Конкретный ORBможет поддерживать широкий набор объектных реализаций: отдельные серверы, библиотеки, объектно-ориентированные системы управления базами данных и др. С помощью использования дополнительных Адаптеров Объектов теоретически можно поддерживать любую реализацию объекта.
Ссылки на объект.
Ссылка на объект требуется для указания ее в запросе. Оба, клиент и сервер имеют тип ссылки на объект и, таким образом, они изолируются от настоящего представления объектов. Две реализации ORB-а могут использовать различное представления для ссылок на объект.
Представление ссылки на объект используется клиентом и действительно только в течение времени жизни клиента.
Все реализации ORB-ов должны обеспечить представление ссылки на объект (обычно ссылаемый какObject)для данного языка программирования. Это допускает перенос программ между различными реализациямиORB-ов на уровне исходных текстов. Отображение для конкретного языка программирования может обеспечить дополнительные функции для работы со ссылками на объект.
Существует одна ссылка, которая гарантированно отличается от любой другой ссылки, ссылающейся на определенный объект.
Язык описания интерфейсов.
Язык описания интерфейсов (IDL), используемыйOMG определяет типы объектов посредством спецификации их интерфейсов. Интерфейс состоит из множества именованных операций и их параметров. Хотя и описание наIDL обеспечиваетORB всей необходимой информацией о типе объекта, для работы вовсе необязательно, чтобыORB-у был доступен исходный текст этих описаний. Эта же информация может быть заложена также в виде заглушек со стороны клиента и скелета со стороны сервера, а также в динамически изменяемом хранилище описаний, что позволитORB-у нормально функционировать.
Язык описания интерфейсов рассматривается как средство, с помощью которого реализация объекта сообщает своим потенциальным клиентам о том, какие операции доступны и каким образом их следует вызывать. Можно оттранслировать описание на языке IDL в исходный код на конкретном языке программирования.
Отображение IDL в языки программирования.
Различные объектно-ориентированные или объектно-неориентированные языки программирования могут получать доступ к объектам различным образом. Для объектно-ориентированных языков допускается отображение объектов, доступных ORB-у в объекты в смысле этих языков программирования. Даже для объектно-неориентированных языков декорирование настоящего представления ссылок на объекты будет полезным. Конкретное отображениеIDL для языка программирования должно быть идентичным для всех реализацийORB-ов. Отображение для языка программирования включает в себя определение специфичных для языка программирования типов данных и описания процедур доступа к объектам посредствомORB-а. Оно также включает в себя интерфейс для доступа клиента к заглушке, что может не требоваться для объектно-ориентированных языков, интерфейс динамических вызовов, скелет реализации, описание адаптеров объектов и прямой интерфейс кORB-у.
Отображение для языка также определяет порядок взаимодействия между вызовом метода и потоками (тредами - threads) как со стороны клиента, так и со стороны реализации. Обычно обеспечивается синхронный вызов, в котором подпрограмма вызова возвращает управление при завершении выполнения запроса. Допускается определение дополнительных средств, для определения порядка передачи управления и синхронизации клиентского кода с вызовом метода объекта.
Клиентская часть - заглушки.
Для объектно-неориентированных языков программирования задается программный интерфейс для доступа к методам объекта-заглушки, имеющегося у клиента. Эта заглушка осуществляет передачу запроса и обычно оптимизирована для выполнения под управлением конкретного ORB-а. Если доступно более одногоORB-а, то у них может быть различное внутреннее представление заглушек.
Объектно-ориентированные языки программирования, такие как C++ иSmalltalk такого интерфейса не требуют.
Интерфейс динамического выполнения вызовов.
Этот интерфейс допускает динамическое создание запросов к объекту вместо вызова процедуры, декорирующей такое создание. При динамическом создании запроса клиент должен указать всю информацию. Необходимую выполнения операции. Например, информация о типах параметров может быть получена с помощью хранилища описаний объектов.
Скелет реализации.
Для конкретного отображения и, возможно, используемого адаптера объектов определяется свой порядок вызова методов каждого объекта. Этот интерфейс в общем случае является интерфейсов обратных вызовов. При необходимости ORB вызывает требуемые процедуры.
Динамическая обработка запросов.
Также доступен интерфейс для динамической обработки поступающих запросов. В этом случае реализация объекта взаимодействует с заданным интерфейсом по аналогии с интерфейсом динамических вызовов.
Подпрограммы динамической отработки запросов могут вызываться как с помощью интерфейса динамических вызовов, так и с помощью процедур-заглушек, каждый метод дает одинаковый результат.
Адаптеры объектов.
Адаптер объектов - это первичный путь для обеспечения сервиса конкретной реализацией объекта. Предполагается, что имеется несколько адаптеров объектов, каждый из которых обеспечивает доступ к объектам определенного вида.
Сервисы, которые обеспечиваются ORB-ом посредством адаптеров объектов часто включают: генерацию и интерпретацию ссылок на объекты, вызов методов, активацию и деактивацию реализаций объектов, а также регистрацию конкретных реализаций и отображение объектных ссылок и реализаций.
Интерфейс ORB-а.
Интерфейс ORB-а является функциям, вызываемым непосредственно у Брокера Объектных Запросов и идентичным для всехORB-ов, не зависящим от конкретного объекта либо адаптера объектов. Но так как большинство действий с объектами выполняется посредством адаптеров объектов, существует всего несколько общих операций, которые могут быть выполнены над каждым объектом. Эти операции могут вызываться как клиентом, так и реализацией объекта.
Хранилище описаний.
Хранилище описаний представляет из себя сервис, который обеспечивается постоянным объектом, доступном из программы. Во время выполнения программы он дает доступ к информации, аналогичной той, что сохраняется в IDL описании объекта. Эта информация может быть использована для выполнения запроса - таким образом программа, которая не предусматривала использование объекта какого-либо типа, определить доступные у этого типа методы, типы его параметров и осуществить вызов.
Хранилище информации о реализациях объектов.
Хранилище информации о реализациях объектов содержит информацию, позволяющую ORB-у обнаружить местоположение и активизировать реализацию объекта. Хотя большинство информации специфично для конкретной среды выполнения, хранилище информации о реализациях объектов является местом для хранения такого рода информации.