Posts tagged with 'rabbitmq'
Jeremy Miller is using Jasper to distribute computing. This episode is sponsored by Smartsheet.
Show Notes:
-
Nancy (NancyFx) was mentioned
- FubuMVC was mentioned too.
- TIBCO
- webMethods
- RabbitMQ as a "store and forward" queue (video)
- Azure Service Bus
- NServiceBus (from Particular Software)
- More on the Happy Meal metaphor from Jimmy Bogard
- The Oatmeal (comic)
- Jasper website - Jasper on Gitter
- Book: Enterprise Integration Patterns
- For more on Akka, check out episode 062 with Ted Neward
Want to be on the next episode? You can! All you need is the willingness to talk about something technical.
Music is by Joe Ferg, check out more music on JoeFerg.com!
Ted Neward is using the actor model with Akka.
Show Notes:
- Akka.io
- Erlang
- Scala
- Actor Model (c2)
- java.lang.Thread
- Book: Java Concurrency in Practice by Brian Goetz (and others)
- Jonas Bonér (from Lightbend)
- Episode 009 - Correl Roush on Erlang
- RabbitMQ
- Microsoft's Orleans
- JErlang - Erlang for the JVM
- RetLang
- Smalltalk / Objective-C
- Joe Armstrong
- SmartSheet
Want to be on the next episode? You can! All you need is the willingness to talk about something technical.
Theme music is "Crosscutting Concerns" by The Dirty Truckers, check out their music on Amazon or iTunes.
RabbitMQ is a "message broker". Your program gives it messages. Other programs can come along and retrieve those messages and then do something with them. It sits in the middle, so it's often referred to as "middleware".
Why would you want a middleman? Haven't a lifetime of mattress commercials shown that cutting out the middleman is always better?
Not always. Let's build an online store that takes orders and has to tell a warehouse to process the order. Consider these three designs:
- Your website does the work itself.
- Your website passes a message to another program directly.
- Your website passes a message to a broker. Another program picks up messages from the broker.
These are the questions I asked, and below are the conclusions I've come to. If I'm missing anything, please add to the discussion in the comments.
#1 Your website does the work itself
A customer places an order. Since your website is doing all the work itself, it has to: email the customer, charge a credit card, and tell the warehouse to ship the item. What if the warehouse doesn't have the item? Now you have to check another warehouse. While your website is doing this, it has fewer resources available to process other customer's browsing and ordering. So it could become a performance problem as well as a complexity problem. Instead...
#2 Your website passes a message to another program directly.
Let's just tell a warehouse program to do the work, and the website will go about its business. The warehouse program can figure out which warehouse, and send the appropriate information. If it has a web service, we can just push the information. But what if something goes wrong? What if the service is down, or busy, or overloaded? Now we need to build in a retrying mechanism into our website, and we're still managing complexity and putting strain on the website. But what if...
#3 Your website passes a message to a broker. Another program picks up messages from the broker.
Our website just records all the information that the warehouse needs to a message. That message goes on the broker and waits. Once the website dumps the message, it's done, and can go about serving other customers. The warehouse program can ask the broker for messages. It gets a message, does the processing. If it goes well, then the broker can forget the message. If something goes wrong, it's up to the warehouse program to figure out what to do. It could keep retrying, send an email, call a web service, or whatever else you need. If the warehouse program gets overloaded, you can spin up another warehouse program that talks to the same broker. If the warehouse programs crash, the messages will wait on the broker.
It might seem that the middleman's job is very simple, it's very important to ensure that complex operations can be broken down and processed smoothly.
I have been accepted as a speaker for CodeMash 2016. I will be presenting "Convention Over Configuration: Queueing is Easy". This session will demonstrate how EasyNetQ (on top of RabbitMQ) makes it easier to deal with queues by using convention over configuration.
I have started preparing material for this session. One of the ways I'm doing this is by creating a series of short videos. The videos will be more in-depth than the ultimate session, but it gives me a chance to practice, prepare, and organize my thoughts. I usually prepare session material this way; I just don't record it on video.
To date, I've created and release two videos. Check out the playlist on YouTube for RabbitMQ/EasyNetQ.
