Utilización del soporte de la gestión de sesiones HTTP para aplicaciones JAX-WS
La gestión de sesiones HTTP se realiza en la capa de transporte HTTP utilizando cookies o la reescritura de URL. Al proporcionar varias opciones para el seguimiento de una serie de peticiones, la gestión de sesiones HTTP permite que las aplicaciones JAX-WS (Java™ API for XML-Based Web Services) aparezcan como dinámicas para los usuarios de aplicaciones.
Antes de empezar
Desarrolle un cliente de proxy dinámico o de asignación JAX-WS. Si desea más información sobre cómo desarrollar clientes JAX-WS, consulte información sobre cómo desarrollar un cliente JAX-WS a partir de un archivo WSDL (Web Services Description Language) o desarrollando un cliente dinámico mediante las API de JAX-WS.
Acerca de esta tarea
Puede utilizar la gestión de sesiones HTTP para mantener la información de estado de usuario en el servidor, mientras se devuelve mínima información al usuario para rastrear la sesión. Puede implementar la gestión de sesiones HTTP en el servidor de aplicaciones utilizando las cookies de sesión o la reescritura de URL.
La interacción entre el navegador, el servidor de aplicaciones y la aplicación es transparente para el usuario y el programa de aplicación. Normalmente, la aplicación y el usuario desconocen el identificador de la sesión proporcionado por el servidor.
Cookies de sesión
El dispositivo de la sesión de mantenimiento HTTP utiliza una sola cookie, JSESSIONID, y esta cookie contiene el identificador de la sesión. Esta cookie se utiliza para asociar la solicitud con la información almacenada en el servidor para dicha sesión. En las solicitudes posteriores procedentes de la aplicación JAX-WS, el ID de la sesión se transmite como parte de la cabecera de la solicitud, que permite a la aplicación asociar cada solicitud para un ID de sesión determinado con las solicitudes anteriores procedentes de dicho usuario. Las aplicaciones de cliente JAX-WS recuperan el ID de sesión de las cabeceras de respuesta HTTP y, a continuación, utilizan estos ID en las solicitudes posteriores estableciendo el ID de la sesión en las cabeceras de solicitud HTTP.
Reescritura de URL
La reescritura de URL funciona como un URL redireccionado, ya que almacena el identificador de la sesión en el URL. El identificador de sesión se codifica como un parámetro en cualquier enlace o formulario que se envía desde una página web. Este URL codificado se utiliza para las solicitudes posteriores al mismo servidor.
Procedimiento
Resultados
Ejemplo
<!-- Éste es el tipo de política de transporte HTTP -->
<wsp:ExactlyOne>
<wsp:All>
<wshttp:readTimeout>300</wshttp:readTimeout>
<wshttp:writeTimeout>300</wshttp:writeTimeout>
<wshttp:connectTimeout>180</wshttp:connectTimeout>
<wshttp:persistConnection>yes</wshttp:persistConnection>
<wshttp:messageResendOnce>no</wshttp:messageResendOnce>
<wshttp:chunkTransferEnc>no</wshttp:chunkTransferEnc>
<wshttp:acceptRedirectedURL>no</wshttp:acceptRedirectedURL>
<wshttp:sendExpectHeader>no</wshttp:sendExpectHeader>
<wshttp:maintainSession>yes</wshttp:maintainSession>
<wshttp:compressRequest>
<wshttp:compressType name="none"></wshttp:compressType>
</wshttp:compressRequest>
<wshttp:compressResponse>
<wshttp:compressType name="none"></wshttp:compressType>
</wshttp:compressResponse>
<wshttp:protocolVersion>HTTP/1.1</wshttp:protocolVersion>
</wsp:All>
</wsp:ExactlyOne>
Map<String, Object> rc = ((BindingProvider) port).getRequestContext();
...
...
rc.put(BindingProvider.SESSION_MAINTAIN_PROPERTY, Boolean.TRUE);
...
...