Web Services：自洽，編碼，交換模型

 

1, 自洽以前曾經寫過：

目前WebService不是自洽的，即一個WebService方法的參數和傳回值不能是另外一個WebService，因此你不能在WebService的傳回值上調用商務邏輯方法；頂多開發包做點手腳，封裝幾個getter/setter方法，或同構平台上在用戶端擁有服務端的類定義，可以調用其方法，像.Net平台上的DataSet；參考開發包的處理，我們可以自己為WebService的傳回值加入商務邏輯方法a，開發包無非是為用戶端產生一堆代理類，完成序列化/還原序列化，解析遠程調用協議等 b，我們可以修改這些代理類，加入商務邏輯方法，只要不影響序列化/還原序列化，解析遠程調用協議那些原有的部分就行參考以前的遠端程序呼叫協議，COM，RMI等，都能通過一個遠程對象返回另外一個遠程對象，可以調用各種方法，WebService完全應該定義其傳回值、參數可以是另外一個WebService

 最近看了<<我應該採用哪一種WSDL樣式>>, 文中提到RPC/Literal編碼方式的href屬性，讓我聯想起以前的想法，其實如果規定用戶端Stub必須是可序列化的，那麼是否就有可能解決WebService的參數和傳回值可以是另外的WebService呢（或說是另外的WebService的用戶端Stub類呢）？  2. Content-TypeSOAP 1.1 HTTP/SOAP 訊息的媒體類型為“text/xml”，其編碼處理是在 RFC2376 中定義的。而 SOAP 1.2 HTTP/SOAP 訊息的媒體類型為“application/soap+xml”，其編碼處理是在 RFC3023 中定義的。這些 RFC 規範定義了下列行為：

SOAP 1.1: HTTP/SOAP 請求的字元集由 HTTP 頭中的 ContentType 字元集參數確定。在 SOAP 訊息的 XML 聲明部分定義的編碼特性將被忽略。如果不指定 ContentType 字元集參數，字元集將被視為 US-ASCII。

SOAP 1.2: HTTP/SOAP 請求的字元集由 HTTP 頭中的 ContentType 字元集參數確定。在 SOAP 訊息的 XML 聲明部分定義的編碼特性將被忽略。如果未指定 ContentType 的字元集參數，將使用在 XML 聲明部分定義的編碼特性。如果 ContentType 字元集參數或 XML 聲明的編碼特性均未定義，它將被視為 UTF-8。

Content-Type: text/html;charset=GB2312Content-Type: text/xml; charset=utf-8  3，UTF-8，Axis？支援其它編碼？How to ？希望各位看官給個下面問題的答案

POST /wstest/NetWebService/SampleService HTTP/1.1Host: localhostContent-Type: text/xml; charset=utf-8  <!--1, how can I change it to charset=shift_jis using axis? Thanks-->Content-Length: lengthSOAPAction: "http://tempuri.org/max"<?xml version="1.0" encoding="utf-8"?> <!--2, how can I change it to encoding="shift_jis" using axis? Thanks--><soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">  <soap:Body>    <max xmlns="http://tempuri.org/">      <a>int</a>      <b>int</b>    </max>  </soap:Body></soap:Envelope> 

Assume the operation name is not "max", but a japanese string, and I prefer shift_jis to utf-8, then what should I do?

4, 文檔交換vs. RPC模型以下內容來自<< Webservice 的設計和模式>>

RPC（Remote Procedure Call）本質上就是遠程方法的調用。儘管Webservice是基於XML的但是你仍然可以使用遠程方法調用這種模式來進行Webservice的實現，尤其是在那種簡單的請求相應的模型中。在這個過程中，傳輸中的XML檔案所描述的更多是有關遠程方法的資訊，比如方法名，方法參數等等。而文檔交換方式，與RPC相比較在XML檔案中不是做遠程方法的映射，而是一份完整的自包含的業務文檔，當Service端收到這份文檔後，先進行預先處理（比如詞彙的翻譯和映射），然後再構造出返回訊息。這個構造返回訊息的過程中，往往不再是簡簡單單的一個方法調用，而是多個對象協同完成一個事務的處理，再將結果返回。這兩種方式的區別，類似與打電話和發郵件的不同處理方法。在目前，對於第一種方法提供了很多自動化的工具使得遠程方法的調用能夠很容易的完成，而後一種方法缺少一系列工具的支援，需要開發人員手工完成。儘管如此，在此還是推薦使用文檔交換的方式。由於它在以下方面具有RPC所不具備的優點。 使用文檔方式，你可以充分利用XML檔案的功能去描述和驗證一份業務文檔，而在RPC模型中XML僅僅被用於描述方法的資訊。 使用文檔方式，在客戶的Service的提供者之間不再需要緊密的約定，而RPC模型需要客戶和Service的提供者緊密相連，一旦方法發生變化，用戶端就需要做相應的改動。這不符合低耦合系統的要求，而在文檔交換方式中則靈活的多。 由於業務資料是自包含的，顯然文檔模型更利於採用非同步處理。

