EIP / Format Indicator


Format Indicator

ひと言要約

データフォーマットの変更に備えるため、バージョン番号、外部キー、フォーマット文書を使用する

要約

Messageを介したアプリケーション間の通信では、合意したデータフォーマット、例えば企業内のCanonical Data Modelに従う

  • とは言うものの、フォーマットは時間が経てば変わってしまうよね
将来的な変更を可能にするメッセージフォーマットはどう設計できる?

すべてのアプリケーションで機能するデータフォーマットを設計するときでさえ、将来的な要求は変わってしまう

  • 新しいフォーマット要求を持った新しいアプリが追加されたり
  • 新しいデータをメッセージに含む必要があったり
  • 開発者が同じデータを構築するよりよい方法を見つけたり

いずれにせよ、ひとつの企業データモデルを設計するのは非常に困難だし、将来的にも変更しないなんてありえない

企業のデータフォーマットが変わるとき、すべてのアプリケーションがそれで変わるなら問題はないはず

  • すべてが狂いなく同時に旧形式をやめて新形式に移行でき簡単
    • 移行が発生する前にチャネルを空にできるよう、すべてのメッセージは消費されているべき
  • 問題は、あまり使われないアプリが移行されない一方で、いくつかのアプリが先に移行してしまうといったケース

現実的には、新形式も旧形式も同時に使えるべき

  • 実現するには、アプリケーション側がどちらの形式を扱えるのか伝えればよい

解決策のひとつは、新しいフォーマットのメッセージのチャネルのセットを分離すること

  • が、チャネル数の増大、設計の重複、設定の複雑化を招く

よりよい解決策は、旧形式と同じチャネルを新形式も使うこと

  • 受信側が区別する必要がある
    • それぞれのメッセージが使用しているフォーマットを表す簡単な方法が必要となる

メッセージがどのフォーマットを使用するのかを特定するために、Format Indicatorを含んだデータフォーマットを設計


Format Indicatorを使えば、送信元が受信先にメッセージのフォーマットを伝えられる

  • 実装は主に3通り
  1. バージョンナンバー
    • ユニークにフォーマットを識別するナンバーあるいは文字列
    • 利点は送受信側それぞれでフォーマット記述子の共有リポジトリに従う必要がないこと
    • 欠点は送受信側それぞれがどのような記述子が示されてるか、そしてそこにどうアクセスするかを知っている必要があること
  2. 外部キー
    • 一意のID(ファイル名、データベース行のキー、URLなど)でフォーマット文書を特定
    • 送受信側それぞれ、キーと文書のマッピングとスキーマの形式に同意しているべき
    • 利点はとてもコンパクトで、共有リポジトリにある細かなデータフォーマットの記述を指し示せること
    • 欠点は送受信側それぞれがリモートのリソースにあるフォーマット文書を検索する必要があること
  3. フォーマット文書
    • データフォーマットを記述したスキーマで、外部キーで検索される必要もバージョンナンバーで推測する必要もない、メッセージに埋め込まれたもの
    • 送受信側それぞれでスキーマのフォーマットに同意しているべき
    • 利点はメッセージ自身で含んでいること
    • 欠点はそれぞれのメッセージが、あまり変わることのないフォーマット情報を含んでいることによって、トラフィックが増加すること

バージョンナンバーや外部キーはヘッダー領域で保持できる

フォーマット文書はヘッダーで保持するには複雑すぎるので、ボディ内でスキーマ部とデータ部に別れる


XMLの例

  1. バージョンナンバー
    <?xml version="1.0"?>
  1. 外部キー
    <!DOCTYPE greeting SYSTEM "hello.dtd">
  1. フォーマット文書
    <!DOCTYPE greeting [
      <!ELEMENT greeting (#PCDATA)>
    ]>