Message Channel Revisited

I've been a part of several separate conversations about how applications communicate. As a result, I've been thinking in more detail about the Message Channel pattern from Enterprise Integration Patterns. That pattern is still valid, and it was never meant to be the end-all pattern for how applications connect. But I'm now thinking about some other patterns to go with it.

(Some related thoughts have also lead to Mediator vs. Adapter.)

New Patterns

I'm thinking in terms of four patterns:

• Channel – Enables two (or more) threads to exchange data. Data is divided into atomic items (aka documents, packets, messages). Implements an add/remove API (aka produce/consume, get/put, send/receive) with FIFO (First In, First Out) behavior. Support for concurrent access by multiple threads.
• Queued Channel – A Channel where data items are queued for asynchronous access. Optionally provides transactions and persistence.
• Network Channel – A Channel that implements interprocess communication (IPC) so that the threads can be in different processes.
• Message Channel – A combination Queued Channel and Network Channel which enables threads in different processes to exchange data via queued messaging.

These patterns have a supertype/subtype relationship. Channel is the root supertype. Queued Channel and Network Channel are subtypes of Channel and peers of each other. Message Channel is a subtype of both Queued Channel and Network Channel.

Examples

So, what are examples of these patterns?

• Channel – Channel is so abstract that I can't think of any example that isn't also an example of a more specific pattern.
• Queued Channel – This could be a shared collection, such as a Java Queue, a type of Collection. A queue can only be shared by threads in the same process, but that's all that's required.
• Network Channel – This is a network connection, such as Ethernet. Realistically, we see it as a networking protocol such as IP, TCP, HTTP, etc.
• Message Channel – This is a messaging destination, such as a queue or topic, in a messaging system.

Conclusions

What does all this mean? It means you can have channels without needing a full messaging system. A SOAP-over-HTTP invocation is running across a Network Channel, which is a type of Channel but not a full Messaging Channel. It also means that a channel doesn't have to span processes; a Queued Channel lets threads communicate; they don't care whether they're in the same process.