Benoit, Have you looked at the DCI(Data, Context and Interaction) architecture stuff from Trygve Reenskaug and James O. Coplien? I don't know if this is the best link for it, but I'm in transition(or should be): http://www.artima.com/articles/dci_vision.html
Essentially what gets lost with pub-sub and likely any event-based integrative (EBI) architecture is that interactions are no longer explicit and less visible, but implicit and so it becomes hard to reason about the behavior of the system at a higher level. DCI is aimed at making interactions a first class citizen. Also check out Orit Shaer's dissertation, chapter 4, section 3 (there's a journal paper that is probably more succinct, but I'm on the run): http://books.google.com/books?id=MQc6WTtulJQC&printsec=frontcover&hl=en#v=onepage&q&f=false In it, she discusses using high-level states to describe the behavior of interactive systems that incorporate physical representations (tangible user interfaces). It's not so much about messaging and pub-sub, but the model presented in the document relates a UI dialogue (both user-system and system-system) to a set of interaction patterns that are supported by system (see https://skitch.com/corntoole/8miq9/cs.wellesley.edu-oshaer-tuiml.pdf). Perhaps, a similar model could be used to encapsulate the relationships between certain message patterns and high-level behavior. (I see that google books omits part of the book germane to this discussion, so here's a link to the journal paper: http://cs.wellesley.edu/~oshaer/TUIML.pdf, see section 2.1.2 ) -- Cornelius Toole Sent with Sparrow (http://www.sparrowmailapp.com) On Monday, March 19, 2012 at 6:33 PM, Benoît Fleury wrote: > Hi Casey, > > the decoupling of the event emitters and receivers is what I find the most > interesting in a pub/sub model. The publisher raises an event (in its > semantic domain) and does not know what subscribers are going to receive it > or what they're going to do with it. One of the advantage of this decoupling > is that you can extend a system without modifying existing parts. > > Practically, I also encountered systems where a pub/sub model helped reducing > the amount of code. A lot of objects needed to be aware of events happening > in the system and instead of having to call all these objects every time > something interesting was happening in the system, we raised an event for > each one of them and had the objects subscribe to these events. > > The other advantage I also felt while using pub/sub model is that it helped > me create better object-oriented design: > - because you can't send direct messages, you don't use your objects as data > structures > - and consequently, all the code that changes the state of your object is > located in the object which makes the system easier to understand > > The issue I have with the event systems I encountered so far is that you gain > the decoupling but lose the expressiveness of message passing. The code in > the subscribers often looks like this: > > cause => effect > cause => effect > cause => effect > > If you want to implement a complex behavior, you need to maintain state and > that becomes quickly harder to understand. That's why I was wondering if you > could interleave the "causes" and "effects" in a grammar to describe the > behavior of an object in a more readable way, be able to reuse rules, having > higher-order rules... > > Benoit > > On Mon, Mar 19, 2012 at 3:35 PM, Casey Ransberger <[email protected] > (mailto:[email protected])> wrote: > > Here's the real naive question... > > > > I'm fuzzy about why objects should receive messages but not send them. I > > think I can see the mechanics of how it might work, I just don't grok why > > it's important. > > > > What motivates? Are we trying to eliminate the overhead of ST-style message > > passing? Is publish/subscribe easier to understand? Does it lead to simpler > > artifacts? Looser coupling? Does it simplify matters of concurrency? > > > > I feel like I'm still missing a pretty important concept, but I have a > > feeling that once I've grabbed at it, several things might suddenly fit and > > make sense. > > _______________________________________________ > > fonc mailing list > > [email protected] (mailto:[email protected]) > > http://vpri.org/mailman/listinfo/fonc > > _______________________________________________ > fonc mailing list > [email protected] (mailto:[email protected]) > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
