目次


SOA ポリシー

Comments

このドキュメントの使用方法

このドキュメントは SOA Policy Reference Architecture を理解して使用するための簡単なチュートリアルです。詳細な例を含めて SOA Policy Reference Architecture を十分理解するには、「参照資料」セクションに挙げた完全なドキュメントを参照してください。

SOA ポリシーを作成、編集、監督、管理、施行する人々にとってポリシーが果たす典型的な役割を理解するために、以下の図について考えてみてください。

図 1. SOA Policy Reference Architecture を使用する上でのポリシーの役割
SOA ポリシーの役割
SOA ポリシーの役割

SOA Policy Reference Architecture の説明

以下の図に示すように、SOA Policy Reference Architecture とは、ポリシーを使用してサービスを管理する場合のリファレンス・アーキテクチャーです。

図 2. SOA Policy Reference Architecture
ビジネス・ポリシー、アーキテクチャー・ポリシー、オペレーション・ポリシー
ビジネス・ポリシー、アーキテクチャー・ポリシー、オペレーション・ポリシー

SOA Policy Reference Architecture ではポリシーの表現を階層化することで、既存の SOA におけるポリシーおよび人々の役割を表しています。

  • ビジネス層は、ビジネスのニーズを詳細に記述できるビジネス・アナリスト、またはビジネスの代表者が主導する必要があります。
  • アーキテクチャー層は、SOA の完全性に責任を持つアーキテクトが主導する必要があります。
  • オペレーション層は、オペレーション・ポリシーのパターンを実装するランタイム・ポリシーの仕様が反映されます。

ビジネス・ポリシー層

最上位レベルでの抽象化では、ポリシーは特定のビジネス・ニーズを記述したものにすぎません。このレベルでは、ポリシーは通常、自然言語で表現され (例えば英語やフランス語など)、ビジネス・アナリストと IT 専門家との間でのビジネス要件に関するコミュニケーションを行うために使用されます。両者が協力作業を開始すると、このビジネス・ポリシーは組織全体でビジネス要件をどう実装し、どう施行するかの詳細を定義する一連の目的、戦略、戦術に分解されます。

これらのビジネス・ポリシーは、ポリシーの適用対象となるビジネス・ソリューションのコンテキストで定義する必要があります。サービスによって提供されるビジネス機能は、追跡できるようにするのが通常なので、ビジネス・ポリシーを適用する必要があるサービスに対しては大抵、即座にビジネス・ポリシーを関連付けることができます。

ビジネス要件が分解され、一連のサービスに適用可能なポリシーになった段階で、アーキテクチャー・ポリシー層を使用して、これらのポリシーの施行に使用できる共通のパターンを定義します。

アーキテクチャー・ポリシー層

アーキテクチャー・ポリシー層は、企業が採用するアーキテクチャーにポリシーを統合するためのパターンを提供します。ポリシーは (例えば、ビジネス・ルールの中で定義されたポリシーによって価格決定サービスが制御される場合など) サービスの振る舞いに対して適用される場合や、あるサービスを別のサービスが利用する場合に適用されることもあります。

オペレーション・ポリシー層

オペレーション・ポリシー層はデプロイされた製品とソフトウェア・インフラストラクチャーを提供します。このソフトウェア・インフラストラクチャーによってビジネス・ソリューションが実現され、そのソリューションの中でポリシーを使用できるようになります。SOA Policy Reference Architecture は、実際に運用される SOA ソリューションでポリシーをどのように実現するかを記述するコンポーネントをいくつも定義します。

ポリシー・ソリューションの例

以下の図はサービス・レベル管理要件の非常に単純な例を示しています。

図 3. SLA ポリシーをトップ・ダウン方式で分析する場合のポリシー・ツリーの例
ビジネス・ポリシー、アーキテクチャー・ポリシー、オペレーション・ポリシー
ビジネス・ポリシー、アーキテクチャー・ポリシー、オペレーション・ポリシー

