Симфония CORBA

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

Сольфеджио

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

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

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

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

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

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

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

Как показывает практика, постоянное совершенствование заложено в самом стиле, выработанном 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. Именно с этого момента стало очевидно, что стандарт скорее жив, чем мертв и сейчас он в превосходной форме. Cимфония CORBA состоит из 4 основных частей:

• Object Request Broker - посредник объектных запросов;
• Object Services - объектные сервисы;
• Common Facilities - общие средства;
• Application и Domain Interfaces - прикладные и отраслевые интерфейсы.

Итак OMG - дирижер уже взмахнул палочкой.

"Анданте кантабиле". ORB (Object Request Broker)

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

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

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

- компонент сам по себе не является приложением;

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

- компонент не зависит от адресного пространства, сетевого протокола, алгоритмических языков, операционных систем, средств программирования;

- компонент имеет хорошо развитый интерфейс.

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

ORB - средство сборки промежуточного ПО из компонентов заказ

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

OMG разработала специальный язык верхнего уровня для описания ORB и других компонент CORBA-стандарта - IDL (Interface Definition Language - язык определения интерфейсов). Этот необычный язык не содержит присваиваний, операторов if или while, функций и логических переходов. IDL - это только описания, декларация, пассивные определения атрибутов, родительских классов, типов поддерживаемых событий, методов, включая входные и выходные данные, основные и составные типы данных, исключительные ситуации для обработки ошибок. IDL описывает интерфейсы - то же, что классы в С++ или в Smalltalk, интерфейсы в Java, пакеты в Ada95. Каждый интерфейс определяет операции, которые могут быть вызваны клиентами, но не то как эти операции выполняются вне IDL и CORBA. Синтаксически IDL является подмножеством С++ с дополнительными ключевыми словами для поддержки концепции распределенности. Существуют компиляторы IDL в С++, Java, Ada, Smalltalk, COBOL, OLE (VisualBasic, PowerBuilder и Delphi).

Одна из задач OMG - IDL-изация всех клиент-серверных приложений, что даст им возможность свободно взаимодействовать через ORB, который поддерживает динамические и статические интерфейсы. Первый определяется на стадии разработки приложения и компилируется вместе с ним, второй конструируется "на лету", на работающем приложении. Еще одно "интерфейсное" определение CORBA - "стандарт для промежуточного ПО, которое поддерживает как статические так и динамические методы вызова". На рис. 1 приведены клиентская и серверная части ORB.

(1x1)

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

Server IDL Stub или Static Skeleton аналогично Client IDL Stub связывает ORB и серверные приложения. Создается после компиляции IDL. Dynamic Invocation Interface, интерфейс динамического вызова, позволяет объекту создавать запрос в реальном времени. Структура запроса, его параметры и атрибуты и даже сама ссылка на объект-адресат генерируются в DII (Dynamic Invocation Interface) либо на основе данных, полученных из Interface Repository, либо на основе пробного, недетализированного запроса к объекту и анализу отклика.

Dynamic Skeleton Interface - серверный аналог DII. Он позволяет ORB доставлять на объект-сервер запрос, который не был заранее известен серверному приложению. ORB Interface - логический интерфейс, выполняющий вспомогательные функции, такие как конвертирование ссылок на объект-сервер в строковую переменную и наоборот, создание списка аргументов для запросов, сделанных через динамический интерфейс, и т.д. Object Adapter отвечает за доставку запросов объекту-серверу и, если надо, его активизацию.

Interface Repository - база данных реального времени всех зарегистрированных интерфейсов, методов, которые они поддерживают и их параметров, в терминах CORBA называемых росписью метода. Все данные IR доступны для компонентов и могут ими динамически изменяться.

Implementation Repository - собрание информации о серверах и способах их активизации

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

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

• IDL - язык определения интерфейса;
• Компилятор IDL,написанный на одном или нескольких языках (С++, Java, ADA, Smalltalk, COBOL, VisualBasic);
• Поддержка интерфейсов в реальном времени;
• Interface Repository - библиотека реального времени.

Физические реализации ORB обычно состоят из двух типов элементов: набор библиотек, которые компонуются с клиентским и серверным кодом и демоны - процессы, устанавливающие связи между клиентами, серверами и другими ORB. Многие компьютерные фирмы в рамках стандарта CORBA создали свои реализации ORB: Orbix (IONA) [3], Visigenic (VisiBroker), SOM (IBM), ORB Plus (HP), ObjectBroker (DEC), PowerBroker (Expersoft) и NEO/Joe (SUN).

В информационной метасреде, к которой стремится OMG, необходимо научить ORB различных изготовителей "понимать друг друга". CORBA 2.0 обеспечила стандарт взаимодействия посредников между собой, протокол GIOP - General Inter-ORB Protocol (Общий протокол взаимодействия ORB). GIOP определяет формат сообщений и шаблоны общих данных для взаимодействия через ORB. Этот протокол может выполняться поверх практически любого транспортного протокола. GIOP поверх TCP/IP получил название IIOP - Internet Inter ORB Protocol. Он был разработан OMG в 1996 г., а в 1997 г. появилась его версия с возможностями авторизации и шифрования.

Теперь от базиса перейдем к надстройке, от ORB - к сервисам.

Аллегро модерато. Object Services - объектные сервисы

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

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

"Анданте престо". 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.

"Скерцо". Прикладные и отраслевые интерфейсы

Эта часть стандарта CORBA предназначена для избранных, для любителей экзотических блюд, какофонии в музыке и абстрактной живописи. Сюда попали стандарты, специфичные для какого-нибудь одного приложения (Application Interface) или достаточно узкой области деятельности в отдельном домене (Domain Interface). Например, сюда включен PDM - Project Data Management, но у него есть все основания быть произведенным в вертикальные - Common Facilities.

"Финал грандиозо". Достоинства CORBA

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

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

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

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

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

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

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

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

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

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

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

На этом мы завершаем краткий обзор симфонии CORBA. Ей же предстоит еще звучать и звучать.

Литература

Объектные сервисы

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 спецификациям.