Overview of Some Readings on Events

Posted by Dru Sellers on April 14, 2010

I recently gave a presentation in Kansas City where I mention several books that I have read on messaging and events in general. For easy reference here are those books with a brief review of each one.

IMG_0848.JPG

  • Enterprise Integration Patterns

    Considered by many to be ‘the’ text on messaging. I like that it gives pros and cons to messaging and other integration styles.

  • Enterprise Service Bus

    Builds on top of EIP, and carries forward on the ESB pattern. I really enjoyed this book and it is usually one of my top recommendations. I especially like chapter 9 which discusses the bloat that is introduced by batch based latency.

  • The Power of Events

    I enjoyed this book because it was one of the first books I read on Complex Event Processing, something that is going become more and more important as event processing becomes mainstream. It also introduced me to composed events and some of the finer notions of events in general.

  • Event-Based Programming

    I liked this book because it talks a lot about coupling and the various types of coupling. It also contains some ‘conversation’ patterns work building evented systems.

About Dru Sellers

Sr. Software Engineer at Dovetail Software.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.michaelhamrah.com/blog Mike H

    I’m curious how some of the patterns in these are represented with MassTransit. Dependencies were the biggest issue when I experimented with the framework; mainly because the subscriber would register itself with the publisher (via some sort of middleman), but when the subscriber exited, it would unregister itself and not receive any more notifications. Later on, if it came back online, there wouldn’t be messages waiting to be processed; instead, it would start listening for any new content.

    I’d love some insight where the pub/sub model works when the dependency is a non issue, and how to deal when it’s essential to store messages until a sub “wakes up” to handle messages. (I think this is called a dead letter-queue)?

  • http://phatboyg.lostechies.com/ Chris Patterson

    @Mike: If you need your subscription to persist, just don’t unregister it. Every time you restart your application, the old subscription is removed and replaced with the new one. If you need to ultimately remove the subscription later, the SystemView tool has a right-click option to remove a subscription from the store.

    If you have an event that -must- be consumed, considering using something other than pub/sub to -source- the event, such as a static route (.Route<> in MT, which can use an endpoint URI read from a config), or just sending directly to an endpoint without actually spinning up an instance of the bus (since you aren’t receiving).

    At least, that’s how we deal with it. Different patterns for different needs.

  • http://www.michaelhamrah.com/blog Mike H

    Thanks, I like those two options. It’s been great MT evolve over the past couple of years- good job!