ポリシー

メディエーション・ポリシーを作成する際に、WSRR を「ポリシー・オーサリング・ポイント (Policy Authoring Point)」として、また WebSphere® DataPower® を「ポリシー実施ポイント (Policy Enforcement Point)」として使用するための実装の詳細を説明します。

WSRR のポリシー

WSRR を使用して、SLA (サービス・レベル・アグリーメント) ポリシー、メディエーション・ポリシー、モニタリング・ポリシー、カスタム・ポリシーなどのすべての SOA ポリシーを作成することができます。 Business Space ユーザー・インターフェースを使用すると、WSRR でポリシー文書を作成、更新、または削除することができます。 ポリシー文書には、特定のポリシー・ドメインに対していくつかのポリシーを指定するポリシー式を含めることができます。 あるいは、他の文書から既存のポリシーをアセンブルするポリシー文書を作成することもできます。 個々のポリシーは、ポリシーを文書に追加する際に指定したポリシー ID を使用して参照されます。 ポリシー式はポリシーの宣言を表し、WS-Policy 文書の <wsp:Policy> 要素に相当します。

Business Space でメディエーション・ポリシーを作成する手順については、新規メディエーション・ポリシーのオーサリングを参照してください。

メディエーション・ポリシー・アサーション

サービス・レベル・アグリーメント (SLA) は、サービスの提供するサービス品質が指定された標準に合致するビジネスの要件に基づいています。 サービスが設計される間に、サービスの動作のロジックをガイドするための機能要件が作成されます。 それと同時に、サービスの分析や設計の一環として非機能要件を指定して、サービスに期待されるサービスの品質を指定します。 例えば、ビジネスに、顧客のインターネット照会に応じて情報を提供するサービスがあるとします。 目標は、3 秒以内に応答を返すことです。 エンドツーエンド・トランザクションの設計の一環として、ビジネスの非機能要件を満たすためには、このサービスが 2 秒以内に情報を返す必要があると判断されます。

サービスがその SLA に合致することを保証するため、サービスのパフォーマンスに関するランタイム・チェックを実装し、要件を満たす場合にアクションを実行するポリシーを作成することができます。 例えば、通常 (全体の時間の 95%) は 2 秒以内にサービス応答を提供できる、サービスの 1 次エンドポイントがあるとします。 SOA 設計者は、2 次エンドポイントを別のサーバー上に作成します。この 2 次エンドポイントは、1 次エンドポイントで障害が発生した際のホット・スタンバイとして使用できますが、1 次エンドポイントがトランザクションの負荷に対応しきれない場合に、オーバーフローしたトラフィックに対して使用することも許可されています。 サービス応答時間を検査して、SLA に合致する必要がある場合にトラフィックを再経路指定するポリシーを作成できます。

ランタイム・ポリシーによって SLA が保守されるもう 1 つの例は、それぞれ優先順位レベルが異なる多様なコンシューマーを持つトランザクションにサービスが応答している場合です。 単純な例として、「Gold」および「Bronze」の顧客がいて、ビジネスでは「Gold」の顧客に対してのみ特定のサービスの品質を保証する場合を考えます。 この例では、コンシューマーが「Gold」であるかどうかを検査し、そうであれば 2 次エンドポイントへ再経路指定します。「Bronze」の顧客は、それより低速の応答時間で対応することになります。 ビジネスでこの決定が下される理由は、「Bronze」の顧客に「Gold」の顧客の SLA に合致する応答時間を提供するための費用に対して、得られる増分収益が不十分であるためです。

3 つ目の例として、サービスが可能な限り十分機能しても、負荷がかかっていると判断される場合には、優先順位の低いコンシューマー・サービスからのメッセージをキューに入れたり、拒否したりする場合があります。 例えば、予期しない時間のコンシューマー要求で、バッチ・ルーチンによってシステムがフラッディングしてしまう場合が挙げられます。 サービスの品質を守るために、営業時間中にのみ有効になるランタイム・ポリシーを作成して、この時間内はすべてのバッチ要求を拒否することができます。

より一般的には、メディエーション・ポリシーを使用して、クライアント (コンシューマー) からの着信メッセージに対して妥当性検査と変換を行ってから、サーバー (プロバイダー) に表示することができます。

