Mule ESB は非同期メッセージングの並行処理

Mule ESB を、実際に使い始めているけど、なかなか、発想の転換が難しい、というのが実感。

inbound（受信) -> サービスコンポーネント -> outbound(送信)

という単純な仕組みを 連結していくだけなんだけどなあ。

手続き的に書きたくなる【アンチパターン】

最初の頃、ひっかかったのは、「手続き的」に設計する、アンチパターン。

個別のメッセージの処理、というより、「メッセージの集合」から、一件ずつ、順番に取り出しながら、処理していく、というバッチ処理の発想から抜け出せない。

並行処理

いま、苦戦しているのが、並行処理。
Mule ESB は、デフォルトで、

inbound したあとのメッセージ処理　４つのスレッドで並列処理
サービスコンポーネントの活性化　４つのスレッドで並列処理
outbound ４つのスレッドで並列処理

という方式になっている。

メッセージの到着順と、処理の順番、前後関係は、なにも保証されてない。
これを、前提とした、設計の頭になかなかきりかわらない。

あと、データベースへのコネクションが並列して発生するとか、わかってしまえば、あたりまえなんだけど、直感的には、単独の処理プロセスのイメージからヌケきれず、かなりつまづいている。

Mule ESB 自体は、かなり、軽量で、高トラフィックのメッセージ処理ができる手ごたえがある。
ところが、大量のメッセージを高速に並列処理できる Mule ESB のよさが、データベースアクセス、ファイルの読み書き、SMTP でのメール送受信とかがからんでくると、とたんに性能問題、容量問題、データや処理の一貫性問題にぶつかる。

現場で格闘しながら、必死に勉強中です。
サンプルプログラムみたいに、動いたら、おしまい、というわけにはいかない。