a <<= MyArray_forany (mas, true); // или a <<= MyArray_forany (mas, 1);

Для чтения массива из any необходимо сначала создать переменную типа MyArray_forany. Для этого типа переопределена операция [], так что можете рассматривать объект этого типа как обычный массив:

MyArray_forany buffer;
any >>= buffer;
if (buffer [2] = buffer[3])
...

any и объектные ссылки

Применительно к взаимодействию any и объектных ссылок справедливы все замечания, касающиеся использования структур, объединений и последовательностей. VisiBroker предусматривает только одну форму операции <<=, а именно, с использованием типов _var и _ptr. В этом случае выполняется копирование объектной ссылки, т.е. вызывается операция _duplicate(). Спецификация говорит о возможности генерации операции <<=, для которой в качестве второго операнда используется адрес объектной ссылки, т.е. указатель на объект _var- или _ptr-типа.

TCKind

TCKind просто представляет из себя перечисление, в котором для каждого типа данных IDL (включая тип any) сопоставлен свой элемент):

module  CORBA
{
   ...
   enum TCKind
   {
      tk_null,     tk_void,      tk_short,    tk_long,  
      tk_ushort,   tk_ulong,     tk_float,    tk_double,
      tk_boolean,  tk_char,      tk_octet,    tk_any,
      tk_TypeCode, tk_Principal, tk_objref,   tk_struct,
      tk_union,    tk_enum,      tk_string,   tk_sequence,
      tk_array,    tk_alias,     tk_except,   tk_longlong,
      tk_ulonglong,tk_longdouble,tk_wchar,    tk_wstring,
      tk_fixed,    tk_value,     tk_value_box,tk_native,
      tk_abstract_interface
   };
   ...
};

TCKind, как перечисление IDL, безо всяких изменений отображается в перечисление (enum) C++. Обычно в СORBA-программах те или иные конкретные значения признака типа используются примерно так:

CORBA::Ant any;
...
TypeCode_var type_code = any->type();
switch (type_code->kind())    // TCKind
{
case CORBA::tk_short :
   ...
   break;
   
case CORBA::tk_long :
   ...
}

TypeCode

TypeCode представляет собой довольно интересный IDL-тип. C одной стороны, правила его отображения с IDL на конкретный язык программирования могут отличаться от стандартных правил, т.е. TypeCode является псевдо-типом IDL, объявленным с помощью PIDL. С другой стороны, TypeCode можно передавать как аргумент удаленных методов, что нехарактерно для псевдо-типов. Не забывайте также, что TypeCode является IDL-интерфейсом, т.е. это объектная ссылка.

Основными методами интерфейса TypeCode являются следующие:

kind() - возвращает TCKind для TypeCode.

equal() - сравнивает, является ли объект типа TypeCode, для которого вызывается этот метод, <эквивалентным> аргументу этого метода. Метод equal() в CORBA 2.3 возвращает значение TRUE тогда и только тогда, когда сравниваемые объекты типа TypeCode эквивалентны во всех отношениях, т.е. для них применимы одни и те же операции интерфейса TypeCode, и все они дают для обоих объектов одинаковые результаты.

equivalent() - выполняет те же действия, что и equal(), но при этом он поступает более <интеллектуальным> образом. В частности, он игнорирует наличие алиасов типов (т.е. использование синонимов типов, создаваемых с помощью typedef).

get_compact_typecode() - получает новый объект TypeCode на базе исходного путем удаления всех необязательных описателей структуры типа вида name и member_name. Алиасы остаются нетронутыми.

id() - возвращает репозитарный идентификатор (Repository ID).

В чем же заключаются особенности отображения TypeCode по сравнению с <нормальными> интерфейсами CORBA? Одной из таких важных особенностей является возврат для методов name(), id(), member_name() и других C++-типа const char*, а не char*:

IDL:

RepositoryId id () raises (BadKind);
Identifier name () raises (BadKind);

C++:

class CORBA_TypeCode
{
public:
   ...
   virtual const char* id() const;
   virtual const char *name() const; 
   ...
};

Это, в частности, означает, что управление возвращаемыми строками берет на себя сам TypeCode, и вам не следует пытаться вызывать CORBA::string_free(). Вряд ли это удобно, но что поделаешь.

Поскольку TypeCode часто используются при анализе типов используемых данных, возникает вопрос об универсальности их использования - и для стандартных данных, и для типов, созданных программистом. На первый взгляд может показаться, что, например, для сравнения типов объектов вполне достаточно наличия объектов типа TCKind, т.е. вместо сравнения TypeCode лучше сравнивать их TCKind'ы:

TypeCode_ptr  type_code1 = ...
TypeCode_ptr  type_code2 = ...
...
// непереносимый код, так не сравнивают объектные ссылки!
if (type_code1 == type_code2)
...
// Правильно:
if (type_code1->kind() == type_code2->kind())
...

