There are some interesting fields of application for high-performance, messaging-oriented middleware such as finance, medicine, and, in general, whenever there is the need of exchanging a chunk of information in a very fast way.

Throughout this book, we will use the same fictional example that will help us to describe, chapter by chapter, the various functionalities of HornetQ both for software coding and framework configuration. The example may seem far from everyday software coding, with a database as a backend, and a frontend that could be a web interface or a GUI. However, the trickiness of the configuration and of its requirements will really help you see the advantages of using HornetQ to exchange messages.

Our fictional example deals with a software house that is developing a software called HomeECG. The main purpose of this software is to allow people to do an Electrocardiography (ECG) exam at home. An ECG device is able to detect and amplify the tiny electrical changes on the skin that are caused by the heart during contractions. Using such biophysical signals, a doctor is able to detect abnormal heart functionality. Every person who needs this capability at home will be equipped with a device that is able to trace the ECG, and send the data using an HTTP connection to a server inside a health care institution.

Describing how such a system works is outside the scope of this book, so we won't explain in detail all the requirements such a measurement device should have. For the purpose of our demo, the important thing is that we have many messages coming from different patients, which need to be stored in a queue and transformed, to be inserted in a more structured way inside a database system.

Considering this case, we also have to deal with some important performance issues arising from the fact that a normal ECG could take three different measurements ten times per second. So our HomeECG framework should be able to manage—if one hundred patients do the ECG for ten minutes, all at the same time—potentially, nearly two billion messages!

So we need a messaging framework that is able to process a large number of messages (such as ECG measures) in an asynchronous way and store them in the final database. Now that we have described our fictional software, we need to move onto a developer PC to see how to install and configure a full, testing environment.