...
The set of Message Channels that are open and available to an application have a tendency to be static. Thus, when designing an application, a developer has to know where to put what should understand the architecture of the channels; where to place which types of data to share that data with other applications, and likewise ensure that it is being shared with the correct application. Also, we should know (on the receiving side) where to look for what certain types of data coming from other applicationssystems.
These paths of communication cannot be dynamically created and discovered at runtime; they need to be agreed upon at design time so that the application knows where its data is coming from and where the data is going to. (While it is true that most channels must be staticly defined, there are exceptions to this theme, cases where dynamic channels are practical and useful. One exception is the reply channel in Request-Reply. The requestor can create or obtain a new channel the replier knows nothing about, specify it as the Return Address of a request message, and then the replier can make use of it. Another exception is messaging system implementations that support hierarchical channels. A receiver can subscribe to a parent in the hierarchy, then a sender can publish to a new child channel the receiver knows nothing about, and the subscriber will still receive the message. These relatively unusual cases notwithstanding, channels are usually defined at deployment-time and applications are designed around a known set of channels.)
...