Messaging Channels (EIP Catalog)

When two different applications or systems wish to exchange data, they can accomplish this by transmitting the data through a common channel that connects the two.

The application sending the data may not know (or, even need to know) which application will receive the data (location transparency), but by choosing a specific channel that it is connected on to send the data, it will know that a receiver (connected to that shared channel) will be one that is looking for that sort of data.

In this way, the applications that are producing shared content have the means to transmit it to other applications that have the need to consume that data.

The challenge is knowing what channels your applications will need and what to use them for.

A fixed set of channels

One implementation variation is that the set of Message Channels available to an application will tend to be static and fixed. Therefore, when designing an application, a developer has to know where to put what types of data to share that data with other applications, and likewise where to look for what types of data coming from other applications.

It is understood that these communication routes cannot be created dynamically and discovered at runtime. They will need to be agreed upon during application design to allow each application to understand where its data is coming from and where the data is going.

Determining the set of channels

A related issue is: Who decides what Message Channels are available, the messaging system or the applications? That is to say: Does the messaging system define certain channels and require the applications to make due with those? Or do the applications determine what channels they need and require the messaging system to provide them? There is no simple answer; designing the needed set of channels is iterative. First the applications determine the channels the messaging system will need to provide. Subsequent applications will try to design their communication around the channels that are available, but when this is not practical, they will require that additional channels be added. When a set of applications already use a certain set of channels, and new applications wish to join in, they too will use the existing set of channels. When existing applications add new functionality, they may require new channels.

Unidirectional channels

Another implementation decision is whether our channels will be defined as unidirectional or bidirectional. Actually, it’s neither; a channel is really like a container that some applications add data to and other applications retrieve data from.

But because the data is in messages that travel from one application to another, that gives the channel direction, making it unidirectional. If a channel were bidirectional, that would mean that an application would both send messages to and receive messages from the same channel, which—while technically possible—makes little sense because the application would tend to keep consuming its own messages, the messages it’s supposed to be sending to other applications. So for all practical purposes, channels are unidirectional. As a consequence, for two applications to have a two-way conversation, they will need two channels, one in each direction (see Request-Reply in the next chapter).