Корпоративные информационные системы (КИС)

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

Надо отметить, что при работе со шлюзами данные других СУБД органически включаются в среду распределенных БД Oracle: реализуется полнофункциональная поддержка синхронной связи между серверами без тиражирования и даже некоторые варианты тиражирования данных.

10.2 Администрирование распределенных систем на примере Oracle

Немного поговорим о тех средствах, которые Oracle предлагает в помощь администратору распределенной информационной системы.

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

Полезность централизации хотя бы части административных функций очевидна. На рынке программных продуктов существует достаточно много средств, направленных на решение именно этой задачи. К примеру, есть системы, реализующие централизованную идентификацию пользователей. Для некоторых из них (Kerberos, Sesame) Oracle предоставляет интерфейсы, что позволяет ввести их функциональность в распределенную БД на базе Oracle.

Что касается средств централизованного управления, то их на рынке тоже достаточно много, и значительная часть из них в той или иной степени способны работать с СУБД Oracle. Однако в данной области находиться в полной зависимости от технологии третьих фирм чересчур рискованно для крупных поставщиков передовых программных технологий, таких как Oracle: слишком большое значение приобретает данный аспект системы, чтобы игнорировать его в собственных разработках.

В значительной степени задачу централизованного администрирования распределенной БД позволяет решить Oracle Enterprise Manager, поставляемый сейчас в комплекте с сервером БД. Этот программный продукт позволяет с помощью графического интерфейса управлять сколь угодно сложной конфигурацией распределенной БД, включая возможность определения удаленных заданий, выполняемых по заданному расписанию, извещения о различных событиях в системе и т. п.

Кроме этого, в состав программного продукта включен ряд утилит, выполняющих детальный мониторинг серверов БД, оптимизацию их параметров.

В их состав входит также Oracle Expert - экспертная система, позволяющая провести оптимизирующую настройку любого сервера.

Важно еще и то, что Oracle Enterprise Manager предоставляет открытый интерфейс, позволяющий дополнять управляющую консоль администратора новыми средствами как третьим фирмам, так и самим пользователям. Можно рассчитывать поэтому на то, что в самое ближайшее время большая часть существующих на рынке средств централизованного администрирования систем на основе Oracle объединится в интегрированную управляющую среду.

11. OMG и её стандарт CORBA

CORBA (Common Object Request Broker Architecture) - это стандарт, набор спецификаций для промежуточного программного обеспечения (ППО,middleware) объектного типа. Задача ППО, как известно, и заключается в связывании программных приложений для обмена данными. Эволюция ППО - это путь от программ передачи информации между конкретными приложениями, через средства импорта- экспорта данных и организацию мостов между некоторыми приложениями, через SQL, RPC (Remote Procedure Call), TP мониторы (Transaction Proceesing) обработки транзакций, Groupware - управление различными неструктурированными данными (тексты, факсы, письма электронной почты, календари и т.д.) и, наконец, MOM - Message-Oriented Middleware (асинхронный обмен сообщениями между сервером и клиентом), к созданию распределенных компьютерных систем. Элементы этих систем могут взаимодействовать друг с другом как на одной локальной машине, так и по сети. Уникальная полифоничность CORBA позволяет организовать единую информационную среду, элементы которой могут общаться друг с другом, вне зависимости от их конкретной реализации, "прописки" в распределенной системе, платформы и языка их реализации.

В стандарте CORBA звучат две основные темы:

Точка отсчета (развития). В отличие от стандартов MS COM/DCOM (Component Object Model / Distributed COM), которые были созданы для объединения мелких офисных программ, CORBА возник в ответ на необходимость интеграции промышленных приложений.

Объектность идеологии. CORBA - стандарт для объединения объектов.

Чтобы разобраться в объектно - ориентированной партитуре CORBA, отвлечемся на краткий курс объектной теории.

Классический объект - самостоятельная часть кода для компилятора. В общем случае неизвестен и недоступен вне данной программы.

