OK, here's what RHQ is (a previous post described it well). The RHQ Server is a custom JBossAS application - it has a webapp inside of it that you use as the "core UI" - it provides core management functionality for ALL managed products (a JBoss/Remoting instance would be just one, you could manage that along with JBossAS servers, operating systems, Tomcat servers, Apache Web Servers, Hibernate services, blah blah blah). So you log into the core UI that RHQ provides and it gives you out of box features like operational control over your managed products, view/edit configuration of those products, monitoring, fine grain user control and auditing, alerting, etc. etc. This is out of box - you don't have to write any of it. The RHQ Server has a web service front end with an API that you can use to write your own apps (Swing app if you want, or other web apps - we have prototyped a Turbo Gears web app written in Python that talks to our RHQ Server via the web services). That's the server side and you typically need to do nothing on that side but run it. No development necessary under 99% of the use-cases. Then you have the agents. The RHQ Agent talks to an RHQ Server - the agent ships up to the server things like: monitoring data, results of an operation execution, auto-discover results (i.e. what was found running on the box, et. al.). This agent-to-server comm is JBoss/Remoting 2 with an additional command/command response framework built on top of it that gave us things like client-side spooling/guaranteed delivery, asynchronous calls, remote POJO RPC features, etc. - but this is all not interesting as you as the RHQ user won't even see or use it directly, so ignore what I just said :-)). The RHQ Agent runs on each machine that is running managed products. Its the typical hub-n-spoke model. So, if you have a box running Apache Web Server, Tomcat, JBossAS server, some hibernate services running in these things, some JBoss Remoting services running in these things, etc, you'd run one RHQ Agent on that box to manage it all. The RHQ Agent has inside of it a plugin container that hosts "plugins" - each plugin manages one or more managed products. For example, the JBossAS plugin manages the JBossAS server itself, the JMS queues and topics, the data sources, etc. The Hibernate plugin manages the Hibernate services (deployed entities, entity cache, etc.). In the Jboss Remoting case, you would write a "remoting plugin" that simply hooks in using our plugin API. Its very very easy to write a plugin. It snaps into the RHQ framework and you immediate get all the functionality that the core UI provides for all the other products. You only implement the things in your plugin that you want to support. If you just want monitoring, just implement the monitoring API facet and don't implement the others, as an example. See: http://support.rhq-project.org/display/RHQ/Writing+Custom+Plugins http://support.rhq-project.org/display/RHQ/Design-Introduction The wiki home is here, poke around for more design doc info, user guide type info, etc.: http://support.rhq-project.org/display/RHQ/Home View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130745#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...