ビジネス・ポリシー層のソリューション

ポリシー・ツリー分析は、上位レベルでのビジネス・ポリシー要件 (例えばビジネス・ユーザーやビジネス・アナリストからの要件など) を簡単に記述するところから開始します。次にこの記述を同じくビジネス・レベルで細部まで改善し、ビジネス・ポリシーの要件の意味や、確実にポリシーに準拠するために何を測定する必要があるかなどについて詳細に規定します。

ビジネス・ユーザーとの話し合いを基に、比較的容易にビジネスの趣旨や目標を上位レベルで定義することができます。例えば、「応答時間は顧客のニーズを満たす必要がある」、「顧客の信用リスクが妥当な場合にのみ保険商品を販売する」、「高コストのトランザクションは CFO が承認する必要がある」などが考えられます。

しかしそうすると、さらに詳細な質問が浮かんできます。知識の豊富なアナリストであれば、以下のような質問を開始するかもしれません。

  1. 応答時間の要件は一部の顧客と他の顧客とで異なるのか?
  2. 適切な応答時間はどの程度か?
  3. このポリシーはどのようなソリューション・コンテキストで適用されるのか?
  4. どのようにして信用リスクが妥当であるかどうかを測定するのか?
  5. 保険商品の種類が異なるとリスク・レベルも異なるのか?
  6. コストが高いトランザクションは何か?
  7. コストが高いトランザクションは何であるかには、リスク・レベルが影響するのか?

これらの結果を以下の図のように分解します。

図 4. ビジネス層でポリシーを分解する例
ビジネス・ポリシー層
ビジネス・ポリシー層

では、ビジネス層のポリシーを分解し、説明します。

表 1. ビジネスの目標からポリシーを分解する
アクティビティー説明
ビジネスの目標を明らかにするビジネスの目標はビジネスの観点から趣旨を記述したものであり、何をする必要があるかを定義します。応答時間に関する顧客の期待を満たす必要がある。
ポリシー・ディレクティブを導き出すポリシー・ディレクティブはビジネスの目標の趣旨を定義するものであり、ビジネス目標をさらに分解する方法についての指針を提供します。ポリシー・ディレクティブはソリューション・コンテキストのステージや、ポリシー・ドメイン、ソリューション・ポリシー、ガバナンス・ポリシーのステージでもさらに改善されます。顧客にとってのエンド・ツー・エンドの応答時間 (Enter キーを押してから応答を受信するまで) は 3 秒未満でなければならない。
ビジネスの目的を定量化するビジネスの目的は、目標の達成度を追跡するために何を詳細に測定する必要があるかを KPI の形で定義します。KPI 1: 顧客サービスの最大応答時間を測定し、規定時間を超過した場合には運用上非常に重要な警告を発する。
ソリューション・コンテキストのスコープを規定するソリューション・コンテキストは、ビジネスのどこでビジネス・ディレクティブを適用するのかを定義します。ソリューション・コンテキストのスコープは小規模なビジネス機能の範囲内というローカルな場合や、幅広くビジネス全体が対象となる場合があります。フェーズ 1: 銀行 ATM サービスのみ
ポリシー・ドメインを選択する各ドメインでは、一貫性を持ったポリシー定義のために使用すべき共通の語彙を特定します。ビジネス・ポリシーのサブドメインとして、以下のようなドメインを考慮する必要があります。
  1. 状況認識ポリシー (特定の期間にわたって複数のイベント・パターンを検出する、など)
  2. 特定のアクティビティー・ステップでプロセスの動作に影響するビジネス・プロセス・ポリシー
  3. 業界標準やコンプライアンス規制の実装につながる業界特有のポリシー
  4. サービス・レベル管理ポリシー