Распределенный объект или компонент - объект, который может существовать независимо от данной программы, в том числе на сети. Это самостоятельная, отдельно скомпилированная часть кода.

Бизнес-объект - распределенный объект, выполняющий ту или иную бизнес-функцию, иначе говоря, законченную производственную, финансовую, административную, информационную операцию.

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

OMG сформулировала единый семантический стандарт для своих членов - Объектную Модель, в которую входит 4 основных понятия:

объекты, моделирующие окружающий мир (человек, лодка, документ);

операции, относящиеся к объекту и описывающие его особенности и специфику поведения (дата рождения для объекта "человек", материал, из которого сделана лодка);

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

подтипы, уточнения типов (лодка, максимальная скорость которой 10км/час).

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

Как показывает практика, постоянное совершенствование заложено в самом стиле, выработанном OMG для развития CORBA.

11.1 История создания OMG и стандарта CORBA

В 1989 г. несколько компаний, поставщиков и потребителей компьютерных технологий, устав от неразберихи в промышленных приложениях, образовали OMG. Цель новой некоммерческой организации звучала в лучших традициях философских утопий: "Объединить мир". Переходя от философии к реальной жизни, это означает: объединить, путем создания средств интеграции приложений, мир прикладных программ, с их комплексами и системами, прежде всего в области автоматизации различных отраслей промышленности.

В названии группы уже был скрыт ключ к решению поставленной задачи: OMG определяет Object Management (Объектное Управление) как создание программного обеспечения, которое через понятие объекта моделирует реальный мир. Объектная технология - великолепное средство разработки промежуточного ПО. Ее главное достоинство, способность расширять функциональность и добавлять новые компоненты в систему без изменения существующей структуры, позволяет легко строить гибкие, самоуправляемые, масштабируемые распределенные системы. С другой стороны, именно с развитием объектных методов возникла необходимость конструирования промежуточного ПО нового типа - не раз навсегда установленного моста между компонентами, а универсальной среды их взаимодействия.

OMG с самого начала объявила себя демократической организацией, а выработанные стандарты - бесплатными и открытыми для дополнений и изменений. Члены OMG разработали необыкновенно интересную процедуру создания новых стандартов, основанную на понятии Request For Proposal (RFP - запрос на разработку). RFP выпускается специальным комитетом OMG - Task Force и представляет собой адресованный членам OMG подробный запрос на развитие какого - либо конкретного стандарта. Task Force формирует запросы на основании информации, поступающей как от членов OMG, так и от независимых компаний и частных лиц. Запрос на RFP должен быть обоснован реальными потребностями существующих или разрабатываемых продуктов. Через 3 недели после публикации проекта нового RFP (это время дается членам ОMG на обдумывание задачи) происходит обсуждение запроса и определяется график выпуска нового стандарта. После создания новых спецификаций члены OMG голосуют за принятие нового стандарта и включение его в структуру CORBA. Обычно процесс разработки нового стандарта занимает около года. Сейчас актуальны, например:

RFP о компонентной модели CORBA - спецификации для интерфейсов и механизмов распределенной компонентной модели, основанной на CORBA, которые способны взаимодействовать с другими компонентными технологиями;

RFP о специальном языке сценариев для облегчения работы с компонентами CORBA;

RFP для управления документами медицинского страхования и бухгалтерских расчетов в медицине, передаваемыми по сети.

Очевидно, что при таком подходе темпы развития CORBA стремительно растут, ведь чем больше компаний используют CORBA совместимые продукты, тем больше выпускается RFP и тем быстрее развивается стандарт.

Сегодня в OMG входят более 800 компаний, среди которых: Acer, Cisco, HP, American Airlines, Hitachi, IBM, Siemens, Microsoft Sun, Sybase, Boeing, EDS, Ericsson, Netscape, Nokia, Ford Motor, Oracle и ряд других. Большинство крупных компаний, имеющих отношение к информационным технологиям, входят в OMG. Корпорация Microsoft долго не присоединялась к OMG - развивала собственный стандарт, COM/DCOM. Сегодня битва OMG - Microsoft на поле промежуточного ПО завершилась, наконец, мирными переговорами. Разработаны специальные средства, которые позволяют приложениям, поддерживающим один стандарт, взаимодействовать с приложениями из другого лагеря. DCOM присущи все недостатки стандарта, разрабатываемого одной компанией: он сконцентрирован на Windows и Microsoft не портируется на другие платформы; кроме того, DCOM проигрывает и по некоторым другим позициям.

