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

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

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

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

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