您现在的位置：程式碼之家 >> 編程語言 > >> Java 程式設計 >> J2ME

J2ME 呼叫 .NET Web Service 實戰：從 kSOAP 到 JSR 172 的技術選型與坑點踩雷全記錄

編輯：J2ME

技術選型路徑圖

裝置支援	推薦方案	核心工具	優勢	劣勢
支援 JSR 172 (Web Services API)	標準 Stub 生成	WTK 2.2+ `wscompile`	型別安全、標準化、無第三方依賴	僅支援簡單型別回傳；複雜型別生成失敗
不支援 JSR 172 (主流舊機型)	kSOAP 手動構建	kSOAP 1.x / 2.x	靈活控制 SOAP 封包、支援複雜型別	手工維護協議、易出錯、效能較差

JSR 172 標準路徑 (WTK 2.2)

取得 WSDL URL
WTK 選單 Tools → Generate Stubs 輸入 WSDL
自動產生 Stub 類別 + 協議處理類別
專案引用生成碼，直接呼叫強型別方法

陷阱：Web Service 回傳型別若非 WTK 支援的基本型別/陣列/簡單 Bean，Stub 生成會失敗。需協調後端簡化契約。

kSOAP 實戰踩雷記錄 (血淚教訓)

環境：kSOAP 2.x + .NET ASMX Web Service

初期嘗試 kSOAP2 失敗，錯誤指向 kxml.parser 找不到 v11 類別。轉戰 kSOAP 1.x。

核心問題 1：SOAP 命名空間前綴大小寫不一致

.NET 期望：soapenc, soapenv (小寫)
kSOAP 預設產出：SOAP-ENC, SOAP-ENV (大寫連字號)
修正：修改 org.ksoap.soap.SOAPConstants (或同名類) 中常數定義，強制小寫

核心問題 2：XML 命名空間聲明序列化缺陷

org.kxml.parser.AbstractXMLParser.startTag() 中 do-while 迴圈邏輯錯誤，導致當前 PrefixMap 後繼節點的命名空間聲明未寫入輸出流，造成封包頭資訊不全。


// 修正後邏輯
do {
    String p2 = current.getPrefix();
    String ns = current.getNamespace();
    if (!ns.equals(oldMap.getNamespace(p2))) {
        attribute(p2.equals("") ? "xmlns" : "xmlns:" + p2, ns);
    }
    current = current.getPrevious();
} while (current != null && current != oldMap);

核心問題 3：SOAP 版本衝突導致重複命名空間聲明

SOAPConstants.prefixMap 陣列初始化邏輯將 V11 (1999) 與 V12 (2001) 版本命名空間混合，導致 soapenc/soapenv 重複出現。

修正：重構 prefixMap 靜態陣列，明確分離版本，僅保留目標版本 (實測 .NET 需 V11)。

核心問題 4：SOAPAction HTTP Header 必須精確匹配

.NET ASMX 強制要求 SOAPAction Header 與 WSDL 定義完全一致
格式通常為 "namespace/methodName" (如 "https://www.tmp.com/MethodName")
kSOAP 需手動設定：call.soapAction = "namespace/methodName"

核心問題 5：.NET 端需標註 `[SoapRpcMethod]` 屬性

僅 [WebMethod] 不足夠，必須加上 [SoapRpcMethod] 才能正確處理 RPC 編碼風格請求。

總結：成功關鍵清單

確認目標裝置 JSR 172 支援度，優先標準路徑
若用 kSOAP，鎖定 1.x 穩定版本，避開 2.x 早期缺陷
SOAP 命名空間前綴、版本、Action Header 三大項逐項對齊 .NET 期望
建立「SOAP 封包對比測試流程」：抓取 .NET 官方測試工具 (SoapUI/WCF Test Client) 正確封包，與 kSOAP 輸出逐字節對比
後端協調：簡化回傳型別、添加 SoapRpcMethod、固定命名空間

現代映照

今日行動開發呼叫 .NET Core / ASP.NET Core Web API，標準做法是 REST + JSON (Retrofit/OkHttp, HttpClient, URLSession)，完全避開 SOAP 複雜性。J2ME 時代的 SOAP 接入經驗，本質是異構系統邊界協議協商的縮影，其核心教訓——契約優先、封包可觀測、版本顯式化——在 gRPC/GraphQL 時代依然適用。