I'm in complete agreement with you on this. Pub/sub encourages hand-offs and "just trust me" types of designs. Invariably we find that the initial trust is misplaced and so elaborate approaches to monitor the pub/sub fabric are devised. Some folks use pub/sub as the default approach unless there is a reason not to. My preference is the reverse--use pub/sub only when there is a compelling reason to do so. For me, "completely decoupled" (which is unachievable) and "can add subscribers over time" are not compelling enough on their own.
Pub/sub can be very useful. And robust systems can be developed using that interaction mechanism. We just need to be wary of notions like "completely decoupled" and "the middleware will manage it all so the endpoints don't have to care" because endpoints in most business integrations do care. -Rob --- In [email protected], Gregg Wonderly <[EMAIL PROTECTED]> wrote: > > Rob, do you think that any network protocol can ever be better than > TCP? In the past, I elaborated here the very notion that you > should in fact never consider the network more than a UDP packet > conveyer. Each node in your pub/sub system, between the producer > and final consumer is just a "router". Routers don't store > and maintain packets, they make their best effort. > > Data will be lost. Data will be corrupted in processing. Data > will not make it where you want it to go, everytime. Why? Because > software/hardware has bugs! > > A resilient system design includes the ability to manage this, end > to end. A robust system design, doesn't try to make the "network" > do more than it is capable of. > > Gregg Wonderly >
