5.2. Порядок действий

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

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

• объектно-ориентированный анализ и моделирование;

• описание и трансляция объектов;

• создание сервера;

• создание клиента;

• отладка объектов.

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

5.3. Объектно-ориентированный анализ и моделирование

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

В принципе для обдумывания модели проекта достаточно острого карандаша и нескольких листов бумаги. Однако чтобы идея была понятна и разработчикам, нужно задокументировать ее. Построить IDL-описания по моделям поможет пакет Rational Rose, нацеленный на создание UML-моделей (UML — универсальный язык описания моделей).

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

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

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

5.4. Описание и трансляция объектов

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

В каждой версии VisiBroker имеется свой компилятор IDL: VisiBroker for C++ оснащен компилятором idl2cpp, а VisiBroker for Java — idl2java. Первый на основе IDL-описания объектов генерирует исходные тексты на языке Cи++ и включаемые заголовочные файлы, а второй делает описания классов на языке Java и пакетную структуру имен.

VisiBroker for Java обладает еще парочкой компиляторов java2iiop и java2idl, иначе называемых технологией Caffeine. Однако пока они реализованы лишь в Java-версии VisiBroker да и больше подходят для переноса в среду CORBA старых классов Java, а не для создания новых объектов.

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

Файл component.idl

#pragma prefix ”pcworld.ru”

module AbstractComponent

{

// Опережающее описание некоего интерфейса

// для получения информации о компоненте

interface ComponentInfo;

interface ServiceProvider

{

// Компонент возвращает строку со своим

// кратким текстовым описанием

string getDescription();

// Операция получения информации о компоненте

// в машинном виде

ComponentInfo getComponentInfo();

// Операция присвоения компоненту

// уникального идентификатора

void setUniqueID(in long id);

};

};

Дальнейшие действия для программистов на Java и Cи++ будут несколько различаться. Трансляция на Cи++ должна быть запущена командой:

idl2cpp -src_suffix cpp component.idl

а трансляция на Java — командой:

idl2java corba.idl

Если ошибок в IDL не было, то в результате на диске появятся всего четыре файла для Cи++, в то время как для Java файлов может оказаться гораздо больше, да и размещаться они будут в каталогах со сложной структурой. Об именах полученных файлов и их назначении будет сказано в следующих разделах.