I think the issues of reliable messaging and notification have been addressed by the WS-Reliablemessaging and WS-Notification standards. The WS-ReliableMesaging addresses how web services messaging can e done in a fashion that leaves the requester and provider no doubts as to whether any particular message as received. The WS-Notification addresses how to publish and subscribe (pub/sub) notification massages in web services environment. Al the best
Ashraf Galal On Sun, Dec 7, 2008 at 5:02 AM, Udi Dahan <[EMAIL PROTECTED]>wrote: > I've put a short article up on my blog about the whole issue of lost > notifications and pub/sub. > > > > Lost Notifications? No > Problem.<http://www.udidahan.com/2008/12/07/lost-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]<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 > > >
