目次


WS-Policy の処理を理解

WS-Policy でのインターセクション、マージ、そして正規化を探究

Comments

はじめに

Web Service Policy Framework(WS-Policy)仕様は、要件、設定、そして機能を記述するサービス・プロバイダーとサービス・リクエスターの構文とセマンティックを定義します。構文はポリシーとしてそれぞれのドメインでの必要性を表記する柔軟かつ簡潔な方法を提供します。このコンテキストのドメインは、下記のようなサービスへと応用される汎用的な興味の対象です。

  • セキュリティー
  • プライバシー
  • アプリケーションの優先権
  • ユーザー・アカウントの優先権
  • トラフィック制御

仕様はドメインと独立して実行されるそれらのポリシーの処理モデルをも表記します。ポリシーを処理する定義されたオペレーションには 3 種類(正規化、インターセクション、そしてマージ)あります。この記事はそれらの機能を考察し、この処理にあるそれほどに一目瞭然ではない潜在的重要性を強調します。

WS-Policy フレームワーク仕様が使用する基本的な用語を網羅するのに少々時間をさくのは、意義のあることです。この記事ではアサーション(Assertion)とオルタナティブ(Alternative)と言う単語が頻繁に使用されていますので、それらの単語に慣れるように次の章で説明します。

アサーション

アサーションはポリシーの基本的な単位です。それはポリシーを処理するインフラストラクチャーへの命令としても解釈されます。例えば、アサーションはメッセージが暗号化されることを宣言できます。このアサーションの実際の定義は、WS-Security Policy のドメインの仕様にあります。

このように、個々のアサーションの意味はそれぞれのドメインに特化されそれぞれの別々の仕様にて識別されます。(ドメインに特定されたそれぞれのアサーションの詳細は、WS-Policy のフレームワークの守備範囲から外れます。)とはいえ、WS-Policy のフレームワークはそれぞれのアサーションを不透明だと見なします。

それぞれのアサーションはその Qualified Name(QName)により識別されます。アサーションは簡素なストリングや(多数のサブエレメントや属性をともなう)複雑なオブジェクトにもなり得ます。しかしながら、どの WS-Policy フレームワークの処理とも関与するのは、ルートの XML エレメントの QName のみです。

オルタナティブ

ポリシーはアサーションとネストされたオペレーター(<wsp:All><wsp:ExactlyOne>)の組み合わせ、そして Optional 属性から構成されます。与えられた Web サービス呼び出しにて、ポリシーを処理するインフラストラクチャーへの命令の完全なセットを形成するために、このポリシー構文はアサーションの受け入れられる組み合わせを記述するのに使われます。それぞれのアサーションのセットはオルタナティブと称されます。

Optional 属性または <wsp:ExactlyOne> オペレーターを含むポリシーのみが複数のオルタナティブをいだけることに注意してください。反対に言えば、アサーションそして <wsp:All> オペレーターのみを使って構築されたポリシーは、単一のオルタナティブに縮小することが可能です。

ポリシーにより実行されるそれぞれの処理のタイプを、次に続く章にて網羅します。

正規化の処理

Web サービスのポリシー・フレームワークの柔軟な構文は、潜在的に複雑なポリシーへと導く可能性を持っています。ポリシーの Normal フォームは、ポリシーの理解を明確にして操作を簡素化するために定義されました。ポリシーの処理にある基本的なオペレーションがいかにして実行されるかが、Normal フォームのポリシーの真髄なのです。

マージまたはインターセクションのオペレーションでポリシーを処理するには、ポリシーは標準化された Normal フォーマットとしてまとめられなくてはなりません。Normal フォームはただひとつ選りすぐりのオペレーター <wsp:ExactlyOne>> を含みます。この定義された Normal フォームは、リスト 1 にて示したスキーマを持つ簡素化された XML フォーマットを使用します。

リスト 1. Normal フォームの例
<wsp:Policy ... >
   <wsp:ExactlyOne>
    [<wsp:All> [ <assertion ...>... </assertion>]* </wsp:All> ]*
   </wsp:ExactlyOne>
