5 Replies Latest reply on Jan 8, 2015 11:37 AM by mazz

    agent and messaging

    mazz

      Just a heads up on what's been done the past few days wrt rhq.next agent and messaging.

       

      Heiko has been playing with the rhq.msg stuff - which includes a broker, Java client API, and a RA integration in JEE. As was suggested by Heiko and John Sanda, I recently incorporated ListenableFuture (guava API) to the client API so it uses that now. In addition, the msg broker can be installed as a Wildfly Extension (so you enable/disable/configure it via the normal standalone.xml or JBoss CLI mechanism). The messaging framework is all based on ActiveMQ so you can use their other client APIs for other language support.

       

      More interestingly, this messaging framework has a REST frontend that I've enabled and shipped in the broker wildfly extension. When you install the broker extension, you can now send and receive messages via REST. This will help enable our "dumb feeds" (as well as anyone else that wants to use the REST API). I've successfully tested this REST interface using simply wget and curl - it works pretty nicely. Again, all based on ActiveMQ.

       

      I also finished a skeleton agent that also runs as a WildFly extension. It includes the broker extension so we now have an agent that can send/receive messages over the bus (and as mentioned before, this even means something will be able to talk to the agent even with something like curl or wget).

       

      Becaue we do not yet have a real name for the project, this stuff is spread out in different places. You can see the rhq-msg stuff at: https://github.com/rhq-project/rhq-msg and the agent is at: https://github.com/jmazzitelli/rhq-next-agent

       

      If you want a quick test of the agent and the REST API, you can easily build and test via mvn and curl to send a test message. First, build the BOM (which is in yet another repo - rhq-project/rhq-next-bom · GitHub ), then build rhq-msg, then build rhq-next-agent, run the rhq-next-agent distribution, and test with curl and see the agent receive it. Here's how:

       

      1. git clone git@github.com:rhq-project/rhq-next-bom.git

      2. (cd rhq-next-bom; mvn clean install)

      3. git clone git@github.com:rhq-project/rhq-msg.git

      4. (cd rhq-msg; mvn clean install)

      5. git clone git@github.com:jmazzitelli/rhq-next-agent.git

      6. (cd rhq-next-agent; mvn -Pdev clean install)

      7. ./rhq-next-agent/rhq-next-agent-distro/target/wildfly-8.2.0.Final/bin/standalone.sh

      8. curl -d "body={message: helloworld}" http://localhost:8080/rest/message/ping?type=queue

       

      At this point, in your console where you started the agent, you'll see the agent log a message saying it received your helloworld message:

       

      13:25:03,476 INFO  [org.rhq.next.agent.extension.AgentService] (ActiveMQ Session Task-2) mazztower --> helloworld

       

      This just shows that you were able to send a message from your command line (curl) over the bus via REST to the agent. The "mazztower -->" is the agent name (which is nothing more than the node name of your Wildfly host container).

       

      In the future, the idea is that we'll have plugins or "feeds" that can send and receive data to/from the agent where those plugins or feeds can be running either in the agent VM (perhaps as wildfly extensions) or outside the agent but talking to the agent over the bus (via either this REST API, the Java API, or other ApacheMQ client API, of which I know there is C and others).

       

      Anyway, just wanted to post this to let people know what's going on in the spirit of full disclosure

        • 1. Re: agent and messaging
          mazz

          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.

          • 2. Re: agent and messaging
            mazz

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

            Agent Design Ideas.png

            • 3. Re: agent and messaging
              mazz

              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.

              • 4. Re: agent and messaging
                heiko.braun

                Is there any particular reason to leverage activeMQ, opposed to the default wildfly message broker (hornetq)?

                • 5. Re: agent and messaging
                  mazz

                  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.