Продолжается подписка на наши издания! Вы не забыли подписаться?

CORBA Component Model**

Александр Цимбал

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

Все это привело к тому, что реальные системы стали создавать с использованием Java-технологий, и в первую очередь – с использованием серверной компонентной модели Enterprise JavaBeans (EJB). Возможно, именно ее наличие в значительной степени замедлило работы по созданию собственной компонентной модели CORBA. Дело в том, что многие реализации J2EE вообще, и EJB, в частности, самым тесным образом связаны с CORBA – в них используется протокол CORBA IIOP и Сервис Транзакций CORBA OTS (его Java-аналог называется JTS). Вообще, согласно спецификации, компонент EJB является, помимо всего прочего, CORBA-объектом. Использование EJB позволило Java-программистам избежать всех упомянутых выше проблем, возникающих при создании сложных серверных приложений.

Возникает вопрос: а нужна ли вообще компонентная модель CORBA, если у программистов есть J2EE и .NET?

Наличие сомнений по этому поводу в компьютерной индустрии очевидно – иначе и спецификация, и реализации появились бы значительно раньше. Правда, эти сомнения связаны с соображениями экономического, а не технического, плана. Компонентная модель CORBA по определению должны быть мощной и универсальной (она таковой на самом деле и является), и, следовательно, требует больших усилий для создания ее качественной реализации. Но с технической точки зрения необходимость создания такой модели очевидна – вследствие бросающихся в глаза ограничений и недостатков, присущих EJB и компонентам .NET.

С компонентами .NET все ясно – их возможности довольно ограничены (они не имеют состояния), кроме того, они в основном рассчитаны на Windows. До тех пор, пока для больших систем широко используются серверы и операционные системы, не относящиеся к платформе Wintel, говорить об универсальности .NET просто не приходится.

Компонентная модель EJB также не свободна от существенных ограничений. Основных ограничений, пожалуй, два: ориентация на язык Java (хотя есть возможности это ограничение обойти) и специфический стиль большинства Java-спецификаций, а именно: большое количество важных вопросов оставляется на усмотрение разработчиков. Традиционный девиз "Написано однажды – работает везде" применительно к Java-технологиям создания распределенных систем нужно воспринимать не совсем буквально. Кроме того, Java не является языком программирования, идеально подходящим для создания любых программ – в конце концов, большая часть приложений до сих пор создается на C++, не говоря уже о "доле" таких языков, как ADA, COBOL, Pascal и др.

Следует также иметь в виду еще одно обстоятельство. OMG создала новую архитектуру (точнее, метаархитектуру) программных комплексов – Model-Driven Architecture (MDA). Суть ее заключается в том, что проектирования программного комплекса выполняется на уровне абстрактных моделей. Этот подход можно трактовать, как качественно новый этап развития использования CASE-инструментов. На базе таких моделей автоматически могут быть сгенерированы различные компонентные решения более низкого уровня – например, стандартов CORBA, J2EE, .NET или любых иных. Наложение ограничений использования только Java или только определенных версий Windows не выглядит ни естественно, ни оправданно.

Итак, CORBA, очевидно, нуждалась (и нуждается) в собственной компонентной модели. Сейчас такая модель, наконец, появилась, и в этой статье мы начнем с ней знакомиться.

Изменения, связанные с введением CCM

Создание CCM потребовало внесения многочисленных изменений в стандарт CORBA 2. В первую очередь, серьезной модификации подвергся сам язык IDL – в него были добавлены конструкции, позволяющие описать компоненты и связанные с ними новые элементы – в первую очередь, фабрики и хранилища. В формальное описание синтаксиса IDL к 111 ранее существовавшим правилам добавлено еще 27, связанных с определением компонентов. Появились такие новые служебные слова, как component, supports, provides, uses, emits, publishes, consumes, manages, home, primarykey, finder, eventtype. Кроме того, введено расширенное толкование служебных слов «custom», «abstract» и «factory».

Но изменения в IDL – только первый шаг...

. . .
Все эти вопросы кратко будут рассмотрены в данной статье.

Компонентная модель EJB

Наличие этого раздела в данной статье может показаться странным. Тем не менее, автор решил начать именно с очень краткого рассмотрения EJB (читатель, который знаком с этой темой, может этот раздел просто пропустить).