</wsp:Policy>

正規化されたポリシーの中で <wsp:ExactlyOne> オペレーターが一度そして一度のみ使われるのに注目してください。要するに、<wsp:ExactlyOne> オペレーターの中にあるそれぞれのエレメントはポリシーのオルタナティブなのです。それぞれのポリシーのオルタナティブは、<wsp:All> オペレーターの中にてカプセル化されています。

正規化されたポリシーには 2 つ特殊なケースがあることを述べるのは、意味のあることです。リスト 2 にて示されるとおり、最初の例は空のポリシーです。

リスト 2. 空のポリシー
<wsp:Policy ... > <wsp:ExactlyOne>
      <wsp:All/>
   </wsp:ExactlyOne>
</wsp:Policy>

<wsp:All/> に表記される単一の空のポリシーにあるオルタナティブは、アサーションが必要とされていないことを示します。これは、ポリシーのインフラストラクチャーが何も行動を起こさなくてもよいと言っているのと同じことです。空のオルタナティブは他の空ではないオルタナティブと共に正規化されたポリシーにて現われる可能性があります。単に何も行動を起こさないのが有効な選択肢であると、それは述べているわけなのです。

正規化されたポリシーでの第二の特殊なケースは、ヌル・ポリシーです。

リスト 3. ヌル・ポリシー
<wsp:Policy ... >
   <wsp:ExactlyOne/>
</wsp:Policy>

ヌル・ポリシーは、妥当なオルタナティブがないことを示します。この Web サービスへの呼び出しの試みが成功しないのは、要求された状況に従いそれがどのようにして使用されるかに関する定義されたポリシーがないからです。これの例として、(サポートするセキュリティー・インフラストラクチャーをサービス要求者が所持しない)特定のタイプの暗号化メソッドに問い掛けるサービス・プロバイダーがあります。そのような場合、ポリシー・フレームワークは互換性のあるポリシーがヌルであると判断し、このためサービスの呼び出しは機能しません。

Optional 属性の使用は、より深き考察すべき要点を伴います。もしもポリシーが単に 2 つのオプショナル・アサーション(optional assertions)からなるのであれば、実質上 4 つの順列が可能性としてあり、それゆえにその Normal フォームでは 4 種類のオルタナティブがあることになります。同様に 3 つのオプショナル・アサーションは 8 種類のオルタナティブをもたらします。より多くのアサーションが追加されれば、可能性としてあり得るオルタナティブの数はバイナリ・エスカレーション(binary escalation)で膨張するのが明白です。受け入れられないほどに多数のオルタナティブを作成するには比較的少数のオプショナル・アサーションで十分ですので、Optional 属性の使用には注意を払うべきです。

正規化の使用の用例

正規化のプロセスは、段階を踏まえることにより説明できます。それがどのように機能するかを示すそれぞれの段階を、リスト 4 にて表わします。

リスト 4. 基本的な正規化されたポリシー
<wsp:Policy ...>
   <wsp:All>
      <wsp:ExactlyOne>
         <nsSecurityAssertion wsp:Optional="true"/>
         <nsReliableMessagingAssertion/>
      </wsp:ExactlyOne>
      <nsTransactionAssertion/>
      <nsAuditAssertion/>
   </wsp:All>
</wsp:Policy>

ステップ 1: @wsp:Optional 属性を拡張

まず、@wsp:Optional 属性を拡張します。オプショナルなアサーションのそれぞれの発生のために 2 つの入力が作成されたことを意味します。入力のうちの 1 つはアサーションを含み、もう 1 つの入力にはアサーションはありません。それら 2 つのオプションを表記するには、<wsp:ExactlyOne>> オペレーターを使用します。アサーションの存在しないオプションを表記するには、空のポリシーの構文を使用します。例えば、

<nsSecurityassertion wsp:Optional="true"/>

上記を拡張すれば下記のようになり、

