對于Webservice的編寫，我們可能會犯錯的地方應(yīng)該就是入?yún)⑴c出參了，以上面我們編寫的Webservice為例，它的入?yún)⑹荱serRequest對象，出參是UserResponse對象，可以看到它的入?yún)⑴c出參都只是一個，這并不是巧合，而是故意為之，是一種最佳實踐。

對于入?yún)?，UserRequest對象包含兩個屬性，一個是userCount，一個是targetCompany，也就是說我們的Webservice服務(wù)類需要兩個參數(shù)，但在編寫Webservice的Endpoint時，我們并沒發(fā)將其作為兩個入?yún)⑻幚?，而是將這兩個參數(shù)以屬性的形式放在一個對象當(dāng)中，作為一個入?yún)⑻幚怼＿@樣做的好處是避免了我們手工解析RequestPayload中的XML可能會出現(xiàn)的錯誤（Spring-WS允許我們方法調(diào)用參數(shù)當(dāng)中解析RequestPayload中的XML以實現(xiàn)多個入?yún)ⅲ?，同時即使我們的服務(wù)類需要再多的其它類型的參數(shù)（或者只有一個參數(shù)），我們也可以將其作為這個UserRequest對象的一個屬性處理，簡單且容易理解。

可能你會遇到一種相對較為簡單的入?yún)⑶闆r，那就是這個入?yún)⒅挥幸粋€值，比如只有一個String類型的值，那么對于這種情況我們又該如何處理呢？同樣遵行我們一個參數(shù)的原則，將我們需要端所需要的一個參數(shù)也放在一個我們自定義的對象當(dāng)中，作為這個對象的屬性實現(xiàn)數(shù)據(jù)的傳遞。比如我們之前的例子當(dāng)中，如果服務(wù)端只需要一個userCount參數(shù)，而不需要targetCompany參數(shù)，同樣我們也需要將這個userCount參數(shù)作為一個Javabean的屬性。

討論完入?yún)⒑?，我們來看看出參。對于出參而言，我們同樣要遵循一個參數(shù)的原則，以我們上面所舉的示例來說，出參是一個UserResponse對象，它有一個集合類型的User對象屬性，也就是說，它的出參實際上也是一個值，一個集合類型的值，但我們并沒有將這個集合直接作為出差使用，那是因為系統(tǒng)無法將集合值直接序列化成SOAP的消息部分內(nèi)容，所以我們將這個集合放在一個我們自定義的名為UserResponse對象當(dāng)中，這樣在返回值時，系統(tǒng)會按照UserResponse對象當(dāng)中定義的Annotation將這個返回值序列化成SOAP的消息部分內(nèi)容。

通過以上對入?yún)⒓俺鰠⒌挠懻?，我們總結(jié)出一個結(jié)論，我們基于Spring-WS編寫的Webservice的服務(wù)端方法，無論出參還是入?yún)⒍贾荒苁且粋€參數(shù)，而不能是多個，同時這個參數(shù)必須是我們自己定義的且添加了相關(guān)Annotation(比如@XmlRootElement等)的Javabean，對于服務(wù)端執(zhí)行業(yè)務(wù)時需要的參數(shù)（無論是一個還是多個）都放到這個自定義的Javabean中，作為這個Javabean的標準屬性實現(xiàn)參數(shù)值的傳遞。