Clientes de servicios web y configuración de política para utilizar la política de proveedor de servicios
Si un proveedor de servicios publica su política en el WSDL (Web Services Description Language), la configuración de políticas de un cliente de servicio de WebSphere Application Server puede configurarse dinámicamente según las políticas soportadas por su proveedor de servicios.
El proveedor de servicios debe publicar su política en formato WS-PolicyAttachment en el WSDL y el cliente debe poder soportar estas políticas del proveedor. El cliente puede basar por completo su configuración de políticas en la política del proveedor, o bien parcialmente en la política del proveedor con limitaciones definidas por la configuración del conjunto de políticas del cliente.
Un cliente adquiere la política de proveedor mediante una solicitud HTTP GET o el protocolo Web Services Metadata Exchange (WS-MetadataExchange) para obtener el WSDL del proveedor. Puede configurar cómo el cliente obtiene la política del proveedor, y el punto final en el que se adquiere la política, con la consola de administración o los mandatos wsadmin. Si utiliza el protocolo WS-MetadataExchange para obtener la política del proveedor, tendrá la ventaja de poder proteger las solicitudes GetMetadata de WS-MetadataExchange utilizando un conjunto de políticas del sistema adecuado.
Si la política de proveedor utiliza WSDL de varias partes, puede utilizar una solicitud HTTP GET para obtener la política del proveedor, pero no puede utilizar el protocolo WS-MetadataExchange. Para obtener más información acerca del WSDL de múltiples partes, consulte el tema que trata sobre WSDL.
La política del lado del cliente de aplicaciones web se calcula y almacena en memoria caché como una configuración de tiempo de ejecución. Esta política calculada se conoce como política efectiva y se utiliza para las siguientes solicitudes de servicios web de salida a la operación o el punto final para los que se realizó el cálculo. La configuración del conjunto de políticas original del cliente no cambia.
Para un servicio específico, la configuración de política dinámica se produce una vez de forma predeterminada y se supone que esta configuración es la misma para todos los puntos finales que implementan un servicio, porque tienen el mismo WSDL. Los cálculos de las políticas que se basan en este WSDL se colocan en memoria caché en el tiempo de ejecución del cliente (no son persistentes) y se comparten con cada servicio de destino.
En un entorno en clúster, esto significa que el cliente no vuelve a obtener la política del proveedor para cada instancia de punto final de un servicio web.
En WebSphere Application Server versión 8.0 y posterior, se puede configurar una referencia de servicio para utilizar un documento WSDL diferente al WDSL configurado para el servicio de cliente. De forma predeterminada, las referencias de servicio heredan su conjunto de políticas y configuración de WS-Policy de su de servicio padre; sin embargo, si lo desea, el conjunto de políticas y la configuración de WS-Policy se pueden sobrescribir. Consulte Utilización de WS-Policy para el intercambio de políticas en un formato estándar si desea detalles adicionales.
Si necesita una configuración de política distinta para cada implementación de punto final, debe crear un nuevo puerto para cada punto final. A continuación, puede especificar una configuración de política distinta para cada punto final.
Las políticas de transporte, como HTTP, SSL y JMS, no se pueden expresar en formato WS-PolicyAttachment, por lo que el cliente no puede adquirir las políticas de transporte del proveedor de servicios. Si el cliente necesita políticas de transporte, debe configurarlas como parte de la configuración del conjunto de políticas del cliente.
Para una solicitud HTTP GET, cuando el destino de la solicitud es la misma ubicación que la del punto final, la solicitud utiliza las mismas políticas de transporte HTTP y SSL que la aplicación. Cuando la solicitud HTTP GET tiene como destino un punto final diferente, también puede conectar un conjunto de políticas del sistema para especificar distintas políticas de transporte HTTP y SSL.
Para una solicitud WS-MetadataExchange GetMetadata, se utiliza la configuración de WS-Security del conjunto de políticas del sistema especificado. Las propiedades de transporte HTTP se heredan de la aplicación.
Un cliente que esté configurado para utilizar SAML (Security Assertion Markup Language) puede utilizar la configuración de política dinámica. No obstante, el cliente debe estar configurado para poder utilizar enlaces generales.
Política en un registro
Un cliente puede obtener la configuración de política de un proveedor de servicio web de un registro, por ejemplo WSRR (WebSphere Service Registry and Repository), utilizando una solicitud HTTP GET.
El WSDL para la política del proveedor de servicios, las políticas y conexiones de política correspondientes se almacenan en un registro como WSRR. Dicha política debe contener la configuración de políticas en formato WS-PolicyAttachments. El cliente debe poder dar soporte a estas políticas de proveedor.
El registro debe soportar el uso de solicitudes HTTP GET para publicar el WSDL que contiene las conexiones de WS-Policy, por ejemplo, WSRR versión 6.2 o posterior.
Puede aplicar la política de proveedor que el cliente obtiene de un registro a nivel de servicio o referencia de servicio, pero no a nivel de aplicación.
Si existe una conexión segura entre el cliente y el registro, debe asegurarse de que se establezca confianza entre el servidor de aplicaciones y el servidor de registro.
Si el registro necesita autenticación, también tiene que configurar una política para autenticar las solicitudes de servicio de salida en el registro. De forma predeterminada, se utilizan las credenciales HTTP y HTTPS tanto para el punto final de servicio web como para el registro. Por lo tanto, se recomienda proteger las credenciales de autorización y asegurarse de que estas credenciales no se envíen a un punto final no autorizado. También puede conectar un conjunto de políticas del sistema para especificar distintas políticas de transporte HTTP y SSL.
Herencia de política
La política del proveedor puede conectarse a nivel de aplicación o de servicio. Los puntos finales y las operaciones heredan su configuración de políticas del servicio relevante.
Cálculo de política
- Cuando sólo se especifica la política del proveedor, la política calculada se basa en todas las políticas a las que da soporte el cliente de WebSphere Application Server intersectadas por la política del proveedor. En efecto, el proveedor determina la política, siempre que el cliente pueda soportarla. Esta configuración de políticas está disponible si el punto de ámbito (operación de punto final) al que se conecta la política del proveedor no está conectado a un conjunto de políticas de cliente y no hereda una conexión de conjunto de políticas de los puntos de ámbito padre.
- Al especificar la política de cliente y de proveedor, la política calculada se basa en la intersección de la política aceptable para el cliente con la política de proveedor. En efecto, la política cumple con el conjunto de políticas de cliente, pero podría estar limitada por las políticas dictadas por el proveedor. El conjunto de políticas, conectado al punto de ámbito del cliente o heredado de un punto de ámbito padre por el punto de ámbito del cliente, define la política que es aceptable para el cliente. Esta configuración de políticas está disponible si el punto de ámbito (operación de punto final) al que se conecta la política del proveedor está conectado a un conjunto de políticas de cliente o hereda una conexión de conjunto de políticas de los puntos de ámbito padre.
El lenguaje WS-Policy proporciona el modo de expresar varias opciones de política, de manera que el cálculo de la política puede generar más de un resultado. Por ejemplo, el proveedor de servicios puede dar soporte a WS-ReliableMessaging 1.0 y WS-ReliableMessaging 1.1. Si el cliente soporta también ambas versiones, el cliente puede utilizar cualquiera de ellas en las solicitudes de servicio web al proveedor. En esta situación, en la que tanto el cliente como el proveedor aceptan más de una versión de la especificación, la política efectiva se calcula utilizando la versión más reciente.
Intersección de política en el cliente de asignación JAX-WS
- El cliente se ajusta a la política del proveedor del ámbito de la operación sólo si la política del proveedor es idéntica para todas las operaciones proporcionadas por el servicio (tanto semántica como sintácticamente).
- Si la política del proveedor no es idéntica para todas las operaciones que proporciona el servicio, el cliente devuelve una excepción WebserviceException de JAX-WS con la causa WSPolicyException (CWPOL0106E), y un mensaje de error inadecuado.
- Si no hay ninguna política en ninguna de las operaciones, el cliente utiliza la política de proveedor efectiva para el punto final de servicio.
Renovación de la política del proveedor por parte del cliente
La política del proveedor que mantiene el cliente para un servicio se renueva la primera vez que se invoca el servicio web después de que se haya iniciado la aplicación. A continuación, la política del proveedor se renueva cuando la aplicación se reinicia o cuando se invoca explícitamente una actualización de la política del proveedor. Cuando se renueva la política de proveedor, se vuelve a calcular la política efectiva.
Puede invocar una actualización de la política del proveedor en el código de la aplicación. Esto puede resultar útil si falla la invocación JAX-WS; en el manejo de excepciones, puede forzar un reintento con la política renovada. Puede establecer la siguiente propiedad (disponible en la clase WSPConstants de la API) en el proxy de cliente JAX-WS y, a continuación, volver a emitir la solicitud JAX-WS: com.ibm.websphere.wspolicy.refreshProviderPolicy.
Cuando se establece la propiedad com.ibm.websphere.wspolicy.refreshProviderPolicy, se renueva la política de proveedor que mantiene el cliente para un servicio y se vuelve a calcular la política efectiva en la solicitud siguiente. Después de que se hayan producido la renovación y el nuevo cálculo, se anula el establecimiento de la propiedad com.ibm.websphere.wspolicy.refreshProviderPolicy.
En el ejemplo siguiente de código para un cliente de asignación se muestra la identificación de una excepción que se puede resolver renovando la política del proveedor, seguida de la invocación de la renovación.
try
{
dispatch.invoke(params);
}
catch (javax.xml.ws.WebServiceException e)
{
Throwable cause = e.getCause();
if ((cause instanceof NullPolicyException) || (cause instanceof PolicyException) )
{
// La excepción se puede producir debido a que la política del proveedor no está actualizada.
//
// También hay un mensaje en la consola que comienza con los caracteres CWPOL,
// que ayuda a descifrar y depurar la causa del error.
// Este mensaje también está disponible utilizando
// String nlsedMessage = cause.getMessage();
Map<String, Object> requestContext = dispatch.getRequestContext();
requestContext.put(WSPConstants.REFRESH_PROVIDER_POLICY, Boolean.TRUE);
// El siguiente método podría causar otra excepción de invocación jax-ws.
// La causa puede ser la política y, de ser así, se graba un mensaje en la
// consola.
dispatch.invoke(params);
}
// Para todas las excepciones restantes, utilice el manejo de excepciones normal para la
// aplicación. En este caso, presuponga que no hay más excepciones y vuelva a emitir la
// excepción inicial. Recuerde que WebServiceException se puede generar a causa de
// WSPolicyAdministrationException. En esta situación, se graba un mensaje en la
// consola, pero forzar la renovación de la aplicación no solucionará el problema.
throw e;
}