Технология Клиент-Сервер 2003'1 |
|||||||
|
Отсутствие собственной компонентной модели в CORBA (точнее, задержка с ее принятием и реализацией), вне всякого сомнения, послужило одной из основных причин того, что CORBA чисто внешне отошла на второй план – если сравнивать ее, в первую очередь, с J2EE (а сейчас и .NET). Давайте рассмотрим, какие проблемы возникали у разработчиков по причине отсутствия компонентной модели:
объектная модель CORBA в значительной степени возлагала на разработчика обязанность управления жизненным циклом как CORBA-объектов, так и их сервантов. Некоторые возможности в этом плане предоставляли такие элементы инфраструктуры CORBA, как объектные адаптеры POA, менеджеры сервантов и менеджеры POA, но во многих случаях задача создания, активизации и уничтожения серверных объектов, а также "сборка мусора", возлагалась на программистов.
Большой проблемой являлась задача сохранения состояния серверных объектов, особенно с учетом возможных сбоев в системе. Нельзя сказать, что эту задачу решить было очень сложно, но, тем не менее, она требовала достаточно грамотного программирования при создании серверных приложений. Многочисленные попытки создания спецификации Сервиса Состояний (POS, Persistense Object Service) привели к созданию двух спецификаций этого сервиса, но обе они не были поддержаны сообществом программистов из-за очевидных недостатков. Впрочем, уже давно стало достаточно очевидно, что работоспособную спецификацию сохранения состояния вне компонентной модели создать не удастся.
Создание сложной системы немыслимо без обеспечения транзакционности на уровне объектов. Сервис Транзакций CORBA обеспечивал все необходимое для этого, но реализация некоторых интерфейсов – в первую очередь, интерфейса CosTransactions::Resource – возлагалась на программиста. Не было предусмотрено никаких стандартных механизмов взаимодействия с серверами баз данных с учетом наличия объектных транзакций.
Не существовало универсального и простого в использовании подхода для управления взаимодействием объектов CORBA (порождения событий и их обработки).
Отсутствие компонентов и контейнеров компонентов в CORBA привело к тому, что был сильно затруднен процесс создания, распространения и использования универсальных CORBA-компонентов.
Все это привело к тому, что реальные системы стали создавать с использованием 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 потребовало внесения многочисленных изменений в стандарт CORBA 2. В первую очередь, серьезной модификации подвергся сам язык IDL – в него были добавлены конструкции, позволяющие описать компоненты и связанные с ними новые элементы – в первую очередь, фабрики и хранилища. В формальное описание синтаксиса IDL к 111 ранее существовавшим правилам добавлено еще 27, связанных с определением компонентов. Появились такие новые служебные слова, как component, supports, provides, uses, emits, publishes, consumes, manages, home, primarykey, finder, eventtype. Кроме того, введено расширенное толкование служебных слов «custom», «abstract» и «factory».
Но изменения в IDL – только первый шаг...
Наличие этого раздела в данной статье может показаться странным. Тем не менее, автор решил начать именно с очень краткого рассмотрения EJB (читатель, который знаком с этой темой, может этот раздел просто пропустить).
Причина очень проста – компонентная модель CORBA, во-первых, создавалась как расширение и обобщение компонентной модели EJB, а, во-вторых, она (т.е. CCM) довольно сложна для понимания читателя, который с компонентными моделями не знаком. Так как EJB-модель проста – намного проще CCM – то знакомство с ней позволит гораздо быстрее понять архитектуру CCM.
Начнем с того, что же такое «компонент EJB». Некоторая сложность состоит в том, что используемый в спецификации термин "компонент" (bean) имеет различные значения, смысл которых очевиден в том или ином контексте для опытных EJB-разработчиков. Тем не менее, такая двойственность может сбить с толку программиста, который только начинает знакомиться с технологией EJB. Вследствие этого, автор взял на себя смелость ввести систему своих терминов, несколько отличающихся от тех, которые используются в спецификации – просто для ясности.
Согласно спецификации CORBA 3, "компонент CORBA является основным мета-типом в CORBA. Компоненты как мета-типы являются расширением и уточнением объектных типов (т.е. интерфейсов CORBA). Компоненты определяются на языке IDL и идентифицируются с помощью компонентной ссылки, которая является объектной ссылкой CORBA".
Таким образом, в CORBA, как и во многих других технологиях и языках программирования, произошел естественный переход от объектной архитектуры к архитектуре компонентной. Как и для всех остальных технологий, этот этап развития не привел к революционным переменам в терминологии или иной трактовке старых понятий. Как и IDL-интерфейс, IDL-компонент является типом, на основе которого можно создавать логические экземпляры компонентов CORBA (ранее – объектов CORBA). В общем, CORBA-компонент можно трактовать точно так же, как и компонент EJB – как некий мета-тип. Компонент CORBA можно также рассматривать, как обычный объект CORBA с дополнительными возможностями.
Поскольку мы уже знакомы с понятиями "компонент" и "экземпляр компонента", то в дальнейшем иногда будем использовать только термин "компонент", если смысл ясен по контексту.
Отличия между компонентом CORBA и объектом CORBA состоят, главным образом, в следующем:
компонент CORBA может объявлять несколько интерфейсов (не связанных друг с другом отношением наследования). Такие интерфейсы называют "фасетами" (facets) компонента;
с каждым компонентом CORBA (как типом) сопоставлена специальная фабрика для создания экземпляров компонентов этого типа. Функциональность этой фабрики задается программистом с помощью объявления сопоставленного с компонентом Home-интерфейса;
экземпляр компонента CORBA может иметь сопоставленный с ним уникальный идентификатор – первичный ключ (primary key), который позволяет отличить этот экземпляр от всех других таких же экземпляров, созданных той же фабрикой (home-объектом). Обычно первичный ключ задается с помощью valuetype;
компонент CORBA может получать и порождать события;
компонент CORBA может иметь атрибуты, определяющие его состояние (атрибуты CORBA-интерфейсов были просто формой объявления методов);
компонент CORBA может поддерживать модель установки соединений с другими компонентами или пользователями. Специальные точки входа, используемые для установки соединения с сопоставленными объектными ссылками, называются "гнездами" (receptacles);
компонент может сохранять и восстанавливать свое состояние. Соответствующие описания на специальном языке – PSDL – по сути, являются частью объявления компонента;
компоненты CORBA, в отличие от классических объектов CORBA, работают под управлением контейнеров CORBA. Это приводит к тому, что необходимо в составе компонента предусмотреть дополнительные описания (дескрипторы развертывания в XML-виде), которые используются в процессе установки компонента в контейнер.
Важным отличием компонентов CORBA от EJB-компонентов является расширенная модель поддержки многопоточности...
По совокупности характеристик как компонентов 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, поэтому будут рассмотрены (на уровне иллюстраций) только основные подходы, используемые для определения компонентов.
Спецификация оговаривает некоторые правила, которые неявно позволяют отличить объявление базового компонента от объявления компонента расширенного. Для базового компонента рекомендуется использовать следующую форму объявления:
“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; };
Интерфейсы, поддерживаемые компонентом, который не является производным от другого компонента, всегда имеют один или несколько базовых интерфейсов, в том числе – обязательно интерфейс Components::CCMObject. Наследование этого интерфейса выполняется неявно. В свою очередь, этот интерфейс наследует три стандартных интерфейса...
Компонентная модель CORBA – простой в использовании (но не в реализации!) и очень мощный инструмент создания распределенных систем. Ее наличие позволит обеспечить взаимодействие CORBA с архитектурой MDA, а также создавать универсальные, многоязыковые и многоплатформенные серверы приложений, преодолевая тем самым ограничения как J2EE (ориентированность на Java), так и .NET (реальная одноплатформенность). Впрочем, говорить об этом можно не раньше, чем появятся промышленные полномасштабные реализации этой компонентной модели. Первые шаги в этом направлении уже сделаны.
Copyright © 1994-2016 ООО "К-Пресс"