以下內容來自<<我應該採用哪一種WSDL樣式>> Java 方法 : public void myMethod(int x);

Binding Type	WSDL Sample	SOAP Sample	Advantage	Disadvantage
RPC/Encoded	<message name="myMethodRequest">     <part name="x" type="xsd:int"/> </message> <message name="empty"/> <portType name="PT">     <operation name="myMethod">         <input message="myMethodRequest"/>         <output message="empty"/>     </operation> </portType> <binding .../>  <!-- I won't bother with the details, just assume it's RPC/encoded. -->	<soap:envelope>     <soap:body>         <myMethod>             <x xsi:type="xsd:int">5</x>         </myMethod>     </soap:body> </soap:envelope>	WSDL 基本達到了儘可能地簡單易懂的要求。 操作名出現在訊息中，這樣接收者就可以很輕鬆地把訊息發送到方法的實現。	類型編碼資訊（比如 xsi:type="xsd:int" ）通常就是降低輸送量效能的開銷。 您不能簡單地檢驗此訊息的有效性，因為只有 <x xsi:type="xsd:int">5</x> 行包含在 Schema 中定義的內容；其餘的 soap:body 內容都來自 WSDL 定義
RPC/Literal	<message name="myMethodRequest">     <part name="x" type="xsd:int"/> </message> <message name="empty"/> <portType name="PT">     <operation name="myMethod">         <input message="myMethodRequest"/>         <output message="empty"/>     </operation> </portType> <binding .../>  <!-- I won't bother with the details, just assume it's RPC/         literal. -->	<soap:envelope>     <soap:body>         <myMethod>             <x>5</x>         </myMethod>     </soap:body> </soap:envelope>	WSDL 還是基本達到了儘可能地簡單易懂的要求。 操作名仍然出現在訊息中。 去掉了類型編碼	您仍然不能簡單地檢驗此訊息的有效性，因為只有 <x xsi:type="xsd:int">5</x> 行包含在 Schema 中定義的內容；其餘的 soap:body 內容都來自 WSDL 定義
Document/Litaral	<types>     <schema>         <element name="xElement" type="xsd:int"/>     </schema> </types> <message name="myMethodRequest">     <part name="x"         element="xElement"/> </message> <message name="empty"/> <portType name="PT">     <operation name="myMethod">         <input message="myMethodRequest"/>         <output message="empty"/>     </operation> </portType> <binding .../>  <!-- I won't bother with the details, just assume it's         document/literal. -->	<soap:envelope>     <soap:body>         <xElement>5</xElement>     </soap:body> </soap:envelope>	沒有編碼資訊 您可以在最後用任何 XML 檢驗器檢驗此訊息的有效性。 soap:body （ <xElement>5</xElement> ）中每項內容都定義在 Schema 中	WSDL 變得有些複雜。不過，這是一個非常小的缺點，因為 WSDL 並沒有打算由人來讀取。 SOAP 訊息中缺少操作名。而如果沒有操作名，發送就可能比較困難，並且有時變得不可能。
Document/LiteralWrapped	<types>     <schema>                 <element name="myMethod"/>             <complexType>                 <sequence>                     <element name="x" type="xsd:int"/>                 </sequence>             </complexType>         </element>     </schema> </types> <message name="myMethodRequest">     <part name="         parameters" element="         myMethod"/> </message> <message name="empty"/> <portType name="PT">     <operation name="myMethod">         <input message="myMethodRequest"/>         <output message="empty"/>     </operation> </portType> <binding .../>  <!-- I won't bother with the details, just assume it's document/literal. -->	<soap:envelope>     <soap:body>         <myMethod>             <x>5</x>         </myMethod>     </soap:body> </soap:envelope>	沒有編碼資訊。 出現在 soap:body 中的每項內容都是由 Schema 定義的，所以您現在可以很容易地檢驗此訊息的有效性。 方法名又出現在 SOAP 訊息中	WSDL 甚至更複雜，但是這仍然是一個非常小的缺點