Причина очень проста – компонентная модель CORBA, во-первых, создавалась как расширение и обобщение компонентной модели EJB, а, во-вторых, она (т.е. CCM) довольно сложна для понимания читателя, который с компонентными моделями не знаком. Так как EJB-модель проста – намного проще CCM – то знакомство с ней позволит гораздо быстрее понять архитектуру CCM.

Начнем с того, что же такое «компонент EJB». Некоторая сложность состоит в том, что используемый в спецификации термин "компонент" (bean) имеет различные значения, смысл которых очевиден в том или ином контексте для опытных EJB-разработчиков. Тем не менее, такая двойственность может сбить с толку программиста, который только начинает знакомиться с технологией EJB. Вследствие этого, автор взял на себя смелость ввести систему своих терминов, несколько отличающихся от тех, которые используются в спецификации – просто для ясности.

. . .

Компонент CORBA

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

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

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

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

Важным отличием компонентов CORBA от EJB-компонентов является расширенная модель поддержки многопоточности...

 

Виды компонентов CORBA

По совокупности характеристик как компонентов CORBA, так и их контейнеров, все компоненты можно разбить на четыре группы (категории). Для формального определения категорий компонентов в спецификации используются такие понятия, как "external API types" – т.е. набор интерфейсов, доступных клиенту компонента, "container API types" – API, используемый разработчиком компонента, и "модель использования CORBA" (CORBA usage model), которая определяет взаимодействие между контейнером и другими элементами CORBA, такими, как POA, ORB и сервисами CORBA. Об этом нужно сказать несколько слов.

Типы внешнего API (external API types) определяются с помощью IDL и в большинстве случаев представляют собой обычные интерфейсы CORBA. Они определяют, каким образом клиент использует функциональность, предусмотренную разработчиком компонента. Здесь можно выделить две группы типов: home-интерфейсы и application-интерфейсы. Очевидна аналогия с home- и component-интерфейсами в EJB.

Типы контейнерного API (container API types) – это совокупность локальных интерфейсов, а также способ определить взаимодействие компонента и его контейнера. Один из возможных типов контейнерного API выбирается с помощью объявлений языка CIDL – языка описания реализаций компонентов. Спецификация оговаривает два основных таких типа – session-тип (основанный на использовании временных, transient, объектных ссылок) и entity-тип – с использованием долговременных (persistent) объектных ссылок. Названия типов совпадают с названиями видов EJB-компонентов, конечно же, не случайно, хотя аналогия здесь далеко не такая прямая, как в предыдущем случае.

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

. . .

Элементы компонентов

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

IDL для объявления компонентов

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

“component” <identifier> [<supported_interface_spec>]
“{“ {<attr_dcl> “;”}* “}” 

, т.е. нужно указать имя компонента, список "поддерживаемых" им интерфейсов и список атрибутов компонента, например:

exception MyException {};

interface ChangeByOne 
{
  void increment ();
  void decrement ();
};
component MyComponent supports ChangeByOne 
{
  attribute int myValue raises (MyException);
};

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

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

interface MyFacetInterface 
{
  void myMethod ();
};
interface MyReceptacleInterface;

component MyDerivedComponent : MyComponent 
    supports MyInterface 
{
  attribute string myAttribute;
  provides MyFasetInterface facetOne;
  uses  MyReceptacleInterface receptacleOne;
};

Интерфейс CCMObject и наследование интерфейсов

Интерфейсы, поддерживаемые компонентом, который не является производным от другого компонента, всегда имеют один или несколько базовых интерфейсов, в том числе – обязательно интерфейс Components::CCMObject. Наследование этого интерфейса выполняется неявно. В свою очередь, этот интерфейс наследует три стандартных интерфейса...

. . .

Заключение

Компонентная модель CORBA – простой в использовании (но не в реализации!) и очень мощный инструмент создания распределенных систем. Ее наличие позволит обеспечить взаимодействие CORBA с архитектурой MDA, а также создавать универсальные, многоязыковые и многоплатформенные серверы приложений, преодолевая тем самым ограничения как J2EE (ориентированность на Java), так и .NET (реальная одноплатформенность). Впрочем, говорить об этом можно не раньше, чем появятся промышленные полномасштабные реализации этой компонентной модели. Первые шаги в этом направлении уже сделаны.

** Прочитать статью полностью вы можете в печатной версии журнала

Copyright © 1994-2016 ООО "К-Пресс"