この記事では最初に、問題判定にまつわる様々な問題点と、（しばしば　不十分なものとなる）ログ・メッセージの果たす役割について調べて行きます。Common Base Eventに用意されているフォーマットと内容が、その一つの答えとなります。そこでCommon Base Eventの構造を詳細に説明し、主な目標を示すことにします。つまりCommon Base Eventにどのようなコンポーネントがあるかを特定し、状況をクラス分けするのです。これからの説明で、全てのイベントが12の状況タイプに分類されることが分かるでしょう。これが実際にどのように動作するのかを簡単に説明するために、まずログ・メッセージはどのようにCommon Base Eventsに変換されるのか、そして次に、フェールしようとしているシステムの修復を目標として、オートノミック・マネージャーがどのようにイベントを分析するのかを解説して行きます。

コンピューター・インフラのための神経系

コンピューター・システムにおいて、問題はどのようにしてその姿を現し、また診断を受けるのでしょう？ 「アプリケーションが生成するメッセージを通して」というのがその答えです。専門の技術者であれ、一般的なコンピューター・ユーザーであれ、誰でもこうしたメッセージには経験があるものです。一部のメッセージは良く書かれており、素早い診断や解決の助けとなります。ところがあまりに簡単、不明瞭で、それを見た人を怒らせる以外、何の役にも立たないメッセージも山のようにあります。

良いメッセージであれ悪いメッセージであれ、どのようなメッセージも同じものが2つあることはなく、しかもアプリケーション間でのメッセージには、ありとあらゆるスタイルとフォーマットがあるものです。一つのアプリケーションの中であっても、メッセージの標準やメッセージの作者に大きな幅があることに皆さんも気がつくでしょう。全てのメッセージがアプリケーションからユーザーへの伝達を意図しているわけではありません（場合によると、アプリケーションから専門家への伝達すら意図されていません）。アプリケーションが生成する多くのメッセージは、別のアプリケーションで使うためのものです。そのためには何にもまして共通メッセージを厳密に定義し、アプリケーション同士が理解できるようにしておく必要があります。

こうしたメッセージはすべて、神経系と似たように機能します。私たちの神経系が、特に意識しなくても神経パルスを使って心拍や体温を制御するのと同じように、オートノミック・コンピューティング・システムではメッセージに依存することによって、人の介在無しにアプリケーションの健全さを確保するのです。

上に戻る

一貫したメッセージング

メッセージ・ログは必然的に製品依存であり、特定のベンダー（場合によっては特定なアプリケーション）に特有の標準や用語に従います。こうした場合にメッセージが一貫した解釈をされるように保証するためには、どのようにすれば良いでしょう？ その答えがCommon Base Eventモデルなのです。この標準は幾つかのタイプのイベント、特にログやトレース、管理、それにビジネス・イベントなどに対して容易に適用することができます。

さらに皆さんの興味を引くと思われるのは、Common Base Eventモデルはメッセージの多様性に関する2つの大きな課題、つまりフォーマットと内容、に対応しようとしているという点です。

Common Base EventはXMLスキーマ定義（.xsd）によってフォーマットの一貫性を保証していますが、これは現在では自然な選択と言うことができます。XSDによって必要な構造が強制されますが、それとは別に、XSDは今やWebサービスで必要不可欠のものとなっています。理想的な目標としては、例え異なるベンダー製のものであっても、多様なアプリケーションにまたがってオートノミック制御をすることです。こうしたアプリケーション間の通信において、Webサービスは共通言語となっています。

またXSDによって、一貫したメッセージ内容を保証するために必要なスコープが定まります。この記事の後の方で分かる通り、これは単にメッセージが運ぶべき情報のタイプを定義することにとどまりません。XSDの定義の多くの部分が、状況またはコンポーネントを記述するために選択する実際の言葉について規定しているのです。

