ESBにおけるルーティングとオーケストレーションの選択

導入

現在、エンタープライズサービスバスは、アプリケーションとサービス統合の分野で現実的な問題を解決することのできる多数のツールを結びつけるための本当に有用なソリューションです。しかし、問題に対するソリューションは理解しているのに、目的のためにどのツールを選べば良いのかを見つけ出すことができないことを知っているユーザーのためにツールボックスができることには、ちょっとした不便さが存在しています。

本稿の目的は、最も複雑で多様性のあるESBのコンセプトであるルーティングとオーケストレーションに直面したときに、ESBユーザーが彼らの必要性に応じた正しい答えを選択する手助けとなることです。抽象的な理論を述べる代わりに、私たちは単純な試みと根拠について説明したいと思います。たとえば、OW2 PEtALSのJBIに準拠したESB([1]参照)による現実世界での実例、低レベルのルーティングとグローバルなビジネスサービスオーケストレーションの間のすき間を埋めようする試みです。言い換えれば、私たちはルーティングとオーケストレーションの異なるレイヤーを構築する方法を明らかにしようと思います。

エンタープライズサービスバスからルーティング問題まで

ESB は、情報システムに広がるサービス指向アーキテクチャ(SOA)を含んだ、多くのアプリケーション分野を対象としています。しかし、最も低レベルでは、それら全てはアプリケーションとサービスの統合を容易にすることを目的としています。つまり、あるアプリケーションやサービスの呼び出しをさせることです。この非常にシンプルで一般的な試みには、さまざまな複雑さのレベルがあります。

• 「ルーティング」。呼び出し元のソースサービス、あるいは、どちらかを選ぶためのターゲットサービスが、一つではなく多く存在する場合。
• 「プロトコルブリッジ」。サービスがもう一つのプロトコル上で公開されているとき、他のサーバーまたは他の情報システムに属している場合。
• 「トランスフォーメーション」。サービスメッセージが同じデータフォーマットを持たない場合。それが、例外というよりはルールとなっている場合。

これら3つの、「ルーティング」、「プロトコル」、「トランスフォーメーション」は、一連の近い関係を持っていますが、それにもかかわらず、主要なESBの概念とみなされているかもしれません。本稿では、一番初めのもの(ルーティング)と、それの近い関係にあるもの(オーケストレーション)との関連についてフォーカスしたいと思います。簡単な説明として、たとえば、ルーティングが基本的に低レベルなものであるか、あるいはほぼESBの核であること、メッセージが送信されなければならない場所の技術的な解決を提供するための技術的な構成(サービスデプロイメントディスクリプタのようなもの)に依存していることです。オーケストレーションは、高レベルでより有用なコンポジットサービスをつくるためのサービス呼び出しを結びつけるものとして見ることができますが、多くは、明確な「ビジネスレベル」の輪があります。そして、このケースの場合は、アプリケーションと情報システム全体のビジネス特有のサービスを結合しているビジネスレベルのプロセスを実行するための短縮形です。

ルーティング対オーケストレーション ～ 「あるサイズが全てに適合」と「白か黒か」の世界、いずれでもない

さて、オーケストレーションの必要性が、ESBでどのように処理されるのでしょうか? ミドルウェアソリューションで提供されたオーケストレーションエンジンを利用することが道理にかなっているように思います。しかし、これは複雑な質問に対してあまりに単純な回答です。以下の例を見てみましょう。

品目一覧を表示する

「ItemManager」アプリケーションは、登録、更新、削除といったオペレーションで品目を管理するように設計されています。このアプリケーションは、「ItemManagementListener」サービスと接続していて、それは品目が更新されると通知をパブリッシュします。

もう一つのアプリケーションの「HammerMonitor」アプリケーションは、具体的にハンマーについて、品目の更新情報を表示するためのモニタリングツールです。このアプリケーションは、「HammerMonitor」サービスを公開しており、これらの通知を受ける「表示」オペレーションもあります。

両方のサービスは、ESB上で公開されています。私たちが欲しいものは、HammerMonitorに品目管理アプリケーションが知っているハンマーを表示させることです。

ItemManagementServiceをHammerMonitorServiceに接続するために、私たちはESBコネクタ（通称、「バインディングコンポーネント」）を構成する必要があります。1つのコネクタはItemManagerアプリケーションとリンクします。他のものは、 HammerMonitorアプリケーションとリンクします。

