レベル: 初級 Marc-Thomas Schmidt, Distinguished Engineer, Chief Architect Enterprise Service Bus, IBM
Shankar Kalyana (shankark@us.ibm.com), Executive IT Architect, IBM
2004年 8月 24日 オンデマンド・オペレーティング環境は、SOA (Service Oriented Architecture) の概念に基づいています。SOA では、すべてのアプリケーションやリソースを、特定の、識別可能な一連の (ビジネス) 機能を実装するサービスとみなします。オンデマンド環境でのサービスは、ビジネス機能の他にも、環境に対する広範な構成やオペレーション、モニタリングに参加するための管理インターフェースを実装することもあります。この記事では、オンデマンド・オペレーティング環境について紹介します。
はじめに
サービスは、構造化された情報、つまりメッセージあるいは文書 (ビジネス・オブジェクトと呼ばれることもあります) を交換することによって、お互いに通信を行います。サービスの機能定義は、そうしたサービスで作成、利用できるメッセージを宣言するインターフェースによって、また要求される、あるいは提供されるサービス品質を宣言するポリシー注釈によって、そしてサービスの対話動作において順守すべき動作の制約を宣言するコレオグラフィー注釈によって、行われます。実際の実装は、サービス要求者からは見えないようになっています。またSOA は新規のアプリケーションと既存のアプリケーションを素早く組み合わせて新しい用途に用いることができるため、アプリケーションの統合を実現する上で便利な方法と言うことができます。
既存のアプリケーションは、サービス宣言に「適合 (adapt)」させられます。アダプターは、例えば WebSphere® Business Integrator のモデルに従います。アダプターはサービス・インターフェースを実装し、メッセージを、既存アプリケーションに対するオペレーションへと変換します。
サービス間のすべての対話動作は、ESB (Enterprise Service Bus) を通して流れます。しかしこれは、すべての対話動作にネットワーク・コミュニケーションや XML メッセージが必要だという意味ではありません。ESB はサービスに対して、「サービス」という概念モデルを提供します。またESB によって、メッセージの伝達やエンコーディングを最適化することができます。極端な場合、2 つのサービスの間での対話動作が、ローカル・プログラム・コールにバインドされることもあります。
サービス要求者とサービス・プロバイダーとのマッチングは、デプロイ前など非常に初期の段階で行われることもあれば、動的な発見機構によって非常に遅い段階で行われることもあります。
SOA は、サービスやサービスの機能や対話動作を定義する標準を必要とします。構造化された情報の標準的な表現手段としての XML と、Web サービス標準 (よく WS-* 標準と呼ばれます) が広く受け入れられるようになるにつれ、SOA というアーキテクチャー手法の採用も促進されてきました。SOA の概念モデルは、ビジネス機能を仮想化したものと物理インフラを仮想化したものの両方に適用されます。またこのモデルでは、アプリケーションの構築から、アプリケーションのデプロイメントや管理までが対象となります。顧客 (ユーザーあるいはビジネス) はビジネス・サービスの集合しか見ず、そうしたサービスの品質にしか関心を持ちませんが、オンデマンド・オペレーティング環境は、アプリケーションの組み合わせやサービスの提供についての詳細を顧客から見えないようにするのです。
次のセクションでは、オンデマンド・オペレーティング環境のアーキテクチャーと、この環境を導く原則の詳細について見ていきます。
図 1. オンデマンド・オペレーティング環境のアーキテクチャーの概要
ESB (Enterprise Service Bus)
オンデマンド・アプリケーションはビジネス・サービスであり、他のサービスでも使用できるものとして宣伝する価値のある、一連の機能を提供するサービスで構成されます。ビジネス・サービスは、他の多くのサービスに依存して実装されることが多いものです。サービスは、サービス・エンドポイント間の対話動作の仲介を行う ESB を通して対話動作を行います。ESB は、イベント・ベースの対話動作も、サービス・リクエストを処理するためのメッセージ交換もサポートしています。ESB の革新的な点は、メッセージとイベントに対して共通のモデルを使うことです。サービスをデプロイすることでイベント空間のトピックにメッセージをバインドできるのであれば、すべてのメッセージはイベントとなることができます。
メディエーションは、イベントとメッセージの両方に対して対話動作を実現します。例えば、要求者が求める機能を提供するサービスを見つける、あるいは、機能面で互換性のある要求者とプロバイダーとの間のインターフェースの不整合を処理する、などを行います。この記事では、サービスという言葉を非常に広い意味で使います。ESB の観点から言えば (ESB は効率的で仲介された機能ベースのマッチングのために正規化表現を必要とするため)、すべてのアプリケーション・コンポーネントは WS-* 標準を使って規定することができます。しかしこれは、そうしたコンポーネントがすべて SOAP や WS-* プロトコル標準を使って通信するという意味ではないことに注意してください。アプリケーション・コンポーネントは、ESB に対して、そうしたフォームで記述する必要があるだけなのです。ESB は、バスに乗ったり (接続したり)、バスから 降りたり (切り離したり) するための、非常に幅広い方法をサポートしています。そうした中には、レガシー・アプリケーションのためのオンランプ (on-ramp) や、B2B 対話動作シナリオでの外部パートナーがサービス対話動作というゲームに参加するための、ビジネス・コネクション (注記 1) なども含まれています。
 |