Common Base Eventモデルを使うことによって、（メッセージの）フォーマットと内容の一貫性が保証されるようになるだけでなく、完全さも高めることができます。メッセージは多くの場合、開発者が時間に追い立てられる中で書きます。開発者は多くの情報は持っているのですが、スペースは限られています。彼らはこの限られたスペースの中に、状況の詳細と、その状況が起こった背景を詰め込まなければなりません（例えば、どのコンポーネントが、どこで壊れたのか、など）。ですからあのログ・メッセージが、その目指す所とかけ離れてしまう場合が多いのも無理がありません。ところがCommon Base Eventスキーマを使うと、必須要素があることによって、こうした情報が必ず入るように保証されるのです。

上に戻る

Common Base Eventの構造

Common Base Eventモデルはその前提として、メッセージとは、その根底にある状況を示唆するイベントである、としています。ある状況が単一のイベントを引き起こす場合もありますが、関連して幾つかのイベントを引き起こす可能性が高いと言うことができます。

イベントと状況のデータを構造化するために、Common Base Eventでは最上位レベルに3つの主な部分を持っています。Common Base Eventの定義文書ではこれを3タプル構造と呼んでいます。これらの部分は下記に関する情報を提供します。

1. 特定な状況をレポートするコンポーネント
2. 状況に影響を受けたコンポーネント
3. 状況そのもの

状況に影響を受けたコンポーネントはしばしば、その状況をレポートするコンポーネントでもあります。そうした場合、影響を受けたコンポーネントの情報のみを含むように、とCommon Base Event定義では強調しています。結局、重複したデータでネットワークを詰まらせるのは避けるべきだということです（後ほど、影響を受けたコンポーネント用にキャプチャーされた情報タイプと、レポートするコンポーネント用にキャプチャーされた情報タイプが同じであることが分かります）。

3番目のタプル、つまり状況に関する情報、は必須です。またタプル外には、Common Base Event自体に関連づけられたコア情報もあります。この情報には、例えばイベントを識別し、その優先順位を示すような鍵となる属性が含まれています。この構造には、特別な機能やベンダー特有の要求をサポートするためのオプション的な部分も幾つか含まれています。

これに関しては先の方でさらに説明します。

上に戻る

さらに掘り下げると

XMLスキーマは読むことはできますが、素早く概略を見るには最適なものではありません。ところがCommon Base Event仕様には、データやイベントの様々な部分の関係を要約するUML図（Unified Modeling Language diagram）があるのです。図1は最上位レベルでのCommon Base Eventと、その3つのタプルを示しています。

上の図を元にUMLを簡単に説明すると、下記の通りです。

• 3つのボックスはスキーマでの要素を表します（ComponentIdentficationとSituation、それにCommonBaseEvent自体）。各ボックスの一番上の長方形にはスキーマ要素の名前が入っています。
• 名前の下の長方形には各要素に対する簡単なデータがあります。明るい青のアイコンはこうした各データを表し、このアイコンに続いてデータの名前と、そのデータ型があります。Situation要素にはcategoryNameというデータがあり、この場合は文字列です（図には示されていない値に対しての制約を含むものですが、これについては後ほど説明します）。
• 勘違いしては困りますが、3つのボックスが3つのタプルに対応しているわけではありません！ ここで（UML UMLの関連を示す）ラインが登場するのです。一番上にあるボックスCommonBaseEventは3つのタプルのうちの一つではありませんが、3つのタプルを含むルート要素なのです。CommonBaseEventはそれ自身に関する単純データを幾つか、ボックスの中に持っていますが、同時にまたボックスに接する菱形を3つ持っており、それぞれ矢印が出ていて他の3つのボックスを連結しています。これはCommonBaseEventが、こうした他の複合要素を持っていることを意味します（UML用語では集約と言います）。
• CommonBaseEventからComponentIdentificationに向かう2つの菱形と2本の矢印があります。一つは影響を受けたコンポーネントで、もう一方はレポートするコンポーネントで、それぞれsourceComponentIdというラベルとreporterComponentIdというラベルの付いたラインで示されています。矢印の先の数字は、CommonBaseEventの期間内にその要素が何回起こるかを示します。ですからsourceComponentIdの場合、その数字は1です（そして常に1です。これは必須です）。reporterComponentIDの場合は、0または1です（reporterComponentIDはsourceComponentIdと異なる場合にのみ存在します）。これを簡単な図で示すような規則はありません。この図は単に、CommonBaseEventにはreportComponentIdsが最低で0、最高で1つあることを示しています。
• 3番目のタプルSituation（データ）は一番下の左にあります。矢印の先が示すように、こうした要素が1つ存在する必要があります。

