Оптимизированные для WebSphere локальные адаптеры - WebSphere Optimized Local Adapters - Wikipedia

Оптимизированные локальные адаптеры IBM WebSphere (OLA или WOLA) является функциональным компонентом IBM с WebSphere Application Server для z / OS который обеспечивает эффективный механизм перекрестной памяти для вызовов как входящих в WAS z / OS, так и исходящих из z / OS. Поскольку он позволяет избежать накладных расходов, связанных с другими механизмами связи, он способен к обмену сообщениями большого объема. WOLA является расширением существующего механизма обмена между памятью WAS z / OS, при этом WOLA предоставляет внешний интерфейс, поэтому адресные пространства z / OS вне сервера WAS z / OS могут участвовать в обменах между памятью. WOLA поддерживает соединение между сервером WAS z / OS и одним или несколькими из следующих компонентов: CICS, IMS, Batch, UNIX Systems Services и ALCS. WOLA впервые стала доступной в WAS z / OS версии 7, Fixpack 4 (7.0.0.4). Функциональные улучшения появились в последующих пакетах исправлений, как описано в этой статье.

История

Оптимизированные локальные адаптеры WebSphere для WAS z / OS (для краткости WOLA или OLA) возникли из желания обеспечить эффективную входящий механизм вызова; то есть из за пределами в Java EE в нее, чтобы использовать ресурсы Java EE. Это требование было особенно ярко выражено в z / OS, где традиционная пакетная обработка требовала использования растущей базы программных ресурсов на основе технологий Java EE и EJB.

Существовали и другие входящие решения, например:

Хотя у каждого были свои сильные стороны; у каждого были свои недостатки: накладные расходы и задержка; сложность в строительстве; или недостатки в модели безопасности или распространения транзакций.

Это был исходный проект для оптимизированных локальных адаптеров. Архитекторы решения расширили дизайн, включив двунаправленные вызовы: входящий в WAS z / OS из внешнего адресного пространства и исходящий из WAS во внешнее адресное пространство.

Техническая основа

Архитекторы этого решения решили использовать существующий элемент конструкции WAS z / OS под названием «локальные коммуникации», механизм перекрестной памяти, используемый WebSphere Application Server для z / OS со времен V4.x, который оптимизирует трафик IIOP между приложениями. серверы на том же LPAR. OLA - это, по сути, экстернализация существующего механизма кросс-памяти, так что адресные пространства за пределами WAS z / OS могут соединяться и обмениваться сообщениями через пространство общей памяти.

Программы внешнего адресного пространства получают доступ к интерфейсу OLA с помощью набора поставляемых API. Программы Java, работающие в WAS z / OS, получают доступ к интерфейсу OLA через реализацию, упакованную как стандартный адаптер ресурсов JCA.

Текущая поддержка

Поддерживаемые в настоящее время внешние адресные пространства Для WAS z / OS OLA поддерживаются:

Языки программирования, поддерживаемые во внешних адресных пространствах:

Java - это язык программирования, используемый для доступа к WAS z / OS OLA из контейнеров Java EE WAS z / OS.

История обновления функции

Поддержка функций IBM WebSphere Optimized Adapters обновляется по мере выпуска новых версий или пакетов исправлений. Эта функция впервые стала доступной в WAS z / OS Version 7 Release 0 Fixpack 4 level (7.0.0.4).

Функциональные обновления, часть 1
Функциональные обновления, часть 3

7.0.0.4

WOLA была представлена ​​с пакетом Fixpack 4 для продукта WAS z / OS Version 7 Release 0. Применение обслуживания привело к созданию нового каталога в файловой системе продукта, в котором находятся модули WOLA, общие объекты, адаптер ресурсов JCA и библиотеки классов разработки. Сценарий оболочки (olaInstall.sh) создает необходимые символические ссылки UNIX из среды выполнения на файловую систему установки продукта.

