Claim Check Pattern for multi hop BW integration with large payload

Problem:
With client adapter, enterpise orchestration service and provider adapter, exchanging large XML messages, JMS is a bottleneck - big message is usually stored to disk with expensive allocation (expansion) of data store. Piping it from disk to JMS session is also slow. With modern hardware 20MB of XML may be transported 20 seconds in one way. With every hop there is increased JMS overhead.

Solution:
From the last BW component return autogenerated HTTP URL pointing to this component HTTP listener - instead of large XML payload. Render original payload as XML and put it to Java static HashMap. HTTP Get should return from HashMap value for given key. HTTP listener should use Tomcat as underlying implementation with forced compression. HTTP Get should be performed using Accept-Encoding: gzip. The first BW component should analyze response message, detect that payload should be extracted via HTTP and unpack it transparently.

Pros:
KISS solution. Simple design, easy to implement.

Cons:
The last BW component needs HTTP port.