Spec-Zone .ru
спецификации, руководства, описания, API
Содержание документации

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

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

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

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

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

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

  1. Получите корневой POA
  2. Определите политики POA
  3. Создайте POA
  4. Активируйте POAManager
  5. Активируйте слуг, который может включать активирование Связи
  6. Создайте ссылку на объект из 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 есть следующие политики по умолчанию:

Следующий фрагмент кода показывает, как политики устанавливаются в 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 может иметь следующие значения:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

POA создается как дочерний элемент существующего POA использование работы create_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 может иметь следующие состояния:

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. Этот тип активации может быть выполнен одним из следующих способов.

Если 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, с которым связывается объект. Ссылки создаются следующими способами:

Как только ссылка создается в сервере, это может быть сделано доступным для клиентов. Для получения дополнительной информации по созданию ссылок на объект и экспорту в клиенты, отнеситесь, чтобы разделить 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. Два типа менеджеров слуги:

Для получения дополнительной информации по менеджерам Слуги отнеситесь, чтобы разделить 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, Вы были бы:

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

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

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

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

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

Oracle и/или его филиалы Авторское право © 1993, 2011, Oracle и/или его филиалы. Все права защищены.
Свяжитесь с Нами