Mark Turansky detailed his implementation of a POJO message bus architecture using Terracotta and Java 5. Instead of using an MQ or JMS based deployment, Mark took advantage of the Terracotta architecture to create his POJO message bus. This allowed for a clean, simple, and inexpensive infrastructure solution to his message needs. One item of note about the process was:
Our second implementation... used JMS [because] ActiveMQ is also open source, mature, and Camel looked very cool insofar as they give you a small domain specific language for routing rules between queues.
There were some problems getting ActiveMQ to work well for them. This led to reviving research into using Terracotta . Thanks to good design, the team swapped out the old messaging structure and brought in the new one with relative ease:
All JMS-related code was hidden by handler/listener interfaces. Our consumer logic did not know where the messages (our own domain objects) came from. Implementations of the handlers and listeners were injected by Spring. As a result, it took just 90 minutes to swap in a crude but effective queueing and routing system using Terracotta. We've since cleaned it up, made it robust, added functionality for business visibility, and load tested the hell out of it. It all works beautifully.
The main components for the messaging system included:
- Java 5's concurrent API for queueing (especially bounded java.util.concurrent.LinkedBlockingQueue)
- some knowledge of Java threading
- insight into long running Java processes (with help from how Tomcat does it)
- an above average understanding of classloaders and how to name them
- and how to "spool" requests
The rest came from investigating and understanding how Terracotta works with classloaders, objects in clustered memory, and concurrency. Terracotta itself provided the messaging backbone and glue:
Last but not least, you need some queues, you need multi-JVM consumers, you need persistent data (a message store) that won't get wiped out with a catastrophic failure, you need business visibility to track health and status of all queues and consumers, and you need to glue them all together. Terracotta Server handles these requirements very well.
In the end, Terracotta allowed for using the Java 5 concurrent API to provide "in memory" POJO message queues for the Producers to post onto and for competing Consumers to pull from. By implementing the Consumers as long running daemon processes using bootstrap loaders, the architecture provided grid computing capabilities with POJO simplicity.
Mark also described the developer friendliness of the architecture:
[Terracotta] lets us make an entirely POJO system that runs beautifully in IntelliJ. A single "container" type main program can run all our components in a single JVM simply by loading all our various Spring configs. Developers can run the entire messaging system on their desktop, in their IDE, and run their code against it. They can post messages to an endpoint listening on 127.0.0.1 and debug their message code inside the messaging system itself.
The implementation allowed them to have simplicity, scalability, and reliability for little cost. Mark also said that rolling his own minimalist framework alllowed his team to have large amounts of freedom and flexibility in the implementation. They were able to avoid being locked into any heavy-weight application server API dependencies and maintain a very small footprint (the entire implementation is in a 100KB jar file).
The Terracotta FAQ says that they do not advocate replacing JMS with Terracotta but Terracotta, Inc. CTO Ari Zilka liked what Mark had to say.
In related news, Jonas Boner had details about using Terracotta to cluster Scala actors to perform Fork/Join or Master/Worker processing.