Configurações de Clientes e de Política de Serviço da Web para Usar a Política de Provedor de Serviços
Se um provedor de serviços publica sua política no WSDL (Web Services Description Language), a configuração da política de um cliente de serviço da Web do WebSphere Application Server poderá sr configurada dinamicamente, com base nas políticas suportadas por seu provedor de serviços.
O provedor de serviços deverá publicar sua política no formato WS-PolicyAttachment e seu WSDL, e o cliente deverá suportar essas políticas do provedor. O cliente pode basear sua configuração de política inteiramente na política do provedor ou parcialmente na política do provedor com restrições definidas pela configuração do conjunto de política do cliente.
Um cliente adquire a política do provedor usando uma solicitação HTTP GET ou o protocolo do Web Services Metadata Exchange (WS-MetadataExchange) para obter o WSDL do provedor. É possível configurar como o cliente obtém a política do provedor e o terminal em que a política é adquirida, utilizando o console administrativo ou comandos wsadmin. Uma vantagem de usar o protocolo WS-MetadataExchange para obter a política do provedor, é que é possível aplicar a segurança nas solicitações do WS-MetadataExchange GetMetadata usando um conjunto de políticas de sistema adequado.
Se a política do provedor usar um WSDL de diversas partes, será possível usar a soliticação HTTP GET para obter a política do servidor, mas não poderá usar o protocolo do WS-MetadataExchange. Para obter informações adicionais sobre WSDL com múltiplas partes, consulte o tópico sobre WSDL.
A política do lado do cliente do aplicativo da Web é calculada e armazenada em cache como uma configuração de tempo de execução. Essa política calculada é conhecida como a política efetiva e é usada para solicitações de serviços da Web de saída subsequentes para o terminal ou a operação para o qual o cálculo foi executado. A configuração do conjunto de política original do cliente não muda.
Para um servidor específico, por padrão, a configuração da política dinâmica ocorre uma vez e considera-se que essa configuração seja igual para todos os terminais que implementam um serviço, pois eles têm o mesmo WSDL. Os cálculos de política baseados nesse WSDL são armazenados em cache no tempo de execução do cliente (não são mantidos) e compartilhados com cada serviço de destino.
Em um ambiente em cluster, isso significa que o cliente não obtém a política do provedor novamente para cada instância do terminal de um serviço da Web.
No WebSphere Application Server Versão 8.0 e posterior, uma referência de serviço pode ser configurada para usar um documento WSDL diferente para o WSDL configurado para o serviço do cliente. Por padrão, as referências de serviço herdam o seu conjunto de políticas e a configuração do WS-Policy de seu serviço pai, entretanto, se desejar, o conjunto de políticas e a configuração do WS-Policy podem ser sobrescritas. Consulte Utilizando o WS-Policy para Trocar Políticas em um Formato Padrão para obter detalhes adicionais.
Se for necessária uma configuração de política diferente para cada implementação de terminal, você deverá criar uma nova porta para cada terminal. Em seguida, será possível especificar uma configuração de política diferente para cada terminal.
Políticas de transporte, como HTTP, SSL e JMS não podem ser expressas no formato WS-PolicyAttachment, portanto, o cliente não pode adquirir as políticas de transporte do provedor de serviços. Se o cliente requerer políticas de transporte, essas políticas deverão ser configuradas como parte da configuração do conjunto de política do cliente.
Para uma solicitação HTTP GET, quando a solicitação for destinada ao mesmo local do terminal, ela usará o mesmo HTTP e as mesmas políticas de transporte SSL do aplicativo. Quando a solicitação GET HTTP for destinada em um terminal diferente, poderá também anexar um conjunto de políticas do sistema para especificar políticas de transporte HTTP e SSL diferentes.
Para um pedido GetMetadata WS-MetadataExchange, a configuração WS-Security no conjunto de políticas de sistema especificado é usada. As propriedades de transporte HTTP são herdadas do aplicativo.
Um cliente que é configurado para usar o Security Assertion Markup Language (SAML) pode usar a configuração de política dinâmica. Entretanto, o cliente deve ser configurado para usar ligações gerais.
Política em um Registro
Um cliente pode obter a configuração de política de um provedor de serviços da Web a partir de um registro, como o WebSphere Service Registry and Repository (WSRR), usando uma solicitação HTTP GET.
O WSDL para a política do provedor de serviços, e suas políticas correspondentes e anexos de políticas, são armazenados em um registro como WSRR. Essa política deve conter sua configuração de política em formato WS-PolicyAttachments. O cliente deverá suportar essas políticas do provedor.
O registro deve suportar o uso de solicitações HTTP GET para publicar o WSDL que contém anexos WS-Policy, por exemplo, WSRR Versão 6.2 ou posterior.
É possível aplicar a política do provedor que o cliente obtém a partir de um registro no nível de serviço, ou referência de serviço mas não no nível do aplicativo.
Se existir uma conexão segura entre o cliente e o registro, você deve garantir que a confiança seja estabelecida entre o servidor de aplicativos e o servidor de registros.
Se o registro necessitar de autenticação, você também deve configurar uma política para autenticar pedidos de serviço de saída para o registro. Por padrão, as credenciais HTTP e HTTPS são usadas para o terminal e registro de serviço da Web. Portanto, é aconselhável proteger quaisquer credenciais de autorização para assegurar que essas credenciais não sejam enviadas para um terminal não autorizado. Também é possível anexar um conjunto de políticas do sistema para especificar políticas de transporte HTTP e SSL diferentes.
Herança de Política
A política do provedor pode ser anexada no nível de aplicativo ou de serviço. Os terminais e operações herdam a configuração de política do serviço relevante.
Política de Cálculo
- Quando você especifica apenas a política do provedor, a política calculada é baseada em todas as políticas que o cliente WebSphere Application Server suportar com uma interseção feita pela política do provedor. Efetivamente, o provedor determina a política, enquanto o cliente pode suportar essa política. Essa configuração de política ficará disponível se o ponto de escopo (operação de terminal), no qual a política do provedor é anexada, não estiver anexado a um conjunto de política do cliente e não herdar um anexo do conjunto de política dos pontos de escopo pai.
- Quando você especifica a política do cliente e do provedor, a política calculada é baseada na política aceitável ao cliente em interseção pela política do provedor. Efetivamente, a política está em conformidade com o conjunto de política do cliente, mas pode ser restrita ainda pelas políticas decretadas pelo provedor. A política aceitável ao cliente é definida pelo conjunto de política anexado ao ponto do escopo do cliente ou o ponto do escopo do cliente herda de um ponto de escopo pai. Essa configuração de política ficará disponível se o ponto de escopo (operação de terminal), no qual a política do provedor é anexada, for anexado ao conjunto de política do cliente ou herdar um anexo do conjunto de política dos pontos de escopo pai.
A linguagem WS-Policy fornece uma maneira de expressar várias opções de política, portanto, o cálculo da política pode produzir mais de um resultado. Por exemplo, o provedor de serviços pode suportar o WS-ReliableMessaging 1.0 e o WS-ReliableMessaging 1.1. Se o cliente suportar também as duas versões, ele poderá usar qualquer versão em suas solicitações de serviços da Web para o provedor. Nessa situação, onde mais de uma versão de especificação for aceitável em ambos cliente e provedor, a política efetiva é calculada usando a versão mais recente.
Interseção de Política no Cliente de Dispatch JAX-WS
- O cliente será compatível com a política do provedor com escopo na operação apenas se a política do provedor for idêntica para todas as operações fornecidas pelo serviço (tanto semântica quanto sintaticamente).
- Se a política do provedor não for idêntica para todas as operações fornecidas pelo serviço, o cliente retornará uma JAX-WS WebserviceException com a causa WSPolicyException (CWPOL0106E) e uma mensagem de erro apropriada.
- Se não houver nenhuma política em nenhuma das operações, o cliente utilizará a política de provedor efetiva para o terminal em serviço.
Atualizando a Política do Provedor Mantida pelo Cliente
A política do provedor mantida pelo cliente para um serviço será atualizada na primeira vez em que o serviço da Web for chamado após o início do aplicativo. Depois disso, a política do provedor é atualizada quando o aplicativo reinicia ou quando você chama explicitamente uma atualização da política do provedor. Quando a política do provedor é atualizada, a política efetiva é recalculada.
É possível chamar uma atualização da política do provedor no código do aplicativo. Isso poderá ser útil no caso de falha de uma chamada JAX-WS; na manipulação de exceção, é possível forçar uma nova tentativa com a política atualizada. É possível configurar a propriedade a seguir (disponível na classe WSPConstants da API) no proxy de cliente do JAX-WS e, em seguida, emitir novamente o pedido de JAX-WS: com.ibm.websphere.wspolicy.refreshProviderPolicy.
Quando a propriedade com.ibm.websphere.wspolicy.refreshProviderPolicy estiver configurada, a política do provedor mantida pelo cliente para um serviço será atualizada e a política efetiva será recalculada no próximo pedido. Após atualização e recálculo, a propriedade com.ibm.websphere.wspolicy.refreshProviderPolicy é desconfigurada.
O exemplo de código a seguir para um cliente de dispatch mostra a identificação de uma exceção que pode ser resolvida pela atualização da política do provedor, seguida da chamada da atualização.
try
{
dispatch.invoke(params);
}
catch (javax.xml.ws.WebServiceException e)
{
Throwable cause = e.getCause();
if ((cause instanceof NullPolicyException) || (cause instanceof PolicyException) )
{
// A exceção pode ser em razão da política do provedor não estar atualizada.
//
// Existe também uma mensagem no console que começa com os caracteres CWPOL,
// o que ajuda a decifrar e a depurar a causa do erro.
// Essa mensagem também fica disponível através do uso de
// String nlsedMessage = cause.getMessage();
Map<String, Object> requestContext = dispatch.getRequestContext();
requestContext.put(WSPConstants.REFRESH_PROVIDER_POLICY, Boolean.TRUE);
// O método a seguir pode causar outra exceção de chamada jax-ws.
// A causa ainda pode ser a política e, nesse caso, será gravada uma mensagem no
// console.
dispatch.invoke(params);
}
// Para todas as outras exceções, utilize a manipulação de exceção normal do
// aplicativo. Neste caso, suponha que não haja outras exceções e emita novamente a
// exceção inicial. Lembre-se de que WebServiceException pode ser causada por uma
// WSPolicyAdministrationException. Neste caso, uma mensagem é gravada no
// console, mas forçar uma atualização no aplicativo não pode resolver o problema.
throw e;
}