使用 Java 來開發 Web Services 的讀者應該大部分都聽過 soapUI 這套測試工具，使用微軟.NET 平台進行開發的讀者有可能就鮮少聽聞過這套工具，因為它是一個使用 Java 開發的工具。
使用 Java 來開發 Web Services 的讀者應該大部分都聽過 soapUI 這套測試工具，使用微軟.NET 平台進行開發的讀者有可能就鮮少聽聞過這套工具，因為它是一個使用 Java 開發的工具。讀者或許會好奇為什麼介紹這一套工具呢？還記得我們 .NET 的開發人員大多是怎麼測試自己開發的 Web Services 呢？最簡單的方式就是使用 ASP.NET 內建的測試畫面，如下：
但這只支援HTTP協定的測試，如果您只單單要走 SOAP，那這個方式就會宣告無效。
而認真工作的員工就是自己寫測試程式，開個簡單的 Windows Form 專案，使用加入參考，我就可以呼叫該 Web Services。
當然，您也可以使用 wsdl.exe 等公用程式土法煉鋼，自動化編譯 WSDL 為 DLL，並自動 Load Assembly 至專案中，甚至測試時再搭配 NUnit 等測試工具進行偵錯，這種事筆者也幹過...
再來，回到正題，專業的員工可能會知道使用 .NET WebService Studio 這套工具來進行測試。這已經幾近完美了，因為我不需要再自己寫 Code 來只是為了測試 Web Services 了，如下：
但是對要求更高的專業人員來說還是不夠的，為什麼呢？有時與異地的人員進行 Web Services 的對測時，又因為對方使用的為非 .NET 平台所開發的 Web Services 時，再加上對方又只能告訴你：『阿我就是傳這樣的 XML 的 SOAP 封包進來，你的 Web Services 就會報錯..』的時候，在這種時候，你就會發現 soap UI 有多好用，因為這套工具對於測試 Web Services 有較靈活的設定方式，它甚至可以直接將別人呼叫你的Web Services 的 XML 貼過來修改一下內容，然後再 Invoke 到自己的 Web Services 中，實際的測試會發生什麼樣錯誤。
測試的方式如下：
1. 安裝 soap UI
可到官方網站 http://www.soapui.org/ 下載，或是到 http://sourceforge.net/projects/soapui/files/soapui/4.5.1/ 下載 32 位元版 soapUI-x32-4.5.2.exe 或是64位元版 soapui-4.5.1-win32-standalone-bin.zip，Windows 的使用者建議到 http://www.soapui.org/ 下載 Windows 32bit installer。
2. 安裝完成後，如果是官方版，可直接執行工具列連結即可
或是到目錄中執行 "C:\Program Files (x86)\SmartBear\soapUI-4.5.2\bin\soapui.bat"，啟動畫面如下：
3. 至選單中->File->Import Project ，匯入 WSDL 檔案
4. 匯入成功後，可至左方列表選擇要測試的 Web Service 的作業
例如要測試 SSOLoginConfirmWebService –> SSOLoginConfirmSoapBinding 的 web service 就點選 LoginConfirm -> Request，就會把自動透過 WSDL 產生的訊息格式帶出來。此時可直接在右邊窗格中編輯測試訊息，如下：
5. 編輯要 Invoke 的 URL，與使用綠色的箭頭進行實際的呼叫
6. 在 Debug 模式下，我們就可以輕易查看訊息是否成功的接到
若發生錯誤時，soap UI 也會 catch 錯誤訊息在右端
補充說明：
另外在使用 .NET 開發的 Web Services 要提供給 Java 呼叫的時候，由於雙方一些規範嚴格來說有一點出入，並不是說微軟或 Java 沒有支援正規的 SOAP 1.1 & 1.2 ，其實是有完整支援的，只是微軟的 SOAP Binding 使用的 XSD 預設使用的 namespace 有時並不為對方所接受，典型的如送出去的 SOAPAction ，.NET 所開發的 Web Services 你會看到預設的 http://tempuri.org/
有時即是問題的所在，不見得是 SOAP 規範的問題，而 .NET 在這邊也提供了 SoapDocumentMethod 的 Attribute 提供自行定義與修改 SOAPAction。
下方為實際提供 Java 端呼叫的一個例子，我透過 SoapDocumentMethod 自行定義 RequestNamespace 與 ResponseNamespace ，並決定 SoapBinding 使用 Literal 方式，最後也自訂 return 時序列化外層所使用的 XmlElement 標籤，以及在傳遞的參數前面均使用 XmlElement 宣告為 XmlSchemaForm.Unqualified。
如下例子：
什麼是 XmlSchemaForm.Unqualified 呢？因為另一個典型傳值失敗的例子在於 SOAP 在 Binding 時，XSD 內定義的 Namespace 不同所致，怎麼說呢，看看下面的圖就了解了。
如圖中，左邊的 Namespace 是 soapenv，右邊的是 soap，有時在接收 Java 傳遞過來的參數就會得到 NullReferenceException 的錯誤，因此，如圖中，只要在方法中與參數前面均宣告 [XmlElement(Form=XmlSchemaForm.Unqualified)]，他會讓 SOAP 訊息項目中忽略命名空間的前置詞，如此一來就可解決這個問題。
結語：
有時與其它平台界接時會發現，有時並不是 Web Services 本身有問題，或是開發工具對 SOAP 規範支援的不完整，只是我們對於 Web Services & SOAP 底層技術的運作不夠了解所造成的。而透過一些測試工具如 soap UI 這種強大且靈活的工具可以幫助我們了解與解決這種類似的問題。
簽名：
學習是一趟奇妙的旅程
這當中，有辛苦、有心酸、也有成果。有時也會有瓶頸。要能夠繼續勇往直前就必須保有一顆最熱誠的心。
軟體開發之路（FB 社團）：https://www.facebook.com/groups/361804473860062/
Gelis 程式設計訓練營（粉絲團）：https://www.facebook.com/gelis.dev.learning/
如果文章對您有用，幫我點一下讚，或是點一下『我要推薦』，這會讓我更有動力的為各位讀者撰寫下一篇文章。
非常謝謝各位的支持與愛護，小弟在此位各位說聲謝謝!!! ^_^
