Always request-response, same as SC-SOM, but with the integration layer performing several look-ups, potentially in several applications and re-combining and transforming the data for a specific purpose.
This is an additional value that pattern S2SESB can provide in the non-standard cases, and where it is valuable to hide the complexity of several back-end systems for the service consumer.
Looking at new integration problems, one should always look at where it makes the most sense to have this service call orchestration (note: this is not transactional orchestration).
The ESB can be used here as it masks the service caller from the complexities of the underlying systems and provides decoupling to enable easy migration away from old systems when needed; giving IT agility.
Avoid writing multiple services to cater for subtle changes in requirements - if complicated requests can be broken into a collection of simpler more discrete service calls, the smaller / fine grained services will be re-used further.
However, be aware of the impact on performance as there is an overhead in orchestrating the composition of services.