Funny how smaller rooms cause more nervousness than a decent sized crowd for me.

I gave a talk at orug on both the very simple starling, and messaging in general. It was especially nice to see a little interest sparked in messaging in general as it is a really nice way to accomplish asynchronous tasks. SEDA is, in fact, one of my favorite application architecture models.

Among other things, messaging provides a very nice way to scale out. First, you need to be mindful about your asynchronous processes during UI development—users are usually fine with a short wait, or not up to the nanosecond updated stats so long as you handle it somewhat elegantly. Next, you have to consider “Do I really need the return value from this operation?”, if not, it is something you could make asynchronous fairly easily. The bonus here is the ease with which you can move that off to a different server, or servers, as you grow.

To toss SEDA into the mix, you can break up those long processes into multiple smaller stages all communicating via queues. Why? If you have ever taken a look at basic processor design, it is a bit like pipelining. If different stages use different resources, all can be kept busy at the same time. By the same token, you can load up more instances of stages that handle intense processes, and scale back on the quick-to-complete stages.

It is just a lot of fun to look at everything messaging enables (one of the reasons Ruby is so flexible in fact! Its method calls are messages).

Here are some more resources:

• Enterprise Integration Patterns—a good book on messaging patterns in general
• Starling’s Rubyforge
• SEDA’s page
• ActiveMQ—a quick & enterprisey java-based messaging queue
• Spread—a fast c-based messaging queue