はじめに
ビジネスインテリジェンス(BI)が組織に多くの利益をもたらすことは、既に知られています。整理統合、集約、データの分析などを通じて、BIは組織の中で何が起きようとしているのかということばかりでなく、今何が起きているのかということに対して、多くの見識をもたらしています。BIにより、組織がどこへ向かうのかあるいはどこへ向かうべきなのかという、(組織の)動向を特定することができます。BIへの道のりは、一般的には、抽出、変換、格納 (ETL)から始まります。一般的に言えば、ETLとは以下を含むデータウェアハウスのプロセスのことです。
- 外部や内部のデータソースからデータを抽出する
- ビジネスニーズに適合したデータに変換する
- 変換したデータをデータウェアハウス(もしくは、データマート)に格納する
基本的に、私たちがBIの境地に到達するためには、まさに一つのインプットだけが必要となります。それは、データです。BIには組織のシステムの中に埋もれたデータが必要なのです。
SOAを導入する
この数年間、私たちはITアーキテクチャの最前線にサービス指向アーキテクチャ（SOA）の進展を見てきました。それが誇大広告であることが明らかになる中で、組織はSOAへ移行し、BIが必要とするデータが複数のサービスと契約の背後に隠されたものとの間ですぐに散在してしまいました。
図１(What Is SOA, Anyway?(PDF･英語)から抜粋しました)のSOAコンポーネントを見て下さい。明らかなコンポーネントであるサービスから離れて、そのサービスのインターフェースに関連した、SOAが所有するその他いくつかのコンポーネントを見てゆくことにします。それらは、次のとおりです。
- サービスが実装する契約
- サービスの窓口となるエンドポイント
- サービスとコンシューマの間を行きかうメッセージ
- サービスに適用されるポリシー
- サービスと協調するコンシューマ
データではなく、スキーマを共有するものだ" とか、"サービスは自律的であるべきだ" といったSOAの考え方と同様に、これらのことは、SOAが如何にそのインターフェースを大切にしているかということを私たちに教えてくれます。厳密に定義されたインターフェースを通じたコミュニケーションが重要であるということは、SOAによる疎結合、柔軟性、俊敏性といった技術的かつビジネス的なアドバンテージを確実にもたらします。
図１. SOAコンポーネントとそれらの関係
データを詳しく把握することを目的としてデータを格納しているBIと、インターフェースの背後にある内部データを独立させることを目的としたSOAの間に、本当のインピーダンスミスマッチがあります。Pat Helland氏は外部データ vs. 内部データ(source) の中で、サービスの内部データはサービスの外部に決して公開されてはならないものですが、それこそがまさにBIが必要としているデータなのです。従って、私たちがこのことに関して考えるとき、Ventana Research(サイト･英語)による調査 (Dan Everett氏により、Dr. Dobb's Journalで公開)で、内部のIT要員がBIのサービスを実装するために必要な知識と技術を持っていると考えていると、回答者の３分の１が答えたということはさほど驚くことではありません。
解決策として、二つの選択肢があると思います。データを直接利用し、SOAの原則(データではなくスキーマを共有するなど)のいくつかを無効にするというものと、今配置されている契約と、(将来的に)BIに足りうるデータを持ちたいという希望で済まそうとするものです。(後ほど説明しますが、第三の選択肢として、第一の選択肢と同様にBIに必要な契約を個別に作るというものがあります。)
データを得る、あるいは・・・
第一の選択肢は、既に実績のあるELTのプロセスを使用して、BIが必要とするデータを獲得することです。
多くの分散した場所（サービス）からデータを統合しなければならないので、SOA化にはETLへの課題が少し残っています。しかしながら、多くのリソースからデータを統合するということは、BIやETLにとって新たな問題にはなりません。何故なら、大企業では、ERP、CRM、部門別データなどといった多くのデータソースを既に持っているからです。さらに、企業データが、システム間を１対１でつないだ(ポイント・ツー・ポイント)インテグレーションの複雑さではなく、凝集性のある構造に織り込まれているということをSOAが約束しているということを考えると、SOAでのETLは、より容易であると思います。("約束している"というのは、ここでは重要な意味を持つ語です。実際のところ、サービスを凝集性のある構造にするのは、簡単なことではないからです。しかし、それに関しては他の記事や書籍に譲ります。)
私が先で述べたように、ETLは成熟しており、BIソリューションの構築基盤としての実績があります。しかしながら、ETLを基盤に使用することで、私たちが当初目指していたSOAの利点の大部分を失うことになります。主な問題の一つとして、SOA以前の時代(実際は、多くの企業がそれが現実であるが)は、統合が複雑化していました。図２の状況を見てみます。歴史的に、それぞれの部門が自身のシステムを構築していました。その結果、新たなビジネス要求が発生するにつれ、独立したストーブパイプシステムができあがりました。そして、システムはデータの共有が必要になり、それらの統合の必要性を解決するために、新たなシステム間を１対１でつないだ(ポイント・ツー・ポイント)ときのインターフェースが追加されました。人々がシステムを利用するにつれ、他のシステムからの情報が必要であることや、システム間を１対１でつないだ(ポイント・ツー・ポイント)インテグレーションといった問題が持ち上がることが分りました。図２は、ポイント・ツー・ポイントインテグレーションの４つのタイプを表しています。ETL(抽出、変換、格納)のような DBとDBの関係や、オンライン、ファイルベースのようなアプリケーションとアプリケーションの関係があります。DBに直接接続するものは、アプリケーションとデータベースの関係になります。注意すべき点として、これは余すところのない完全なリストではないということです。その他のタイプとして、メッセージをベースとしたレプリケーションなどがありますが、それらに関しては図２に示していません。
最終的な結果は、システムのスパゲッティ化です。一つのシステムの変更はわずかでも、その結果は予測不能とものとなります。SOAの重要性は、さまざまなインターフェースや自律により、これらの問題を解決しようとするところにあります。
図２. 典型的な企業システム統合の複雑さ
サービスのデータへダイレクトパイプラインとしてETLを追加することは、単に、新たなポイント・ツー・ポイントのインターフェースを追加することです。即ち、SOAの「インターフェースの鎧」を破壊し、BIとサービスの間の依存性を持ち込むことになります。それは、その他の代替手段に対して利用することもできます。(もし私たちがBIのためにそうすることができるのならば、他のアプリケーション、サービス、システムに対しても同じようにするのはどうでしょう？)
ETLを行う上でのバリエーションとして、SOAのデータを外部データベースに複製し、そのデータでETLを行うことが可能です。しかし、それはまさに、私たちが今なお契約を無視し内部データの構造と結びついているように、サービスのデータベース上でETLを使うことと同じです。
以上により、ETLを利用することはおそらくベストな選択肢ではありません。ですから、契約の利用によるSOAの原則の上で構築する第二の選択肢で、BIとSOAの統合がよりうまくいくのかを見てみることにしましょう。
SOAのデータを抽出する(リクエスト/リプライ)
SOAとBIの統合で最も単純なソリューションは、BIのプロセスのために特別なことは一切しないということではありません。代わりに、もし私たちが今ある契約、例えばそれらがSOAイニシアチブの一部としてドラフト段階のものであったとして、それらを利用したらどうなるでしょう？私たちのBIニーズを満たすためには、定期的にサービスのインターフェースを抽出する必要があるでしょう。それにより、我々は継続的なデータを得ることができるのです。
このアプローチには、根本的な問題が二つあります。まず一つは、ネットワーク帯域の問題です。それぞれのサービスをポーリングするのに、ネットワーク上で多くのデータ転送を必要とします。この問題を解決するには、サービスをポーリングする間隔を空けたいと思うかもしれません。しかし、そうすることで次の問題が発生します。それは、その間に発生した重要なイベントを見失ってしまうリスクがあるということです。これは、午前と午後に空を眺めて、正午におきた日食を完全に見損なってしまうことに似ています。よって、残念ながら、何もしないよりはましですが、これが期待できる選択肢とは言えません。
SOAの接点を利用したもう一つの選択肢として、BIのニーズを供給するであろう特別な契約を作ることがあげられます。つまり、その契約により、サービスの内部構造からデータを取り出すことを可能とし、BIがそれを使用することができるのです。しかしながら、それは標準的なETLを使うこととほとんど同じです。つまり、ポイント・ツー・ポイントのインテグレーションや個別に利用するための特別な契約の事例をさらに作ることになります。
従って、その状況はあまり期待できるものとは思えません。以上により、私たちは苦境に立たされました。つまり、私たちがSOAのデータを抽出しようとするならば、SOAの原則と利益のいくつかを捨て去るか、BIの素晴らしいソリューションに関しては忘れてしまうかのどちらかにしなければならないということです。
でも、ちょっと待って下さい。別の方法があるかもしれません。結局のところは、・・・
SOAのマインドシフト～プッシュモデルへの移行
第三のオプションは、SOAを前提においたものです。それは、私たちがよく知っている単純なリクエスト/リプライを拡張し、イベント駆動アーキテクチャ（EDA）と呼ばれているもう一つのアーキテクチャスタイルと結合することをベースとしたものです。
EDAを一言でいうとSOAのようなものですが、プッシュモデルで構築されたアーキテクチャスタイルです。EDAコンポーネントがイベントを発行します。論理的には、コンポーネントに何か意味のある変更がおきたとき、イベントを発行するというものです。その変更は適切な処理の結果で可能で、例えば処理された命令がそれにあたります。また、データベースのダウンといったような、失敗でも可能です。他にも、１００万人目の顧客が購入をするといったような、ある値に達したときや、何かしら重要であると思われる状況になったときというのも可能です。物理的には、イベントはイベントのメタデータで記述されたヘッダー部と、その内容を含んでいるボディ部で構成されています。
それらがつくられるとすぐに、イベントは認可されているコンポーネントまで通知されます。そのイベントが処理されると、これらのコンポーネントも新たなイベントをつくるといったことを行います。航空会社のシナリオを例にあげると、フライトが遅延したということを、イベントが通知することができます。このイベントは、乗り継ぎ便を管理している別のコンポーネントをトリガーとし、遅延したフライトで到着した乗客のために、別のフライトを探そうとするといったことができます(本当に、今までおきたことを見ているかのように)。その他のプッシュ技術と比較して、独自の特徴をもつEDAは、イベントストリーム処理(ESP)と複合イベント処理(CEP)の概念からなります。イベントを独立した事象として扱うのではなく、それらを関連したイベントの連鎖として見ます。イベントの連鎖を見ることで、さらにそれらをいくつかのイベントの連鎖(イベントの集合体)の連携としてみることができます。それにより、長い期間をかけてイベントのパターンに関するその他有益な分析をすることができるだけでなく、過去に遡った分析をおこなうことができます。
EDAは、SOAとは無関係に使用することができますが、それらを一緒に融合することで、非常に有益なものになりえるのです。
SOAがEDAに出会う
契約の中に発行したメッセージを追加したらどうなるでしょう？"発行したメッセージ"とは、サービスがその状態を周期的な方法、もしくは、誰かがリッスンしているかもしれないイベント毎に発行することを言っています。私は、このサービス - コミュニケーションのパターンを「コミュニケーションの反転」と呼びたいと思います。何故なら、それがSOAの一般的なケースであるリクエスト/リプライのコミュニケーションスタイルを逆にしたものだからです。それは、サービスを取得するのに必要なネットワーク負荷と同じくらいの量であると思われるので、ネットワーク付加はずっと少ないです。しかしながら、コミュニケーションの反転を利用すると、ポーリングしているコンシューマが複数回にわたり同じ状態変化を取得している間(若しくはデータを取得しそこなったとき)は、関心のあるサービスコンシューマ毎にイベントを、たかだか一回だけ取得すれば良いのです。
ソリューションを完全なものとするために、サービスコンシューマが最初のスナップショットを取得するのに、リクエスト/リプライ、もしくは、リクエスト/リアクションのメッセージをさらに追加することができます。このアプローチの後に、BI特有ではない方法でサービスの中でのイベントストリームの変更を取得することができます。実際、他のサービスがイベントストリームに応答することで、システムの全体的な疎結合を促すことができます。例えば、他のサービスの状態をキャッシュすることができ、サービス間の一時的な結合が容易になります。加えて、EDAをSOAに加え、aggregated- reporting パターン(初期の草案ですが)を実装することによって、今あるSOAの問題を解決するための基盤となりえます。
SOAでのEDAはBIの問題を解決します。ネットワーク上のイベントストリームだけでなく、BIのコンポーネントがデータを取得し、好きなように加工し、それをデーターマートやデータウェアハウスに格納することができます。また一方では、イベントストリームでより複雑で関心のあるリアルタイムなイベントやリアルタイムなデータ傾向の分析が可能となります。そして、コンプレックス・イベント・プロセッシング(CEP)ツールを利用することによって、リアルタイムなビジネス・アクティビティ・モニタリング(BAM)を取得することができ、結果として、BIそれ自体を強化することも可能です。イベント処理はどのように見えるのでしょうか？処理すべての注文がXML記述によって書かれ、あるイベントを発行する注文サービスがあるとイメージしてみて下さい。例えば、リスト１のようになります。
OrderDate="2007-04-02T00:00:00"
DueDate="2007-05-15T00:00:00">
リスト１. 注文合計のXMLの抜粋
より一層の分析や行動をすることを目的として、このストリームを監視したり、関心のあるイベントを継続的に抽出するために、ESPやCEPのツールを利用することができます。例えば、リスト２は100,000ドルよりも大きい注文を見つけるための注文の流れに関するクエリーを表しています。注意点として、このクエリーはSQLのようにも見えます(SQLから派生しています)が、それとは全く違うということです。それは、クエリーが永続的でないイベントストリーム上を継続的に実行しているからです。
INSERT INTO LargeOrders
SELECT
orderid as orderid,
SUM(Ords.price * Ords.qty) AS TotalValue,
FROM
OrdersStream AS Ords XMLTable (val
ROWS '//OrderLine'
COLUMNS
Orderid as orderid,
TO_FLOAT (XMLExtractValue ('@Price')) AS price,
TO_FLOAT (XMLExtractValue ('@Quantity')) AS qty );
WHERE
TotalCost>100000
リスト２. 注文の中から$100,000 ドルより大きい注文を見つけ、それをLargeOrders テーブルに格納するためのCoral8の継続的な計算クエリー言語
CEP が主流となるまでの道のりはまだ先のことですが、いくつかのベンダーはこのソリューションを利用しています。たとえ私たちがCEPを使わないとしても、これらのイベントを受け取ることでも多くのメリットを得ることができます。例えば、データウェアハウスで株を管理しているサービスであれば、注文サービスの注文処理の流れをリッスンし、新しい株の注文や、保有している株の利用などに注意を払うことができます。
SOAでのEDAによりBIを構築するとき、基本的にはBIをサービスのマッシュアップとして作ります。さらに拡張して、BIコンポーネント自体がその傾向のデータやその他の分析結果をサービスとして公開することができます。そして、それらのデータを利用し、他のアプリケーションでそれを利用することができます。例えば、もしリスト２のCEPクエリーが、$100,000より大きい注文に対して毎回イベントを生成したとしたら、一時間/一日単位で、いくつかの有効な計測値と共にどのくらい大きな注文を処理しているかをリアルタイムで示すことができる素晴らしいダッシュボードを、CEOのポータル上に表示させることができるのです。
図３. BIをマッシュアップとして表示する
しかし、まだ次の問題に答えていません。どのようにしてサービスがこれらのイベントを作るのでしょうか？
ところで、リクエスト/リプライはどうなのか？
実装サイドを見ると、この動向をサポートするためのインフラは既に出始めており、既に存在します。もし、ESB上でSOAを実装するなら、大抵の ESB製品はイベント発行をフルセットでサポートしているので、むしろ実装が簡単です。WS*のプロトコル群を利用するなら、WS- BaseNotification、WS-BrokeredNotification、WS-Topicという標準セットがあります。
Representational State Transfer (REST)を利用するか、若しくは、前述の比較的未完成なWSプロトコルのセットを利用したくないのであれば、自分でパブリッシュ/サブスクライブの部分を実装しなければならないでしょう。しかし、それに対する解決策も既にあります。それは、RSSと呼ばれているものです。誰かがブログに投稿すると、 RSSリーダーがリクエスト/リプライ方式(同期)をとり、前回RSSリーダーが問い合わせを行ってから追加された投稿を取得します。ちょっと聞いてください。RSSは、疎結合なパブリッシュ/サブスクライブであり、リクエスト/リプライ(同期)の上に作られたトピック(カテゴリ)も含んでいます。
.あなたのサービスは、ちょうどブログのようなもので、フィードとしてそれらのイベントをパブリッシュすることができます。それは、いくつかのアーキテクチャ的な利点をボーナスとしてもっています。まず第１に、サービスはサブスクライバーを管理する必要がありません。第２に、サービスを利用するためにイベントが発生している間は、コンシューマがそこにある必要はありません。さらに、キューイングエンジンやその他、私が考えうるその他の技術を利用するよりも、管理やセットアップが容易で単純です。
結論
EDAとSOAを一緒に使うことで、SOAを壊さずにBIの要件を解決するためのソリューションを私たちにもたらします。しかしながら、EDAと SOAのアプローチには、チャレンジしなければならないことが二つあります。一つは、BIのソリューションとしてEDAとSOAを使用した実績があまりないことです(実績のあるETLと比較した場合。それは先に述べたとおりです)。もう一つは、第一段階として、SOAの実装が基本的な同期メッセージのアプローチにより構築されているので、それに対する作りこみやもっと言えば作り直しが必要になるということです。既存のSOAソリューションにEDAを加えるということは、少しの努力でできるものではありません。しかしながら、そのどちらもSOAの中でETLを使っていません。何故なら、私たちは多くのソースからそれぞれのサービスが保有する自身の内部データを抽出し、公開しなければならないからです。そして、そこそこのSOAイニシアティブのためのデータであれば、割と多く持っていると思われます。
私の意見としては、総合的にはほぼ全ての考え方において、EDAとSOAの方がETLを利用するよりも勝っていると思います。
SOAの観点から見ると、SOAにEDAを追加することは、SOAのイニシアティブにとって総合的に良いことです。EDAは、より自律したサービスを構築するのに役立つツールです。例えば、サービスが他のサービスから関連するデータをキャッシュすることができ、データが変更したときに通知を受けることができます。そして、利用しているサービスは、やがてそれが相互に作用するサービスから分離され、それらの有用性に頼ることはできません。それは、リクエスト/リプライ(同期)が利用されたときの状況です。
BIの観点から見ると、事象はさらによいです。EDAを活用することで、従来のBIのメカニズムを用いて成し遂げるのが本当に難しかったことを私たちにもたらしてくれます。それは、リアルタイムという考え方です。EDAが生成したイベントストリームを利用するとリアルタイムにデータを取得することができ、CEPツールを利用することでリアルタイムな動きを扱い、それらが示す新たな傾向を処理することができます。
以上をまとめると、EDAとSOAを利用してBIソリューションを実装することは、従来のETLを使用するよりも優れているといえます。基本的な BIだけでなく本当により良いリアルタイムのBIにするということ。それは、SOAの品質を全体的に改善すれば良いというものではないということです。
著者について
Arnon Rotem-Gal-Oz氏は、様々なプラットフォーム(HP-UXやSolarisから、AS400やWindowsまで)上で、大規模で複雑な分散システム構築した数多くの経験をもったマネージャー兼アーキテクトです。Arnon 氏のブログは www.rgoarchitects.com/blog です。また、Dr. Dobb's Portal blogでは、ソフトウェアアーキテクチャと設計に関する記事(www.ddj.com/dept/architect)を書いています。Arnon氏の連絡先は、arnon@rgoarchitects.comです。
原文はこちらです：http://www.infoq.com/articles/BI-and-SOA
このArticleは2007年7月10日に原文が掲載されました）