加えて、HammerMonitorアプリケーションにリンクしたコネクタは、ESBの中に、「hammerMonitorService」という名称のエンドポイントで公開されるように設定されます。このようにして、私たちの目的を達成するための単純な方法は、ItemManagerアプリケーションとリンクしたコネクタを構成することです。それは、ItemManagerアプリケーションからメッセージを受け取るときはいつでも、ESBの中でエンドポイント「hammerMonitorService」と呼ばれます。

しかし、通常、現実の世界では、たとえば両方のサービスが異なるデータフォーマットを持っていることがあります。SOAは疎結合のアーキテクチャなので、それはSOAに対する障壁ではありません。(つまり、サービスコンシューマがサービスプロバイダに合わせることは強制ではないということです)

ItemManagementアプリケーションは、以下のメッセージをItemManagementListenerServiceに提供します。

<items>
    <item type="Hammer" name="hammer1"/>
 </item> 

そして、ItemMonitorServiceは以下のフォーマットを使って、「表示」オペレーションをおこないます。

<hammers>
    <hammer hammerName="hammer1"/>
 </hammers>

この点で、単なる呼び出しは、両方のサービスをリンクするように機能しません。ItemManagementアプリケーションによって提供されたデータは、最初に変換される必要があるからです。実際、これはとてもシンプルで、ビジネスレベルとは無関係のオーケストレーションに必要な局所的なものです。

これを解決するための第一の方法は、完全に外部に配置されたBPELサポートのオーケストレーションエンジン([2]参照)のような、一般的によく知られたオーケストレーションのソリューションを利用することでしょう。これは機能しますが、この場合はクルミを割るためにハンマーを使う(意図的なしゃれです) のと同様なことだと思います。つまり、変換したすべてのメッセージが、一つの中心となるリモートのオーケストレーションエンジンを通す必要がある(ある意味では、旧式の「ハブ」統合アーキテクチャと同様です)のか、それぞれのノードに配置されたオーケストレーションエンジンでなければならないのかのどちらかになります。この単純な問題に対して、明らかにとても重厚なソリューションです。

そこで、オーケストレーションのニーズに対する単一でグローバルなビジネスレベルの答えは、十分でないように思えます。バスで提供された一般的なルーティングでは十分でなく、主な関心事が、SOAで管理されたビジネスサービスを操作することによるビジネスルールやプロセスの実行がいまだ行われていないということであるというときに、ルーティングとビジネスレベルの間でおこなう必要はありますが、単純に技術的に「舞台裏」のサービスを結合するのであれば、いわゆる「汚い」作業はどうでしょうか?

バスレベルの特定の開発アプローチ ～ インターセプター

技術的なルーティングとオーケストレーションのニーズに対する最も低いレベルでの答えが、ESBのビルトイン機能を強化するところにあります。

先の例の場合では、メッセージを送信するアプリケーションとそれを受信するアプリケーションの間でのデータの一貫性の問題を回避するための直接的な方法は、コネクタで若干のロジックを加えることでした(つまり、ESBのバインディングコンポーネントです)。

たとえば、PEtALS ESBによって提供されるバインディングコンポーネントは、「インターセプター」で拡張することができます。インターセプターは、メッセージが送られたときに、メッセージがバスに、あるいは、「レシーバー」コンポーネントで送られる前に、「センダー」のバインディングコンポーネントで実行されるJava コードです。

そうは言うものの、このアプローチは非常に限定的で、広範囲でありません。XSL変化が(HammerMonitorにリンクしている)「レシーバー」コネクタで実行される場合、受け取ったすべてのメッセージにItemMangementのXML構造があると仮定しています。メッセージがもう一つのアプリケーションから来るならば、それは異なる構造をもっているでしょう。そして、このケースの場合、XSL変化は失敗するでしょう。

インターセプターは、受け取ったメッセージ構造をチェックすることができ、メッセージによって、あるXSL変化または別のものを選ぶことができます。しかし、センダーとの強い結びつきがまだ残ったままです。このアプローチは、SOAの疎結合の概念に順守していません。さらに、別の変換が必要なときは、 ESBエンジンの中での特定の機能セットを別に開発することを暗示しています。それは、ESBユーザーは予期していることができないし、そうすべきではありません。

