データタイプ チャンネル(Datatype Channel) †
一言要約 †
データの型は受け手・送り手どちらも合わせておくチャンネルを用意することで、受け手は、受け取ったメッセージの処理方法を知ることができる。
要約 †
- アプリケーションは、異なるドキュメントの種類のように、異なるデータの型を転送するために、Messagingを使っている。
アプリケーションは、受け手が処理方法を知っているように、どうやってデータ項目を送ることができるか？
- すべてのメッセージは、最終的にはバイト配列のデータ構造になる。
- データ構造は、メッセージを送信するメッセージングシステムにとっては、充分特定することができるが、
受け手にとっては、メッセージの中身を処理することを特定するには、充分ではない。
- 受け手は、メッセージの中身のデータ構造とデータフォーマットを知っておかなければならない。
- 受け手は、受信するメッセージがどんな型か知るべきである、そうしないと、そのメッセージの
処理方法がわからなくなる。
figure: Mixed Data Types
- 送り手は、送信するメッセージの型が何かを知っており、受け手にどうやって伝達することができるか？
- 送り手は、メッセージのヘッダーの中にフラグを立てる。(Format Indicator、参照) しかし、受け手は、ケース文を必要とすることになるだろう。
- 送り手は、各データの型のために、異なるコマンドで、Command Messageの中に、データをラップすることができる。
- しかし、全てのメッセージが、受け手にデータを送信することを試しているとき、受け手に、データの使い方を教えることが推測できる。
- 項目のコレクションが処理されるときに似たような問題 が起きる。
１つがメッセージングから分ける
- コレクションは、均一でなければならないということは、項目の全てが同じ型であることを意味している。
- 処理する側が項目の型が何かを知っているかのように、どう操作するかを知っている。
- 同じ原理が、メッセージングに適用できる。
- 理由、チャンネル上のメッセージは、全てが、同じ型であるべきだからである。
- 異なるフォーマットが必要なのであれば、Format Indicatorが有効。
各データタイプによって、分けられたDatatype Channel を使うので、
特定のチャンネル上の全てのデータが、同じ型になる。
- それぞれのデータの型に対して、''Datatype Channel'’を分けて使うことで、チャンネルに与えられたメッセージの全てが、同じデータ型を含むことになる。
- 掲載されている図のように、送り手が３つの異なる型のデータを送信したいので、3つの異なるチャンネルを使用するべきだ。
- ３つのデータ
- 問い合わせ -> 問い合わせ用チャンネル
- 見積り価格 ->
- 購入注文
- Message Channelにおける議論としては、チャンネルは安価であるが、自由ではない。
- アプリケーションは、たくさんの異なるデータの型を送信することが必要かもしれない。そのときにDatatype Channelを分けて作るのは多くなりすぎる。
- 複数のデータ型が、１つのチャンネルを共有することが、Selective Consumerを利用することで、できるようになる。
- Datatype Channelは、なぜ１つのチャンネルで全てのメッセージが同じフォーマットでなければならないかを説明している。
- Canonical Dataは、どうやって企業の全てのチャンネルで全てのメッセージが、まとまったデータモデルで流すべきかを説明している。
- Content-Based Router について
担当者のコメント †
みんなの突っ込み †
