レベル: 初級 Peter Crocker, Senior IT Specialist, IBM
Doina Klinger, Advisory Software Engineer, IBM
Latha Sivakumar, Advisory Software Engineer, IBM
2008年 09月 03日 WebSphere® Business Events は、ビジネス・イベントのパターンを検出、評価し、そのパターンに対応することを可能にする新しい IBM® 製品です。この連載のパート 1では、WebSphere Business Events の主要な概念とツールを紹介します。
概要
この記事は、WebSphere Business Events (以下、「Business Events」と呼びます) を紹介し、WebSphere Enterprise Bus、WebSphere Process Server、WebSphere Message Broker、WebSphere Business Monitor といった WebSphere ファミリーの他の製品と共に利用する方法を説明する連載の第1 回目の記事です。パート 1 では、エンタープライズ・アプリケーションの統合で Business Events がもたらすビジネスの価値と、Business Events のコアとなる概念およびツールについて学びます。パート 2 では、簡単な Business Events のアプリケーションを開発およびテストする方法を段階を追って説明します。その後の記事では、このアプリケーションを他のWebSphere 製品に組み込む方法を説明します。
ビジネス・イベントの処理
ビジネスが行われる環境では、互いに関連するイベントが絶えず変化しています。顧客取引、金利の変更、サプライヤーへの発注、物流トラブル、さらにはハリケーンからストライキに至る予期しない外部の出来事など、あらゆるものがビジネスに影響を与える可能性があります。
多くの場合、ライブ・データの量が膨大であるため、これらのイベントのパターンを特定するのは困難です。この困難さによって、新たなオポチュニティーの見逃し、ニーズ発生時に必要なリソースの割り振りの遅れ、予期せぬ事態への対応能力の不足などが生じます。
ビジネス・イベント処理 (BEP) ソフトウェアを使用すると、企業はタイミングよくイベント・パターンを検出、評価し、さらにそれに対応してビジネス目標を満たすことができます。BEP はビジネス・プロセス・マネージメント (BPM) の世界に、ライブ・イベント・パターンを検出し、それらのパターンに対応するための動的プロセスを提供します。
詳細については、「Business Event Processing from IBM: A Smart SOA Solution（US）」を参照してください。
WebSphere Business Eventsは、以下のような場合に、異種のアプリケーションからのイベントを処理します。
- ロジックのパスが予測不能であり、複数のアプリケーション間でアクティビティーを検出し、時間やシーケンスによって関連付ける必要がある場合 (非線形処理)
- ビジネス・ロジックが頻繁に変わる場合 (動的処理)
- 結果をリアルタイムで監視し、アクティビティーの傾向に自動的に対応することが重要な場合。これによって、閉ループでアクティブな監視が行われます。
Business Events によって、既存の BPM やサービス指向アーキテクチャー (SOA) インフラストラクチャーを拡張することができます。
WebSphere Business Events
Business Events は、使いやすいグラフィカルなオーサリング・ツールを備えています。これらツールを使ってビジネス・ポリシーやビジネス・ロジックを定義して、関心のあるビジネス・イベントやパターンに対応したり、適切なビジネス・アクションを開始したりすることができます。これらのビジネス・ポリシーは普通の言葉で書かれた規則に忠実に従って作成されるため、技術的な知識がないユーザーにも非常に読みやすくなっています。ポリシーには、特定の組み合わせで、あるいは特定のタイミングで発生した/発生しなかったイベントに対して、システムがどのように対応するかが記述されています。ポリシーを使うことで、人、イベント、情報間の単純な、あるいは複雑な関係を検出および分析し、それらに動的に対応することができます。
イベントは多様なシステムやアプリケーションで発生します。これらのシステムやアプリケーションは相互に関連付けられている場合も、そうでない場合もあります。Business Events はこういったあらゆるソースからのパターンの関連付けと特定を行った後、外部システムがコンシュームするアクションを生成したり、新たにイベントを生成して、それを Business Events に送信したりします。
図 1 に示したのは、Business Events が得意とするいくつかのビジネスの状況です。ご覧のとおり、株取引、アカウントの開設、パスワードの変更、アカウント・プロファイルの更新、アカウント・マネージャーの訪問、取引指示を記載した電子メール、顧客による個人情報の変更、多額の引き出しなど、異なるソース間で、異なる時間内に起こる多様なイベントが含まれます。Business Events は種類の異なるソースで発生したこれらの雑多なイベントについて、逐次的でも直線的でもない相関関係やパターンをリアルタイムで発見し、それらが全部どのような意味を持つのかを解明します。
図 1. 概要図: イベントの検出、意思決定、アクションの実施
サンプル・シナリオ
この連載では、サンプル・シナリオを使用して Business Events のしくみを説明します。このシナリオでは、ある株取引システムにおける投機的な行為を検出しなければなりません。すなわち、ある時間内に発生するイベントのパターンを特定し、それに適切に対応することが要求されます。
売買依頼を受け付ける株取引システムを思い浮かべてください。このシステムは、取引時間中における取引データ内の特定のパターンを監視する役割を担っています。私たちに関心があるのは、膨大な数の取引イベント (メッセージ) に含まれる、投機行為を示唆するパターンです。そのような状況を割り出すために 2 つのポリシーを定義します。「売り」イベントと「買い」イベントには、それぞれその顧客、株式、取引の日時、株数、価格を示す属性が設定されています。同じ株式に対する同じ顧客による「買い」イベントが発生した 1 時間以内に「売り」イベントが発生すると、SellAfterBuy アクションが生成されます。ある顧客が、ある株式に対する「買い」後の「売り」を 1 日に 3 回行った場合、SpeculativeCustomer アクションが生成されます。これらのアクションが Business Events の出力です。これらのアクションは他の外部システムで処理されます。これについては、この連載の以降の記事で説明します。
このサンプル・シナリオは金融業界の規制順守ユース・ケースのアプリケーションを単純化したものです。仲買人は投機的な取引を見つけ出す必要があるとともに、状況に応じてそのような事例を報告する義務があります。
Business Events のアーキテクチャー
図 2 に示したのは WebSphere Business Events ランタイム・アーキテクチャーの主要なコンポーネントです。
図 2. Business Events のランタイム・アーキテクチャー
- ランタイム・サーバー(Runtime)は Business Events の核となるコンポーネントです。ビジネス・イベント処理がここで行われます。
- コネクター(Connectors)は、プログラムのコーディングなしで、多様なプロトコルを介してタッチポイントとの接続を提供する内部システム・コンポーネントです。
- リポジトリー(Repository)は Business Events の資産の定義を安全に格納する共用の場所です。
Business Events のツール
Business Events には、異なるユーザー役割に応じて、以下に示す 2 つのコア・ツールが付属しています。
- Design Data ツールは、Business Events と対話する外部ビジネス・システムと、必要なデータ・オブジェクトを定義するのに使用されます。このツールは通常、IT 接続を担当する IT プロフェッショナルが使用します。
- Design ツールはビジネス・イベントのルールの定義に使用されます。このルールには、イベントが Business Events に到着し、あるパターンが特定されたときに何を行うかが記述されます。このツールは通常、ルールを分析し、状況の変化に応じてルールを適宜修正できるビジネス・アナリストが使用します。
この連載のすべての記事を通してこれら 2 つのツールに言及したり、使用したりする予定ですので、ここではその紹介を行います。この連載では取り上げませんが、Business Events ツールには他にも Administration、Dashboards、Design Dashboards、Properties、User Console といったツールが含まれています。パート 2 では、これらのツールの使用方法を詳しく学びます。これらのツールの詳細については、「WebSphere
Business Events V6.1 Information Center（US）」を参照してください。
Design Data ツール
Design Data ツールは、以下の主要なコンポーネントから構成されています。
- タッチポイントは、WebSphere Business Events との間でイベントを送受信する外部システムまたはアプリケーションです。 サンプル・アプリケーションでは TradeSystem というタッチポイントを定義します。実稼働環境の Business Events アプリケーションでは複数のタッチポイントが定義されます。また、多様なソースからイベントが到着し、関連付けとパターンの特定が行われます。サンプル・アプリケーションでは、単純化のために、使用するタッチポイントを 1 つとします。
- イベントは、Business Events 内での何らかの計算をトリガーする、タッチポイント内のアクティビティーです。サンプル・アプリケーションでは、Buy および Sell イベントを定義します。イベントは 1 つ以上のイベント・オブジェクトで構成されます。
- イベント・オブジェクトは定義済みのデータ・フィールドの集合です。Buy および Sell イベントは TradeObject という 1 つのイベント・オブジェクトを共有し、このオブジェクトには CustomerID、StockID、Quantity、Price、Date というフィールドが設定されています。
- アクションは、Business Events で 1 つ以上のルールが成立する場合に、タッチポイントで発生するアクティビティーです。サンプル・アプリケーションで定義されたアクションの例として SellAfterBuy Speculative Customer を挙げることができます。アクションは 1 つ以上のアクション・オブジェクトで構成されます。
- アクション・オブジェクトは、定義済みのデータ・フィールドの集合です。サンプル・アプリケーションでは、TradeOut アクション・オブジェクトがすべてのアクションで共有されます。
- 合成イベントは、インタラクション・ブロックでアクションの代わりに使われる結果イベントです。合成イベントによって、インタラクション・ブロックは他のイベントを直接呼び出すことができます。こうすることで複合イベントをすぐ処理せずに、 1 つの独立したイベントとしてトリガーできるため、複雑なイベントの処理に役立ちます。
- インターミディエイト・オブジェクトは、ビジネス・オブジェクトを概念的に表したもので、通常は異なるアプリケーションやシステム内 (つまり、異なるイベント・オブジェクトやアクション・オブジェクト内) に、さまざまな名前や形式で記述されています。インターミディエイト・オブジェクトは新しいイベントが Business Events に入力されたときに作成されます。このオブジェクトのフィールドは、イベント・フィールドから複製されるほか、計算されたり、定数に設定されたり、データベース表から入力されます。この例では、TradeObject というインターミディエイト・オブジェクトが 1 つ使用されます。
- データ・ソースはリレーショナル・データベースや Excel スプレッドシートといった追加のデータ・ソースです。これらは通常、イベントに存在しないインターミディエイト・オブジェクトのフィールドを算出するのに使われます。例えば、イベントの customerID フィールドに基づいてデータベース表に SELECT 文を実行して、address フィールドを求めます。データをデータ・ソースから取得するプロセスを「データ・フェッチ」と呼びます。データベースはホスト (DB2® や Oracle® など)、ローカル (Microsoft® Excel スプレッドシート)、リモートのいずれでもかまいません。インターミディエイト・オブジェクトの 1 つ以上のフィールドはテーブル内の列にマップできます。
- コネクターは、XML メッセージとして定義されたデータ・ペイロードをタッチポイントと、ランタイムが使用する JMS メッセージ・トピックの間で受け渡しします。イベント・コネクターはタッチポイント内のイベントを認識すると、HTTP などのプロトコルを使ってデータを直接または間接的に内部の Java™ Message Service (JMS) メッセージ・キューに渡し、定義済みのインタラクション・ポリシーで評価できるようにします。同様に、アクション・コネクターはビジネス・プロセス・ルールの評価結果を受け取ると、内部の JMS メッセージ・キューからアクションをペイロードとして取得して、タッチポイントに渡します。アクション・コネクターも結果を返します。この結果はインバウンドのメッセージ・キューに置かれ、結果イベントとして評価されます。
図 3 に示すのは Design Data ツールの例です。左側には、次の 3 つのセクションに分類された定義とともにアセット・ツリーが表示されています。
- データ・ソース
- インターミディエイト・オブジェクト
- タッチポイント
右側には、選択したオブジェクトのエディターが表示されています。
図 3. Design Data ツール
Design ツール
Design ツールは、以下の主要なコンポーネントから構成されています。
-
インタラクション・ブロックおよびインタラクション・セット。インタラクション・ブロックには、Business Events にイベントが到着し、何らかの条件、すなわちフィルターが満足されたときにトリガーされるアクションが記述されます。同じイベントによって 1 つ以上の関連するブロックがすべてトリガーされる場合、そのグループのブロックをインタラクション・セットと呼びます。1 つのポリシーを構成するルールに異なるフィルターを付加したり、それらを異なるタッチポイントのアクションに適用したりすることができます。この例では、SellAfterBuy と SpeculativeCustomer の 2 つのインタラクション・ポリシーを使用します。
- コンテキストは、インターミディエイト・オブジェクトのコンテキスト ID というフィールドで関連付けられたインタラクション・セットの集合です。コンテキスト ID (例えば顧客 ID) によって、ストリームを流れる共通のイベント・セットが一意に識別されます。関数とフィルターは、コンテキスト ID が同じイベントについて評価されます。この例では、SellAfterBuy ポリシーは顧客 ID と株式 ID を組み合わせたコンテキスト ID を使用します。ポリシーでコンテキストの関係が定義されている場合、特定のイベントに対する Occurrences などの関数は、評価中のイベントと同じコンテキスト ID を持つイベントの発生を示唆します。
- フィルターは、 1 つ以上のルール中に現れる条件です。フィルターで表現される条件には、1 つのデータ・フィールドの値をテストするといった非常に単純なものや、時間が経過するにつれ発生する (または発生しない) 複数のイベントのパターンが関わる、非常に複雑なものがあります。このアプリケーションのフィルターは、After Buy と Speculative Customer です。
- イベント・フローは、実行可能な、ビジネス・プロセスをグラフィカルに表したものです。イベント・フローは一連のインタラクション・セットと関連するビジネス・ステップで構成され、トリガーされたアクションの後に発生するイベントを示します。
図 4 は Design ツールのスクリーン・ショットの一例です。アセット・ツリーではインタラクション・セットとフィルターが展開表示されています。Design ツールによる定義、タッチポイントとそのイベントおよびアクション、およびインターミディエイト・オブジェクトは表示できますが、修正することはできません。
図 4. インタラクション・セットとフィルターが表示された Design ツール
今後の連載記事の内容
今後のこの連載記事では、ビジネス・イベント・パターンの検出方法を指導し、Business Events を他の WebSphere 製品およびテクノロジーと統合する方法を説明します。
- パート 2 では、株取引データのパターンを検出するためのサンプル・アプリケーションを構築し、テストする方法を学びます。Design Data ツールを使ってイベントやアクションなどのデータを定義する方法を学びます。また、Design ツールを使ってフィルターやインタラクション・セットを定義する方法も学びます。最後に、Business Events アプリケーションをデプロイおよびテストする方法を学びます。
- パート 3 では、WebSphere Message Broker と Business Events を統合して、イベントをフィルタリングしてメッセージをイベントに変換し、アクションを作成する方法を学びます。Business Events はイベント内のパターンを検出し、アクションを生成します。
- パート 4 では、Business Events を WebSphere Process Server および WebSphere Enterprise Service Bus (WebSphere ESB) と統合して、WebSphere ESB からのメッセージをイベントとして Business Events に送り、そのパターンを検出した結果のアクションを WebSphere ESB に戻して処理する方法を学びます。
- パート 5 では、Business Events を WebSphere Business Monitor (Monitor) と統合して、Business Events が Monitor サーバーが受信および処理できる形式でビジネス・イベントを転送する方法を学びます。Monitor はこの受信したビジネス・データを分析し、レポートを生成します。Monitor のダッシュボードには、Business Events から受け取ったデータを監視したり、データに対応するために使用可能な包括的なグラフ、レポート、通知が表示されます。
- パート 6 では、Common Event Infrastructure (CEI) 経由で伝送される Common Base Events を受信および生成できるように Business Events を構成する方法を学びます。
まとめ
この記事では、ビジネス・イベント処理と、WebSphere Business Events およびそのコアとなる概念とツールについて説明しました。この連載の次の記事では、サンプル・シナリオを構築する方法を段階を追って説明します。
参考文献
著者について  | 
| | Peter Crocker は英国の IBM Hursley Software Lab で WebSphere Business Events のアーキテクト兼開発リードとして勤務しています。Crocker は以前、IBM Software Service の技術的な実務をワールドワイドで担当するコンサルタントとしてお客様の WebSphere Message Broker ソリューションのアーキテクチャー、設計、実装を指導してきました。それ以前は、WebSphere Message Broker と WebSphere MQ の製品開発において開発を担当していました。 |
| 
| | Doina Klinger は IBM Hursley Software Laboratory のアドバイザリー・ソフトウェア・エンジニアであり、WebSphere Business Events の開発者です。Klinger はこれまで数々の WebSphere 製品およびコンポーネントの開発者兼開発リードとして働いてきました。 最近では、WebSphere Enterprise Service Bus および WebSphere Integration Developer を担当しました。Eclipse とメッセージング/イベント処理テクノロジーに関心を持っています。Purdue University で情報科学の修士号を取得し、2000 年に IBM に入社しました。 |
| 
| | Latha Sivakumar は Research Triangle Park (ノースカロライナ州) の IBM WebSphere Business Monitor 開発チームのアドバイザリー・ソフトウェア・エンジニアです。Sivakumar は現在、Business Monitor と、Websphere Business Events を始めとする BPM スイートの他製品との統合を担当しています。以前は Monitor Data Services チームや、Tivoli Business System Manager を始めとする複数の Tivoli 製品に携わっていました。 |
記事の評価
| 