コンポーネント（「ビルディングブロック」）指向アプローチ ～ EIPツールセット

ESB は、インテグレーションコンポーネントを提供することによってインテグレーション機能を提供します。これらのコンポーネントは、コンシューマとサービスプロバイダの間で、小さく、有用で、柔軟な一連の操作をすることができます。それらは、一般的にいくつかのエンタープライズインテグレーションパターン (Gregor Hohpe氏によってよく知られるようになりました。[3]を参照)を実装し、ESBユーザーにとってのスイスのナイフのような万能さです。

サービスディスクリプタ(WSDLやその他)から独立して、これらのEIPコンポーネントは、単純に小さなことを実行します。最も知られているのは、以下のとおりです。

• 「pipe」パターン。一つのイベントが、一連の処理ステップを誘発します。そして、各々が特定の機能を実行します。EIPコンポーネントは、呼び出しを順序づけます。
• 「content based router」パターン。EIPコンポーネントがメッセージ内容を調べて、メッセージに含まれるデータに基づいた異なるチャネル上にメッセージを送ります。
• 「message dispatcher」パターン。EIPコンポーネントが、サービスプロバイダのリストにメッセージを送ります(マルチポイント)。
• 「scatter gather」パターン。EIPコンポーネントが、いくつかのサービスプロバイダにリクエストメッセージを送ります。そして、すべてのレスポンスを一つのレスポンスメッセージに集約します。

すべてのEIPコンポーネントのオペレーションに関する知識により、開発者がビジネスアプリケーション(コンシューマとサービスプロバイダ)をそれぞれの「インテグレーションパターンブリック」に結びつけることができます。最終結果は、コンポジットインテグレーションです。インテグレーションのそれぞれのブリックは、サービスです。

もちろん、このコンポジットインテグレーションを設計するためには、使いやすさに加えて、すべてのブリックの構成をまとめて見ることができることから、専用のグラフィカルなIDEが最高です。たとえば、以降のサンプルは、PEtALSのESBインテグレーションツールで設計されたものです。

パイプライン

pipelineパターンは、いくつかのサービスに受信したメッセージを「送信する」のに用いられます。メッセージは最初のものに送られ、そのレスポンスが次のものに送信され、そのレスポンスがその次へものに送信され・・・といった具合です。

コンシューマとサービスプロバイダ間の適合

私たちが先に説明したItemManagementの利用ケースでは、変換コンポーネントと「パイプ」ブリックといった、この種の組み立てで設計することができます。

サービスのバージョン展開の管理

以下のようにして、同じ振る舞いが、サービスのバージョン展開の管理に利用することができます。コンシューマは、常に「パイプ」ブリックに同じメッセージ構造を送信し、それが実際のサービスに対するプロキシとなります。サービスのシグネチャが変わったときは、「パイプ」ブリックが、まず初めに、(コンシューマのメッセージを新しいサービスのフォーマットに適合させるための)ＸＳＬ変換のメッセージをコンシューマに送信し、それをサービスの新しいバージョンに送信します。そして、コンシューマに対する変更は何もありません。

コンテンツベースルーティング

私たちは、いくつかのサービスを一つのものに構成するための方法について見てきました。しかし、動的なプロセスの側面は解決されていません。ここで再び、ルーティングの挑戦が訪れます。多くの間で一つのサービスを呼ぶにはどうしたら良いでしょうか?

多くのサービス間で一つのサービス呼び出しを切り替えるのはどうするのでしょうか? ルーターは、リクエストをあるバージョン、あるいは別のものに切り替えるために、いくらかの検査をおこなうかもしれません。

たとえば、ItemManagementListenerは、「コンテンツベースルーティング」コンポーネントによって、ハンマーやのこぎりに対する通知を送ることができます。このコンポーネントは、メッセージの中の品目名称を検査して、正しいモニタリングサービス (HammerMonitorServiceまたはSawMonitorService)にそれを送ります。各々のサービスが異なるフォーマットを定めていても、2つの異なる変換は、正しいサービスにメッセージを送る前に実行されなければなりません。そこで、私たちは「パイプ」と「トランスフォーメーション」で「ルーティング」を組み立てます。

ディスパッチャー

