Format Indicator †
ひと言要約 †
データフォーマットの変更に備えるため、バージョン番号、外部キー、フォーマット文書を使用する
要約 †
Messageを介したアプリケーション間の通信では、合意したデータフォーマット、例えば企業内のCanonical Data Modelに従う
- とは言うものの、フォーマットは時間が経てば変わってしまうよね
将来的な変更を可能にするメッセージフォーマットはどう設計できる？
すべてのアプリケーションで機能するデータフォーマットを設計するときでさえ、将来的な要求は変わってしまう
- 新しいフォーマット要求を持った新しいアプリが追加されたり
- 新しいデータをメッセージに含む必要があったり
- 開発者が同じデータを構築するよりよい方法を見つけたり
いずれにせよ、ひとつの企業データモデルを設計するのは非常に困難だし、将来的にも変更しないなんてありえない
企業のデータフォーマットが変わるとき、すべてのアプリケーションがそれで変わるなら問題はないはず
- すべてが狂いなく同時に旧形式をやめて新形式に移行でき簡単
- 移行が発生する前にチャネルを空にできるよう、すべてのメッセージは消費されているべき
- 問題は、あまり使われないアプリが移行されない一方で、いくつかのアプリが先に移行してしまうといったケース
現実的には、新形式も旧形式も同時に使えるべき
- 実現するには、アプリケーション側がどちらの形式を扱えるのか伝えればよい
解決策のひとつは、新しいフォーマットのメッセージのチャネルのセットを分離すること
- が、チャネル数の増大、設計の重複、設定の複雑化を招く
よりよい解決策は、旧形式と同じチャネルを新形式も使うこと
- 受信側が区別する必要がある
- それぞれのメッセージが使用しているフォーマットを表す簡単な方法が必要となる
メッセージがどのフォーマットを使用するのかを特定するために、Format Indicatorを含んだデータフォーマットを設計
Format Indicatorを使えば、送信元が受信先にメッセージのフォーマットを伝えられる
- バージョンナンバー
- ユニークにフォーマットを識別するナンバーあるいは文字列
- 利点は送受信側それぞれでフォーマット記述子の共有リポジトリに従う必要がないこと
- 欠点は送受信側それぞれがどのような記述子が示されてるか、そしてそこにどうアクセスするかを知っている必要があること
- 外部キー
- 一意のID（ファイル名、データベース行のキー、URLなど）でフォーマット文書を特定
- 送受信側それぞれ、キーと文書のマッピングとスキーマの形式に同意しているべき
- 利点はとてもコンパクトで、共有リポジトリにある細かなデータフォーマットの記述を指し示せること
- 欠点は送受信側それぞれがリモートのリソースにあるフォーマット文書を検索する必要があること
- フォーマット文書
- データフォーマットを記述したスキーマで、外部キーで検索される必要もバージョンナンバーで推測する必要もない、メッセージに埋め込まれたもの
- 送受信側それぞれでスキーマのフォーマットに同意しているべき
- 利点はメッセージ自身で含んでいること
- 欠点はそれぞれのメッセージが、あまり変わることのないフォーマット情報を含んでいることによって、トラフィックが増加すること
バージョンナンバーや外部キーはヘッダー領域で保持できる
フォーマット文書はヘッダーで保持するには複雑すぎるので、ボディ内でスキーマ部とデータ部に別れる
XMLの例 †
- バージョンナンバー
<?xml version="1.0"?>
- 外部キー
<!DOCTYPE greeting SYSTEM "hello.dtd">
- フォーマット文書
<!DOCTYPE greeting [
<!ELEMENT greeting (#PCDATA)>
]>
