使用服务提供程序策略所需的 Web Service 客户机和策略配置
如果服务提供程序在其 Web Service 描述语言 (WSDL) 中发布其策略,那么您可以根据 WebSphere® Application Server 服务客户机的服务提供程序所支持的策略来动态地配置该客户机的策略配置。
服务提供程序必须在其 WSDL 中以 WS-PolicyAttachment 格式发布其策略,客户机必须能够支持那些提供程序策略。客户机可以使其策略配置完全基于提供程序的策略,也可以部分基于提供程序的策略并实施由客户机的策略集配置所定义的限制。
客户机通过使用 HTTP GET 请求或 Web Service 元数据交换 (WS-MetadataExchange) 协议获取提供程序策略,以获取提供程序的 WSDL。通过使用管理控制台或 wsadmin 命令,您可以配置客户机获取提供程序策略的方式以及从哪个端点获取该策略。如果使用 WS-MetadataExchange 协议来获取提供程序的策略,那么有一个优点,即,您可以使用适当的系统策略集来保护 WS-MetadataExchange GetMetadata 请求。
如果提供程序策略使用多重部件 WSDL,那么您可以使用 HTTP GET 请求来获取提供程序策略,但是您不可以使用 WS-MetadataExchange 协议。有关多重部件 WSDL 的更多信息,请参阅关于 WSDL 的主题。
会将 Web 应用程序客户机端策略作为运行时配置来计算和高速缓存。这个计算出的策略称为有效策略,并用于随后的出站 Web Service 请求,以用于执行计算的端点或操作。客户机的原始策略集配置保持不变。
对于特定服务,在缺省情况下,一旦发生动态策略配置,并且假设这个配置与实现服务的所有端点相同(因为他们具有同一 WSDL)。基于此 WSDL 进行的策略计算将在客户机运行时中进行高速缓存(而不会保存下来)并与每个目标服务共享。
在集群环境中,这意味着客户机不会再次获取 Web Service 每个端点实例的提供程序策略。
在 WebSphere Application Server V8.0 及更高版本中,可以将服务引用配置为使用不同于为客户机服务配置的 WSDL 文档。缺省情况下,服务引用会从其父服务继承策略集和 WS-Policy 配置;但是,如果需要,可以覆盖该策略集和 WS-Policy 配置。请参阅使用 WS-Policy 来交换标准格式的策略以获取更多详细信息。
如果每个端点实现都需要不同的策略配置,那么您必须为每个端点创建新端口。然后,可以对每个端点指定不同的策略配置。
HTTP、SSL 和 JMS 之类的传输策略不能以 WS-PolicyAttachment 格式表达,因此客户机无法获取服务提供程序的传输策略。如果客户机需要传输策略,那么您必须将这些策略配置成该客户机的策略集配置的组成部分。
对于 HTTP GET 请求,当该请求以此端点所在的位置为目标时,该请求将与应用程序使用相同的 HTTP 和 SSL 传输策略。当 HTTP GET 请求以其他端点为目标时,您还可以连接系统策略集以指定不同的 HTTP 和 SSL 传输策略。
对于 WS-MetadataExchange GetMetadata 请求,将使用指定的系统策略集中的 WS-Security 配置。将从应用程序继承 HTTP 传输属性。
已配置为使用安全性断言标记语言 (SAML) 的客户机可以使用动态策略配置。但是,您必须将此客户机配置为使用常规绑定。
注册表中的策略
通过使用 HTTP GET 请求,客户机可以从 WebSphere 服务注册表和存储库 (WSRR) 之类的注册表中获取 Web Service 提供程序的策略配置。
服务提供程序的策略的 WSDL 及其相应的策略和策略附件存储在 WSRR 之类的注册表中。该策略必须包含其 WS-PolicyAttachments 格式的策略配置。客户机必须能够支持那些提供程序策略。
注册表必须支持使用 HTTP GET 请求来发布包含 WS-Policy 连接(例如,WSRR V6.2 或更高版本)的 WSDL。
可以在服务 或服务引用 级别而不是应用程序级别应用客户机从注册表获取的提供程序策略。
如果在客户机和注册表之间存在安全连接,那么您必须确保在应用程序服务器和注册表服务器之间建立了信任。
如果注册表要求认证,那么您还必须配置策略以认证至该策略的出站服务请求。 缺省情况下,HTTP 和 HTTPS 凭证同时用于 Web Service 端点和注册表。因此,建议对任何授权凭证进行保护,并确保这些凭证不会被发送到未经授权的端点。您还可以连接系统策略集以指定不同的 HTTP 和 SSL 传输策略。
策略继承
可以在应用程序级别或服务级别连接提供程序策略。端点和操作将从相关服务继承其策略配置。
计算策略
- 如果您只指定了提供程序策略,那么计算而得的策略将基于 WebSphere Application Server 客户机所支持的所有策略与提供程序策略的交集。实际上,策略由提供程序确定,条件是客户机能够支持该策略。如果提供程序策略所连接的范围点(端点操作)未连接到客户机策略集,并且未从父范围点继承策略集附件,那么此策略配置可用。
- 如果您指定了客户机策略和提供程序策略,那么计算而得的策略将基于客户机可接受的策略与提供程序策略的交集。实际上,此策略与客户机策略集相符,但可能会受提供程序所指定的策略的进一步限制。客户机可接受的策略由连接到客户机范围点的策略集定义,或者由客户机范围点从父范围点继承的策略集定义。如果提供程序策略所连接的范围点(端点操作)连接到客户机策略集,或者从父范围点继承了策略集附件,那么此策略配置可用。
WS-Policy 语言提供了一种方法来表达多个策略选项,以使策略计算可以生成多个结果。例如,服务提供程序可能同时支持 WS-ReliableMessaging 1.0 和 WS-ReliableMessaging 1.1。如果客户机也同时支持这两个版本,那么客户机可以在其向提供程序发出的 Web Service 请求中使用任何一个版本。在这种情况下,客户机和提供程序都可接受多个规范版本,因此有效策略将使用最新版本计算而得。
JAX-WS 分派客户机中的策略交集
- 仅当提供程序策略在语义和语法方面对于服务所提供的所有操作而言都完全相同时,客户机才会在提供程序策略以操作为范围的情况下进行编译。
- 如果提供程序策略并非对于服务所提供的所有操作都完全相同,那么客户机将返回原因为 WSPolicyException 的 JAX-WS WebserviceException (CWPOL0106E) 以及适当的错误消息。
- 如果任何操作都没有策略,那么客户机将使用服务端点的有效提供程序策略。
刷新客户机所拥有的提供程序策略
客户机为服务保留的提供程序策略将在启动应用程序后调用 Web Service 时进行首次刷新。此后,在应用程序重新启动时,或者当您显式地调用提供程序策略更新操作时,将刷新提供程序策略。刷新提供程序策略时,将重新计算有效策略。
您可以在应用程序代码中调用提供程序策略更新操作。在 JAX-WS 调用失败时,这样做可能有用;在异常处理中,可以强制使用刷新后的策略进行重试。您可以对 JAX-WS 客户机代理设置以下属性(这些属性在 API 的 WSPConstants 类中),然后重新发出 JAX-WS 请求:com.ibm.websphere.wspolicy.refreshProviderPolicy。
如果设置了 com.ibm.websphere.wspolicy.refreshProviderPolicy 属性,那么将刷新客户机所拥有的用于某个服务的提供程序策略,并且将在处理下一个请求时重新计算有效策略。进行刷新和重新计算后,将取消设置 com.ibm.websphere.wspolicy.refreshProviderPolicy 属性。
以下分派客户机代码示例说明如何标识一个可以通过依次刷新提供程序策略和调用刷新操作来解决的异常。
try
{
dispatch.invoke(params);
}
catch (javax.xml.ws.WebServiceException e)
{
Throwable cause = e.getCause();
if ((cause instanceof NullPolicyException) || (cause instanceof PolicyException) )
{
// The exception might be because the policy of the provider is not up to date.
//
// There is also a message on the console that starts with the characters CWPOL,
// which helps to decipher and debug the cause of the error.
// This message is also available by using
// String nlsedMessage = cause.getMessage();
Map<String, Object> requestContext = dispatch.getRequestContext();
requestContext.put(WSPConstants.REFRESH_PROVIDER_POLICY, Boolean.TRUE);
// The following method might cause another jax-ws invocation exception.
// The cause might still be policy, in which case, a message is written to the
// console.
dispatch.invoke(params);
}
// For all other exceptions, use the normal exception handling for the
// application. In this case, assume there are no other exceptions and rethrow the
// initial exception. Remember that the WebServiceException might be caused by a
// WSPolicyAdministrationException. In this situation, a message is written to the
// console, but forcing a refresh in the application cannot resolve the problem.
throw e;
}