ポリシーはこのタイプのメッセージの妥当性検査や変換をサポートします。 ポリシーは、プロバイダー・サービスに対してのみ指定することも、特定のコンシューマーとプロバイダーのペアや、プロバイダー・サービスの匿名コンシューマーに対して指定することもできます。 匿名の顧客に対するポリシーを指定すると、他のポリシーが適用されないコンシューマーに対してのみ適用されるデフォルト・ポリシーを定義することができます。 このフィーチャーを使用すると、自身を明らかにしない不正なコンシューマーに対してポリシーを指定することができます。 それによって、そのようなコンシューマー・サービスのトランザクションを拒否することができます。 これは、プロバイダー・サービスをダウンさせる目的でシステムをトランザクションでフラッディングさせようとするコンシューマー・ハッカーからのサービス妨害攻撃を防ぐのに役立ちます。

メディエーション・ポリシーの条件

メディエーション・アサーションを作成して、ランタイム・ポリシーによって、サービスの SLAを制御したり、コンシューマーからプロバイダーへのメッセージを変換したり、コンシューマー・メッセージのメッセージ・スキーマを妥当性検査したりすることができます。

メディエーション・ポリシーの特殊なタイプである SLA ポリシー条件は、 条件を指定した従来の if-then-else 構造を効率的に使用して、その条件の評価に基づいて一連のアクションが実行されるようにします。 条件の指定はオプションです。 条件が指定されない場合は True に評価される論理条件と同等と評価され、その結果、指定されたどのアクションも実施されます。

条件が指定される場合、その条件はブール式またはスケジュール仕様のいずれかで構成する必要があります。これら両方を含むこともできます。

スケジュール

スケジュールを指定する場合、そのスケジュールはポリシーが有効になる時点を特定します。 日時はローカルの「ポリシー実施ポイント (Policy Enforcement Point)」によって評価され、使用されるタイム・ゾーンはその「ポリシー実施ポイント (Policy Enforcement Point)」のタイム・ゾーンになります。 スケジュールが指定されない場合、ポリシーは「ポリシー・オーサリング・ポイント (Policy Authoring Point)」から「ポリシー実施ポイント (Policy Enforcement Point)」にダウンロードされるとすぐに開始し、無期限に続行されます。

スケジュールでは、オプションの開始日とオプションの停止日、オプションの日次時間フレーム、およびオプションの曜日のリストを定義します。 例えば、2012 年 10 月 1 日から 2012 年 10 月 30 日までの毎週水曜日と日曜日に、午前 8 時から午後 5 時まで有効になるようにスケジュールを定義できます。

このスケジュールに指定可能なパラメーターは、以下のとおりです。
  • StartDate - このオプション属性は、スケジュールが有効になる日付を xs:date という形式で指定します。 「StartDate」に指定された日付から有効になり、この属性が指定されない場合、スケジュールは即日有効になります。 (xs:time ハイパーリンクをクリックして、この業界標準について理解してください。)
  • StopDate - このオプション属性は、スケジュールが有効でなくなる日付を xs:date という形式で指定します。 「StopDate」に指定された日付は有効期間には含まれないため、開始日よりも後の日付を指定する必要があります。 停止日が開始日と同じかそれより前の日付である場合、スケジュールは有効になりません。 この属性が指定されない場合、スケジュールは無期限で有効になります。
  • Daily - このオプション要素は、スケジュールが有効になる日次時間フレームを指定します。 この要素が指定されない場合、スケジュールは終日有効になります。
    • StartTime –「Daily」を指定した場合、この属性は必須です。 この属性は、スケジュールの日次開始時刻を xs:time という形式で指定します。 (xs:time ハイパーリンクをクリックして、この業界標準について理解してください。)
    • StopTime -「Daily」を指定した場合、この属性は必須です。 この属性は、スケジュールの日次停止時刻を xs:time という形式で指定します。 「StopTime」に指定された時刻は有効期間に含まれないため、日次開始時刻と同じかそれより前の時刻が指定された場合、スケジュールは翌日の指定された停止時刻に停止します。
  • Weekdays - このオプション・エレメントは、スケジュールに組み込まれる曜日を指定します。 この要素が指定されない場合、すべての曜日がスケジュールに組み込まれます。 この要素は、スケジュールで午前 0 時をまたぐ実行が許可されている場合、日次時間フレームの開始にのみ影響を与えます。 例えば、スケジュールが毎週水曜日の午後 11 時に開始し、2 時間実行するように設定されている場合、そのスケジュールは実際には木曜日の午前 1 時に終了します。
    • Days -「Weekdays」を指定した場合、この属性は必須です。 スケジュールに組み込まれる曜日を、正符号 (「+」) で区切った名前としてリストします。例: 「Monday+Tuesday+Wednesday+Thursday+Friday+Saturday+Sunday」。

メディエーション・ポリシーの条件式