Это будет хорошо работать, но только до тех пор, пока вы не захотите сравнить типы двух массивов или структур. Их TCKind будет одинаков - tk_array или tk_struct, соответственно, но два типа могут иметь разные типы своих элементов, число этих элементов или полей. Поэтому необходимо сравнивать все-таки сами объекты типа TypeCode.

Это сопряжено с определенными трудностями. Вообще, сравнение на равенство (или неравенство) двух объектных ссылок в CORBA - задача трудно решаемая. В общем случае получить достоверный однозначный ответ крайне трудно, если не сказать невозможно. Но в данном случае, к счастью, никаких проблем не возникает. Для сравнения TypeCode вы можете использовать вполне однозначные функции TypeCode::equal() и TypeCode::equivalent().

if(type_code1->equal (type_code2) )...

или

if(type_code1->equivalent (type_code2) )...

Теперь можно задаться следующим вопросом: где взять конкретные значения TypeCode - и для стандартных IDL-типов, и для IDL-типов, определенных пользователем?

Значения стандартных TypeCode для IDL-типов, не требующих наличия дополнительной информации, помимо TCKind, созданы как константы в классе CORBA. Вот список этих констант (все они имеют тип const CORBA::TypeCode_ptr):

_tc_null      _tc_void       _tc_short  _tc_long
_tc_ushort    _tc_ulong      _tc_float  _tc_double
_tc_boolean   _tc_char       _tc_octet  _tc_any  
_tc_TypeCode  _tc_Object     _tc_string _tc_longlong
_tc_ulonglong _tc_longdouble _tc_wchar  _tc_wstring

Для остальных типов данных соответствующие _tc_-константы генерируются непосредственно компилятором idl2cpp.

IDL:

typedef sequence<long, 20> LongFixSeq;

C++:

extern CORBA::TypeCode_ptr _tc_LongFixSeq;
extern CORBA::TypeCode_ptr _tc_LongFixSeq_get();

Это, конечно, прекрасно, но мы говорим о динамическом способе взаимодействия и, следовательно, IDL-декларации просто отсутствуют. В этом случае нужные объекты типа TypeCode можно создать, используя в качестве фабрики сам ORB:

CORBA::TypeCode_ptr alias_tc =
orb->;create_alias_tc ("LOCAL:MyRepositoryID", "SIAlias", _tc_SimpleInterface);

Описание метаданных каждого типа данных и список функций для создания объектов типа TypeCode вместе со списками их аргументов приведены в документе 99-10-11.pdf.

dynAny

Итак, мы теперь знаем, что объекты типа any состоят из описания типа (объект TypeCode) и собственно значения. Если и TypeCode, и тип значения, которое нужно поместить в объект any, известно на этапе компиляции, то не возникает никаких трудностей. Вы определяете с помощью IDL свой собственный тип данных (обычно это структура, объединение, последовательность, массив или тип-значение), а компилятор с IDL на выбранный язык программирования сгенерирует для этого типа операции помещения его в объект any и извлечения из него. Для стандартных типов данных - short, string и др. - такие стандартные операции являются частью мэппинга IDL на конкретный язык программирования.

Проблемы возможны в том случае, если код типа (TypeCode) и/или собственно данные, которые нужно поместить в объект типа any, неизвестны на этапе компиляции, т.е. для них нет IDL-декларации и, следовательно, нет сгенерированной операции помещения таких данных в any.

Как динамически создавать коды типов с помощью ORB, было уже показано. Возможно и динамическое - без IDL - создание данных произвольных типов и помещение их в объект типа any. Такие операции предоставляют совместно интерфейсы DynAny и DynAnyFactory.

module DynamicAny 
{
   interface DynAny 
   {
      exception InvalidValue {};
      exception TypeMismatch {};
      
      // Методы, определяющие операции копирования, уничтожения, сравнения и 
      // преобразования типов от any к DynAny и обратно
      
      CORBA::TypeCode type();
      
      void assign(in DynAny dyn_any) raises(TypeMismatch);
      void from_any(in any value) raises(TypeMismatch, InvalidValue);
      any to_any();
      boolean equal(in DynAny dyn_any);
      void destroy();
      DynAny copy();
      
      // Методы записи данных базовых типов, объектных ссылок, 
      // any и DynAny в объект DynAny
      
      void insert_boolean(in boolean value) raises(TypeMismatch, InvalidValue);
      void insert_octet(in octet value) raises(TypeMismatch, InvalidValue);
      void insert_char(in char value) raises(TypeMismatch, InvalidValue);
      void insert_short(in short value) raises(TypeMismatch, InvalidValue);
      ... 
      // Методы чтения данных базовых типов, объектных ссылок, any и DynAny
      // из объекта DynAny
         
