EIP/Service Activator - Java EE勉強会

Service Activator †

アプリケーションの中で、サービスを様々なメッセージング技術からも非メッセージング技術からも呼び出せるようにするにはどう設計すべきか？

アプリケーションでは、サービスを同期型／非同期型のどちらで呼び出せるかを限定したくないこともあるが、技術の選択次第では強制的にどちらかにせざるをえないこともある。
- 例えば、EJBセッションビーンは同期型、MDBは非同期型を強制される。
B2Bアプリケーションのように他のアプリケーションと連携するアプリケーションでは、そもそもどんなクライアント／通信技術で連携があるかを把握していないこともある。全てのメッセージング技術やデータ形式に予め対応するのは非現実的。
メッセージの受信と処理にはいくつかのステップがあり、再利用性の高いMessage Endpointコードを作るにはどのステップを分離するかが重要。
複数の通信方式をサポートするために方式毎にサービスを再実装するのはイマイチ。1つのサービスが複数の通信方式をサポートするような設計が必要。

Service Activatorを導入して、チャネル上のメッセージをアクセスしようとしているサービスに接続する。

Service Activatorはone-wayでもtwo-way（Request-Reply）でもよい。サービス自体は、PofEAAのService Layerパターンのようなシンプルなメソッド呼び出しでもよく、ハードコーディングされた呼び出し方でもリフレクションを使った方法でもよい。Service Activatorがメッセージングに関する一切の複雑さを吸収する。
まずService Activatorがリクエストメッセージを受信して、サービスを呼び出し、その実行が完了するまでブロックする。結果を受け取り、two-wayだったらリプライメッセージをクライアントへ返す。
Service Activatorが非同期の処理を全てやるので、サービスは同期呼び出しを前提にした設計で実装するだけでよい。
Service Activatorが処理できなかったメッセージは無効（invalid）なメッセージという扱いになるので、Invalid Message Channelへ転送する。サービス実行まで行って起こったエラーはセマンティックなエラーなので、アプリケーション側で処理すべきである。
開発者は、パートナーが採用したいサービスへの通信方法を全て予測することはできないが、まずはサービスを実装して、新たな通信方式が必要になったら都度Service Activatorを追加してゆけばよい。

このパターンは、Core J2EEパターンのService Activatorから採用した。J2EEパターンの方はEvent-Driven Consumerが前提になっているという違いはあるが、基本は同じ問題と解法を扱っている。このパターンはPOSA2のHalf-Sync/Half-Asyncパターンとも関連がある。
Service Activatorは通常Command Messageを受け取り、Messaging Gatewayになる。Service ActivatorはPolling ConsumerでもEvent-Driven Consumerでもよい。トランザクションを管理するなら、Transactional Clientになる。複数のService ActivatorはCompeting Consumersになっても、Message Dispatcherで制御されてもよい。無効なメッセージは、Invalid Message Channelへ。

一瞬、J2EEのService Locatorパターンと混同した。J2EEパターンでService Activatorなんてほとんど注目してなかった・・・
このパターンも、ある意味、Message Bus + Message Broker + Canonical Data Modelに加えて、今のESBの形を定義したパターンの1つなのかもしれない。