条件式が指定される場合、それはブール式を指定する非反復要素になります。

この式は、「Attribute」、「Operator」、および「Value」の 3 つのパラメーターと、オプションの「Interval」および「Limit」のパラメーターで構成されます。 「Attribute」および「Value」(該当する場合は、これらに加えて「Interval」および「Limit」) への「Operator」の適用が True に評価されると、式は True に評価されます。 「Limit」要素は、「HighLow」演算子および「TokenBucket」演算子と一緒にのみ使用されます。 「Limit」が指定されない場合、値は 0 になります。「Interval」が指定されない場合、デフォルトは 60 秒になります。

式に指定可能なパラメーターは、以下のとおりです。
  • Attribute - 以下の表に、定義される属性とそれぞれのタイプをまとめます。
    表 1. 定義される属性
    属性 説明とタイプ
    ErrorCount モニタリング間隔の間に確認された障害の数。
    MessageCount モニタリング間隔の間にインターセプトされたメッセージの実際の数。
    InternalLatency 秒単位の内部待ち時間 (処理時間)。
    BackendLatency 秒単位のアプライアンスからサーバーに対する待ち時間。
    TotalLatency 秒単位のバックエンドと内部待ち時間の合計。
  • Operator - 以下の表に、使用可能な演算子とそれぞれの意味をまとめます。
    表 2. 演算子
    演算子 意味
    GreaterThan 定義された「Value」よりも「Attribute」が大きい場合に True に評価される、単純な数値アルゴリズム。
    LessThan 定義された「Value」よりも「Attribute」が小さい場合に True に評価される、単純な数値アルゴリズム。
    TokenBucket バーストを許容するレート・ベースのアルゴリズム。 このアルゴリズムは、トークンの最大容量「Limit」を持つバケットで構成されます。 「Attribute」単位ごとにトークンが 1 つ除去される一方で、バケットには「Interval」ごとに一定レートで「Value」個のトークンが入れられます。 このアルゴリズムは、バケットにトークンが入っていない場合に True に評価され、それ以外の場合は False に評価されます。 このアルゴリズムの説明に役立つ例を示します。Limit=100、Value=5、Interval=1 秒、および Attribute=MessageCount と想定します。
    1. バケットは、最大容量 100 トークンによる満杯状態で開始されます。
    2. メッセージが到着すると、アルゴリズムはバケットにトークンが入っているかどうかを検査します。
      1. 入っている場合、アルゴリズムは False に評価され、バケットから 1 つのトークンが除去されます。
      2. 入っていない場合、アルゴリズムは True に評価されます。
    3. その間、アルゴリズムは容量の許す限りバケットに毎秒 5 つのトークンを追加します。
    HighLow 「Attribute」が「Value」として指定された上限しきい値に達すると True に評価され、「Attribute」が「Limit」として指定された下限しきい値に達するまで True に評価され続けるアルゴリズム。
  • Value – これは正整数要素です。「0」は有効です。
  • Interval - このオプション要素は、式を評価するときに「wsme:Attribute」を測定するためにスライディング・ウィンドウとして使用される時間間隔を xs:duration の形式で定義します。 これを指定しない場合、60 秒の間隔が使用されます。 指定する場合は、構成される「ポリシー実施ポイント (Policy Enforcement Point)」の機能も考慮して、合理的な値を指定してください。 つまり、この値が大きいほど、「ポリシー実施ポイント (Policy Enforcement Point)」が属性を追跡するために必要とするメモリーの量が多くなります。 (xs:duration ハイパーリンクをクリックして、この業界標準について理解してください。)
  • Limit - このオプション整数要素は、「wsme:Operator」が「TokenBucket」または「HighLow」である場合に必要な、追加の「Limit」引数を定義します。 単位は、指定された「wsme:Operator」に応じて決まります。

    「wsme:Operator」が「HighLow」である場合、この要素で下限しきい値を、「wsme:Value」で上限しきい値を定義します。 「wsme:Value」のしきい値よりも小さいしきい値を指定してください。 指定されない場合のデフォルトの「Limit」の値は「0」です。

    「wsme:Operator」が「TokenBucket」である場合、このエレメントでバーストの最大サイズ、つまりバケット内のトークンの最大数を定義します。一方、「Value」でバケットが入れられるレートを「Interval」ごとのトークン数として指定します。 指定されない場合のデフォルトの「Limit」の値は「0」であり、その場合「TokenBucket」は「GreaterThan」演算子に相当します。

メディエーション・ポリシーのアクション

