arclamp.jp アークランプ

　いよいよデモアプリケーションの説明です（デモのダウンロードはServiceMix (1) JBIとServiceMix から）。

　ServiceMix (2) デモアプリケーション概要の「ServiceMix内の概要」に描いた図を、もう一度載せます（クリックで拡大）。

　デモでは2つのSeriviceMixが起動しています。ここではメインになる画面を表示する側（左側）のServiceMixを見て行きます。設定ファイルであるservicemix.xmlは、src\webapp\WEB-INF\servicemix.xmlです。

　servicemix上の流れを見るためには、要素sm:activationSpecの属性destinationServiceに定義されたサービス名を見ていけばよいことになります。

httpBinding（HTTPのリクエストをJBIに流し込むためのBC）
受け取ったら、そのままfoo:asyncForwarderに流します。

asyncForwarder（HTTPの同期メッセージを非同期に切り替える）
foo:findAggregatorに対して非同期でメッセージを送ります。foo:httpBindingからは同期処理で呼ばれているので、帰りの処理はメッセージに返信すれば自然に戻っていきます。

findAggregator（指定されたサービスを同時・非同期に呼び出し、結果を集積する）
　ここではtargetsに指定されたInfoProvider達に情報を非同期に同時実行するため、順次、実行結果が戻ってきます。その数を数えて、全て集まったら結果を１つのXMLファイルにして戻します。そのためdestinationServiceとは戻り先であるfoo:asyncForwarderになります。

provider1（実際のプロバイダ）
　それぞれのInfoProviderは、処理後foo:findAggregatorに戻ります。

exProvider（別サーバ・インスタンスのInfoProviderを呼び出す）
　これも戻り先自体はfoo:findAggregatorです。

　というわけで、非常に直感的ではないでしょうか。もちろん単純だからということもありますが、コンポーネントのフローがよく分かります。

　つまり、このデモアプリケーションというのは、ServiceMixによってコンポーネントとメッセージ交換で組み上げられたものなわけです。しかも、その組み合わせ方が「同期で呼ばれていたものを、内部的には非同期同時でビジネスロジックを処理する」という、それなりに複雑なものです。
　そのためにInfoProvider以外はビジネスロジックではなくコントロールとして機能しています。asyncForwarderは同期・非同期の切り替えであり、findAggregatorは非同期実行と実行結果の集約というコントロールなのです。
　「こんなに組み合わせるなんてめんどうだなぁ」と感じられるかもしれません。しかし、このようにロジックとコントロールが明確に分離されることで、アプリケーションとして変化に適応できる可能性があることに気づきます。BCを変更すればJMSやWebサービスからも呼び出し可能でしょうし、findAgregatorの機能を上げればタイムアウトなども実現することもできます。もちろんビジネスロジックであるInfoProviderを変更する必要性はありません。

　なお、こういったアイデアはEAIやBPM（ビジネス・プロセス・マネージメント）と変わるないように感じるかもしれません。しかし、これまでのEIAやBPMはIFなどの単純な処理しかできなかったのに比べると、BPELやJBIはそのよりも遥かに細かい上の処理が可能になります（思い出してください。BPELはBusiness Process Execution Language for Web Servicesの略です）。

　ここで感じていただきたいのは、ServiceMixが実現しているものが、きっと皆さんが思うSOAとは一線を画しているということです。ServiceMixによってSOAの本質である「メッセージ交換による疎結合」というのがDIコンテナに持ち込まれました。その結果、SOA的アプローチは普通のアプリケーションの構築においても十分に利用可能になったわけです。
　僕はこれを「コンテナベース・サービス・インテグレーション」と呼んでみたわけですが「コンテナベース・コンポーネント・リミックス（マッシュアップ）」という感じの方が正確かもしれません（IBMやBEAを主導にSCA（サービス・コンポーネント・アーキテクチャ）という取り組みもはじまっているのですが、その話は別の機会に）。

　丸山先生はこのservicemix.xmlを見て

- ただ、ServiceMixのXbeanの記述を見ていると、DIコンテナの単なるコンフィグ・ファイルとして以上の意味を、それが潜在的に持っていることに気づく。

- それが表現しているものを、単なるInjectされるべきオブジェクトの宣言としてではなく、ネットワーク上の複数のコンポーネントの結合の青写真を与えるものと考えると面白い。

- Grid風に言えば、それはVirtual Organizationの見取り図を与えているのである。

- BPELも似たような特徴をもつのだが、我々は、ネットワーク上のサービスをプログラムする、新しいメタ・プログラム言語が誕生する時代の入り口に立っているのかもしれない。

と指摘されています。若干、大げさだとは思いますが意図している感覚は伝わるのではないでしょうか。

　で、なんか結論らしいものがないのですが、僕もはっきりといえるほどに使い込んでいないのが現状です。ただ、こうした手法を業務アプリケーションに組み込んでいくことで、ロジックとコントロールの分離が明確になり、よりアプリケーションの構造が柔軟になることは間違いないと思います（と、信じたいｗ）。
　来年は、こうした考え方（もはやSOAという印象からは離れているかもしれませんが）によるアプリケーション構築が大きな課題になることでしょう。
　EIA的なSOAに取り組み必要性はまったくないのですが、こういう小さなSOAには、どんどん手を出していただきたいと思うわけです（安いし、手の届く範囲でできるし）。

　では、次回は視点を変えてInfoProviderの仕組みを見てみます。これによって、現状のServiceMixの課題が見えてくるはずです。

このServiceMix連載の一覧