спецификации, руководства, описания, API

Переносимый Объектный Адаптер (POA)

Каков Переносимый Объектный Адаптер (POA)?

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

Позвольте программистам создавать объектные реализации, которые переносимы между различными продуктами ШАРА.
Окажите поддержку для объектов с персистентными идентификационными данными.
Окажите поддержку для прозрачной активации объектов.
Позвольте единственному слуге поддерживать многократные объектные идентификационные данные одновременно.

Этот документ представляет введение в использование POA с Java 2 Платформы, Standard Edition. Для более полного описания POA см. Главу 11 CORBA 2.3.1 Спецификации.

Создание и Используя POA

Шаги для создания и использования POA изменятся согласно определенному разработанному приложению. Следующие шаги обычно происходят во время жизненного цикла POA:

Получите корневой POA
Определите политики POA
Создайте POA
Активируйте POAManager
Активируйте слуг, который может включать активирование Связи
Создайте ссылку на объект из POA

Каждый шаг описывается более подробно в разделах, которые следуют.

Шаг 1: Получите корневой POA

Первый шаг должен получить первый POA, который вызывают rootPOA. Корневым POA управляет ШАР и обеспечивается для приложения, используя интерфейс инициализации ШАРА под начальным именем объекта "RootPOA".

Пример кода, который получит корневой объект POA и бросит его к POA:

      ORB orb = ORB.init( args, null );
      POA rootPOA = POAHelper.narrow(orb.resolve_initial_references("RootPOA"));

Шаг 2: Определите Политики POA

Переносимый Объектный Адаптер (POA) разрабатывается, чтобы обеспечить объектный адаптер, который может использоваться с многократными реализациями ШАРА без необходимой перезаписи, чтобы иметь дело с реализациями различных поставщиков.

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

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

Политика потока: ORB_CTRL_MODEL
Политика продолжительности жизни: ПЕРЕХОДНЫЙ ПРОЦЕСС
Объектная Политика Уникальности Идентификатора: UNIQUE_ID
Политика Присвоения идентификатора: SYSTEM_ID
Политика Задержания слуги: СОХРАНИТЬ
Политика Обработки запросов: USE_ACTIVE_OBJECT_MAP_ONLY
Неявная Политика Активации: IMPLICIT_ACTIVATION

Следующий фрагмент кода показывает, как политики устанавливаются в IIOP RMI (с POA) пример:

      Policy[] tpolicy = new Policy[3];
      tpolicy[0] = rootPOA.create_lifespan_policy(
        LifespanPolicyValue.TRANSIENT );
      tpolicy[1] = rootPOA.create_request_processing_policy(
        RequestProcessingPolicyValue.USE_ACTIVE_OBJECT_MAP_ONLY );
      tpolicy[2] = rootPOA.create_servant_retention_policy(
        ServantRetentionPolicyValue.RETAIN);

Каждая политика обсуждается кратко в следующих темах. Для получения дополнительной информации по политикам POA сошлитесь на Главу 11, Переносимый Объектный Адаптер CORBA/IIOP 2.3.1 Спецификации.

Политика потока

Эта политика определяет модель потоков, используемую с создаваемым POA. Значение по умолчанию ORB_CTRL_MODEL.

ThreadPolicyValue может иметь следующие значения:

ORB_CTRL_MODEL - ШАР ответственен за присвоение запросов на УПРАВЛЯЕМЫЙ ШАРОМ POA к потокам.
SINGLE_THREAD_MODEL - Запросы на однопоточный POA обрабатываются последовательно. (ОТМЕТЬТЕ: Эта политика не поддерживается в ШАРЕ, поставленном с J2SE Sun v.1.4.1 или выше).

Политика продолжительности жизни

Эта политика определяет продолжительность жизни объектов, реализованных в создаваемом POA. Значение по умолчанию TRANSIENT.

LifespanPolicyValue может иметь следующие значения:

