The WS-Addressing interceptors use a ConcurrentHashMap to store previously encountered MessageIDs. This code does not expire entries in the map nor is the map persisted between restarts or shared across JVMs in a cluster. For these reasons, this approach poses a potential memory usage issue as well as a false sense of security with respect to replay prevention when the service is restarted or multiple instances of the service are running in a cluster. This approach also requires that all services in a JVM that wish to prevent replay must share a single set of addressing interceptors. When used in conjunction with a digital signature and a timestamp providing message expiration, this ID provides a replay prevention mechanism as well as a strong upper limit to the lifetime of MessageIDs in the cache. It is recommended that an abstraction for the cache be implemented such that a simple in memory implementation may be provided by default. For more advanced use cases, an implementation of the cache may be implemented over a cache library that supports disk persistence and/or sharing of the cache across JVMs. I have implemented a simple cache abstraction over the Springmodules cache library with some success in other projects. Springmodules (https://springmodules.dev.java.net/ http://github.com/astubbs/spring-modules/) appears largely dormant at this time, but the ability to choose from a number of cache providers, some of which support distribution across multiple JVMs and disk persistence is exactly the type of flexibility that the solution should afford.