Consideraciones sobre el diseño de aplicaciones de asignador de solicitudes asíncronas

El asignador de solicitudes asíncronas (ARD) no es un a solución de talla única para la programación de servlets. Debe evaluar las necesidades de su aplicación y las implicaciones del uso de ARD. Hacer que todos los archivos de inclusión se inicien asíncronamente no es la solución para todos los casos prácticos, pero si se utiliza sabiamente, ARD puede mejorar el tiempo de respuesta.

Implementación del lado del cliente del asignador de solicitudes asíncronas

  • Se escribe JavaScript dinámicamente en la salida de la respuesta.
  • Este JavaScript se traduce en solicitudes Ajax que se devuelven al proveedor de resultados del lado del servidor.
  • Debido a las características AIO (entrada/salida asíncrona) del canal, la solicitud Ajax no inicia una hebra y, en su lugar, recibe una notificación de finalización mediante una devolución de llamada de inclusión.
  • El cliente sólo efectúa una solicitud a la vez para los includes asíncronos, debido a las limitaciones del navegador respecto al número de conexiones.
  • La conexión original debe ser válida durante la vida útil de los includes. No se puede reutilizar para las solicitudes Ajax.
  • Los nodos de comentarios, como los siguientes,
    <!--uniquePlaceholderID--><!--1-->
    se colocan en el modelo de objetos del navegador puesto que los nodos de comentarios no producen efecto alguno en el diseño de la página.
  • Cuando existe un fragmento completo, se puede enviar una respuesta al cliente y se sustituye el nodo de comentario con el mismo ID. Se realizan solicitudes hasta que se recuperan todos los fragmentos.
  • Verifique las aplicaciones en todos los navegadores soportados cuando utilice la agregación del lado del cliente. Se utilizan los principios de JavaScript orientados a objeto, por lo que las aplicaciones sólo necesitan evitar el uso del nombre de método getDynamicDataIBMARD. Todo suceso window.onload anteriormente especificado se inicia antes del método onload de ARD.

Servicio de resultados de canal del asignador de solicitudes asíncronas

Las solicitudes de datos de inclusión del código JavaScript asíncrono se envían identificadores uniformes de recursos, URIs, también denominados URLs, que el canal ARD puede interceptar para impedir que viajen a través del manejo de la solicitud de contenedor web. Estos URI son exclusivos para cada reinicio de servidor.

Por ejemplo, /IBMARD01234567/asyncInclude.js es el URI del JavaScript que fuerza la recuperación de los resultados e /IBMARD01234567/IBMARDQueryStringEntries?=12000 se utiliza para recuperar los resultados para la entrada con el ID 12000.

Para impedir el acceso a resultados no autorizados, se generan IDs exclusivos para el URI del servicio y para las entradas ARD. Se comparte un generador común de IDs entre la sesión y el ARD, por lo que la exclusividad es configurable mediante la configuración de la sesión. Los ID de sesión se consideran seguros, pero no son tan seguros como utilizar una señal LTPA (autenticación ligera de tercer interlocutor).

Agregación del lado del cliente personalizada

Si desea realizar su propia agregación del lado del cliente, el método isUseDefaultJavascript debe devolver false. El método isUseDefaultJavascript forma parte del método AsyncRequestDispatcherConfig, que se establece en el AsyncRequestDispatcher o para el método AsyncRequestDispatcherConfigImpl.getRef. El método AsyncRequestDispatcherConfigImpl.getRef es el objeto de configuración global. Puede desear realizar su propia agregación del lado del cliente si la funcionalidad del botón atrás es problemática. Debe eliminar los resultados del servicio de resultados genérico para impedir fugas de memoria, de modo que múltiples solicitudes con los mismos resultados de respuesta a través de un XMLHttpRequest fallen. Para facilitar la correcta ubicación de las posiciones, los espacios en blanco siguen escritos en el código como
<!--uniquePlaceholderID--><!--x-->
donde x es el orden de las inclusiones. El punto final para recuperar resultados se recuperan del atributo de solicitud com.ibm.websphere.webcontainer.ard.endpointURI.
Al efectuar una solicitud al punto final, ARD envía tantos fragmentos de respuestas como sea posible cuando se realiza la solicitud. Por lo tanto, el cliente debe volver a realizar la solicitud si no se devuelven todos los fragmentos devueltos inicialmente. El intento de visualizar los resultados directamente en un navegador sin utilizar una XMLHttpRequest puede causar errores relacionados con XML no válido. Los datos de respuesta se devuelven en el siguiente formato con tipo de contenido text/xml:
<div id="2"><BR>Servlet 3--dispatcher3 requesting Servlet3 to sleep for 0 seconds at: 1187967704265 
<BR> Servlet 3--Okay, all done!  This should print pop up: third at: 1187967704281 </div>

