3.定義服務使用的邏輯消息
當服務的操作被調用時,服務被定義為消息交換。在wsdl文檔中,這些消息被定義message元素。這些消息由稱之為part元素的部分組成。
一個服務的操作,通過指定邏輯消息的方式來定義。當操作被調用時,邏輯消息被交換。(也就是說,邏輯消息代表了服務的操作)這些邏輯消息,將在網絡上傳輸的數據定義為xml文檔。他包含了所有的參數,這些參數是方法調用的一部分。(也就是說,邏輯消息裡的參數,是操作對應方法的參數集合)
消息和參數列表:每一個被服務暴露的操作能且僅能有一個輸入消息和一個輸出消息。輸入消息定義當操作被調用時,服務接受的所有消息。輸出消息定義的是,當操作完成時服務返回的所有消息。fault消息定義的是服務返回錯誤時的數據。
另外,每個操作可以有一定數量的fault消息。這個fault消息定義了當服務發生錯誤時返回的數據。這些消息通常有一個部分,該部分提供足夠的信息來讓消費者知道錯誤是什麼。
消息設計用於集成固有系統:如果你將已經存在的應用程序定義為一個服務,你必須確保方法(實現操作的方法)中使用到的每個參數都能夠在消息中找到對應。你必須確保返回值也在操作的輸出消息中。
定義你的消息的一個方法是:RPC風格。當使用RPC風格時,你使用給每個在參數列表中的參數定義一個part。每個消息part是基於在types中頂一個的type。
你的輸入消息為每個輸入參數對應一個part,同樣輸出消息為每個輸出參數對應一個part。另外增加個part來對應返回值。如果一個參數既是輸入,又是輸出,那麼它即作為輸入又作為輸出消息列出來。
RPC風格的消息定義是當服務使能存量系統時有用。它使用類似於TIBCO或者CORBA的模式傳輸。這些系統圍繞著過程和方法來設計。正是由於這樣,他們是最容易使用消息來建模。RPC風格也是服務和應用程序之間的映射清晰化。
為SOAP服務設計消息:當RPC風格用於建模存量系統,但是服務協會強烈地喜歡包裝文檔風格。在包裝文檔風格中,每個消息有一個part。這個消息的part參考了一個包裝元素,該元素定義在types元素中。包裝元素有如下特性:
消息命名:每個消息都在其命名空間中有唯一名字,建議使用下面的命名規則:
消息部件:消息部件是邏輯消息最常用的單元。每個part被定義,用part元素。並且通過name屬性,用type屬性或element屬性來指定數據類型。
消息允許重用part名。對於一個實例來說,如果一個方法有一個參數:foo,他被應用或者通過in/out傳遞,他能夠作為一個Part存在於請求或者應答消息中。如下例:
例子:假設你有一個服務器存儲了個人信息並且提供一個方法,該方法換回雇員的數據,基於雇員ID.。該方法如下:
personalInfo lookup(long empId)
被映射到RPC風格的WSDL如下
映射到包裝風格如下:
...