特集 次世代XML Webサービスを試す Part 4 ―― SOAPメッセージとファイル添付 ―― １．SOAPメッセージの添付ファイル インフォテリア株式会社 吉松 史彰 2003/04/02

Page1 Page2 Page3 Page4

Back Issue

1 Web Services Enhancements イントロダクション − 2 WS-Security詳細解説 3 SOAPメッセージのルーティング

始めに

　今回は、Web Service Enhancements（WSE）の解説の最後として、SOAPメッセージへの添付ファイル追加機能を紹介する。この場合の添付ファイルは、実はファイルとしてハードディスク上に存在しなくても構わないので、「添付データ」といった方が適切かもしれない。しかし電子メールなどを通じて添付ファイルという言葉が浸透しているので、本稿でも添付ファイルという言葉で解説する。添付するものがファイルとしてではなく、例えばほかのネットワークから送られたデータでも、データベースから取り出したデータでも何の問題もないことに注意して読み進めてほしい。

SOAPメッセージに添付ファイルを付ける必要性

　おなじみの添付ファイルは、電子メールを使って補足資料を送信したり、電子メールでは送れないバイナリ・データを送信したりするために使われている。電子メールは名前のとおりの手紙なので、開けば人間が読むことができるメッセージが含まれているはずだ。しかし、中にはイメージや実行可能ファイルを他人に送信したいというニーズもある。そこで添付ファイルという発想が生まれた。SOAPメッセージも同じだ。当初、SOAPメッセージはXML形式であることが過剰に強調されて、「どんなデータでも送受信可能」といわれたことがあったが、実際には現在のXMLは、最終的にXML 1.0仕様にのっとったテキスト・データとなるため、バイナリ・データを直接XML化することは不可能である。

　電子メールも同様にテキスト・データを前提にした仕様で作られているので、バイナリ・データを送受信することができない。そこで、あらゆるバイト列を特定の範囲のテキストで表現できるように置き換えるアルゴリズムができた。代表的なのがBase64といわれるもので、3byte（24bit）のデータを6bitずつの4文字に変換する。変換結果はアルファベット（大文字、小文字）、数字、「+」、「/」のいずれかになるので、テキストとして送信することが可能だ。Base64で変換した結果はテキストであるので、XMLに含めて送信することもできる。

　しかし、Webサービスがシステム同士の機械的なやりとりであることを考えると、バイナリ・データをバイナリ・データのまま送信できる方が自然だ。加えて、Base64などのアルゴリズムでは、バイナリをテキストに変換し、受け取った側でテキストをバイナリに再変換しなくてはならず、ただでさえXMLの解析処理のパフォーマンスが槍玉に挙げられているWebサービスにとって、このような問題は無視できない。

MIMEによる添付ファイル

　現在の電子メールでは、バイナリ・ファイルを当然のように添付できる。このような機能は、Multipurpose Internet Mail Extensions（MIME）の仕様化によって実現された。MIMEは単なるヘッダと本文でしかなかった電子メールに構造を与え、添付ファイルを実現した。MIMEのマルチパート機能によって、1つの電子メールが複数のパーツから成り立つ構造化データになったのだ。電子メールで使われるMIMEマルチパートのデータは次のような内容になっている。

From: "Fumiaki Yoshimatsu" <fumiaki_y@hotmail.com> To: friend@example.org Subject: My favorite player Date: Mon, 27 Jan 2045 11:23:34 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="NextPart" This is a multi-part message in MIME format. --NextPart Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit She's so cute --NextPart Content-Type: image/jpeg; Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Hantuchova4.JPG" /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsL DBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/ （省略） ANUMjVIzVC1TIoKp6s37u3T6uf5VejXd8tVdSj3SM3ooWphuc2Kl7ljHptOZ iigBtFFFBQUUU2gAooptABRTtm7migD/2Q== --NextPart--

電子メールで使われるMIMEマルチパートのデータ例

“NextPart”という文字列で区切られたパーツが集まって1つのデータを構成している。それぞれのパーツには、データ型や転送形式などを示すヘッダが付いており、これを読み取ってもとのデータを再構築できる。

　“NextPart”という文字列で区切られたパーツが集まって1つのデータを構成している。それぞれのパーツには、データ型や転送形式などを示すヘッダが付いており、これを読み取ってもとのデータを再構築できるわけだ。

　このMIMEマルチパートによる構造化を、そのままWebサービスでも使ってしまおうと考えるのも自然なことだろう。SOAP仕様がW3Cに提出された7カ月後には、「SOAP Messages with Attachments（SwA）」という仕様がW3Cに提出されている。このSwAの内容は、要するに上記のようなMIMEマルチパートにおいて最初のパーツに本文となるSOAPメッセージを配置し、2つ目以降のパーツにはSOAPメッセージに添付されるデータを配置するための決まりごとだ。SwAでは、例えば次のようなデータが送られる（仕様書から抜粋）。

MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;         start="<claim061400a.xml@claiming-it.com>" Content-Description: This is the optional message description. --MIME_boundary Content-Type: text/xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: <claim061400a.xml@claiming-it.com> <?xml version='1.0' ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> …… <theSignedForm href="cid:claim061400a.tiff@claiming-it.com"/> …… </SOAP-ENV:Body> </SOAP-ENV:Envelope> --MIME_boundary Content-Type: image/tiff Content-Transfer-Encoding: binary Content-ID: <claim061400a.tiff@claiming-it.com> ...binary TIFF image... --MIME_boundary--

SOAP Messages with Attachments（SwA）で送信されるメッセージ例（仕様書から抜粋）

パーツは“MIME_boundary”という文字列で区切られ、最初のパーツに本文となるSOAPメッセージを配置し、2つ目以降のパーツにはSOAPメッセージに添付されるデータを配置する。

　SwA仕様には、Apache SOAPを含む数多くの実装が存在する。だが皮肉なことに、SwA仕様を書いて提出した当のMicrosoftからは、SwAの実装は出ていない。

DIME仕様

　MIMEは、もともとASCIIコードで表現できるデータを送受信するための電子メールを、もっと多様なデータを送信できるように改良することを目的として生まれた仕様である。そのため、その本質は文字列データを扱うということにある。つまり、文字列データを扱う上では当然のことが当然のこととして仕様化されているのだ。当然のこととは、例えばMIMEマルチパートにおけるパーツとパーツの区切りにアクセスする方法が、文字の読み取り以外にはないということだ。

　MIMEでは複数のパーツを組み合わせて1つのメッセージを構築するのは簡単だ。だが、そのようにして構築されたメッセージを複数のパーツに分割するのは容易ではない。送られた文字列を1行1行解析して、MIMEマルチパートのバウンダリ文字列を見つけ出さなければならないのだ。また、どうせ文字列データを1行1行読み取らなければデータは取得できないのだから、各パーツにはそのパーツの長さを示すようなヘッダは存在しない場合が多い。ところが、メッセージを受け取る側から見ると、事前にサイズが分からないので、どれくらいのメモリをバッファ領域として確保すればデータが取得できるのかが判別できない。このようにMIME仕様は、文字データを扱うという前提が崩れてしまうと、不便さだけが際立つものになっている。

　Microsoftの面々は、これらMIMEの欠点を排除する新しいデータの構造化仕様を作成することにした。そしてSwAの実装をMicrosoftが提供する可能性はなくなった。何といっても、SwA仕様の著者であるHenrik Frystyk Nielsen氏ですら、この新しい仕様の策定に中心的に参画しているのだ（ちなみにNielsen氏はHTTP 1.1仕様の著者でもある）。その結果生まれたのが、Direct Internet Message Encapsulation（DIME）仕様である。この仕様は主にMicrosoftの著者によって起草され、現在RFC化するべくInternet Draftとして提出されている（http://www.ietf.org/internet-drafts/draft-nielsen-dime-02.txt）。現在の版は3世代目であり、この版からIBMの著者も名を連ねている。

　DIMEはMIMEと同じく、複数のパーツからなる単一のデータを表す構造を示す仕様である。DIMEのパーツは、レコード・ヘッダとペイロードから成るレコードと呼ばれる。レコード・ヘッダにはペイロードの長さや、レコード・ヘッダに含まれるオプション・ヘッダの長さなどが記述される。レコード・ヘッダには任意の長さのオプション情報を含むことができるのだが、それらのオプション情報の長さを示す場所は固定長である。そのため、レコードの先頭から特定のバイト数だけ移動すれば、ヘッダ長が分かるようになっている。このように簡単にレコード・ヘッダからレコード全体のサイズが分かるので、MIMEのようなバウンダリ文字列は使わない。また、レコードサイズが簡単に分かるので、レコードを読み取らずにスキップするような操作も可能になっている。

WS-Attachments仕様

　DIME仕様はデータをパッケージングするための仕様であり、SOAPメッセージに特化した仕様ではない。DIMEを使ってSOAPメッセージと添付ファイルを扱う仕様は、WS-Attachements仕様として別に策定されている（IETFのWS-Attachments解説）。WS-Attachments仕様には、例えばDIMEメッセージの最初のパーツがSOAPメッセージの本体でなければならないことや、SOAPメッセージから同じDIMEメッセージの別のレコードを参照する方法などが定義されている。WSEに含まれているのは、このWS-Attachments仕様に基づいてSOAPメッセージと添付ファイルを送受信する機能である。

INDEX
	［特集］次世代XML Webサービスを試す Part 4
	SOAPメッセージとファイル添付
	1．SOAPメッセージの添付ファイル
	2．WSEとWS-Attachments
	3．DIMEメッセージの解析
	4．ほかのWS-Attachments実装との相互運用

　

「特集：次世代XML Webサービスを試す」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）