OMG работает в тесном контакте с другими центрами стандартизации: ISO, Open Group (X/Open), WWW консорциум, ANSI, IEEE и многими другими. Как утверждает президент OMG Вильям Хоффман, в 1997 г. CORBA стал неотъемлемой частью жизни распределенных объектных компьютерных систем. Окончательная ли это победа? Будем осторожны. Ведь в данном случае говорить о полной интеграции приложений можно только если их "общение" столь же естественно, как телефонный разговор. До этого еще далеко.

Первый итоговый документ OMG был опубликован в 1991 г., это OMA (Оbject Management Architecture) Guide - путеводитель по архитектуре объектного управления, описывающий ядро CORBA. В 1992 г. вышел его переработанный вариант, а в 1994 г. появился CORBA 2.0. Именно с этого момента стало очевидно, что стандарт скорее жив, чем мертв и сейчас он в превосходной форме. Стандарт CORBA состоит из 4 основных частей:

Object Request Broker - брокер объектных запросов;

Object Services - объектные сервисы;

Common Facilities - общие средства;

Application и Domain Interfaces - прикладные и отраслевые интерфейсы.

11.2 Брокер (посредник) объектных запросов ORB (Object Request Broker)

Обобщенная Архитектура построения Брокеров Объектных Запросов разработана для поддержки интеграции самых разнообразных объектных систем. Спецификация CORBA устанавливает принципы создания Брокеров Объектных Запросов, которые и допускают такую интеграцию.

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

При определении конкретной архитектуры Брокер Объектных Запросов вовсе необязательно должен быть реализован как один компонент, но каждая реализация должна реализовывать три категории операций:

Операции, которые одинаковы для всех реализаций ORB-а.

Операции, специфичные для конкретного объектного типа.

Операции, специфичные для отдельных видов реализаций объектов.

Различные реализации ORB-а могут поддерживать различные виды реализаций, а различные адаптеры объектов могут обеспечивать различные наборы сервисов для клиента и реализаций.

Ядро Брокера Объектных Запросов обеспечивает основные механизмы для манипуляций объектами и выполнения запросов. Спецификация CORBA предназначается для поддержки различных механизмов реализации объектов, поэтому структура ядра не определяется. Вместо этого задается набор интерфейсных функций, которые должны присутствовать в каждой реализации ORB-а и тем самым маскируют отличия между различными реализациями Брокеров Объектных Запросов.

Объекты

Система объектов обеспечивает клиента набором сервисов. Клиент способен запросить некоторый сервис. Объект - это нечто, что обеспечивает один или более сервисов, которые клиент может запросить.

Пример Брокеров Объектных Запросов

Доступно широкое множество способов реализации конкретных ORB-ов. Далее будут приведены примеры таких реализаций. Следует иметь ввиду, что конкретный ORB может быть реализован сразу несколькими способами.

ORB, включаемый в клиентское и серверное приложение

Если имеется подходящий механизм коммуникаций, то возможна реализация ORB-а в виде набора подпрограмм как со стороны клиента, так и со стороны реализации объекта. Вызовы методов могут транслироваться в работу со средствами взаимодействия процессов (Inter Process Communication - IPC).

ORB, выполненный в виде сервера

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

ORB как часть системы

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

ORB, основанный на библиотеках

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

Реализации объектов

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

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

Адаптеры объектов

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

Сервисы, которые обеспечиваются ORB-ом посредством адаптеров объектов часто включают: генерацию и интерпретацию ссылок на объекты, вызов методов, активацию и деактивацию реализаций объектов, а также регистрацию конкретных реализаций и отображение объектных ссылок и реализаций.

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

