高スケーラブル、高パフォーマンスなアプリケーションを実現するための分散非同期型のアーキテクチャスタイル

適応性に優れる (小規模から大規模まで)

メッセージキューによる複数のシステムの統合

2 つのパターン

Broker パターン

本質は非同期通信

テストが難しい

中心の調整役がいないため、協調やエラーハンドリングが難しい

軽量メッセージブローカー (RabbitMQ、ActiveMQ、HornetQ など) を介してブロードキャスト方式でイベント処理

構成部品が高度に疎結合になっているので、非常に進化しやすいパターン

Mediator パターン

調整役の振る舞いをするハブとなる追加のコンポーネントが存在 (イベントメディエーター)

処理するイベントの性質や複雑さに応じて様々な方法で実装可能

単純なものであれば Apache Camel、Mule ESB、Spring Integration などで十分

複雑なものだと、Apache ODE や Oracle BPEL Process Manager といったものが選択肢に

Business Processing Execution Language (BPEL) に基づく

BPEL では途中に人の手が介在するものを扱いづらい

その場合には jBPM などのビジネスプロセスマネジメント (BPM) エンジンが必要

多くの場合は、様々な複雑さのイベントが混ざっている

常に単純なイベントメディエーターを経由するようにして、複雑なイベントは別のイベントメディエーターに委譲する手がおすすめ

エラー処理が難しい

ワークフローイベントパターンで対処

データロスが最大の懸念事項

軽減策

永続的なメッセージキューへの同期送信 (保証された配送)

メッセージキューからイベントを取り出した後にイベントプロセッサが落ちる問題 → クライアント応答モードで対応

キューからメッセージを消すのではなく、クライアント ID をメッセージに付けることで他のクライアントが読めないように

参考文献