サービス・レベル管理ポリシー・ドメインを使用する。
ソリューション・ポリシーに分解する対象コンテキストに関する詳細情報が得られたら、ポリシー・ディレクティブをさらに改善する必要があります。すべての銀行 ATM サービスでの利用者の操作に対する応答時間は 3 秒未満でなければならない。
ガバナンス・ポリシーを適用する将来アジャイルな変更を実現できるようにポリシー・ディレクティブを管理する必要があります。これは、どこで SOA ポリシーのライフサイクルを実装するのかに関連しています。マーケティングに分類されたビジネス・ポリシーの作成、更新、削除については、すべてマーケティングに権限がある。

ビジネス層で分解された主な出力のうち、アーキテクチャー層で使用されるものは以下のとおりです。

  • ソリューション・ポリシー: ポリシー・ディレクティブから分解され、ソリューション・コンテキストの影響を受けます。
  • ソリューションの KPI: ポリシー・ディレクティブとビジネスの目的から分解され、ソリューション・コンテキストの影響を受けます。
  • ポリシー・ドメイン: 上記の顧客対応の例で選択されたサービス・レベル管理。

アーキテクチャー・ポリシー層のソリューション

適切なレベルのビジネス・ポリシーが規定されると、それらのポリシーを分解し、ビジネス・ポリシーの実装に必要なアーキテクチャー・ポリシー層のポリシーにすることができます。アーキテクチャー・ポリシーは必要に応じてビジネス・ポリシーを改善することによって高品質設計のソリューションを保証し、また必要な場合には、どのポリシー・パターンを使用してビジネス・ニーズを満たすのかを指定します。

アーキテクチャー層では主に 3 つの概念について考慮する必要があります。これらの概念を以下の図と表で説明します。

図 5. アーキテクチャー層でポリシーを分解する例
アーキテクチャー・ポリシー層
アーキテクチャー・ポリシー層

SOA ポリシーのライフサイクルのこの段階については、ビジネス・ポリシーを編集してサービスの呼び出しごとに関連付けられる一連のオペレーション・ポリシーに変換する手段を示してあります。

表 2. アーキテクチャー層で分解する
アクティビティー説明
ソリューション・ポリシーを分解するこのアクティビティーではアーキテクチャー層を使用して、ビジネス層で提供されたソリューション・ポリシーを状況に応じてそのソリューションの SOA リソースに適用可能なポリシーに分解する方法を定義します。このアクティビティーには、影響を受けるリソース (サービス、情報、またはプロセス) を特定することが含まれます。すべての銀行サービスは 2 秒以内に応答しなければならない。すべての情報サービスは 1 秒以内に応答しなければならない。
ドメイン・パターンを選択する既存の SOA インフラストラクチャーによって提供されるドメイン・パターンを使用すると、特定の実装パターンの使用を強制することができます。既存のパターンを選択することで、新しいソリューションの開発が必要なくなり、既存のコンポーネントを再利用できるため、価値実現までの時間や開発期間を短縮することができます。要求されるサービス・レベルを実現するために、サービスの遅延を監視し、その遅延に応じて適切なサービスにルーティングするという、SLA パターンを使用する。
オペレーション・ポリシー・セットを作成するソリューション・ポリシーを、ドメイン・パターンのオペレーション上の実装を使用して実行可能なポリシー・セットの形にします。これらのポリシーを管理するためにデプロイされた機能や製品を使用して、ポリシー管理ライフサイクルのすべてが提供されます。特定のサービス・ポリシー・セットにはルーティング・ポリシーと監視ポリシーが含まれる。

オペレーション・ポリシー層のソリューション

最後に、オペレーション・ポリシー層では、ビジネス・ポリシーとアーキテクチャー・ポリシーをさらに、ポリシーの施行や監視に必要で実行可能な一連のオペレーション・ポリシーに分解し、元々のビジネス・ニーズを確実に満たすようにします。