TRANSIENT - Объекты, реализованные в POA, не могут пережить экземпляр POA, в котором они сначала создаются.
PERSISTENT - Объекты, реализованные в POA, могут пережить процесс, в котором они сначала создаются.

Объектная Политика Уникальности Идентификатора

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

IdUniquenessPolicyValue может иметь следующие значения:

UNIQUE_ID - Слуги активировались с этим, POA поддерживают точно один Объектный Идентификатор.
MULTIPLE_ID - Слуга активировался, с которым POA может поддерживать один или более Объектных Идентификаторов.

Политика Присвоения идентификатора

Эта политика определяет, сгенерированы ли Объектные Идентификаторы в создаваемом POA приложением или ШАРОМ. Значение по умолчанию SYSTEM_ID.

IdAssignmentPolicyValue может иметь следующие значения:

USER_ID - Объекты, создаваемые, с которым POA присваиваются Объектные Идентификаторы только приложением.
SYSTEM_ID - Объекты, создаваемые, с которым POA присваиваются уникальный объектный идентификатор POA. Если POA также имеет PERSISTENT политика, присвоенные Объектные Идентификаторы должны быть уникальными через все инстанцирования того же самого POA.

Политика Задержания слуги

Эта политика определяет, сохраняет ли создаваемый POA активных слуг в Активной Объектной Карте. Значение по умолчанию RETAIN.

ServantRetentionPolicyValue может иметь следующие значения.

RETAIN - указать, что POA сохранит активных слуг в своей Активной Объектной Карте.
NON_RETAIN - чтобы указать на Слуг не сохраняются POA.

Политика Обработки запросов

Эта политика определяет, как запросы обрабатываются создаваемым POA. Значение по умолчанию USE_ACTIVE_OBJECT_MAP_ONLY.

RequestProcessingPolicyValue может иметь следующие значения:

USE_ACTIVE_OBJECT_MAP_ONLY - Если объектный ID не находится в Активной Объектной Карте, OBJECT_NOT_EXIST исключение возвращается клиенту. RETAIN политика также требуется.
USE_DEFAULT_SERVANT - Если объектный ID не находится в Активной Объектной Карте или NON_RETAIN политика присутствует, и слуга значения по умолчанию был зарегистрирован в POA использование set_servant работа, запрос диспетчеризируется слуге значения по умолчанию.
USE_SERVANT_MANAGER - Если объектный ID не находится в Активной Объектной Карте или NON_RETAIN политика присутствует, и менеджер слуги был зарегистрирован в POA использование set_servant_manager работа, менеджеру слуги дают возможность определить местоположение или активировать слугу или повысить исключение.

Неявная Политика Активации

Эта политика определяет, поддерживается ли неявная активация слуг в создаваемом POA. Значение по умолчанию IMPLICIT_ACTIVATION.

ImplicitActivationPolicyValue может иметь следующие значения:

IMPLICIT_ACTIVATION - Указывает на неявную активацию слуг. Это требует SYSTEM_ID и RETAIN политики, которые будут установлены.
NO_IMPLICIT_ACTIVATION - Не указывает ни на какую неявную активацию слуги.

Шаг 3: Создайте POA

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

POA создается как дочерний элемент существующего POA использование работы create_POA на родительском POA. Чтобы создать новый POA, передайте в следующей информации:

Имя POA. POA дают имя, которое должно быть уникальным относительно всего другого POAs с тем же самым родителем. В следующем примере называют POA childPOA.
Менеджер по POA. Определите менеджера POA, чтобы быть связанными с новым POA. Если, как показывается в следующем примере, null передадут для этого параметра, то новый менеджер POA будет создаваться. Пользователь может также хотеть передавать менеджера POA другого POA.
Список политики. Определите список политики, который будет связан с POA, чтобы управлять его поведением. В следующем примере персистентная политика продолжительности жизни была уже определена для этого POA.

