レベル: 中級 Victor Grund (vgrund@us.ibm.com), WebSphere Technical Sales Manager, IBM
Chuck Rexroad (crexroad@us.ibm.com), Executive Software IT Architect, IBM
2007年 12月 05日 この記事はESB製品を選ぶための技術的な検討ポイントについて解説をします。ESBを実装したIBM製品の紹介だけではなく、ESBに共通の、実装パターンの概要についてご紹介します。また製品紹介として 3種類のIBM ESB製品と、いくつかのESBパターンを拡張する補完製品について説明します。最後に、ESB実装ケース・スタディ事例を2つ取り上げて、詳しく説明します。
3種類のIBM ESB製品
- WebSphere Message Broker
- WebSphere ESB
- WebSphere DataPower SOA アプライアンス
ESBを拡張する補完製品
- WebSphere MQ
- WebSphere Service Registry and Repository
- WebSphere Transformation Extender
- WebSphere Adapters
- WebSphere Process Server
- WebSphere Business Services Fabric
- IBM Tivoli Composite Application Management for SOA（ITCAM for SOA）
エンタープライズ・アーキテクチャーにおけるESBの役割とその価値
サービス指向アーキテクチャー（SOA）は柔軟で拡張性のあるコンポーネント指向のアプローチにより、新規開発する代わりに既存のアプリケーションを拡張して利用します。SOAで最も重要なことは、柔軟性です。ビジネス・プロセスの要素とそれを支えるITインフラをゆるやかな疎結合し、安定した粒度でまとめたサービスを使って、その標準化されたインターフェース同士を組み合わせることで、変化するビジネス要件に素早く応えることを可能にします。
SOAで使用されるサービスは、各種メッセージを送受信するためのよく検討されたインターフェースを持ち、実装時には記述されたエンドポイントへ正しくバインディングされることが必要です。エンタープライズ・サービス・バス（ESB）はアーキテクチャー・パターンであり、サービス同士のやりとりを仮想化して管理します。サービス・プロバイダーとリクエスターとの接続中継ポイントとして動作します。この柔軟な接続フレームワークにより、アプリケーション間のインターフェース数、サイズ、複雑さを軽減し、確実で安定したシステム統合を実現します。
直接やり取りをするのではなく、ESBのようなサービス接続フレームワーク経由にすることで、SOAの基本思想を拡張して、仮想化と管理機能が利用できるようになります。ESBの仮想化テクニックには次のものがあります：
- ロケーションと実体：メッセージを受け取ると、サービス同士がやり取りするためのルーティングを行います。これらのサービスは互いに、相手のロケーションや実体について知る必要はありません。例えば、リクエスターは自分の要求が何種類のどのプロバイダーで処理されるかを知る必要はありません。新たなサービス・プロバイダーを追加するときは、ESBにてメッセージがルーティングされるように設定変更します。こうすることで、変更作業によるリクエスターへの影響を抑えることができます。
- 通信プロトコル：異なる通信プロトコルや通信スタイルを使用するサービス・リクエスターからプロバイダーにメッセージを送るときに、通信プロトコルを変換してメッセージをルーティングします。逆方向も同様です。例えば、リクエスターがSOAP/HTTPを使ってプロバイダーへアクセスすると、ESBはプロバイターが使用しているJMSに変換します。
- インターフェース：リクエスターとプロバイダー同士でインターフェースを揃えて定義する必要はありません。ESBは双方が持つインターフェースに対して、リクエスターから送られたメッセージを一旦、正規化データとして受け取り、プロバイター向けフォーマットに再度変換して送り出します。
ESBパターンは、様々なミドルウエア製品（ハードウェアとソフトウェア）、プログラミング・モデル、およびインタラクション・スタイルにより実装されます。
ESBの基本機能：
- メッセージを識別し、アプリケーションとサービス間をルーティングする
- 通信プロトコルが異なるリクエスターとプロバイダー間でも、プロトコル変換してメッセージ交換を可能にする
- メッセージ・フォーマットが異なるリクエスターとプロバイダー間でも、フォーマット変換してメッセージ交換を可能にする
- 様々なソースからくるビジネス・イベントを見分けて配信する
- 堅牢で確実なコミュニケーション環境を提供
- コンポーネントをプラグインすることで拡張できるアーキテクチャーを実現
- インテリジェントに判断できるルーティングによる、ロケーションに依存しない処理が可能
- メタデータによりメッセージ記述および定義を管理する
- エンタープライズ全体にわたって、ニーズに合わせてアセットを統合する
実装されたESBの多くはサービス・コネクティビティを実現するために、XMLとWebサービスといった標準を利用しています。このことはESBの定義として業界では認知されています。
しかし本来ESBとは、こうした標準にあてはめる必要はありません。ESBアーキテクチャーのパターン はもっと拡張できます。メインフレームのアセット、パッケージ・アプリケーション、センサーとデバイス、ファイルやカスタム・プロトコルといった、共通標準ではない既存IT投資資産の活用をサポートすることができます。ESBは企業全体にわたる接続要件をサポートできるのです。
ESBは次のタイプのサービス・インタラクション・パターンをサポートします：
- 一方向、または 要求/応答
- 同期、または 非同期
- パブリッシュ/サブスクライブ・モデル、または 複合イベント・プロセッシング
イベント・プロセッシングとは、発生した一連のイベントから、一つの結果としてイベントを生成することをいいます。組織にとってESBは重要な投資です。その特徴は次のとおりです：
- シンプル：インターフェースの数、サイズ、複雑さを低減
- リスクとコストを低減：ビジネス・ニーズの変更に、迅速に対応できるITを実現
- 再利用の促進：再利用しやすいデータ、ビジネス・ロジックやアプリケーション作成時にサービス利用を促進
- 動的で、リアルタイムな、イベント・ドリブンなSOAをサポート：密結合のためシステム変更が困難なバッチ更新のITシステムを置き換える
ユーザーのロールとタスク
SOAは、他のITイニシアチブと同様に、テクノロジー・人・プロセスに依存します。ESBの主な成功要因は、ガバナンス・フレームワークの下で、ESBテクノロジーが適切に管理されていることです。これによりSOAの価値を得ることができます。多くの事例からSOAセンター・オブ・エクセレンス（CoE）組織が大きな価値を持ち、SOAテクノロジーを受け入れるスピードを上げることが分かりました。CoEは全ての組織に関与し、経験を共有し、教育を施し、プロセス改善の提案をし、SOA環境の成熟度をチェックします。
CoEはSOAガバナンス・ボードの援助が必要です。SOAには特有の課題があります。たとえばサービスのバージョン管理、サービスの共有、そしてセキュリティです。SOA CoEでは、組織をまたがったITチームとしてIT投資、デザイン決定への助言を行い、SOAビジョンと戦略に沿った、戦略的共有ITソリューションに近づけていきます。CoEは様々な課題に対処します：
- ガバナンスを実践する
- 組織にSOAを浸透させる
- SOAガバナンス定義とSOAガバナンス・ボードによる管理プロセスをサポートする
- SOAガバナンスの管理・運営を実施する
- ソートリーダー（実践的先駆者）としての行動と、ビジョンを作成：SOAガバナンスと管理・運営のソートリーダーとして行動する
- SOAスキルを持ったエキスパートを入れる
- アセットの利用方法など、ナレッジ管理方法をデモしてみせる
- IT部門以外の部門とのコミュニケーションを行う
CoEが担う役割について、次の図に表わします。
テクノロジーの選択基準
インタラクションのスタイル
様々なインタラクション・パターンをサポートするには、包括的なSOAアプローチが要求されます（例えば要求/応答モデル、パブリッシュ/サブスクライブ、イベントなど）。ESBインフラは、3種類の主な企業レベルの統合スタイルをサポートします:
- SOAアプリケーション：高い再利用性を持つサービスを組み合わせて構成された、アプリケーション。そのサービスは、熟考を重ねた明確なインターフェース定義を持つ。メッセージングやイベント・コミュニケーション・モデルを基にした、サービス指向インタラクションを行う。
- メッセージ・ドリブン・アーキテクチャー：発信元アプリケーションは、まずESBにメッセージを送信し、ESB経由で宛先アプリケーションへルーティングされる
- イベント・ドリブン・アーキテクチャー：イベントを生成するアプリケーションと、それを利用するアプリケーションとは独立している
サービスを呼び出すコンシューマーは、サービス呼び出しの方法を、様々な方法で実装できます：
- 同期：コンシューマーは、シングル・スレッドでサービスを呼び出す。スレッドが要求送信してサービスが実行している間は、継続処理を止めて応答を待つ。
- 非同期：コンシューマーは、2つのスレッドを用いてサービスを呼び出す。1つ目のスレッドが要求送信するとそれは処理を継続し、別のスレッドがその応答を待つ。
- パブリッシュ/サブスクライブ：サービス・パブリッシャーは特定トピックについてメッセージをパブリッシュし、サービス・サブスクライバーはトピットに対してサブスクライブ登録することで、パブリッシュされたメッセージを受け取る。この仕組みにより、複数のサブスクライバーにメッセージを配信する。
ESBはこれら呼び出しモデルを組み合わせてサービスに提供し、サービス・コンシューマーが適切なモデルを選択できるようにします。
インタラクション・スタイルはESB実装に影響します。IBM® WebSphere® Message Brokerは、非同期もしくは擬似同期を行う典型的な基本フローのアーキテクチャーに適しています。
ステートフルネス
ある状況では、メッセージが横断するときの状態をESBが管理する必要があります。単純な例としては、最終メッセージが持つコンテキスト情報から、特定のサービス・エンドポイントを選択するケースがあります。複雑な例になると、複数のメッセージとイベントの文脈依存（意味論的な前後関係、実際の前後関係、目に見える前後関係）など複雑な状況から、ESB動作を拡張して複雑なイベントを処理するケースもあります。こうした機能性は、ビジネス、アプリケーション、インフラのいずれの観点から見ても、イベント・ソースが複数ある場合には、極めて有効に機能します。またこういったシナリオは、セキュリティ、財政、金融、保険業界においても、SLA違反を警告する仕組みや、コンプライアンス遵守の確認作業にも関連するでしょう。
ハードウェアによるESB実装システムでは、一般的にはステートフルなインタラクションをサポートしません。ソフトウェアによるESB実装システムであれば、ステートフルネスな仕組みを実現できます。WebSphere Message Brokerはその中でもユニークな特徴を持っており、製品機能として複雑なメッセージ処理を実装しています。こうした機能が求められるユースケースにおいては、この製品が最も適したものと言えるでしょう。
エンドポイント、使用標準、プロトコル
エンドポイントとは、ESBを経由してやり取りを行うサービス・コンシューマーとサービス・プロバイダーのことです。
Webサービスのような標準のテクノロジーとプロトコルを使用するエンドポイントであれば、ESBテクノロジー選択において最も柔軟性があると言えるでしょう。しかしながら既に多大な投資をされた大規模なレガシー・システムについては、こうした標準テクノロジーを適用することが現実的でなかったり、コストに見合わなかったりします。また、パッケージ・アプリケーションにも同様のことが言えます。独自のAPIを使用しているため、そのミドルウェア・ベンダーに統合を任せたほうがよい場合もあります。
こうした課題を解決するためには、アダプターを使ってシンプルな統合を実現します。この場合には、様々なアダプターに対応したソフトウェアESBを選択するとよいでしょう。
ポリシーによるインタラクション管理と、動的なサービス選択
動的なエンドポイント選択機能は、急速に発達しているESBテクノロジーの一つです。これはエージェント・ベースのエンドポイントを扱うもので、サーバーの使用率と状態を改善します。この機能をサポートするIBMのESB製品は、IBM Tivoli Composite Application Manager（ITCAM for SOA）と組み合わせることで特別な開発をせずに、この機能が利用できるようになります。
メッセージのボリューム、サイズ、タイプ
各々のESB製品は、異なる拡張性を持ちます。一般に言えるのは、ハードウェアESB製品は、業界標準データ・フォーマットをサポートするのに適しています。ただしソフトウェアESB製品ほどには、多様な機能を提供しません。WebSphere Message BrokerはESBの豊富な機能を利用するのに適しており、カスタム・コンポーネントとアダプターを使って、さらに拡張可能な製品です。WebSphere ESBは、業界標準フォーマットを数多くサポートしており、JavaとWebサービス標準、それにカスタム・コンポーネントとアダプターを使うことで、さらに拡張可能な製品です。
信頼性、可用性、保守性（RAS）
各々のESB製品は、異なる運用操作性を持っており、異なるメカニズムとアーキテクチャーにより、高い拡張性と高可用性を実現します。例えばクラスタリングの方法でも、アプリケーション・サーバーによる方法とOSレベルによる方法といった違いがあります。ソリューション・アーキテクチャーを決める考慮点としては、RAS（信頼性、可用性、保守性）についての検討と、予算、組織の保有スキル、運用容易性のバランスをとることが重要です。
メディエーションに求められる要件
各々のESB製品は、プログラミングせずに行うメディエーションのカスタマイズ方法を、各々の方法で実現しています。とりわけWebSphere Message Brokerは、標準データ・フォーマットを幅広くサポートします。例えば、ACORD, SWIFTやCOBOL copybooksといったものをサポートします。データ・フォーマットがXML形式で、かつWebサービスを使用するものであれば、Websphere DataPower® SOAアプライアンスを使用するのが良いでしょう。これは高いパフォーマンスを発揮します。
IBM ESB製品
エンタープライズ・サービス・バス（ESB）を実現するための製品は、多くあります。IBMは選択肢を複数提供しています。ニーズに合わせて、適切なESBテクノロジーを選択することができます。ESBテクノロジーは複数の組み合わせで利用されることもあり、その使用場所、テクノロジー、その他理由でハイブリッドなESBが要求されることもあります。ハイブリッドESBとなるケースは、2つの大組織で各々が個別のSOA構築をした後になって、相互連携を図る必要が出てきたときに起こります。
IBMではWebSphere Message Broker、WebSphere ESB、それにWebSphere DataPower SOAアプライアンスといった、3つの主要なESB製品を提供しています。
WebSphere Message Broker
WebSphere Message Brokerは、多くのお客様で利用されるESBです。ハイブリッドなソリューションにおける、セントラルESBとして利用されるケースがあります。WebSphere Message Brokerは、歴史的にWebSphere MQメッセージングから派生した製品であり、とりわけMQメッセージングに依存した環境に適しています。WSDLと他のメッセージ・フォーマットに対応したインターフェース定義を提供しています。メッセージ・フロー制御を行うメディエーション機能と、WMQとHTTPによるコミュニケーション形式をサポートします。他にもコンテンツ・ベースのパブリッシュ/サブスクライブといったインタラクションと、トピック・スペースの管理機能をサポートします。
エンドポイント間で行われるサービス・インタラクションのメディエーション・パターンを幅広く実装しています。また業界標準のメッセージ・セット（一部XMLエンコーディングを使用）をサポートし、さらにはユーザー定義のメッセージ・フォーマットも追加できます。WebSphere Message Brokerソリューションが選ばれる典型的な要件には、次のものが挙げられます：
- トランザクショナルであること
- パブリッシュ/サブスクライブによるメッセージ配信
- ACORD, SWIFT, またはCOBOL copybook標準フォーマットを使用
- XMLフォーマットのデータを使用
- WS-*標準に準拠すること
- WebSphere MQメッセージングを既に利用している
- 複雑な変換処理が必要
- 複雑なイベント処理が必要
WebSphere Message Brokerは多岐に渡るESBとしての接続性と、any-to-anyのデータ転送機能を提供します。これによりレガシー・アプリケーションなどの、標準に準拠していないシステムでもESBへ接続させることができます。
WebSphere ESB
WebSphere ESBは、J2EEベースのESBです。IBM WebSphere Application ServerのJ2EEコンテナーで動作します。そのため J2EEとWS-*標準ベースのアプリケーションに適しており、こうしたアプリケーション同士のコミュニケーションを行う場合に最適です。またSOAワールドへの最適なエントリー・ポイントが用意されており、基本的なWebサービスを足掛かりにして、より堅牢なSOA環境に成長させることが可能です。
この製品は、標準ベースのWebサービス接続、JMSメッセージング、およびサービス指向の統合機能を提供しています。Point-to-pointおよびパブリッシュ/サブスクライブ・メッセージングのJMSアプリケーション、JAX-RPCサービス指向アプリケーションは直接、WebSphere ESBに接続できます。またWebSphere ESBを経由させてWMQ、SOAP/HTTP、SOAP/JMSといった多様な転送ができます。Webサービスのゲートウェイとしても実装が可能で、SOAP/HTTPとSOAP/JMSベースのアプリケーション同士を、メディエーションを使って連携させることができます。UDDI（Universal Description Discovery and Integration）との連携も、可能です。WebSphere ESBソリューションが選ばれる典型的な要件には、次のものが挙げられます：
- J2EE 実装であること
- Web サービス・インターフェースを使用
- SOAP/HTTPを使用
WebSphere DataPower SOAアプライアンス
WebSphere DataPower SOAアプライアンスは、ハードウェアでありソフトウェアでもあります。XMLアクセラレーション、強制セキュリティ、ESB機能といった重要な機能を提供します。DataPowerの重要な特徴は次のとおりです：
- 効率的に動作するハードウェア、ファームウェア、組み込みOS
- 高レベルで保証された構成
- セキュリティ脆弱性の低減
- ハードウェア保存された暗号化キーと、それによる監査ログのロック
- ハードディスク、CD-ROM、USBポートは搭載せず
- フタを空けられたら動作停止する、改ざん防止機能
- アプライアンス製品ならではの容易な操作性、DataPowerは手軽に始められるSOAとして利用可能、また同時にセキュリティ環境も構築
DataPowerソリューションが選ばれる典型的な要件には、次のものが挙げられます：
- セキュリティ・ゲートウェイが必要
- XMLファイヤー・ウォール、パーシング、バリデーションを行いたい
- 基本的なルーティングが必要
- コンテンツによるルーティングが必要
- 次のプロトコル・ブリッジが必要: HTTP、WebSphere MQクライアン、FTP、ODBC、etc…
その他の補完テクノロジー
上記でご紹介したESBテクノロジーのほかに、次のESB実装を拡張させる補完製品があります：
WebSphere Service Registry and Repository
WSRRは、UDDIサービス・ディレクトリーが提供する基本リポジトリー機能よりも多くの機能を提供します。UDDIは完全なスペック定義がされておらず、現在利用されているUDDIは、ベンダー各々によって異なる実装をしています。WSRRはどんなサービスが存在するのかを登録するレジストリー機能だけでなく、開発者向けの再利用促進させる機能（サービス検索の充実）、および実行局面でのESB機能強化に利用可能です。
WSRRは次の情報を保持します：
- サービス関連情報を登録するサービス・レジストリー
例.サービス・インターフェース、オペレーション、パラメーター
- 多様な利用形態をサポートする、サービスのメタ情報リポジトリー
WSRRはSOAライフサイクル全体に関わります：
- サービスの開発局面において、標準アセットの情報提供による再利用促進
- サービスの修正・変更や本番リリースで変化する、ライフサイクル状態遷移のトラッキング
- 実行局面における、サービスの状況に応じたアクセス条件の最適化
- 運用システム管理における、サービスとメタ情報の共有
WSRRは、サービスに関する「誰が、何を、どのサービスに、いつ」といった情報を提供します。詳細については、ケース・スタディで説明します。
ESBの基本パターン
ここでは共通言語ともいえる、ESBメディエーションについて紹介します。このパターンはESBメディエーションの基本的なコンテキスト（文脈）を説明しており、このメディエーション・パターンを組み合わせることで、ベスト・プラクティスやレッスンズ・ラーンド（経験則）を表現することが可能です。またESBのユースケースも、このコア・パターンの組み合わせで表現できます。
|
プロトコル変換（プロトコル・スイッチ）
- 多様なプロトコルを使用するサービス・リクエスターからのメッセージを、それとは異なるプロトコルを使用するプロバイダーへディスパッチする際に実施（例. SOAP/HTTP, JMS, およびMQ Integrator）
- ターゲットのサービス・プロバイダーに合わせて実施
- リクエスター、プロバイダーのインタラクションが終了した時点、その両方が終了した時点、またはその合間にて実施
- 各々の形式と関連性が明らかであれば、プロトコル変換の自動生成が可能
|
|
|
メッセージ変換
|
|
- メッセージのコンテキスト情報は変更せずに、ペイロード部分（電文本体）を更新
|
|
- 変換サブパターン（変換）
- メッセージ・ペイロード（電文本体）のフォーマット（別名スキーマ）を、リクエスターのものからプロバイダーの形式に合わせて変換する
- 他ネットワークの使用プロトコルに合わせてメッセージ・ヘッダーを用意し、メッセージそのものを中に入れてしまう
- 暗号化にも利用
|
|
- 情報付加サブパターン（増強）
- メッセージ・ペイロード（電文本体）に、メディエーションのカスタム・パラメータやDBクエリー（検索）で得た外部データソースからの情報を付加する
|
|
|
経路変更（ルーティング）
- メディエーションによりサービス・プロバイダーを選択
- 例：ゴールド会員には、高いSLAのプロバイダーを選択
|
|
|
検索（ディスカバリー）
- ESBレジストリーを検索し、リクエスターが要求する条件に合ったサービス・プロバイダーが複数見つかったときは、そのうち一つを選択してルーティングする
- ルーティングの拡張パターン：
- メディエーション開始時点では、サービス・プロバイダーは構成されていない状態
- 次の条件でサービス・プロバイダーを検索、結果を取得
リクエスターが使うメッセージ・フォーマットと一致すること
リクエスターが要求するQoSを満たしていること
条件に指定したプロトコルの一つと一致すること
- 検索結果から一つを選択してルーティングする
- 例：データセンターのフェールオーバー・シナリオ
データセンターをバックアップのオンラインに復旧し、レジストリー・サービスとトラフィックをバックアップ系統へルーティングさせたい。このとき、メディエーション・モジュール全部を変更するような作業はしたくない。
|
|
|
分配（ディストリビュート）
- 関係者グループに対して、メッセージ配信する
- 関係者グループへは、サブスクライバーが関係者プロファイルで登録する
|
|
|
モニター（監視）
- ESB上を流れるメッセージを監視する例：
- サービス・レベルのモニタリング
- 問題原因を特定するためのデータ監視
- ビジネス・レベルでのイベント記録（例：トランザクションが特定の収入を超えた等）
- 監査用メッセージをログ
|
|
|
相関（複雑なイベント処理）
- 関連し合うメッセージやイベント・ストリームから、複合イベントを知る手段として使用する。パターンによる検知ルールと、そのときのリアクションを定義する。
例えば、きっかけとなるイベント・ストリームのコンテンツから、複合イベントを生成するなど。
|
|
基本パターンを組み合わせた、複合パターンの例：
|
正規アダプター（カノニカル・アダプター）
- 全ての使用メッセージと使用ビジネス・オブジェクトは、正規化されたフォーマットにまとめる。
正規アダプターは、エンドポイントが使用するプロトコルをESB標準プロトコルへ変換し、ペイロード（電文本体）を正規化データ・フォーマットにマッピングする。ルーティング先へは再度、リクエスターに合わせて同様な変換が行われる。これはプロトコル変換とフォーマット変換パターンの組み合わせで表現できる。
|
|
|
メッセージ変換、ロギング、ルーティング
- ESB に共通した組み合わせパターン。送信されたメッセージのプロトコル変換、ロギング、およびエンドポイントへのルーティングを行う
|
|
|
プロキシー・パターン（ゲートウェイ・パターン）
- サービス・エンドポイントに合わせたルーティングやプロトコル変換パターンに加えて、セキュリティ機能（承認とアクセス・コントロール）とロギングまたは監査能力を提供する
- 変換メディエーションとモニター・メディエーションを組み合わせて、暗号化やロギング、監査能力などを提供する。またone-to-manyの関係にメッセージを集約、あるいは分解する場合もある。
例：複数のサービスに対して単一の接続点を提供し、内部サービスの詳細を見えないようにする。
|
|
ESBの複雑なパターン
これからご紹介するパターンは、より現実的な要望に応えるためにリッチなサービス仮想化を進めたESB活用方法です。大規模な組織や外部SOAパートナー協業する組織の多くは、複数ESBが必要になることがあります。要件は次のとおりです：
- セキュリティ
- パフォーマンス
- アカウンタビリティ（責任追跡性）/監査性
- リソース・コントロール
次に紹介するパターンは実証例であり、完全に網羅したパターンではありません。これらのパターンは、プロジェクト要件に応じて組み合わせることができます。
グローバル ESB
グローバルESBは、すべてのサービス・リクエスターが１つのレジストリーにアクセスすれば、すべてのサービスが見えるようにします。このパターンは本番環境には向かないかもしれませんが、小規模なシステムテスト環境に利用できます。他のESBを使用しないで行うグローバルESBです。これはハイブリッドESBのアプローチとは異なります。ハイブリッドESBについては、後ほどご説明します。
- すべてのサービスが1つのネームスペースを共有し、異機種混成、地理的に分散環境においてもセンターESBを経由して、サービス・プロバイダーがすべてのサービス・リクエスターから見えること
- あるサービスが、部門や小規模な企業レベルを超えて使用されるケース
グローバルESBでは、WebSphere Message BrokerとWebSphere ESBの2つのESBテクノロジーが選択できます。WebSphere ESBは使用環境がJ2EEと標準ベースのときに適しています。複雑な変換や非J2EEシステムとのインタラクションが要求されるときは、WebSphere Message Brokerがよいでしょう。大規模な組織になれば、両方の製品を使って、メッセージ・タイプと宛先に応じたルーティングを適切に行います。これについては後述するフェデレーテッドESBでご説明します。
ESBゲートウェイ
ESBゲートウェイ・パターンは、内部と外部ドメイン境界を越えてしっかりコントロールされた、安定したサービス・インタラクションを提供します。
ESBゲートウェイ・パターンは、多くの場合でDataPowerアプライアンスを使って実装されます。これはゲートウェイ機能だけでなく、XMLファイヤー・ウォール機能をも提供します。DataPowerは、ネットワーク境界を越えた連携に適しています。また組み込みOSとソフトウェアを実装しているため、OS環境のセットアップが不要になり、これに関するリスクを低減しています。
フェデレーテッドESB
フェデレーテッドESBは、複数あるサービス・レジストリーを連合することができます。管理ドメインからそれぞれのサービス・レジストリーをマッピングし、サービスをフェデレーテッド・セットにまとめます。これにより、複数のESBでサービスのインタラクションが実現します。個別管理されているサービスを全社統合するケースなどで使用されます。
- 独立した複数ESBをフェデレートした、単一イメージのマスターESB
- サービス・コンシューマーとプロバイダーが、ネットワーク越しにサービスへアクセスするための、マスターESBまたは独立ESB
- 各部門で管理しているESBを連合し、各部門からそれを共用利用する仕組み
フェデレーテッドESBでの中心となるESBには、WebSphere Message Brokerが適当でしょう。それ以外のESBとしてはWebSphere ESB、遠隔にあるオフィス用にはDataPowerアプライアンスがよいでしょう。このパターンでは、それぞれのサイトにサービス・レジストリーを持ちます。ベスト・プラクティスによれば、ネットワーク境界にはDataPowerアプライアンスを使って、承認と証明を行わせます。また内部システムへデータを送る前に、XMLのパースと確認を行います。こうした使い方は、DataPowerアプライアンスの特徴である高速度な処理を生かして、トランザクション処理スピードを上げてESBサーバーのCPU使用率を下げる効果があります。
ブローカーESB
ブローカーESBは、複数レジストリーをサポートします。例えば各レジストリーではその部門が担当するサービスのみが管理されて、サービス全体で見ると複数ESB/レジストリーに分散された状態になっているとします。このとき、サービス全体を統一イメージで利用できるようにしたいときに、ブローカーESBを利用します。
- サービス間をブリッジすることで、リクエスターやプロバイダーに対して、他のESBドメインにある相手が見えるようにします
- それぞれのESBでは、独自のネームスペースを管理します
- ESB間のサービス・インタラクションは、共通ブローカーを経由することで容易になります
- 各部門で開発・管理した保有サービスを他のESBにまで広く公開できるようになるので、より広範囲でサービスを共有できるようになります
ブローカーESBパターンは、フェデレーテッドESBに似ていますが、ブローカーとして動作する中心となるESBが、サービスをルーティングすると同時に、強制ポイントでもある点が異なります。
JBI標準（JSR208）でブローカーESBについて議論されていますが、これは実際に経験したことを踏まえた十分な検討がされていないため、IBMはJBIスペックの代わりになるものを選択しました。コンポーネント構成に適したメカニズムで、より確実な連携ができる、多くのテクノロジーとオープン・スペックが利用可能だからです。IBMは製品、アプリケーション、既存のビジネス・アセットを幅広くサポートし、統合化を実現することを優先します。
ESBシナリオ #1：ABCホテル
ABCホテルは、グローバル展開しているホテルとレジャー会社です。いくつかのブランド名を持ち、贅沢で高級なフルサービスのホテルを展開しています。900を超える直営と、230,000部屋を越える管理またはフランチャイズ経営のホテルがあります。
ABCは大規模で複数年に渡るプロジェクトを開始し、大規模でモノシリックなメインフレームで構築された中央予約システム（CRS：Central Reservation System）を、分散J2EEサービスによって刷新することを計画しました。狙いはメインフレームを置き換えることによるコスト削減と、ビジネス・アジリティ（機敏性）を向上することでした。プロジェクトは、SOAの適用コンセプトと方針を決めるものとして、大きく検討されました。作成されたサービスは2箇所のデータセンター上に分散されました。個々のサービスが二重に配置されたことで、システム・スループットと可用性が向上します。
当初、このCRSプロジェクトは汎用的なESBフレームワーク無しに検討されていました。プロジェクトが進むにつれサービス統合が複雑さを極め、このまま進められなくなりました。それはアーキテクト、開発者、運用担当者に重い負担となって圧しかかり、CRSプロジェクトの成功も危うくさせるものになりました。そこでESBでまとめることが検討されたのです。ABC社は正しい対応を知るために、検証作業を実施することになりました。
IBMに提出されたABCホテルのESB要件をまとめたものは次のとおりです：
- リクエストのルーティングとワークロード管理：サービスを分散コピーして各インフラに配置することで、信頼性、保守性、可用性を向上できること。ESBはクライアントからの要求を適切なサービスかつ適切なバージョンにルーティングすること。ESBはワークロード管理を実施し、大量の要求を複数のサービス・インスタンスに負荷分散させることが出来ること。それにはシンプルな分散アルゴリズムであること、ただしエンドポイントのワークロード・バランスを考慮して実施されること。
- レジストリー統合：ABC社は開発局面でUDDIベースのサービス・レジストリーによるサービス・カタログを使用していました。このレジストリー情報を実行局面でも活用できること。
- メディエーション：ABC社は、ESBがクライアントとサービス間をメディエーションするものとする。サービス・データはWSDL/XMLで表現するものとし、固有処理が必要な独自のデータ・フォーマットは使用しないものとする。パフォーマンス/変換スピードと同様、WS-IとXSDによるメッセージ確認機能は重要な要件とする。
- トランザクション管理：ABC社はコミット済みのサービス・リクエストに対して、コンペンセーション（補償）とロールバックを必要とするユースケースを持っている（複合サービスで構成した分散トランザクションをサポートするケース）。こうしたケースに対応するための、ルール・ベースによる処理、トランザクションの原子性確保、およびプロセス・ドリブンなトランザクションのサポートができること。
- サービス・コレオグラフィーとワークフロー：小規模なサービス・インタラクションにも複雑なワークフローのサポート要件が要求されます。こうした場合には、BPELサポートを適用します。ビジネス状態マシン、インタラクションのスケジューリングとタイミング制御、イベントの相互関係、ワークフローから呼び出すヒューマン・インタラクションのサポートができること。
- バックエンド・システム統合を容易にする仕組み：Siebelなどを直接統合するには課題あり
- 高パフォーマンス / 低遅延：ESBを使用することで全体パフォーマンスを向上し、一方で処理遅延が極力発生しないこと
- モニタリング、管理、運用：サービス・レベルのモニタリング、標準とカスタム・メトリックス、失敗検知、原因分析、レポーティング、および履歴分析などに関する要件
- セキュリティ：Tivoli Access Manager、LDAP、そのほかセキュリティ製品との統合が可能なこと。証明書と主要管理機能、標準ベースの認証処理、アクセス・コントロール、暗号化/復号化、SSL、サーベンス・オクスレー管理（SOX）、DMZ（ネットワーク環境における非武装地帯）を考慮する。
- SDLC：ABC社はEclipseベースのRational Application DeveloperとRational Software Architect製品を使用している。ESB実装ツールは、こうした製品と高い親和性を持つこと
- 迅速なデプロイメント：ABC社はESB検討前にかなりの投資を既に実施しており、ESB実装にかかるコストとスピードは重要な懸念項目
- 運用難易度の削減：リスクと複雑さを低減するために、ABC社はESBベースのアーキテクチャーを採用することに決定した。そのため簡単なソリューションを強く希望する。
サンプルのユースケース
バックエンド・サービスを呼び出すビジネス・パートナー
ABC社は通常、空き部屋検索と予約処理を、ビジネス・パートナーと協力して実施します。DMZ実装パターンが使われているバックエンド・サービスへの仮想呼び出し要件がありました。この場合クライアントは、アクセスするためのネットワーク認証と許可を得る必要があります。また同時に、すべてのアクティビティはモニターされ、ログに記録される必要があります。
クライアント別、要求タイプ別、またはその他情報による分類で、トラフィックを分割することも、これからの要件として検討します。
バックエンド・サービスを呼び出すホテル・プロパティ
それぞれのプロパティには、CRSへのインターフェースを持つローカルのプロパティ管理システム（PMS）を持ちます。ここでのプロパティの役割は部屋状況を更新して予約済みにします。CRSはそうして刻々と変化する部屋の空き状況を確認する必要があります。プロパティが持つCRSとのインターフェースはXML over MQを使用し、CRSサービス側ではそれと異なるプロトコル、たとえばSOAP/HTTPを使用しています。
同様にこのパターンを増やして、エンドポイントの利用状況に応じてルーティングさせるようにするのが考えられるシナリオです。
上記両方のユースケースとも、ESBトラフィック の大部分を表わしています。
障害時における複雑なリカバリー・シナリオ
プロパティからのクライアント要求に応じて処理実行中に、複合サービスのインタラクションが失敗したケースを想定します。失敗時点からリカバリーを行うには、人によるリカバリー・タスクも含めたワークフロー手順が必要だと考えられます。コアESBパターン変更せずにコンポーネントをアーキテクチャーに追加して、この機能を実現したいと考えました。
バックエンド統合を含んだ複雑なワークフロー
このシナリオでは、顧客からの要望を受けて優良ゲストのトラッキング・システムに入力されたことを想定します。ビジネス・ユーザーは、この情報をメディエーション処理の一部でSiebelシステムに登録したいと考えました。ESBは既存サービスが標準メディエーションを実施すると同時に、ISVバックエンド・システムへも更新をかけます。変換・モニター・ルーティングのESB集合パターンをこのケースに適用できますが、アーキテクチャーは複数ITコンポーネントを使用することで、このサービス要求を解決します。
ソリューション・アーキテクチャー概要
IBMはハードウェアとソフトウェアESB両方の実装による、一貫性のあるハイブリッド型ESBアーキテクチャーをここでは提案します。ESB機能としては、それぞれの異なる強みを合わせ持ちます。
アプライアンス（DataPowerのようにハードウェアとソフトウェアを組み合わせたもの）
- 相当な高パフォーマンス最適化、相当に処理遅延を低く抑える
- 最もシンプルな構成、デプロイメント、運用
- セキュア、改ざん防止
- 汎用目的プラットフォームを使用し、高価な処理基盤を排除
ソフトウェア
- アプリケーション・ホスティング、ワークフロー、複雑なメディエーションをサポート
- アダプターを利用しアプリケーション統合を実施
- ビジネス・アクティビティのモニタリング実施
多くのお客様がハイブリッド型アーキテクチャーを採用して、双方のアプローチによるメリットを生かすことをIBMは期待しています。SOAサービス・レジストリーと管理機能により、ハイブリッド型アーキテクチャーはさらに増強されます。
ソリューション・コンポーネント
- DataPower XI50（ESBアプライアンス製品）
- WebSphere Process Server（WebSphere ESBを包含）
- WebSphere Business Integration Adapter（s）（バックエンド・システムとの統合に使用）
- IBM Tivoli Composite Application Management for SOA（サービス・モニタリングと管理）
- WebSphere Service Registry and Repository（サービス・レジストリー）
次のシステム・コンテキスト・ダイヤグラムは、コンポーネント間のインタラクションを表現しています。
このアーキテクチャーにおいては、DataPower XI50は二つの役割を持ちます。一つはDMZ（非武装地帯ネットワーク）におけるサービス・ゲートウェイ、もう一つは信頼済みネットワーク・ゾーンにおける汎用ハードウェアESB的な役割です。ソフトウェアESBで求められるようなタスク（Siebelアダプターや人手による判断が必要な複雑なエラー・リカバリー）は、WESBを包含するWebSphere Process Serverに任せます。
DataPowerはABC社で発生するESBトラフィック要求の大部分を高いパフォーマンスで受け持ちます。WebSphere Process ServerとWebSphere ESBは、DataPowerと組み合わることでその機能を増強し、このアーキテクチャーの柔軟性を最大にします。
IBM Tivoli Composite Application Management（ITCAM）製品はESBと組み合わせて、そこでやり取りされるコンポーネントのモニタリングと管理を行います。モニタリング・エージェントから収集した情報はESB機能を増強し、動的サービス選択のような、複雑なルーティング・パターンを実現します。これはサービスをモニタリングしているモニタリング・エージェントから得られた情報を元にして、そのサービス選択時の判断に加えさせる動きです。例えばサービスをホスティングしているサーバー負荷を見て、次回からサービスを選択する優先度を変更したりします。
WebSphere Service Registry and Repository製品は、サービスの完全なライフサイクル・ガバナンスを実現し、ESBにおいては動的なサービス選択を実現可能にします。UDDIだけでは実現できない機能です。
このアーキテクチャーはパフォーマンスと柔軟性を良いバランスで実現します。
ESBシナリオ #2：XYZ 保険会社
XYZ保険会社は、医療保険を扱う会社です。企業は何百万人もの顧客を持ち、顧客、提供者、外部エージェント、その他とビジネス上の関係にあります。この例は、保険プロジェクトの実例を組み合わせて説明しています。
XYZ社は現在までに多大な投資を行ってきたメインフレーム（z/OS）上のCOBOL、Assembler、PL/Iアプリケーションを活用しつつ、ITを最新にすることを狙いました。これらのシステムはDB2とIMSデータベースを使用しており、エンドユーザーとのコミュニケーションにはCICS（Customer Information Control System）を使用していました。IBMのWebSphere MQはインフラであり、かつアプリケーション間のメッセージを支えるバックボーンです。メインのデータセンターがあり、複数のサテライトにあるデータセンターと、外部システムとがつながっています。
XYZ社はサービス指向アーキテクチャー（SOA）を採用し、新しいコールセンター環境（CCE：Call Center Environment）を構築することに決めました。これで新しい苦情処理アプリケーション（CPA：Claims processing Application）システムを構築します。多くのアプリケーションと変更作業が要求されますが、この2つの主要システムに集中することにしました。
プロジェクト全体の要件としてIBMとXYZが考慮したアーキテクチャー定義は次のとおりです：
- 新たにコーディングせずに、レガシー・アプリケーションを活用する
- 新しいサービスを作成するまでは、メインフレーム・システムを活用する
- 複数の通信プロトコルをサポート（SOAP/HTTM, WebSphere MQ, etc.）
- 外部組織に対するSOAインタラクションのセキュリティ・サポート
- 地理的に分散した複数データセンター環境の運用
- リアルタイム・モニタリング機能と、期待するサービス・レベルでのトランザクション・ルーティング
ESB要件についてはABC社のケース・スタディと似ています。違いがあるのは、より複雑なメディエーションが要求される、という点です。同様に数多くの規制、セキュリティ、監査性要件により、ABC社のケースよりも、さらに堅牢なシステムが求められました。
ユースケースのサンプル
リモートにあるデータセンターから本体のデータセンター・サービスを呼び出す
リモートにあるデータセンターの一つは、コールセンター環境（CCE）において頻繁にメインのデータセンターを呼び出します。これが組織で検討された結果、ゲートウェイを使用してアプリケーションのセキュリティを確認し、要求に合致していることを監査していました。
このケースでは、メインのデータセンターに対するサービス・コールを一つ用意すれば、レガシー・アプリケーションに対して個別に複数コールすることと同じことになります。そこで要求されるサービス・コレオグラフィーとワークフロー・コンポーネントにより、結果情報を組み合わせて一つのサービス応答として返す仕組みを用意しました。
データセンター側では次のように表現されます：
メインのデータセンター側では次のように表現されます。ゲートウェイとモニタリング・コンポーネントはこのダイヤグラムには明示的に表現されませんが、ソリューションには重要なコンポーネントです：
本体のデータセンターからリモートのデータセンター・サービスを呼び出す
メインのデータセンターは頻繁にリモートにあるデータセンターの一つを呼び出して、最新のコールセンター環境（CCE）のアクティビティを確認します。これはリモートにあるデータセンターに完全なるSOA環境を要求し、メインのデータセンターと同等のセキュリティと監査機能を要求することになります。
メインのデータセンター側では次のように表現されます：
本体のデータセンターから社外サービスを呼び出して住所確認を行う
メインのデータセンターは外部サービスを呼び出して、XYZ社のデータベースに保存前に、入力された住所が正しいことを確認します。
外部エージェンシーが意識せずレガシー・アプリケーションをサービス呼び出しする
外部アプリケーションが呼び出したサービスが実はレガシー・アプリケーションである、ということを知る必要はありません。これはアーキテクチャー的に興味深いユースケースです。
リモートにあるデータセンター側では次のように表現されます：
メインのデータセンター側では次のように表現されます。ゲートウェイとモニタリング・コンポーネントはこのダイヤグラムには明示的に表現されませんが、ソリューションには重要なコンポーネントです：
サービス・コールのパターンから不正探知する
サービス・コールのパターンから不正探知を行うことは、コール回数を数えるだけではなく、どのエンティティが呼び出しを行ったのか、どんな間隔で呼び出しを行ったのかをモニタリングする必要がある複雑なケースです。特定ユーザーが特定顧客に異常な回数を呼び出ししたという情報、またはユーザーのアクセスが一次禁止されて通知されるケースは、XYZ社が調査を行うべき異常な振る舞いです。
このモニタリング、ロギング、相関性、セキュリティについてのシステム統合は相当なチャレンジですが、SOAテクノロジーと既存ESBテクノロジーで実現できます。
ソリューション・アーキテクチャーの概要
IBMとXYZ社は共同作業を行い、ハードウェアとソフトウェアESBコンポーネントを組み合わせた、ハイブリッド型ESBアーキテクチャーを作りました。このケースではIBMの3つのESBテクノロジーが用いられ、要求された機能を実現しました。レガシー統合に対する要件、サービス・コレオグラフィー、基本ワークフローがアーキテクチャーを決定づけました。
次のシステム・コンテキスト・ダイヤグラムはそれらのコンポーネントのやり取りを表しています。
ABC社の例では、DataPower XI50は、DMZにおけるセキュリティ・ファイヤー・ウォール、それに信頼するネットワーク・ゾーンにおけるハードウェアESBとしての、2つの役割を持っていましたWebSphere Process Server/ESBは複雑なサービス・インタラクションをコレオグラフィーするのに使用され、データ構造からデータを取り出してより複雑なビジネス・サービス応答に組み込むことに利用されます。WebSphere Message Brokerは複雑なメッセージ変換を行い、レガシー・システムとの連携を実現します。この例では、こうした3つのIBM ESBソリューションの持つ価値を一つのデザインで表現され、それぞれが互いの特徴を活用していることが分かります。
IBMは多くの組織においてXYZ社と同様の、複雑な要件を持っていることを知りました。これらの要件は複数のテクノロジーを用いて、可用性、パフォーマンス、セキュリティ要件に対して最も適切な能力を実現することができます。
ソリューションを構成するコンポーネント
XYZ社が使用したソリューション
- DataPower XI50（ハードウェア ESB, XML セキュリティ・ゲートウェイ）
- WebSphere Process Server（WebSphere ESB、および複雑なサービス・インタラクションをサポートするプロセス・クレオグラフィーを含む）
- WebSphere Message Broker（複雑なメッセージ転送と、非標準メッセージングをサポートするソフトウェア ESB）
結論
この記事はESBコンセプトと実装例を取り上げました。ESBを構成するテクノロジー選択と、どの製品がどんなシチュエーションに適しているかを述べました。このガイダンスは経験ある担当者にとっても役に立つでしょう。
謝辞
執筆者はMarc-Thomas Schmidt氏, Kyle Brown氏, Rachel Reinitz氏の協力に謝辞を申し上げます。彼らの協力で ESBにとって重要なIBM SOAイニシアチブに関する基本的な多くの情報を盛り込むことが出来ました。
参考文献
著者について  | | | ヴィクター・グランド氏（Victor Grund）はニューイングランドとニューヨーク州北部地区に責任を持つIBM WebSphereテクニカル・セールス・マネージャーです。17年のエンタープライズIT経験を持ち、そのうち近年7年間はIBMでの経験です。マネージャー、ソフトウェア・アーキテクト、SOAアーキテクト・リーダー、ITスペシャリスト、コンサルタントを経験しました。エンタープライズ・アプリケーションと統合ソリュシーョンのデザインと実装に幅広い経験を持っています。
コンタクト先はこちら vgrund@us.ibm.com
|
| | | Chuck Rexroad is the principal Software IT Architect for IBM's New England and upstate New York territory.
He joined IBM in 1998 as a Technical Specialist in the Tivoli brand and has extensive experience with all aspects of systems management.
For several years, he has been dedicated to SOA projects and technologies and has helped clients implement SOA environments in large and medium-sized organizations.
You can contact Chuck at crexroad@us.ibm.com. |
記事の評価
| 
