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

●インターネット サービス バス

　図 4 は、インターネット サービス バスの概念を示しています (ISB の初期の例は BizTalk サービス。「参考資料」を参照)。ISB プロバイダは PHP Web サイトをホストする会社に似ています。どちらもアプリケーション プラットフォームを "雲" の中で仮想的に提供します。PHP Web をホストするサイトは主にデータベースとやり取りする動的 Web サイトや Web サービスを開発するためのプラットフォームを提供します。それに対し、ISB プロバイダは他のサイトが提供するサービスを統合するコンポジット アプリケーションの作成と配置のためのプラットフォームを提供します。ISB も PHP Web ホスティング会社も、Amazon の S3 のようなサービスとしてのストレージもアプリケーションをサポートするサービスとしてのインフラストラクチャ ソフトウェアの例です。これは当初、サービスとしてのパッケージ アプリケーション ソフトウェアだった Salesforce.com とは対照的です。

図 4 : インターネット サービス バス

　ISB の中心となる概念は、URI (Uniform Resource Identifier) 空間を中心にして構築されています。アプリケーションに取り組んでいる Dave のチームは http://ISB.net/DaveAndTeam という URI を登録し "所有" します。このルートの下の URI は、アプリケーション統合点を表します。これは Java メッセージング サービスにおける送信先や、メッセージ指向のミドルウェアにおける待ち行列、あるいはパブリッシュ/サブスクライブにおけるトピックに似ています。チームは、ポリシーと機能を URI に関連付けることによって ISB アプリケーションを開発します。コンポジット アプリケーションは URI とポリシーと機能の集合です。

　ISB は ID と、どのメッセージをどの URI に誰が送信できるかを制御するアクセス機能を提供します。ID とアクセス機能はポリシーを URI に関連付ける例の 1 つです。

　たとえば、Dave が出張での予約を表示する公開 Web サイトにウィキ ページを維持することにしたとします。ウィキ ページへのアクセス制御が必要になります。自分の個人 Web サイトで認証機能と認証データベースを維持するのは面倒な作業になります。複数の Web サイトにページやデータがある場合、問題はもっと複雑になります。次のような例を考えてみましょう。

• データベース駆動型の個人 PHP サイト
• http://www.twiki.org/ を使用して構築した家族コラボレーション ポータル
• Windows Live Spaces (http://home.services.spaces.live.com/) のような空間型サイトにおける自分の空間

　Dave の友達の Don は、ISB の ID コンポーネントに登録し、ユーザー ID として don@foo.bar を作成できます。Dave は ID コンポーネントの Web UI を使用して Dave の ISB URI のどれに Don がアクセスできるかを指定できます。Dave はグループを作ってグループにアクセス許可を与えることもできます。Don は ISB にログオンすれば URI にアクセスできます。Dave はデータベースの集中管理を維持しながら "ISB" にウィキその他のリソースへのアクセスを許可することができるので、ISB は Dave のセキュリティ管理を単純化します。ISB は、ISB URI へのアクセス制御を通じてその背後にある実際のリソースを保護します。ISB の利点は、それが Dave の Web 上でのすべての "サービス" に関連する ID、グループ、リソース、およびアクセス ポリシーを定義して維持する単一の空間となることができる点です。

　Web ページを通じて行う目に見えるユーザーの動作を記述してきましたが、もう 1 つの一般的なアプローチは、コンポジット アプリケーションの一部になっている個別のアプリケーションに Web サービス API を使用して ISB へアクセスさせることです。

　ID コンポーネントは WS-Security のセキュリティ トークン サービス (STS) 機能もサポートし、他の STS と統合されます。これで Dave は ISB に登録されていない ID でのアクセスを管理できます。foo.bar が Dave が信頼し STS を実装している会社なら、Dave は foo.bar を認証する ID のアクセス ポリシーを定義できます。

　やがて、ISB は URI に関連付けることのできる追加のポリシーや実装を提供するようになるでしょう。例としては、WS-ReliableMessaging や暗黙のメッセージ ロギングなどが考えられます。その概念は、メッセージ指向のミドルウェアにおいて接続に quality-of-service ポリシーを関連付けるのに似ています。

　ISB は ID とアクセス制御機能を土台にして "セキュリティ保護された汎用接続性" を提供します。ファイア ウォールの後ろにあるアプリケーションにさえ接続できます。これには広範囲にわたる接続性パターンとプロトコルへのサポートが含まれます。例には、エンタープライズ アプリケーションの多くに見られる REST 指向の HTTP、WS-*、イベント駆動型パターンなどがあります。具体的には、ISB の接続コンポーネントは次の 3 つの中核機能を提供します。

1. 中継は、ISB とファイア ウォールの後ろのアプリケーションとの間の通信を可能にします。この能力の実現方法はたくさんあります (Biztalk Labs、「参考資料」を参照)。中継機能によって、簡単なシナリオの場合に体系的な企業間接続を設定する必要がなくなります。

2. プロトコルは、メッセージのやり取りに使用する WS-* や REST などの一般的なプロトコルの集合を提供します。ISB は異なったプロトコルを使用する 2 点間の接続では自動的にプロトコル マッピングも提供します。たとえば、RSS フィードを WS-* メッセージ接続に接続できます。どちらのアプリケーションも変更する必要はありません。

3. 機能は、ESB のように簡単な機能を URL に関連付けるためのサポートを提供します。例としては、マルチキャスト、WS-Eventing (イベント通信)、持続メッセージなどがあります。

　接続性レイヤはインフラストラクチャ技術のレベルで動作します。"配管" の違い (たとえば、REST 対 WS-*) が原因となる複雑さを取り除くことによって、ソリューションの開発を単純化します。このレベルでのインフラストラクチャの統合が要求されるプロジェクトではコストとリスクが高くなります。ISB はそのような問題を解消します。

　接続レイヤはアプリケーション レベルの要素やメッセージのフォーマットを認識しません。コンポジット アプリケーションの作成では、接続される各種サービスが使用する異なったメッセージ フォーマット間での調整が必要になります。ISB の機能の例は、HTTP GET 内のパラメータを XML メッセージ内の要素に変換する機能です。ISB はアプリケーション レベルのマッピングを提供する簡単なワークフロー (サービス構成) を提供します (図 5 を参照)。

図 5 : ISB のメッセージ処理

　ISB は簡単な機能のテンプレート "アクティビティ" を提供します。ワークフローはアクティビティ テンプレートのインスタンスで構成された図式です。仮に、航空会社がフライト状況を RSS フィードで発信するとします。そして Dave のアプリケーションの一部がフライト状況の更新を WS-Eventing 通知で受け取るようになっているとします。接続レイヤが RSS と WS-* の統合をサポートします。Dave のアプリケーションは XML イベント フォーマットを要求するので、それでもまだメッセージの内容を RSS フォーマットから XML イベント フォーマットへ変換する必要があります。ISB は通常、RSS から XML へのマッピング用に設定可能、再使用可能なアクティビティ テンプレートを提供します。

　もう 1 つのよく使用されるアクティビティ テンプレートは、選択ベースのルーティングです。Dave のアプリケーションは、ID = 1234 の車の予約をキャンセルするメッセージを発信できます。タウン カー サービスの予約コードの 1 つが "LE-" で始まり、もう 1 つが "OL" で始まる場合、Dave のアプリケーションは単一の ISB URI にキャンセル イベントを送信できます。セレクタがそのメッセージを処理して正しい端点にルーティングします。

　より複雑なメッセージ処理にはアクティビティを組み合わせることができます。これは ISB の一般的な機能です。例として、図 6 に車の予約をキャンセルするメッセージを受け取るように定義された URL でのアクティビティを示します。

1) WS-* を使用して XML でキャンセル メッセージを受け取る。
2) 予約 ID 要素を抽出してその先頭文字をテーブルで照合するアクティビティがある。
3) そのメッセージをタウン カー サービスに必要なフォーマットに変換する。
a) 1 つのプロバイダは HTML 電子メールを使用する。
b) もう 1 つのプロバイダは HTTP POST を使用する。