Para obtener información adicional acerca de las interfaces AsyncRequestDispatcherConfig y AsyncRequestDispatcher, consulte el paquete com.ibm.websphere.webcontainer.async en la documentación de la API (interfaz de programación de aplicaciones). La documentación de la API generada está disponible en la tabla de contenido de la documentación de Referencia > API - Interfaces de programación de aplicación.

Agregación del lado del servidor

Al igual que la agregación del lado del cliente, la agregación del lado del servidor utiliza el canal ARD como servicio de resultados. El canal ARD conoce las inclusiones asíncronas que se han producido para un cierto conjunto de almacenamientos intermedios. En estos almacenamientos intermedios se pueden efectuar búsquedas de un espacio en blanco de inclusión. Debido a los problemas del almacenamiento intermedio de JSP, el espacio en blanco de la inclusión puede no estar en los almacenamientos intermedios buscados. Si esto ocurre, también debe mirarse el siguiente conjunto de almacenamientos intermedios para ver si hay espacios en blanco de inclusiones perdidas en el conjunto anterior. ARD intenta agregar iterativamente cuando se devuelven las inclusiones para que se pueda enviar el contenido de la respuesta al cliente tan pronto como sea posible.

Simultaneidad

Se utiliza un gestor de trabajo para incluir las inclusiones. Si el número de inclusiones actualmente solicitadas es mayor que el tamaño máximo de la agrupación de hebras del gestor de trabajos y dicho tamaño no es ampliable, inicia el trabajo en la hebra actual y omite la escritura del espacio en blanco. La utilización de Concurrency Utilities for Java™ EE permite la propagación del contexto Java EE de la hebra original, que incluye área de trabajo, internacionalización, perfil de aplicación, gestión de carga de trabajo del sistema operativo z/OS, seguridad, transacción y contexto de conexión.

Temporizador

Se utiliza un único temporizador para ARD se crean tareas de temporizador para todos los tipos de tiempos de espera de las solicitudes ARD. Es posible que las tareas registradas en el temporizador no se ejecuten a la hora exacta especificada debido a que el temporizador se ejecuta en una única hebra, por lo tanto un tiempo de espera puede hacer que se espere a que las demás acciones del tiempo de espera finalicen. El temporizador se utiliza como último recurso.

Asignador de solicitudes remotas

Opcionalmente, ARD se puede utilizar conjuntamente con el asignador de solicitudes remotas. El asignador de solicitudes remotas ejecuta la inclusión en un servidor de aplicaciones distinto de un grupo principal, serializando el contexto de la solicitud en un mensaje SOAP y utilizando servicios web para llamar al servidor remoto. Esto es útil cuando el gasto que supone crear y enviar un mensaje SOAP a través de servicios web supera el de la emisión de la solicitud localmente.

Excepciones

En el caso de una excepción en un servlet de inclusión, el contenedor web recorre las definiciones de páginas de error correlacionadas con los tipos de excepción. De este modo, una página de error definida en el descriptor de despliegue aparece como un fragmento de la página agregada. Inserte lógica en la página de error si el comportamiento debe ser distinto para una inclusión. Puesto que la inclusión se ejecuta asíncronamente, es posible que el servlet de nivel superior no siga estando en servidor y por lo tanto que la excepción no se propague de vuelta desde una inclusión asíncrona como una inclusión normal. Otras inclusiones finalizan para que se puedan visualizar las páginas parciales.

Si el gestor de trabajos ARD se queda sin hebras de trabajador, la inclusión se procesa como una inclusión síncrona. Éste es el valor predeterminado pero el gestor de trabajos también puede crecer de tal modo que no resulte en esta condición. Este cambio en el proceso es invisible al usuario durante el proceso pero se nota una vez el sistema anota un mensaje de aviso y el resto del tiempo del rastreo anota cuando está habilitado. Otros estados que puedan desencadenar que la inclusión se produzca síncronamente son alcanzar el porcentaje máximo de solicitudes caducadas en un intervalo de tiempo y alcanzar el tamaño máximo del almacenamiento de resultados.

Podrían producirse excepciones fuera del ámbito del manejo normal de páginas de error. Por ejemplo, el gestor de trabajos puede rechazar los trabajos. Un temporizador puede caducar esperando una respuesta de inclusión a devolver. El canal ARD, actuando como un servicio genérico para recuperar los resultados, puede recibir un ID que no sea válido. En estos casos, no existe ninguna vía de acceso al manejo de la página de error puesto que falta el contexto, como ServletRequest, ServletResponse y ServletContext, para que la solicitud funcione. Para mitigar estos problemas, puede utilizar la interfaz AsyncRequestDispatcherConfig para proporcionar mensajes de error personalizados. Se proporcionan valores predeterminados e internacionalizados según sea necesario.