Скелет реализации

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

Динамическая обработка запросов

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

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

Запросы

Клиент запрашивает сервисы инициированием запросов. Запрос - это событие, то есть действие, происходящее в конкретный момент. С запросом связана информация, состоящая из операции, объекта, у которого запрашивается сервис, нуля или более действительных параметров вызова и необязательный контекст запроса. Форма запроса - это описание или шаблон, который может быть выполнен произвольное количество раз. Форма запроса определяется отображением для конкретного языка программирования. Альтернативной формой запроса является использования Интерфейса Динамических Вызовов, который позволяет создать запрос, добавить аргументы и выполнить запрос. Под значением понимается допустимый параметр запроса. Значение которое определяет объект, называется ссылкой на объект, связанной с конкретным экземпляром объекта. Выполнение запроса вызывает выполнение соответствующего сервиса. После завершения запроса клиенту возвращается результат запроса (если он есть). В случае ненормального завершения запроса клиенту возвращается исключение. Исключение может содержать специфические параметры, специфические для данного типа исключений.

Параметры

Параметр характеризуется режимом передачи и своим типом. Режим определяет, должно ли передаваться значение параметра от клиента к серверу (in), от сервера к клиенту (out) или в обоих направлениях (inout).

Возвращаемое значение.

Если есть возвращаемое значение, то оно рассматривается как параметр типа out.

Исключения.

Исключение свидетельствует о том, что операция не была успешно выполнена. Исключение может содержать дополнительную информацию, специфичную для конкретного исключения.

Контекст.

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

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

Интерфейсы

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

Типу интерфейса удовлетворяют только объектные типы.

Интерфейс ORB-а

Интерфейс ORB-а является функциям, вызываемым непосредственно у Брокера Объектных Запросов и идентичным для всех ORB-ов, не зависящим от конкретного объекта либо адаптера объектов. Но так как большинство действий с объектами выполняется посредством адаптеров объектов, существует всего несколько общих операций, которые могут быть выполнены над каждым объектом. Эти операции могут вызываться как клиентом, так и реализацией объекта.

11.3 IDL (Interface Definition Language - язык определения интерфейсов)

Язык описания интерфейсов (IDL), используемый OMG определяет типы объектов посредством спецификации их интерфейсов. Интерфейс состоит из множества именованных операций и их параметров.

Язык описания интерфейсов рассматривается как средство, с помощью которого реализация объекта сообщает своим потенциальным клиентам о том, какие операции доступны и каким образом их следует вызывать. Можно оттранслировать описание на языке IDL в исходный код на конкретном языке программирования.

Отображение IDL в языки программирования

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

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

Типы данных

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

Объектным типом называется тип, членами которого являются объекты, удовлетворяющие данному типу.

Определены следующие основные (базовые) типы данных:

16 и 32 разрядные знаковые и беззнаковые целые типы;

32 и 64 разрядные типы с плавающей точкой в соответствии с IEEE;

Символьный тип в соответствии с ISO Latin-1 (8859.1);

Логический тип с множеством значений истина и ложь;

8 разрядный тип, который гарантированно не подвергается никаким изменениям при передаче между различными системами;

Перечислимые типы, состоящие из последовательности идентификаторов;

Строковый тип, состоящий из последовательности символов переменной длины, длина строки доступна во время выполнения программы;

Тип "any", который может принимать значения всех базовых и составных типов.

Также могут быть определены составные типы:

структура, состоящая из упорядоченных пар (имя, значение);

объединение, состоящее из дискриминатора и значения типа, связанного с дискриминатором;

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

массив фиксированной длины, элементами которого являются значения одного типа;

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

Параметры, представленные в запросе должны удовлетворять одному из перечисленных типов, за исключением типа интерфейс, как показано на рисунке 2-1.

Синтаксис Общего Представления Данных - CDR

CDR - это способ представления всех типов данных, определенных в OMG IDL в виде последовательности восьмиразрядных величин, далее называемых байтами.