　メッセージ処理機能を構築するのはいたって簡単です。大多数の一般的なアプリケーション シナリオでは、単純にパターンとテンプレートをインストールするだけです。ISB プロバイダは簡単な Web ベースのアプリケーション開発ツールを提供します。開発者はそれを使用してアクティビティ テンプレートを選択し、Web フォームから設定パラメータを設定します。ルーティングには、Web フォームを使用してルーティング用のメッセージ フィールドとルーティング テーブルでの値を指定することができます。そのうちやがて、ISB は BizTalk の中のメッセージ処理ツールのようなもっと強力なツールを提供するようになります。

　多くのアプリケーション シナリオでは、メッセージ処理 (ルーティングや変換など) で十分間に合います。とは言え、簡単な順序付けと制御の流れが要求される場合もあります。ダラスで足留めを食ったときのホテルの予約というタスクを考えてみましょう。そのプロセスを簡単に記述すると、次のようになります。

1) ホテルチェーンの AAA に予約のリクエストを送る。
2) 返事を受け取る。
3) 成功すれば終了する。
4) ホテルチェーンの BBB に予約のリクエストを送る。
5) 成功すれば ……

　ワークフロー アクティビティでは、while や if ... then … などの制御の流れのアクティビティ テンプレートを使用してメッセージ処理を拡張します。ISB は基本的なメッセージ処理を拡張する簡単なワークフローに対するサポートを徐々に追加していきます。

図 6 : ISB のメッセージ処理

　ワークフローは複雑な概念に見えることがあります。業務ワークフローの体系的なソリューションではワークフローは強力かつ複雑です。アドホックな便宜的アプリケーションのワークフローの大多数は、非常に単純です。その構造は単純な PowerPoint ダイアグラムより複雑になることはあまりありません。少数の "クリップアート" があり、接続や図形に使用されます。アクティビティの動作は図形にプロパティを設定することによって表現します。

　ほとんどのワークフロー プロセスは、入れ子リストの構造を持つ傾向があります。これにより、簡単なツールでワークフローを構築できるようになります。単純な XSD で、入れ子リストのワークフローを定義する XML ドキュメントの構造を指定できます。視覚的なツールを使用して、アクティビティとその実装を指定したり、外部サービスへの接続を指定したりできます。Web UI フレームワークは、ページの流れや移行でしばしば似たような概念を提供する (Struts など) ので、このモデルは開発者コミュニティで広く知られています。

　体系的なワークフロー ソリューションは、ミッション クリティカルで何千人もの人々が使用するアプリケーションをサポートするので、複雑になりがちです。そのプロセス モデルとエンジンは、そのプロセスのすべての機能を表現し、複雑なエラー条件や承認などを扱うことができなければなりません。それに比べ、大半の便宜的なアドホック ソリューションでは、そのワークフローを使用する人の数が少なく、絶えず皆がいじくり回し改善されていきます。

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

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

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