EIP / Message Endpoint

メッセージエンドポイント（Message Endpoint） †

サマリ †

アプリケーションがをメッセージチャネルに接続するには、メッセージエンドポイント＝メッセージングシステムのクライアント、を作りましょう。

詳細 †

• アプリケーションは、Message Channelを介してMessageを送ることでお互いに通信している。

メッセージを送受信するために、アプリケーションをどうやってメッセージチャネルに接続するか？

• アプリケーションとメッセージングシステムは別物。アプリケーションはユーザに何らかの機能を提供するのに対して、メッセージングシステムはメッセージチャネルを管理してメッセージを転送するのが目的。
  • メッセージングシステムはDBMSやWebサーバのようなもの。
• メッセージングシステムはある種のサーバ（メッセージングサーバ）。
• クライアントは、APIを用いてメッセージングサーバと通信する（DBサーバと同様）。APIはアプリケーション固有でなく（メッセージング）ドメイン固有なもので、アプリケーションにはメッセージングドメインをアプリケーションに結合するコードが必要になる。

メッセージエンドポイント（Message Endpoint）＝メッセージングシステムのクライアントを用いてアプリケーションをメッセージチャネルと接続しましょう。

• メッセージエンドポイントは、アプリケーションからしてもメッセージングシステムのAPIからしてもカスタムのコード。アプリケーションはメッセージエンドポイントとだけやり取りし、メッセージエンドポイント内部でAPIを介してメッセージチャネルからメッセージの送受信をを行う。
• メッセージエンドポイントは、アプリケーションに対してメッセージングシステムをカプセル化する。APIを差し替えたりバージョンアップしてもメッセージエンドポイントがすべての影響を吸収する。理想的には、メッセージングから他の統合パターンに切り替えてもアプリケーションには影響が無いようにする。
• 1つのメッセージエンドポイントは送信／受信どちらか一方に専用で、両方同時にはできない。エンドポイントは1つのチャネルだけに対応するので、複数のチャネルにアクセスするには複数のエンドポイントを用意する。逆に、マルチスレッドなどで1つのチャネルに複数のエンドポイントインスタンスを使ってアクセスしてもよい。

他のパターンとの関係 †

• メッセージエンドポイントはChannel Adapterの一種で、アプリケーション専用に作られて組み込まれたアダプタ。
• メッセージエンドポイントはMessaging Gatewayとして設計すべきもの（＝メッセージングをカプセル化しろ）。ドメインオブジェクトからメッセージへの変換にMessaging Mapperを使ってもよい。同期型のサービスや関数を非同期的にアクセスするのにService Activatorを用いてもよい。トランザクション管理のためにTransactional Clientを用いてもよい。
• 送信より受信の方が複雑なので、そっち向けの関連パターンが多い。Polling ConsumerとEvent-Driven Consumerのどちらにするか。同一チャネルの同時受信にCompeting Consumersを使うかMessage Dispatcherを使うか。受信メッセージの選別にはSelective Consumerが使える。エンドポイント切断中もメッセージ受信を逃さないようにするにはDurable Subscriberを使う。重複メッセージの受信が嫌ならIdempotent Receiverを使う。

例: JMSのProducerとConsumer †

• JMSでは送信にMessageProducer?、受信にMessageConsumer?のクラスがある。メッセージエンドポイントの実装には、このどちらかを使う。

例: .NETのMessageQueue †

• .NETではエンドポイントのクラスはMessage Channelと同じでMessageQueue。メッセージエンドポイントの実装には、送信・受信どちらもこのクラスを使う。

担当者のつぶやき †

• Message Endpointパターンは、DDDのAnti-Corruption Layerパターンに対応すると考えるときれいかも。
• このパターンの理解には、どちらの視点（アプリケーション or MOM）から見たパターンなのかという点が重要に思う。