Поток байт представляет из себя некоторую абстракцию обычно соответствующую буферу данных, который передается между процессами или машинами с помощью средств IPC или сетевого транспорта. Далее считается, что поток байт или просто поток - это последовательность переменной (но конечной) длины величин, состоящих из 8 бит (байт) с четко определенным заголовком. Байты в потоке нумеруются от 0 до n-1, где n - это длина потока. Индекс каждого байта используется для вычисления границ выравнивания, как это описано далее.

Протокол GIOP определяет два вида потоков - сообщение и инкапсуляция. Сообщение - это основная единица обмена информацией в протоколе GIOP. Инкапсуляция - это поток, внутри которого любая структура данных, имеющаяся в OMG IDL может быть декодирована независимо от остального контекста сообщения. Инкапсуляция позволяет осуществлять предварительное кодирование сложных типов данных (таких как TypeCode) или обрабатывать части сообщений без требования полного его декодирования.

Кодирование базовых типов

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

Для того, чтобы сделать возможным помещение и извлечение значений базовых типов в поток и из потока с помощью подпрограмм, предназначенных для работы именно с этими типами данных, все базовые типы данных при помещении в поток должны быть выровнены на свою естественную границу, то есть на число байт, которое нацело делится на число байт, необходимых для представления этого типа. Таким образом значение, имеющее размер n должно кодироваться с позиции m*n, где m - это целое число. В CDR n может принимать значения 1, 2, 4 или 8. Если необходимо, то выровненному значению предшествует область минимально возможного размера, необходимого для выравнивания. Значение байтов внутри этой области не определено.

Выравнивание определяется относительно начала потока. Первый байт в сообщении или инкапсуляции имеет индекс 0.

Кодирование составных типов

Выравнивание составных типов не налагает никаких дополнительных требований, кроме тех, которые применяются при кодировании их элементов.

Элементы структуры кодируются в том порядке, в котором они определены в описании на IDL. Каждый элемент кодируется образом, соответствующим его типу.

Объединение кодируется значением дискриминатора и членом объединения, соответствующим данному значению.

Массив кодируется как последовательность его элементов. Так как длина массива фиксирована, она не кодируется. Если массив имеет несколько измерений, то первый индекс изменяется наиболее медленно, а последний - наиболее быстро.

Последовательность элементов кодируется как величина типа unsigned long, за которым следуют элементы последовательности. Это значение определяет количество элементов. Каждый элемент кодируется в соответствии со своим типом.

Строка кодируется как величина типа unsigned long, содержащее длину строки, и отдельными символами - элементами строки. Длина строки и ее представление в виде списка символов включают завершающий нулевой символ, что дает возможность использования стандартных функций библиотеки языка C (например, strcpy) для декодирования сообщения.

Значение перечислимого типа кодируется в виде величины типа unsigned long, соответствующей данному значению. Первому в порядке перечисления в определении на IDL значению соответствует 0, второму - 1 и так далее.

Кодирование инкапсуляции

Первый байт инкапсуляции кодирует порядок байт внутри нее - значение типа 0 означает кодирования по принципу первым - старший байт, 1 - младший. Далее идут данные. Флаг порядка байт не включается в данные, но он включается в инкапсуляцию. Все значения внутри инкапсуляции выравниваются относительно ее начала, первый байт (с индексом 0) соответственно занимает флаг порядка байт. Если инкапсуляция кодируется как последовательность величин типа octet (байтов), то ей предшествует значение типа unsigned long, содержащее общий размер инкапсуляции. Никакого выравнивания для инкапсуляции не предполагается, но такой способ кодирования всегда гарантирует 4-байтное выравнивание для первого байта инкапсуляции.

Кодирование псевдообъектов

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

Операции

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

спецификации параметров, требуемых для выполнения операции

спецификации возвращаемого значения

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

спецификации дополнительной контекстной информации, которая может повлиять на выполнение запроса

индикации семантики, которую клиент должен учитывать при выполнении операции.