皆さんは図に表現された各部分が、あまりに簡単なことに驚いているかも知れません。確かに、例えばSituationの場合であれば、categoryNameと呼ばれる単純な一つのデータのみで状況を識別できるわけではありませんよね？ その通り、これは不完全な図なのです。Situationは後ほど説明するような、他の要素も含んで（集約して）いるのです。

上に戻る

Common Base Eventに対するコア・データ

Common Base Eventに対するUMLの概要に関しても説明を終える前に、CommonBaseEventボックスの中にある単純データに戻ろうと思います。こうしたデータは、イベント自体に関するメタデータなのです。

• extensionName はイベントに対して名前を与えるために使うオプション・プロパティです
• globalInstanceId はこのイベントを唯一に識別する値を含む必要があります（それまでに生成された他の全てのCommon Base Eventsと共にデータベースに保存されている場合であっても、識別子は真にグローバルに唯一である必要があります）。localInstanceIdがある場合には同様の識別機能を果たしますが、これは特定なイベントを生成するプロセス内で唯一であることしか保証しません。
• creationTime はイベントの日付/時間のスタンプです
• severity は0から70の範囲の数字で、レポートするコンポーネントに対して状況が与える影響を段階付けします。これは、0から60の範囲で10毎に増える、7段階の事前定義した値です（例えば10-情報、30-警告、60-致命的など）。あるイベントに対する深刻さの値は、イベントのもたらす人的影響に基づいて、その分野の専門家が提供すべきです。問題管理の期間中は、最も深刻なイベントが最初に注目を集めるようにすべきです。
• priority は0から100の範囲の数字で、Common Base Eventsを監視しているアプリケーションがこのイベントをどのように扱うべきかを示します。数字が大きいほど、アプリケーションはより迅速にそのイベントに対応する必要があります。これには事前定義された数字が3つあり、10-低、50-中、70-高です。
• msg は人に読める形のテキストで、通常はアプリケーションのメッセージとして必要不可欠なコンポーネントです。実は、これがオプションなのです（ただし相変わらず推奨ではあり、人に読めるテキストを表すようなカタログ情報が無い場合には特に推奨されます）。これは奇異に思えるかも知れません。なぜイベント・メッセージにメッセージ・テキストが無いのでしょう？ 一つには、National Language Support（私がアプリケーションを英語、フランス語、ルーマニア語でレポートするように設定したいと思うかも知れません）用にメッセージの実行時バインディングをサポートするために、msgの代わりにMsgDataElement複合型を使うことがあります。また別の理由として、特定なビジネス・イベントに伴うメッセージ・テキストは無いかも知れず、そうした場合には、単にCommon Base Event定義を正しく維持するだけのために疑似テキストを作り出す必要がないこともあります。Common Base Eventモデルが本質的に目標としているのは、システムをオートノミックに管理するための道を開くことであることも思い出してください。オートノミック・マネージャーはCommon Base Event定義のうち、より固定的な部分を元にレスポンスを作るでしょう。そうした方が、人が読むことを想定した中途半端なテキストを構文解析するよりも容易である可能性が高いと言えます。
• repeatCount とelapsedTime とはお互いに関係しています。前者は指定された時間間隔内に同じイベントが起こる回数を計数し、一方elapsedTimeはその時間間隔を指定します。
• sequence number はイベントを処理すべき順序を規定するという点で、多少priorityと似たように動作します（イベントを管理するアプリケーションにイベントが到着する順序がバラバラな可能性があり、しかも処理の順序が致命的に重要な場合、これは特に便利です）。
• version はCommon Base Event仕様のバージョンを言います。コモン・ベース・イベントを受け取るプログラムは、これを使用してバージョン間の互換性に関連する問題を処理することができます。
• otherData は、アプリケーション特有なためCommon Base Eventモデルでは名前を持つ要素としては存在していないようなデータの全てを捉えて保持します。Common Base Eventを受け取るソフトウェアはこの情報を利用しないかも知れませんが、それでもこれを保存し、転送する必要があります。イベントを転送する連鎖の中にある、アプリケーション的なソフトウェア（または人）がこの情報を利用するかも知れません。