Следующий фрагмент кода показывает, как POA создается в Привет Мир: Персистентный пример Сервера.

// Create a POA by passing the Persistent Policy
POA persistentPOA = rootPOA.create_POA("childPOA", null, 
   persistentPolicy );

Шаг 4: Активируйте POAManager

У каждого объекта POA есть связанное POAManager возразите, что управляет состоянием обработки POAs, с которым оно связывается, такой как, ставятся ли запросы к POA в очередь или отбрасываются. POAManager может также деактивировать POA. Менеджер POA может быть связан с одним или более объектами POA.

POAManager может иметь следующие состояния:

Содержа - В этом состоянии, связанный POAs поставит входящие запросы в очередь.
Активный - В этом состоянии, связанный POAs начнет обрабатывать запросы.
Отбрасывая - В этом состоянии, связанный POAs отбросит входящие запросы.
Неактивный - В этом состоянии, связанный POAs отклонит запросы, которые не начали выполняться так же как любые новые запросы.

POAManagerOperations javadocs содержат больше информации об этих состояниях.

Менеджеры по POA автоматически не активируются, когда они создаются. Следующий фрагмент кода показывает, как POAManager активируется в Привет Мир: Персистентный пример Сервера. Если менеджер POA не активируется таким образом, все звонки Servant зависнет, потому что по умолчанию менеджер POA находится в HOLD состояние.

            // Activate PersistentPOA's POAManager. Without this step,
            // all calls to Persistent Server will hang because POAManager
            // will be in the 'HOLD' state.
            persistentPOA.the_POAManager().activate( );

Шаг 5: Активируйте слуг

Следующая информация заключается в кавычки из раздела 11.2.5 из Спецификации CORBA.

В любом моменте времени объект CORBA может или не может быть связан с активным слугой.

Если POA имеет RETAIN политика, слуга и ее связанный Объектный Идентификатор вводятся в Активную Объектную Карту соответствующего POA. Этот тип активации может быть выполнен одним из следующих способов.

Серверное приложение непосредственно явно активирует отдельные объекты (через activate_object или activate_object_with_id операции).
Серверное приложение сообщает, что POA, чтобы активировать объекты по требованию при наличии POA вызывают предоставленного пользователем менеджера слуги. Серверное приложение регистрирует этого менеджера слуги в set_servant_manager.
При некоторых обстоятельствах (когда IMPLICIT_ACTIVATION политика также в действительности, и привязка к языку позволяет такую работу), POA может неявно активировать объект, когда серверное приложение пытается получить ссылку для слуги, который не уже активен (то есть, не связанный с Объектным Идентификатором).

Если USE_DEFAULT_SERVANT политика также в действительности, серверное приложение сообщает, что POA, чтобы активировать неизвестные объекты при наличии POA вызывают единственного слугу независимо от того, каков Объектный Идентификатор. Серверное приложение регистрирует этого слугу в set_servant.

Если POA имеет NON_RETAIN политика, для каждого запроса, POA может использовать или слугу значения по умолчанию или менеджера слуги, чтобы определить местоположение активного слуги. С точки зрения POA слуга активен только для продолжительности того одного запроса. POA не вводит объектную слугой ассоциацию в Активную Объектную Карту.

При использовании технологии IIOP RMI Ваши реализации используют делегацию (известный как модель Связи), чтобы связать Вашу реализацию с интерфейсом. Когда Вы создаете экземпляр своей реализации, Вы также должны создать объект Связи связать ее с интерфейсом CORBA. Следующий фрагмент кода показывает, как активировать Связь, если политика POA USE_ACTIVE_OBJECT_MAP_ONLY. Этот пример кода от IIOP RMI с примером POA.

_HelloImpl_Tie tie = (_HelloImpl_Tie)Util.getTie( helloImpl );
String helloId = "hello";
byte[] id = helloId.getBytes();
tPOA.activate_object_with_id( id, tie );

