この図は、Video メッセージ・セット中でメッセージを構成する論理フォーマットおよびオブジェクトを示しています。 下の図の説明も参照できます。
Video メッセージ・セットは、Video Rental サンプル・メッセージ・モデルのコンポーネントです。 このメッセージ・モデルから、論理メッセージ・モデルとそれに伴う物理フォーマットを構築する方法を見ることができます。 Video Rental サンプルのメッセージ・モデルには、ビデオを借りている顧客についてのデータが入っています。 メッセージ中のデータには、次のものが含まれています。
詳しくは、WebSphere Message Broker 資料で、メッセージ・モデルについて調べてください。
このメッセージ・モデルに含まれるエレメントは、複合タイプと単純タイプに基づいています。 影のついたボックスは複合タイプに基づくエレメント、また影のついていないボックスは単純タイプに基づくエレメントをそれぞれ表しています。 図に示されているように、このメッセージ・モデルには単純タイプに基づく 14 のエレメントが含まれています。 単純タイプは、ストリング、整数、およびバイトなどのデータ・タイプです。 これらの単純タイプが、図の中の陰影のないエレメントの基礎になっています。 Customer の直接の子である ID および Magazine エレメントを除き、メッセージ・モデル内のすべての単純エレメントは、複合エレメントまたは 1 つのグループの子です。 それらの複合エレメントとグループは、複合タイプ Customer の子です。 複合タイプは 1 つの構造定義であり、実際にはそこに含まれるデータのテンプレートとなるものです。 これらの複合タイプが、図の中のグレーの陰影の付いたエレメントの基礎になっています。
複合タイプには、名前を付けた複合タイプと無名の複合タイプがあります。 Video メッセージ・モデルの場合、Address と Borrowed には無名の (ローカル) 複合タイプが含まれています。一方、Name には名前付き (グローバル) 複合タイプが含まれています。 名前付き複合タイプは他のスキーマの中など、どこでも使用できます。一方、無名複合タイプはそれを含む宣言の中でしか使用できません。 名前付き複合タイプを使用することには、明らかにいくつかのメリットがあります。 たとえば、名前付き複合タイプを使用すると、組織内でより簡単に情報を共用できます。 しかし、無名の複合タイプを使用する方が好ましい場合もあります。複合タイプをいかなる場合にも再利用してはいけない時などです。
IdGroup というオブジェクトは、グループであるという点でメッセージ内の他のエレメントと異なっています。 IdGroup は、エレメント PassportNo、DrivingLicenseNo、および CreditCardNo の動作方法を定義するのに役立ちます。 顧客が新たにビデオ店の会員になった時点で、身分証明として必要なのは 1 つの種類の身分証明書だけです。 グループを作成し、PassportNo、DrivingLicenseNo、および CreditCardNo をそのグループのメンバーとして定義すると、メッセージ・モデルを構成でき、3 つのタイプの身分証明書 (ID) の 1 つだけを選択できます。 つまり、それら 3 つのエレメントは、証明書の種類の選択肢となるわけです。 あるタイプにこれらのエレメントを直接組み込むと、同時に 3 つのエレメントを入力することが可能になってしまいます。
メッセージ・モデルのさまざまな構成方法を示すため、LastName というオブジェクトはエレメントではなく属性として作成しています。 オブジェクトを属性として作成すると、それは XML の構成方法に影響します。
詳しくは、WebSphere Message Broker 資料で、メッセージ・モデル・オブジェクトについて調べてください。
さらに Video Rental サンプルでは、メッセージ・モデルや XML 入力メッセージの中で、また、メッセージ・フローが メッセージの一部を参照するために使用する ESQL の中で、ネーム・スペースを使用する方法も示されています。 Video Rental サンプルには、3 つのメッセージ定義が含まれています。 Customer 情報のためのメッセージ定義ファイルには、ターゲット・ネーム・スペースがありません。 しかし、Address と Borrowed の情報のためのメッセージ定義ファイルには、ターゲット・ネーム・スペースがあります。 Customer 情報用のメッセージ定義ファイルには、Address と Borrowed のメッセージ定義ファイルがインポートされています。 Address と Borrowed を別個のネーム・スペースにすることにより、それらのエレメントを別の業務においても容易に使用できます。
情報を論理的にグループ化するなら、たとえば会社の中で、お客様サービス部が在庫管理や営業などの他の部署と容易にデータを共有できます。 共有することの必要なオブジェクトを別々のネーム・スペースにすることは、必ずしも必要ではありませんが、それが共有のために役立つ状況は確かにあります。 たとえば、異なる開発者が互いに独立して作業している場合、それらの開発者が名前は同じでも業務上の意味の違うオブジェクトを作成することは、十分考えられます。 それらのオブジェクトをそれぞれ別個のネーム・スペースにするなら、名前の競合を心配することなく、各オブジェクト・セットを独立して開発することができます。
オブジェクトを開発する開発者のグループが 1 つしかない場合でさえ、ネーム・スペースは役立ちます。 たとえば、Name というオブジェクトには、さまざまな意味を持たせることが可能です。顧客の名前の場合もあれば、製品の名前の場合もあります。 この問題を回避する 1 つの方法は、CustomerName や ProductName といった名前を使用してオブジェクトを作成することですが、これでは名前が長くなってしまいます。 それに代わる方法として、顧客情報に関連したすべてのオブジェクトを 1 つのネーム・スペースとして分類し、製品に関連したすべてのオブジェクトを別のネーム・スペースとして分類するという方法があります。 そのようにすれば、あるオブジェクトが属するネーム・スペースによって、そのコンテキストが決まります。
詳しくは、WebSphere Message Broker の資料で、ネーム・スペースについて調べてください。
WebSphere Message Broker では、メッセージの物理表現を詳細に定義するための物理フォーマットがいくつか サポートされています。 例えば、カスタム・ワイヤー形式 (CWF) をメッセージ・セットに追加すると、この形式で入力メッセージを処理し、この形式で 出力メッセージを構成し、CWF から TDS または XML へ、またはその逆へメッセージを変換することができます。 3 つの物理フォーマットの入力メッセージについては、次のセクションで説明しています。
詳細については、WebSphere Message Broker の資料で、物理フォーマットについて調べてください。
CWF 物理フォーマットの Video 顧客メッセージは、下記のとおりです (メッセージ全体を見るには右にスクロールする必要があるかもしれません)。
Mr Fred Bloggs 12 Willow Avenue Salisbury CJ123456TT Fast Cars 2003-05-233.00Cut To The Chase 2003-05-233.751
カスタム・ワイヤー形式はタグを使用しません。
たとえば、上記のメッセージの最初のフィールド (値は Mr) の長さは 3 ですが、フィールドがどこで終わるかを示すタグは何もありません。
カスタム・ワイヤー形式での Video 顧客メッセージは、次のようになります。
ただし、読みやすくするため、フィールドごとに行を変えています。
Mr Fred Bloggs 12 Willow Avenue Salisbury C J123456TT Fast Cars 2003-05-23 3.00 Cut To The Chase 2003-05-23 3.75 1
Video 顧客メッセージは、以下のように XML で表現されます。
<Customer xmlns:addr="http://www.ibm.com/AddressDetails" xmlns:brw="http://www.ibm.com/BorrowedDetails">
<Name LastName="Bloggs">
<Title>Mr</Title>
<FirstName>Fred</FirstName>
</Name>
<addr:Address>
<HouseNo>13</HouseNo>
<Street>Oak Street</Street>
<Town>Southampton</Town>
</addr:Address> <ID>P</ID>
<PassportNo>J123456TT</PassportNo>
<brw:Borrowed>
<VideoTitle>Fast Cars</VideoTitle>
<DueDate>2003-05-23T01:00:00</DueDate>
<Cost>3.50</Cost>
</brw:Borrowed>
<brw:Borrowed>
<VideoTitle>Cut To The Chase</VideoTitle>
<DueDate>2003-05-23T01:00:00</DueDate>
<Cost>3.00</Cost>
</brw:Borrowed>
<Magazine>0</Magazine>
</Customer>
TDS 形式の Video 顧客メッセージを以下に示します (データは読みやすいようにそれぞれ別の行に分割されています)。
{Name:[Title:Mr*FirstName:Fred*LastName:Bloggs] &Address:[HouseNo:12*Street:Willow Avenue*Town:Salisbury] &ID:P &PassportNo:J123456TT &Borrowed:[Fast Cars+2003-05-23+3.00] &Borrowed:[Cut To The Chase+2003-05-23+3.75] &Magazine:1}
このメッセージの中の IdGroup というオブジェクトは、ビデオを借りる顧客の身分証明のタイプの 1 つの選択肢を表します。 身分証明としては、パスポート番号、運転免許証番号、またはクレジット・カード番号を使用できます。 入力メッセージに含まれる番号は、可能性のある 3 つの (選択肢) フィールド、つまり PassportNo、DrivingLicenseNo、または CreditCardNo のいずれかに対応します。 XML メッセージと TDS メッセージの場合、選択肢はメッセージ自体の中のタグと区切り文字によって解決されます。 一方、CWF メッセージにはタグも区切り文字もないため、選択肢は ESQL およびメッセージ中の ID フィールドの値を使用して解決する必要があります。 ID フィールドには、顧客の指定した身分証明 (ID) の種類を示す 1 文字が含まれています。P は PassportNo (パスポート番号)、D は DrivingLicenseNo (運転免許証番号)、そして C は CreditCardNo (クレジット・カード番号) です。
未解決の選択項目を含む CWF メッセージが入力ノードに来ると、MRM パーサーは警告メッセージを発生させます (メッセージ・フローをトレースしているなら、それを表示できます)。 メッセージの処理は継続されますが、それ以降に、選択項目を解決するための ESQL コードを含むノードがないなら、その処理は完了できません。 Compute ノードの ESQL には、初期の解析処理の結果として作成された論理メッセージ・ツリーを参照するための手段が含まれています。 入力メッセージが未解決だったため、そのツリーへの参照ではヌルが戻されます。
身分証明番号がどのフィールドに割り当てられたものか (PassportNo、DrivingLicenseNo、CreditCardNo のいずれか) を判別するため、付加的なフィールドとして ID フィールドが使用されます。 ID フィールドには、使用する身分証明書の種類を表す 1 文字 (P、D、または C) が入れられます。メッセージ・ツリーの中でこのフィールドは、IdGroup 選択肢フィールドの前にあります。 そのため、ID フィールドの値は、選択項目解決の前に解析できます。 ID フィールドを解析すれば、ESQL ステートメントでその値を使用することによって、選択肢を解決できます。
選択項目の処理方法を調べるには、『Video Rental サンプルの実行』を参照し、オプションである トレース作業を実行してみてください。 このサンプルの ESQL がどのようなものかについては、『メッセージ・フローの作成』を参照して ください。
メッセージ・セット・ファイルをワークベンチにインポートしたなら、Video メッセージ・モデルに含まれるさまざまなエレメントのプロパティーを調べることができます。 ワークベンチの中に表示されるものは、上のメッセージ構造の図に対応しています。 たとえば、Name エレメントについて調べるには、
他のエレメントについても、同じ方法で表示できます。 メッセージ構造の構築方法については、『Video Rental サンプルの作成』を参照してください。