*THE Extensible WSDL Framework (P.89)

・Defining Message Data Types (P.90)

Webサービスは、そのもっとも抽象的なレベルにおいて、遠隔ソフトウェアプログラムに送る、もしくはそこから送られてくるXMLドキュメントから成っています。そのためWebサービスを定義するときの最初の作業はWebサービスの機能性を実装しているソフトウェアプログラムへのデータ要求を明らかにすることなのです。


入力と出力、またはそれらがサービスにどのように反映されるかを明らかにすることが、Webサービスにおいて必要とされます。WSDL types はこの点に気をつけています。TypesはXMLドキュメントであるか、もしくはその一部です。WSDLでは、typesを別々の要素の中で定義することができます。これにより多様なWebサービスにおけるtypesの再利用が可能になります。


データtypesは、あなたがWebサービスで使おうとするデータ型や仕様をどのように定義するかという点を処理します。型情報は送信側と受信側との間で共有されます。そのためメッセージの受取人は、あなたがデータを符号化するのに使った情報へのアクセスが必要であり、そのデータがどのように符号化されているかを知らなくてはいけません。


typesは基本的にXMLスキーマを使って定義されます。しかし、WSDLの他の部分のように、typesの部分部分は完全に拡張可能であり、それ以外の型システムを代わりに使うことができます。たとえばWebサービスのある実例で、ターゲットがCORBAオブジェクトであることを知っていれば、あなたはXMLスキーマ型システムではなくCORBA型システムを使うでしょう。また、それ以外の標準自己記述符号、たとえばAbstract Syntax Notation One(ASN.1)—抽象構文表記—のようなものを簡単に導入することもできるでしょう。これはWSDLのローカルエリアネットワークアプリケーションに有効であると思われます。このアプリケーションはXMLスキーマ型に含まれる、もしくは含まれない写像空間の最適化やバイパス化に役立ちます。


他にも高レベルな符号へのWebサービス記述言語ファイル内での型定義という選択もできるようになっています。typesはWSDL要素の範囲内、もしくはその要素に参照されるファイル内で定義されます。


XMLは元来融通がきき、変形が可能であり、さらに拡張可能であるため、Webサービス用に定義されるXMLデータは、バックで動くプログラムのデータ要求に厳密にマッチする必要はないのです。実際のところマッチしていることはあまりないでしょう。写像空間内でデータが処理される限りは、もとのアプリケーションとはちがう抽象レベルや仕様での定義が可能です。XMLデータがソフトウェアプログラムに写像される間は、Webサービスはそれ自体では実行可能ではないので、写像空間を含みます。また、そのプログラム自体が実行中であるときも同様に、実行空間を含みます。


写像空間はサービスのXMLデータとXMLスキーマ表現を、それを実行するソフトウェアプログラムへと変換することを要求されます。そのためメッセージデータ要求とWSDLの処理をおこなう部分こそがソフトウェアプログラムの多量のデータやセマンティックスを表現するのです。これは、変形能力と端末間の写像面によってネットワークを越えてブリッジを作るのを可能とするためです。


図の3-4に示されるように、ひとつ、またはいくつかの独立したデータ型がメッセージに写像されます。複数の処理で同じメッセージを写像することができるのです。types（型）は基本的にXMLスキーマにより支持されているデータ型、たとえば整数や文字列、論理演算子や日付けなどのどれにでもなります。また、そのデータ型は構文や配列、またはSOAPのために定義されるそれらの複雑なデータ型を含みます。そのためデータ型はシンプルなスキーマ型であるか複雑な型を定義するスキーマであるかのどちらかになります。他のWSDLの分野のように、型はXMLスキーマだけに限りません。なぜならWebにおいてたったひとつのシステムの型で、存在しうるすべてのメッセージ形式を記述できるとは誰一人として思いはしないからです。

下に示す例はSkateboots.comの購入注文の総数を返す注文サービスの型とメッセージ定義を描いたものです。WSDLファイルで使われるXMLスキーマデータ型は、スキーマ要素名を使ったメッセージへ写像されます。SOAPを使っているときはメッセージはSOAPリクエスト、もしくは応答の量として運ばれます。それはWSDLメッセージ定義がSOAPエンベロープやヘッダ、誤りコードに写像される情報を一切含まないことを示しています。言い換えればWSDLは抽象化層に的をしぼっていて、それはSOAPの抽象化層を完全に超えたものなのです。

 
 

・Defining Operations on Messages (P.94)

次のレベルの抽象化と実行は与えられたメッセージ、もしくはメッセージセットのために実行される命令の型を特定するというWebサービスの要求に取り組みます。データをどのように解釈するかということや、どのデータを要求に対して返すかということをWebサービスに知らせるために、実行(operation)は定義されます。


実行は一方通行、もしくは要求／応答のような共通のメッセージパターンに対応づけて定義されます。WSDLは他の実行に対する特定の定義を持ちません。しかしより複雑な相互動作はこれらの基本型を持つことによって作られます。たとえばebXMLからの共同作業のパートナーのプロフィールの仕様のようなものは、複雑なメッセージパターンのインタラクションを支え、一方通行や要求／応答実行の順序を定義します。


図3-5に示されるように、インプットとアウトプットが要求／応答メッセージのパターンに合うよう、実行がメッセージを分類します。


 


WSDLは以下の4つのオペレーションの型をもっています。

• One-way（一方通行）：fire-and-forgetに似ていますが、よりシンプルで、メッセージは応答の返信の要求をせずに送られます。
• Request/Response（要求／応答）：RPC(Remote Procedure Call：遠隔手続き呼び出し)スタイルのインタラクションに似ています。送信側はメッセージを送り、それに応じた応答を受信側が出します。（いくつかのプロトコルでは、すべての要求に対して応答があるとはかぎりません）
• Solicit response（応答の要請）｛定義はまだありません｝：入力データなしでおこなう、単純な応答要求です。メッセージを得るための要求であり、メッセージを送ることはしません。ある意味ではひとつ、もしくはいくつかの型定義からなるWSDLメッセージのようなものです。これは一方通行（One-way）実行の逆です。
• Notification（通知）｛定義はまだありません｝：この型の実行はブロードキャストのような、メッセージに対する複合受信機を定義します。そのために、この実行はときにpublish/subscribe（公布／署名）のような署名メカニズムを持ちます。

実行は、メッセージの順序を特定のパターンに関連づけることを可能にします。これにより複雑なフロー仕様を導入する必要がなくなります。実行はオブジェクトでのメソッドとは異なりますが、.NETやEJB、CORBAのようなオブジェクト指向技術でサービスを実装するときには実行のために定義される入力・出力パラメータがメソッド入力・出力アーギュメントに正常に写像されるのは確かです。


実行は任意の失敗メッセージを含むことがありますが、それらの内容は仕様の範囲には含まれません。下の例はSkateboots.comサービスのためのrequest/response（要求／応答）実行定義を示したものです。








以前示したWSDLファイルの要素で作られるメッセージ定義を使って、

＊SOAPエンベロープ

SOAPは封筒のような構造をしています。封筒構造の必要性は次のようなものが挙げられます。

• 宛名書きができる：たとえば納品書の宛名に「〇×会社御中」とだけ書いてあっても、封筒があれば表書きに実際の担当者名や所属などの情報を追加できます。
• 中身を隠すことができる：封印処理をすることで、受け取った人以外には誰も中身を覗いていないことがわかり、セキュリティやプライバシーの保護に役立ちます。
• 一緒にさまざまな文書を入れることができる：何種類か複数の文書を入れたり、別の封筒を入れたりできます