もう一つのインテグレーションの必要性は、複数のサービス(複数ポイントの通信)にリクエストを送ることです。たとえば、品目の注文がフロントアプリケーションから注文システムに送られるときに、確認のために、電子メールが顧客に送信することも可能です。たとえば、メッセージは注文サービスに、そして、 SMTPサービスに送られます。

私たちは、ItemManagementアプリケーションから通知を送信するItemManangementListenerサービスが、 HammerMonitorやSawMonitor、全体的なモニタリングツール(それは全ての通知を受信します)に通知をパブリッシュする必要があることを想像できるでしょう。

「ルーティング」や全体的なモニタリングサービスにメッセージを送信するために、「ディスパッチャー」のインテグレーションブリックが先のコンポジットインテグレーションに加えられます。

DSLベースのアプローチ ～ 軽量なオーケストレーターDSL

パターンが終わる所で、軽量なオーケストレーターが始まります

エンタープライズインテグレーションパターンは、ルーティングとオーケストレーションのソリューションを設計する助けとなる重要な概念です。そして、EIP コンポーネントは、実際に、これらの問題のソリューションを設計することを可能とする素晴らしいツールです。しかし、複雑なインテグレーションの場合、コンポジットを組み立てるアプローチは、散らばりすぎの設計しきれない構造に陥りやすいです。さらに、全てのパターン同様に、現実の世界がより柔軟なソリューションを必要とする予期しないケースで満たされているときは、EIのパターンでは限度があります。

その答えは、軽量なオーケストレーション特化DSL(ドメイン特定言語)を利用することです。それは、PEtALSで提供している「軽量なオーケストレーター」または「エンタープライズインテグレーションオーケストレーション」コンポーネントです。

そのようなコンポーネントを利用するための適切なタイミングはいつでしょうか? それは、開発の慣習を含む多くのものに依存しますが、ここではいくつかのヒントをあげます。

• 私たちがちょうど今言ったように、ただ素直に「本による」パターンを使用したソリューションを想像するのが難しいとき。
• 先に述べたもののように、「ルーティング」と多重化パターンが普通になっているとき(これも、ルールエンジンコンポーネントを使用する兆しです)。
• ＥＩＰベースのシステムに組み込まれた「ブリック」の層がたくさんあるとき。
• 単純ではあるが、いくつかのEIP「ブリック」全体で散らばっているよりも、一つの場所で解決したい場合で、オーケストレーションサブシステムが最も理解され、支持されるとき。
• EIPコンポーネントでサポートされないような、より珍しいEIパターンが必要なとき(完全に動的なルーティング、リターンアドレス、コンテンツエンリッチャー、ノーマライザ、など)。

EIオーケストレーションの利用ケース ～ 複雑な動的ルーティング

EIオーケストレーションコンポーネントを紹介するために、私たちのシステムの拡張性にフォーカスしましょう。

私たちは、初めはハンマーを扱うことだけが可能だったシステムに、のこぎり特有のモニタリング機能を追加する方法を見てきました。私たちは、同じ方法で他のツール特有な機能を追加することができました。しかし、もう一つのツールタイプを加えたいと思うたびに、再度、それらを再設定する必要があります。そこで、ある人たちが、彼ら自身のツールタイプと特定のモニタリング機能を加えることができる私たちのバスを利用できるようにしたいと思うならばどうなるでしょうか?

例：私たちの顧客は、スクリュードライバーのツールタイプのためにScrewdriverMonitorServiceを、穴あけ機のためにDrillerMonitorServiceを、などと動的な追加ができることを望んでいます。

私たちは、各々のメッセージの範囲内で、送信されなければならないツール特有のモニターサービスの名称を顧客に言うことができます。そして、私たちのシステムに動的なルーティング機能を追加します。

例：以下のメッセージボディをItemManagementListenerServiceに提供するために、私たちはItemManagementアプリケーションを拡張します。

<items>
    <item type="Screwdriver" name="screwdriver1"
          customMonitorService="ScrewdriverMonitorService"/>
 </item> 

customMonitorServiceは、追加のデータフィールドで、ItemManagementアプリケーションを通じて顧客によって提供されるでしょう。

ESB では、そのようなメッセージのルーティングは、「customMonitorService」のアトリビュートで受信サービスを動的に選択することによっておこなわれることができます。たとえば、これは、「get-calls-by-xpath」機能を利用し、EIオーケストレーションコンポーネントを使用しているPEtALSでおこなうことができます。

