A typical scenario is where a transaction is completed or a customer created or updated, and a number of systems need to be immediately aware.
An Event in a system starts these interfaces.
Often speed requirements are moderate (~< 30s). Volumes are low (< 1/s), and message size is small (<1MB).
In this scenario there is often a (1 - n) situation, where several systems need the update directly to be able to perform their function.
Different parties may want to receive the data in different formats and on different transports. Some systems may want to accumulate the updates until the end of day
With the routing component and different receivers, it is a perfect case for the pattern S2SESB.
This scenario is sometimes combined with a local data hub, S2SLDH that has the capacity to collect and even combine the data from one or more sources, before it is sent out in a way that is suitable for the consumers. This is a central data pattern and can promote decoupling and re-use.
Where possible, implement solely using the pattern S2SESB. Within this pattern there are different ways in which data can be distributed (fire and forget, reply request, publish / subscribe). Further details on which pattern applies and is best to use is given in the book "Enterprise Integration Patterns"
Where data needs to be combined or enriched from multiple sources, the Pattern S2SLDH can be used. The logical data hub then acts as the 'master' for that type of data. The hub will act as a source, using S2SESB to distribute data to receiving systems.
Product Information details. Many systems want to receive the same data, but want to filter out some specific data and receive it in different formats.