В версии 7.0.0.4 поддерживаются следующие функции:

  • Поддержка CICS, Batch, USS и ALCS
  • Одноэтапная фиксация исходящего WAS в CICS (2PC в CICS TS 4.1, поставляемый с 7.0.0.12)
  • Двухфазная фиксация для входящего CICS в WAS
  • Собственные API
  • Адаптер ресурсов JCA

7.0.0.12

Пакет Fixpack 12 для WAS z / OS версии 7 Release 0 предоставил два обновления для поддержки WOLA:

  • Поддержка WOLA и IMS
  • Обработка транзакции двухфазной фиксации от исходящего WAS до CICS TS 4.1

8.0.0.0

WebSphere Application Server для z / OS версии 8, выпуск 0 продолжил поддержку оптимизированных локальных адаптеров WebSphere. WOLA входила в состав продукта, а это означало, что запуск olaInstall.sh больше не требовался для создания символических ссылок UNIX на файлы продукта. Кроме того, были предоставлены следующие обновления функций:

  • Поддержка многосегментных больших сообщений (размером более 32К) для работы с IMS
  • Поддержка классификации входящих транзакций для вызовов WOLA отдельно от вызовов IIOP
  • Идентификация в записи SMF 120.9 для вызовов WOLA как WOLA, а не IIOP
  • Идентификация сбоя ресурса и альтернативное аварийное переключение JNDI

Восстановление и восстановление ресурсов

Эта функция предоставляет средства обнаружения потери ресурса данных, подключенного к фабрике соединений JCA, и автоматического переключения на определенный альтернативный JNDI. Обнаружение восстановления первичных ресурсов данных и восстановления после сбоя также является элементом этой функциональной схемы. Схема аварийного переключения ресурсов присутствует в WebSphere Application Server версии 8 на всех платформах для JDBC и JCA. WAS z / OS версии 8 обеспечивает поддержку аварийного переключения ресурсов WOLA как часть общей поддержки аварийного переключения ресурсов JCA. Вызов аварийного переключения происходит, когда возникает настраиваемое пороговое количество сбоев getConnection (). После вызова аварийного переключения все новые запросы getConnection () направляются в альтернативный пул соединений фабрики соединений. Восстановление после сбоя происходит, когда WAS z / OS определяет, что отказавший первичный ресурс данных вернулся. Новые запросы getConnection () обрабатываются в отношении основной фабрики соединений.

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

Несколько настраиваемых свойств пула соединений были добавлены для поддержки этого механизма аварийного переключения ресурсов и восстановления после сбоя:

  • failureThreshold - количество последовательных сбоев getConnection (), которые должны произойти до того, как будет запущена автоматическая отработка отказа
  • alternateResourceJNDIName - JNDI-имя альтернативной фабрики соединений, которое будет использоваться, если запущено автоматическое переключение при отказе
  • resourceAvailabilityTestRetryInterval - интервал в секундах, используемый WAS для проверки возврата первичного ресурса

Примечание: для этой функции существуют другие настраиваемые свойства пула соединений. Найдите полный список по строке "cdat_dsfailover" в информационном центре WAS z / OS.

8.0.0.1 / 8.5.0.0

Примечание: WAS z / OS 8.5.0.0 обеспечивает поддержку WOLA, функционально идентичную 8.0.0.1

Пакет Fixpack 1 для WebSphere Application Server для z / OS версии 8 предоставил следующие функциональные обновления WOLA:

  • 64-битные вызываемые собственные API-интерфейсы для программ C / C ++, работающих в 64-битном режиме
  • SMF 120 подтип 10 записей для WOLA исходящий звонки из WAS (SMF 120 подтип 9 захватывает информацию о входящих звонках)
  • Распределение работы - возможность циклического перебора исходящих вызовов между несколькими внешними регистрациями с одним и тем же именем
  • Поддержка прокси для удаленного доступа - это может быть две формы: входящая и исходящая.