      boolean get_boolean() raises(TypeMismatch, InvalidValue);
      octet get_octet() raises(TypeMismatch, InvalidValue);
      char get_char() raises(TypeMismatch, InvalidValue);
      short get_short() raises(TypeMismatch, InvalidValue);
      ...
   };
   
   // Интерфейсы, обеспечивающие работу с? сконструированными типами данных 
   // и перечислениями
   
   interface DynFixed : DynAny 
   {
      string get_value();
      boolean set_value(in string val) raises(TypeMismatch, InvalidValue);
   };
   
   interface DynEnum : DynAny 
   {
      string get_as_string();
      void set_as_string(in string value) 
         raises(InvalidValue);
      unsigned long get_as_ulong();
      void set_as_ulong(in unsigned long value) 
         raises(InvalidValue);
   };
   ...
   interface DynStruct : DynAny { ... };
   interface DynUnion : DynAny { ... };
   interface DynSequence : DynAny { ... };
   interface DynArray : DynAny { ... };
   interface DynValue : DynAny { ... };
   
   // Интерфейс для создания объектов типа DynAny
   
   interface DynAnyFactory 
   {
      exception InconsistentTypeCode {};
      
      DynAny create_dyn_any(in any value) raises(InconsistentTypeCode);
      DynAny create_dyn_any_from_type_code(in 
         CORBA::TypeCode type) raises(InconsistentTypeCode);
   };
   ...
};

Способ получения интерфейса DynAnyFactory и простые примеры работы с DynAny будут рассмотрены ниже.

Более подробное рассмотрение этой темы выходит за рамки статьи. Исчерпывающее описание можно найти в документе 99-07-13.pdf на сайте www.omg.org.

Некоторые IDL-типы, используемые при работе с DII/DSI

Практически все рассматриваемые в этой главе IDL-объекты являются псевдо-объектами, и на практике гораздо важнее знать, во что превращается данный набор IDL-объявлений при работе с C++ или Java, чем помнить само IDL-объявление. Вследствие этого, мы рассмотрим и IDL-декларации, и их отображения на C++.

NamedValue

Структура NamedValue используется для задания аргументов удаленных методов в динамическом режиме. В принципе информация, которая хранится в такой структуре, соответствует информации, известной компилятору С++, Java или других языков при использовании статических стабов. Тип NamedValue предназначен для использования исключительно как элемент NVList.

module CORBA
{
...
   typedef unsigned long Flags;
   typedef string Identifier;
   const Flags ARG_IN = 1;
   const Flags ARG_OUT = 2;
   const Flags ARG_INOUT = 3;
   const Flags CTX_RESTRICT_SCOPE = 15;
   
   struct NamedValue {  // PIDL
      Identifier name;  // имя аргумента
      any argument;     // значение аргумента
      Flags arg_modes;  // признак вида аргумента
   };
};

Отображение на C++

Согласно спецификации OMG, С++-аналог IDL-типа NamedValue выглядит так:

class NamedValue
{
public:
   const char *name() const;
   Any *value() const;
   Flags flags() const;
};

Отображение для VisiBroker for C++

Реализации Visigenic/INPRISE, в общем, следует спецификации OMG, но при этом добавляет несколько полезных методов (далее мы будем приводить отображение для VisiBroker). Текст находится в файле ...vbroker\include\nameval.h. Ниже приведены наиболее важные фрагменты:

class CORBA_NamedValue : private VISResource
{
private:
   CORBA_NamedValue();
   ~CORBA_NamedValue();
   CORBA_NamedValue (const CORBA_NamedValue& ) {}
   CORBA_NamedValue& operator=(const CORBA_NamedValue&);
   
   CORBA::String_var _name;
   CORBA_Any_var _value;
   CORBA::Flags _flags;
public: 
   const char *name() const { return _name; }
   CORBA_Any *value() { return _value; }
   CORBA::Flags flags() const { return _flags; }
   
   static CORBA_NamedValue_ptr _duplicate(CORBA_NamedValue_ptr nv);
   static CORBA_NamedValue_ptr _nil() 
   { return (CORBA_NamedValue*)NULL; }
   static void _release (CORBA_NamedValue_ptr ptr);
   ...
};

Обратите внимание на то, что деструктор объявлен как private-метод. Это классический способ гарантировать в С++ использование только динамических объектов такого типа.

Вы можете, как всегда, использовать типы NamedValue_ptr и NamedValue_var.

NVList

Этот псевдо-объект IDL предназначен для хранения списка аргументов.

module CORBA
{
   ...
   pseudo interface NVList
   {
      readonly attribute unsigned long count;
      
      NamedValue add(in Flags flags);
      NamedValue add_item (in Identifier item_name, 
         in Flags flags);
      NamedValue add_value (in Identifier item_name, 
         in any val, in Flags flags);
      
      NamedValue item(in unsigned long index) raises(Bounds);
      void remove(in unsigned long index) raises(Bounds);
   };
};

