ESB導入効果を発揮するには
2010年2月2日に日本アイ・ビー・エムが開催したIMPACT Winterセミナーで、日本アイ・ビー・エム株式会社 WebSphere事業部 テクニカルセールス&サービス 豊村明彦氏は、ESBの歴史、基礎、現状、トレンドなどを概観した。
企業内には、様々な目的で構築された多数の情報システムがある。そこで扱われているデータの形式や、プロトコルが違うため、システムの相互接続には構築と運用管理の両面で大きな負担がかかる。そこで現在注目されているのが、システムをサービス化してつなぐESB(Enterprise Service Bus)だ(図1)。
ESBの基本機能としてはまず、通信プロトコルの透過性の提供がある。たとえばリクエスターがJMSでメッセージを投げるのに対し、サービスプロバイダーはWebサービスしか受け付けないシステムである場合、ESBがプロトコルを変換する。ESBのもう一つの要件がデータ記述の透過性の提供だ。ここでもESBが、データのフォーマットをつながっているシステムの求めに応じて変換する。第3の要件は、ロケーションの透過性の提供だ。ESBが適切なプロバイダーへルーティングする機能で、何らかの変更があった場合でもそれをESBが吸収する。
ESB活用の代表例がレガシー・トランスフォーメーションだ。レガシー・システムのインターフェイスをESBに合わせてWebサービス化する。大規模な改修になるが、一回行えば再利用性は非常に高い。また、ホスト・システムを書き換えず、インターフェイスをESBに任せることでレガシーアプリケーションを最小コストで再利用することが可能になる。SAPなどのERPパッケージ・アプリケーションの情報を他システムでも活用するERP連携でもESBは有効だ。
今後ESBは、ますますSOAの中核として周辺サービスとの関わりを深めてゆく傾向にある。バッチ処理としてのファイル連携、イベント処理、さらにコンプライアンスのための証跡管理や、サービスのライフサイクル管理とも密接に連動する機能を備えてきている。
豊村氏は「ESBを使う時、企業の中のポリシーが重要」と指摘した。一つのプロジェクト内だけでESBを導入しただけでは、コストリカバリーしないケースが多いからだ。複数のプロジェクトにおいて、継続的に、横串で使い回すことが肝要だ。それゆえ業務部門とIT部門がきちんと合意し、効果的に導入する必要がある。
巨大ファイル転送をサービス化する
続く、日本アイ・ビー・エム株式会社 WebSphere事業部 テクニカルセールス&サービス 恩田洋仁氏のセッションのテーマはファイル転送のサービス化だ。アプリケーション統合において、ファイル転送は外せない分野となっているが、ESBでは課題になるケースがある。
ESBでは異なるデータ形式を持つシステムをつなぐため、内部を流通するデータの解析と直列化を行う。物理形式の変換をESBのパーサーが行うため、インターフェイス管理が劇的に楽になる半面、アクセスが集中するESBでファイル転送のような大容量のデータを扱う際はパフォーマンスに注意が必要だ。ESBで消費するメモリについても転送データの数倍から数十倍必要というケースがある。またESBは多数のシステムと連携するため、ネットワークの帯域も確実に保護する必要がある。またファイル連携の実装は転送後のジョブの起動やファイルの完全性チェック等に複雑な処理を行っていることが多い。このような要因によってファイル連携がESB導入の妨げになることがある。
それではどう対応するか。完全な解はなかなか出てこないのだが、WebSphere MQ File Transfer Edition(図2、以下:WMQFT)を利用することで大きな作り込みをすることなくファイル転送自体をサービス化、仮想化できる。従来のMQ製品にファイル転送機能がなかったが、WMQFTはサーバーをまたがってのファイル連携の管理、監査証跡を一元的に行うことも可能にしたMQの上位製品だ。
それではESBとWMQFTがどう関係するのか。まずリアルタイム連携のためのIT基盤をESBで構築し、ファイル転送のためのIT基盤をWMQFTで構築する。ESBに接続するシステムからのファイルの転送指示イベントは、ESBを介してXML形式のMQ/JMSメッセージの形で転送基盤に送られる。ESBに接続しているシステムならどこからでもファイル転送指示を出すことができるようになり、ESBによるファイル転送の仮想化が可能になる。そして転送が行われると、ログもXMLの形でESBにパブリッシュされる。ファイル転送の一元管理を可能にすると同時に、監査ログとしても活用できる点も注目だ。
このようにファイル転送をサービス化することで仮想化やガバナンスの強化というESBの目的を失うことなく、負荷がかかるファイル連携部分をESBの外に切り出すことができる。
ESBにおけるイベント活用の効果
続く、日本アイ・ビー・エム株式会社 WebSphere事業部 テクニカルセールス&サービス 常盤千絵氏のセッションのテーマは、ESBが検知、作成するイベントを活用したビジネス情報の迅速な取得だ。IT業界において「イベント」はなじみ深い用語だが、本セッションでは何か「興味があること」が起こっているか、あるいは「起こる兆し」という意味で使用された。ESBでイベントにより実現したいことの一つはリスク回避だ。エラーのアラートを拾い、必要な対処を迅速に行う。そしてビジネス機会を見逃さない。データベースに格納されている静的なデータを検索して得る知見ではなく、今まさに発生しているイベント(パターン)からビジネス状況を把握し、アクションを行う。
実はESBとイベントは愛称がいい。ESBではつながっているシステムからのイベントが電気的な信号で入り、それを蓄積できる。そしてイベントをESBで拾い、アクションを起こすことができれば、様々な付加価値をつけることができる。元々ESBはサービスをつなぐバスであるから、Webサービスなどつながっているサービスを起動するのは容易だ。
イベントのパターンが非常に複雑で、ESBだけで適切に処理するのが難しいケースもある。その場合、ESBの外部にイベント処理ネットワークを構築し、連動するとより複雑なイベント・パターンを検出し、対応することができる。
IBMのソフトウェアの多くの製品では、CEI(Common Event Infrastructure)というイベント処理のための仕組みとCBE(Common Base Event)というイベントを表現するためのXML標準を採用している。CEIはイベントの送受信、イベント・バスの分散化、イベントの保持、サブスクライブ、更新、および照会といった機能を提供する。
中でもWebSphere Business Events(図3、以下:WBE)は、イベント処理に特化した製品だ。イベントから得られる情報をよりビジュアルに、統計的に表示する。ESBはイベントを検知するのと同時にイベントの発生源にもなる。WBEなどとの組み合わせにより、ビジネスが求めるピンポイントの情報を即座に得てアクションを行うことが可能になる。
動的なサービス呼び出しが解決するESBの課題
最後に登壇した、日本アイ・ビー・エム株式会社 WebSphere事業部 テクニカルセールス&サービス 豊田麻美氏のセッションテーマは、ESB管理において将来起こりうる課題の解決策だ。ESBによりITインフラ運用管理者への負荷を減らすことが期待されているが、将来的につながるサービスの数が増えていくと、様々な課題が浮上する。なぜならESBは、実装した時点でのサービスへしかルーティングできないからだ。サービスのバージョンやロケーションが変わるたびにESBを再実装しなければならない。
この課題を解消する一つの方法は、ESB側にサービスのロケーション情報を持たせず、外出しに保管することだ。リクエスターからメッセージが飛んできた場合、この保管庫にどのサービスに投げたらいいかを問い合わせ、その返答に合わせてESBがサービスを呼びに行く。リクエストが飛んできた時点で宛先を判断する、動的なルーティングだ。
IBMがこの考え方で提供しているミドルウェア製品が、WebSphere Service Registry and Repository(以下:WSRR)だ。SOAPやJavaのAPIを持ち、プログラムからの呼び出しでサービス情報を検索、登録が可能になる。
IBMのESB製品ではWSRRに接続し、検索するための標準機能を提供している。リクエスターから来たメッセージをどういう形で処理するか、ケースバイケースでフローを作成する。すべてのESB製品が持つ、「エンドポイント情報取得」のための部品をフロー上に配置し、求めている処理の流れを定義する。
またWSRRにはサービスのロケーション情報だけでなく、その属性なども登録し、公開できる。同様のサービスを利用したいと考える開発者が発見しやすくすることで、再利用(共用)を促進する。
WSRR導入における効果で注目したいのがガバナンスの遵守だ(図4)。サービスの設計段階から開発、運用まで、すべての情報はWSRR上で一元管理することで、抜けや漏れ、規範からの脱線を排除することができる。さらに監視系のソフトウェアTivoliシリーズを導入すれば、サービスの品質を保ちながらWSRRとESBを連携させることが容易になり、さらに優れたサービス管理を実現するのだ。
ESBを、システムをつなぐためだけに使うのでは、そのポテンシャルの一部しか活用していない。様々な課題に応えるソリューションを生み出すESBの可能性に注目したい。