7.2. メッセージ構造

サービスの観点から見ると、メッセージの最も重要なコンポーネントはボディーです。これは、ビジネスロジックに固有の情報を伝えるために使用されるためです。クライアントとサーバーの両方が、対話するために相互に理解する必要があります。この理解には、トランスポートのモード(Java Message Service や HTTP など)と使用されるダイアレクト（データがメッセージに表示される形式）に関する合意が関係します。

メッセージをサンプルフライト予約サービスに直接送信するクライアントを簡単にするには、サービスがメッセージに関与する操作をどのように判断するかを決定する必要があります。この場合、開発者は org.example.flight.opcode という場所にある opcode （操作コード）が文字列(reserve, query、upgrade)として表示されると判断します。その他の文字列値（または値がない場合）は、メッセージが不正であると見なされます。

メッセージボディーは、クライアントとサービスの間でデータを交換する主要な方法です。任意のデータタイプを含めるのに十分な柔軟性があります。（各操作に関連するビジネスロジックを実行するために必要な他のパラメーターは適切にエンコードする必要があります。）

これらの操作はすべて、メッセージ内で情報をカプセル化してクライアントに返します。応答メッセージは、独自の形式を決定するために同じプロセスを通過します。簡単にするために、応答メッセージはこの例からなくなります。

1 つ以上のアクションを使用してサービスを構築します。これらのメッセージは、受信メッセージを事前に処理し、コンテンツをメインのビジネスロジックを担当するアクションに渡す前に変換します。これらの各アクションは分離して記述することができます（同一組織内の異なるグループや、全く異なる組織によっても記述される場合もあります）。各アクションに、それが動作するメッセージデータの一意のビューがあることを常に確認してください。そうでない場合は、チェーンされたアクションが上書きされたり、相互に干渉する可能性があります。