緩存SOAP響應

Question

我們當前的應用程序必須以SOAP風格服務的形式與SAP PI層交談。不幸的是，這個服務層沒有實現任何形式的緩存，導致響應時間很長，甚至對於後續請求也是如此。我們認爲我們有兩種選擇來解決這個問題。請注意，這些是HTTP POST。

• 緩存我們在第一次調用後創建的java響應對象。
• 通過引入緩存代理來緩存xml響應。在這裏驗證和檢查緩存響應似乎更加困難，因爲它涉及到請求主體。

我們想知道，如果任何人有兩種方法，或當遇到類似的情況，你會怎麼解決這個問題的任何經驗

Answer 1

你運行工作了你的緩存機制的路徑之前請記住哪些服務和流程（SOA和BPM）是關於什麼的。它們旨在抽象出基於標準接口背後的某種業務功能的實際實現。

當你說有很高的響應時間時，你分析了延遲的來源是什麼？

• 您的延遲有多少是網絡延遲？
• 集成堆棧讀取和寫入SOAP請求和響應的數量是多少？
• 是否還有其他開銷，例如記錄或持續請求/響應（例如，如果使用持久性消息傳遞作爲傳輸層）？
• 在SAP PI中實際處理請求的時間有多少？

您所調用的服務和流程應被視爲黑匣子，即您不必知道封面背後發生了什麼，只是它正在執行您要求的功能。但是，如果您實施緩存，則假定您所調用的服務沒有副作用，如更新數據，保留審計跟蹤，向其他方或系統通知事件等。因此，即使你找到了一個實現緩存需求的技術方式，你可能實際上正在破壞服務實現。對於您的應用程序，它看起來不錯，但是您可能會影響其他您不知道的系統或進程。

如果你有信心，你知道你在做什麼，那麼一定要看看緩存。通過存儲響應對象在應用程序中實現它可能會最快，但不會被其他應用程序使用，因此性能優勢將被本地化。如果你採用這種方法，你可能仍然要考慮建立一個選擇性緩存機制，而不是全部應用。

某些ESB甚至XML網關/設備具有緩存功能。例如，我知道IBM DataPower設備具有文檔緩存功能，您可以在其中控制緩存哪些服務/ URL以及這些緩存副本具有何種生存時間。這種方法的優勢在於爲所有SAP服務的使用者提供所需的性能提升。請注意，緩存會增加內存消耗，因此如果您不仔細處理，可能會導致您的應用程序或ESB或您實現的任何內存耗盡內存不足。 DataPower似乎有一個不幸的習慣，就是在沒有告訴任何人我們在項目中遇到這個問題時重置自己！ :)

希望有所幫助。