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.
To be able to do anything useful, an ESB must be configured with all sorts of
parameters, from endpoint connection URIs to message transformation scripts
to content-based routing definitions. Moreover, ESBs like Mule can host
custom components, which will process messages and perform user-specific
actions on them.
Deploying a new version of an ESB configuration raises the question of
whether it will break anything. How can we build confidence that everything
will be just fine? If unit testing did it for standard software development,
what can it do in the realm of the ESB? Since... (more)
One of the very first CTO-grade decision I had to take in the making of
Snoget was to pick what would become our main transactional persistence
engine. Since we're using Erlang exclusively for our production servers, the
solution seemed easy: use Mnesia. But I settled for PostgreSQL.
At this point, anyone who's been dealing with O/R mapping (like Ted Neward
who said: "Object/relational mapping is the Vietnam of Computer Science"),
should cry fool: Mnesia would offer me persistence without any impedence
mismatch with the application runtime environment and I preferred a SQL
In a recent blog post titled "The Limitations of TDD", Jolt Awards colleague
Andrew Binstock shared some reservations Cédric Beust has about TDD.
When a person of extensive experience like Cédric speaks about testing, you
pay attention. And I did.
Among the very interesting quotes from Cédric that Andrew has reproduced,
the following really struck me:
Another important point is that unit tests are a convenience for *you*, the
developer, while functional tests are important for your *users*. When I have
limited time, I always give priority to writing functional tests. Your duty
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
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)