Rob Eamon wrote: > --- In [email protected] > <mailto:service-orientated-architecture%40yahoogroups.com>, "Udi Dahan" > <[EMAIL PROTECTED]> wrote: > > > > However, I'd assert that there are advantages to a pub/sub approach > > over a non-pub/sub approach, not the least being that additional > > subscribers can be added into the ecosystem without changes to pre- > > existing members. > > That is a value of pub/sub, one that I think is touted well beyond > its actual benefit. It is indeed relatively easy to add a new > subscriber. What is less easy, and rarely mentioned, is the > additional work that is usually needed to monitor and manage that new > connection. > > Pub/sub works best in a fire and forget mode--where publishers don't > care if the message makes it. IME, many publishers care very much > that the message gets to the intended recipients. Most business > solutions don't lend themselves to "I don't care if the message > doesn't make it." So one ends up creating elaborate monitoring and > retry facilities to tend to the pub/sub garden.
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
