In addition to getting the REST interface working, I just finalized some code that helps writing MDBs easier on this stuff. There is a sample MDB app that you can build and try out if you want that shows this stuff in action: https://github.com/rhq-project/rhq-msg/tree/master/rhq-msg-samples/rhq-msg-sample-mdb

Here's a very quick summary:

1) if you want to send a message to an MDB but want that MDB to reply back with a response (we call this "RPC" for lack of a better and easier word to type ), your MDB should extend RPCBasicMessageDrivenBean and all you need to do (aside from annotating your MDB with the normal things so it can hook up to the proper queue or topic) is implement onBasicMessage() method - which accepts a message and returns a message (of any type derived from BasicMessage). To see an example, here's the sample MDB - you can see its pretty trivial: MyRPCMDB. The message types you expect to come in, as well as what you are going to return are paramaterized in the class definition using standard Generics notation.

2) Similarly as above, if you want to send a message to an MDB but do not expect any response sent back ("fire and forget") your MDB should extend BasicMessageListener and again all you need to do (other than annotate it properly) is implement onBasicMessage(), but this time (because no response is expected) it returns void. To see an example of what this type of MDB would look like, here's the one from the samples app: MyMDB and again you can see its pretty trivial and easy to code this up.

If you want to see what the client side looks like, here's the sample MDB app's servlet (which acts like a client - it is the thing that sends the messages to the MDBs): QueueSendServlet - you will want to concentrate on the fireAndForget() and rpc() methods.

Here is my initial thoughts on the messaging on the agent side.

I've got the "agent" distribution where it can now deploy your own "plugins". I put these in quotes because I really do not want to confuse these names with the current RHQ concepts. The "agent" distribution (located currently at the rhq-next-agent-distro mvn module) is a Wildfly 8.2 container that has the message broker extension AND the message resource adapter installed, along with the agent extension. The agent extension today is very little - it just deploys "things" that it finds in its own deployments directory. These are "plugins" for lack of a better term right now - these can be wars, ears, or jars. They will get deployed in wildfly using the normal mechanisms. These are here rather than the deployment scanner directory (standalone/deployments) because this is how we should be deploying things to prepare for being patched (the wildfly patch mechanism is meant to patch module extensions, not hot deployments found in the deployment scanner directory).

So to see it in action, just build all of rhq-msg, all of rhq-next-agent, then in rhq-msg/rhq-samples/rhq-sample-mdb copy the mdb war (see the target/ directory) into the agent distro's modules/.../org/rhq/next/agent/main/deployments. Start the agent via standalone.sh and you can run the sample MDB (point brower to http://localhost:8080/sample-mdb )

What's the point? Well, now we have a full container that can host any component that wants to hook to the RHQ.next bus. You take this agent distro and you can deploy your component (which can be an ear or a war for example) and you can talk to the bus (since the agent provides you with the messaging infrastructure already defined for you). We can eventually put some functionality into the agent extension itself, but I don't know what that would be yet.

The thinking there was we've been in discussions, and are being guided to integrate, with the fabric team and their stuff and their underlying messaging framework was activeMQ. Figured it would be nice to use that directly rather than some bridge. Might also lend ourselves to productize on JBoss A-MQ in the future.