Route

Route

   Routeステップは、メッセージの内容からどのサービス（サービス実装）を呼び出すかを決定する。

   これは、ネットワークのルーティング処理が送信先のIPアドレスからどのネットワーク先かを判定して物理的な送り先を決定しているのと同様で、Routeステップもメッセージの中身からどのサービスを呼び出すのかを決定する。

   このようにメッセージの中身に基づいてルーティングすることをCBR（Content Based Routing）と呼ぶ。例えば、ESBの物理的配置が異なる場合の転送や同じような内容を抽象化して複数の実装を持つ場合などは、Routeステップで 処理すべきサービスを決定させる。

Operate

   Operateステップは、メッセージ／エンドポイント／Routeステップによって決定されたサービスの実装を呼び出すステップである。呼び出す サービスは、ESBにデプロイされたサービス／外部のWebサービス、他のESBにデプロイされたサービス、外部リソースにアクセスするアダプタなどがあ げられる。

ESBのアーキテクチャ

   以上説明してきたステップの組合せによって、ESBのサービス（メディエータしたサービス）は成り立っている。では、ESB全体のアーキテクチャがどのようになっているかというと、図1のようになっている。

図1：ESBのアーキテクチャ
（画像をクリックすると別ウィンドウに拡大図を表示します）

   複数のトランスポートを経由してエンドポイントに到着したリクエストは、ESBの内部構造に適した形式に変換された後、設定されているフィルタを実行する。

   例えばセキュリティ機能などが実行され、次にエンドポイントに対応したメディエータにリクエストが渡される。するとメディエータは定義されたサービス（VETROなど）を実行する。

   外部を呼び出すアダプタには、レガシーシステムを構成するホストやSAP R/3に代表されるERP、他のRDBMSなどを接続ができるものがあるので、これらを利用してレガシーシステムとの連携を取ることが可能である。もちろ ん外部リソースとの連携が複雑な場合はサービスとして別に実装する必要はあろう。

ESBを用いたシステムイメージ

   ESBを用いたシステムのイメージがどのようなものかをあらわすと以下の図のようになるのが一般的だ。

図2：ESBを用いたシステムイメージ

   ESBのクライアントとしては、WebアプリケーションやJavaアプリケーションを用いることができる。また、WebアプリケーションとESBの インタフェースはSOAPを利用することもJMSを利用することもできる。JMSを選択した場合は、WebアプリケーションがJMSクライアントとして振 舞うことになる。

   このようなシステム形状では、ESBクライアントでビジネスロジックをどの程度実装すべきかを考えることが重要になる。これはサービスとアプリケーションの違いを考えることに等しい。

   アプリケーションはユーザの要望によって定義される要件を実現するが、サービスは各ユーザの要望というよりも組織が持つ資産／内部統制ルール／蓄積 すべき情報によって定義される要件を実現する。これらの違いを意識してESBクライアント（Webアプリケーション）に配置するビジネスロジックを決定す る必要がある。