C++,C#,JAVA之間webservice互操作問題探討

c++用的是gsoap,關於使用gsoap建立webservice的用戶端服務端問題，可以參見我以前的隨筆: << gsoap使用心得>>
JAVA用的是axis，用axis建立webservice的用戶端和服務端的問題，可以google一番，很多這方面的介紹。
C#用的是system.webserive這個類庫。

我們的目標是要求這三者之間的webservice互相通訊正常，即能收到用戶端發過來的一串字串，伺服器 端返回給用戶端一段字串。
要保證互相通訊正常，則必須首先明確webservice的採用的SOAP協議。
根據網上的資料:

style屬性可分為rpc document，rpc document之間的區別為:

    * RPC 樣式

RPC樣式指定 元素包含一個將被調用的web方法的名稱的元素（wrapper element（封裝元素））。這個元素依次為該方法的每個參數還有傳回值作了記錄。

    * Document　樣式

如果是document 樣式，就沒有像在RPC樣式中的wrapper元素。轉而代之的是訊息片斷直接出現在< SPAN>> 元素之下。沒有任何SOAP格式化規則規定元素下能包含什麼；它包含的是一個寄件者和接收者都達成一致的XML文檔。

‘Use’ 屬性。這與各種類型如何在XML中顯示有關，它指定使用某種編碼規則對訊息片段進行編碼，還是使用訊息的具體架構來定義片段。如下就是提供的兩種選擇：

    * encoded

如果use的值是”encoded”, 則每個訊息片段將使用類型屬性來引用抽象類別型。通過應用由 encodingStyle 屬性所指定的編碼樣式，可使用這些抽象類別型產生具體的訊息。最常用到的SOAP編碼樣式是在SOAP1.1中定義的一組序列化規則，它說明了對象、結構、數組和繪圖物件應該如何序列化。通常，在應用程式中使用SOAP編碼著重於遠程進程調用和以後適合使用RPC訊息樣式。

    * Literal

如果use 的值是”Literal”， 則每個片段使用 element 屬性（對於簡單片段）或 type 屬性（對於複合片段）來引用具體架構，例如，資料根據指定的架構來序列化，這架構通常使用W3C XML架構來表述。

我找了很多這方面的資料，但是具體理解起來還是很困難。單從字面取理解其實很簡單，但是聯絡到實際操作中,根據各種方式產生的wsdl來看，卻很難理解其中的異同。因為遵循document格式的soap訊息看上去很像rpc格式。而且對於簡單對象如int string等類型來說，好像並未有十分明顯的異同，因此在我測試過程中，一直都是比較模糊的。我也採用了comview，iris抓包工具，抓獲它們之間發送的資料包，對問題分析還是有所協助的。

我是以gsoap為主線進行測試的，因此在測試完成後，對自己的測試結果持有懷疑，我感覺是自己對gsoap的rpc docment encoded literal之間的差異並沒有理解透徹，我是這麼定義的：
document/literal方式：
//gsoap ns service name: EASReceive
//gsoap ns service location: http://services.xmethods.net/soap
//gsoap ns service namespace: http://tempuri.org/
//gsoap ns service style: document
//gsoap ns service encoding: literal
//gsoap ns service method-action: EASReceive ""

typedef char *xsd__string;
int ns__EASReceive(xsd__string strSubmitData ,xsd__string *strPxFormData);  

rpc/encoded方式：
//"OAMethod.h"的內容:
//gsoap ns service name: EASReceive
//gsoap ns service location: http://services.xmethods.net/soap
//gsoap ns service namespace: http://tempuri.org/
//gsoap ns service style: rpc
//gsoap ns service encoding: encoded  
//gsoap ns service method-action: EASReceive ""

int ns__EASReceive(char* strSubmitData ,char** strPxFormData);  

可我發現產生的wsdl中除了style use屬性值不一樣外，並沒有其它什麼區別，對了在encoded中我還加了soap2cpp.exe -e選項（加與不加都測試過）。

C#的用戶端多種方式都測試過，經測試只有採用
    [System.Web.Services.Protocols.SoapRpcMethodAttribute(
        "http://tempuri.org/EASReceive",
        RequestNamespace = "http://tempuri.org/",
        Resp,
        Use = System.Web.Services.Description.SoapBindingUse.Literal)]