64-битные вызываемые собственные модули API

До версии 8.0.0.1 собственные модули API поставлялись только в 31-битном вызываемом формате. Эти модули имели четырехзначный префикс BBOA *, связанный с каждым именем модуля.

В версии 8.0.0.1 доступны как 31-битные, так и 64-битные вызываемые модули API. 31-битные модули сохраняют четырехзначный префикс BBOA * для каждого имени модуля. 64-битные модули имеют четырехзначный префикс BBGA * для каждого имени модуля.

Количество API осталось прежним: 13 конкретных API. Использование такое же, как и раньше.

Инфоцентр Поиск: cdat_olaapis

SMF 120.10 для исходящих вызовов WOLA

В WAS z / OS V7 поддержка WOLA для SMF была ограничена входящий только звонки. Входящие вызовы WOLA к целевым EJB в контейнере WAS z / OS были идентифицированы как вызовы IIOP и перехвачены SMF как вызовы IIOP, неотличимые от любых других вызовов IIOP. Обычная запись WAS z / OS SMF 120 подтипа 9 (или 120.9 в сокращенной записи) использовалась для захвата информации о входящем вызове.

В WAS z / OS 8.0.0.0 функция записи и захвата SMF 120.9 была изменена для идентификации входящих вызовов WOLA отдельно от входящих вызовов IIOP.

В WAS z / OS 8.0.0.1 запись SMF 120.10 была создана для сбора информации о исходящий звонки из WAS z / OS. Запись SMF 120.10 состоит из восьми разделов:

  • Раздел информации о нейтральном к платформе сервере
  • Раздел информации о сервере z / OS
  • Раздел информации об исходящих запросах
  • Раздел, посвященный типу исходящего запроса WOLA
  • Раздел контекста транзакции исходящего запроса
  • Раздел контекста безопасности исходящего запроса
  • Раздел контекста CICS для исходящих запросов
  • Раздел, посвященный типу исходящего запроса OTMA

Для каждого исходящего запроса создается одна запись.

Инфоцентр Поиск: rtrb_SMFsubtype10

Распределение работы

Это функциональное обновление предоставляет возможность распределять исходящие вызовы по нескольким внешним адресным пространствам, зарегистрированным на данном сервере WAS z / OS с одним и тем же регистрационным именем. Обычным шаблоном использования для этого будет несколько регионов CICS с одной и той же развернутой службой целевой программы без сохранения состояния. Была создана новая переменная среды, чтобы указать тип желаемого распределения работы. Ниже показано использование этой функции:

OLA Work Distribution.jpg

Инфоцентр Поиск: cdat_olacustprop

Поддержка прокси: входящие и исходящие

Характер обмена данными WOLA между памятью подразумевает, что сервер WAS z / OS и внешнее адресное пространство должны находиться в одном логическом разделе z / OS (LPAR). WAS z / OS 8.0.0.1 предоставляет функцию прокси, позволяющую размещать вызывающие WOLA и целевые объекты WOLA отдельно. Это включает расположение в экземплярах операционной системы, отличных от z / OS. Эта функция имеет два формата: поддержка прокси для исходящий звонки и поддержка прокси для входящий звонки.

Поддержка прокси для исходящих вызовов

Это обеспечивает механизм, с помощью которого приложения Java могут использовать поставляемый адаптер ресурсов WOLA JCA для доступа к целевому адресному пространству на удаленной z / OS. Примером использования может быть разработка или тестирование предлагаемого приложения. Доступ к WOLA-соединению между памятью в целевой системе z / OS обеспечивается прилагаемым прокси-приложением WOLA, установленным на сервере WAS z / OS, на котором включена WOLA. На следующем рисунке показана топология:

OLA Proxy Outbound Calls.jpg