<wsp:ExactlyOne>
   <nsSecurityassertion/>
   <wsp:All/> 
</wsp:ExactlyOne>

例にあるポリシーはリスト 5 のようになります。

リスト 5. 修正ずみの正規化されたポリシー
<wsp:All>
   <wsp:ExactlyOne>
      <wsp:ExactlyOne>
         <nsSecurityAssertion/>
         <wsp:All/>
      </wsp:ExactlyOne>
      <nsReliableMessagingAssertion/>
   </wsp:ExactlyOne>
   <nsTransactionAssertion/>
   <nsAuditAssertion/>
</wsp:All>

ステップ 2: ポリシー・オペレーターを縮小

次に、<wsp:All> オペレーターにラッピングされたアサーションを含む単一の <wsp:ExactlyOne> しかない状態になるまで、ポリシーにあるオペレーターの縮小を繰り返すべきです。可能性としてあり得る結果の数は有限ですので、これは想像されるほどに複雑なわけではありません。例えば、<wsp:All> の中にある <wsp:All> や、<wsp:ExactlyOne> の中にある <wsp:ExactlyOne> の場合、結合法則によりそれぞれが単一のオペレーターに縮小されます。

下記の例では、どのようにしてアサーションから始めて外側に向かって作業を進めるかを示します。この例にて、<wsp:ExactlyOne> をキャンセルした場合には、リスト 6 にて示される結果を得られます。

リスト 6. 縮小するオペレーター
<wsp:All>          <wsp:ExactlyOne>
      <nsSecurityAssertion/>
      <wsp:All/>
      <nsReliableMessagingAssertion/>
   </wsp:ExactlyOne>
   <nsTransactionAssertion/>
   <nsAuditAssertion/>
</wsp:All>

ステップ 3: 統一されるまで縮小のプロセスを繰り返す

単一の <wsp:ExatclyOne> オペレーターのみが外側に残されるまで、縮小のプロセスは繰り返されます。この例で唯一トリッキーな操作は、<wsp:All> オペレーターそして <wsp:ExatclyOne> オペレーターを入れ換えることです。ここでのテクニックは、クロス積の原理を採用することです。

単独のアサーション(<nsSecurityAssertion/><wsp:All><nsReliableMessagingAssertion/>)はそれぞれ 1 つずつ <wsp:ExactlyOne> から取り外され、外側の <wsp:All> にある全てのアサーション(<nsTransactionAssertion/><nsAuditAssertion/> >)と結合させられます。

<wsp:ExactlyOne>
   <wsp:All>
      <nsSecurityAssertion/>
      <nsTransactionAssertion/>
      <nsAuditAssertion/>
   </wsp:All>
   <wsp:All>
      <wsp:All/> <nsTransactionAssertion/>
      <nsAuditAssertion/> </wsp:All>
   <wsp:All>
      <nsReliableMessagingAssertion/>
      <nsTransactionAssertion/>
      <nsAuditAssertion/>
   </wsp:All>
</wsp:ExactlyOne>

ステップ 4: 最後の調整

Normal フォームに達するには、最後に残されるちょっとした整理が必要です。<wsp:All/> の中にある <wsp:All/>(空のポリシー)を除去できます。この空のアサーションがこのアサーションが実行されないことを示すからなのです。そのアサーションは名前を付けられはしないものの、ほのめかせられます。この例では、それは事実上オプショナルな SecurityAssertion です。これが、アサーションの出番のないケースなのです。

これが正規化されたポリシーの定義と比較されれば、これが正規化された形として存在するのはご覧のとおりです。これは、<wsp:All> オペレーターを含む 1 つの <wsp:ExactlyOne> オペレーターです。この例でのポリシーが 3 つのオルタナティブを生んだのがおわかりでしょう。

マージ