<eip:get-calls-by-xpath base="/items/item" service="@customMonitorService"
       operation="'display'"/>

私たちの例では、前のメッセージでScrewdriverMonitorServiceを呼ぶでしょう。

PEtALSによる完全なEIオーケストレーションのサンプル

私たちが初めに述べたように、PEtALSのEIオーケストレーションコンポーネントは、複雑なプロセスを十分に操作することができます。そこで、私たちが本稿で見た、単一の構成すべてを集めたのが、以下の例です。パイプ("eip:chain"要素)、変換、単純なコンテンツベースルーティング ("eip:choose"要素)、最後に、動的ルーティング("eip:get-calls-by-xpath"要素)があります。いろいろある割には、とても読みやすいです。

<eip:eip>
    <eip:chain>
       <eip:choose>
          <eip:when test="/items/item[0]/@type = 'Hammer'">
             <eip:call service="ItemToHammerService" operation="transform"/>
             <eip:call service="HammerMonitorService" operation="display"/>
          </eip:when>
          <eip:when test="/items/item[0]/@type = 'Saw'">
             <eip:call service="ItemToSawService" operation="transform"/>
             <eip:call service="SawMonitorService" operation="display"/>
          </eip:when>
          <eip:otherwise>
             <eip:get-calls-by-xpath base="/items/item"
                   service="@customMonitorService" operation="'display'"/>
          </eip:otherwise>
       </eip:choose>
    </eip:chain>
 </eip:eip>

 

ビジネスプロセスマネジメントの概念への橋渡し

そして、成熟したビジネスレベルのオーケストレーションはどうか？

インテグレーションの上のもう一つの考え方はトップダウンアプローチです。そこでは、エンタープライズビジネスプロセスが定義されています。このアプローチでは、ビジネスプロセスがビジネスサービスの定義を扱います。それ故、何のサービスが既存のアプリケーションで提供されているかと、何のビジネスプロセスがオーケストレーションをしたいのかということの間に、ブリッジが必要となります。そのようなブリッジは、企業情報システム内で管理された、全てのビジネスレベルのサービスのセットで明らかにされます。つまり、そのSOA(サービス指向アーキテクチャ)は、低レベルのバス上の技術的なサービスと実際のビジネスプロセスの両方を保護するレイヤーとして機能します。

SOA の世界でプロセスを実行する標準的な方法は、BPELエンジン(［2］参照)の使用です。それは、複数のサービスを呼び出すことができ、フロー上で、そしてXMLドキュメント上であるビジネスロジックを処理することができます。さらに、データマッピングの問題も処理することができます。このアプローチでは、ビジネスサービス定義がオーケストレーションの鍵となります。すべてのサービス定義(一般的にはWSDL)なしでBPELオーケストレーションが可能となるわけでなく、よりきれいな(しかし、より高価な)サービスコンポジションを保障します。

ESBでBPELを使用する際のオーケストレーションのセットアップに関する概要は、Adrien LOUISが書いた記事、「既存サービスからSOAアプリケーションを構築する」([4]参照)が有効です。

ビジネスプロセスへの人間の介入 ～ ワークフロー

さて、私たちのモニタリングツールの例で、モニタリングアプリケーションに、実際に情報を表示する前に統括者の承認が必要だった場合はどうなるでしょうか? 専任のオペレータによる手入力の介入が必要になるでしょう。これが、ビジネスプロセスマネジメントのもう一つの側面です。それは、ワークフローで、ビジネスポータルで提供されるであろうグラフィカルなユーザーインターフェース、あるいはより技術的な管理インターフェースを通して、手作業のビジネスタスクであれ、手動の管理であれ、手作業や人のオペレーションが関与することを許容するビジネスプロセスです。

重要なポイントは、ワークフローが、BPELオーケストレーターのようなフローベースのものというよりはむしろ、ステートベースのアプローチの逆のパラダイムに従うということです。オーケストレートされたサービスの上にいることを制限されることなしに、それらが長く生存するプロセスに適するようにします。したがって、ワークフローサーバーは、「きちんとした」オーケストレーターによって有効に補完されますが、それは2つのビジネスプロセス指向のサーバーを配備することを意味します。それについては、jBossとBullの「プロセスバーチャルマシン」やEclipseのJavaワークフローツールプロジェクト([5]参照)のような、興味深い新しいイニシアチブによって、制約の解決に取り組んでいます。