Common Base Eventでコアとなるヘッダー情報に関しては見ましたので、コンポーネント識別をもう少し詳しく調べることにしましょう。

上に戻る

Common Base Eventモデルではコンポーネントをどのように定義するか

次のUML図はCommon Base EventのComponentIdentification部分のみを示しています。これは影響を受けたコンポーネントと、レポートするコンポーネントの両方（最初の2つのタプル）で使用している部分です。

ComponentIdentificationには明確な目的があり、それはコンポーネントを識別することです。先ほど、イベント自体はグローバルに唯一な識別子（globally unique identifier: GUID）で識別することを説明しました。現実の世界では、コンポーネントも同じようにグローバルに識別できます。ただしCommon Base Eventモデル・チームではコンポーネントの識別には様々な手法があることを認識しており、Common Base Eventモデルの定義の中でそうした手法を許しています。

さてComponentIdentification要素の最上位レベルには、locationという単純なデータがあります。これは何らかの物理アドレスを示すもので、コンポーネントの位置を表します。locationがIPアドレスなのかSNA番号なのか、ホスト名なのか、あるいは全く違う何かなのか、を示すのは次の属性locationTypeです。Common Base Eventの仕様では、20近くの　既知のロケーション・タイプが用意されています。できればこれらに従うべきでしょう。もちろん　既知のロケーション・タイプが無い時には「Unknown」が位置の値となります。

applicationプロパティは通常、コンポーネントに対するビジネス名です。これは、例えばAccounts Receivable Module v4r5.3のような、ビジネス・アプリケーションに実際に対応するコンポーネントにとっては特に便利です。

次に、名前の中にcomponentを持つ4つのプロパティを調べます。component自体は、（それがアプリケーションであれ製品であれ、またはサブシステムであれ）コンポーネントの名前であり、subcomponentはさらにコンポーネント内での一つの要素を区別します。ですからJava技術での例を挙げるとcomponentは「My Currency Exchange Kiosk Application」であり、subcomponentはJavaクラスやメソッドの名前になります（com.mycompany.utilities.EuroConverter.toEuros()）。componentIdTypeはコンポーネントの種類を識別するもので、　既知のキーワードを幾つか持っています（例えばProductNameやDeviceName、ServiceNameなど）。componentTypeプロパティは認識されたコンポーネント・タイプを保持するために使用しますが、コンポーネント・タイプはベンダー特有の可能性があります（例えばIBMDB2UDB）。Common Base Event仕様には長々とした付録が付いており、よく定義された名前を使って、全てのIBM®製品や他のベンダー製品の多くを分類しています。名前の例としてはWebSphereApplicationServerやMicrosoftWindows_XP_Professionalなどがあります。この付録ではコンポーネントの階層構造を認識しています。ですから例えばアプリケーション・サーバーの場合であれば、例えばEAR_Fileや、Web_Module、J2EE_Applicationなどのコンポーネントの幾つかをホストすることができます。これにはコンポーネント・タイプ定義を名前空間に置くという明確な意図があり、そうすることによってその名前空間を今後のバージョンのCommon Base Event定義に容易に組み込むことができ、componentTypeプロパティを検証できるようになります。