マージとは、単一のポリシーを形成するためにサブ・ポリシーを結合するプロセスです。ポリシーを構築または取得する方法がばらばらなため、このオペレーションは必要です。例えば、WS-PolicyAttachment 仕様は WSDL のエレメントに対してどのようにしてポリシーが接続されるかを説明します。さらに、WSDL にあるそれぞれのエレメントは、それと関連するポリシーのリストを所有できます。ポリシーの処理において、これらのポリシーを互いに結合させて単一のマージされたポリシーを形成するのは必要なのです。

マージのプロセスは、Normal フォームに変換されたポリシーにて実行されます。それぞれのサブ・ポリシーからのオルタナティブは、新規のマージのオルタナティブを形成するために結合させられます。結合のプロセスは、クロス積のパターンに従います。(すべての順列が消耗されるまで)それぞれのポリシーからオルタナティブが順番に 1 つずつ処理されます。リスト 7 そしてリスト 8 は、プロセスにおいて互いにマージされる予定の 2 つのポリシーを示します。

リスト 7. Policy P1
<wsp:Policy wsu:id="P1"...>
   <wsp:ExactlyOne>
      <wsp:All>
         <nsSecurityAssertion/>
      </wsp:All>
      <wsp:All>
         <nsReliableMessagingAssertion/>
      </wsp:All>
   </wsp:ExactlyOne>
</wsp:Policy>

上記と下記とをマージできます。

リスト 8. Policy P2
<wsp:Policy wsu:id="P2"...>
   <wsp:ExactlyOne>
      <wsp:All>
         <nsTransactionAssertion/>
      </wsp:All>
      <wsp:All>
         <nsAuditAssertion/>
      </wsp:All>
   </wsp:ExactlyOne>
</wsp:Policy>

マージされたポリシーを得るには、ポリシーP1 にある個々のオルタナティブはポリシーP2 にあるオルタナティブと結合します。P1 と P2 はすでに Normal フォームですので、それぞれのオルタナティブからアサーションを取り出してすべてのアサーションを含む新規のオルタナティブを形成するだけの話です。

リスト 9. P2 と結合させられた P1
<wsp:Policy wsu:Id="P1_Merged_with_P2"...>
   <wsp:ExactlyOne>
      <wsp:All>
         <nsSecurityAssertion/>
         <nsTransactionAssertion/>
      </wsp:All>
      <wsp:All>
         <nsSecurityAssertion/>
         <nsAuditAssertion/>
      </wsp:All>
      <wsp:All>
         <nsReliableMessagingAssertion/>
         <nsTransactionAssertion/>
      </wsp:All>
      <wsp:All>
         <nsReliableMessagingAssertion/>
         <nsAuditAssertion/>
      </wsp:All>
   </wsp:ExactlyOne>
</wsp:Policy>

アサーションの複製から生じるオルタナティブの意味を判断するのは、潜在的なポリシーのインフラストラクチャーの持つ責任です。それぞれの元々のポリシー(ここでの例では、P1、P2)にて複数の選択肢がある場合には、マージされたポリシーのサイズの急激な成長の潜在的な可能性があることを、ここにて述べておくべきです。それを承知のうえで、サイズの膨張へと直ぐに導く Optional 属性の使用に特別な注意を払いましょう。

インターセクション

インターセクションとは、共通のオルタナティブを有する 2 つの Web サービスを比較するプロセスです。相互作用の両側が最低 1 つのポリシーのオルタナティブにて合意する場合にのみ、その相互作用の実行が可能となります。要求者がその能力と要件をポリシーのフォームで表現するときに、このオペレーションは一般的に使われます。要求者のポリシーは、そのローカルのランタイム・インフラストラクチャーが処理能力を持つことを、アサーションに対して示すであろうと考えられます。2 つのポリシーのインターセクションは 0 かそれ以上の(両方のパーティーが合意する)オルタナティブを提供します。

インターセクションのプロセスは最初に予想されるほどには当たり前にはならないでしょう。「ドメインから中立したポリシーのフレームワークは、どのようにして 2 つのアサーションが同じであるかどうかを判断するのでしょうか?」と言う問いかけを考慮してみてください。アサーションの意味は、それらを定義するドメインのみに知られています。この論題に対処するには、ドメインから中立したポリシーのフレームワークにできることには限界があります。このプロセスを完了するにはドメインに関する知識が必要です。

