Оптимизированные для WebSphere локальные адаптеры

Оптимизированные локальные адаптеры 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.

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

Обмен сообщениями, например Websphere MQ или другие поставщики JMS.
РМИ / МИОП
Веб-сервисы

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

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

IBM CICS
Пакетные задания
Системные службы UNIX (USS)
Система управления авиакомпанией (ALCS)
IMS (поддержка началась с обслуживания 7.0.0.12)

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

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

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

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

7.0.0.4

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

Поддерживаемый функционал, предложенный в версии 7.0.0.4, был:

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

7.0.0.12

Пакет Fixpack 12 для WAS z/OS версии 7 выпуска 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.

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

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

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

Поиск по информационному центру: cdat_olacustprop

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

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

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

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

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

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

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

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

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

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 должен работать с 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 должен работать с 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 ^{[ нужны разъяснения ]} и Каналы/Контейнеры поддерживаются.

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

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

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

Обзор поддержки 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 снижает накладные расходы, что приводит к повышению производительности и пропускной способности.

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

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

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

Рекомендации по программированию

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

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

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

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

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

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

Если внешним адресным пространством является CICS, то у пользователя есть возможность использовать предоставленную задачу сервера ссылок, чтобы действовать в качестве принимающего агента от имени существующих программных активов CICS. Задача Link Server (по умолчанию BBO$) принимает вызов и выдает EXEC CICS LINK программы, указанной в взаимодействииSpecImpl.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 for z/OS (короткое имя ячейки), а для вызова целевого EJB используются множественные вызовы BBOA1INV. BBOA1INV является синхронным , поэтому управление программой сохраняется до тех пор, пока EJB не вернет ответ. Этот API полезен, когда вызывающая программа заранее знает размер ответного сообщения. Если размер ответного сообщения неизвестен во время вызова, то более подходящими будут более примитивные API (BBOA1SRQ (отправка запроса), BBOA1RCL (получение длины ответа), BBOA1GET (получение данных сообщения)).

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

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

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

Ограничения

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

Внешние ссылки

Redbooks: WebSphere on z/OS — оптимизированные локальные адаптеры
Официальные документы IBM: локальные адаптеры, оптимизированные для WebSphere z/OS
IBM InfoCenter: Планирование использования оптимизированных локальных адаптеров для z/OS
Видеодемонстрации можно посмотреть на YouTube, выполнив поиск по ключевому слову WASOLA1.
Видео на YouTube:
- WP101490 - WOLA - Основы WOLA [1]
- WP101490 - ВОЛА - CICS [2]
- WP101490 - ВОЛА - IMS [3]
- WP101490 – WOLA – Собственные API, часть 1 из 2 [4]
- WP101490 — WOLA — Собственные API, часть 2 из 2 [5]
- WP101490 — WOLA — Особенности Java [6]