instanceId は、精査されるコンポーネントがひとつ以上発生する場合に意味があります。ただし、例えばデータベースなどに対しては（未知ではありませんが）それほど意味がありません。一方Enterprise Java Bean (EJB)では、ほとんど必然的に意味があります。EJBインスタンスへの参照を、このinstanceIdプロパティで保持できるのは便利です。

残りの3つのプロパティ、executionEnvironmentとprocessed、それにthreadedはどれも、アプリケーションまたはオペレーティング・システムが作業を論理的に分割する方法を規定します。こうした詳細が適切で既知の場合に、これらを使います。

こうしたプロパティが全て入手できれば、レポートするコンポーネントと影響を受けるコンポーネントがうまく識別できることが分かるでしょう。では、イベントを引き起こすに至らしめた状況についてCommon Base Eventモデルがどういうことを言うかについて見てみましょう。

上に戻る

Common Base Eventで状況データをどのように定義するか

Common Base Event定義内部での動作で、最も素晴らしいのは状況のデータに関わる部分です。これはCommon Base Eventの持つ3つのタプルの3番目であり、また最も重要なものでもあります。ここでも再度UML図を挙げますが、ここでは状況データの詳細を示しています。

主な要素はSituationであり、これはそれ自身に関する一つのプロパティcategoryNameを持っています。このプロパティによって、12ある状況タイプのうち、そのイベントがどれに当たるかを指定します。SituationType要素自体はSituationの下にあります。SituationTypeを指す矢印を共有している12のボックスが、StartSituationからOtherSituationまでの12の状況タイプを図式的に表しています。

ではこうした状況タイプとは何なのでしょう？ Common Base Eventチームでは、数多くのIBM製品や他社製品から得られる何百という様々なログ・ファイルの中から、何千ものメッセージを取り出して分析しました。こうしたログで記述されたあらゆるイベントの中から、正式に認識できるような重要な状況を幾つか抽出しようと試みたのです。

この分析から明らかであったのは、本質的に同じことを言うのに多くの方法がある、ということでした。コンポーネントの起動に関しても、「begin work」「be started」「launch」「bootstrap」などの言い方があるのです。そうした言葉を含む　従来のメッセージはどれも、Common Base Eventフォーマットに変換する時にはStartSituationに属すことになるでしょう。

状況タイプ記述情報の全てに共通なのはreasoningScopeですが、これはイベントのスコープが、影響を受けるコンポーネント内部（INTERNAL）か、あるいは外部に影響を与える可能性がある（EXTERNAL）かを規定します。

このクラス図から、12の各状況タイプにはそれぞれさらに、単純データ要素があることが分かります。多くの場合このデータは同じであり、幾つかの状況タイプ（StartSituation,StopSituation,ConnectSituation,ConfigureSituation,CreateSituation,DestroySituation、RequestSituation）にはどれもsuccessDisposition単純データ要素があります。successDisposition単純データ要素がイベントの結果を示すためにとる有効な値はSUCCESSFUL、またはUNSUCCESSFULです。

リストに挙げた状況タイプの最初、StartSituationは、コンポーネントの開始を処理するイベントのために予約されています。StartSituationは、successDisposition要素（SUCCESSFUL/UNSUCCESSFUL）とは別に、situationQualiferを持っています。これは3つの値をとりますが、その意味は自明でしょう。値はそれぞれSTART INITIATED, RESTART INITIATED, START COMPLETEDです。この構造は、残る11の状況タイプに典型的なもので、簡単に説明すると下記のようになります。