メディエーション・アクション要素は、実行されるアクションを指定します。 構文ではさまざまな組み合わせが許可されますが、それらのすべてが必ずしも意味を持つわけではなく、矛盾するアクション (メッセージをキューに入れることと拒否することがいずれも要求されるなど) が指定された場合は、「ポリシー・オーサリング・ポイント (Policy Authoring Point)」でその振る舞いが拒否されます。 許可されるメディエーション・ポリシー・アクションは、以下のとおりです。
  • QueueMessage – このアクションは、論理条件が合致したときにトランザクションがキューに入れられることを指定します。 メッセージ処理は、論理条件が合致しなくなるまで再開されません。 キューの方法とそれに関連するタイムアウトは、「ポリシー実施ポイント (Policy Enforcement Point)」(この場合は WebSphere DataPower) によって定義されます。 単一の「Action」要素で複数のアクションが指定される場合、「QueueMessage」は最初のアクションでなければなりません。
  • RejectMessage – このアクションは、論理条件が合致したときにトランザクションが拒否されることを指定します。 トランザクションは、論理条件が合致しなくなるまで、拒否され続けます。 トランザクションが拒否されると、クライアント (コンシューマー) サービスに SOAP 障害が返されます。 単一の「Action」要素で複数のアクションが指定される場合、「RejectMessage」は最初のアクションでなければなりません。 「QueueMessage」と「RejectMessage」を同時に指定することはできません。
  • Notify - このオプション要素は、論理条件が合致したときに、通知を生成することを指定します。 DataPower の場合、メッセージは DataPower システム・ログに書き込まれます。
  • RouteMessage - このオプション要素は、論理条件が合致したときに、指定のエンドポイント宛先にメッセージを経路指定することを指定します。 メッセージは、論理条件が合致しなくなるまで、指定のエンドポイント宛先に引き続き経路指定されます。
    • EndPoint – このパラメーターは、「RouteMessage」のアクションが指定された場合に必須です。 サポートされるエンドポイントの値には、IP アドレス、ホスト名、または仮想ホスト (ロード・バランサー・グループなど) があります。
  • ValidateMessage - このオプション要素は、指定の文法に照らしてメッセージを妥当性検査することを指定します。 妥当性検査が失敗すると、メッセージは拒否されます。 「ValidateMessage」を指定する場合は、サブパラメーターとして「XSD」または「WSDL」のいずれかを指定する必要があります。 「SCOPE」はオプションであり、指定されない場合は「SOAPBody」が妥当性検査に使用されます。
    • XSD - メッセージに含まれる URI で識別される XML スキーマに照らしてメッセージを妥当性検査することを指定します。
    • WSDL - メッセージに含まれる URI で識別される Web サービス記述 (WSDL) に照らしてメッセージを妥当性検査することを指定します。
    • SCOPE – メッセージのどの部分を妥当性検査するかを指定します。 以下の表に、指定可能な値とそれぞれの意味をリストします。
      表 3. 「ValidateMessage」要素
      説明
      SOAPBody SOAP Body 要素の内容。SOAP 障害に関する特別な処理はありません。(デフォルト)
      SOAPBodyOrDetails SOAP 障害の詳細要素の内容。それ以外の場合は、Body の内容。
      SOAPEnvelope SOAP メッセージ全体 (エンベロープも含む)。
      SOAPIgnoreFaults メッセージが SOAP 障害の場合は妥当性検査なし。それ以外の場合は SOAP Body の内容。
  • ExecuteXSL - 指定されたスタイル・シートおよびパラメーターを使用して XSL 変換を実行することを指定します。 実行が失敗するとトランザクションは拒否されます。 「Stylesheet」情報の指定は必須ですが「Parameters」はオプションであり、指定された特定のスタイル・シートの必要に応じて指定します。
    • Stylesheet - 変換操作で、含まれる URI で指定されるスタイル・シートが使用されることを指定します。 スタイル・シートは、XSLT ファイルでなければなりません。
    • Parameter - このオプションの反復要素は、ExecuteXSL 操作に使用するスタイル・シート・パラメーターを指定します。
      • Name – この属性は、対応する「Parameter」パラメーターごとに必要であり、パラメーターの名前を指定します。
      • Value - この属性は、対応する「Name」パラメーターごとに必要であり、パラメーターの値を指定します。

概念 概念

フィードバック


タイム・スタンプ・アイコン 最終更新: 2014 年 3 月 6 日


http://publib.boulder.ibm.com/infocenter/prodconn/v1r0m0/topic/com.ibm.scenarios.soawdpwsrr25.doc/topics/csoa2_SOA_implementation.htm