Хранилище описаний

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

11.4 Object Services - объектные сервисы

Само по себе ORB обеспечивает чистое взаимодействие объектов друг с другом, телефонные линии распределенной информационной среды. Сервисы, написанные на IDL, поставляют объектам дополнительные интерфейсы. Благодаря сервисам разработка прикладных программ упрощается едва ли не до уровня все той же игры с конструктором. В реальной системе не обязательно должны присутствовать все сервисы, их набор зависит от требуемой функциональности. На сегодня разработано всего 14 объектных сервисов:

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

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

Security, сервис безопасности, ограничивает права доступа в распределенной среде.

Transactions, сервис транзакций, при работе с базами данных обеспечивает подтверждение или "roll back" всех изменений, сделанных по ORB.

Trading, сервис коммерции, альтернатива сервису наименований. Вместо ссылки на нужный объект по имени дает возможность объекту-отправителю выбрать группу объектов заказанного типа.

Life Cycle, сервис функциональности разрешает создавать, копировать, перемещать и уничтожать компоненты по ORB.

Externalization, сервис импорта / экспорта - с его помощью внутренние (internal) параметры объекта сохраняются в текстовом файле, из которого затем можно скопировать или восстановить объект с теми же параметрами.

Licensing, сервис лицензирования, защищает от несанкционированного использования программных компонентов в распределенной среде.

Time, сервис времени - набор интерфейсов для установки текущего времени и операций с временными интервалами. Дает возможность оперировать с событиями во времени.

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

Relationships, сервис отношений, с его помощью можно связать два типа объектов через IDL определения.

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

Persistent Objects, сервис надежного хранения - для особо важных данных, которые надо хранить в защищенных структурах, таких как БД или специальные файловые системы. Интерфейсы сервиса могут выполняться, например, над реляционной базой данных, включенной в распределенную систему.

Query, сервис запросов, определяет тип простого набора данных и способы выполнения запросов (query) к объектам такого набора. Поддерживает большинство query языков и прежде всего SQL. Соответствует SQL3 спецификациям.

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

11.5 Common Facilities - общие средства

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

USER Interface - представление объектов и сложных документов. Сюда входят средства работы с подсказками, проверка правописания и грамматики, управление рабочим полем (desktop). Система OpenDoc (совместная разработка группы компаний, среди которых и IBM) может служить хорошим примером использования USER Interface.

Information management - моделирование информации, ее сохранение и восстановление, кодирование и перевод, поддержка времени и календаря. System management - управление ORB и CORBA приложениями. Для этой спецификации OMG использовала стандарт X/Open. Task management - контроль выполнения, отслеживание агентов.

Все перечисленные интерфейсы представляют собой горизонтальные средства, общие для всех доменов. Домен в лексике CORBA - отрасль промышленности. Это одно из ключевых понятий, ведь основная задача OMG - объединение именно промышленных приложений. Нетрудно заметить, что промышленные приложения сильно зависят от предмета, который призваны автоматизировать. Поэтому кроме общих горизонтальных средств выделились вертикальные общие средства по доменам. Сейчас они определены по следующим направлениям: телекоммуникация, финансы, производство, медицина, транспорт, электронная коммерция, бизнес-объекты. Этот список постоянно пополняется: выпускаются новые RFP, по ним разрабатываются новые стандарты, которые относятся к Object Services или Common Facilities, к Application или Domain Interfaces.

11.6 Достоинства CORBA

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

CORBA - сетевая архитектура по определению, эта идея лежит в основе его развития. Объектно-ориентированные интерфейсы CORBA легко определять, создавать и использовать.

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

CORBA хорошо сочетается с разнообразным промежуточным ПО, включая OLE языки (например, для реализации интерфейса можно использовать VisualBatch).

В рамках CORBA можно обеспечить необходимый уровень безопасности системы.

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