• StopSituation はStartSituationに対応するもので、コンポーネントのシャットダウンを処理するイベントのためのものです。
• ConnectSituation は、あるコンポーネントと別のコンポーネント間の　接続に関して記述するイベントのためのものです。
• RequestSituation は、長期間実行のリクエストまたは複合リクエストが成功したかどうか、またはリクエストの状態をコンポーネントが識別するためのものです。
• ConfigureSituation は、例えば設定変更リクエストに対して応答中といったように、そのコンポーネントの設定に関して何らかの説明するためのものです。
• AvailableSituation は、コンポーネントがその稼働状態について、またはそのコンポーネントが使用可能かどうかについてコメントするためのものです。これには少し違った役割もあり、それについてはCommon Base Event仕様で詳しく説明されています。
• ReportSituation は使用の状態、つまりCPU利用率、バッファー・サイズ、メモリ割り当てなどに関してレポートするイベントのためのものです。reportCategoryTypeのみがこれを使え、有効な値は、PERFORMANCE, HEARTBEAT, SECURITY, STATUSです。
• CreateSituation は、コンポーネントが何かを作っていること（例えばファイルやドキュメント、Enterprise Java Bean (EJB)などを作っていること）を知らせるイベントのためのものです。
• DestroySituation はCreateSituationに対応するもので、何かの消滅を処理するイベントのためのものです。
• FeatureSituation は、ある機能（例えばサービス）が使用可能（または使用不可）であることを、コンポーネントが知らせるためのものです。
• DependencySituation は、必要とする別なコンポーネント（または機能）をコンポーネントが見つけられないことを示します。dependencyDispositionType修飾子は依存関係がMETか、またはNOT METかを示します。
• OtherSituation は、他のどれにも合わないようなイベントに対する「その他全て」を表す状況タイプです。

上に戻る

Common Base Eventモデルにおける、その他の状況データ

Common Base Eventモデルに関連してその他にも幾つか、下記のUML図で示すような複合型があります。これらは3番目の状況データ・タプルの一部と考えることができます。

MsgDataElementはメッセージ自体のメタデータを保持します。幾つかのプロパティ名に catalogがありますが、これはメッセージのテキストや、予想されるパラメーターを保持する任意のリポジトリの汎用名です。これはプロパティ・ファイルのように単純な場合もあれば、メッセージ・データベースのように高度のものの場合もあります。msgIdは伝統的なメッセージ識別子で通常7から9文字から成り、たいていの場合、おかしくなったアプリケーションのトラブルの深刻さや、どの部分がおかしくなったかを表す略語が詰まっています。msgIdTypeは、メッセージ識別子の構成に幾つかの標準があることを認識しています。そうした標準に従うのであれば、その標準をここに置きます。こうした良い情報が全てオプションとなっていますが、これは皆さんには意外かも知れません。しかしMsgDataElementは、実行時バインディングのメッセージ・パラメーターをサポートできるようになっているのです（例えばメッセージを表示する時に、言語を変えたいような場合のために）。これは製品特有のイベント・マネージャーの多くで特徴となっています。ところが、MsgDataElementが持つ情報はこのスキーマの他の部分で行われるような厳格な分類の対象になっていない、という正にその理由のために、オートノミック・マネージャーはMsgDataElementが持つ情報を使わずに状況に対応できる必要があるのです。そうは言っても、そうした情報があるのであれば、当然ながらCommon Base Eventに提供すべきです。

ExtendedDataElementは何度でも現れ得るもので、各インスタンスは内部に任意の数のExtendedDataElementを持つことができます。その中にある単純データの汎用名（name,type,values,hexValue）から想像できると思いますが、ExtendedDataElementは他のどこにも入らないような、いかなるイベント・データも受け入れる柔軟な容器と言うことができます。

ContextDataElementによって、特定なイベントを何らかのコンテキストにフックできるようになります。このコンテキストは任意で、製品やアプリケーションで定義されます。同じコンテキストに属すCommon Base Eventはそれぞれ同じcontextIdまたはcontextValueを共有します。使い方として一つ考えられるのは、例えば「月末管理報告」のように、どのようなコンポーネント属性によっても一緒にできないような重要なビジネス・プロセスです。CommonBaseEventとContextDataElementとの関係では、同じCommon Base Eventが異なる多くのコンテキストに加わることを許していることに注意してください。ですからContextDataElementによって、様々なメッセージが様々なイベントにまたがって相関関係を持つことができるようになり、そうしたメッセージには、トランザクションの実行または何らかの作業単位の実行によって生成される全メッセージも含まれる可能性があります。

