[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2 Management Interfaces

[mazz@jboss.com]

Oh, forgot to talk about JON and how this all works with the JBoss5 profile service.

First off, JON (JBoss Operations Network 2.0) will have at its core the RHQ stuff.  It will be built with RHQ, but we'll add additional things - like support for content delivery through the JBoss Customer Support Portal (so we can pull down via our customer CSP RSS feeds the JBoss cumulative patches and so we can ship those CPs to agents and have those patches applied - remote patching and upgrading of your deployed JBossAS servers is what we are going to achieve).

Now - the profile service.  The JBoss5 profile service is simply JBoss5's way of providing management services.  This is analogous to, say, Apache and its SNMP module - where Apache provides its management features through an SNMP mod (in fact, this is how RHQ's apache plugin works - it talks to the Apache SNMP mod).  Its analogous to JMX in JBoss4 - this is how the jboss4 plugin works - we talk to the JBossAS server over the JNP port so we can talk JMX to the server and do things like collect monitoring data and control things like the data source MBean and the like.

JBoss5 will be exposing its management features via the Profile Service.  So our jboss-5 plugin will remotely talk to a JBoss5 server via the profile service to do things like configure JBossAS services.  I think the jboss-5 plugin will also talk to the server via direct JMX to get things like monitoring data (I'm not 100% sure on this, but if its not correct, I'm close).  The point here is, a plugin needs to interface with the products its managing using that product's management interface, whatever that interface is.  Apache plugin wants to manage Apache - it does that by talking to Apache's SNMP management interface.  The JBossAS-4 plugin wants to manage JBossAS 4.x - it does that by talking to JBossAS 4's JMX interface.  JBossAS-5 plugin wants to manage JBossAS5 - it does that by talking to it via the Profile Service.  You get the idea.

This is why it is important for products that want to be managed to provide SOME kind of management interface.  If it does, the plugin simply uses the management interface provided by the product to manage it. The RHQ plugin API then puts a common interface around it all so the RHQ Server can generically manage any and all products that have a plugin for it.

Note that the core UI that the RHQ Server provides knows nothing about how to manage a JBossAS5 server - or Apache - or Tomcat - or... It knows nothing about the Profile Service, or SNMP or JMX or any of it.  That's the plugins' job and only the plugins' job.  So, if you write a remoting plugin that talks to your remoting management interface (however you implement it), you will have to do nothing else to get: audited configuration updates, auditing operational control over your remoting servers, monitoring, alerting, etc.  If you do not want to support remote configurability for your remoting services, then don't implement the configuration facet in your plugin and RHQ just ignores it (you won't see the configuration features when looking at your remoting services in the RHQ UI).

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130749#4130749

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130749