I've put a short article up on my blog about the whole issue of lost notifications and pub/sub.
Lost <http://www.udidahan.com/2008/12/07/lost-notifications-no-problem/> Notifications? No Problem. In it I outline how the various performance and availability characteristics of different services may cause a subscriber to miss a notification and how to feed that back into the design process to get a service ecosystem where notifications (different kinds than before) won't be lost or missed. Interested in hearing feedback, especially on how this may impact the issues of monitoring and management Rob raised below. -- Udi Dahan - The Software Simplist From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Eamon Sent: 05 December 2008 19:34 To: [email protected] Subject: [service-orientated-architecture] Re: Roch Clarifies Some Key Terms --- 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. 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 No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.9.13/1826 - Release Date: 05/12/2008 09:57
<<image001.jpg>>
<<image002.jpg>>
