Patrick,
Actually, javaspaces provide fault tolerance via replication instead of durability, but, ok. I'm quite familiar with using these kinds of technologies in scenarios similar to that which I outlined in my blog post and there are other issues that aren't magically handled by the space, still requiring solutions like those I outlined. For instance, when a publisher puts a message/event into the space, how long of a lease should it have? Too long and you may run out of memory in the space, too little and subscribers that were unavailable can miss it. That being said, these memory based solutions can be much more performant than disk based solutions. Thanks, -- Udi Dahan - The Software Simplist From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick May Sent: 07 December 2008 16:32 To: [email protected] Subject: Re: [service-orientated-architecture] Re: Roch Clarifies Some Key Terms There is an alternative to implementing durable subscribers by persisting messages to disk for each subscriber. A JavaSpace provides durability in-memory, with each message stored only once. Publishers and subscribers can join and leave at any time without the need for complex coordination. I'll refrain from advertising on Gervas' list, but I work for a company that sells a distributed, highly available space implementation that is interoperable across multiple languages. It is frequently used to address exactly the issues you mention in your blog post. Regards, Patrick -- http://www.spe.com/pjm On 7 Dec 2008, at 05:02, Udi Dahan wrote: 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 OfRob 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 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: 06/12/2008 16:55
<<image001.jpg>>
<<image002.jpg>>
