共通イベント・インフラストラクチャー （CEI） 1 WebSphere ESBアナウンスメントWorkshop

WebSphere ESBアナウンスメントWorkshop
共通イベント・インフラストラクチャー
（CEI）
Copyright IBM Japan Co.,Ltd 2006
1
目次
‰
WESBのCEI概要
‰
CEIの前提
‰
イベント・ソースの開発
‰
イベント・サーバの構築
‰
イベント・コンシューマの利用と開発
‰
まとめ
2
Disclaimer
‰
当資料で提供する技術情報は、各製品の出荷前コードに基づくものを含
みます。
‰
この資料は日本アイ・ビー・エム株式会社ならびに
日本アイ・ビー・エム システムズ・エンジニアリング株式会社の正式なレ
ビューを受けておりません
‰
当資料は、資料内で説明されている製品の使用を保証するものではあり
ません。
‰
資料の内容には正確を期するよう注意しておりますが、この資料の内容
は2006年3月現在の情報であり、製品の新しいリリース、PTFなどによっ
て動作、仕様が変わる可能性があるのでご注意下さい。
‰
今後国内で提供されるリリース情報は、対応する発表レターなどでご確
認ください。
3
WESBのCEI概要
4
WESBのCEI
WebSphere Process Server
Service
Components
Supporting
Services
Business
Business
Processes
Processes
Interface
Maps
Human
Human
Tasks
Tasks
Business
Business
State
State
Machines
Machines
Business
Object Maps
Business
Business
Rules
Rules and
and
Selectors
Selectors
Relationships
WebSphere ESB
Mediations
Mediations
SOA Core
Service
Component
Architecture (SCA)
Business
Objects
Common Event
Infrastructure
WebSphere
WebSphere Application
Application Server
Server
Network
Network Deployment
Deployment
共通イベント・インフラストラクチャー（CEI）は、WebSphere ESB（WESB）で提供される重要な機能
のひとつです。WESBで稼動するサービスやコンポーネントは全て、CEIを使用できます。このセッ
ションでは、CEIをご紹介いたします。
5
CEIの目的
今まで各ノードでアプリケーション・ログに出力していた情報を、「イベ
ント」と定義して取り扱い、一元管理する
サービス・ log
プロバイダー１
サービス・ log
リクエスター１
サービス・ log
リクエスター２
サービス・
log
リクエスターN
サービス・
リクエスター１
WESB
log
log
WESB
サービス・
log
プロバイダーN
サービス・
プロバイダー１
サービス・
プロバイダー２
サービス・
リクエスター２
サービス・
リクエスターN
サービス・ log
プロバイダー２
log
log loglog
アプリログのフォーマット
が全て違う！
どこでエラーが発生してい
るか？
どこがボトルネックとなっ
ているか？
どのサービスが何回よばれ
たか？
どのフローを改善すべき
か？
サービス・
プロバイダーN
今までログとして各ノー
ドに出力していた情報を、
「イベント」として一括
管理！
WESBは、サービス・リクエスターとサービス・プロバイダーを仲介して、容易に連携して
くれる製品です。WESB上で稼動するSCAコンポーネントに対するエクスポート/イン
ポートも汎用的であるため、様々な種類のサービス・リクエスターとサービス・プロバイ
ダーを連携することができます。
サービスの利用者となるエンドユーザは、サービスが呼ばれている場所やサービスの種
類など全く意識する必要がありません。しかし、運用管理者から見た場合はどうでしょう
か。
例えば、エンドユーザに対してエラーが返っているとします。WESBを跨って連携するコ
ンポーネントは、それぞれの存在するノード上にファイルでログを出力します。運用管理
者は分散されたログファイルを集めて、各ログファイルを照らし合わせ、どこでエラーが
起きているかを判断する必要があります。ログファイルがサービス毎に異なったフォー
マットで出力されていれば、ログファイルを読む知識も必要です。
またはログファイルを収集、解析する仕組みを作りこむ場合も、汎用性やワークロードを
考慮する必要があります。
CEIは、ログフォーマットを統一して情報を一元管理することで、これらの問題点を解消
するだけでなく、アプリケーションログから出力される情報を、より有効活用していくことを
目的としています。
6
CEIのメリット
‰
CBE（後述）でログフォーマットを統一し、ログ管理や問題判別の効率が
向上する
€
‰
個々のログファイルに分散して出力していたイベント（ログ情報）を、CEI
で一元管理できる
€
‰
個々のログ解析ツールやログファイルに対する知識が必要なくなる
WESB上のあらゆるコンポーネントから発生するログ、イベントを収集すること
ができる
CEIで一元管理されたイベントは、DBに永続化され、情報を関連付けて
把握することができる
€
アプリケーションログを収集管理するインフラが提供されるため、各プロジェ
クトごとに作りこむ必要が無くなる
‰
イベント・ソースやイベント・コンシューマーを作成するためのAPIが用意
されているため、ユーザアプリケーションに組み込むことが可能となる
‰
DBに格納されたイベントを簡単に閲覧できるツールが用意されている
CEIの利点は上記のようにまとめられます。
ログファイルに共通フォーマットがなければ、各ログファイルに対する知識が必要であっ
たり、個々のログ解析ツールの知識が必要になるので、運用管理者にはそれだけの
ワークロードがかかります。ログフォーマットをCBEという形式に統一することで、そのよう
な負荷が軽減されるでしょう。
また、現在ログファイルはそれぞれのノードにファイル形式で出力されています。今まで
はログファイルを収集して保管する仕組みを作る必要がありましたが、CEIではログ情報
をイベントという形で一括管理し、イベントの収集/保管/利用の仕組みを提供します。
CEIで一括管理されたイベントは全てCBE形式で保管されているため、用途に応じて、
関連付けたりカスタマイズして分析に役立てることが容易になります。
イベントを出力する方法（イベント・ソース）や、イベントを取得して活用する方法（イベン
ト・コンシューマ）もAPIが用意されているので、自由に作りこむことができます。
また、一括管理されたイベントを簡単にモニターできるツール（CBEブラウザー）も用意
されています。
7
CEIの概要
WESB
イベント・ソース
イベント・サーバー
ユーザ
アプリケーション
CEIサーバーの設定により、
データストアへイベント
イベント・
を書き込んだり、PTPまた
コンシューマー
はPub/Subでイベントを
配布することも可能
ユーザ
アプリケーション
エミッター
（同期）
EJB
キュー
または
CEIサーバー
エミッター
（非同期）
MDB
モニタリング
ツール
トピック
キュー
ユーザアプリはエ
ミッターに対して
イベントを送信
CBEのExtended Data
（ユーザ独自のイベント
情報）はイベントカタロ
グに定義しておき、あと
から参照も可能
エミッターは同期または非
同期でCEIサーバーへイベン
トを送信（イベントのフィ
ルタリングも可能）
イベント
カタログ
イベント
定義
ユーザアプリまたはモニタ
リングツールを用い、CEI
サーバーから配布されたイ
ベントを受信したり、後か
らイベントを検索したりす
ることが可能
イベント
データベース
イベント
イベント（CBE）の動き
イベントの検索
上図は、CEIの概要を示しています。
イベント・ソースは、イベントを生成し、エミッターを経由してイベント・サーバーへイベント
を送信します。イベントの送信方法には、直接的にEJBコールして送信する方法（同期）
と、間接的にJMSを通して送信する方法（非同期）を選択できます。
イベント・サーバーは、イベント・ソースから送信されるイベントを収集して一元管理しま
す。イベント・サーバーは、イベントをデータベースに保管したり、イベントをモニタリング
しているアプリケーション（イベント・コンシューマー）へ、イベントを配布します。データ
ベースへの保管や、イベント・コンシューマーへのイベント配布は、設定で容易に選択
できます。
また、送信されたイベントをフィルタリングすることで、イベントのトラフィックを軽減させる
こともできます。
イベント・コンシューマーは、イベント・サーバーやイベント・データベースで管理されて
いるイベントを取得し利用するコンポーネントであり、問題判別やパフォーマンス情報の
把握などに役立てることができます。
イベント・データベースは、イベントを保管するデータベースです。
イベント・カタログは、イベント定義をデータベースに保管する機能です。
8
CEI（共通イベント・インフラストラクチャー）とは
‰
共通イベント・インフラストラクチャー
€
€
‰
CEI：Common Event Infrastructure
アプリケーションに対してイベント管理サービス（イベントの生成/永続化/配布/検索な
ど）を提供し、複数の分散された異なるイベントを連携させる技術
CEIの基本コンポーネント
€
イベント・ソース
„
„
„
€
エミッター
„
„
€
イベントの伝達の詳細を扱うコンポーネント
イベントサーバーのロケーション、イベントのフィルタリング、伝達のメカニズム（同期or非同期）を設定
イベント・サーバー
„
„
€
イベントを生成するアプリケーション
監視対象のリソースに関するイベントを生成するアダプターやモニター
他のソースからイベントを転送するアプリケーション
イベントを管理するサーバー
イベントの配布、イベント・データストアへのアクセスを実装
イベント・コンシューマー
„
„
イベント・サーバーからイベントを受け取るアプリケーション
非同期にイベント通知の受信や、イベント・データストアから過去のイベントデータの検索を行う
€
イベント・データベース
€
イベント・カタログ
„
„
イベントを格納するリポジトリー
イベントのメタデータ（CBEのExtended Dataの定義）を格納するリポジトリー
前述のとおり、CEIは、アプリケーションが従来ファイルに出力していたログ情報をイベン
トという形で一元管理するための新しい仕組みです。
アプリケーションから出力されるイベントを管理するための、イベント生成方法、永続化
や配布などの仕組みを提供しています。
従来ログに出力していたアプリケーションに関連する情報などがイベントとして管理され
ます。
CEIを構成するコンポーネントには、上記のようなものがあります。
9
CEIの前提
10
コモン・ベース・イベント（CBE）
‰
Common Base Event（CBE）
¾
¾
¾
‰
異なるソフトウェアやアプリケーションに対して、統一されたログ・フォーマット
（XML形式）を提供
CISCOとIBM中心に仕様を定め、OASIS（標準化団体）へ提出（2003年）
CEIで扱われるイベントは、CBEで表される
3-tuple（CBEのフォーマットに必要な3要素）
¾
¾
¾
起動/停止/接続…などの「状況」を、製品やプラットフォーム
Situation
やアプリケーションの区別なく共通のフォーマットで表現する
「状況」
Reporting component （Observing component）
Situationを報告するコンポーネント
Affected component （Experiencing / Impacted component ）
Situationに影響されるコンポーネント
影響範囲が分かる
‰
Extended Data（拡張データ・エレメント）
¾
CBEの3-tuple に当てはまらないユーザデータは、Extended Dataに格納すること
が可能
¾
¾
¾
3-tupleのひとつであるメッセージ（msg）に格納できるデータは、1024文字という制限がある
ユーザアプリケーションの要件によっては、3-tupleにどうしてもあてはまらない場合がある
Extended Dataに、ユーザが独自のログ情報の属性が定義可能
CEIで取り扱うイベントは、イベントの構造を定義する標準のXML ベース形式である、コ
モン・ベース・イベント（CBE）を使用して表現されます。
今日の複雑なシステムでは、様々なOS/ミドルウェア/ユーザ・アプリケーションなどから
多くのログが出力されますが、それらは全て独自のフォーマットで記述されています。こ
れらのログを共通フォーマットで表示し、管理/解析/問題解決を容易に実施できるという
目的で定められた仕様がCBEです。
CBEは3-tupleと呼ばれる三つの要素を定めています。ただし、3-tupleに当てはまらな
いデータのための領域としてExtended Data（拡張データ･エレメント）を用意しています。
実際にCBEでログ設計を行う場合には、このExtended Dataの設計が重要となるでしょ
う。
11
CBEの出力例
<CommonBaseEvent creationTime="2005-06-08T05:25:08.660Z" globalInstanceId="F3A7B8FB7B42173DADDB1260D7DD11D9"
sequenceNumber="0" severity="10" version="1.0.1">
<extendedDataElements name="level" type="noValue">
<children name="name" type="string">
<values>INFO</values>
</children>
<children name="value" type="int">
<values>800</values>
</children>
Extended Data
</extendedDataElements>
<extendedDataElements name="sequenceNumber" type="long">
<values>396</values>
</extendedDataElements>
<extendedDataElements name="threadID" type="int">
<values>67</values>
</extendedDataElements>
<extendedDataElements name="loggerName" type="string">
<values>test.EventGenServlet</values>
</extendedDataElements>
<sourceComponentId application="Test" component="EventGenClass" componentIdType="Application" executionEnvironment="Java"
location="9.170.233.104" locationType="IPV4" subComponent="doPost" threadId="WebContainer : 3" componentType="Web_Application"/>
<msgDataElement msgLocale="ja-JP">
<msgCatalogTokens value="TestClass"/>
Reporting Component
Situation
<msgId>ABCD0001A</msgId>
<msgIdType>IBM4.4.1</msgIdType>
<msgCatalogId>CLASS_STARTED_SUCCESSFULLY_MSG</msgCatalogId>
<msgCatalogType>Java</msgCatalogType>
<msgCatalog>TestClassCatalog</msgCatalog>
</msgDataElement>
<situation categoryName="StartSituation">
<situationType xsi:type="StartSituation" reasoningScope="INTERNAL" successDisposition="SUCCESSFUL"
situationQualifier="START COMPLETED"/>
</situation>
</CommonBaseEvent>
CBEの出力例です。
最初に、creationTime（イベント発生時刻）、globalInstanceId（一意のID）、version
（CBEのバージョン）などが定義されています。
次に、Extended Dataはユーザ独自のフォーマットで表された領域です。
sourceComponentIdは、Reporting Component（このイベントを発生させたコンポーネ
ント）を表しています。
msgDataElementは、どのようにこのイベントのメッセージテキストが作成されて解釈さ
れたかを表すエリアであり、Localeなどが指定されています。
最後に、Situationです。「開始した」という状況「Situation」でも “Component ‘x’
started” や “Change server state from starting to running” などアプリ毎に異なるメッ
セージで表記されると解析し難くなってしまいますが、CBEでは「StartSituation」という
統一された表記にまとめることができます。
12
イベント・ソースの開発
13
イベント・ソースの開発
‰
イベント・ソース
€
‰
イベントを出力するアプリケーション
イベント・ソースの開発方法
€
SCAモジュール（メディエーション・モジュール）のイベント出力
„
€
WEDのツールを使用
ユーザ・アプリケーションからのイベント出力
„
コーディング
イベント・サーバー
イベント・ソース
SCA
モジュール
イベント
バスMDB
同期
CBE
エミッター
CBE
CBE
その他の
アプリケーション
非同期
イベント
バスSLSB
CBE
エミッター
CBE
データ
ストアBean
CBE
イベント
データベース
まず、アプリケーションからイベントを出力する方法について解説します。
イベントを出力するアプリケーションをイベント・ソースと呼びます。
イベント・ソースの開発には主に2種類あります。
①SCAモジュールの場合は、イベントを出力させるためのツールが、WIDで用意されて
います。
②その他の通常のユーザ・アプリケーションからは、APIを使用して自由にコーディング
できます。
14
SCAモジュールのイベント出力
‰
WID上でSCAを開発する場合は、イベントを出力させるツールが用意さ
れているので、チェックを入れるだけでイベント出力の指定が可能
イベント出力を使用可能にす
るとイベント・モニター・シ
ンボルが付与される
イベント・モニター・
ビューでイベント出力を
設定する
SCAモジュールをWIDで開発する場合は、イベントの出力の有無をチェックするだけで
指定できる「イベント・モニター」というツールが用意されています。
上記は、WIDのイベント・モニターの例です。
詳細は下記リンクをご参照下さい。
・WebSphere Integration Developer におけるイベント・モニターの使用可能化
http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/topic/com.ibm.wbit.hel
p.cei.ui.doc/topics/tstrtmon.html
15
SCAモジュールのイベント出力
‰
イベント・モニター
€
€
WIDで提供されているイベントを生成/モニターするためのツール
アセンブリーエディターの「プロパティー」ビューから、開くことが可能
„
„
‰
イベント出力指定が可能なコンポーネント
€
SCAのインターフェース操作（インターフェースの要求応答操作（オペレー
ション））
€
メディエーション・フローのインターフェース操作も可
„
„
„
‰
エントリー/エグジット/失敗のイベントを出力可能
イベント・モニターは、メディエーションフロー・エディターから開くことができないため、アセン
ブリー・エディターから開く
カスタム・メディエーションでコーディングすることも可能（後述）
イベント・モニターを使用可能にすると
€
€
アセンブリー・エディターにイベント・モニター・シンボル
.monファイルが生成される
„
‰
アセンブリー・エディターで対象となるコンポーネントを選択
「プロパティー」ビュー → 「詳細」 → 「イベント・モニター」
が付く
.monファイルは、アプリケーションのデプロイ後は変更できないため、WIDでイベント・モニ
ターに関する変更があった場合は、再デプロイが必要
WIDのWESBテスト環境でもCBEブラウザー（後述）が使用可能
上記のように、イベント・モニターは、アセンブリー・エディターから開くことができます。
WESBで稼動するSCAモジュールを開発する場合は、このアセンブリー・エディターを
使用します。
その他、以下のエディターから、イベントモニターを開くことは可能です。以下のエディ
ターはWPSに関連するエディターです。
ビジネス・プロセス・エディター
ビジネス状態マシン・エディター
ビジネス・オブジェクト・マッピング・エディター
ビジネス・ルール・グループ・エディター
インターフェース・マッピング・エディター
人的タスク・エディター
セレクター・エディター
16
ユーザ・アプリケーションからのイベント出力
‰
イベントの出力をユーザーコーディングすることが可能
① CBEのイベントを生成
„
„
Common Base Event API（Hyades APIとも呼ばれる）を使用
Common Base Event APIはWASに同梱されている
② エミッターにイベントを送信
„
„
エミッターのAPIを使用するためにはevents-client.jarをパスが通るエリアに配置する
events-client.jarはWESBで提供されている
z
„
<WESBインストールルート>¥CEI¥clientディレクトリに格納
イベント・ソース開発者は、イベント・サーバーの場所やエミッターの設定を気にする必要が
無い
ユーザー・アプリケーション（イベント・ソース）
ユーザー定義のロガークラス
メソッド定義
ビジネスロジック
クラス
メソッド
使用
ロガー使用方法は
変更なし！
メソッド
使用
CBE APIを使用し
CBEにフォーマット
CBE
API
Emitter
API
イベントを
イベント
サーバーへ
送信
エミッターのAPIを使用して
イベントを送信
（events-client.jarが必要）
SCAモジュール以外のユーザ・アプリケーションの部分では、コーディングでアプリケー
ションからイベントを出力することができます。
最初に、CBE APIを使用してCBEのイベントオブジェクトを生成します。CBEのライブラ
リーはWASに同梱されています。
次に、エミッター用APIを使用してエミッターオブジェクトを取得し、CBEオブジェクトを送
信します。エミッター用のAPIはWESBで提供されています。
上図のように、通常、ユーザ・アプリケーションではロガークラスを用意して、ビジネスロ
ジッククラスはロガーで提供されたメソッドを使用することでログを出力します。エミッター
経由でイベントを出力する場合も、ロガークラスの実装だけをCBEとエミッターのAPIを
使用するように変更すれば、ビジネスロジッククラスからの使用方法に影響を与えません。
17
ユーザ・アプリケーションからのイベント出力
①CBEのイベントを生成 -1‰
CBEのAPIを使用してイベントを生成するサンプル
･･･省略
CBE APIのパッケージ
import org.eclipse.hyades.logging.events.cbe.*;
･･･省略
EventFactory eventFactory = (EventFactory) EventFactoryFactory.createEventFactory();
CommonBaseEvent event = eventFactory.createCommonBaseEvent();
try {
event.setVersion(“1.0.1”); // CBEのバージョン
event.setExtensionName("CEI Test User Application (Event Source)");
event.setPriority(new Integer(priority).shortValue());
event.setMsg(msg);
event.setCreationTimeAsLong(System.currentTimeMillis()); // creationTimeの設定
CBEオブジェクトの
生成
CBEオブジェクトの
属性の設定
//sourceComponentId の設定
event.setSourceComponentId( "CEI Test Application", // application
"WESB V6", // component
"EventGenerator Class", // subcomponent
"http://www.ibm.com/namespaces/autonomic/WebSphereApplicationServer", // componentType
ComponentIdentification.COMPONENT_ID_TYPE_PRODUCT_NAME, // componentIdType
InetAddress.getLocalHost().toString(), // location
ComponentIdentification.LOCATION_TYPE_HOSTNAME // locationType
);
//situationオブジェクトの生成
Situation situation = eventFactory.createSituation();
//situationType の設定
situation.setAvailableSituation(
"EXTERNAL", // reasoningScope
"NOT AVAILABLE", // availabilityDisposition
"STARTABLE", // operationDisposition
"FUNCTION_PROCESS"); // processingDisposition
//situationの設定
event.setSituation(situation);
CBEオブジェクトを生成するサンプルです。上記の例は、CBEの3-tupleを設定していま
す。
18
ユーザ・アプリケーションからのイベント出力
①CBEのイベントを生成 -2‰
CBEのAPIを使用してイベントを生成するサンプルの続き
// ExtendedDataElement
ExtendedDataElement data1 = eventFactory.createExtendedDataElement();
data1.setName("MyRegularExtendedDataElement");
data1.setType(ExtendedDataElement.TYPE_STRING);
data1.setValuesAsString("ExtendedDataValue");
event.addExtendedDataElement(data1);
// ExtendedDataElement
ExtendedDataElement data2 = eventFactory.createExtendedDataElement();
data2.setName("MyEmbeddedExtendedDataElement");
data2.setType(ExtendedDataElement.TYPE_NO_VALUE);
data2.addChild("ChildElement", "ChildValue");
event.addExtendedDataElement(data2);
event.complete();
Extended Dataの
属性の設定
} catch (UnknownHostException e) {
e.printStackTrace();
} catch (CompletionException e) {
e.printStackTrace();
}
･･･省略
CBEオブジェクトを生成するサンプルの続きです。上記は、Extended Dataを設定して
います。
19
ユーザ・アプリケーションからのイベント出力
②エミッターにイベントを送信
‰
‰
エミッターにイベントを送信するサンプル
エミッターをLookupしてイベントを送信するのみ
€
€
イベント・ソースの開発者が、イベント・サーバーの場所、フィルターの設定、イベン
トの伝送メカニズム（同期/非同期）などのエミッターの設定を気にする必要はない
エミッターの設定をオーバーライドするAPIが用意されているため、ソースの中でエ
ミッターの設定を指定することも可能
import com.ibm.events.EventsException;
import com.ibm.events.emitter.*;
try {
context = new InitialContext();
エミッターのライブラリー
エミッターの名前を指定し
てJNDI検索
EmitterFactory emitterFactory = (EmitterFactory) context.lookup("com/ibm/events/configuration/emitter/Default");
Emitter emitter = emitterFactory.getEmitter(); //エミッターの取得
//エミッターの設定を非同期モードにオーバーライド
emitter.setSynchronizationMode(SynchronizationMode.ASYNCHRONOUS);
emitter.sendEvent(event); //イベントを送信
emitter.close();
} catch (NamingException e) {
e.printStackTrace();
} catch (EventsException e) {
e.printStackTrace();
}
エミッターを取得し、イベントを送信
sendEvents()で、複数のイベントを一
括で送信し、パフォーマンス向上を図
ることも可能
エミッターオブジェクトを取得して、前頁で生成したCBEオブジェクトを送信する例です。
エミッターでイベントを送信する場合、イベント・サーバーの場所、フィルターの設定、イ
ベントの送信方法（同期/非同期など）は気にする必要はありません。
エミッターの設定は、基本的にイベント・サーバーで管理しています。ただし、デフォルト
のエミッターの設定をオーバーライドしたい場合は、APIが用意されているので可能で
す。
また、イベント・サーバーの場所も基本的に気にする必要はありません。ただし、CEI
サーバのホスト名とポート番号を明示的に指定することも可能です。稼働環境がWESB
でセルに統合されていれば、別ノードでも明示的に指定する必要はありません。
http://www-1.ibm.com/support/docview.wss?uid=swg21218608
20
イベント・サーバの構築
21
CEI構成の全体像
イベントの流れ
リクエストの流れ
イベント検索・取得の流れ
セル
デプロイメント
・マネージャー
CBE
ブラウザー
ノード１
WESBサーバー
イベント
サーバー
イベント
データベース
ノード２
アプリケーション・サーバー３
J2EE
アプリケーション
（イベント・コンシューマ）
ノード３
ME
バス（CommonEventInfrastructure_Bus ）
アプリケーション・サーバー１
WESBサーバー
アプリケーション・サーバー２
メディエーション・モジュール
エミッター
J2EE
アプリケーション
（サービス・リクエスター）
ノード４
エミッター
ノード５
エミッター J2EE
アプリケーション
（サービス・プロバイダー）
ノード６
WESBのセルを構築した場合、SCAモジュールとCEIを含めた全体図です。
上記のスライドの下段（ノード４～ノード６）で、サービス・リクエスター、メディエーション・
モジュール、サービス・プロバイダーが稼動しています。これらは全てイベント・ソースと
して、アプリケーション稼動時の重要なイベントをエミッター経由で送信します。
WESBのセルを構成すると、デフォルトでCEI専用のバスが構成され、エミッターが非同
期の場合は、このバスを経由してイベント・サーバーへイベントが集まります。
収集されたイベントは、イベントデータベースに永続化され、CBEブラウザーや、ユーザ
が作成したイベント・コンシューマーで検索することができます。
22
CEIの構築手順
‰
CEIを構成するためのツールが用意されている
① イベント・データストアを構築する場合はDBサーバを用意する
シングルサーバー構成の場合
（スタンドアロンプロファイル作成時）
② スタンドアロンプロファイルを
作成
プロファイル作成時に、CEIとイベ
ントデータベース関連の情報を指
定する
Network Deployment環境の場合
（DMプロファイル/カスタムプロファイル作成時）
② 各プロファイルを作成
③ イベントサーバー用アプリケーション
サーバー/クラスターを作成
④ イベントデータベースの構成用ツール
を実行
⑤ CEIアプリケーションの導入とリソース
の設定用ツールを実行
CEIのデフォルト構成が完了
上記は、CEIを構築するための手順を示したスライドです。
スタンドアロン・プロファイルを作成する場合、プロファイル作成ウィザードで、CEIやイベ
ント・データベースに関する情報の入力が求められます。そして、プロファイル作成時に、
自動的にCEIのデフォルト構成が完了します。
Network Deployment環境の場合は、イベントサーバー/クラスター作成後に、CEI構成
用ツールを実行することで、同様のCEI構成を構築することができます。
イベント・データベースとしてサポートしているDB（2006/03現在）
・CloudscapeV5.1.1
・DB2 Universal V8.1 / V8.2.1（Win/Linux/Unix）
・DB2 Universal OS/390 V7.1/ V8.1
・Oracle V9.1 / V10.1
23
管理コンソールからみるCEIの構成 -1Common Event Infrastructureサービス
CEI使用の有無を指定する
使用不可にするとイベン
ト・サーバーはイベントを
処理せず、イベント・デー
ターベースへの書き込みな
ども実行されない
Common Event Infrastructureエンタープライズ・アプリケーション（EventServer）
Common Event Infrastructureメッセージング・アプリケーション（EventServerMdb）
■EventServer
イベント・サーバー用のエンタープ
ライズ・アプリケーション
■EventServerMdb
イベント・サーバーへ非同期でイベ
ント送信するための、MDBのエン
タープライズ・アプリケーション
デフォルト構成は、以下のオブジェクトで構成されています。
・共通イベント・インフラストラクチャー・サービス
WebSphere サーバーにインストールされるサービス。このサービスにより、WebSphere
アプリケーションおよびクライアントで共通イベント・インフラストラクチャーが使用可能に
なります。
・共通イベント・インフラストラクチャー・エンタープライズ・アプリケーション
イベント・サーバー用のエンタープライズ・アプリケーション。エンタープライズ・アプリ
ケーションのデプロイメント記述子により、イベント・サーバーが、使用する共通イベント・
インフラストラクチャー・リソースに関連付けされます。
・共通イベント・インフラストラクチャー・メッセージング・アプリケーション
イベント・サーバーへの非同期イベント送信をサポートする、メッセージ駆動型Bean 用
のエンタープライズ・アプリケーション。このアプリケーションは、イベント・メッセージング
を構成した場合にのみ使用可能です。
24
管理コンソールからみるCEIの構成 -2Common Event Infrastructureプロバイダー
■イベント・グループ・プロファイル・リスト
イベントをグループ分けして、イベントの検索や
配布時に役立てることが可能
■フィルター・ファクトリー・プロファイル
イベントをフィルタリングすることで、重要なイベ
ントのみを選別してトラフィックを軽減させること
が可能
CEIの各コンポーネントから
使用されるJNDI名を定義
・共通イベント・インフラストラクチャー・プロバイダー
共通イベント・インフラストラクチャーのコンポーネント、イベント・ソース、およびイベント・
コンシューマーにより使用されるリソースが含まれるコレクション・オブジェクト。
追加プロパティーから、イベント・グループの指定や、フィルタリングの指定が可能です。
25
イベントのフィルタリング
‰
イベントをフィルタリングすることで、重要な
イベントのみを選別してトラフィックを軽減さ
せることが可能
€
€
€
②エミッター・ファクトリー・プロファイルに関連付け
イベントがイベント・ソースからエミッターに送
信されるたびに、エミッターは現行のフィル
ター基準に照らし合わせてイベントを検査
イベントがフィルター基準にパスした場合、エ
ミッターはイベント・サーバーにイベントを送
信
イベントがフィルター基準にパスしない場合、
エミッターによりそのイベントが廃棄される
①フィルター・ファクトリー・プロファイルでフィルター基準を作成
①で指定したフィルター・ファ
クトリー・プロファイルのJNDI
名を指定し、「フィルター処理
使用可能」にチェック
フィルターの構成をXPathで定義
Priorityが10のイベントを指定した例
イベントを収集するトラフィックを軽減させるため、必要なイベントのみを選別してイベン
ト・サーバーへ送信したい場合は、フィルターの設定を管理コンソールから指定すること
ができます。
Common Event Infrastructureプロバイダーのフィルター・ファクトリー・プロファイルで
フィルター基準を作成します。このとき、フィルタリングの基準を指定する際には、XPath
を使用します。
具体例は、下記リンクを参照下さい。
http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/topic/com.ibm.websph
ere.wesb.doc/doc/ccei_adminCBEB_eventselector.html
その後、エミッター・ファクトリー・プロファイルで、作成済みのフィルター・ファクトリー・プ
ロファイルのJNDI名を関連づけます。
26
（参考）CEIに関係するWASの設定箇所
参照
イベント・
ソース
Lookup!
エミッター
イベント
データベース
イベント・サーバー
イベント・サーバー用アプリ
EventServerMdb
アプリケーション
eventデータソース
Event_DB2_
JDBC_Provider
EventServer
アプリケーション
event_catalogデータソース
JDBCプロバイダー
リスナー
バインディング
同期
エミッターファクトリー
プロファイル
非同期
同期/非同期や
フィルタリン
グの指定
キュー接続ファクトリー
CEI_QueueCF
イベントバス伝送
プロファイル
JMS伝送
プロファイル
イベントサーバー
プロファイル
CommonEventInfrastructureプロバイダー
キュー宛先
CEI_Queue
トピック宛先
CEI_AllEventsTopic
JMS活動化仕様
CEI_ActivationSpecs
データストア
プロファイル
イベントDBの
DataSourceを
指定
トピック接続
ファクトリー
CEI_AllEvents
TopicCF
JMSプロバイダー
ME
CEIQueueDestination
CEITopicDestination
バス（CommonEventInfrastructure_Bus ）
上図はCEIに関するWASの設定項目を示しています。CEIの設定を変更/追加する際などに活用下さい。
CEIのコンポーネントとしては、上記のほかに、
イベント・グループ・プロファイル・リスト（イベント・グループの指定）
フィルター・ファクトリー・プロファイル（フィルタリングの指定）
があります。
・データ・ストア・プロファイル
データ・ストア・プロファイルは、デフォルト・データ・ストア・プラグインにより使用されるプロパティーを定義
します。データ・ストア・プラグインは、イベント・サーバーにより受信されたイベントの永続的な保管に使用
されます。
・イベント・バス送信プロファイル
イベント・バス送信プロファイルでは、EJB 呼び出しを使用して、イベント・サーバーに同期してアクセスす
るエミッターにより使用されるプロパティーを定義します。このプロファイルはエミッター・ファクトリー・プロ
ファイルにより使用されます。
・エミッター・ファクトリー・プロファイル
エミッター・ファクトリー・プロファイルでは、エミッターにより使用されるプロパティーを指定します。エミッ
ター・ファクトリー・プロファイル内のプロパティーは、関連するエミッター・ファクトリーを使用して作成され
るすべてのエミッターの振る舞いに影響します。異なる振る舞いのエミッターが必要な場合は、追加のエ
ミッター・ファクトリー・プロファイルを作成することができます。
・イベント・サーバー・プロファイル
イベント・サーバーにより使用されるプロパティーを定義するプロファイル。デフォルトのイベント・サー
バー・プロファイルでは、イベントの配布およびパーシスタンス(永続性) が使用可能に設定され、デフォル
トのデータ・ストア・プラグインを使用するよう構成されます。
・JMS送信プロファイル
JMS 送信プロファイルでは、JMS キューを使用してイベント・サーバーに非同期にアクセスするエミッター
により使用されるプロパティーを定義します。このプロファイルは、エミッター・ファクトリー・プロファイルによ
り参照されます。
27
イベント・カタログ
‰
‰
CBEの3-tupleに当てはまらない情報は、Extended Dataに書かなければいけな
い
Extended Dataに何を定義したか（どういう名前のタグで何が書かれているのか）
という情報が分からないと、ログ分析時に困る
€
‰
システムを統合したときに、統合先のアプリが何を定義しているのかを知る必要があ
る
イベント・カタログは、イベントのフォーマットをDBに格納する機能
€
€
Extended Dataの定義（メタデータ）をデータ・カタログに定義することが可能なため、各
アプリケーションのExtended Dataの定義情報を一元管理できる
カタログに定義した情報にアクセスするAPIやコマンドが提供される
変更通知
イベント・サーバー
イベント
カタログBean
イベント定義の
追加/除去/置換
イベント定義の
追加/除去/置換
JMS
API
Event Catalog
インタフェース
変更通知
イベント
カタログ
J2EEアプリケーション
イベント定義の
インポート/
エクスポート
CLI
eventcatalog.jacl
イベント・カタログは、イベントの定義を管理するためのリポジトリーです。例えば、
Extended DataにUserIDというタグを指定しても、アプリAとアプリBでは意図や用途が
異なります。このように、何を定義しているか、という定義情報をカタログで管理すること
ができます。管理するアプリケーションや、Extended Dataの項目が多いほど、カタログ
はより重要な機能となることが考えられます。
イベント・カタログを使用して、そのアプリケーションの固有のイベント定義を管理するこ
とができます。
イベント・カタログのためのAPIが用意されているため、ユーザー・コーディングでイベン
トを定義したり、追加/除去/置換したりすることができます。
イベント・カタログでイベントが追加/除去/置換などがされた場合、通知イベントが発生し
ますので、必要な場合はそのイベントを取得することもできます。
28
管理コマンド
‰
CEIの管理のためのコマンドが提供されている
€
€
<WESBインストールディレクトリ>¥profiles¥<プロファイル名>¥event¥bin
ディレクトリに配置
Jaclスクリプトで提供されるため、wsadminツールを使用して実行
„
„
wsadmin –f XXXXXX.jacl <option>
wsadmin –f XXXXXX.jacl help
ヘルプの表示
スクリプト
内容
eventpurge.jacl
イベント・データベースからイベントを消去
eventbucket.jacl
イベント・データベース・バケット（高速にイベントを消去するた
めの仕組み）構成の表示/変更
eventcatalog.jacl
イベント・カタログ内のイベント定義のリスト/インポート/エクス
ポート
emitevent.jacl
イベント・サーバにイベントを送信
XMLファイルまたはコマンドラインのオプションでイベントの内
容を指定
eventquery.jacl
イベント・データベース内のイベントをリスト
イベントを取り扱うための管理コマンドも提供されています。
イベントの送信、取得や、消去がコマンドからも実行できます。
29
イベント・コンシューマの利用と開発
30
CBEブラウザー
‰
‰
イベント・データベースに格納されたイベントを閲覧することが可能
管理コンソールと同様の位置づけ
CBEブラウザーのアドレス
http://<ホスト名>:<ポート番号>/ibm/console/cbebrowser/
Network Deployment環境の場合は完全修飾名で指定
例）cell/nodes/<CEIのノード名>/servers/<CEIのサーバー>
/ejb/com/ibm/events/access/EventAccess
検索の条件を指定して（オプ
ション）、イベントデータベース
からイベントを取得
WESBを構築すると自動的にCBEブラウザーが導入されています。CBEブラウザーは、
管理コンソールと同様に管理用アプリケーションとして、デプロイメント・マネージャーに
インストールされています。シングル・サーバー構成の場合は、サーバー自体にインス
トールされています。
CBEブラウザーは、イベント・データベースに格納されたイベントを検索することができま
す。従ってイベント・コンシューマーの一種と言えるでしょう。
Network Deployment環境の場合は、「イベント・データ・ストア」の欄の指定に注意が必
要です。
http://www-1.ibm.com/support/docview.wss?uid=swg21218710
31
CBEブラウザーの出力例
ユーザ・アプリケーションからのイベントの例
（コーディングして自由に出力することが可能）
SCAモジュール（メディエーションモジュール）から
出力されたイベントの例
（WIDで容易に設定することが可能）
イベントの詳細なデータを
表示
イベントを取得して、閲覧した場合の例です。
WESB上で、複数のSCAモジュールやWebサービスリクエスター/プロバイダーが存在
し、複数のノードで稼動している構成の場合、どのサービスが呼ばれたか？どこでエ
ラーが起きているか？といった状況の把握は非常に難しいものです。
しかし、CBEイベントブラウザーを使用すれば、ユーザリクエストの流れや、リクエスト量
なども簡単に把握することができます。
32
CBEブラウザー（WIDのWESBテスト環境）
‰
WIDのWESBテスト環境でも、CEIのテストとCBEブラウザーを使用
することが可能
06年04月現在、このメニューは使用できないが、ブラウザーから
http://<ホスト名>:<ポート番号>/ibm/console/cbebrowser/
を指定すれば、CBEブラウザーの使用が可能
WIDでWESBテスト環境を使用する場合も、CEIやCBEブラウザーを使用することがで
きますが、ひとつ注意点があります。
右クリックでCBEイベントブラウザーを起動するメニューが表示されますが、これは現在
のところ稼動していません。しかし、ブラウザーからCBEブラウザーのアドレスを指定す
れば、問題なく使用できます。
33
イベント・コンシューマの開発
‰
イベント・コンシューマ
€
‰
イベント・サーバーからイベントを受け取るアプリケーション
イベント・コンシューマの種類
€
イベント・サーバーからの非同期イベント通知を受け取る
„
€
JMS APIを使用し、イベント通知をJMSメッセージとして受け取る
イベント・データベースに格納されたイベント・データを照会/処理する
„
Event Accessインタフェース（イベント・サーバー用アプリケーションで提供）を使用し、イベン
ト・データベースを検索する
イベント・サーバー
イベント・
コンシューマ
イベント
配布Bean
JMS
API
イベント
アクセスBean
Event Access
インタフェース
イベント
データベース
データ
ストアBean
イベント・コンシューマーは独自に開発することも可能です。
イベント・サーバーから配布されたイベントをJMS API経由で取得することもできますし、
イベント・データベースのイベントを検索することもできます。
これらのAPIを使用して、アプリケーションの稼動確認をしたり、ビジネス・パフォーマン
スを把握する独自のアプリケーションを開発することも可能です。
34
ユーザ・アプリケーションからのイベント検索
‰
イベント・データベースからイベントを検索するサンプル
import org.eclipse.hyades.logging.events.cbe.CommonBaseEvent;
import com.ibm.events.EventsException;
import com.ibm.events.access.EventAccess;
import com.ibm.events.access.EventAccessHome;
･･･省略
try {
CommonBaseEvent events[]
= null;
CBEとEventAccessのパッ
ケージをインポート
EventAccessビーンはSLSBの
// Event Accessビーンのlookup
ため、EventAccessビーンの
Hashtable jndiConfig = new Hashtable();
インスタンスを生成する
jndiConfig.put(Context.INITIAL_CONTEXT_FACTORY,"com.ibm.websphere.naming.WsnInitialContextFactory");
jndiConfig.put(Context.PROVIDER_URL,providerUrl);
Context initial = new InitialContext(jndiConfig);
Object objref = initial.lookup("ejb/com/ibm/events/access/EventAccess");
EventAccessHome eventAccessHome = (EventAccessHome) PortableRemoteObject.narrow(objref,EventAccessHome.class);
EventAccess eventAccess = eventAccessHome.create();
//イベントの検索
events =eventAccess.queryEventsByEventGroup(eventGroup,eventSelector,true,number);
･･･省略
//取得したイベントからmsg属性を取得
if(printEvents)
{
for(int j = 0; j < events.length; j++){
System.out.println("The Message of event is " + events[j].getMsg());
}
}
}
･･･省略
取得したイベントはCBE API
を使用してイベントの属性
を取得する
上記の例は、イベント・データベースからイベントを検索するサンプルです。
取得したイベントはJavaオブジェクトのため、CBE APIを使用してイベントの属性を検索
してください。
35
まとめ
36
まとめ
‰
複数のコンポーネントから出力される異なるログフォーマットは、コモン・
ベース・イベント（CBE）で共通化できる
‰
CBEは、ログフォーマットを標準化するための仕様である
‰
共通イベント・インフラストラクチャー（CEI）は、CBE形式のイベントを収集
/永続化/配布するための管理機能を提供する仕組みである
‰
WIDでのSCA開発時は、CEIの開発を効率化するためのツール（イベン
ト・モニター）が提供されている
‰
分散するSCAモジュールから発生するイベントを収集し、問題判別やビ
ジネス上の分析に利用することができる
‰
CEIは、WPSやBusiness Monitorのインフラとしても使用される
上記に、CBE/CEIのポイントをまとめました。
CBEでログフォーマットを統一し、フォーマットが統一されたイベントをCEIで一元管理
することで、問題判別やビジネス上の分析にも役立てることができます。
また、CEIはWPSやBusiness Monitorのインフラとしても使用される重要な機能である
といえます。
37