Las excepciones también pueden producirse fuera del ámbito de la solicitud en la que se estableció la configuración personalizada, como en las XMLHttpRequests del lado del cliente posteriores. En este caso, debe alterarse la configuración global. Ésta se puede recuperar a través de com.ibm.wsspi.ard.AsyncRequestDispatcherConfigImpl.getRef().

Inicio de inclusión
El gestor de trabajos proporciona un tiempo de espera para el tiempo que debe esperarse a que se inicie una inclusión. Puesto que generalmente esto se produce inmediatamente, no existe ninguna manera programática de habilitarlo. No obstante, esto es configurable en los valores del gestor de trabajos. De manera predeterminada no se encontrará esta situación debido a la comprobación de máximo de hebras que se realiza antes de programar el trabajo. Se puede volver a intentar el trabajo si se llama a setRetriable(true) en la AsyncRequestDispatcherConfig en uso.
Finalización de inclusión
El tiempo de espera iniciado empieza después de aceptarse el trabajo. Se puede configurar a través de la consola o programáticamente mediante el método AsyncRequestDispatcherConfig.setExecutionTimeoutOverride; el valor predeterminado es de 60000 ms, o un minuto. En lugar del resultado de la inclusión, se envía el mensaje de AsyncRequestDispatcherConfig.setExecutionTimeoutMessage. Si se alcanza este tiempo de espera iniciado, pero el resultado de la inclusión real está preparado cuando los datos se pueden vaciar, se da preferencia a los resultados reales. Además, esto no es aplicable a las llamadas de insertFragmentBlocking, que siempre esperan a que finalicen las inclusiones.
Caducidad de los resultados
Puesto que el lado del cliente debe conservar los resultados en un servicio para enviar la solicitud Ajax, necesitamos una manera de caducar los resultados si el cliente se apaga y nunca recupera la entrada. El valor predeterminado de un minuto es suficiente para una solicitud típica puesto que la solicitud Ajax regresaría inmediatamente después de enviar la respuesta. El temporizador se puede configurar programáticamente utilizando el método setExpirationTimeoutOverride de la AsyncRequestDispatcherConfig. El mensaje del método getOutputRetrievalFailureMessage de AsyncRequestDispatcherConfig se visualiza cuando alguien intenta acceder a una entrada caducada y que se ha eliminado del almacenamiento temporal. Este mensaje es el mismo mensaje que se envía a alguien que solicite un resultado con un ID que nunca ha existido.

Inclusiones o fragmentos

Considere qué operaciones se pueden realizar asíncronamente y cuándo pueden iniciarse. Idealmente, todas las inclusiones han finalizado cuando se efectúan llamadas a getFragment al principio de la solicitud, de forma que las inclusiones tengan un poco más de tiempo para finalizar y, en la inserción de los fragmentos, haya menos operaciones de almacenamiento intermedio y agregación si han finalizado. No obstante, llamar a una inclusión asíncrona es más fácil porque sigue el mismo patrón que una inclusión de asignador de solicitudes normal.

Contenedor web

ServletContext
Al realizar inclusiones multicontexto, el contexto que es el destino de la inclusión también debe tener ARD habilitado puesto que la aplicación web debe haber estado inicializada para ARD por su contexto de servlet para que tenga métodos válidos que permitan recuperar un AsyncRequestDispatcher. El tipo de agregación viene determinado por la configuración del contexto original ya que no puede mezclar tipos de agregación.
ServletRequest
Debe clonar la solicitud para cada inclusión. De lo contrario, pueden producirse conflictos entre hebras. Puesto que las aplicaciones pueden envolver los objetos de solicitud por omisión, sus envolturas deben implementar la interfaz com.ibm.wsspi.webcontainer.servlet.IServletRequest, que tiene un método, el método public Object clone, que crea la CloneNotSupportedException.
La desenvoltura se produce hasta que se encuentra una envoltura de solicitud que implemente esta interfaz. Las envolturas que no la implementan se pierden; no obstante, un filtro de servlet configurado para la inclusión puede volver a envolver la respuesta.
Los cambios efectuados en ServletRequest no se propagan de nuevo hasta el servlet de nivel superior a menos que se habilite transferState en AsyncRequestDispatcherConfig y se llame a insertFragmentBlocking.
ServletResponse
ARD crea una respuesta envuelta que extiende com.ibm.websphere.servlet.response.StoredResponse y la envía a las inclusiones ya que la salida de la respuesta debe poderse recuperar más allá del ciclo de vida de la respuesta original.
Las cabeceras internas establecidas en las inclusiones asíncronas no se soportan debido a las restricciones del ciclo de vida a menos que se habilite transferState en la configuración de AsyncRequestDispatcher y se llame a insertFragmentBlocking. Las cabeceras normales no se soportan en una inclusión síncrona según se especifica mediante la especificación del servlet.
Los filtros de inclusión pueden volver a envolver la nueva respuesta y debe vaciarse una vez finalice.
ServletInputStream
Una aplicación que lea parámetros utilizando getParameter no es problemática. Se fuerza el análisis de parámetros antes de la primera inclusión asíncrona para impedir el acceso concurrente a la corriente de entrada.
HttpSession
Las llamadas iniciales a getSession que se traduzcan en una cabecera Set-Cookie deben realizarse desde el servlet de nivel superior, ya que no se puede predecir si las inclusiones se han iniciado y si las cabeceras ya se han vaciado. La excepción es cuando se habilita transferState en AsyncRequestDispatcherConfig y se llama a insertFragmentBlocking. Esto normalmente crea un excepción cuando añade la cabecera.
Filtros
Si existe un filtro para una inclusión, se emite el filtro en la hebra asíncrona.
Inclusiones asíncronas anidadas
Las inclusiones asíncronas anidadas no se soportan ya que complican la agregación. No obstante, una inclusión asíncrona puede tener inclusiones síncronas anidadas. Cualquier intento de realizar una inclusión asíncrona anidada hace que se revierta a la inclusión síncrona.