Фабрикой для NVList является ORB.

module ORB //PIDL
{
   ...
   void create_list(
      in long count, // Число элементов в списке
      out NVList new_list); // Созданный список
};

Отображение для VisiBroker for C++

class CORBA_NVList : private VISResource
{
public:
   class Bounds: public CORBA_UserException { ... };
   
   CORBA::Long count() const { return _count; }
   
   CORBA_NamedValue_ptr add(CORBA::Flags);
   CORBA_NamedValue_ptr add_item(const char *name, 
      CORBA::Flags flags);
   CORBA_NamedValue_ptr add_value(const char *name, 
      const CORBA_Any& any, 
      CORBA::Flags flags);
   CORBA_NamedValue_ptr add_item_consume(char *name, CORBA::Flags);
   CORBA_NamedValue_ptr add_value_consume(char *name, 
      CORBA_Any *value,
      CORBA::Flags flags);
   
   CORBA_NamedValue_ptr item(CORBA::ULong index);
   void remove(CORBA::ULong index);
   
   // Следующий метод оставлен для совместимости с ранними версиями
   void free_out_memory();
   
   static CORBA_NVList_ptr _duplicate(CORBA_NVList_ptr ptr);
   static CORBA_NVList_ptr _nil() { return (CORBA_NVList_ptr)NULL; }
   static void _release(CORBA_NVList_ptr ptr);
   
   CORBA_NVList(CORBA::ULong initial_size=16);
   ~CORBA_NVList();
   private:
      CORBA_NVList(const CORBA_NVList& );
      CORBA_NVList& operator=(const CORBA_NVList& );
      ...
};

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

Обратите внимание на наличие public-конструктора и деструктора.

Environment

Этот тип предназначен для управления исключениями при работе с DII, точнее, для хранения и управления объектом типа <исключение>. Программист устанавливает исключительную ситуацию (как объект) или получает к нему доступ с помощью атрибута exception, который в обычном стиле CORBA реализован с помощью пары set/get- методов.

Этот тип очень важен, так возникновение исключительной ситуации при использовании DII-вызовов отслеживается путем явного анализа присутствия (или отсутствия) исключения как объекта, который <упакован> в объект CORBA::Request. Поскольку каждый конкретный вызов может приводить к появлению только одной исключительной ситуации (из некоторого множества возможных для данного метода), то объект Request содержит единственный подобъект типа Environment, который, в свою очередь, может содержать только одно исключение.

Проверка, нее возникло ли исключения при вызове, выполняется путем вызова get-метода exception(). Возврат нулевой ссылки (NULL для C++) говорит о том, что при выполнении кода удаленного метода исключительной ситуации не возникло.

pseudo interface Environment
{
   attribute Exception exception;
   void clear();
};

Задание в качестве параметра при вызове set-метода exception() нулевой ссылки эквивалентно вызову метода clear(), т.е. сбросу установленного исключения

Отображение для VisiBroker for C++

class CORBA_Environment
{
private:
   CORBA_Exception_var    _exception;
public:
   CORBA_Environment() {}
   ~CORBA_Environment() {}
   
   CORBA::Exception *exception() const { return _exception; }
   void  exception(CORBA::Exception *exp) { _exception = exp; }
   void  clear() { _exception = (CORBA_Exception *)NULL; }
   
   static CORBA_Environment_ptr _duplicate(CORBA_Environment_ptr env);
   static CORBA_Environment_ptr _nil() 
{ return (CORBA_Environment_ptr)NULL; }
   static CORBA_Environment& current_environment();
};

При вызове set-метода exception() объект типа Environment становится владельцем передаваемого ему объекта типа <исключительная ситуация>, причем он предполагает, что этот объект создан с помощью операции new. Get-метод exception(), возвращая объект, не передает пользователю <владение> им - по-прежнему за удаление этого объекта отвечает Environment, и вы НЕ должны вызывать функцию delete для результата get-метода exception().

Интерфейс ExceptionList

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

module CORBA
{
   ...
   pseudo interface ExceptionList
   {
      readonly attribute unsigned long count;
      void add(in TypeCode exc);
      TypeCode item(in unsigned long index) raises(Bounds);
      void remove(in unsigned long index) raises(Bounds);
   };
};

Смысл методов этого интерфейса абсолютно очевиден.

На C++ на него основе будет сгенерирован примерно следующий класс:

module CORBA 
{
   ...
   class ExceptionList
   {
   public:
      ULong count();
      void add(TypeCode_ptr tc);
      void add_consume(TypeCode_ptr tc);
      TypeCode_ptr item(ULong index);
      void remove(ULong index);
   };
};

DII

