3. サービスで使用される論理メッセージを定義します
サービスは、その操作が呼び出されるときのメッセージ交換として定義されます。 wsdl ドキュメントでは、これらのメッセージは message 要素で定義されます。これらのメッセージは、パート要素と呼ばれる部品で構成されます。
サービスの動作は、論理メッセージを指定することによって定義されます。オペレーションが呼び出されると、論理メッセージが交換されます。 (つまり、論理メッセージはサービスの動作を表します) これらの論理メッセージは、ネットワーク上で送信されるデータを XML ドキュメントとして定義します。これには、メソッド呼び出しの一部であるすべてのパラメーターが含まれます。 (言い換えれば、論理メッセージ内のパラメータは、対応する操作メソッドのパラメータセットです)
メッセージとパラメーターのリスト: サービスによって公開される各操作には、入力メッセージと出力メッセージを 1 つだけ含めることができます。入力メッセージは、操作の呼び出し時にサービスが受け入れるすべてのメッセージを定義します。出力メッセージは、操作の完了時にサービスによって返されるすべてのメッセージを定義します。障害メッセージは、サービスがエラーを返したときのデータを定義します。
さらに、各操作には特定の数の障害メッセージが含まれる場合があります。この障害メッセージは、サービスでエラーが発生したときに返されるデータを定義します。通常、これらのメッセージには、消費者にエラーの内容を知らせるのに十分な情報を提供するセクションがあります。
メッセージは既存のシステムと統合するように設計されています。既存のアプリケーションをサービスとして定義する場合は、メソッド (操作を実装するメソッド) で使用されるすべてのパラメーターがメッセージ内で見つかることを確認する必要があります。戻り値がオペレーションの出力メッセージにも含まれていることを確認する必要があります。
メッセージを定義する 1 つの方法は、RPC スタイルです。 RPC スタイルを使用する場合、パラメーター リスト内の各パラメーターの部分を定義します。各メッセージ部分は、タイプの最初のタイプに基づいています。
入力メッセージには入力パラメーターごとに 1 つの部分があり、出力メッセージには出力パラメーターごとに 1 つの部分があります。さらに戻り値に対応する部分を追加します。パラメーターが入力と出力の両方である場合、そのパラメーターは入力メッセージと出力メッセージの両方としてリストされます。
RPC スタイルのメッセージ定義は、サービスが既存のシステムで有効になっている場合に役立ちます。 TIBCO または CORBA と同様のモード送信を使用します。これらのシステムは、プロセスと方法を中心に設計されています。このため、メッセージを使用してモデル化するのが最も簡単です。 RPC スタイルにより、サービスとアプリケーション間のマッピングも明確になります。
SOAP サービスのメッセージの設計: RPC スタイルはインベントリ システムのモデル化に使用されますが、サービス協会はラッパー ドキュメント スタイルを強く好みます。ラップされたドキュメント スタイルでは、各メッセージは 1 つの部分で構成されます。メッセージのこの部分は、types 要素で定義されたラッパー要素を参照します。パッケージング要素には次の特徴があります:
メッセージの命名: 各メッセージには、名前空間内で一意の名前が付けられます。次の命名規則を使用することをお勧めします。
メッセージではパーツ名の再利用が可能です。たとえば、メソッドにパラメータ foo があり、適用または入出力で渡される場合、そのパラメータはリクエストまたは応答メッセージの一部として存在できます。例として:
個人情報の検索(長いempId)
RPCスタイルにマッピングされたWSDLは以下の通りです
...