プロセスは、両方のポリシーが Normal フォームに拡張されることにより開始されます。2 つの正規化されたポリシーは一度に 1 つのオルタナティブごとに検査されます。明らかに異なるオルタナティブを除外するのが、最初の段階の意図するところです。2 つのオルタナティブの Vocabulary を検査することにより、それは達成されます。オルタナティブの Vocabulary はそのオルタナティブでのアサーションの QNames の集合です。Vocabulary が適合しなければ、2 つのオルタナティブは明確に異なりインターセクションの処理から外されます。

この Vocabulary の比較は、これらの QNames の複製を考慮に入れません。オルタナティブにて同一の Qname をいだく複数のアサーションがあれば、2 つ目のオルタナティブからの同一の Qname を持つアサーションといくつでも適合できます。比較のプロセスは、これらのアサーションがかかえる可能性のある属性や値を考慮に入れません。このため 2 つのオルタナティブが同一の Vocabulary を共有するのは可能ですが、一部の状況においては互いに矛盾する場合もあります。例えば、<nsAssertionvalue="on"/><nsAssertionvalue="off"/> と同一の QName を持ちます。比較のプロセスは根源的には単に 2 つのオルタナティブが同じ言語を駆使することを確かめているだけです。それを分類するのは、適合するオルタナティブを作成するインターセクションの次の段階です。

異なる Vocabulary を所持する 2 つのオルタナティブには互換性がないとみなされます。2 つのオルタナティブが適合する Vocabulary を持つ場合には、それらは交差するポリシーにて単一で新規のオルタナティブを作成するように結合します。オルタナティブのアサーションは結合されていますので、結果として得られるオルタナティブは、(そのアサーションの多くから複製されたものを含み)矛盾するアサーションを含むかも知れません。しかしながら、アサーションが詳細の改良の面のみにて異なる可能性が高いのです。例えば、要求者のポリシーからのオルタナティブからのアサーションは、それが暗号化をサポートする能力を持つことをただ単に述べるだけかも知れません。このため、それはルート・エレメントのみから構成され、属性または値を伴わない可能性があります。サービス・プロバイダーのポリシーのオルタナティブからの同等の適合するアサーションは、どの暗号化が使用されるべきかに関する詳細、そして改良に必要な属性を含むかも知れません。

2 つのポリシーからのオルタナティブを結合させるプロセスは、クロス積の方法で実行されます。個々のポリシーからのそれぞれのオルタナティブは、それとは別のポリシーからの個々のオルタナティブと比較されます。インターセクションされたポリシー(Intersected policy)が巨大になる可能性があることを、ここにて述べておくべきでしょう。元々のポリシーでの選択肢が多ければ、その分可能性としてあり得る組み合わせも増えます。

これらの組み合わせられたオルタナティブがどのようにして解釈されるかを定義するのは、WS-Policy のフレームワークの仕様の守備範囲から外れます。結合されたオルタナティブをインフラストラクチャーにとって何か意味があるものとして合理的に解釈するには、ドメインの知識が必要とされます。例えば、WS-Security Policy のドメインは、2 つのセキュリティーのアサーションが互いに矛盾するのかそれとも互いを補足する改良点なのかに関する唯一の情報源となります。

同一の QName を持つオルタナティブの中にあるそれぞれのアサーションでの複数のオカレンスを、インフラストラクチャーへの単一の意味ある命令に縮小するプロセスは、問題として取り上げられているアサーションの意味に対する知識を必要とします。「2 度にわたるアサーションの登場は、このアサーションに定義されるオペレーションをインフラストラクチャーが 2 回にわたり実行しなくてはならないことを意味するのでしょうか?」と言う質問を考慮してください。その解答は「これはここにて記述されるドメインから中立した処理に向けられた質問ではない。」であり、それはドメインに特定の知識から得られるべきです。

