アーキテクチャ・ジャーナル インターネット サービス バス Donald F. Ferguson、Dennis Pilarinos、John Shewchuk 2009/01/19

■ソフトウェアとサービス : インターネット サービス バス

●エンタープライズ サービス バス

　Dave がニューヨークからダラスへ飛んでいる間に、航空会社が Dave のダラスからサンフランシスコへの接続便をキャンセルしたらどうなるか考えてみましょう。Dave はサンフランシスコへ行けないので、接続空港のある町で 1 泊する必要があります。ホテルとレストランと車の手配を変更する必要があります。Dave は空港に着いたら例のマッシュアップ アプリケーションを使用して変更の実行を簡略化できます。飛んでいる間に自動的に変更が行われればもっといい (カッコイイ) わけです。航空会社とフライト監視サイトはフライト スケジュールの更新フィードを発信します。理想的には、Dave のアプリケーションは "雲の中の" どこかで常に実行していればいいわけです。アプリケーションはフィードを監視してイベントに反応する簡単なロジックを使用して日程を変更できます。

　簡単なエンド ユーザー アプリケーションが常に日程を修正できる可能性は低いと思いますが、多くの修正は簡単です。Dave は複雑なケースのみを手作業で処理すればいいわけです。飛んでいる間にアプリケーションが自動的に行った変更を承認するようにもできます。

　日程の修正は企業の中では一般性の高い汎用アプリケーションのシナリオです。同じような問題は発注や経費の承認などでも発生します。このシナリオは直通処理 (STP : Straight-Through-Processing) パターン (「参考資料」を参照) を実装するコンポジット アプリケーションの例です。企業ではこのような問題の解決には体系的なアプローチを取ります。図 2 はそのようなコンポジット アプリケーションの概容を示したものです。ただしここでは、航空会社、ホテル、レストラン、タウン カー、その他のシステムが企業ファイア ウォールの内側にあると仮定しています。比較的長期間実行されるオーケストレーション プロセスが、フライト管理システムが発信するイベントにサブスクライブします。このプロセスは既存のアプリケーションとメッセージのやり取りをしたり、呼び出したりして、予約の解除、問い合わせ、新しい予約の作成を行います。企業はさまざまですから、既存のアプリケーションではさまざまなメッセージ フォーマット (C、COBOL、その他) と通信プロトコル (WebSphere MQ、SAP RFC など) が使用されています。

図 2 : 企業の業務処理

　図 2 に示した修正プロセスはもろいデザインです。たとえば、もう 1 つの航空会社アプリケーションが追加されると、その業務処理を変更する必要があります。業務処理は既存アプリケーションの使用する特定のメッセージ フォーマットや言語に結び付いている可能性もあります。たとえば、経営陣の出張の場合はすべてのメッセージを記録するといった一定の条件を満たす汎用メッセージ ロギング メカニズムを追加するのは難しくなります。このもろさが、エンタープライズ アプリケーション アーキテクチャをエンタープライズ サービス バス (ESB) へと導いたのです。

　図 3 にエンタープライズ サービス バスの概容を示します。アプリケーション アダプタによって、既存のフォーマットとプロトコルが標準 Web サービスに変換されます。これが、何かを何かに接続するときの N × N プロトコル/フォーマット マッピングの問題を N → 1 マッピングの問題、つまりすべてを標準に変換する問題に一変させます。ESB はサービス間を流れるメッセージを処理する機能を追加します。例としては、メッセージの変換、ロギング、ルーティングなどがあります。

図 3 : エンタープライズ サービス バス

　Dave の会社の開発部門と業務部門で彼の出張アプリケーションは予算を付けるだけの価値があり、エンタープライズ チームは図 3 のようなアプリケーションを実装してもいいと決定されたとします。この体系的ソリューションの開発には次のような問題があります。

1. 企業がコンポジット アプリケーションに予算を付けるという保証はありません。他にもっと急ぐ必要のある問題があるかもしれません。

2. 体系的な開発にはユースケース、何らかの形のプロセス モデル、関係者のインタビューなどが必要であり、時間がかかります。

3. 航空会社、ホテル、およびその他のアプリケーションは企業の外部にあります。企業は、ビジネス間接続の設定には非常に慎重で注意深いものです。取引先の会社が Web サービスを導入したとしても、企業は取引先との Web サービス相互アクセスの認証規則と監査を確立する必要があります。従業員は社内 ID と航空会社やホテルで使用する ID を持っているので、企業はユーザー ID の管理、フェデレーション、およびプロビジョニングをサポートする必要があります。

4. 個々の従業員に対してソリューションをカスタム化しようとすると複雑になります。従業員はカスタム化を "自分でする" ことができません。アプリケーションは中央の基幹サーバーに入っています。業務処理は Dave ではなく IT プロフェッショナルが定義し修正します。

　Dave が体系的なソリューションの簡単な個人版を作成できれば本当にカッコイイわけです。ESB を広義に解釈して、体系的な業務アプリケーション開発用に最適化されたサービス バスの一種と考えれば、便宜的な開発用に最適化されたサービス バスの一種を考えることもできます。これがインターネット サービス バス (ISB) です。ISB はいたるところに存在するメッシュのようなものです。ISB はデバイスどうし、デバイスとローカル サーバー、Web サイトどうし、ESB どうし、それ自身と ESB などをリンクします。ISB は "自作" コンポジット アプリケーションや業務処理プロセスのプラットフォームです。ISB はサービスとしてのソフトウェア (SaaS) の例でもあります。

INDEX
	［アーキテクチャ・ジャーナル］
	インターネット サービス バス
	1．シナリオ : 便宜的開発と体系的開発
	2．ソフトウェアとサービス : インターネット サービス バス（1）
	3．ソフトウェアとサービス : インターネット サービス バス（2）
	4．ソフトウェアとサービス : インターネット サービス バス（3）

「アーキテクチャ・ジャーナル」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）