David Dossot

In Mule ESB, outbound dispatching to a destination whose address is known at runtime only is a pretty trivial endeavor. A less frequent practice consists in programmatically defining inbound service endpoints. I recently had to do such thing for a little side project I'm running where Mule is used as a frontal bus and load throttler in front of a R nodes exposed over RMI. The goal was to have a non-fixed number of file inbound endpoints defined in a simple properties file and declare them on a particular service during the initialization sequence of Mule. As an integration framework, Mule ESB exposes all its moving parts and lets you configure them easily with its Spring-powered XML DSL: that's all we need to achieve the above goal. Let's first look at the resulting service configuration: As you can see the inbound router doesn't have any endpoint configured on it. Th... (more)

Monitoring RabbitMQ with Zabbix

If you use RabbitMQ as your message oriented middleware and Zabbix as your monitoring and graphing tool, you're probably wondering how to monitor the former with the latter. Here is the Zabbix Agent configuration I use to keep track of the number of messages pending delivery and the total number of queues (this second parameter may not make sense for you if you don't create a lot of dynamic queues): UserParameter=rabbitmq.local.queues.count[*],sudo rabbitmqctl -q list_queues -p $1 | wc -l UserParameter=rabbitmq.local.messages_ready.count[*],sudo rabbitmqctl -q list_queues -p $1 m... (more)

Integration Testing Asynchronous Services

Whether you use Mule or another integration framework, writing integration tests for asynchronous services can be a little tricky, as you may start running assertions in your main test thread while messages are still being processed. Suppose you want to ensure that your content based router sends messages to the expected target services. Your integration test suite will consist in sending valid and invalid messages to the input channel in front of this router and check they end-up in the expected destination services. But how to be sure that the delivery has happened and it is safe... (more)

Conversation with a Web Thread

DD: Hi Mr. Web Thread and thanks for joining us. WT: My pleasure. Do you mind if I stay in the pool? DD: Hmm? Sure, why not. So, can you please tell us how is your life nowadays? WT: Life has been pretty good. I have become very popular recently and came to perform some massive gigs in highly trafficked web sites. I really like this pool. DD: Mmhh, okay. How do you think developers treat you, nowadays? WT: Well, I am glad you ask. I think things have improved a lot, thanks to the emergence of concepts like continuations and AJAX. Still, I sometimes get badly beaten by some reckless cod... (more)

SOA's Eulogy is Liberating

One of the thoughts I gathered from last night's panel on the possible death of SOA, pertains to the natural consequence of the push back on the WS-DeathStar and the spike of interest in the REST architecture. So what is the consequence of dropping the dream of web-level distributed transactions and beyond-the-firewall data consistency? Except for Juval Löwy (who I guess was playing devil's advocate with a mischievous wit), the panelists were unanimous on the need to create systems that handle failures gracefully, can self-heal and achieve eventual consistency. David Platt said it ... (more)