Спецификация DII содержится в документе 99-07-11.pdf. Автор рекомендует знакомиться с вопросами, имеющими отношение к DII, по спецификациям отображения IDL на конкретный язык программирования – они (по крайней мере, на момент написания статьи) содержат более свежую и полную информацию).

Термин «DII» относится к совокупности интерфейсов, методов, типов данных и пр., которые обеспечивают динамическое (т.е. в процессе работы программы) формирование запроса, который стандартным образом передается ORB, а затем и компонентам CORBA на стороне сервера для его выполнения и, возможно, возврата результата. Концептуально и динамический, и статический способ формирования запроса (более конкретно, объекта типа CORBA::Request) ничем не отличаются друг от друга, просто в одном случае программист вызывает те или иные методы, формирующие данный объект, а в другом эту работу выполняет сгенерированный компилятором с IDL некий код в клиентском стабе.

Для использования DII (и DSI) программист должен свободно ориентироваться в средствах динамического создания как новых типов (интерфейс TypeCode), так и данных таких типов (интерфейсы any и DynAny и производные от него интерфейсы - DynStruct, DynArray и др.)...

Объект CORBA::Request

Объект Request играет главную роль при вызове удаленных методов в режиме DII. Он содержит все необходимые свойства и методы, чтобы выполнить следующие действия (предположим, что этот объект уже тем или иным образом создан):

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

обращение к одному из методов выполнения удаленного вызова;

получение и анализ результата.

Ниже приведена IDL-декларация для интерфейса Request. Как и большинство ранее рассмотренных объявлений, это псевдо-IDL, и отображения на конкретные языки программирования имеют многочисленные особенности.

module CORBA 
{
   pseudo interface ExceptionList { ... }
   pseudo interface ContextList { ... }
   
   pseudo interface Request
   {
 // серверный объект
      readonly attribute Object target;
 // имя вызываемого метода
      readonly attribute Identifier operation;
 // список аргументов
      readonly attribute NVList arguments;
 // значение результата
      readonly attribute NamedValue result;
 // исключение (если было возбуждено)
      readonly attribute Environment env;
 // список возможных исключений
      readonly attribute ExceptionList exceptions;
 // список свойств контекста
      readonly attribute ContextList contexts;
      attribute context ctx;
      
      void invoke();
      void send_oneway();
      void send_deferred();
      void get_response();
      boolean poll_response();
   };
};

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

Отображение Request на C++

Одной из важных (и очень приятных) особенностей отображения IDL для интерфейса Request на C++ является добавление большого количества вспомогательных и очень удобных для работы методов - методов формирования списка аргументов.

class Request
{
public:
   Object_ptr target() const;
   const char *operation() const;
   NVList_ptr arguments();
   NamedValue_ptr result();
   Environment_ptr env();
   ExceptionList_ptr exceptions();
   ContextList_ptr contexts();
   void ctx(Context_ptr);
   Context_ptr ctx() const;
   
   Any &add_in_arg();
   Any &add_in_arg(const char* name);
   Any &add_inout_arg();
   Any &add_inout_arg(const char* name);
   Any &add_out_arg();
   Any &add_out_arg(const char* name);
   
   void set_return_type(TypeCode_ptr tc);
   Any &return_value();
   
   void invoke();
   void send_oneway();
   void send_deferred();
   void get_response();
   Boolean poll_response();
};

Как всегда, для VisiBroker предусмотрены три дополнительные статические функции - _duplicate(), _release() и _nil().

Для объекта Request определены специальные правила управления памятью для всех методов, сгенерированных для IDL атрибутов, а именно, программист никогда не должен пытаться применять операцию delete (или ее аналоги) к результате вызова методов target(), operation(), arguments(), result(), env(), exceptions(), contexts() и ctx().

Если при формировании списка ExceptionList() вы использовали методы с суффиксом _consume, то список создает копии объектов TypeCode и хранит эти копии. Более того, реализация может после создания копии уничтожить оригинал, поэтому не рекомендуется при создании переносимых программ обращаться к объектам, которые являлись аргументами метода add_consumer().

Методы add_XX_arg() позволяют легко добавлять в список новые аргументы. Вместо получения объекта <список аргументов> с помощью вызова arguments(), а затем использования метода NVList::add(), например, так:

*(request->arguments()->add(ARG_IN)->value()) <<= anArg;

можно сразу обратиться к методам добавления аргументов непосредственно в классе Request:

request->add_in_arg() <<= anArg;

Создание объекта Request

Итак, мы уже немного научились работать с объектом Request, но до сих пор не знаем, как его создать. Стандартным методом, объявленным на уровне IDL, является метод Object::create_request() (об интерфейсе CORBA::Object говорилось в разделе 6.4.1).

