特集
|
DIMEメッセージの解析
通信プロトコルはHTTPなので、最初は次のようなHTTPヘッダが送信される。Content-TypeがDIMEメッセージであることを示している。
|
|
Webサービスに送信されるHTTPヘッダ |
HTTPのペイロードに載せられるのがDIMEメッセージだ。DIMEメッセージはバイナリ・データなので、次のようなビットの羅列となる。
00001100 00100000 00000000 00000000 ……
DIMEメッセージのレコードの全体構造は次の図のようになっている。先ほどのWebサービスでクライアントからサーバへ実際に送信されるDIMEメッセージを、この図に照らし合わせながら解説していこう。
DIMEメッセージのレコードの全体構造 |
まず、ヘッダの最初の4byteの意味は次のとおりだ。
最初の5bitはDIMEのバージョン番号を示す。現在は1が指定される。次の1bitはMB(Message Begin)フィールドで、このレコードがDIMEメッセージの最初のレコードであることを示す。次の1bitはME(Message End)フィールドで、このレコードがDIMEメッセージの最後のレコードであることを示す。次の1bitはCF(Chunk Flag)フィールドで、このレコードがデータを細かく分割したチャンクの一部であることを示す。上記のコードで送信されるデータでは、まずDIMEバージョンが1(00001)でMBフィールドに1が立ち、MEとCFフィールドは0となる。結果、最初の8bitは00001100となる。
次の8bitのうちの最初の4bitはペイロードのデータ型を表すフィールドの種類を示す。例えば「image/jpeg」のようなメディア・タイプである場合は1が、URIの場合は2が設定される。今回の場合はSOAPのEnvelopeなので、http://schemas.xmlsoap.org/soap/envelope/というURIが指定されるため、値は2、すなわち0010となる。次の4bitは予約領域で0が設定されるため、2つ目の8bitの値は00100000となる。
次の16bitは96ビット目から始まるオプション・フィールドの長さを示す。今回は使われていないため0となる。
結果として、最初の32ビットは次のようなデータになる。
00001100 00100000 00000000 00000000
続く16bitは、「96+上記のオプション・フィールドの長さ」の先から始まるIDフィールドの長さを示す。その次の16bitは、「96+上記のオプション・フィールドの長さ+左記のIDフィールドの長さ」の先から始まるTYPEフィールドの長さを示す。今回はIDとして「uuid:c4e5c3ef-38f0-48f1-a984-44604b770f66」が、TYPEとして「http://schemas.xmlsoap.org/soap/envelope/」がそれぞれ設定される。たまたま両者とも41byte長(2進数では101001)なので、結果として2つ目の32bitは次のようなデータとなる。
00000000 00101001 00000000 00101001
その次の32bitは、上記のTYPEフィールドの先から始まるペイロードの長さ(データ長)を表す。今回は860byteなので、結果として3つ目の32bitは次のようなデータとなる。
00000000 00000000 00000011 01011100
ここまでがDIMEのレコード・ヘッダのうち固定長の部分である。この固定長の部分を正しく計算すれば、DIMEレコードの各部のサイズは簡単に求まる。
ここから先は可変長になる。まず最初はオプション・フィールドだが、今回は指定されないので0byteとなり、データには現れない。次はIDフィールドである。IDフィールドはこのレコードをDIMEメッセージの中で一意に識別するためのもので、今回は上記のとおり「uuid:c4e5c3ef-38f0-48f1-a984-44604b770f66」という値が設定される。1文字1byteで41byteになるが、DIME仕様ではIDヘッダは4オクテット(4byte)の倍数でなくてはならず、余ったら0でパディングすることと定められているため、IDフィールドのデータ長は44byteとなる(ただし、パディング部分は上記のフィールド長にカウントする必要はないと定められている)。
次はTYPEフィールドである。TYPEフィールドには上記のとおり「http://schemas.xmlsoap.org/soap/envelope/」が設定される。これはDIMEではなくWS-Attachments仕様で決められた値で、SOAP 1.1のEnvelopeがペイロードに含まれていることを示す。TYPEフィールドの長さも41byteだが、これも4byteの倍数でなくてはならないので、余った3byteが0でパディングされる。
次が実際のペイロードだ。今回はペイロードには次のようなデータが含まれることになる。特に何の変哲もないSOAPメッセージだ。なお、実際のデータには改行やインデントは一切含まれない。
|
|
DIMEメッセージの最初のレコード内のペイロード・データ | |
クライアントからWebサービス・サーバに送信されるDIMEメッセージの最初のレコードのペイロードには通常のSOAPメッセージが含まれている。 |
これでDIMEメッセージの最初のレコードが終わり、次のビットからは2つ目のDIMEレコードが始まる。長さが指定されているため、MIMEのようにバウンダリ文字列などは特にないのである。
2つ目のDIMEレコードの固定長部は次のようなデータになる。
00001010 00010000 00000000 00000000 00000000 00101001 00000000 00001010 00000000 00000000 00000111 00101101
つまり、DIMEバージョン1、Message End、TYPEはメディア・タイプ、オプション・フィールド長は0byte、IDフィールド長は41byte、TYPEフィールド長は10byte、ペイロード長は1837byteということになる。
また、このDIMEレコードのIDは「uuid:5ff6fdf5-da91-4a6b-a446-5c61980931f9」という値であり、TYPEフィールドの値は「image/jpeg」である。ペイロードにはJPEG画像のバイナリ・データがバイナリのまま含まれる。これがDIMEメッセージの全貌だ。もっとも、DIMEメッセージの解析はWSEが行うので、開発者はAttachmentsプロパティにアクセスすればすぐにそのデータが取得できる。
INDEX | ||
[特集]次世代XML Webサービスを試す Part 4 | ||
SOAPメッセージとファイル添付 | ||
1.SOAPメッセージの添付ファイル | ||
2.WSEとWS-Attachments | ||
3.DIMEメッセージの解析 | ||
4.ほかのWS-Attachments実装との相互運用 | ||
「特集:次世代XML Webサービスを試す」 |
- 第2回 簡潔なコーディングのために (2017/7/26)
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために (2017/7/19)
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator (2017/7/18)
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
|
|