……開發者不理解技術的局限性：XML處理對解決許多問題都有用，
但是你必須認識到消息是要被解析的——并且在大多數……產品中，
這就意味著許多或者所有的消息都會駐留在內存中。

不要發送冗余信息。在許多情況下，發送二進制數據時，你可能會
發現消息高度重復。如果是這樣，你可能就要考慮在HTTP層面使用
壓縮技術來改善你的網絡延遲。雖然這不會幫助你處理負載，但可
能有助于減輕其中一個問題。 

在XML消息體中，根本不要嵌入二進制信息。這是較好的解決方法，
還有幾種不同的途徑可以實現這一效果。比如，你可以使用帶有附件
的SOAP或者消息傳輸優化機制（MTOM）繞過解析開銷，盡管這無助于
網絡延遲問題。 

……還有一個更好的辦法，使用SOAP根本不發送大的二進制blob。
替代方法，通過受控的文件傳輸系統，使用一個“帶外數據
”傳輸……或者“聲明標簽（claim Check，參見《EIP模式》或這里）”
模式，避免在SOAP和HTTP上發送大的二進制文件。 

誤解了SOA架構原則。一個優秀SOA架構的關鍵原則是你的服務
應該具有高復用性。

……如果設計是根據現有代碼“自上而下”衍生出服務，這類服務
就會出現；通常，開發者會看著他們現有的架構圖并且決定將
架構中的每一層（包括表現層）轉變成服務集。

相反，在SOA架構的正確位置使用粗粒度的Web服務會更好。再次
強調，檢查一個架構的標準分層模型，通常在架構中會有一個
明確定義的地方已經封裝了系統業務邏輯。可以使用“遠程門面
模式（Remote Facade Pattern）”來包裝這些服務，以便用合適
的方式來暴露基于模型的服務。

這個問題的癥狀是組織沒有看到SOA承諾的好處，而且維護他們的
解決方案似乎比以前使用Web服務的時候更難（而不是更容易）

如果你正在構建WS-* Web服務，那么這個XML應該被包含
在描述你的Web服務的WSDL之中。即使你在使用REST方法，
擁有易于訪問的XML模式將鼓勵你的服務被重用。