缓存SOAP响应

sho*_*han 2 xml soa soap caching web-services

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

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

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

Chr*_*isC 9

在开始编写缓存机制的路径之前,请记住服务和进程(SOA和BPM)的内容.它们旨在抽象出基于标准的界面背后某种业务功能的实际实现.

当你说有很高的响应时间时,你有没有分析延迟的来源是什么?

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

您调用的服务和流程应被视为黑盒子,即您不必知道封面后面发生了什么,只是它正在执行您要求它执行的功能.

但是,如果实现缓存,则假设您调用的服务没有副作用,例如更新数据,保留审计跟踪,通知其他方或系统事件等.即使您发现了技术实现缓存需求的方式实际上可能会破坏服务实现.对于您的应用程序,它看起来不错,但您可能会影响您不了解的其他系统或进程.

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

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

还要记住,缓存会增加内存消耗,所以如果你不小心处理它,你可能会导致你的应用程序,或ESB或你实现它的任何内容耗尽内存.DataPower似乎有一种不幸的习惯,就是在我们遇到项目中遇到这个问题时,不告诉任何人就重置自己!:)

希望有所帮助.