我的消息吃了我的服務(wù)器！Kyle指出，通常，Web服務(wù)開(kāi)發(fā)者開(kāi)始經(jīng)歷“內(nèi)存溢出”的錯(cuò)誤或者奇怪的“性能問(wèn)題”時(shí)，總是會(huì)發(fā)現(xiàn)服
務(wù)器擁有極高的處理負(fù)載，CPU使用率接近100%，以及較低的吞吐量和高網(wǎng)絡(luò)延遲。導(dǎo)致這些癥狀的典型原因是非常大的（有時(shí)會(huì)達(dá)到50
MB或者更大）消息。而且，這些大消息往往包含了非常大的、作為XML消息主體的、采用base-64編碼的二進(jìn)制編碼信息。導(dǎo)致其發(fā)生的原因通常是：
……開(kāi)發(fā)者不理解技術(shù)的局限性：XML處理對(duì)解決許多問(wèn)題都有用，但是你必須認(rèn)識(shí)到消息是要被解析的——并且在大多數(shù)……產(chǎn)品中，這就意味著許多或者所有的消息都會(huì)駐留在內(nèi)存中。
Kyle建議采用如下方法來(lái)改善這種情況：
- 不要發(fā)送冗余信息。在許多情況下，發(fā)送二進(jìn)制數(shù)據(jù)時(shí)，你可能會(huì)發(fā)現(xiàn)消息高度重復(fù)。如果是這樣，你可能就要考慮在HTTP層面使用壓縮技術(shù)來(lái)改善你的網(wǎng)絡(luò)延遲。雖然這不會(huì)幫助你處理負(fù)載，但可能有助于減輕其中一個(gè)問(wèn)題。
- 在XML消息體中，根本不要嵌入二進(jìn)制信息。這是較好的解決方法，還有幾種不同的途徑可以實(shí)現(xiàn)這一效果。比如，你可以使用帶有附件的SOAP或者消息傳輸優(yōu)化機(jī)制（MTOM）繞過(guò)解析開(kāi)銷(xiāo)，盡管這無(wú)助于網(wǎng)絡(luò)延遲問(wèn)題。
- ……還有一個(gè)更好的辦法，使用SOAP根本不發(fā)送大的二進(jìn)制blob。替代方法，通過(guò)受控的文件傳輸系統(tǒng)，使用一個(gè)“帶外數(shù)據(jù)”傳輸……或者“聲明標(biāo)簽（claim Check，參見(jiàn)《EIP模式》或這里）”模式，避免在SOAP和HTTP上發(fā)送大的二進(jìn)制文件。
任何一種技術(shù)都有它使用的環(huán)境，在做架構(gòu)設(shè)計(jì)的時(shí)候一定要避免因?yàn)閭€(gè)人的偏好，無(wú)意識(shí)的舍棄某些選擇。 一種簡(jiǎn)單的方法論是，根據(jù)需要達(dá)到的目的，列出所有可能的實(shí)現(xiàn)方案，最后做出決定。
不好意思，你的數(shù)據(jù)正在顯示。根據(jù)Kyle所說(shuō)，另一個(gè)典型的Web服務(wù)的“性能問(wèn)題” 是，使用Web服務(wù)的層面非常、非常低——通常Web服務(wù)跟一個(gè)SQL語(yǔ)句相關(guān)，這是因?yàn)椋?/p>
誤解了SOA架構(gòu)原則。一個(gè)優(yōu)秀SOA架構(gòu)的關(guān)鍵原則是你的服務(wù)應(yīng)該具有高復(fù)用性。
根據(jù)Kyle所說(shuō)，這些情況通常發(fā)生在：
……如果設(shè)計(jì)是根據(jù)現(xiàn)有代碼“自上而下”衍生出服務(wù)，這類服務(wù)就會(huì)出現(xiàn)；通常，開(kāi)發(fā)者會(huì)看著他們現(xiàn)有的架構(gòu)圖并且決定將架構(gòu)中的每一層（包括表現(xiàn)層）轉(zhuǎn)變成服務(wù)集。
相反，在SOA架構(gòu)的正確位置使用粗粒度的Web服務(wù)會(huì)更好。再次強(qiáng)調(diào)，檢查一個(gè)架構(gòu)的標(biāo)準(zhǔn)分層模型，通常在架構(gòu)中會(huì)有一個(gè)明確定義的地方已經(jīng)封裝
了系統(tǒng)業(yè)務(wù)邏輯。可以使用“遠(yuǎn)程門(mén)面模式（Remote Facade Pattern）”來(lái)包裝這些服務(wù)，以便用合適的方式來(lái)暴露基于模型的服務(wù)。
同樣是可以利用方法論來(lái)避免問(wèn)題，但對(duì)于粒度的把握就是一個(gè)經(jīng)驗(yàn)的問(wèn)題。
模式（Schema）？我們不需要任何發(fā)臭的模式！
Kyle指出，通常開(kāi)發(fā)者試圖重用現(xiàn)有代碼來(lái)生成和解析作為Web服務(wù)實(shí)現(xiàn)基礎(chǔ)的XML。這些實(shí)現(xiàn)通常使用XML解析器來(lái)編組/解組消息，同時(shí)使用
Java
HTTP類來(lái)發(fā)送和接收XML文檔。使用Web服務(wù)時(shí)，通用的方法是，創(chuàng)建使用模式元素的WSDL文檔，使XML不受阻地通過(guò)，然后在現(xiàn)有代碼中對(duì)它們進(jìn)
行解析。
這個(gè)問(wèn)題的癥狀是組織沒(méi)有看到SOA承諾的好處，而且維護(hù)他們的解決方案似乎比以前使用Web服務(wù)的時(shí)候更難（而不是更容易）
簡(jiǎn)單的解決方案是，每當(dāng)寫(xiě)Web服務(wù)時(shí)，不管使用WS-*標(biāo)準(zhǔn)還是使用REST方法，都要確保你創(chuàng)建了代表你文檔結(jié)構(gòu)的完整準(zhǔn)確的XML模式。
如果你正在構(gòu)建WS-* Web服務(wù)，那么這個(gè)XML應(yīng)該被包含在描述你的Web服務(wù)的WSDL之中。即使你在使用REST方法，擁有易于訪問(wèn)的XML模式將鼓勵(lì)你的服務(wù)被重用。