Transacciones

Toda tarea que se envía al gestor de trabajo se llama utilizando su propia transacción, de la misma forma que las transacciones gestionadas por contenedor en enterprise beans típicos. El tiempo de ejecución inicia una transacción local antes de iniciar el método. La tarea puede iniciar su propia transacción global si esta transacción es posible para el componente Java EE de llamada.

Si la tarea crea una excepción, las transacciones locales se retrotraen. Si el método se devuelve con normalidad, todas las transacciones locales incompletas se completarán de acuerdo con la política de acciones no resueltas configurada para el bean. Si la tarea inicia su propia transacción global y no confirma esta transacción global, la transacción se retrotrae cuando se devuelve el método.

Gestión de conexiones

Una tarea que se envía al gestor de trabajo puede utilizar los orígenes de datos y las fábricas de conexiones que su servlet de creación ha obtenido utilizando las referencias de recursos java:comp. Sin embargo, el método de bean debe acceder a estas conexiones utilizando el patrón get, use o close. No hay ningún almacenamiento en memoria caché de conexiones entre llamadas de método en una tarea. Los orígenes de datos o las fábricas de conexiones se pueden almacenar en memoria caché, pero las conexiones se deben recuperar en cada llamada de método, utilizar y a continuación cerrar. Mientras que la tarea puede buscar fábricas de conexiones utilizando un nombre JNDI (Java Naming and Directory Interface) global, esto no se recomienda por las razones siguientes:
  • El nombre JNDI está codificado en la aplicación, por ejemplo, como una propiedad o literal de serie.
  • Las fábricas de conexiones no se comparten ya que no se puede especificar un ámbito de compartimiento.
Evalúe los escenarios de gran carga ya que las inclusiones asíncronas pueden aumentar el número de hebras que esperan en la conexión.

Rendimiento

Puesto que las inclusiones se completan asíncronamente, debe tenerse en consideración los datos de rendimiento totales de las inclusiones asíncronas para una solicitud. El tiempo total de la solicitud podía entenderse anteriormente como el tiempo que tarda en completarse el servlet de nivel superior, pero ahora dicho servlet finaliza antes de que se completen las inclusiones. El servlet de nivel superior sigue acaparando gran parte del tiempo de configuración adicional necesario para cada inclusión.

Por lo tanto, se ha añadido una nueva métrica de rendimiento ARD a la infraestructura de supervisión del rendimiento (PMI) para medir el tiempo que tarda en completarse una solicitud a través del canal ARD. La granularidad de estas métricas se encuentra a nivel de URI de solicitud.

Puesto que ARD es una característica opcional que debe habilitarse, no se produce ninguna disminución del rendimiento cuando no se utiliza ARD. Sin embargo, las aplicaciones no ARD que residen en un servidor de aplicaciones habilitado para AD pueden notar la capa adicional de ARDChannel. La capa de canal no sabe a qué aplicación va, por lo que en una cadena de canales es sí o no para todas las aplicaciones. Éstas se definen por cada host virtual.

Seguridad

No se invoca a la seguridad en las asignaciones de inclusiones síncronas de acuerdo con la especificación del servlet. No obstante, el contexto de seguridad se pasa mediante Concurrency Utilities for Java EE para dar soporte al uso programático de los métodos isUserInRole y getUserPrincipal en ServletRequest. Este contexto de seguridad también se puede propagar a una asignación de solicitud remota utilizando Web Services Security.


Icon that indicates the type of topic Reference topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rweb_ard_considerations
File name: rweb_ard_considerations.html