前言
Web 服務承諾無縫整合，異構平台卻暗藏殺機。本系列三文將系統剖析互操作性核心議題。首篇聚焦：為何必須「WSDL 先行」、為何棄用 RPC/Encoded、如何用 WS-I 測試工具把關。
核心觀點
1. WSDL 先行：契約優於實作
- 工具從程式碼產生 WSDL 雖省力，但雙向映射（Code→WSDL→Proxy Code）會放大資訊遺失
- XSD 型別系統比任何程式語言更豐富、語言中立，應作為設計起點
- 手工設計訊息部份、資料綁定、元素命名，遵循 WS-I Basic Profile，再用工具產生骨架程式碼
2. RPC/Encoded 為何必須棄用
- WS-I Basic Profile 僅支援 Document/Literal 與 RPC/Literal，明文禁止
soap:encodingStyle
- SOAP Encoding 支援循環物件圖（多重參考 id/href），但無法用 XSD 精確描述，導致跨平台序列化細節不一（WebSphere vs .NET 輸出差異）
- Document/Literal 雖需自行處理循環參考，但驗證嚴格、互操作性穩健
範例：Person 互指友人，RPC/Encoded 輕鬆表達；Document/Literal 需重新設計（如改用 ID 參考）。
3. WS-I 測試工具：自動化合規把關
- 分析器掃描 WSDL、SOAP 訊息，產出合規報告
- 典型違規：
use="encoded"、缺少 wsdl:fault 定義等
- 持續整合管線建議加入 WS-I 測試步驟
實務建議
- 先寫 WSDL/XSD，再產生伺服器/客戶端存根
- 強制 Document/Literal，拒絕 RPC/Encoded
- 每次建置跑 WS-I 測試，失敗即阻擋發布
- 團隊建立「訊息設計規範」（命名、空值處理、錯誤代碼等）
下一篇將深入資料型別映射陷阱。
