サービス・プロバイダー・ポリシーを使用するための Web サービス・クライアントおよびポリシー構成
サービス・プロバイダーが Web サービス記述言語 (WSDL) でポリシーを公開する場合、 WebSphere® Application Server サービス・クライアントのポリシー構成は、 サービス・プロバイダーによってサポートされるポリシーに基づいて動的に構成することができます。
サービス・プロバイダーは WSDL で WS-PolicyAttachment 形式を使用してポリシーを公開する必要があり、クライアントによるそのプロバイダー・ポリシーのサポートが可能である必要があります。 クライアントは、完全にプロバイダー・ポリシーに基づいてポリシー構成を行うことも、クライアントのポリシー・セット構成で定義されている制約事項を持つプロバイダー・ポリシーの一部に基づいてポリシー構成を行うこともできます。
クライアントがプロバイダー・ポリシーを取得する場合、HTTP GET 要求を使用するか、プロバイダーの WSDL を取得するための Web Services Metadata Exchange (WS-MetadataExchange) プロトコルを使用します。 クライアントがプロバイダー・ポリシーを取得する方法、およびポリシーを取得するエンドポイントは、管理コンソールまたは wsadmin コマンドを使用して構成できます。 WS-MetadataExchange プロトコルを使用してプロバイダーのポリシーを取得する場合、これにより、適切なシステム・ポリシー・セットを使用して WS-MetadataExchange GetMetadata 要求を保護できるようになります。
プロバイダー・ポリシーで複数パーツの WSDL が使用されている場合は、HTTP GET 要求を使用してプロバイダーのポリシーを取得できますが、WS-MetadataExchange プロトコルを使用することはできません。複数パーツの WSDL について詳しくは、WSDL に関するトピックを参照してください。
Web アプリケーション・クライアント・サイドのポリシーは、ランタイム構成として計算され、キャッシュされます。 この計算されたポリシーは効率的なポリシーと認識され、計算の対象となったエンドポイントまたは操作に対する後続のアウトバウンド Web サービス要求に使用されます。クライアントの元のポリシー・セット構成は変更されません。
特定のサービスの場合、デフォルトで動的ポリシー構成が一度行われ、その構成はサービスを実装するすべてのエンドポイントで同一と見なされます。理由は、使用される WSDL が同一であるためです。 この WSDL に基づいたポリシーの計算は、クライアント実行時にキャッシュに入れられ (永続ではない)、各ターゲット・サービスで共有されます。
すなわち、クラスター環境の場合、クライアントは Web サービスのエンドポイント・インスタンスごとにプロバイダー・ポリシーを再取得しないことになります。
WebSphere Application Server バージョン 8.0 以降では、 サービス参照は、クライアント・サービス用に構成された WSDL とは別の 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 トランスポート・プロパティーは、アプリケーションから継承されます。
Security Assertion Markup Language (SAML) を使用するように構成されているクライアントは、動的ポリシー構成を使用できます。ただし、クライアントを、汎用バインディングを使用するように構成しなければなりません。
レジストリーのポリシー
クライアントは、HTTP GET 要求を使用して、WebSphere Service Registry and Repository (WSRR) などのレジストリーから Web サービス・プロバイダーのポリシー構成を取得することができます。
サービス・プロバイダーのポリシーに使用する WSDL およびそれに対応するポリシーやポリシーの関連付けは、WSRR などのレジストリーに保管されています。 このポリシーには、WS-PolicyAttachments 形式のポリシー構成が含まれている必要があります。 クライアントによってそのプロバイダー・ポリシーのサポートが可能である必要があります。
レジストリー (例えば、WSRR バージョン 6.2 以降) は、WS-Policy の関連付けを含む WSDL を公開するための HTTP GET 要求の使用をサポートする必要があります。
アプリケーション・レベルではなく、サービス・ またはサービス参照 レベルでクライアントがレジストリーから取得するプロバイダー・ポリシーを適用することができます。
クライアントとレジストリーの間でセキュア接続を使用している場合は、アプリケーション・サーバーとレジストリー・サーバーの間にトラストが確立されていることを確認する必要があります。
レジストリーに認証が必要な場合は、そのレジストリーへのアウトバウンド・サービス要求を認証するためのポリシーを構成する必要もあります。デフォルトでは、HTTP クレデンシャルおよび HTTPS クレデンシャルは、Web サービス・エンドポイントとレジストリーの両方に使用されます。 そのため、すべての許可証明書を保護し、これらの許可証明書が許可されていないエンドポイントに送信されないようにすることをお勧めします。異なる HTTP および SSL トランスポート・ポリシーを指定するシステム・ポリシー・セットを追加することもできます。
ポリシーの継承
プロバイダー・ポリシーは、アプリケーション・レベルまたはサービス・レベルで関連付けることができます。 エンドポイントおよび操作は、関連サービスからポリシー構成を継承します。
ポリシーの計算
- プロバイダー・ポリシーのみを指定すると、計算されたポリシーは、プロバイダー・ポリシーと共通する、WebSphere Application Server クライアントがサポートするすべてのポリシーに基づくものになります。クライアントでそのポリシーがサポート可能である限り、事実上、プロバイダーはこのポリシーを判別します。 プロバイダー・ポリシーが関連付けられる有効範囲ポイント (エンドポイント操作) がクライアント・ポリシー・セットに関連付けられず、親有効範囲ポイントからポリシー・セット関連付けを継承しない場合は、このポリシー構成を使用できます。
- クライアント・ポリシーとプロバイダー・ポリシーを指定すると、計算されたポリシーは、プロバイダー・ポリシーと共通する、クライアントで受け入れ可能なポリシーに基づくものになります。 事実上、ポリシーはクライアント・ポリシー・セットに適合しますが、プロバイダーが決定したポリシーによってさらに制限される可能性があります。 クライアントで受け入れ可能なポリシーは、クライアント有効範囲ポイントに関連付けられるポリシー・セットか、あるいはクライアント有効範囲ポイントにより親有効範囲ポイントから継承されるポリシー・セットで定義されます。プロバイダー・ポリシーが関連付けられる有効範囲ポイント (エンドポイント操作) がクライアント・ポリシー・セットに関連付けられるか、または親有効範囲ポイントからポリシー・セット関連付けを継承する場合は、このポリシー構成を使用できます。
WS-Policy 言語では複数のポリシー選択項目を示す方法を用いるため、ポリシー計算の結果が複数になる場合があります。 例えば、サービス・プロバイダーは WS-ReliableMessaging 1.0 と WS-ReliableMessaging 1.1 をサポートする場合があります。 クライアントでもこれらの両方のバージョンをサポートする場合、クライアントはプロバイダーへの Web サービス要求でいずれかのバージョンを使用することができます。 複数の仕様バージョンがクライアントとプロバイダーの両方で受け入れ可能な場合には、最新のバージョンを使用して効率的なポリシーが計算されます。
JAX-WS ディスパッチ・クライアントでのポリシー論理積
- プロバイダー・ポリシーがサービスで提供されるすべての操作で同一である場合にのみ、クライアントは操作を有効範囲とするプロバイダー・ポリシーに適合します (意味的にも構文的にも)。
- プロバイダー・ポリシーがサービスで提供されるすべての操作で同一でない場合は、クライアントから JAX-WS WebserviceException とその原因を示す WSPolicyException (CWPOL0106E)、および該当するエラー・メッセージが返されます。
- いずれの操作にもポリシーがない場合は、クライアントはサービス・エンドポイントに対して有効なプロバイダー・ポリシーを使用します。
クライアントが保持するプロバイダー・ポリシーの更新
サービスに対してクライアントが保持しているプロバイダー・ポリシーは、アプリケーションが開始された後、Web サービスが初めて呼び出される際に更新されます。それ以降は、アプリケーションを再始動するか、またはプロバイダー・ポリシーの更新を明示的に呼び出すときに更新されます。 プロバイダー・ポリシーが更新されると、有効なポリシーが再計算されます。
アプリケーション・コードでプロバイダー・ポリシーの更新を呼び出すことができます。この方法は、JAX-WS 呼び出しに失敗したときに役立つ場合があります。その場合、例外処理で、更新済みポリシーを使用して再試行を強制することができます。 JAX-WS クライアント・プロキシーに com.ibm.websphere.wspolicy.refreshProviderPolicy というプロパティー (WSPConstants クラスの API で得られます) を設定して、JAX-WS 要求を再発行することもできます。
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;
}