實現(xiàn)XML和Web服務(wù)時要避免的三種常見錯誤
IBM的Kyle Brown在其評論文章開始描述了一種常見的情景：“許多人因以不恰當?shù)姆绞绞褂肳eb服務(wù)和XML而給他們自己挖了一個坑”。在他的評論中，Kyle介紹了三個常見的痛點，解釋了它們?yōu)楹螘l(fā)生并提供了一些替代方法。
我的消息吃了我的服務(wù)器！Kyle指出，通常，Web服務(wù)開發(fā)者開始經(jīng)歷“內(nèi)存溢出”的錯誤或者奇怪的“性能問題”時，總是會發(fā)現(xiàn)服務(wù)器擁有極高的處理負載，CPU使用率接近100%，以及較低的吞吐量和高網(wǎng)絡(luò)延遲。導(dǎo)致這些癥狀的典型原因是非常大的（有時會達到50 MB或者更大）消息。而且，這些大消息往往包含了非常大的、作為XML消息主體的、采用base-64編碼的二進制編碼信息。導(dǎo)致其發(fā)生的原因通常是：
……開發(fā)者不理解技術(shù)的局限性：XML處理對解決許多問題都有用， |
Kyle建議采用如下方法來改善這種情況：
不要發(fā)送冗余信息。在許多情況下，發(fā)送二進制數(shù)據(jù)時，你可能會 在XML消息體中，根本不要嵌入二進制信息。這是較好的解決方法， ……還有一個更好的辦法，使用SOAP根本不發(fā)送大的二進制blob。 |
不好意思，你的數(shù)據(jù)正在顯示。根據(jù)Kyle所說，另一個典型的Web服務(wù)的“性能問題” 是，使用Web服務(wù)的層面非常、非常低——通常Web服務(wù)跟一個SQL語句相關(guān)，這是因為：
誤解了SOA架構(gòu)原則。一個優(yōu)秀SOA架構(gòu)的關(guān)鍵原則是你的服務(wù) |
根據(jù)Kyle所說，這些情況通常發(fā)生在：
……如果設(shè)計是根據(jù)現(xiàn)有代碼“自上而下”衍生出服務(wù)，這類服務(wù) 相反，在SOA架構(gòu)的正確位置使用粗粒度的Web服務(wù)會更好。再次 |
模式（Schema）？我們不需要任何發(fā)臭的模式！ Kyle指出，通常開發(fā)者試圖重用現(xiàn)有代碼來生成和解析作為Web服務(wù)實現(xiàn)基礎(chǔ)的XML。這些實現(xiàn)通常使用XML解析器來編組/解組消息，同時使用Java HTTP類來發(fā)送和接收XML文檔。使用Web服務(wù)時，通用的方法是，創(chuàng)建使用模式元素的WSDL文檔，使XML不受阻地通過，然后在現(xiàn)有代碼中對它們進行解析。
這個問題的癥狀是組織沒有看到SOA承諾的好處，而且維護他們的 |
簡單的解決方案是，每當寫Web服務(wù)時，不管使用WS-*標準還是使用REST方法，都要確保你創(chuàng)建了代表你文檔結(jié)構(gòu)的完整準確的XML模式。
如果你正在構(gòu)建WS-* Web服務(wù)，那么這個XML應(yīng)該被包含 |
避免Kyle描述的陷阱似乎是個常識。不幸的是，我們的業(yè)界證明了，除非很好的理解和治理SOA實現(xiàn)，否則我們會繼續(xù)一次又一次地重復(fù)犯同樣錯誤。
【編輯推薦】