最後にAssociatedEventとAssociationEngineがあります。Association engineはイベント間の関係を確立するアプリケーションです。既存のログ・メッセージをCommon Base Eventに変換するプロセスの一部として、一つまたは多数のassociation engineが呼び出される可能性があります。コンテキストの場合と同様に、同じイベントに対していくらでも必要なだけassociation engineを結びつけることができます。　関連付けられたイベントの情報の追加は、Common Base Eventを処理するオートノミック・マネージャーの仕事でもあるでしょう。（つまりオートノミック・マネージャーは association engine として動作し得るわけです）。

関連したエンジン情報が何によって作られるにせよ、タイプ・プロパティはcontextIdやcontextValueと同じように、イベント間に存在する関連づけのタイプ記述に使うことができます。Common Base Eventエンベロープは2つの異なる方法でAssociationEngineを参照します。個々のイベントはそれ自体、そのイベントを使ったAssociationEnginesへの参照を保持することができます。逆にCommon Base Eventエンベロープは、その特定なエンジンが解決したイベントの全IDと共に、AssociationEngineをリストアップします。

モデル全体を表すクラス図を示して、Common Base Eventモデルのプロパティの詳細に関する説明を終わりたいと思います。

上に戻る

Common Base Eventモデルの応用

皆さんがCommon Base Eventモデルにおける状況タイプの分類やその他の定義に対して同意するにせよ同意しないにせよ、重要なのは共通の分類法を持った方が良い、という点です。既存のソフトウェア供給者は、そうしたシステムがもたらす利点を既に認識しています。例えばCiscoはIBMの動きに追随しています。複数の製品がCommon Base Eventモデルを採用すれば、異なるベンダー間の製品に渡っても、真のオートノミック・コントロールのスコープが実現します。

当然ですが、皆さんの製品をCommon Base Event対応にするためには多くの作業が関係してきます。生成されるイベントが全てCommon Base Eventになるように、全ソフトウェアを即座に書き換えられるようなベンダーはありません。必要なことはCommon Base Eventを生成できるという機能であって、必ずしも既存のログ・エントリーをCommon Base EventのXMLフォーマットで保存することではありません。一番うまくこれを実現するには、アダプターと呼ばれる小さなソフトウェアを使って、既存のログ・メッセージを等価なCommon Base Eventにマップすることです。こうしたマッピングを定義するにしても、まだまだ多くのことが必要になりますが、これは徐々に進められるプロセスです。IBMではGeneric Log Adapterを作っており、これはオートノミック・コンピューティング・ツールキットに同梱されているログ・トレース・アナライザーのコンポーネントとして提供されています。共通フォーマットがソフトウェアによって直接生成されるようになるまで、このツールを使うことによって、すぐにでも数多くの製品が共通フォーマットを利用できるようになるのです。

Common Base Event仕様では、イベントに対する状況タイプを示すような共通の言葉を既存のログから抽出してリストアップしています。ですから例えばCommon Base Event仕様では、ある従来のログ・メッセージをFeatureSituationとして識別するためのガイダンスとして次のようなものを用意しています。

                
Existing situations include words like now available, currently available, 
and transport is listening on port 123, for example:
SRVE0171I: Transport HTTPS is listening on port 9443 
MSGS0601I: WebSphere Embedded Messaging has not been installed

図6はWebSphere Application Serverが生成したメッセージの変換プロセスを示しています。

上に戻る

まとめ

この記事では、今日の複雑なシステムを管理する上で人が介在することによる問題を取り上げ、これがITリソースにどのような負荷になるか、という点から説明を始めました。続いて、根底にある深刻な問題としてログ・フォーマットのテキストが様々である点を指摘し、特にログ・フォーマットがコンピューター・アプリケーションの神経系であり、自動管理の根幹である場合において、そうした点が問題となることを説明しました。