新たにインターセクションされたポリシーは、Web サービスの相互作用の両側に受け入れられサポートされるオルタナティブの互換性のある集合を導き出す前に、さらなる処理をまだ必要とするかも知れません。必要とされる振る舞いを実行する責任を持つ潜在的なインフラストラクチャーに対して意味不明な矛盾をオルタナティブが含むかも知れず、その場合には呼び出しは失敗に終わるかも知れません。

ヌルや空の場合のようなポリシーの特殊例でのインターセクションに起こりえる効果について触れるのも大事です。ヌルのポリシーを他のポリシーとインターセクションさせると、ヌルのポリシーと言う結果をまねきます。1 つの例外を除き、空のポリシーを別の何かとインターセクションさせると、ヌルのポリシーと言う結果をまねきます。2 つの空のポリシーがインターセクションされれば、空のポリシーができあがります。

サービス・プロバイダーのポリシーと要求者のポリシーがあると想定してください。これらのポリシーは正規化され、下記のようになります。

<wsp:Policy wsu:Id="Provider_Policy"...>
   <wsp:ExactlyOne>
      <wsp:All> <nsSecurityAssertion level="high"/> <nsReliableMessagingAssertion/>
      </wsp:All>
      <wsp:All>
         <nsSecurityAssertion level="medium"/>
         <nsTransactionAssertion/>
      </wsp:All>
   </wsp:ExactlyOne>
</wsp:Policy>

要求者側のポリシーは、以下のとおりです。

<wsp:Policy wsu:Id="Requester_Policy"...>
   <wsp:ExactlyOne>
      <wsp:All>
         <nsSecurityAssertion/>
         <nsReliableMessagingAssertion timeout="100"/>
         <nsReliableMessagingAssertion retries="3"/>
      </wsp:All>
   </wsp:ExactlyOne>
</wsp:Policy>

インターセクションのプロセスは <wsp:All> オペレーターによりバウンドされたそれぞれのオルタナティブを処理します。QNames のアサーションのみが比較されます。要求者側のオルタナティブがプロバイダーのポリシーにある最初のオルタナティブのみと適合することをそれは意味します。これら 2 つのオルタナティブは結合し、インターセクションされたオルタナティブを作成します。

<wsp:All>
   <nsSecurityAssertion level="high/>
   <nsSecurityAssertion/>
   <nsReliableMessagingAssertion timeout="100"/>
   <nsReliableMessagingAssertion retries="3"/>
   <nsReliableMessagingAssertion/>
</wsp:All>

このポリシーのオルタナティブを解釈してからプロセス・モジュールに対して意味を持つアサーションに瓜二つの Qnames のアサーションを結合させるのは、ポリシーのプロセスのインフラストラクチャーに与えられた任務です。例えば、ReliableMessagingAssertion アサーションは単一のアサーションとして結合させられます。

 <nsReliableMessagingAssertion timeout="100" retries="3"/>

Web サービス・インターオペラビリティーの論題がさらに顕著になるにつれ、ポリシーの使用法はより重要になります。アプリケーションの開発者そして配置者がポリシーの処理の潜在的な重要性を回避するのが不可能なのは、現実味をおびた話です。重要になる可能性の高い論題の一部に、この記事は触れました。この記事は現時点での知識と経験を基にしています。これが成長を続ける題目であることは疑いようもありません。Web サービスが進化を遂げ続けより深い論題が持ち上げられるにつれ、多くの変更がこれからももたらされることでしょう。


ダウンロード可能なリソース


関連トピック

  • Web サービスに関連する数百ものタイトルを含む技術書物の包括的なリストのあるDeveloper Bookstoreを訪れてみて下さい。
  • 知識欲の袋に底はないのでしょうか?SOA and web services のページは、数百にもわたる情報豊かな記事と、Web サービス・アプリケーションの開発方法についての(初級、中級、そして上級の)チュートリアルを提供します。

コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=241867
ArticleTitle=WS-Policy の処理を理解
publish-date=12072004