導入 †
- 重要なシステムは単独で動くことはなく、他のアプリケーションと統合して選りすぐれたものとなる。
- あらゆる統合には本質的な課題がある
- ネットワークは信頼できない：ネットワークを通じて他のコンピュータとデータのやりとりをしなければならないが、電話線やLAN、ルーター、スイッチ、公共ネットワーク、衛星リンクといった各ステップで遅延や妨害が発生する。
- ネットワークが遅い：ローカルメソッドコールに比べると、スピードのオーダーがまったく違う。
- アプリケーションはひとつとして同じものがない：情報がやりとりされるアプリケーションは、プログラミング言語、OS、データ形式などが違うかもしれないのに、こうした別々の技術とインターフェイスしなければならない。
- 変更が避けられない：アプリケーションは変化するものであり、統合ソリューションはつながっているアプリケーションと歩調を合わせなければならない。あるアプリケーションの変更の影響が他にも派生するため、疎結合によって影響を最小化することが重要。
- 主なアプローチは四つある。
- ファイル転送（43）：一方のアプリケーションがファイルを書き、別のアプリケーションが読む。ファイル名や場所、フォーマットや書いたり消したりするタイミングなどについて合意が必要。
- データベースの共有（47）：複数のアプリケーションが、物理的に一ヶ所に置かれたデータベーススキーマを共有する。
- リモートプロシージャ呼び出し（50）：あるアプリケーションが他のアプリケーションから使えるように機能を公開する。やりとりはリアルタムかつ同期で行われる。
- メッセージング（53）：あるアプリケーションがメッセージを共通のメッセージチャンネルに公開する。別のアプリケーションが後からそのメッセージを読み込むことができる。やりとりは非同期。
- どのアプローチが解決する問題も本質的には同じだが、それぞれ個別の長所／短所がある。実際には状況に応じて最適なものを組み合わせて使う。
メッセージングとは何か？ †
- 本書はアプリケーションを統合する上でメッセージングを使う方法を扱う。メッセージングとは何かを理解するには電話システムを考えればよい。
- 電話をして相手が出れば話ができる
- 留守番電話のおかげで非同期コミュニケーションができる：送り手がメッセージを残し、受け手が後でメッセージを聞く。
- メッセージングは高速、非同期なプログラミング同士のやりとりを安心して行うための技術である。
- メッセージと呼ばれるデータパケットを送り合う
- チャネルもしくはキューを通ってメッセージが伝達される。チャネルはメッセージの配列のようにふるまうが、複数のアプリケーションで共有できる
- 送り手（sender）あるいは供給者（producer）とはチャネルにメッセージを書き込むことでメッセージを送信するプログラム。
- 受け手（receiver）あるいは消費者（concumer）とは、チャネルを読むことでメッセージを受け取るプログラム
- メッセージ自体はある種のデータ構造で、データとして解釈できる。メッセージの中身はふたつにわかれる。
- ヘッダー（header）：メッセージに関するメタ情報。送り手や宛先など。メッセージングシステムが使い、アプリケーションは無視する。
- 本文（body）：転送するアプリケーションデータ。メッセージングシステムは無視し、アプリケーションが使う。
- 非同期メッセージングアーキテクチャは強力だが、開発アプローチを考え直す必要は出てくる。その他みっつのアプローチに比べると、メッセージングやメッセージングシステムになれている開発者は少ない。
メッセージングシステムとは何か？ †
- メッセージングをするための能力はメッセージングシステムないしメッセージ指向ミドルウェア（MOM）と呼ばれる、個別のソフトウェアシステムによって提供される。DBAがデータベースのスキーマを準備しなければならないのと同じように、メッセージングシステムの管理者はコミュニケーションのパスを設定しなければならない。メッセージングシステムの目的は送り手のコンピュータから受け手のコンピュータにメッセージを転送すること。
- やりとりするコンピュータやネットワークが信頼できないので、メッセージングシステムはメッセージをあるコンピュータから別のコンピュータに移動しなければならない（註：DBであれば一ヶ所においておけばいいので、移動はない、ということが念頭にある）。一方の準備ができていても他方がだめであったり、あるいはネットワークが死んでいたりするので、メッセージングシステムは成功するまでメッセージの転送を繰り返し試みる。理想的には一発で成功するのだが、現実はそうはいかない。
- メッセージ転送は以下の５ステップで行われる。
- 生成（Create）：受け手がメッセージを生成してデータを詰める
- 送信（Send）：送り手がメッセージをチャネルに追加する
- 配達（Deliver）：メッセージングシステムが送り手のコンピュータから受け手のコンピュータにメッセージを移動する
- 受信（Receive）：受け手がチャネルからメッセージを読み込む
- 処理（Process）：メッセージからデータを取り出す
- 図参照
- 図が示す、メッセージングの重要なコンセプトふたつ
- 送って忘れる：送信時、メッセージングシステムにメッセージを送ったアプリケーションは、いずれ受け手に届く、と考えることができ、実際に届くまで待つ必要はない。
- 溜めて送る：送信時にはメッセージングシステムはメッセージを送り手のコンピュータに溜めておく。配達時に送り手から受け手にメッセージを移動し、受け手のコンピュータに溜めておく。
- これほど複雑な処理を行うのは、メッセージ送信の責務をアプリケーションがメッセージングシステムに委譲するため。
なぜメッセージングを使うのか？ †
- ファイル転送より直接的だし、共有データベースよりカプセル化されているし、リモートプロシージャ呼び出しより信頼できる。でもそれだけではない。
- たとえば
- 遠隔コミュニケーション：メッセージングによって別々のアプリケーションが通信し、データを転送できる。その際、オブジェクトのシリアライズについて考えなくてもよい
- プラットフォーム／言語の統合：言語や要素技術などが異なるアプリケーション同士を統合するには、中立地帯が必要となる。こうした普遍的な接続性がメッセージバス（137）の核心
- 非同期通信：送って忘れる形式の通信が可能。
- 柔軟なタイミング：同期通信では送り手が受け手を待たなければならないが、非同期通信であれば送り手は自分の好きなペースでメッセージを送ることができる。
- 絞り：リモートプロシージャ呼び出し（RPC）の問題点は、呼び出しが集中すると受け手が過負荷になってしまうこと。メッセージングではキューイングが行われるので、過負荷になることがない。また、非同期なので、処理の遅れによって送り手が影響を受けることもない。
- 信頼できる通信：メッセージングの方が、格納して送る型のアプローチを取っているため、RPCよりも信頼できる。
- 切断状態での操作：ネットワークから切断されていても操作できるよう設計されたアプリケーションには、メッセージングは最適
- 仲介：メッセージングシステムは仲介者として機能する。アプリケーションはメッセージングシステムをディレクトリやサービスとして使うことができる。
- スレッド管理：非同期通信ということは、アプリケーションが待たなくてよいということ。アプリケーションがブロックされると、使えるスレッドが逼迫してしまう。
- 享受できるメリットの中には技術的なものもあればエンタープライズアーキテクチャとしての戦略に関わる部分もある。
非同期メッセージングの課題 †
- 非同期メッセージングは多くの課題を解決するが、独自の課題もある。非同期通信に関わるものもあれば、メッセージングシステムによるものもある。
- 複雑なプログラミングモデル：イベント駆動プログラミングモデルに従う必要がある。ロジックが複数のイベントハンドラに分断されてしまう。
- 順序性の問題：メッセージチャネルはメッセージが送信されることは保証するが、いつ送信されるかは保証しない。したがって、順番が狂う可能性がある。
- 同期シナリオ：すべての処理を非同期に行えるわけではないので同期と非同期のギャップを埋める必要がある。
- パフォーマンス：メッセージングシステムによってオーバーヘッドは発生する。大量データのレプリケーションなどには不向き。
- プラットフォームによるサポートの限界：すべてのプラットフォームでプロプライエタリなメッセージングシステムがつかえるわけではない。
- ベンダーロックイン：多くのメッセージングシステムは独自のプロトコルで実装されているので、別々のメッセージングシステム同士をつなげることができない。
- 要はメッセージングによってすべての問題が解消されるわけではなく、新しい問題が生まれる、ということ。
非同期的に考える †
- メッセージングとは非同期の技術であり、配達が成功するまでリトライしてくれる。ただし、ほとんどのアプリケーションは同期的な関数呼び出しを行う。
- 同期呼び出しでは処理の完了を待つが、非同期では待たない
- 非同期通信をする場合、暗黙的に決まってしまうことがある。
- 実行がシングルスレッドではなく、並列実行されるので、処理は速くなるがデバッグが大変
- コールバックでの実行となるため、別の処理の途中でも処理できなければならない
- 非同期処理は順番がバラバラになってしまう
分散アプリケーションと統合 †
- この本はエンタープライズインテグレーション、つまり、個別のアプリケーションが協力して動けるようにするためにどう統合すればよいかを扱う。しかし、通常エンタープライズアプリケーションが採用するn層アーキテクチャは統合ではなく分散である。
- n層アーキテクチャが統合ではなく分散について考慮している理由
- 通信部分が密結合になっている
- 層間の通信が同期になりがち
- ユーザが人間なのでレスポンスを素早く返す必要がある
- 統合アプリケーションはそれとは裏腹に、それぞれ独立して動くアプリケーションが疎結合なやり方で協力しあう。こうすることで各アプリケーションが自分の機能に集中できるようになる。
商用メッセージングシステム †
- メッセージングシステムと、関連するツールを出しているベンダーは多い。以下四つのカテゴリに分類する。
- OS：OSやDBプラットフォームに統合され始めている。
- Microsoft Windows 2000/XPとMicrosoft Message Queuing(MSMQ)サービス
- OracleとOracle AQ
- アプリケーションサーバ：J2EEがJava Messaging Service（JMS）仕様を含む。そのため、J2EEアプリケーションサーバがすべてJMSを実装
- EAIスイート：独自で機能が豊富なメッセージングシステム。
- WebSphere? MQ
- BizTalk?
- TIBCO
- WebMethods?
- SeeBeyond?などなど
- "Webサービスツールキット"：Webサービスの標準
- WS-Reliability
- WS-ReliableMessaging?
- ebMS
- 本書では、ベンダーに縛られないパターンを紹介する。残念ながら多くのベンダーが独自の用語法を使っているが、本書は中立の立場をとる。
- 他のベンダーが使っている用語と本書の用語との紐付け
