IBM WebSphere Optimized Local Adapters (OLA o WOLA) es un componente funcional de WebSphere Application Server de IBM para z/OS que proporciona un mecanismo eficaz de memoria cruzada para llamadas entrantes a WAS z/OS y salientes desde z/OS. Debido a que evita la sobrecarga de otros mecanismos de comunicación, es capaz de intercambiar mensajes en gran volumen. WOLA es una extensión del mecanismo de intercambio de memoria cruzada existente de WAS z/OS, y proporciona una interfaz externa para que los espacios de direcciones z/OS fuera del servidor WAS z/OS puedan participar en intercambios de memoria cruzada. WOLA admite la conectividad entre un servidor WAS z/OS y uno o más de los siguientes: CICS, IMS, Batch, UNIX Systems Services y ALCS. WOLA se puso a disposición por primera vez en WAS z/OS versión 7, Fixpack 4 (7.0.0.4). Han aparecido mejoras funcionales en los fixpacks posteriores, como se documenta en este artículo.
Los adaptadores locales optimizados de WebSphere para WAS z/OS (WOLA u OLA para abreviar) tienen su origen en el deseo de proporcionar un mecanismo de llamadas entrantes eficiente ; es decir, desde fuera del entorno Java EE hacia él para utilizar los activos de Java EE. Este requisito era particularmente pronunciado en z/OS, donde el procesamiento por lotes tradicional buscaba el uso de una base creciente de activos de programación basados en tecnología Java EE y EJB.
Existían otras soluciones inbound, por ejemplo:
Si bien cada uno tenía sus respectivas fortalezas, también tenía sus defectos particulares: sobrecarga y latencia, dificultad en la construcción o deficiencias en el modelo de seguridad o propagación de transacciones.
Este fue el punto de diseño original de los adaptadores locales optimizados. Los arquitectos de la solución ampliaron el diseño para incluir invocaciones bidireccionales: entrantes a WAS z/OS desde un espacio de direcciones externo y salientes desde WAS a un espacio de direcciones externo.
Los arquitectos de esta solución decidieron aprovechar un elemento existente del diseño de WAS z/OS denominado "comunicaciones locales", un mecanismo de memoria cruzada utilizado por WebSphere Application Server para z/OS desde la versión V4.x que optimizaba el tráfico IIOP entre servidores de aplicaciones en la misma LPAR. OLA es esencialmente una externalización de ese mecanismo de memoria cruzada existente para que los espacios de direcciones fuera de WAS z/OS puedan conectarse e intercambiar mensajes a través de un espacio de memoria compartido.
Los programas de espacio de direcciones externas acceden a la interfaz OLA mediante un conjunto de API suministradas. Los programas Java que se ejecutan en WAS z/OS acceden a la interfaz OLA mediante una implementación empaquetada como un adaptador de recursos JCA estándar.
Los espacios de direcciones externas admitidos actualmente para WAS z/OS OLA son:
Los lenguajes de programación soportados en los espacios de direcciones externas son:
Java es el lenguaje de programación utilizado para acceder a WAS z/OS OLA desde dentro de los contenedores Java EE de WAS z/OS.
La compatibilidad de la función IBM WebSphere Optimized Adapters se ha actualizado a medida que se lanzan nuevas versiones o paquetes de correcciones. La función se puso a disposición por primera vez en WAS z/OS Versión 7 Release 0 Fixpack nivel 4 (7.0.0.4).
WOLA se introdujo con Fixpack 4 en el producto WAS z/OS versión 7 Release 0. La aplicación del mantenimiento dio como resultado un nuevo directorio en el sistema de archivos del producto que proporcionaba los módulos WOLA, los objetos compartidos, el adaptador de recursos JCA y las bibliotecas de clases de desarrollo. Un script de shell (olaInstall.sh) creó los enlaces simbólicos UNIX necesarios desde el entorno de ejecución al sistema de archivos de instalación del producto.
Las funciones admitidas en la versión 7.0.0.4 fueron:
Fixpack 12 para WAS z/OS versión 7 lanzamiento 0 proporcionó dos actualizaciones al soporte de WOLA:
WebSphere Application Server para z/OS versión 8 Release 0 siguió ofreciendo compatibilidad con los adaptadores locales optimizados de WebSphere. WOLA se envió incorporado al producto, lo que significa que ya no era necesario ejecutar olaInstall.sh para crear enlaces simbólicos de UNIX a los archivos del producto. Además, se proporcionaron las siguientes actualizaciones de funciones:
Esta función proporciona un medio para detectar la pérdida de un recurso de datos asociado a una fábrica de conexión JCA y realizar una conmutación por error automática a un JNDI alternativo definido. La detección de la recuperación y conmutación por error de recursos de datos primarios también es un elemento de este diseño funcional. El diseño de conmutación por error de recursos está presente en WebSphere Application Server versión 8 en todas las plataformas para JDBC y JCA. WAS z/OS versión 8 proporciona soporte para la conmutación por error de recursos WOLA como parte del soporte general para la conmutación por error de recursos JCA. La invocación de la conmutación por error se produce cuando se produce un número umbral configurable de errores de getConnection(). Después de que se invoca la conmutación por error, todas las nuevas solicitudes getConnection() se enrutan al grupo de conexiones de la fábrica de conexión alternativa. La conmutación por error se produce cuando WAS z/OS determina que el recurso de datos primario fallido ha regresado. Las nuevas solicitudes getConnection() se procesan contra la fábrica de conexión primaria.
Un patrón de uso común para esta función es el de salida a CICS, donde la región de CICS de destino es una región de enrutamiento. Esta función de conmutación por error proporciona la capacidad de diseñar múltiples regiones de enrutamiento de modo que la pérdida de una sola región de enrutamiento no afecte la disponibilidad general de CICS.
Se agregaron varias propiedades personalizadas del grupo de conexiones para admitir este mecanismo de conmutación por error y recuperación de recursos:
failureThreshold- la cantidad de fallas getConnection() consecutivas que deben ocurrir antes de que se invoque la conmutación por error automáticaalternateResourceJNDIName- el nombre JNDI de la fábrica de conexión alternativa que se utilizará si se invoca la conmutación por error automáticaresourceAvailabilityTestRetryInterval - el intervalo en segundos que WAS emplea para probar el retorno del recurso primarioNota: existen otras propiedades personalizadas del grupo de conexiones para esta función. Busque la cadena "cdat_dsfailover" en el Centro de información de WAS z/OS para obtener una lista completa.
Nota: WAS z/OS 8.5.0.0 proporciona compatibilidad con WOLA funcionalmente idéntica a 8.0.0.1
El Fixpack 1 de WebSphere Application Server para z/OS versión 8 proporcionó las siguientes actualizaciones funcionales a WOLA:
Antes de la versión 8.0.0.1, los módulos API nativos se suministraban únicamente en formato de 31 bits que se podía llamar. Estos módulos tenían el prefijo de cuatro caracteres BBOA* asociado con cada nombre de módulo.
Con la versión 8.0.0.1 se proporcionan módulos API invocables de 31 y 64 bits. Los módulos de 31 bits conservan el prefijo de cuatro caracteres BBOA* para cada nombre de módulo. Los módulos de 64 bits llevan el prefijo de cuatro caracteres BBGA* para cada nombre de módulo.
El número de API sigue siendo el mismo que antes: 13 API específicas. El uso es el mismo que antes.
Búsqueda en el InfoCentro: cdat_olaapis
En WAS z/OS V7, la compatibilidad de WOLA con SMF se limitaba únicamente a las llamadas entrantes . Las llamadas WOLA entrantes a los EJB de destino en el contenedor WAS z/OS se identificaban como llamadas IIOP y SMF las capturaba como llamadas IIOP, indistinguibles de cualquier otra llamada IIOP. Se utilizó el registro normal WAS z/OS SMF 120 subtipo 9 (o 120.9 en notación abreviada) para capturar la información de las llamadas entrantes.
Con WAS z/OS 8.0.0.0 se modificó la función de registro y captura de SMF 120.9 para identificar las llamadas WOLA entrantes por separado de las llamadas IIOP entrantes.
Con WAS z/OS 8.0.0.1 se creó el registro SMF 120.10 para capturar información sobre llamadas salientes desde WAS z/OS. El registro SMF 120.10 tiene ocho secciones:
Se crea un registro para cada solicitud saliente.
Búsqueda del InfoCenter: rtrb_SMFsubtype10
Esta actualización funcional brinda la capacidad de distribuir llamadas salientes a través de múltiples espacios de direcciones externas registrados en un servidor WAS z/OS determinado utilizando el mismo nombre de registro. Un patrón de uso común para esto sería implementar múltiples regiones CICS con el mismo servicio de programa de destino sin estado. Se creó una nueva variable de entorno para indicar el tipo de distribución de trabajo deseada. A continuación, se ilustra el uso de esta función:
Búsqueda en el InfoCenter: cdat_olacustprop
La naturaleza de memoria cruzada de las comunicaciones WOLA implica que el servidor WAS z/OS y el espacio de direcciones externo deben estar en la misma partición lógica z/OS (LPAR). WAS z/OS 8.0.0.1 proporciona una función de proxy para permitir que los llamadores y los destinos WOLA se ubiquen por separado. Esto incluye la ubicación en instancias del sistema operativo distintas de z/OS. Esta función tiene dos formatos: compatibilidad con proxy para llamadas salientes y compatibilidad con proxy para llamadas entrantes .
Esto proporciona un mecanismo mediante el cual las aplicaciones Java pueden utilizar el adaptador de recursos JCA de WOLA suministrado para acceder a un espacio de direcciones de destino en z/OS remoto. Un ejemplo de patrón de uso sería el desarrollo o prueba de una aplicación propuesta. El acceso a la conexión WOLA entre memorias en el sistema z/OS de destino se proporciona mediante una aplicación proxy WOLA suministrada instalada en un servidor WAS z/OS habilitado para WOLA. La siguiente imagen ilustra la topología:
El flujo de red desde la aplicación al sistema WAS z/OS se realiza mediante IIOP. La fábrica de conexiones WOLA recibe información de este flujo IIOP al proxy mediante varias propiedades personalizadas nuevas en el grupo de conexiones. La aplicación proxy en WAS z/OS recibe la llamada y la reenvía a través de una conexión WOLA entre memorias real al servicio de destino designado.
Esta topología tiene limitaciones en comparación con las llamadas WOLA salientes en el mismo LPAR z/OS: las transacciones globales que requieren confirmación en dos fases no se pueden propagar a través de la conexión IIOP al proxy WOLA, y la identidad del usuario en el hilo WAS no se puede afirmar en el servicio de destino en z/OS.
Esto proporciona un mecanismo mediante el cual las aplicaciones que no son Java en un espacio de direcciones externo pueden realizar llamadas entrantes a un EJB de destino habilitado para WOLA en una instancia WAS remota, ya sea en otra LPAR z/OS o en una plataforma WAS distribuida. La misma aplicación proxy WOLA suministrada instalada en una instancia WAS z/OS local es necesaria para manejar la llamada WOLA inicial entre memorias y reenviarla al EJB de destino designado en la instancia WAS remota. La siguiente imagen ilustra la topología:
El EJB de destino habilitado para WOLA no sabe que el proxy está en uso. El flujo entrante llega como una llamada IIOP, tal como lo hace si se utilizó WOLA entre memorias en la misma LPAR. El programa que realiza la llamada debe indicar que el flujo utilizará el servicio proxy. Esto se hace con un parámetro en BBOA1INV (o BBOA1SRQ) de 2 para el parámetro requesttype. Esto le indica a la aplicación proxy local que trate el servicio solicitado, que se especifica como el nombre JNDI del EJB de destino, como una solicitud para invocar el EJB mediante IIOP. Esto requiere que las instancias WAS locales y remotas tengan espacios de nombres federados o funcionen como una sola celda para que la búsqueda JNDI tenga éxito.
En 8.0.0.3 (y 8.5.0.1) se incluye soporte WOLA en IBM Integration Designer para procesos BPEL.
En 8.0.0.4 (y 8.5.0.1) se actualizó el soporte para incluir la afirmación del contexto de transacción RRS desde regiones dependientes de IMS en WAS sobre WOLA:
Fixpack 8.0.0.5 / 8.5.0.2 proporcionó dos mejoras funcionales: (1) afirmación de contexto de transacción RRS desde WAS a IMS a través de WOLA / OTMA, y (2) soporte mejorado para canales y contenedores CICS.
Para transacciones IMS:
Para mejorar la compatibilidad con los canales y contenedores de CICS, antes de la versión 8.0.0.5/8.5.0.2 la compatibilidad con los canales y contenedores de CICS estaba limitada a un único canal de nombre fijo tanto para la solicitud como para la respuesta, y a un único contenedor de tipo BIT o CHAR. Con la versión 8.0.0.5/8.5.0.2:
Los adaptadores locales optimizados se pueden clasificar en los siguientes componentes:
Los adaptadores locales optimizados se implementan en CICS como una salida de usuario relacionada con la tarea (TRUE). Esto es lo que proporciona la conectividad esencial desde la memoria cruzada de CICS al espacio de direcciones WAS z/OS.
Además, se proporciona una tarea de servidor de enlace (BBO$) y una tarea de invocación de enlace (BBO#) para las llamadas desde WAS a CICS. La tarea de servidor de enlace BBO$/BBO# protege los detalles de programación de los programas CICS. La llamada OLA desde WAS es manejada por estas tareas proporcionadas y el programa CICS nombrado se invoca con la llamada EXEC CICS LINK estándar. El programa CICS nombrado permanece sin cambios y sin saber que la llamada proviene de WAS utilizando OLA. El programa de destino en CICS debe poder invocarse con una llamada LINK. Se admiten tanto COMMAREA [ aclaración necesaria ] como Channels/Containers.
También se suministra una transacción BBOC para proporcionar un conjunto de comandos de control para hacer cosas como iniciar manualmente el TRUE (si no está en PLTPI), detener el TRUE, iniciar y detener el servidor de enlace, así como otras funciones de control y administración.
El conjunto de datos de la biblioteca del módulo de interfaz de programación OLA debe concatenarse con la declaración DD DFHRPL de la región CICS.
La siguiente imagen resume el soporte de WOLA CICS para la propagación de transacciones y la afirmación de seguridad:
Los adaptadores locales optimizados se implementan como un subsistema externo de IMS. Su uso es compatible con programas de procesamiento de mensajes (MPP), programas de procesamiento de mensajes por lotes (BMP), IMS Fast Path (IFP) y aplicaciones Batch DL/I.
Las llamadas desde IMS a WAS utilizan la función de conexión de subsistema externo (ESAF). Se trata de la misma interfaz que utilizan otros subsistemas, como DB2 o MQ.
Las llamadas desde WAS a la región dependiente de IMS se pueden realizar mediante OTMA o directamente (es decir, el programa en IMS utiliza las API de OLA para "alojar un servicio", como se describe a continuación). OTMA proporciona transparencia de OLA a las aplicaciones de IMS a costa de algunos gastos generales. El uso de las API de OLA en la aplicación de IMS reduce los gastos generales, lo que da como resultado un mejor rendimiento y una mayor productividad.
Las API de programación para IMS tienen el mismo formato y sintaxis que las introducidas originalmente, pero se han actualizado para que tengan en cuenta IMS si se ejecutan allí y para utilizar ESAF.
Además, el archivo ola.rar que implementa el adaptador de recursos JCA para WAS debe ser el que se incluye con Fixpack 7.0.0.12 o posterior para poder utilizarlo con IMS. Los parámetros del método se han actualizado para que sea compatible con IMS y esa actualización está disponible para WAS al reinstalar el archivo ola.rar que viene con 7.0.0.12.
La siguiente imagen resume el soporte de WOLA IMS para la propagación de transacciones y la afirmación de seguridad:
El espacio de direcciones externo accede al mecanismo OLA a través de los módulos de interfaz suministrados y las API documentadas. Actualmente, hay 13 API que se clasifican a continuación.
Los programas Java que se ejecutan en el entorno WAS z/OS y desean ser el objetivo de una invocación desde el exterior deben implementar la interfaz OLA en un bean de sesión sin estado utilizando los archivos de clase OLA suministrados en el soporte de herramientas de desarrollo.
Un programa Java que desee iniciar una llamada OLA saliente puede implementarse como un servlet o EJB. El programa Java codifica el adaptador de recursos JCA suministrado (ola.rar) utilizando los archivos de clase incluidos en el soporte de herramientas de desarrollo.
Los espacios de direcciones externas que son el destino de la llamada saliente deben estar en un estado listo para aceptar la llamada. Existen dos modelos básicos:
Las API admiten ambos modos. El modo sincrónico proporciona un modelo de programación más simple porque el control del programa no se devuelve al programa que realiza la llamada hasta que se recibe una respuesta. El modo asincrónico proporciona al arquitecto la oportunidad de procesar otro trabajo sin tener que esperar una respuesta proveniente de un proceso de destino de larga ejecución.
Es posible diseñar los artefactos de programación específicos de OLA para que sirvan como "puentes" entre la interfaz de OLA y los recursos existentes. Esto sirve para minimizar el impacto en los recursos de programación existentes y limita el grado de "bloqueo de la plataforma".
Hay 13 API, categorizadas en las siguientes categorías:
El Centro de información contiene una descripción completa de cada uno de ellos, junto con listas de parámetros y códigos de retorno (RC) y códigos de motivo (RSN). Busque en cdat_olaapis.
Un modelo común de uso de API entrante sería:
En este caso, la API BBOA1REG se utiliza para registrarse en el grupo Daemon de WebSphere Application Server para z/OS (el nombre corto de la celda) y se utilizan múltiples invocaciones de BBOA1INV para invocar el EJB de destino. BBOA1INV es sincrónica, por lo que el control del programa se mantiene hasta que el EJB devuelve una respuesta. Esta API es útil cuando el programa que realiza la llamada conoce el tamaño del mensaje de respuesta de antemano. Si el tamaño del mensaje de respuesta es desconocido en el momento de la llamada, las API más primitivas (BBOA1SRQ (enviar solicitud), BBOA1RCL (obtener longitud de respuesta), BBOA1GET (obtener datos del mensaje)) serían más apropiadas.
Cuando el programa que realiza la llamada determina que ha terminado su trabajo, utiliza BBOA1URG para cancelar el registro del grupo Daemon.
Si el programa Java de destino tiene un intervalo de respuesta más largo, es probable que sea mejor un modelo asincrónico . La siguiente imagen ilustra cómo se realizaría una llamada asincrónica utilizando lo que se conoce como API primitiva : BBOA1SRQ con el parámetro async=1 establecido:
Como ilustra la imagen, el modo asincrónico permite que el programa que no es Java tome el control y realice otros procesos. Esto implica verificar si hay una respuesta en algún momento futuro. BBOA1RCL se utiliza para ese propósito. En este ejemplo, BBOA1RCL se emite de manera sincrónica (parámetro async=0). Si hay una respuesta disponible, BBOA1RCL proporcionará la longitud y el control del programa retornará al programa. Si no hay una respuesta disponible, BBOA1RCL retiene el control del programa hasta que haya una disponible. BBOA1RCL con async=1 devolverá x'FFFFFFFF' si no hay una respuesta disponible; el control del programa se devuelve inmediatamente.
Se pueden encontrar otras ilustraciones de salida en el documento WP101490 que se encuentra en el sitio web IBM Techdocs.
Nota: La salida de WAS a CICS no requeriría codificación de API. En ese caso, las transacciones del servidor de enlace BBO$/BBO# suministradas realizarían ese procesamiento. Esas transacciones del servidor de enlace "alojan un servicio" utilizando las construcciones internas similares a la API BBOA1SRV. La salida a un programa por lotes requeriría el uso de las API para "alojar un servicio".
Los adaptadores locales optimizados admiten el procesamiento de confirmación en dos fases (2PC) desde CICS entrante a WAS.
Con la llegada de la versión de mantenimiento 7.0.0.12, los adaptadores locales optimizados también admiten la confirmación de salida en dos fases de WAS a CICS. Antes de la versión 7.0.0.12, la compatibilidad transaccional de WAS a CICS se limitaba a la "sincronización al regresar".
Para IMS, se proporcionó compatibilidad con la aserción transaccional entrante a WAS desde regiones dependientes de IMS en los paquetes de correcciones 8.0.0.4 y 8.5.0.1. La aserción transaccional saliente desde WAS a IMS a través de WOLA/OTMA se proporcionó en el paquete de correcciones 8.0.0.5.
No se admite la propagación transaccional entrante ni saliente a lotes, USS o control de línea de aerolíneas.
Los adaptadores locales optimizados pueden afirmar la identidad en las siguientes circunstancias:
Los adaptadores locales optimizados para WAS z/OS solo se pueden usar dentro de una LPAR determinada. Es un mecanismo de memoria cruzada y no puede pasar de una LPAR a otra ni fuera de la máquina.