interface Object // PIDL
{
   ...
   void create_request (in Context ctx, // контекст для вызываемого метода
      in Identifier operation,          // имя вызываемого метода
      in NVList arg_list,               // список аргументов
      inout NamedValue result,          // значение результата
      out Request request,              // созданный объект типа Request
      in Flags req_flags                // флаги для запроса
   );
};

При создании и заполнении списка аргументов (параметр arg_list) вы можете использовать любой из способов, о которых говорилось ранее - либо применять методы NVList::add, либо методы Request::add_XX_arg(), но не оба сразу. При использовании методов add_XX_arg() параметр arg_list предварительно должен быть установлен в значение NULL/null.

Наверное, единственный из оставшихся параметров, нуждающийся в дополнительных пояснениях - это параметр req_flags. Этот параметр лучше устанавливать в значение CORBA::OUT_LIST_MEMORY при наличии out-аргументов и не устанавливать в противном случае. При установленном значении OUT_LIST_MEMORY динамическая память, выделенная для хранений значения out-аргументов, освобождается вместе с уничтожением самого объекта NVList.

Использование C++

При отображении на С++ предусмотрены две версии метода Object::create_request():

void Object::_create_request(Context_ptr ctx,
                             const char *operation,
                             NVList_ptr arg_list,
                             NamedValue_ptr result,
                             Request_out request,
                             Flags req_flags
                             );
void Object::_create_request(Context_ptr ctx,
                             const char *operation,
                             NVList_ptr arg_list,
                             NamedValue_ptr result,
                             ExceptionList_ptr,
                             ContextList_ptr,
                             Request_out request,
                             Flags req_flags
                             );

Вы можете выбрать любую из них, но на практике программисты на C++ обычно используют дополнительный метод, который отсутствует на уровне IDL, но является частью правил отображения интерфейса Object на C++. Это метод Object::_request(). Единственным его аргументом является строка, содержащая имя вызываемого метода серверного объекта, например:

MyInterface_var oRef = ...;
CORBA::Request_var request = oRef->_request ("my_operation");

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

Вызовы удаленных методов

В настоящий момент, пока (вместе с CORBA 3.0) не утверждена спецификация Messaging Service - спецификация асинхронного взаимодействия клиентов и серверов - для статического режима CORBA возможен только синхронный вызов удаленных методов (oneway-методы мы по ряду причин в расчет не принимаем). Это означает, что поток клиента, из которого был выполнен удаленный запрос, блокируется до завершения этого запроса. Конечно, такой способ далеко не всегда удобен (а иногда и просто неприемлем). Опытный программист может возразить, что такую проблему решить не составляет труда: нужно просто создать отдельный поток и вызвать синхронный метод из него - пусть ждет завершения, сколько надо. Тем не менее, желательно иметь более простые средства выполнения асинхронных вызовов и обработки их результатов. Сейчас это возможно только при использовании DII.

Спецификация предусматривает несколько методов выполнения асинхронных вызовов. Ниже приводятся соответствующие фрагменты IDL-деклараций:

module CORBA {
   ...
   interface Request;
   typedef sequence <Request> RequestSeq;
   
   interface Request 
   {
      void invoke();
      void send_oneway();
      void send_deferred();
      void get_response();
      boolean poll_response();
      ...
   };
   void send_multiple_requests_oneway(in RequestSeq req);
   void send_multiple_requests_deferred(in RequestSeq req);
   
   boolean poll_next_response();
   void get_next_response(out Request req) raises (WrongTransaction);
   ...
};

Метод Request::invoke() выполняет синхронный вызов. Последовательность действий (на C++) выглядит примерно так:

MyInterface_var oRef = ....;
CORBA::Any op1, op2, result;
op1 <<= CORBA::Long (1);
op2 <<= CORBA::Long (2);
CORBA::Request_var request = oRef->_request("operation_add");
request->add_in_arg() <<= op1;
request->add_in_arg() <<= op2;
request->set_return_type (CORBA::_tc_long);
request->invoke();
if(request->env()->exception() == 0) 
// проверка отсутствия возникновения исключения
   request->return_value() >>= result;
...