Спецификация CORBA обсуждает ссылки на объект создания (раздел 11.2.4), объекты активирования (раздел 11.2.5), и обработка запросов (раздел 11.2.6) более подробно, чем делается в этом документе. Пожалуйста, отошлите к CORBA 2.3.1 Спецификации для получения дополнительной информации.

Шаг 6: Создайте ссылку на объект

Ссылки на объект создаются в серверах. После того, как создаваемый, они могут быть экспортированы в клиенты. Ссылки на объект инкапсулируют объектную информацию об идентификационных данных и информацию, запрошенную ШАРОМ, чтобы идентифицировать и определить местоположение сервера и POA, с которым связывается объект. Ссылки создаются следующими способами:

Явно активируйте слугу и свяжите это со ссылкой на объект.
Следующий пример от Привет Мира: Персистентный Сервер. Этот пример использует servant_to_reference работа, чтобы отобразить активированного слугу ее соответствующей ссылки на объект.
```
// Resolve Root Naming context and bind a name for the
// servant.
org.omg.CORBA.Object obj = orb.resolve_initial_references(
  "NameService" );
NamingContextExt rootContext = NamingContextExtHelper.narrow( obj );

NameComponent[] nc = rootContext.to_name( 
  "PersistentServerTutorial" );
rootContext.rebind( nc, persistentPOA.servant_to_reference( 
  servant ) );
```
Серверное приложение непосредственно создает ссылку.
Следующий пример от IIOP RMI с примером POA. В этом примере следующий код непосредственно создает ссылку. При этом они приносят абстрактный объект в существование, но не связывают это с активным слугой.
```
// Publish the object reference using the same object id
// used to activate the Tie object.
Context initialNamingContext = new InitialContext();
initialNamingContext.rebind("HelloService", 
tPOA.create_reference_with_id(id, 
  tie._all_interfaces(tPOA,id)[0]) );
```
Серверное приложение заставляет слугу неявно активировать себя.
Поведение может произойти, только если POA был создан с IMPLICIT_ACTIVATION политика, которая является поведением значения по умолчанию.

Как только ссылка создается в сервере, это может быть сделано доступным для клиентов. Для получения дополнительной информации по созданию ссылок на объект и экспорту в клиенты, отошлите к разделу 11.2.4 из CORBA 2.3.1 Спецификации для получения дополнительной информации.

Активаторы адаптера

Для приложения в качестве примера, которое использует Активаторы Адаптера, см. Используя Активаторы Адаптера.

Активатор адаптера является дополнительным. Вы использовали бы активатор адаптера, если POAs должен быть создан во время обработки запросов. Если все нуждались в POAs, создаются, когда приложение выполняется, активатор адаптера не требуется.

Активатор адаптера предоставляет POA возможность создать дочерний POAs по требованию как побочный эффект получения запроса, который называет дочерний POA (или один из его дочерних элементов), или когда find_POA метод вызывают с активировать значением параметра ИСТИНЫ. ШАР Вызовет работу на активатор адаптера, когда запрос будет получен для дочернего POA, который в настоящий момент не существует. Активатор адаптера может тогда создать необходимый POA по требованию.

Запрос должен быть способным к передаче Объектного Идентификатора целевого объекта так же как идентификации POA, который создал целевую ссылку на объект. Когда клиент выпускает запрос, ШАР сначала определяет местоположение соответствующего сервера (возможно, запускающийся один если нужно), и затем он определяет местоположение соответствующего POA в пределах того сервера.

Если POA не существует в серверном процессе, у приложения есть возможность воссоздать необходимый POA при использовании активатора адаптера. Активатор адаптера является реализованным пользователем объектом, который может быть связан с POA. Это вызывается ШАРОМ, когда запрос получается для несуществующего дочернего POA. У активатора адаптера есть возможность создать необходимый POA. Если это не делает, клиент получает ADAPTER_NONEXISTENT исключение.

