Camel In Action の1章の適当邦訳 〜Apache Camel その4



Camel In Action の1章の適当邦訳 〜Apache Camel その3 - A Memorandumからの続き

Camel のメッセージモデル

Camel ではメッセージのモデリングに 2つの抽象があります。本章ではこの2つについて説明します。

  • org.apache.camel.Message ― Camel にて運び届けられるデータを含む基本的なエンティティ
  • org.apache.camel.Exchange ― メッセージ交換のための Camel での抽象。メッセージの交換は入力となるメッセージと、その応答としての出力メッセージです。

最初に Message について見ていき、Camelではデータがどのようにモデル化され運ばれるかを理解しましょう。そして Camel では交換により どのように会話(コンバゼーション)がモデル化されるかを見ていきます。

1.3.1 Message

メッセージはメッセージングチャネルを使い、各システムがコミュニケートする場合に使われるエンティティです。送信者から受信者への順路におけるメッセージフローを以下に示します。



メッセージはボディ(ペイロード)とヘッダ、そしてオプションとしてアタッチメントを持っています。この構造を以下に示します。



メッセージは java.lang.String 型の識別子により一意に識別されます。識別子の一意性はメッセージの生成元により強制され、保障されるものです。これはプロトコルに依存し、保障されたフォーマットがありません。一意なメッセージ識別子の付与方法が定義されていないプロトコルのために、Camel は独自の UID ジェネレータを使用しています。

ヘッダと添付情報(ATTACHMENTS)

ヘッダは、送信者IDやコンテンツエンコーディングそして認証情報などのメッセージに関連付けられた値です。ヘッダは名前と値のペアで現わされます。名前は大文字と小文字を区別しない java.lang.Object 型の値です。これは Camel がヘッダの型に制約を課さない ということを意味します。ヘッダはメッセージの中にマップとして格納されます。メッセージはWebサービスやE-mailコンポーネントのような追加の添付情報も持つことができます。

ボディ

ボディは java.lang.Object 型です。これはコンテンツとしてどんな種類の情報でも格納できることを意味します。そしてこれは、アプリケーションの設計者が、受信者がメッセージのコンテンツを理解できるかどうかを把握しておく必要があるということになります。送信者と受信者がことなるボディフォーマットを使用していた場合、Camel は受け入れ可能なフォーマットにデータを変換するメカニズムを提供しています。ほとんどの場合この変換は型変換として自動的に、裏舞台で行われます。

フォルトフラグ

メッセージはフォルトフラグ(fault flag)も持っています。WSDL と JBI などのいくつかのプロトコルと仕様は出力するメッセージと失敗メッセージを区別しています。これらは双方ともに処理の呼び出しの結果として得られる正当なメッセージですが、後者は失敗した結果のメッセージとなります。一般的には失敗は統合基盤側で処理されるものではありません。失敗の結果は、クライアントとサーバ間の規約の一部であり、アプリケーションレベルで処理されるものなのです。
ルーティング中にはメッセージは exchange に含まれています。

1.3.2 Exchange

Camel における exchange とは、ルーティング時のメッセージのコンテナとなります。exchange はまた、メッセージ交換パターン(MEPs)として知られるシステム間の様々な相互作用をサポートするために提供されています。MEPs は一方高、およびリクエスト-レスポンスといった双方向のメッセージスタイルを区別して扱います。Camel の exchange はパターンプロパティとして以下のどちらかを持つことができます。

  • InOnly ― イベントメッセージのような一方向のメッセージ。例えば、多くの場合に一方向として利用される JMS など。
  • InOut ― リクエスト-レスポンスメッセージ。例えばクライアントのWebページ取得要求はサーバからの応答を待つといったHTTPベースの送受信。

以下に Camel の Exchange が保持する内容を示します。



Exchange の詳細について見ていきましょう。

  • Exchange ID ― exchange を一意に識別する ID です。明示的に指定しなかった場合は Camel によってデフォルトのユニーク ID が生成されます。
  • MEP ― InOnly か InOut のどちらのメッセージスタイルを使用しているかを示すパターンです。InOnly パターンの場合には exchange は入力メッセージを含みます。InOut の場合は、入力メッセージに加えて呼び出し元へ返却するメッセージを含みます。
  • Exception ― ルーティングの最中にエラーが発生した場合、例外フィールドに Exception が設定されます。
  • Properties ― メッセージヘッダに似ていますが、全てのメッセージ交換の期間において最後まで有効となります。メッセージヘッダは個別のメッセージ固有の情報であるのに対して、Properties はグローバルレベルでの情報を保持することになります。Camel はルーティング中のメッセージの交換のために様々なプロパティを追加していきます。開発者は exchange の有効期間の任意の期間におけるプロパティを取得して保存することができます。
  • In message ― 入力メッセージで、これは必須です。In message にリクエストメッセージが格納されます。
  • Out message ― MEP が InOut となっていた場合のみ設定されます。Out message には返答となるメッセージが格納されます。


アーキテクチャの説明に先立ち、Camel のメッセージモデルについて述べてきました。これは Camel におけるメッセージがどんなものか確実に理解しておいてほしかったからです。結局のところ、Camel の最も重要な側面はメッセージのルーティングなのです。ここまでで、Camel と そのアーキテクチャについて学ぶ準備は十分に整ったはずです。



Camel In Action の1章の適当邦訳 〜Apache Camel その5 - A Memorandumに続く