Hawkular Bus

Work under the new Hawkular umbrella has begun. More information about this new project will trickle out more and more from the team members in the coming weeks and months ahead. There's already a Twitter feed and a developer mailing list.

Here I'll briefly discuss the hawkular-bus work I've done.

The idea is that the hawkular-bus provides a framework to hook into a messaging bus including a Wildfly container that provides all the messaging infrastructure setup for you as well as a convienence API that frees you from the annoying JMS boilerplate code that you typically have to write when it comes to developing bus applications and EJB MDBs in Java.

hawkular-bus also has a REST API that allows any client (Java or non-Java) to produce messages on the bus or consume messages off the bus.

The container that you can use to deploy your bus-based components (be they WARs or EARs or Wildfly module extensions) is called a hawkular-nest. It is simply a pre-configured Wildfly server - it provides the necessary module extensions that give you the messaging infrastructure such that all you need to do is deploy WARs and EARs to it and they can immediately take advantage of the hawkular framework. You can deploy your WARs and EARs directly in the nest module extension (modules/system/layers/base/org/hawkular/nest/main/deployments), thus immediately allowing your applications to be patchable using Wildfly's patching mechanism. In the future, we may want to use this deployment to be able to deploy some kind of "Hawkular Plugin" but nothing has been fleshed out. Right now, WAR and EAR deployments make it easy for you to plug into the hawkular message bus. There is even a hawkular-bus-mdb API that provides an API to allow your MDBs to easily process RPC-like messages (that is, your MDB can not only listen for messages on the bus but then immediately return a response back to the client that sent the message).

I then prototyped a hawkular-audit component that uses hawkular-bus. Hawkular-audit is a server-side component that accepts "audit records" over the bus and places them in a backend storage (today, its just an in-memory H2 database - the one that comes with Wildfly). For example, if you have something that you want to track via an audit trail, that something can put its audit records on the bus and have hawkular-audit store it for you. Your client, if it is Java, can use hawkular-bus API to send the message, or if your client is not Java you can have it use the hawkular-bus REST API to put the message on the bus (for example, using curl).

To try out all this hawkular stuff:

1. Clone both hawkular-bus and hawkular-audit repos
2. Build them by just executing "mvn install" from each repo's root directory.
3. Unzip the distribution from hawkular-audit/hawkular-audit-distro/target and run the "standalone.sh" from the Wildfly's bin/ directory.
4. When the hawkular-audit server starts, it will log its own audit event to record when it started. To see the audit records, point your browser to "http://localhost:8080/hawkular-audit/AuditQueryServlet" and you'll see a simple HTML table with the data.
5. To add your own audit records to the audit trail, run curl to send your audit records over the REST API. For example, try something like this:

    curl -d "body={"subsystem":{"MyComponent":"MySubsystem"},"message":"My audit record message","details":{"key2":"value2","key1":"value1"}}" http://localhost:8080/hawkular-bus/message/AuditQueue?type=queue

Refresh your browser using the same URL mentioned in step 4 above and you'll see your new records.

Hawkular-audit is just a prototype that shows how you can build your own server components to utilize the hawkular-bus and hawkular-nest in order to plug into the bus framework and be able to receive (and send) messages off the bus. In the future, we'll want to cluster the bus so multiple components can talk to each other over one main bus and have clients hook into the bus to send messages to one or more of these server components.