さらに次にはCommon Base Eventモデルの利点を調べ、このモデルによってログ・メッセージのフォーマットや内容がいかに一貫性を持ったものになるか、またコンテキスト情報がいかに完全なものになるかについて述べました。その後Common Base Eventメッセージを顕微鏡に置き、その定義の3つの部分、つまりタプルを細かく見ながら説明しました。最初にコンポーネント情報を専門に扱う同等なタプルを2つ見て、次に状況データ、特に何百という状況記述をたった12に合理化する状況タイプ、を見ました。

そして最後に、古いログ・フォーマットからCommon Base Eventフォーマットに変換するソフトウェア・アダプターを使うことによって、Common Base Eventへの移行が段階的に行えることを示しました。オートノミック・システムは一つの製品で有効という以上のものである必要があり、異なるベンダーの製品にまたがって有効であることが望まれています。オートノミック・システムでは、様々なコンポーネントをつなぎ込んでも影響を受けないようになっている必要があります。Common Base Eventはそうしたことを可能にする共通でオープンな標準であり、最初からWebサービスと統合できるように設計されています。近い将来に多くのソフトウェア・ベンダーがIBMの呼びかけに応え、こうした利点を共有できるようになることを期待しています。

参考文献

• Rational®ではCommon Base Eventモデルの概要を作成しています。
  
  
• 自己修復インフラの構築に向けてIBMとCiscoがどのように協力するかについて、「IBM and Cisco Collaborate on Autonomic Computing Solutions」を見てください。
  
  
• Common Base Eventモデルの仕様が、記事「Specification: Common Base Event」で分かりやすく説明されています（developerWorks, 2003年7月）。
  
  
• press releaseでCommon Base EventモデルをOASIS（Organization for the Advancement of Structured Information Standards）に提出したニュースを見ることができます。
  
  
• OASISとWebサービス批准についてさらに詳しくはOASISにあります。
  
  
• IBMが提供している、オートノミック・コンピューティングの「オートノミック・コンピューティング・アーキテクチャーに関するブループリント」を見てください。
  
  
• 次第に複雑になりつつある今日のアーキテクチャー環境において、オートノミック技術がどのような役に立つのかを説明した一般的な記事として、「 Autonomic computing: Can it help to manage the increasingly complex information environment? Autonomic computing 2: Implications for IT services 」がITサービスにおける意味合いを説明しています。
  
  
• IBMはautonomic computing manifestoを公開し、情報技術に関してのIBMの視点を説明しています。
  
  
• 初心者向けに好適な記事として、オートノミック・コンピューティングの根底にある技術を紹介しつつ、その未来像を紹介した「The Vision of Autonomic Computing」があります。
  
  
• IBMライブラリーで、オートノミック・コンピューティングに関する他の話題についても学んでください。
  
  

著者について

Studio Bの作者であるDavid Bridgewaterはアプリケーション開発経歴が長く、イギリスの、ある大型小売業にJava技術を導入する際には専門家として数年間腕をふるいました。現在はIBMでのJava/WebSphere®の契約講師であり、また独自のトレーニング資料やチュートリアルを作成しています。また、JavaやJ2EEを使用したWebアプリケーション開発を中心とした記事でIBMの技術（WebSphereソフトウェア）をサポートしつつ、技術関係の雑誌にも頻繁に寄稿しています。連絡先はdbridgewater@jbridge.co.ukです。

この記事を評価する

コメント

上に戻る

目次

• コンピューター・インフラのための神経系
• 一貫したメッセージング
• Common Base Eventの構造
• さらに掘り下げると
• Common Base Eventに対するコア・データ
• Common Base Eventモデルではコンポーネントをどのように定義するか
• Common Base Eventで状況データをどのように定義するか
• Common Base Eventモデルにおける、その他の状況データ
• Common Base Eventモデルの応用
• まとめ
• 参考文献
• 著者について
• コメント