Как только ШАР определил местоположение соответствующего POA, он поставляет запрос этому POA. Дальнейшая обработка того запроса зависит оба от политик, связанных с этим POA так же как текущее состояние объекта активации.

Для получения дополнительной информации по Активаторам Адаптера отошлите к разделу 11.3.3 из CORBA 2.3.1 Спецификации или документация API AdapterActivatorOperations.

Менеджеры слуги

Менеджеры слуги являются дополнительными. Вы использовали бы менеджера слуги, чтобы позволить POA активировать слуг по требованию, когда запрос на неактивный объект получается. Если Ваш сервер загружает все объекты, когда он запускает, Вы не нуждаетесь в менеджере слуги.

Менеджер слуги является объектом обратного вызова, который разработчик приложений может связать с POA. ШАР вызовет операции на менеджеров слуги, чтобы активировать слуг по требованию, и деактивировать слуг. Менеджеры слуги ответственны за управление ассоциацией ссылки на объект (как характеризующийся ее Объектным Значением идентификатора) с определенным слугой, и для того, чтобы определить, существует ли ссылка на объект или нет. Каждый менеджер слуги тип содержит две операции, первое, вызванное, чтобы найти и возвратить слугу и второе, чтобы деактивировать слугу. Операции отличаются согласно количеству информации, применимой для их ситуации.

Использовать менеджеров слуги, USE_SERVANT_MANAGER политика должна быть установлена. После того, как набор, тип менеджера слуги, используемого в определенной ситуации, зависят от других политик в POA. Два типа менеджеров слуги:

ServantActivator
Когда POA имеет RETAIN политика, это использует менеджеров слуги, которые являются ServantActivators.

Этот тип обычно используется, чтобы активировать персистентные объекты.
- Для примера, который использует Активаторы Слуги, см. Используя Активаторы Слуги.
ServantLocator
Когда POA имеет NON_RETAIN политика, это использует менеджеров слуги, которые являются ServantLocators. Поскольку POA знает, что слуга, возвращенный этим менеджером слуги, будет использоваться только для единственного запроса, он может предоставить дополнительную информацию к операциям менеджера слуги, и пара менеджера слуги операций может быть в состоянии сотрудничать, чтобы сделать что-то другое чем a ServantActivator. Когда POA использует ServantLocator интерфейс, сразу после выполнения вызова работы на слуге, возвращенном, предварительно вызывает, POA вызовет, поствызывают на менеджера слуги, передавая значение ObjectId и значение Слуги как параметры (среди других). Эта функция может быть использована, чтобы вынудить каждый запрос на объекты, связанные с POA быть установленным менеджером слуги.

Этот тип обычно используется, чтобы активировать временные объекты.
- Для примера, который использует Локаторы Слуги, см. Используя Локаторы Слуги.

Для получения дополнительной информации по менеджерам Слуги отошлите к разделу 11.3.4 из CORBA 2.3.1 Спецификации.

POA Q&A

`POAManager.activate()` требуется для недавно создаваемого POA?

POAManager.activate() требуется для недавно создаваемого POA, если нуль передают для параметра POAManager к POA::createPOA. Если нуль передают, новый POAManager создается и связывается с создаваемым POA. В этом случае POAManager.activate() необходим.

Чтобы управлять несколькими POAs с тем же самым POAManager, Вы были бы:

Создайте POA или используйте rootPOA
Получите менеджера POA через POA::the_POAManager
Передайте POAManager к последующим вызовам createPOA

Нет никакого неявного отношения между POAManager Корневого POA и другим POAs если явно не программирующийся программистом как показано выше.

Для получения дополнительной информации читайте раздел 11.3.2 из спецификации CORBA, formal/99-10-07.

Для получения дополнительной информации

Для получения дополнительной информации о Переносимом Объектном Адаптере, считайте Главу 11 CORBA/IIOP v.2.3.1 Спецификация от веб-сайта Группы по управлению объектами.

Свяжитесь с Нами