Muchos clientes ya utilizan un planificador de carga de trabajo externo para gestionar las cargas de trabajo por lotes en z/OS. Aunque el proceso por lotes Java que se ejecuta dentro de un entorno de WebSphere Application Server es relevante, también es importante una forma de controlar los trabajos de WebSphere Compute Grid mediante un planificador de carga de trabajo externo.
Compute Grid es un componente de WebSphere Extended Deployment Versión 6.1 que proporciona una solución completa de programación de proceso por lotes Java para empresas. Incluye un modelo de programación basado en POJO (Plain Old Java Object) preciso y de gran potencia, un modelo sencillo de empaquetado y despliegue, un lenguaje de control de trabajos con características completas, un planificador de trabajos complejo, un entorno sólido de ejecución, una gestión de carga de trabajo exhaustiva y herramientas administrativas. Todos se combinan para hacer de WebSphere Extended Deployment Compute Grid la solución de proceso por lotes Java más completa que existe hoy día.
Como se muestra en la imagen siguiente, un trabajo por lotes es una serie de programas ejecutados de fondo bajo el control de un gestor de trabajos. Cada programa consume cero, uno o más orígenes de datos de entrada y produce cero, uno o más receptáculos de salida. El sistema operativo z/OS es un ejemplo de un entorno maduro de proceso de trabajos por lotes. WebSphere Extended Deployment Compute Grid generaliza este modelo de proceso y hace que esté disponible en un entorno de WebSphere/Java 2 Enterprise Edition (J2EE).
Una aplicación de WebSphere Extended Deployment Compute Grid es una clase POJO que implementa una interfaz de proceso por lotes y que invoca el contenedor de proceso por lotes de WebSphere Extended Deployment. Tiene acceso a servicios de contenedor que exponen las secuencias de datos de proceso por lotes (BDS), que representan orígenes de datos y receptáculos. Normalmente, el objetivo de este tipo de aplicación es realizar operaciones masivas en un gran conjunto de registros. Una definición de trabajo describe una serie de pasos, donde cada paso invoca un POJO de proceso por lotes. La definición de trabajo describe el orden de ejecución de los pasos y las secuencias de datos de proceso por lotes que son entradas/salidas y que se utilizan en cada paso.
Un trabajo de Compute Grid se ejecuta dentro de un WebSphere Application Server en un contenedor especial denominado el contenedor de proceso por lotes, tal como se muestra en la imagen siguiente:
La definición de trabajo se describe en un archivo xJCL especial, que es un lenguaje de control de trabajos basado en XML. Se somete un archivo xJCL al planificador de trabajos de WebSphere Extended Deployment que, a continuación, envía el trabajo representado por el archivo xJCL a un WebSphere Application Server que aloja los POJO que componen la aplicación de destino. Dentro de WebSphere Application Server, el contenedor de proceso por lotes crea una hebra gestionada, denominada un bean asíncrono, para procesar el trabajo. El bean asíncrono procesa el trabajo invocando el POJO identificado por cada paso del trabajo, empezando por el primer paso, seguido del segundo, etc. El POJO invocado por cada paso tiene acceso a las secuencias de datos de proceso por lotes de entrada y salida que se describen en la definición de trabajo (el archivo xJCL).
El POJO procesa normalmente muchos registros de entrada y produce muchos registros de salida. Como el POJO se ejecuta dentro de WebSphere Application Server, tiene acceso completo al modelo de programación J2EE, así como a todos los servicios de WebSphere Application Server como, por ejemplo, la gestión de conexiones y transacciones. Puede invocar otros servicios web y J2EE localmente para aumentar la eficacia.
Como un planificador externo no sabe cómo gestionar directamente los trabajos de WebSphere Extended Deployment, se utiliza un modelo de proxy. El modelo de proxy utiliza un trabajo JCL normal para someter y/o supervisar el trabajo de WebSphere Extended Deployment. El paso de trabajo JCL invoca un programa especial proporcionado por WebSphere Extended Deployment, que se denomina WSGRID. La aplicación WSGRID somete y supervisa un trabajo de WebSphere Extended Deployment especificado. WSGRID graba los resultados intermedios del trabajo en las anotaciones de trabajo del trabajo JCL. WSGRID no vuelve hasta que haya finalizado el trabajo subyacente, lo que permite un modelo de ejecución síncrono. Como el planificador externo puede gestionar trabajos JCL, puede gestionar un trabajo JCL que invoca WSGRID. Con este patrón, el planificador externo puede gestionar un trabajo indirectamente. Una interfaz de plug-in opcional en el planificador de trabajos permite al usuario añadir un código que actualiza el plan de operaciones del planificador externo para que refleje el estado exclusivo del trabajo subyacente como, por ejemplo, trabajo iniciado, paso iniciado, paso finalizado, trabajo finalizado. El programa WSGRID se graba con un proceso de recuperación especial, para que si se cancela al trabajo JCL, también se cancele el trabajo subyacente, lo que permite sincronizar el ciclo de vida de los dos trabajos.
Como se muestra en el siguiente diagrama, el control de trabajos para las plataformas distribuidas es parecido a excepción de que el subsistema de entrada de trabajos (JES) no es necesario para las plataformas distribuidas.
Muchos clientes ya utilizan TWS para gestionar cargas de trabajo por lotes en la plataforma z/OS. Aunque el proceso por lotes Java que se ejecuta dentro de un entorno de WebSphere Application Server es relevante, es necesaria una forma de controlar los trabajos de WebSphere Extended Deployment Compute Grid a través de TWS. Dado que TWS no sabe cómo gestionar directamente los trabajos de WebSphere Extended Deployment, se utiliza un modelo de proxy. El modelo de proxy utiliza un trabajo JCL normal para someter/supervisar el trabajo de WebSphere Extended Deployment. El paso de trabajo JCL invoca un programa especial proporcionado por WebSphere Extended Deployment, que se denomina Extended Deployment WSGrid. Consulte el Programa de utilidad de línea de mandatos WSGrid .
La aplicación WSGrid somete y supervisa un trabajo de WebSphere Extended Deployment especificado. WSGrid graba los resultados intermedios del trabajo de WebSphere Extended Deployment en las anotaciones de trabajo del trabajo JCL. WSGrid no vuelve hasta que haya finalizado el trabajo subyacente de WebSphere Extended Deployment, lo que permite un modelo de ejecución síncrono. Como TWS puede gestionar trabajos JCL, puede gestionar un trabajo JCL que invoca WSGrid. Si se utiliza este patrón, TWS puede gestionar indirectamente un trabajo de WebSphere Extended Deployment.
Una interfaz de plug-in opcional en el planificador de trabajos de WebSphere Extended Deployment permite al usuario añadir un código que actualiza el plan de operaciones de TWS de modo que refleje el estado exclusivo del trabajo de WebSphere Extended Deployment subyacente como, por ejemplo, trabajo iniciado, paso iniciado, paso finalizado, trabajo finalizado. El programa WSGrid se graba con un proceso de recuperación especial, para que si se cancela al trabajo JCL, también se cancele el trabajo de WebSphere Extended Deployment subyacente, lo que permite sincronizar el ciclo de vida de los dos trabajos.