Сетевой поток от приложения к системе WAS z / OS осуществляется через IIOP. Фабрика соединений WOLA информируется об этом потоке IIOP к прокси-серверу посредством нескольких новых настраиваемых свойств для пула соединений. Прокси-приложение в WAS z / OS принимает вызов и перенаправляет его через фактическое соединение WOLA между памятью в названную целевую службу.

Эта топология имеет ограничения по сравнению с исходящими вызовами WOLA в том же z / OS LPAR: глобальные транзакции, требующие двухфазной фиксации, не могут передаваться через соединение IIOP на прокси WOLA, а идентификатор пользователя в потоке WAS не может быть подтвержден в целевой сервис на z / OS.

Поддержка прокси для входящих вызовов

Это обеспечивает механизм, с помощью которого приложения, отличные от Java, во внешнем адресном пространстве могут выполнять входящие вызовы к целевому EJB с поддержкой WOLA в удаленном экземпляре WAS либо на другом LPAR z / OS, либо на распределенной платформе WAS. То же самое прилагаемое прокси-приложение WOLA, установленное в локальном экземпляре WAS z / OS, требуется для обработки начального вызова WOLA между памятью и пересылки его в указанный целевой EJB на удаленном экземпляре WAS. На следующем рисунке показана топология:

OLA Proxy Inbound Calls.jpg

Целевой EJB с поддержкой WOLA не знает, что прокси используется. Входящий поток поступает как вызов IIOP, как и в случае использования WOLA между памятью на том же LPAR. Вызывающая программа должна указать, что поток будет использовать прокси-службу. Это делается с параметром BBOA1INV (или BBOA1SRQ) равным 2 для параметра типа запроса. Это указывает локальному прокси-приложению обрабатывать запрошенную службу, которая указана как имя JNDI целевого EJB, как запрос на вызов EJB с использованием IIOP. Для этого требуется, чтобы локальные и удаленные экземпляры WAS имели объединенные пространства имен или работали как одна ячейка для успешного поиска JNDI.

8.0.0.3 и 8.0.0.4 / 8.5.0.1

В 8.0.0.3 (и 8.5.0.1) поддержка WOLA включена в IBM Integration Designer для процессов BPEL.

В 8.0.0.4 (и 8.5.0.1) поддержка обновлена, чтобы включить утверждение контекста транзакции RRS из зависимых регионов IMS в WAS через WOLA:

  • Приложения в IMS устанавливают флаг "транзакция поддерживается" в регистре API.
  • В целевой среде WAS установлена ​​и включена переменная среды ola_rrs_context_propagate = 1.
  • IMS Control Region должен работать с RRS = Y

8.0.0.5 (и 8.5.0.2)

Fixpack 8.0.0.5 / 8.5.0.2 предоставляет два функциональных улучшения: (1) утверждение контекста транзакции RRS из WAS в IMS через WOLA / OTMA и (2) расширенную поддержку каналов и контейнеров CICS.

Для транзакции IMS:

  • IMS Control Region должен работать с RRS = Y
  • В целевой среде WAS установлена ​​и включена переменная среды ola_rrs_context_propagate_otma = 1.

Для расширенной поддержки каналов и контейнеров CICS до версии 8.0.0.5 / 8.5.0.2 поддержка каналов и контейнеров CICS была ограничена одним каналом с фиксированным именем для запроса и ответа и одним контейнером типа BIT или CHAR. С 8.0.0.5 / 8.5.0.2:

  • Отправлять и получать один или несколько контейнеров из целевой программы CICS
  • Имя канала задается вами с помощью метода setLinkTaskChanID ()
  • Тип канала устанавливается вами с помощью метода setLinkTaskChanType ()
  • Имена отдельных контейнеров запросов устанавливаются путем добавления данных в MappedRecord с помощью метода put ().
  • Ключи MappedRecord соответствуют именам контейнеров CICS, и соответствующее значение будет использоваться для заполнения контейнера в CICS.
  • Имена контейнеров ответа будут извлечены из канала после завершения запроса CICS и внесены в новую запись MappedRecord, которая возвращается клиенту.