或
    [System.Web.Services.Protocols.SoapRpcMethodAttribute(
        "http://tempuri.org/EASReceive",
        RequestNamespace = "http://tempuri.org/",
        Resp,
        Use = System.Web.Services.Description.SoapBindingUse.encoded)]
可以調通。

C#的服務端卻只有一種方式可以調通:
        [WebMethod]
        [SoapRpcMethod(
            Action = "http://tempuri.org/EASReceive",
            RequestNamespace = "http://tempuri.org/",
            Resp,
            Use = System.Web.Services.Description.SoapBindingUse.Literal)] //encoded不行
        [return: XmlElement("strPxFormData", IsNullable = false)]

也用C#的wsdl自動產生工具測試過，根據gsoap產生的wsdl檔案 ，自動產生的程式碼也不能和gsoap完成通訊正常。我一直理解不明白，按道理說只要將編碼方式一致即可通訊，不知是否我c#端代碼編寫有問題？在網上搜尋 C#端的資料時，發現C#端對webservice中自訂xml檔案方案是十分靈活的，可以隨意定製傳輸的xml節點，因此其實關鍵問題還是格式必須保證互相一致，這樣在收到soap訊息後，雙方都可以對xml進行正確的解析。經過反覆調試，最終還是調通了，都採用rpc/literal方式即可。 JAVA端和gsoap通訊倒是沒有問題，採用何種編碼只要統一即可通訊，因此基於測試發現的C#的"局限性"，我們統一成rpc/literal。

JAVA用戶端代碼：
  String endpoint = "http://192.168.8.94/csharp_demo/Service1.asmx";
  Service     service   =   new   Service();
  Call           call         =   (Call)   service.createCall();
  call.setTargetEndpointAddress(   new   java.net.URL(endpoint)   );
  call.setUseSOAPAction(true);

  String soapActi;  
  call.setSOAPActionURI(soapActionURI);  
  
  
  call.setOperationStyle(org.apache.axis.constants.Style.RPC);
  call.setOperationUse(org.apache.axis.constants.Use.LITERAL);
  
  String strSubmitData = new String("yes or no!???");
  call.setOperationName(new QName("http://tempuri.org/","EASReceive"));
  call.addParameter("strSubmitData",org.apache.axis.encoding.XMLType.XSD_STRING,javax.xml.rpc.ParameterMode.IN);
  //call.addParameter(new QName("http://tempuri.org/","strSubmitData"), org.apache.axis.encoding.XMLType.XSD_STRING, javax.xml.rpc.ParameterMode.IN);
  
  call.setReturnType(   XMLType.XSD_STRING  );
  
  //oper.setElementQName(new QName("http://tempuri.org/","EASReceive"));
  //call.setOperation(oper);  
  String   ret   =   (String) call.invoke(   new   Object[]   { strSubmitData} );
  System.out.println("Get   result   :   "   +   ret);

JAVA服務端代碼:略

最後，歡迎大家一起探討，感覺問題還是很多，現在雖然保證了通訊正常，但實際上我頭腦還是漿糊著呢，呵呵！
令關於C#端必須要求soapAction的問題，有兩種解決方案：
1、C#服務端加入以下代碼，但測試發現，部署到IIS後，並不起作用，具體原因不知道。
[SoapRpcService(RoutingStyle = SoapServiceRoutingStyle.RequestElement)]  //設定無需指派soapAction 但部署到iis 上時並未起作用
//[SoapDocumentService(RoutingStyle = SoapServiceRoutingStyle.RequestElement)]
2、在用戶端加上soapAction，gsoap用戶端傳入soapAction即可。

還有一個棘手的問題，就是中文亂碼問題，呵，說棘手是因為如果不清楚的確很棘手，其實解決起來也很簡單，就是保證通訊編碼一致。這裡的通訊編碼一致有兩層意思：
1、webservice間傳輸編碼，都保證為UTF8,gsoap加入soap_set_mode(s.soap, SOAP_C_UTFSTRING)即可。java,c#端都是預設以utf8傳輸的。
2、傳輸前參數的字元編碼，