注記 1
ビジネス・コネクションによって、外部サービスは (他のサービスとまったく同様に)、ビジネス・レベルの (統合) サービスとも対話動作でき、また (ポリシーで表現される必要なサービス品質を実現するために) インフラ・サービスとも対話動作できるようになります。
|
|
サービスは、ESB の観点からはどれも同じように見えますが、オンデマンド・アプリケーション全体の中のさまざまな側面を実装しています。例えばサービスは、基礎となるビジネス・プロセスに関係する人達との対話動作を実現するかもしれません。あるいは、統合が必要な既存のアプリケーションにアダプターを提供したり、ビジネス・ゴールを実現するために、いくつかのサービス間で行われる対話動作のコレオグラフィーを記述したり、プロセスの実行における潜在的な問題を監視したり、問題が実際に発生したら即座に修正アクションを行えるよう準備したり、要求されているビジネス機能を実行するために必要なリソースを管理したりするかもしれません。従ってオンデマンド・オペレーティング環境は、サービス対話動作のための基本的なインフラを提供する以外に、オンデマンド・アプリケーション構築のための一連の共通パターンの識別も行います。また、そうしたパターンの中で特別の役割を果たす明確なサービス・カテゴリーを実現するための、特定の機能も提供します。2 つの明確なサービス・カテゴリーとして、統合サービスと、インフラ・サービスの 2 種類があります。
統合サービス
オンデマンド・ビジネス・サービスのプログラミング・モデルは、コンポーネント (サービス) アセンブリーによるアプリケーション開発に基づいています。オンデマンド・アプリケーション・ビルダーは、統合カテゴリーのサービスを使って新しいビジネス・サービスを作成します。このカテゴリーのサービスは、統合を実現するだけではなく、統合すべきビジネス機能も提供します。下記はこうしたサービスの説明です。
-
ユーザー・アクセス・サービスは、互いに大きく異なる 3 つの観点からサービスを適用します。つまり、(1) ディスプレイ・サイズやメモリー、プロセッサーなどの制限によるエンドポイントのフォーム・ファクター (上はデスクトップから下はパーベイシブ・デバイスまで) という観点から、(2) 対話動作モード、つまり従来のディスプレイとキーボードによる対話動作だけではなく、音声認識ベースや両者の組み合わせ (マルチモダリティー) という観点から、そして (3) 完全に切り離されたオペレーションまで含めてさまざまな接続信頼性を持つ、ピア・ツー・ピア、あるいはクライアント・サーバーという接続タイプの観点から、サービスを適用します。
-
ユーザー対話動作サービスは、ビジネス・プロセスに関係する人達との直接の対話動作を処理します。そうした人達としては、コレオグラフィーやコラボレーション・プロセス要素などによって大量に生ずる作業アイテムを処理する人達が含まれます。
-
ビジネス・プロセス・コレオグラフィー・サービスは、プロセス・フローやルール技術を使って自分の動作を表現する、他のサービスの実行をサポートします。例えばプロセス・フローは、他のサービス (他のプロセス・フロー・サービスを含め、ほとんどすべての統合種類) の対話動作を記述するために使われ、新しい (組み合わされた、あるいは集約された) ビジネス・サービスが提供する機能の実現に必要なタスクを実行します。
-
ビジネス機能サービスは、「アトミックな」ビジネス機能 (「他のサービスから構成されていない」機能) を提供します。こうした機能は全体としてのビジネス・サービスに要求されます。そしてビジネス・サービスには、パッケージされた、あるいは既存のカスタム・アプリケーションのためのアダプターや、既存のアプリケーションでカバーされない機能要求を実現するために作成される新規アプリケーションのコンポーネントのためのアダプターが含まれます。
-
共通サービスは、有用な機能、つまり多くのビジネス・サービスで使用できるように設計された「ヘルパー機能」を実装します。こうしたサービスの例としては、ユーザー・アクセス・サービスやユーザー対話動作サービスのパーソナル化を実装するサービス、ビジネス・サービスの状態と進行状況をレポートするサービスなどがあります。
-
情報管理サービスは、データベースやレガシー・アプリケーションなど、さまざまなデータ・ソースがホストする情報の統合を補助します。こうしたサービスは、そうした情報にアクセスし (そしてクエリーし、アップデートし、サーチし) 、ビジネス・インテリジェンス・シナリオの中で分析します。あるいは、オンデマンド・オペレーティング環境の中で動作するビジネス・サービスが使用、提供する情報やサービスに関するメタデータを処理します。
統合サービスは、アプリケーション・サービスによってホストされます。アプリケーション・サービスは、こうしたサービスが、他の統合サービスや、オンデマンド・オペレーティング環境のインフラ・サービスとの対話動作に簡単に参加できるようにするためのコンテナー機能を提供します。オンデマンド統合サービスの開発者は、自分たちの関心対象であるビジネス・ロジックを実現すること、必要なビジネス機能を提供する統合サービスを組み立てること、そして期待されるサービス品質を宣言することに集中します。
プログラマーや管理者は、自分たちのアプリケーションやサービスに対して、サービス品質を規定するポリシー宣言という注釈を付けます。アプリケーション・コンテナー (そして ESB) は、インフラ・サービスとの対話動作を自動化し、表現されたポリシーを実現します。またアプリケーション・コンテナーは、自分がホストするサービスのセキュリティーやトランザクションの管理への要求処理など、汎用の機能も提供します。また、「その種類に特有な」機能、例えば、ビジネス・プロセス・コレオグラフィー・サービスの状態と進行状況をレポートするイベントの生成機能なども提供します (注記 2)。
|
注記 2
すべてのサービス・カテゴリーはコンテナーの中にありますが、オンデマンド・オペレーティング環境でのプログラミング・モデルという観点から見て興味深いのは、統合サービスに対するコンテナーのみです。なぜなら、このコンテナーはビジネス・サービス・ビルダーがパラメーター化する必要があるからです。
|
|
インフラ・サービス
インフラ・カテゴリーのサービスは、ビジネス・サービスとその構成要素がデプロイされるインフラを提供し、管理します。下記のリストは、こうしたサービスを説明したものです。
-
ユーティリティー・ビジネス・サービスは、請求 (billing) や課金 (metering)、価格設定 (rating)、ピアリング (peering)、決済 (settlement) などの機能をサポートします。こうした機能は、例えばオンデマンド・ビジネス・サービスや、そのコンポーネントをホストする場合などに一般的に使われます。
-
サービスレベルの自動化とオーケストレーションは、ビジネス・サービスに関するサービス品質ポリシー宣言を現実のものとして実現するためのサービスを提供します。これは、オンデマンド・オペレーティング環境の中でサービスの実行を監視するオートノミック・マネージャーを実装したサービス (もっと正確に言えば、管理対象要素として実装されるサービスの実行を) によって実現され、サービスが受け取るポリシー宣言に従っています。こうしたサービスは、サービスの動作を分析し、もし分析の結果、問題がわかった場合には、その問題に対して意味のある応答を計画し、そしてその計画の実行を開始します。この閉じたフィードバック・ループは、MAPE (Monitor, Analyze, Plan, Execute) ループと呼ばれます。こうしたサービスに特化したものは数多く存在し、例えば可用性や構成、管理対象要素のワークロード、リソースのプロビジョニング、問題管理の実行、オンデマンド・オペレーティング環境サービスに対するエンド・ツー・エンドでのセキュリティー処理、データ・プレースメントの管理などといった管理に焦点を合わせたものになっています。
-
リソース仮想化サービスは、サーバーやストレージ、ネットワークなどのリソース (注記 3) の実装を提供し、オンデマンド・オペレーティング環境のリソース・マネージャーのコントロールの下で、そうしたリソースの管理や仮想化を実現します。リソースとしては、さまざまなデータ・ソースに保持され、構造化された (例えばリレーショナルな) 情報コンテンツや、構造化されていない情報コンテンツなどがあります。仮想化サービスには、サービスの QoS (quality of service) 宣言と、利用可能なリソースの現在の使用率の情報に基づいて、ビジネス・サービスとビジネス・サービス・コンポーネントを適切なリソースにマッピングするという要求が含まれます。
|
注記 3
この記事では、リソースという言葉を非常に一般的な意味で使っており、ハードウェア・デバイスや OS リソース、データベース、アプリケーション、その他までカバーしています。
|
|
2 つのサービス・カテゴリーの間の主な違いは、オンデマンド・オペレーティング環境のさまざまなパターンをサポートするために非常に異なった機能を実装しているという事実の他に、どのユーザー・ロールがこの 2 つを構築し、使用するか、という点にあります。ミドルウェアのプロバイダーや ISV はインフラ要素を構築しますが、オンデマンド・インフラやアプリケーション・ビルダーは、統合要素を構築します。
オンデマンド・オペレーティング環境を考える上で重要なことの 1 つは、アプリケーション・サービスとインフラ・サービスの両方を、共通なパターンがサポートしている、という点です。例えば、
- 既存のインフラ・コンポーネントをアダプターによって ESB の中に統合することができます。
- 多くの場合、MAPE 実行計画のスクリプト記述にはサービス・コレオグラフィーが使われます。
- 管理対象要素とオートノミック・マネージャーとの間でのイベント交換用のインフラを ESB が提供します。
- ユーザーは「ポータル」ユーザー対話サービスを介してインフラ・サービスと対話動作します。
ビジネス・パフォーマンス管理
オンデマンド・オペレーティング環境の持つ 3 つの側面 (ESB と統合サービス、そしてインフラ・サービス) によって、ビジネス・パフォーマンス管理を実現するために必要な機能が提供されます。つまり、ビジネス・サービス実装の分析フェーズで識別されるKPI (key performance indicator) のようなビジネス・ゴールを達成するための、ビジネス・サービスの管理機能が提供されるのです。統合サービスを実装することによって、基礎となるビジネス・サービスの管理のための KPI や他のメトリクスの計算に使われる、ビジネス・イベントが生成されます。またビジネス・サービス・ポリシーはビジネス・サービスに期待される動作を記述しますが、それによって、期待通りにならなかった場合の状況に対応するためのルールも定義します。ビジネス・イベントの例としては、ビジネス・プロセスの完了やロールバック、あるいは手操作による介入などがあります。するすべての受注プロセスが手操作による介入なしに無事完了するとすれば、KPI は 95% になるかもしれません。
インフラ・サービスは IT レベルのイベントを生成し、ビジネス・サービスが使用するリソースの状態をレポートします。(こうしたイベントは、インフラ・サービスが生成するビジネス・サービスと相関しているかもしれません)。サービスレベル自動化サービスは、ビジネス・イベントと IT レベルのイベントを使って、サービスレベル自動化サービスがホストするビジネス・サービスに関連したポリシーを強制します。ユーティリティー・ビジネス・サービスは ESB と共に、そうしたイベントを収集、集約、評価し、ビジネス活動の場でビジネス・プロセスに参加する人達に提示します。
オンデマンド・ビジネス・サービスのライフサイクル
|
注記 4
この記事では、アプリケーション・ビルダーという言葉を、オンデマンド・サービスのモデリングと実現に関連する、一連のユーザー・ロールをカバーするものとして使っています。
|
|
オンデマンド・アプリケーション・ビルダー (注記 4) は、ある企業が関心を持つ、特定のビジネス・ゴールをサポートするビジネス・サービスを開発します。オンデマンド・アプリケーションの 1 面のみを実現する他のサービスとは対照的に、ビジネス・サービスは「それ自身が独立」しており、ユーザー (顧客や、企業内ユーザーなど) に対して、あるいは企業が行う対話動作の対象となる他のビジネスに対して、意味のあるビジネス・プロセスやタスクを実装して提供します。ビジネス・サービスは一連の統合サービスから構成され、そのようにして構成されたものがオンデマンド・インフラにデプロイされます。オンデマンド・インフラ・マネージャー (注記 5) は、そうしたビジネス・サービスの構成をホスト、管理するために必要な、ビジネス・ユーティリティーやサービスレベル自動化、リソース仮想化サービスが適切に配置されるようにします。
|
注記 5
この記事では、インフラ管理者という言葉を、オンデマンド・インフラの管理に関わる一連のユーザー・ロールをカバーするものとして使っています。
|
|
オンデマンド・オペレーティング環境の機能や、サービスの種類、それらの対話動作などを理解するためには、オンデマンド・アプリケーションのライフサイクルを追ってみることです。つまり、そのライフサイクルの中には、基礎となるビジネス機能やパフォーマンス標識のモデリングから、モデルの目的を実装するビジネス・サービス・コンポーネントの構築や組み立てまで、また、そうしたコンポーネントをビジネス・サービスとしてオンデマンド・インフラの中にデプロイする段階まで、オン・デマンド・サービスのライフの 1 日があるのです。
プロセス・モデルを定義する
ビジネス・サービスをどのように捉えるかはこの記事の範囲外ですが、ビジネス・サービス・ビルダー (例えばビジネス・アナリスト) は、いったんビジネス・サービスを理解できると、新しいビジネス・サービス・プロバイダーの主要機能の概略図を提供します。彼らは、CBM (Component Business Model) メソッドを使って(CBM は、ユニークでスタンドアローンのビジネス・コンポーネント群を識別することでビジネスへの見方を単純化しようとする分析手法です)、描いていたビジネス・サービスを詳しく調べ、ある特定のアプリケーション・ドメインのモデルの中に位置付けるのです。
このモデルは、描いていたアプリケーションの主要コンポーネントを、ほとんど実装から独立した形で特定します。またこのモデルは、オンデマンド・オペレーティング環境が「ネイティブで」サポートするパターン (アダプターやプロセス・コレオグラフィー、ビジネス・オブジェクトなど) と似たパターンを使用します。そのためプロセス・モデルは、オンデマンド・オペレーティング環境のサービス種類に関して定義される実装モデル用のテンプレートに容易に変換することができます。
確認されたビジネスのモデルとしてサービス・アナリストが開発するモデルには、ビジネスが関心を寄せるべき KPI の仕様が含まれています。またこのモデルには、サービスを (オンデマンド・オペレーティング環境にホストされる) 他のサービスが実行する一連のアクティビティーに、最初に分解したものが含まれ、他にもプロセスが操作する情報を表すビジネス・エンティティーや、目標とするビジネス機能の実現のために実行されるタスクのある側面に責任を持つユーザーやビジネス・パートナーの識別情報なども含まれています。
図 2. オンデマンド・ビジネス・サービスのライフサイクル
次に、ビジネス・レベルのモデリング・ツールを使ってモデル内での対話動作 (プロセス) が記述され、またそうした動作のシミュレーションが、アクティビティーやリソースの可用性などに対するコスト見積もりに基づいて行われます。次に、この段階で開発される上位レベル・モデルは、オンデマンド・オペレーティング環境ツールがサポートするビジネスから IT レベルへのマッピング・パターンを使って、実装レベルのモデル用のテンプレートに変換されます。多くの場合、「コンポーネント」あるいは「サービス」の既存の実装は、モデルの中にあります。これらは、テンプレートから実装するのではなく、ビジネス・レベル・モデルの中で宣言される特定の要求に従って、ルールまたはポリシーに基づいてカスタマイズする必要があります。
新規のコンポーネントや既存のコンポーネントを組み立てる
ビジネス・コンポーネントに対する実装レベル・モデルのスケッチあるいはテンプレートは、新しいビジネス・サービスのゴールを実現するために必要なビジネス・タスクやビジネス・エンティティーを抽象的に記述したものを、オンデマンド・オペレーティング環境がサポートするアプリケーション・パターン (例えばアダプターやメディエーション、コレオグラフィーなど) に従って、一連の具体的なサービス種類にマップします。
プロセス・コレオグラフィー・サービスは、ビジネス・レベル・モデルに概説されたタスクの分解方針に沿って他のサービスの対話動作のオーケストレーションを行い、求められるビジネス・ゴールを実現します。また、ビジネス・ルールを外部化して、組み合わされるサービスの動作をカスタマイズします。ユーザー・アクセス・サービスは、さまざまなフォーム・ファクターのデバイス、さまざまな対話動作モード、さまざまなコネクション機能のどれに対してもタスクが実行できるようにします。ユーザー対話動作サービスは、そうしたタスクの実行にユーザーが貢献できるようにし、それによってユーザーが、整然としたプロセス・コレオグラフィーを補う形でコラボレーション機能を使った非公式な方法で対話動作を行えるようにします。情報管理サービスは、ビジネス・レベル・モデルで識別されるビジネス・エンティティーを実現し、さまざまな種類のデータ・ストアやバックエンド・システムがホストする情報を新しいビジネス・サービスのアクティビティーで処理できるようにし、情報を変換、統合し、そしてその情報に対してビジネス・インテリジェンス・タイプの分析を行えるようにします。ビジネス機能サービスは、新しいビジネス・サービスの意味合いに合わせて使用可能な、既存のアプリケーション・コンポーネント (パッケージで入手したものあるいは内製したもの) を表現します。こうしたコンポーネントは、ESB アダプターやメディエーション機能を介して、あるいは、新しいサービスによって生じる機能の隙間を埋めるために構築が必要な新しいコンポーネントを介して使用されます。共通サービスは、多くのサービスが使用する機能のカプセル化、つまり人との対話動作をキメ細かくカスタマイズする、ビジネス・パフォーマンスの管理やビジネス・インテリジエンスという意味でのレポートをサポートする、などを行います。
オンデマンド・アプリケーション・ビルダーは、(ESB がホストする) メディエーションも実装します。メディエーションは、全体としてのサービス・ゴールを実現するために、構成要素となっているサービス・コンポーネント間に必要なサービスの対話動作の整合を容易にとれるようにします。
ビジネス・レベル・モデルの中で定義されるパフォーマンス標識などのメトリクスは、ビジネス・パフォーマンス管理のにおいては、できあがるビジネス・サービス・コンポーネントの要素の実装という形に変換されます。この実装モデルは、ビジネス・サービス全体を構成するサービスに対するポリシーの注釈も規定し、こうしたコンポーネントに期待されるサービス品質を示します。アプリケーション・コンテナーは、こうした注釈を実行時の動作にマッピングする上で、またアプリケーションがホストするコンポーネントに対する状態変化イベントを生成する上で、そしてポリシーを適切なインフラ・サービスとの対話動作に変換する上で、重要な役割を担います。
ビジネス・サービス・ライフサイクルの、このフェーズで使用されるオンデマンド・オペレーティング環境用の実装レベル・ツールは、サービス・コンポーネント (新規またはレガシー・ベース) の作成や、既存コンポーネントのカスタマイズや組み立てをサポートします。サービスの作成には、既存アプリケーションに対するアダプターの開発も含まれます。アダプターは多くの場合、既存のアプリケーション・インターフェースを単純に「サービス化」する以上の、アプリケーション・ラッパーを提供します。オンデマンド・オペレーティング環境の統合サービスの開発者は、カスタマイズを考慮しながらコンポーネントを設計することができます。こうしたサービスは、他のコンポーネントに判断を委ねるべき変化点を外部化します。そうした例としては、実行フローを決定するためのビジネス・ルールの協議、あるいはサービスのポリシー注釈として表現される QoS の変形があります。新しいビジネス・サービスとしてコンポーネントを組み立てる方法にはいくつかの方法がありますが、サービス・コレオグラフィーを使用する方法が非常に一般的です。
もっと一般的に言うと、オンデマンド・オペレーティング環境は、サービス・テンプレートという概念をサポートしています。サービス・テンプレートは、コンポーネントを組み合わせたものとカスタマイズしたものを混合して使用することによって、カスタマイズ可能な合成コンポーネントを実現します。こうした合成コンポーネントは、テンプレートによって表現される汎用ビジネス・サービスの変種を構築するためのテンプレートして動作します。こうしたテンプレートを使用するビジネス・サービス・ビルダーは、スタマイズするコンポーネントの内部を理解する必要はありません。テンプレート機構が実装の詳細をサービス・ビルダーから見えないように隠し、テンプレートの変化部分のみを見せるのです。この変化部分は、テンプレートのインスタンス化を実現するためにパラメーター化することができます (あるいはパラメーター化する必要があります)。
インフラを識別し、設計する
次に、できあがるビジネス・サービスと、そのサービスがサポートするユーザー・アクセスや対話動作、ビジネス・プロセス・コレオグラフィー、情報管理、ビジネス機能、そして共通サービスは、もし必要であれば、仮想リソースから成るオンデマンド・オペレーティング環境インフラの中にデプロイされます (場合によると、既にデプロイされているサービスが共有され、再利用されることもあります)。ビジネス・サービス・ビルダーは、デプロイしたタスクの実行に際して、基礎となる (仮想化された) インフラに関する知識を持つ必要はありません。彼らはサービス・アセンブリーを、デプロイメント・プロセスの一部としてランタイム・インフラへの要求に変換されるポリシー注釈によって、パラメーター化します。
オンデマンド・オペレーティング環境は、利用可能なリソースとリソース間の関係を宣言する全体的なリソース・モデルの規定と管理をサポートします。オンデマンド・ビジネス・サービスのリソース要求は、サービスとその構成要素のポリシー宣言に由来しています。この段階では、もし新しいプロセスのポリシー宣言で必要とされる場合には、リソース・プロビジョニングが開始されます。オンデマンド・インフラ・マネージャーは、そのリソース・モデルを定義し、必要なリソース・マネージャーを使ってインフラを構成します。
ビジネス・サービス・アセンブリーの要素は、企業内部のオンデマンド・オペレーティング環境インフラだけではなく、企業外にもデプロイできることに注意してください。オンデマンド・オペレーティング環境のプログラミング・モデルでは、ビジネス・サービス・ビルダーへのサービス・コンポーネントの透過的なアウトソースをサポートしているのです (ビジネス・サービス・ビルダーは、サービス・アセンブリーの中で使用されるサービス・コンポーネントから期待される機能を単に記述するのみであり、そのコンポーネントに対する特定のホスト環境を記述するわけではありません)。
想定し、応答する
そして最後に、自動化サービスやオーケストレーション・サービスから構成されるMAPE ループが、これらの全体をモニターし、コントロールします。こうしたサービスは、ミドルウェア・ベンダーや ISVがインフラ・コンポーネント (部分的に有効にされ、インフラ・レベルのイベントを生成します) に対して提供する実装や、ビジネス・レベルのメトリクスで統合レベルの成果物を実装したものを使用します。このメトリクスは、ビジネス・プロセス・サービスのライフサイクルの初期に概要が作成されるパフォーマンス標識によって呼び出され、ここの段階に関係する統合サービス種類の管理対象要素面の実装に変換されます。
どちらの種類のイベント (インフラによるものと、ビジネスによるもの) も、共通のイベント記述フォーマットを使ってエンコードされること、従って同じ (共通イベント) インフラ (ESB の、もう 1 つのアプリケーション) を介して伝播され、イベントのソースとは独立に相関付けられ、集約されることに注意してください。
もう 1 つ注意すべき点として、ここでキャッチされたイベントによって、ビジネスや IT レベルのイベントのモニタリングが可能になること、またビジネス・サービスの最初の概略を提供した人達 (あるいはその人達に分析を行うように指示した人達) が KPI 指向の形式で描画できることの他に、突き当たる問題に対するリアクションが自動化されることがあげられます。さらに良いことに、将来発生する可能性のある問題を示すイベント・パターンも検出され、それを回避するためのアクションも行われるのです。そうしたアクションは、対象とするビジネス・サービスに関するポリシー宣言に基づいて行われます。
オンデマンド・インフラ・マネージャーは、必要なサービスレベル自動化とオーケストレーション・コンポーネントの構成を行います。特に、有効になったビジネス・サービス・コンポーネント・アセンブリーの要素に対して宣言されるポリシーを理解し、強制するオートノミック・マネージャーの場合には、これを明確に行います。
アーキテクチャーの定義
以下のセクションでは、オンデマンド・オペレーティング環境のアーキテクチャーの主な要素について、よりシステム的に説明します。これは図 1 に示した用語の解説集です。図 1 の大きな四角それぞれの要素に対して 1 つのセクションをあて、アルファベット順に並べました。また、そうしたセクションの中に小さな四角の要素の説明を入れました。
アプリケーション・サービス
アプリケーション・サービスは、統合サービスやビジネス・サービスをホストするコンテナーを実現し、また、他の統合サービスやオンデマンド・オペレーティング環境のインフラ・サービスとの対話動作に単純に参加できるための機能を提供します。
ビジネス
ビジネスは、ビジネス・サービスの対話動作という意味合いでの役割を、プログラム的なリンクを介して担う外部アプリケーション・システムです。ビジネスは、企業の提供するサービスの利用者であるかもしれず、企業に対するサービスのプロバイダーかもしれません。またビジネスは、企業内部あるいは企業外の実体にまたがる場合もあります。例えば、地理的に各地に分散している大きな企業では、地理的にさまざまな場所に複数のビジネス・ユニットを持っているかもしれません。そして各ビジネス・ユニットが、他の場所にあるビジネス・ユニットと「ビジネス」するための独自のシステムやアーキテクチャーを持っているかもしれません。
コンシューマー・コンポーネントは、対象組織が提供するサービスとプログラム的に統合されることに関心を持つビジネスです。コンシューマーから外部システムへのリクエストは、非同期のことも、同期していることもあります。
プロバイダー・コンポーネントは、対象組織がプログラム的なリンクを確立して活用しようとする、ある種のビジネス機能を提供するビジネスです。
ビジネス機能サービス
ビジネス機能サービスはビジネス機能を実装し、その実装の詳細は隠します。ビジネス機能サービスはビジネス・サービスの機能の基本であり、その基礎となる機能をサービスとして、あるいは直接、コレオグラフィーで使用されるコンポーネントとして公開することができます。ビジネス機能サービスは、動作型のこともあり、分析型のこともあります。以下のリストは、ビジネス機能サービスのいくつかを説明したものです。
-
カスタム・アプリケーションは、企業内で作成されたビジネス・アプリケーションです。これらは非常に古い場合が多く、ビジネス・ロジックは中に埋め込まれています。こうしたアプリケーションのいくつかは多くのビジネス・プロセスをカバーし、ビジネス内の複数の機能領域にまたがることもありますが、大部分はビジネスの特定の一面しかカバーしていません。
-
パッケージ・アプリケーションは、外部のアプリケーション・ベンダーからソース・コードあるいはランタイム・コードを購入するビジネス・アプリケーションです。パッケージ・アプリケーションのベンダーの例としては、SAP や Oracle®、PeopleSoft® などがあります。こうしたアプリケーションは、通常はビジネス内の複数の機能を処理しますが、ある機能に特化されたアプリケーションも存在します。こうしたアプリケーションの大部分は、ビジネス・ロジックとビジネス・プロセスをカバーしています。
ビジネス・パフォーマンス管理
ビジネス・パフォーマンス管理サービスによって、ビジネス・マネージャーは明確で測定可能なゴールを持ったビジネス戦略を作成することができ、こうした戦略をアクション・プランやビジネス・ポリシーに変えることができ、こうしたポリシーのパフォーマンスをモニターして KPI が満足されることを確認でき、こうしたプランの結果を分析してパフォーマンス・ドライバーを理解でき、また、こうした結果をさまざまな利害関係者に伝達できるようになります。ビジネス・パフォーマンス管理レイヤーの全体としてのゴールは、感知して応答する環境を実現すること、あるいはもっと意欲的に、想定して事前に動作する環境を実現することです。
図 1 では、ビジネス・パフォーマンス管理は、統合サービスと ESB、そして統合サービスの「交差点」に位置付けられています。
ビジネス・プロセス・コレオグラフィー・サービス
ビジネス・プロセス・コレオグラフィー・サービスは、ビジネス・ゴールの実現に必要な他の (統合) サービスの対話動作を記述するために、プロセス・フロー・グラフを使って実装を表現するサービスの実装をサポートします。ビジネス・プロセス・コレオグラフィー・サービスは、こうしたサービスによるオペレーション・シーケンスのルールや、(基礎となるプロセスの) あるタスクに参加する内部あるいは外部プロセスが果たさなければならないことをエンコードします。コレオグラフィー・サービスは、サービスの仕様を完全に自動的に実行しますが、ユーザーとの対話動作を必要とする対話型のタスクを含むこともあります。下記は、ビジネス・プロセス・コレオグラフィー・サービスの例です。
-
コレオグラフィーは、内部あるいは外部の参加者 (ユーザーまたはビジネス) の間での情報交換フローを定義し、1 つ以上のサービスから構成されるビジネス・プロセスを実装します。こうしたサービスは通常は Web サービスですが、汎用のサービスであることもあります。オーケストレーションは企業内という意味合いでよく使われますが、コレオグラフィーは仮想企業という意味合いで使われます。IBM は、ビジネス・プロセスの境界が曖昧になりつつあることから、これらの用語は等価であると考えています。
-
ビジネス・ルールは、プロセス・コレオグラフィー・スクリプトのような、サービスから外部化される決定をエンコードします。ビジネス・ルールは、下すべき決定を記述することによって、あるいは、ある種のイベントがサービスに発生した場合、あるいは外部からイベントが引き起こされた場合に取るべき一連のアクションを記述することによって、(プロセス) サービスの可変要素や条件的な要素を確立します。ルールやポリシーの外部化は、オンデマンド・オペレーティング環境にとって必須です。外部化は、既存サービスをカスタマイズすることで行われ、これにより、新しいサービスやソリューションそれぞれに対して全面的な実装を強制せずに、新しいビジネス要求を満足することができます。
ビジネス・サービス
ビジネス・サービスは、オペレーティング環境の中で定義され、構成され、デプロイされる、外部化されたさまざまな機能サービスです。ビジネス・サービスは、ユーザーや外部システムにとっての「タッチポイント」であり、実際には、コレオグラフィーによって機能サービスから作られるビジネス・プロセスを集約したビューです。ビジネス・サービスは、CBM (Component Business Modeling) などの機構によって識別され、定義されます。
共通サービス
共通サービスは、複数のサービスが使用する機能サービスやインフラ・サービスです。共通サービスは、そのままで取得、利用されることもあれば、取得された後にカスタマイズされることもあり、白紙の状態から構築されることもあります。共通サービスの例としては、下記のようなものがあります。
- 取得されるサービスは、企業外部の実体から提供され (通常はその実体がホストも行います)、その企業の 1 つ以上のビジネス・プロセスで使われます。これらは、対象企業に外部実体が提供する「ユーティリティー」サービスです。
- パーソナル化には、別のサービスがユーザーのプロファイルやプレファレンスを理解して出力を調整できるようにするサービスが含まれています。パーソナル化とカスタマイズは同じではありません。パーソナル化は、実際にユーザーの必要に応じて対話動作を変更するための、ユーザーのコントロールによるアクションであり、システム自体が行うものではありません。
- レポート・サービスは、さまざまな種類のユーザーをターゲットにレポートを生成する各種アプリケーションに対して、フレームワーク型のサービスを提供します。こうしたサービスは、オペレーション用のレポートと分析用のレポートの両方をサポートしています。
ESB (Enterprise Service Bus)
ESB は、すべてのサービスの間で仲介された対話動作が行えるようにするためのインフラを提供します。ESB は、イベント・ベースの対話動作だけではなく、サービス・リクエスト処理のためのメッセージ交換もサポートしています。どちらの場合も、メディエーションは、要求者が求める機能を提供するサービスの発見や、機能的には互換性のある要求者とプロバイダーとの間の不整合の処理などの対話動作を行います。下記のリストは、ビジネス・コネクションとメディエーション、メッセージング、イベントを説明したものです。
-
ビジネス・コネクションは、企業内のアダプター・サービスと B2B ゲートウェイ・サービスを提供し、オンデマンド・サービスがビジネス・レベルとインフラ・レベルの両面で、企業内および企業間アプリケーションと対話動作できるようにします。ただし一部の B2B プロトコル (例えば RosettaNet など) では、このアーキテクチャーのビジネス・プロセス・コレオグラフィー・レイヤーが提供する他のサービスが必要になるため、最終的にはプロセス調整が必要になることに注意してください。
-
メディエーションとメッセージング、イベントは、ESB が提供するサービス対話動作管理の別の側面です。メディエーションは、サービス・リクエストとサービス・プロバイダーをマッチングさせ、サービス・プロバイダーと要求者相互の対話動作を実現します。これには、サービス発見シナリオでの動的なマッチングのサポートも含まれます。サービス要求者とプロバイダーは、「同期型」の対話動作でメッセージを交換します。ESB サービスは、サービス・プロバイダーからサービス要求者へのメッセージへのブローカリングとルーティングを実現します。この場合、「要求者」は、誰がイベントを受け取るのか (あるいは関係するのか) を知らずにイベントを公開します。一方「プロバイダー」は、ある特定のフィルター基準を満足する関心事項をイベントに登録し、ESB はそれに従って、イベントのプロデューサーとコンシューマーとの間でのマッチングを行います。
情報管理サービス
情報管理サービスは、異種混成の情報ソース全体に渡るデータやコンテンツの、表現、アクセス、維持、管理、分析、統合などに対して、統一的な方法を提供します。
-
分析サービスは、企業内でさまざまな形式やストアとして得られる情報 (例えばデータベースやフラット・ファイル、XML ファイル、表計算形式ファイルなど) の分析をサポートします。こうしたサービスには、スコアリングなどのリアルタイム分析やデータ・マイニングのような探索アルゴリズム、そしてOLAP のような決定支援機能と、ウェアハウス・レポートが含まれます。
-
情報統合サービスは、企業全体に渡って、また企業を越えて、異種混成のデータやコンテンツ・ソースを統合する機能を提供します。また情報統合サービスによって、異機種混成で分散されたデータベース全体にまたがってデータを移動、変換、同期することができます。
-
情報アクセス・サービスは、アプリケーションが JDBC/SQLJ や ODBC などの標準 API を通して広範な種類の保存情報にアクセスするための、統一的な方法を提供します。また、XML やコンテンツにネイティブ・アクセスするための新しい標準の開発も行われています。クエリーやサーチは、リレーショナル・ソースや XML ソース、コンテンツやテキスト・ベースのソースなどの全般にわたってサポートされています。
-
メタデータ・サービスは、データの持つ意味とデータ相互の関係から見た、技術的情報とビジネス的情報の両方を処理します。またビジネスやデータの関係は、メタデータの階層構造としても表現されることが多いものです。このため、ユーザーはメタデータを使ってデータをナビゲートすることができます。情報の有効性や品質に関するデータや、使用頻度や流通状況データ、スケジュール、一般的な環境管理属性などが保存される場合もあります。メタ・タグは、インデックス付けや分類のプロセス、また非構造化情報をタグ付けして一貫性を持つ分類法にする (主にテキスト文書やその他の類似オブジェクト) プロセスをサポートします。
インフラ・サービス
インフラ・サービスは、オンデマンド・インフラが提供する機能を実現します。インフラ・サービスは、ユーティリティー・サービスとサービスレベル自動化サービス、そしてリソース仮想化サービスにカテゴリー分けされます。こうした各カテゴリーの詳細な説明は、個々のセクションを見てください。
先に触れた通り、インフラ・サービスはちょうど統合サービスのようにアプリケーション・コンテナーの中に存在しますが、統合サービスとは対照的に、こうしたコンテナーのパラメーター化は、オンデマンド・オペレーティング環境のアプリケーション・プログラミング・モデルには公開されません。また、インフラ・サービスがビジネス・サービスと同じ原理 (とツール)、つまりプロセス・コレオグラフィーやアダプター、ビジネス・ルール、メディエーションなどを使って構築されることにも注意してください (これらはどれもインフラ・サービスの構築管理にとって重要です)。この記事の焦点はビジネス・サービス・ビルダーであり、オンデマンド・インフラのコンポーネント・ビルダーではないので、これについての詳細は省略することにします。
リソース仮想化サービス
リソース仮想化サービスは、アプリケーションによる物理リソースの使用と、下にある物理リソースの実際の配置との間に、一定レベルの間接化を実現します。以下は、リソース仮想化サービスの一例です。
-
ネットワーク仮想化サービスは、VPN や VLAN などの機能を使って、物理的なネットワークの仮想化を実現します。
-
リソース・マッピング・サービスは、リソースを合成するために顧客のレガシー・リソース・リポジトリーを抽出して正規リソース・タイプに変換することに責任を持ち、またビジネス・サービスのデプロイメントと、実行時におけるオンデマンド・リソースとのオートノミックな管理対話動作をサポートします。
-
サーバー仮想化サービスは、クラスタリングやパーティショニング、仮想マシンなどの機能を使うことによって、インフラ全体に渡って物理サーバーの仮想化を実現します。
-
ストレージ仮想化サービスは、データ・グリッドなどの機能を使うことによって、分散環境全体に渡って永続情報の仮想化を実現します。
-
情報サービスは、文書や e メール、画像、音楽などの非構造化データによって提示される情報を管理し、利用するための手段を提供します。このサービスは、情報のライフサイクルや管理 (アクセスやセキュリティー、バージョン管理、アーカイブ、保存など) を記述したポリシーを調整し、強制します。
サービスレベル自動化とオーケストレーション
サービスレベル自動化とオーケストレーション・サービスによって、システム・リソースは、自己構成、自己修復、自己最適化、自己防御できるようになります。これらの機能は、オートノミック・マネージャーやリソース・マネージャーが提供する一連のサービスによって実現されます。
オートノミック・マネージャーは、モニター (Monitor) コンポーネントを経由して、生のリソース・センサー入力を受信し、処理します。そして、結果のデータをナレッジ・ベースに保存します。データはナレッジ・ベースに置かれると、確立されたポリシーに準拠するために現在のシステムやリソースの動作を評価し、データを分析 (Analyze) するモジュールによって、さらに調整、あるいは操作されます。もし、システムの動作が全体としてのゴールに一致しない場合には、オートノミック・マネージャーは、影響力の及ぶ範囲内にある構成されたリソース群を変化させる別の動作方式を検討し、ナレッジ・ベースに保存されたポリシーに従ってアクション計画 (Plan) を選択します。次にオートノミック・マネージャーは、基礎となる管理対象リソースとの対話動作によって、あるいは、システム中の他のリソースに責任を持つ他のオートノミック・マネージャーと通信することによって、実行 (Execute) 機能を呼び出します。オンデマンド・システムでの、こうしたオートノミックな動作パターンは、MAPE ループと呼ばれています。
リソース・マネージャーは、高次のオートノミック・サービスレベル・マネージャーからの構成変更ディレクティブに応答することに責任を持ちます。リソース・マネージャーは実質的に、サポートしているリソース・タイプのインスタンスを生成、管理するためのファクトリーです。このコンポーネント・モデルの動作によって、基礎となる物理リソース・トポロジーにオンデマンドで動的にバインドされる、論理的なリソース・インスタンスを仮想化することができます。各論理リソースは、それ自体がサービスであり、分散型の状態管理や対話動作に対する識別情報を持っています。下記のリストは、サービスレベル自動化とオーケストレーションに関連するサービスを説明したものです。
-
可用性サービスを利用すると、オンデマンド環境内のさまざまなインフラ・コンポーネントの可用性を、可用性に関連するサービスレベル・アグリーメントに基づいてケース・バイ・ケースで管理することができます。これには、単純にサーバーやソフトウェアのエラーをモニタリングして再起動をかけることから、ホット・スタンバイ、あるいは HACMP のようなフェールオーバー・ソリューションまで幅広い技術が含まれます。また可用性管理には、バックアップとリストア (ADSM など) やデータのミラーリング、RAID デプロイメント、ビジネス継続性や災害時復旧の見通しなども含まれます。可用性管理全体としての目的は、デプロイされるソリューションに対して、ポリシーに宣言されたレベルの回復力を与えることです。
-
構成サービスは、このサービス、またはプロバイダー管理者が規定するゴールとポリシーに基づいて、そして人の介在を最小限にとどめた上で、オンデマンド環境が自らインフラの変化に適応できるようにします。この機能は、最上位レベルのサービスから最下位レベルのリソースまで、そのサービスをサポートするインフラ全体で実現されている必要があります。
-
問題管理サービスは、環境のポリシーやサービスレベルの管理コンポーネント内で設計、デプロイされる適切なロギング機能やトレース機能を提供し、明白な理由もなく SLA 違反が起きた場合にシステムの動作をデバッグできるようにします。
-
セキュリティー・サービスは、オンデマンド環境に対して自己防御機能を提供します。セキュリティーは、SLA や SLO、ポリシーなどに基づいてインフラの中でプロビジョニングされるさまざまなサービス・インスタンスに対して、ケース・バイ・ケースで管理されます。オンデマンド環境では、侵入を検出するだけでは十分ではなく、動的に反応し、さらなる損傷を防ぐことが重要です。また、各ビジネス・サービスのセキュリティー・アーキテクチャーも監査可能である必要がありますが、これはユーザーのためであり、ユーティリティー・プロバイダーや法の執行のためでもあります。また、法に従ってさまざまなイベント (ログオン、ログオフ、Web への訪問数など) をログに記録し、一定期間保持することも、セキュリティーの面から必要です。
-
ワークロード・サービスは、デプロイされたオンデマンド・サービス・インスタンスすべてについての集約負荷が、環境の中でプロビジョニングされた 1 つ以上のリソースのインストール容量を越える場合に、インフラのパフォーマンスとワークロードをバランスさせる機能を提供します。この場合、リソースの調停が、どのインスタンスが制約付きのリソースを取得し、どのリソースが「不足に苦しむ」かを決定します。この決定は、対象インスタンスに適用されている SLA やポリシーに基づいて行われます。全体的なパフォーマンス管理は、システムを実行しているさまざまなクラス全体に渡ってパフォーマンス関連のゴールを的確に達成するために、追加リソースのバランシングとスケジューリング、プロビジョニングの組み合わせによって行われます。
-
データ・プレースメント・サービスは、キャッシュの作成、維持管理、破壊と、データの複製を処理します。このサービスはシステム中のクエリー・ストリームをモニターし、全体的なシステム・パフォーマンスを改善するためにキャッシュや複製を使用する機会を探します。そうした判断のコントロールは、キャッシュや複製の位置や性格を決定するプレースメント・ポリシーによって行われます。
ユーザー
ユーザーというのは、ビジネス・サービスの対話動作という意味合いから、適切なアクセス・チャネル・デバイスを使って役割を果たす人間のことです。ユーザーには、ビジネス・サービスと直接対話動作するユーザーもあれば、あるユーザーの代理として働く従業員、ユーザーである従業員もあります。ユーザーの例には、顧客やパートナー、サプライヤー、従業員などがあります。
ユーザー・アクセス・サービス
ユーザー・アクセス・サービスは、さまざまなデバイス・タイプや対話動作モード、接続トポロジーが、オンデマンド・オペレーティング環境とエンド・ツー・エンド・ソリューションでシームレスに参加するための機構を提供します。下記のリストはユーザー・アクセス・サービスを説明したものです。
-
アダプテーション・サービスは、CPU スピードや RAM、永続ストア、ディスプレイ・サイズ、オペレーティング・システム、プロセッサー命令セットなどに基づいて、さまざまなデバイス機能を実現します。この中には、デスクトップやラップトップ、パーベイシブ・デバイスなどが含まれます。
-
対話動作サービスは、視覚や手動、音声などによる単一モードの対話動作を含め、さまざまな種類のユーザー対話動作モードを実現します。また、それらの組み合わせや、対話動作のさまざまな「豊富さ」レベルやスタイルも実現します。
-
接続性サービスは、使用パターンや、接続 QoS Bearer ネットワーク・プロトコル、モビリティー、位置や存在の情報、地理的なカバー範囲、接続請求モデルなどに基づいて、また単一企業なのか複数の企業またはサービス・プロバイダーなのかといったドメイン、対応するセキュリティー・モデルなどに基づいて、さまざまなトポロジーを実現します。
ユーザー対話動作サービス
ユーザー対話動作サービスは、ユーザーがビジネス・サービスと対話動作するための表示機能を提供します。こうした機能には、表示サービスやコラボレーション・サービス、サーチ・サービス、コンテンツ・サブスクリプション・サービスなどが含まれます。下記のリストはユーザー対話動作サービスを説明したものです。
-
コラボレーション・サービスは、ユーザーが他のユーザーと対話動作できるようにするサービスであり、人による対話動作の本質的な部分です。このサービスは、おおまかにチャット・コラボレーション (e メールやチャット) と、チーム・コラボレーション (e ミーティングやチーム・ルームなど) に分類されます。
-
表示サービスは、使用されるユーザー・アクセス・サービスとは独立に、ユーザーに認識、理解可能な形式でビジネス・サービスを構成します。またこのサービスによって、ユーザーから入力されるデータは、さまざまなサービスで処理可能な情報に変換されます。
ユーティリティー・ビジネス・サービス
ユーティリティー・ビジネス・サービス・レイヤーは、適用される価格設定パッケージに対して、どのリソースあるいはサービスの、どういった使い方が計測され、定義され、許可されるべきかを定義します。これによって、こうしたパッケージを使うためのサポート機能が提供されます。ユーティリティー・ビジネス・サービスには、下記のものが含まれます。
-
価格設定コンポーネントと請求コンポーネントは、技術的な測定値を金銭的な単位に変換する機能を提供し、それに基づいて利用者に請求を行います。これは、その価格設定パッケージ (例えば単位使用量当たりの価格を定義します) と、そのリソース使用量を測定した計測用の記録を使って、リソースのコストあるいは価格を計算するプロセスです。また、利用者への請求書の中に含めるために、SLA 違反に対するペナルティーも処理する必要があります。
-
計測サービスは、利用者によるサービスやリソースの使用率に関連した情報を収集する機能を提供します。この使用率は、リソースの使用状況や消費量によって表現されます。計測サービスによって生成される収集情報は、計測イベントの中で定義されます。こうした計測イベントは、利用者への課金の基礎となります。また、さまざまなサービス・プロバイダー間におけるオンデマンドのサービスやリソース使用に対する請求決済を含め、コスト会計やリソース使用率レポートの基礎ともなります。
-
ピアリングと決済は、どちらも価格設定や請求に似たプロセスです。これらのプロセスは、オンデマンド・ビジネス・サービスの使用に対して利用者に請求を行うのではなく、ビジネス・サービス自体が使用するリソースやサービスに対する会計処理を行います。ピアリングも決済も、ビジネス・サービスの利用者からは見えません。
謝辞
この記事は、IBM 全体で構成されるチームの協力によって作成されました。そうした貢献者、Jim Colson氏、Angel Luis Diaz 氏、Donald F Ferguson 氏、George Galambos氏、Ray Harishankar氏、Shankar S Kalyana氏、Kristof Kloeckner氏、Jeffrey Nick氏、Marc-Thomas Schmidt氏、Sham Vaidya氏、そして Dan Wolfson氏に感謝いたします。
参考文献
著者について | | | Marc-Thomas SchmidtはDistinguished Engineerであり、過去10年以上、IBMのビジネス統合技術に従事してきました。そうした技術には、ワークフロー管理システムから高度メッセージ指向ミドルウェア、ビジネス・プロセス管理技術まで含まれています。現在は、IBMのESB技術に関する技術的アーキテクチャー開発の中心として活躍しています。
|
| | | Shankar S Kalyana は IBM の Executive IT Architect です。 |
記事の評価
| 
