История создания 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. Обычно процесс разработки нового стандарта занимает около года. Сейчас актуальны, например:

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

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

3.     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 основных частей:

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

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

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

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

CORBA (Common Object Request Broker Architecture- общая архитектура брокера объектных запросов) - это стандарт, набор спецификаций для промежуточного программного обеспечения объектного типа. Имеется несколько реализаций CORBA, наиболее широко используются - SOM и DSOM фирмы IBM. CORBA также как составная часть в платформу ONE (Open Network Environment) фирмы Netscape. Две конкурирующих модели - COM и DCOM фирмы Microsoft и RMI фирмы Sun Microsystems.

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

Идентификатор объекта (object ID) – уникальное имя объекта внутри его объектного адаптера. Он представляет собой последовательность байт, которая ассоциируется с объектом в момент его создания. Обеспечивается либо программным приложением, либо РОА. Идентификатор объекта не обязан быть уникальным во всем остальном мире и даже для сервера. Там объект известен под своей объектной ссылкой (object reference). Как правило, идентификатор объекта является частью объектной ссылки. Клиент при обращении к целевому объекту не позволяет себе фамильярничать и называть его по идентификатору, он уважительно именует объект полной объектной ссылкой (по имени-отчеству). Есть еще объектный ключ (тоже часть объектной ссылки), который используется GIOP (General Inter-ORB Protocol), протоколом взаимодействия брокеров объектных запросов, для идентификации конечной точки связи. Объектный ключ уникален именно в этом смысле.

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

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

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

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

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

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

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

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

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

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