Using Mule - Earthquakes on the BUS

Adopting SeisComP3 for locating earthquakes has been a cross cutting change. As I mentioned in a previous post, SeisComP3 makes automatic earthquake locations and as it iterates the solution it releases many updates about an earthquake. Compare this to the current system (CUSP) where we get one or possibly two locations for any earthquake.

The current GeoNet web content is static content that is generated by daemon processes and rsynced to the public web servers. It is event driven; an XML message with earthquake details arrives from the location system, the web content is generated and then copied to the public servers. It takes around twenty to thirty seconds to update the servers. When it takes fifteen minutes or more to make an earthquake location and there is usually only one iteration this time is acceptable. Switching to SeisComP3 means that there are many location messages about an earthquake and they arrive in the few minutes that it takes SeisComP3 to finish iterating the automatic location. Clearly we need a faster way to get locations to the web.

Taking the BUS

To get the earthquake location information to the web quicker we have adopted Mule ESB, an Enterprise Service BUS.

Note: there is often confusion between ESB and messaging (e.g., JMS, AMQP). An ESB implementation will often have messaging as one of its components. A messaging solution on its own is not an ESB.

There are several open source ESB options available. When I was trying them out I found Mule to have a great mixture of features, documentation, community, and training available. Also, if we need them, there are commercial features and support options available beyond the open source version. These are all important features for building long term sustainable software solutions.

Our ESB implementation does have messaging, we use ActiveMQ which implements JMS 1.1. When I get a chance I’ll also try out RabbitMQ which implements AMQP and has some really nice features.

In the time we have been working on this project Mule version 3 has been released. I’ve been having fun converting the ESB configuration from Mule 2 to Mule 3; it has some very nice features that make development, testing, and deployment a lot simpler.

Mule for GeoNet Rapid (Beta)

The primary use of Mule for GeoNet Rapid is to take earthquake messages from SeisComP3, transform them to a simple XML format, send them over the messaging, and insert them into the database. The projects are available under GPL3 on Github:

• seiscomp-producer - takes messages from SeisComP3, transforms them and puts them on the messaging.
• hazbus-xslt - XSLT’s for simplifying the SeisComP3 output. A dependency for seiscomp-producer.
• quake-db-client - inserts quake messages into the database.

Note on loose coupling: Why that transform from SeisComPML to a simple XML format before sending to the messaging? This is loose coupling - the other clients of the ESB don’t need to know about the input format. We have to do a little more work on the input (the message transform) but the benefit is that when the output format of SeisComP3 changes we only have to change the transform and not all the other ESB clients as well.

Conceptually the ESB implementation looks like this.

A reasonable question may be, “Do you really need that ActiveMQ network bridge?” The answer is it’s there to give us a lot of flexibility for when we work on adding other instances of SeisComP3 for geographical redundancy. It’s also useful to abstract away the network configuration from the Mule applications. It remains to be seen if this architecture will make it to full production.

We’ve achieved a lot with Mule. It really makes integration problems like this a lot simpler.

Finally a big thanks to David Dossot and Bruce Snyder for the books they’ve written on these topics and some very useful discussions.