Mismatch
Assume that you’re tasked to create a two component, distributed software system as shown in the figure below. The nature of the application is such that during runtime, component 1 will continuously transmit a “bursty“, asynchronous stream of messages to component 2. During evolution of the system in the future, you know that more and more stages will be tacked on to the “pipeline“, with each stage adding value to a growing customer base (if you don’t screw it up and hatch a BBoM).
Note that the relationship between application components is peer-to-peer and not client-server like this:
One question is this: “Why on earth would anyone choose a client-server messaging system (with peer-to-peer capability tacked on) over a peer-to-peer messaging system for this class of application?“. The question especially applies to product organizations that strive to develop distinctly elegant and innovative solutions – which hopefully includes yours. A second question is: “What would technologically savvy customers think?“. Of course, if you think your customers are dumb-asses (and you won’t be in business for long if you do) and can’t tell the difference, then the situation is a “don’t care“, no?
Leave a comment
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 
If its a real time system and network centric I’d use a UDP Unix domain or Internet domain socket with some kind of Host-to-Wire marshalling class shared between all end points, wait…. isn’t that just DDS??? You don’t want the problems of TCP/IP (a client server and connection oriented protocol). I think you need to elaborate more on the connectionless aspect of the application. If you have security requirements then this all flies out the window.
I wasn’t trying to go down into the next level of detail in the example (connection-oriented vs connectionless, TCP vs UDP, error control, flow control, etc). I was trying to keep the “view” up in the architectural pattern/style space.