Метод Request::send_deferred() (и связанные с ним методы Request::get_response() и poll_response() предполагают другой подход:

...
CORBA::Request_var request = oRef->_request("operation_add");
...
request->send_deferred ();
while(!request->poll_response()) // цикл ожидания прихода ответа 
DoSomething();
request->get_response();
if(request->env()->exception() == 0) 
request->return_value() >>= result;

Периодически вызываемый метод Request::poll_response() возвращает true, если вызов удаленного метода завершен. В этом случае вы вызываете метод Request::get_response() и анализируете полученное значение. Если вы вызовете метод get_response() перед тем, как вызов удаленного метода будет завершен, то поток, обратившийся к этому методу, будет блокирован до получения ответа от сервера.

Спецификация OMG говорит, что результат повторного обращения к методу invoke() или send_deferred() не определен. Та же неопределенность возникает, если вы вызываете эти методы для объекта, который уже был использован в качестве аргумента при вызове метода CORBA::send_multiple_requests_deferred().

Методы

void send_multiple_requests_deferred(in RequestSeq req);
boolean poll_next_response();
void get_next_response(out Request req) raises (WrongTransaction);

позволяют посылать в асинхронном режиме и анализировать состояние сразу для нескольких объектов типа Request. Метод get_next_response() возвращает объект Request для очередного завершенного вызова. Порядок возврата значений зависит от того, какой из методов на стороне сервере был выполнен быстрее, поэтому программисту необходимо определить, ответом на какой запрос является полученный объект Request.

DSI

Спецификация DSI содержится в документе 99-07-12.pdf. Этот документ содержит всего 6 страниц. Как ни прост интерфейс DSI, этого все-таки маловато – автор рекомендует дополнительно обращаться к спецификациям отображения IDL на конкретные языки программирования.

Интерфейс DSI (конечно, «интерфейс» не в смысле «IDL-интерфейс») выполняет на стороне сервера ту же роль, что и интерфейс DII на стороне клиента. При получении клиентского запроса (неважно, каким образом сформированного) на стороне сервера выполняются вполне стандартные действия до тех пор, пока поученный запрос не «доберется» до нужного серванта. Каким образом – статически или динамически – обрабатывать этот запрос, программист решает на стадии создании класса серванта. При работе в статическом режиме вы используете сгенерированный компилятором с IDL класс скелетона, либо создавая на его основе класс серванта (в случае наследования), либо рассматривая этот класс скелетона как класс серванта (в случае делегирования). В обоих случаях вы пишете код для нескольких методов, определенных на уровне IDL.

DSI использует другой подход. Вы создаете класс серванта именно для динамической обработки запросов. Главная идея DSI – использование одного-единственного метода для обработки всех клиентских запросов, адресованных данному объекту. Такой метод (спецификация OMG называет его DIR – Dynamic Implementation Routine) вызывается самим ORB’ом. В качестве единственного INOUT-аргумента ему передается объект типа ServerRequest. Задача программиста – написать код для DIR, который и будет обслуживать все поступающие запросы клиентов.

Объект ServerRequest

Если при использовании DII вы работаете, в основном, с объектом CORBA::Request, то «сердцем» DSI является объект CORBA::ServerRequest. Программисту нет никакой необходимости создавать его - это задача ORB – поэтому использовать интерфейс ServerRequest даже проще, чем интерфейс Request.

Объект типа ServerRequest содержит всю нужную информацию о полученном вызове – имя метода, а также имена, типы и значения его аргументов. Задача программиста – считать значения аргументов типа IN и INOUT, выполнить необходимые действия, а затем установить значения выходных аргументов (типа INOUT и OUT), а также (если надо) значение результата. Кроме того, вы можете создать и поместить в объект ServerRequest объект типа «исключение».

module CORBA 
{
   ...
   interface ServerRequest // PIDL
   {
      readonly attribute Identifier operation;
      void arguments (inout NVList nv);
      Context ctx();
      void set_result(in Any val);
      void set_exception(in Any val);
   };
};

Единственное, что может вызвать некоторые вопросы - это метод arguments(). Вы вызываете это метод, чтобы считать в заранее подготовленный вами список аргументов их текущие значения. Аргумент nv типа NVList имеет атрибут INOUT - сначала вы считываете данные (вызывая метод arguments()), а затем тем или иным образом в этом же объекте устанавливаете значения выходных параметров.

Метод set_exception(), хотя формально получает аргумент любого типа, должен получать только значения типа <исключения> (другими словами, TCKind для TypeCode аргумента должен быть равен) tk_except. В противном случае при попытке установить значение исключения будет возбуждена исключительная ситуация CORBA::BAD_PARAM. Если вы установили исключение, которое не предусмотрено в списке исключений для данного метода, то спецификация разрешает как возбуждение исключения BAD_PARAM при попытке его установки в объекте ServerRequest, так и возбуждение ORB'ом исключения UNKNOWN_EXCEPTION на стороне клиента.

Отображение ServerRequest на C++

Спецификация OMG в качестве стандартного объявляет следующий код:

namespace CORBA
{
   ...
   class ServerRequest
   {
   public:
      const char* operation() const;
      void arguments (NVList_ptr& parameters);
      Context_ptr ctx();
      void set_result(const Any& value);
      void set_exception(const Any& value);
   };
};

Метод operation() возвращает имя вызванной клиентом операции. Если клиент вызвал операцию, используя не IDL-метод, а IDL-атрибут, то имя операции получается конкатенацией префиксов _get_ /_set_ и имени атрибута.

Здесь надо сказать несколько слов об особенностях отображения для этого интерфейса. Спецификация его сильно изменилась по сравнению с версией CORBA 2.0, в которой впервые появилась концепция DSI. Наличие этих изменений, хотя они и не носят принципиального характера (кроме схемы управления памятью), может вызвать затруднение у начинающего CORBA-программиста - реализации поддерживают как старые, так и новые методы, которые, хотя и делают, в общем, одно и то же, но почему-то имеют разные имена или другой способ передачи своих аргументов. Например, <старый> метод result() в качестве аргумента получает указатель на CORBA::Any, а его <новый> аналог - set_result() - сам объект CORBA::Any.

Реализация отображения при работе с VisiBroker выглядит так (полный текст вы можете найти в файле ...\vbroker\include\srequest.h):

class CORBA_ServerRequest : private VISResource
{
private:
   CORBA_ServerRequest (CORBA::MarshalInBuffer& strm, const char* operation,
      VISReplyHandler&);
   ~CORBA_ServerRequest();
   CORBA_ServerRequest(const CORBA_ServerRequest&) {}
   CORBA::ServerRequest& operator=(const CORBA::ServerRequest&);
   
   CORBA::String_var _operation;
   CORBA::Context_var _ctx;
   CORBA::NVList_var _params;
   CORBA::Any_var _result;
   CORBA::Environment _env;
   ...
public:
   CORBA::Context_ptr ctx();
   
   // Методы в "стиле CORBA 2.0"
   const char* op_name() const { return _operation; }
   void params (CORBA::NVList_ptr);
   void result (CORBA::Any_ptr);
   void exception(CORBA::Any_ptr exception);
   
   // Методы в "новом" стиле, ориентированные на поддержку POA
   const char *operation() const { return _operation; }
   void arguments(CORBA::NVList_ptr param) { params(param); }
   void set_result (const CORBA::Any& a) 
   { result(new CORBA::Any(a)); }
   void set_exception (const CORBA::Any& a) 
   { exception(new CORBA::Any(a)); }
   
   static CORBA::ServerRequest_ptr _duplicate(CORBA::ServerRequest_ptr req);
   static CORBA::ServerRequest_ptr _nil() { return 0; }
   static void _release(CORBA::ServerRequest_ptr ptr);
};

Простейший анализ приведенного фрагмента показывает, что в использовании <стиля CORBA 2.0> нет никакой необходимости.

И еще одно изменение по сравнению с CORBA 2.0: объект ServerRequest является владельцем своих объектов, поэтому не надо вызывать delete или free() для результатов методов op_name() и operation().

Тип серванта

Класс серванта, используемого при работе в режиме DSI, должен быть создан как класс, производный либо от CORBA::DynamicImplementation (этот подход объявлен устаревшим), либо от PortableServer::DynamicImplementation. Для пользователя особо большой разницы нет - и в том, и в другом случае необходимо знать (и явно указать) RepositoryID для самого производного в иерархии наследования интерфейса (при работе с C++)., только сделано это немного по-разному. При использовании CORBA::DynamicImplementation вы указываете RepositoryID (и некоторые другие параметры) как аргументы конструктора, а при использовании PortableServer::DynamicImplementation вы должны вернуть нужные значения как результат метода, объявленного в C++ как чисто виртуальный.

Разумеется, при создании новых программ следует использовать класс PortableServer::DynamicImplementation, а не CORBA::DynamicImplementation Поскольку этот класс является классом серванта, т.е. заведомо зависит от языка программирования, то для него не существует IDL-объявления и спецификация определена на уровне конкретного языка программирования.

CORBA не предусматривает никаких специальных процедур регистрации DSI-серванта - создание сервантов и активация CORBA-объектов никак не зависят от того, на базе какого класса создан ваш класс серванта. Все берет на себя объектный адаптер, т.е. POA.

PortableServer::DynamicImplementation

Использование C++

namespace PortableServer
{
   class DynamicImplementation : public virtual ServantBase
   {
   public:
      Object_ptr _this();
      virtual void invoke (ServerRequest_ptr request) = 0;
      virtual RepositoryId _primary_interface
              	(const ObjectId& oid, POA_ptr poa) = 0;
   };
   ...
}

Метод _this() возвращает объектную ссылку для объекта, которому адресован данный вызов. Вызывать этот метод можно в контексте обработки конкретного запроса, обслуживаемого в режиме DSI.

Для VisiBroker этот метод отсутствует в класса PortableServer::DynamicImplementation просто потому, что он уже реализован в его базовом классе - PortableServer::ServantBase.

Два остальных метода вы должны переопределить сами. Метод invoke() и есть та самая DIR, код которой реализует всю необходимую функциональность серверного объекта. Метод _primary_interface() должен возвращать <самый производный> в иерархии наследования интерфейс, методы которых реализованы в методе invoke().

Как invoke(), так и _primary_interface() НЕ должны вызываться явно программистом - результат такого вызова не определен.