EIP / Ch10 Introduction

Ch10 Introduction †

ひとこと要約 †

エンドポイントのざっくり紹介。

要約 †

アプリケーションがメッセージの送受信を行うのに、どのようにメッセージングシステムとつながるのかは3章のMessage Endpointで触れたよね。

• メッセージングのAPIを使ってエンドポイントのコードを書いたり。

• 商用のミドルウェアパッケージで提供されてるツールを使えばこの辺りはほとんど書かなくてすむことも。

Send and Receive Patterns †

送信者と受信者の双方に適用出来るパターン。

• アプリケーションがメッセージングシステムとどのように関連するか、についてのもの。

• Encapslate the messaging code

• アプリケーションは他との統合で、どのようにMessagingを使ってるかは意識しないもの。

• なのでアプリケーションを統合するときには、コードの薄いレイヤーがあるべき。

• その薄いレイヤーでメッセージングシステムとつながっているなら、それがMessaging Gateway。

• Data translation

• 送受信で同じデータフォーマットでやりとりしてるなら最高だけど、ほとんどそうはうまくいかない。

• そんな時にはMessaging Mapperでコンバート。

• Externally controlled transactions

• デフォルトでは、送信や受信はそれだけでトランザクションが閉じてる。

• 複数のメッセージを一緒に扱ったり、他のトランザクショナルなサービスとやり取りしたいときには、Transactional Client。

Message Consumer Patterns †

メッセージの送ることは、メッセージを作りさえすればあとは簡単。

• 一方、受け取るほうはいろいろと大変なので、受け取る側のパターンが色いろある。

この本の導入部で触れたサーバー側の潜在的な問題は、リクエストの量によってサーバーに負荷がかかってしまう、というもの。

• でもメッセージングシステムなら、Message Channelのキューによって適度なペースでさばいていける。

多くのMessage consumer patternsは、代替案として対になっている。

• 単一のアプリケーションは代替案が混在したエンドポイントを持てるが、単一のエンドポイントはどれか1つの案しか実装できない。

• Synchronous or asynchronous consumer

• Polling Consumerは、サーバーが忙しければメッセージの有無を問い合わせることはしないので、メッセージの消費を抑えるにはもってこい。

• Event-Driven Consumerは届いたものはできるだけ早く処理されるが、一つのコンシューマーは一度に一つのメッセージしか扱わないので、コンシューマーの数に制限をかけることでメッセージの消費を抑えられる。

• Message assignment versus message grab

• Point-to-Point Channelが複数のコンシューマを持つ場合、Competing Consumersが最も簡単。

• メッセージとそのコンシューマのマッチングを扱いたいなら、Message Dispatcher。

• Accept all messages or filter

• ある特定のメッセージだけを処理したい時はSelective Consumer。

• Subscribe while disconnected

• Publish-Subscribe Channelで、サブスクライバーのネットワークが切れてたりメンテナンスでシャットダウンしていた時の再送は？

• 普通は非接続時のメッセージは受け取れないもの。

• Durable Subscriberを使ってそういう状況に対処することもできる。

• Idempotency（冪等性）

• 同じメッセージを複数回受け取っても一度だけ処理したいなら、Idempotent Receiver

• Synchronous or asynchronous service

• クライアントによって同期と非同期のどちらを望むかが違ったりすることもある。

• Service Activatorは同期的なサービスとMessage Channelでつながり、メッセージを受け取ったらサービスを呼び出す。

• クライアントは同期的にサービスを利用したいなら直接呼び出し、非同期的にサービスを利用したいならメッセージを送る。

Message Endpoint Themes †

もう一つのこの章のテーマは、Transactional Clientを他のパターンと一緒に使うことの難しさについて。

• Event-Driven Consumerはトランザクションを外側からは制御できない。

• Message Dispatcherは気をつけて設計されるべき。

• 外部からトランザクションを管理するCompeting Consumersは致命的な問題に陥ることも。

• Transactional Clientを使う時に最も安全なのは、単一のPolling Consumerと合わせること。

• とはいっても満足の行く解決策とはいえない。

特記事項として、EJBの一種である、JMS形式のMDB(message-driven beans)に触れる。

• MDBは、Event-Driven Consumerと、J2EEの分散トランザクションをサポートしたTransactional Clientに相当するもの。

• Competing Consumersとして動的にプールされる。

• WebLogic?やWebSphere?といったEJBのコンテナで提供されている。

• コンテナはMessage Dispatcherとして実装されている。

単一のMessage Endpointに異なるパターンを組み合わせられるのを見てきた。

• Competing Consumersのグループは、Selective ConsumerでもありアプリケーションのサービスのService Activatorとしても振る舞うPolling Consumerとして実装されるかもしれない。

• Message Dispatcherは、Messaging Mapperを使用するEvent-Driven ConsumerとDurable Subscriberであるかもしれない。

• 一つのパターンだけではなく、組み合わせを考えること。

• パターンを紡いで問題を解決する美しさがそこにあるのだ。

この章では、どのような選択肢があり、どのように使うのがベストなのかを説明していく。

担当者のつぶやき †