--- In [email protected], "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. I'd argue that the bulk of solutions implemented over pub/sub rarely if ever change the subscribing members. 1 publisher. 1-3 subscribers that don't change. So we introduce a flexible (and more complex) solution approach that needs neither. > The crux is, IMO, what is the semantic thing that you are pub/sub- > ing? Agreed. IMO, pub/sub is for things where: 1) publishers/process really don't care who is subscribing, nor if the messages get lost now and then (which is more or less the problem Ranadive and others addressed when they created TIB); 2) the subscribers change from time to time. IMO and IME, those two criteria (relatively) rarely exist in business oriented systems. > If the thing represents a command (imperative, present tense) like > place order, bill customer, etc, I'd say that pub/sub is a poor > solution. I more or less agree, but I'm of the opinion that pub/sub is a poor solution in more situations than others tend to believe. -Rob