Существует протокол IIOP, который позволяет взаимодействовать различным ORB по TCP/IP. CORBA сервисы обеспечивают ряд дополнительных возможностей: транзакции, события, query и т. д. Одновременная поддержка статических и динамических интерфейсов. Возможность включения в распределенную среду Web-клиентов и серверов, в частности, через Java-реализации CORBA.

CORBA - широко используемый стандарт, со множеством реализаций, но создается и поддерживается он централизованно, OMG.

Так как CORBA - только стандарт, между его реализациями естественное возникает соревнование. Тем самым повышается качество продуктов, а их совместимость заложена в стандарте.

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

11.7 Обзор протоколов GIOP и IIOP

Спецификация протокола GIOP состоит из следующих элементов:

Определение Общего Представления Данных (Common Data Representation - CDR). CDR - это способ кодирования типов данных, определенных в IDL в низкоуровневое представление, пригодное для передачи их по имеющимся каналам связи между ORB-ами.

Формат сообщения протокола GIOP. Сообщения протокола GIOP обеспечивают нахождение объекта, отработку запросов, а также простейшее управление каналом коммуникации.

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

Спецификация IIOP добавляет к спецификации протокола GIOP следующий пункт:

Транспорт для сообщений протокола IIOP.

Спецификация IIOP описывает, каким образом агенты могут установить соединение по протоколу TCP/IP и использовать его для передачи сообщений протокола GIOP.

Протокол IIOP не является самостоятельной спецификацией - это специализированное отображение протокола GIOP поверх транспортного слоя TCP/IP. Спецификация GIOP (без элементов, специфичных для IIOP) может рассматриваться как самостоятельный документ, являющийся базовым для обеспечения в будущем отображения на новые транспортные протоколы.

Протокол обмена GIOP

За исключением редкого случая прямых вызовов методов между классами одного и того же языка программирования необходим механизм кодирования вызова метода в некоторую последовательность байт (byte stream) у клиента и декодирования этой последовательности у сервера. Для этой цели спецификация CORBA определяет Общий Протокол обмена между Брокерами Объектных Запросов (General Inter-Orb Protocol - GIOP). Кроме того, определен протокол передачи сообщений протокола GIOP поверх транспортного протокола TCP/IP, являющегося основным видом взаимодействия в Internet, ввиду чего этот протокол получил название Протокола обмена между Брокерами Объектных в Internet (Internet Inter-Orb Protocol - IIOP). Протокол IIOP должен поддерживаться всеми Брокерами Объектных Запросов независимо от особенностей их реализации, что является главным требованием для обеспечения взаимодействия между произвольными ORB-ами двух разных и совершенно независимых производителей.

Особенности и цели протокола

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

Распространенность

Протоколы GIOP и IIOP разрабатывались с учетом доступного широко распространенного и гибкого транспортного механизма (TCP/IP) и задает минимум дополнительных протоколов, необходимых для передачи запросов между отдельными ORB-ами.

Простота

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

Масштабируемость

Протокол GIOP/IIOP должен поддерживаться как отдельными ORB-ами, так и ORB-ами, объединенными в сеть на уровне Internet и, возможно, шире.

Небольшие затраты на реализацию

Реализация поддержки протоколов GIOP/IIOP должна потребовать минимальных затрат как в плане инженерного проектирования, так в плане распространения готовых ORB-ов.

Общность

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

Архитектурная независимость

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

Подход конкретного ORB-а к обеспечению поддержки протокола GIOP/IIOP не определен. Например, ORB может принять IIOP в качестве внутреннего протокола, использовать его только для внешнего обмена, используя для обмена в рамках самого ORB-а какие-то дополнительные средства коммуникации или выбрать нечто среднее между этими двумя крайностями. Все что требуется от ORB-а - это чтобы существовало нечто способное принимать и отправлять сообщения по протоколу IIOP.

Формат сообщений протокола GIOP

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

Значение, соответствующее типу сообщения	Тип сообщения	Кто может посылать сообщение
		Клиент	Сервер
0	Request	Да	-
1	Reply	-	Да
2	CancelRequest	Да	-
3	LocateRequest	Да	-
4	LocateReply	-	Да
5	CloseConnection	-	Да
6	MessageError	Да	Да

