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