Most typical scenario is when a user works in a GUI of an application and needs to get information from another system.
There can also be transactional interfaces of this type. A part of process orchestration (SC-EPO) can look-up data in another systems or create an object in another system where the ID needs to be immediately returned, and used in the rest of the orchestration. It is also the basic component for composite services that perform several service calls at once, (SC-SOC), see next scenario.
Even if triggered by an end user, the SC-SOM interfaces are still application-to-application or B2B to application, because there is a system or at least a web-browser between the user and the integration solution.
The implementation of these interfaces can be both synchronous via http REST/ SOAP and asynchronous, with messages on queues in real-time.
A request reply (SC-SOM) can also be technically synchronous on SOAP from the caller, and asynchronous on queues against the target, and the opposite.
The preferred method to promote re-use of these interfaces is to implement all request-reply interfaces in common message models on the ESB, exposed on a common API Gateway (S2SAPIM)
The business functionality required by the business should be modeled as a set of services provided by a consistent set of discrete and unique business functions. Each component providing unique services. This will enable the enterprise to identify and remove duplication and help with aligning IT systems to business functionality.