結論

私たちは、本稿でビジネスサービスを互いにつなぐためのいくつかの方法や、カスタマイズしたルーティングのような低レベルのものから、ワークフローやオーケストレーションのようなビジネス指向のアプローチを利用した高レベルのものまで見てきました。最も重要なのは、ESBインテグレーターが、ローカルな技術的なサービスを構成するためのとても一般的な中間レベルのニーズを持つ方法や、「グルー(糊)」、「スイスナイフ」のような機能により、それらが簡単に「きちんと仕事をする」ことができる方法を私たちが公開したことです。

要約すると以下のとおりです。

• 2 つの異種環境にあるアプリケーション間の接続のような、単純なインテグレーションのシナリオの範疇に対しては、ESB特有の機能によるルーティングのカスタマイズ(たとえば、アプリケーションにリンクしたコネクタでXSL変換を追加することにより、メッセージデータフォーマットに適合する)が、実際には最も簡単な方法です(インターセプターアプローチ)。
• 適切なレシーバーにメッセージを送るために戦略が必要なとき、そして、メッセージのオペレーションが連鎖する必要があるとき、私たちは、静的なルーティングを行うための一般的なパターン指向のインテグレーションブリックや、変換で連鎖したものと、単純な組み立てを利用することができます(EIPアプローチ)。
• 複雑なルーティング戦略を解決するために、動的ルーティングや複雑なインブリケーションからなる軽量なオーケストレーションコンポーネントが、ルーティングロジックを中心に集めるのに利用することができます。(軽量オーケストレーターアプローチ)
• 全体的な、ビジネスレベルで、しっかりと管理され、一貫して定義されたビジネス指向サービスでは、WSDLベースのBPELのようなオーケストレーションの利用を構成するのは努力する価値のあることで、ワークフローソリューションを利用している人たちと関係を持ちます。

著者

Adrien Louis は、EBM WebSourcingとSOAコンサルタントで、PEtALS ESBのチーフプロダクトアーキテクトです。Adrienは、Java EE技術、情報システム統合で8年間仕事をしています。

Marc Dutoo は、フランスのオープンソースのポータルインテグレーターを率いるOpen Wideで、オープンソースのソリューションアーキテクトをしています。彼の関心は、SOA、BPM、コンテンツマネジメントです。Marcは、 EclipseのJavaワークフローツールプロジェクトのリーダーの一人です。

情報源

• [1] PEtALS(リンク)は、 OW2のESBです。PEtALSは、SOAをサポートするための優れた主要なオープンソースESBを提供します。それは、A2AとB2B両方のインテグレーションに対して、軽量で、高度に分散され、スケーラブルなプラットフォームです。その特有の分散アーキテクチャとツールの提供に感謝します。 PEtALSは、多数のプロトコルやフォーマットのサポートやインテグレーション機能によって、非常に優位性のあるインテグレーションソリューションを提供します。
• [2] OW2 PEtALS ESBが提供するBull/OW2 Orchestraなど
• [3] Gregor Hohpeのエンタープライズインテグレーションパターン(リンク)
• [4] SOAとESBの導入 : 「既存のサーバーからSOAアプリケーションを構築する」(リンク) (Adrien Louis) 
• [5] オーケストレーションとワークフローを統一する : プロセスバーチャルマシン(リンク) (Tom BaeyensとMiguel Valdes Faura)と、EclipseのJavaワークフローツールプロジェクト (リンク)
• 基本に返り、スクラッチからのESB(リンク) (「ルーティング、トランスフォーメーション、トランスポート、セキュリティ」)(Balwinder Sodhi)
• 溝からコンポジットサービスを構築する(リンク) （Jesus Rodriguez）。「しかし、コンポジットサービスを構築することは、市場の中での大部分のESBに対する挑戦を意味しています。これは、主に、大部分のESBが、ルーティングロジックを他のアプリケーションによって利用可能な新しいサービスで表現するための変換方法を提供していないという事実を与えています。代わりに、開発者はESBエンジンに組み込まれているルーティング機能を活用する裏側のサービスを自身が実装しようとしていることに気づきます。」

原文はこちらです：http://www.infoq.com/articles/louis-dutoo-esb-routing
（このArticleは2008年7月2日に原文が掲載されました）