ビジネス・ポリシーは、アーキテクチャー層で提供される手段によって、プロセスやサービスによって解釈される機能ポリシーと、オペレーション・ソリューションでのアーキテクチャー・パターンの構成方法を制御する非機能ポリシー・セットへとマッピングされます。SOA Policy Reference Architecture では、オペレーション層で実装される重要な非機能ポリシーの領域を 4 つ指定しています。これらのオペレーション・ポリシーの領域では、最後のセクションで説明するアーキテクチャー・パターンに使用される非機能ビルディング・ブロックを提供します。

ポリシー・ツリーを例にとると、オペレーション層には考慮する必要がある主要概念が 3 つ存在しています。これらの概念について以下の図と表で説明し、詳細についてはその後のセクションで説明します。

図 6. オペレーション層でポリシーを分解する例
オペレーション・ポリシー層
オペレーション・ポリシー層
表 3. オペレーション層で分解する
アクティビティー説明
指定されたすべてのやりとりに関するポリシーに対し、ポリシー・セットとの照合を行う特定のポリシー・ディレクティブから生成されたポリシー・セットを、特定のサービスとのやりとりに対して既に提供されている他のポリシーとマージする必要があります。銀行サービスとのやりとりをするための SLA ポリシーを、顧客の口座データを保護する既存のセキュリティー・ポリシーとマージする必要がある。
ポリシー・セットを PDP/PEP 構成にマッピングするポリシーの解釈と施行のために使用される PDP と PEP は多くの場合、ポリシーを施行するために他の動的情報と併せてポリシー・セットを使用します。新しい条項をポリシーに導入するためには、更新されたポリシーをサポートするために、PEP の構成、メディエーション、その他の関連レジストリーを変更する必要があるかもしれません。SLA メディエーションでは、要求される SLA を実現可能なエンドポイントを判断するために、プロバイダーのポリシーに規定された遅延時間の統計を利用します。
監視ポリシー・セットを KPI のダッシュボードとアラートにマッピングするアーキテクチャー層のポリシー・セットにより、それぞれのやりとりで何を記録する必要があるかを定義することができます。しかしポリシーの KPI をダッシュボードに表示する手段や、重要な例外基準やアラートへの応答手段には、やはり構成が必要です。遅延時間がサービス・レベル管理ポリシーに規定される値より大きい場合や、サービス利用率が 90% を超える場合には、アラートを発生させる。

まとめ

SOA ポリシーは、SOA ソリューションにビジネスのアジリティー (俊敏性) と応答性を実現するための手段ですが、これらのポリシーを管理するにはシステマチックな手法が必要です。この記事では、さまざまなポリシー技術によって提供される SOA ポリシーのビルディング・ブロックやパターンを利用可能なソリューションを実現するために、採用するとよい推奨のプラクティスとライフサイクルについてまとめました。

IBM SOA Policy Reference Architecture には、さまざまなポリシーをシステマチックに作成、デプロイ、施行、監視する方法が 1 つのソリューションの一部として記述されています。また、ソリューション・サービス、プロセス、アプリケーションの開発に使用される SOA 開発ライフサイクルとポリシー・ライフサイクルとがどのように相互作用するかについても記述されています。そして最後に SOA ポリシーでは、組織が採用するガバナンス・プロセス全体に対してどのように整合を取ってサポートするのかが記述されています。

参照資料

ファイル名説明
SOA_Policy_Reference_Architecture_Full_Article.pdfSOA Policy Reference Architecture の資料全体をダウンロードしてください。

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


関連トピック

  • Twitter で developerWorks をフォローしてください。
  • 皆さんに最適な方法で IBM 製品を評価してください。製品の試用版をダウンロードする方法、オンラインで製品を試す方法、クラウド環境で製品を使う方法、あるいは SOA Sandbox で数時間を費やし、サービス指向アーキテクチャーの効率的な実装方法を学ぶ方法などがあります。

コメント

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=834263
ArticleTitle=SOA ポリシー
publish-date=09132012