Consideraciones acerca del asignador de peticiones remotas

En este tema se describen algunas consideraciones que debe tener en cuenta cuando utilice el asignador de peticiones remotas.

  • Si una aplicación espera parámetros con una codificación determinada, la aplicación debe establecer la codificación de caracteres, como un include normal, antes de que se produzca las asignación de solicitudes remotas (RRD).
    • Los datos ServletInputStream del servidor local no están disponibles en el servidor remoto. El servidor local analiza los datos POST antes de enviar la solicitud RRD al servidor remoto e incluir parámetros como parámetros de solicitud. El servidor remoto no puede acceder a los datos compuestos de varias partes. Se crea una excepción UnsupportedOperationException si el servidor remoto intenta obtener la corriente de entrada a partir de la solicitud.
    • No hay acceso a la referencia de solicitud original en el servidor remoto.
    • Las envolturas de solicitud y respuesta creados en el servidor local no están disponibles en el servidor remoto. Esto no se puede realizar debido a que los ServletRequestWrappers y los objetos ServletRequest internos de WebSphere no se implementan de forma serializable.
  • Los atributos de solicitud han de ser serializables.
    • La definición de clase de los atributos ha de estar disponible en los servidores local y remoto.
    • Los atributos de solicitud se propagan al servidor remoto y se devuelven al servidor local.
  • Sesiones HTTP
    • No puede tener acceso entre sesiones desde diferentes aplicaciones web cuando las aplicaciones web son remotas.
    • Cuando todas las aplicaciones web están en un servidor local, una aplicación puede compartir sesiones entre aplicaciones web almacenando la sesión en una tabla a la que pueden acceder varias aplicaciones web. Esto no es posible con RRD y no se recomienda tampoco en casos locales.
    • Modelo de programación del servlet: no puede acceder a sesiones en diferentes aplicaciones Web.
    • Modelo de programación normal tanto en el caso local como remoto.
    • En la modalidad local, la aplicación puede guardar en la memoria caché las referencias y compartir la sesión entre las aplicaciones web, lo cual no es factible en el caso de RRD.
    • Un objeto de sesión que se almacena como un atributo de solicitud no está disponible en un servidor remoto ya que la clase Session no implementa Serializable.
  • Las variables locales de hebra que se establecen en el servidor local no están disponibles en el servidor remoto.
  • No todos los métodos definidos en el objeto ServletContext están disponibles para el objeto ServletContext de RRD. Consulte la documentación SPI para com.ibm.wsspi.rrd.context.RemoteServletContext para obtener información detallada.
  • El servidor remoto no tiene acceso a la salida del servidor local cuando utiliza RRD.
  • Cookies y ServletRequestWrappers

    Si la aplicación de cliente efectúa una envoltura del método HttpServletRequest.getCookies y devuelve cookies adicionales o suprime cookies, las cookies modificadas no se envían al servidor remoto porque javax.servlet.http.Cookie no implementa Serializable. Las cookies de las cabeceras de solicitud originales se envían al servidor remoto.


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_rrd_considerations
File name: rweb_rrd_considerations.html