Составные части

Оптимизированные локальные адаптеры можно разделить на следующие компоненты:

  • Интерфейсные модули - предоставить программный доступ к интерфейсу OLA и API OLA
  • CICS Пользовательский выход, связанный с задачей, связать сервер задач и управляющая транзакция - предоставляет упрощенный механизм для поддержки исходящих вызовов программных ресурсов в CICS.
  • JCA Адаптер ресурсов - обеспечивает интерфейс между средой Java и внешней средой
  • Поддержка инструментов разработки - предоставляет вспомогательные классы для разработки приложений с поддержкой OLA
  • Образцы - набор примеров C / C ++, COBOL и Java, иллюстрирующих использование модели программирования

Обзор поддержки CICS

Оптимизированные локальные адаптеры реализованы в CICS как пользовательский выход, связанный с задачами (TRUE). Это то, что обеспечивает необходимое соединение перекрестной памяти CICS с адресным пространством WAS z / OS.

Кроме того, для вызовов от WAS к CICS предоставляется задача сервера связи (BBO $) и задача вызова ссылки (BBO #). Задача сервера ссылок BBO $ / BBO # защищает особенности программирования от программ CICS. Вызов OLA из WAS обрабатывается этими предоставленными задачами, а названная программа CICS вызывается со стандартным EXEC CICS LINK звонок. Названная программа CICS остается неизменной и не знает, что вызов пришел от WAS, использующего OLA. Целевая программа в CICS должна иметь возможность вызывать с помощью вызова LINK. Оба COMMAREA[требуется разъяснение ] и каналы / контейнеры поддерживаются.

WOLA-Link-Server.jpg

Транзакция BBOC также предоставляется для предоставления набора команд управления для выполнения таких действий, как запуск вручную TRUE (если не в PLTPI), остановка TRUE, запуск и остановка Link Server, а также другие функции контроля и управления.

Набор данных библиотеки модуля интерфейса программирования OLA должен быть объединен с оператором DFHRPL DD области CICS.

На следующем рисунке показана поддержка WOLA CICS для распространения транзакций и утверждения безопасности:

CICS-TX-Sec.jpg

Обзор поддержки IMS

Оптимизированные локальные адаптеры реализованы как внешняя подсистема для IMS. Поддерживается использование программ обработки сообщений (MPP), программ пакетной обработки сообщений (BMP), IMS Fast Path (IFP) и пакетных приложений DL / I.

Вызовы из IMS в WAS используют средство подключения внешней подсистемы (ESAF). Это тот же интерфейс, который используется другими подсистемами, такими как DB2 или MQ.

Вызовы из WAS в зависимую от IMS область могут выполняться с использованием OTMA или напрямую (то есть программа в IMS использует API OLA для "размещения службы", как описано ниже). OTMA обеспечивает прозрачность OLA для приложений IMS за счет некоторых накладных расходов. Использование API OLA в приложении IMS снижает накладные расходы, что приводит к повышению производительности и пропускной способности.

WOLA-IMS-Overview.jpg

Программные API для IMS такие же формат и синтаксис как было введено изначально. Но они были обновлены, чтобы знать об IMS, если они там работают, и использовать ESAF.

Кроме того, для использования с IMS файл ola.rar, реализующий адаптер ресурсов JCA для WAS, должен поставляться с Fixpack 7.0.0.12 или новее. Параметры метода были обновлены для поддержки IMS, и это обновление стало доступным для WAS путем переустановки ola.rar, поставляемого с 7.0.0.12.

На следующем рисунке показана поддержка WOLA IMS для распространения транзакций и утверждения безопасности:

IMS-TX-Sec3.jpg

Соображения по программированию

Входящий в WAS z / OS

Внешнее адресное пространство обращается к механизму OLA через поставляемые интерфейсные модули и задокументированные API. В настоящее время существует 13 API. Они разделены на категории ниже.

Программы Java, работающие в среде WAS z / OS, которые хотят быть целью вызова извне, должны реализовать интерфейс OLA в сеансовом компоненте без сохранения состояния, используя файлы классов OLA, предоставленные в составе поддержки инструментов разработки.

Исходящий из WAS z / OS

Программа Java, желающая инициировать исходящий вызов OLA, может быть реализована либо как сервлет, либо как EJB. Программные коды Java для поставляемого адаптера ресурсов JCA (ola.rar) с использованием файлов классов, поставляемых в составе поддержки инструментов разработки.

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

  • Если внешнее адресное пространство - это CICS, то у пользователя есть возможность использовать предоставленную задачу Link Server Task, чтобы действовать как принимающий агент от имени существующих программных активов CICS. Задача Link Server (BBO $ по умолчанию) принимает вызов и выдает EXEC CICS LINK программы, названной в InteractionSpecImpl.setServiceName (). Никаких изменений в существующей программе CICS не требуется, если она поддерживает COMMAREA или каналы / контейнеры.
  • Если внешний адрес - IMS, то вызов может быть выполнен с использованием интерфейса IMS OTMA (что не подразумевает никаких изменений в вашем приложении IMS) или напрямую с использованием OLA (что подразумевает использование API OLA в программе IMS для «размещения службы». ).
  • Если внешнее адресное пространство отличается от CICS или IMS, тогда программе необходимо «разместить службу» с помощью одного из предоставленных API. Это переводит программу в состояние готовности к приему вызова из программы Java в WAS z / OS. Когда вызов получен, он может обработать запрос и вернуть ответ программе Java в WAS z / OS.

Синхронные и асинхронные операции

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

Модульная конструкция

Можно спроектировать программные артефакты, специфичные для OLA, в качестве «мостов» между интерфейсом OLA и существующими активами. Это позволяет минимизировать влияние на существующие программные ресурсы и ограничивает степень «привязки к платформе».

  • Исходящий к CICS - используйте предоставленную реализацию Link Server; никаких изменений в ваших программах CICS.
  • Входящий в WAS - создайте EJB, который принимает вызов OLA, затем поворачивает и вызывает указанный EJB. Если целевой EJB находится в той же JVM, он может быть очень эффективным. Если целевой EJB находится в той же ячейке на том же LPAR, тогда используется ранее упомянутая функция «локальной связи».

API

Существует 13 API-интерфейсов, разделенных на следующие категории:

  • Общая настройка и разборка - BBOA1REG (регистрация) и BBOA1URG (отмена регистрации)
  • Входящий базовый - BBOA1INV (вызов с автоматическим получением ответа)
  • Входящий Расширенный - BBOA1CNG (получить соединение), BBOA1SRQ (отправить запрос), BBOA1RCL (получить длину ответа), BBOA1GET (получить данные сообщения), BBOA1CNR (освободить соединение)
  • Исходящий базовый - BBOA1SRV (хост сервис), BBOA1SRP (отправить ответ)
  • Исходящий Расширенный - BBOA1RCA (получение при любом соединении), BBOA1RCS (получение при конкретном соединении), BBOA1GET (получение данных сообщения), BBOA1SRP (отправка ответа) и BBOA1SRX (отправка исключения)

Инфоцентр имеет полную запись каждого из них вместе со списками параметров, кодами возврата (RC) и кодами причин (RSN). Ищите на cdat_olaapis.

Иллюстрации общих шаблонов API

Обычный входящий Модель использования API будет:

Простой

В этом случае API BBOA1REG используется для регистрации в группе демонов WebSphere Application Server для z / OS (краткое имя ячейки), а для вызова целевого EJB используются несколько вызовов BBOA1INV. BBOA1INV - это синхронный поэтому управление программой сохраняется до тех пор, пока EJB не вернет ответ. Этот API полезен, когда вызывающая программа заранее знает размер ответного сообщения. Если размер ответного сообщения неизвестен во время вызова, то более подходящими будут более примитивные API (BBOA1SRQ (запрос отправки), BBOA1RCL (получение длины ответа), BBOA1GET (получение данных сообщения)).

Когда вызывающая программа определяет, что она завершила свою работу, она использует BBOA1URG для отмены регистрации в группе Daemon.

Если целевая программа Java имеет более длительный интервал ответа, то асинхронный модель скорее всего лучше. На следующем рисунке показано, как будет выполняться асинхронный вызов с использованием так называемого примитивный API: BBOA1SRQ с набором параметров async = 1:

OLA More Advanced Inbound API.jpg

Как показано на рисунке, асинхронный режим позволяет программе, отличной от Java, получать управление и выполнять другие операции. Это подразумевает проверку ответа в будущем. Для этого используется BBOA1RCL. В этом примере выдается BBOA1RCL синхронно (параметр async = 0). Если ответ доступен, BBOA1RCL предоставит длину, и управление программой вернется к программе. Если ответа нет, BBOA1RCL сохраняет управление программой до тех пор, пока он не станет доступен. BBOA1RCL с async = 1 вернет x'FFFFFFFF ', если ответ недоступен; программное управление возвращается немедленно.

Другие иллюстрации для исходящий можно найти в документе WP101490 на веб-сайте IBM Techdocs.

Примечание: Исходящий из WAS в CICS будет нет требуется кодирование API. В этом случае эту обработку будут выполнять предоставленные транзакции сервера ссылок BBO $ / BBO #. Эти транзакции сервера ссылок «размещают службу», используя внутренние конструкции, аналогичные API BBOA1SRV. Для исходящего трафика в пакетную программу потребуется использование API для «размещения службы».

Транзактность

Оптимизированные локальные адаптеры поддерживают обработку двухфазной фиксации (2PC) от входящего CICS к WAS.

С появлением обновления 7.0.0.12 оптимизированные локальные адаптеры также поддерживают двухфазную фиксацию исходящего трафика от WAS к CICS. До 7.0.0.12 поддержка транзакций от WAS к CICS была ограничена «синхронизацией при возврате».

Для IMS поддержка транзакционных подтверждений, входящих в WAS из зависимых регионов IMS, была предоставлена ​​в пакетах исправлений 8.0.0.4 и 8.5.0.1. Исходящее подтверждение транзакции от WAS к IMS через WOLA / OTMA, предоставленное в пакете исправлений 8.0.0.5.

Транзакционное распространение не поддерживается для входящих и исходящих пакетов, USS или Airlines Line Control.

Безопасность

Оптимизированные локальные адаптеры могут подтверждать идентичность в следующих случаях:

  • WAS -> CICS: идентификатор в потоке WAS, используемый для вызова WOLA API, может использоваться для подтверждения идентичности в CICS. Для этого необходимо использовать сервер ссылок WOLA CICS и запустить его с параметром SEC = Y, а регион CICS должен работать с SEC = YES, а идентификатор, под которым запускается задача сервера ссылок, должен иметь полномочия SURROGAT SAF для запуска транзакций. от имени распространенного идентификатора пользователя. Обратитесь к IBM InfoCenter за дополнительной информацией по этому поводу.
  • WAS -> Batch, USS или ALCS: попыток подтверждения личности не предпринимается. Целевой процесс работает под идентификатором, использованным при его запуске.
  • CICS -> WAS: CICS может подтвердить свой идентификатор региона или идентификатор пользователя приложения
  • Пакетный, USS или ALCS: внешний процесс попытается подтвердить свою личность в WAS z / OS.

Ограничения

Оптимизированные локальные адаптеры WAS z / OS могут использоваться только в пределах определенного LPAR. Это механизм перекрестной памяти, который не может перемещаться между разделами LPAR или за пределами машины.

внешняя ссылка