Заголовок сообщения однозначно определяет его тип. Заголовок определен таким образом, чтобы не зависеть от порядка байт в представлении базовых типов данных. Элементами заголовка являются:

Поле magic, которое состоит из четырех символов "GIOP", идентифицирующих все сообщения протокола GIOP.

Поле GIOP_version, которое состоит из двух полей major и minor, идентифицирующих старший и младший номера версии используемого протокола. Текущая спецификация определяет версию 1.0. Приложение должно поддерживать взаимодействие в рамках протокола только если номер, содержащийся в поле major равен, а в поле minor - больше или равен номерам версии, используемой при разработке приложения.

Поле byte_order. Значение 0 в этом поле определяет, что в сообщении принято кодирование данных с лидирующим наиболее значащим байтом, 1 - наименее значащим. В настоящее время подавляющее большинство процессоров, в том числе и серия Intel x86 используется представление с лидирующим наименее значащим байтом.

Поле message_type содержит значение от 0 до 6, определяющее тип сообщения.

Поле message_size содержит длину оставшейся части сообщения (0 если больше ничего нет).

За общим заголовком каждого сообщения в зависимости от его типа может идти заголовок и тело конкретного сообщения. Структура каждого заголовка специфична для каждого типа сообщения и представляет особенного интереса для рассмотрения.

Транспорт для протокола GIOP

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

Транспорт ориентируется на установление соединения с последующим обменом информации в рамках соединения. Соединение используется для определения правил нумерации запросов.

Транспорт протокол должен гарантировать прохождение переданных байт в том порядке, в котором они были посланы.

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

Транспорт должен обеспечивать сигнализацию об разрыве соединения. Если один из участников обмена неожиданно прервал свою работу, произошел сбой в операционной системе или сети, то другой должен быть уведомлен об этом.

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

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

Управление соединением

Соединение двунаправленное в смысле потока данных, но оно не является симметричным в плане обмена сообщениями GIOP. Сообщения Request, LocateRequest и CancelRequest могут посылаться только клиентом. Сообщения Reply, LocateReply и CloseConnection - только сервером. Сообщение ErrorMessage может быть послано обеими сторонами. Через соединение для обмена в соответствии с протоколом GIOP могут посылаться только сообщения GIOP.

Каждое сообщение типа Request должно иметь уникальный номер, который идентифицирует запрос в рамках установленного соединения. Этот номер никоим образом не интерпретируется сервером, но он позволяет клиенту установить соответствие между запросом и пришедшим ответным сообщением в случае инициации сразу нескольких запросов. Генерация этих уникальных номеров возлагается на клиента.

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

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

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

11.8 Безопасность в CORBA

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

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

Как обеспечить оптимальное сочетание универсальности решения с его гибкостью, эффективностью и надежностью?

Как обеспечить возможность (и простоту) использования в универсальной системе обеспечения безопасности уже хорошо зарекомендовавших себя различных технологических решений и подходов?

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

Как организовать относительно простое и удобное управление безопасностью для менеджеров информационных систем?

Как обеспечить взаимодействие подсистем с различными уровнями обеспечения безопасности?

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

Как предложить разработчикам универсальное и эффективное решение по доступной цене?

Система обеспечения безопасности в CORBA (CORBA Security Service) должна была дать ответы на эти и многие другие вопросы. Она разрабатывалась долго, примерно в течение двух лет, и первая версия была принята в самом конце 1995 года. В ее разработке принимали участие специалисты из AT&T, DEC, Expersoft, Hewlett-Packard, IBM, Novell, Siemens, Sunsoft, Tivoli Systems и других компаний. В настоящий момент последней утвержденной является версия 1.8 (принята в марте 2002 года). Номер версии говорит о том, что с момента появления в сервис не вносилось кардинальных изменений, хотя появление новых спецификаций сервисов CORBA требовало учета новых реалий и разработки улучшенных версий Security Service.

...