J2EE 與 .NET 互操作性深度解析（三）：XML 命名空間衝突與解決策略

前言

XML 命名空間如同 Java 套件名，避免元素/屬性命名衝突。但 J2EE 與 .NET 對 URI 解析、對應規則的細微差異，常在跨平台整合時引發難以察覺的互操作性問題。本文為系列第三篇，聚焦命名空間實戰陷阱。

核心問題與案例

1. 相對 URI 引用風險

.NET 允許 [WebService(Namespace="services.inventory")]，產生 targetNamespace="services.inventory"。若另一方同用相對 URI，WSDL 匯入時極易發生型別衝突。最佳實踐：永遠使用絕對 URI（含自有域名），如 https://mycorp.com/services/inventory。

2. 共享域名下的唯一性陷阱

零售與投資部門同用 bigbank.com 域名但不同子路徑：

• https://bigbank.com/retail
• https://bigbank.com/investment

Java 代理產生器以域名為包名依據（com.bigbank），導致同名 AccountService、Customer 互相覆蓋。解法：使用唯一子域名，如 https://retail.bigbank.com、https://investment.bigbank.com；或在 IDE 設定「命名空間→包名」自訂映射。

3. 共享 XSD 型別的陣列命名空間綁定錯誤

三方共用 https://catalog.warehouse.com 的 Product 型別，Order 與 Inventory 服務各自命名空間不同。.NET 產生的 WSDL 將 ArrayOfProduct 放在目錄命名空間，但元素引用 s0:Product 指向 Order 服務命名空間。Java 客戶端共用同一 ArrayOfProduct 類別，欄位綁定卻指向 Order，導致呼叫 Inventory 時傳送空陣列。
對策： (1) 產生第一個 Proxy 時重命名套件；(2) IDE 為每個服務將共享命名空間映射到不同套件。

總結與建議

• 預先設計 WSDL/XSD，勿依賴工具自動產生
• 命名空間 URI 必須全域唯一、絕對化
• 共享 Schema 時務必驗證陣列/複雜型別的命名空間綁定
• 善用 IDE 重構工具解決衝突

系列後續將探討錯誤處理（wsdl:fault）、WS-Security 等進階互操作主題。