xml - 缓存 SOAP 响应

Question

我们当前的应用程序必须以 SOAP 样式服务的形式与 SAP PI 层对话。不幸的是，这个服务层没有实现任何形式的缓存，导致响应时间过长，即使对于后续请求也是如此。我们认为我们有两种选择来解决这个问题。请注意，这些是 HTTP POST。

• 在第一次调用后缓存我们创建的 java 响应对象。
• 通过在两者之间引入缓存代理来缓存 xml 响应。在这里使缓存响应无效和检查似乎更加困难，因为这将涉及窥视请求主体。

我们想知道，如果有人对这两种方法有任何经验，或者遇到类似情况，您会如何解决

Answer 1

在您着手制定缓存机制之前，请记住服务和流程(SOA 和 BPM)是关于什么的。它们旨在抽象出基于标准的接口(interface)背后的某种业务功能的实际实现。

当你说响应时间高的时候，你分析过延迟的根源是什么吗？

• 您的延迟有多少是网络延迟？
• 集成堆栈读取和写入您的 SOAP 请求和响应有多少？
• 是否有其他开销，例如请求/响应的日志记录或持久化(例如，如果使用持久消息传递作为传输层)？
• 在 SAP PI 中实际处理您的请求有多少延迟？

您正在调用的服务和进程应被视为黑盒，即您不必知道幕后发生的事情，只需知道它正在执行您要求它执行的功能即可。

但是，如果您实现缓存，则假设您正在调用的服务没有副作用，例如更新数据、保留审计跟踪、通知其他方或事件系统等。因此，即使您找到一种实现缓存需求的技术方法，您实际上可能会破坏服务实现。对于您的应用程序，它看起来不错，但您可能会影响您不知道的其他系统或进程。

如果您确信自己知道自己在做什么，那么一定要看看缓存。通过存储响应对象在您的应用程序中实现它可能是最快的，但不会被其他应用程序使用，因此性能优势将被本地化。如果您采用这种方法，您可能仍要考虑构建一种选择性缓存机制，而不是应用于所有机制。

一些 ESB 甚至 XML 网关/设备具有缓存功能。例如，我知道 IBM DataPower 设备具有文档缓存功能，您可以在其中控制缓存哪些服务/URL，以及这些缓存副本的生存时间。这种方法的优势在于可以为 SAP 服务的所有消费者提供您所寻求的相同性能提升。

另请记住，缓存会增加内存消耗，因此如果您不小心处理它，可能会导致您的应用程序或 ESB 或您用来实现它的任何东西耗尽内存。当我们在项目中遇到这个问题时，DataPower 似乎有一个不幸的习惯，就是在不告诉任何人的情况下自行重置! :)

希望对您有所帮助。