1 2 3 4 5 Previous Next 61 Replies Latest reply on Feb 21, 2008 8:42 AM by Andy Taylor Go to original post
      • 15. Re: JBM 2 Management Interfaces
        Tim Fox Master


        "apwalker" wrote:
        I like the idea of sending management messages. Such as a message to create a new destination, locking and unlocking the server, shutdown the server, etc

        Yes we should certainly allow some of this to be exposed via the transport itself.

        Actually we already have createQueue/deleteQueue but should expand this...

        • 16. Re: JBM 2 Management Interfaces
          Tim Fox Master


          "mazz@jboss.com" wrote:
          (side note: the comm layer between RHQ's server and agent has JBoss/Remoting 2 under the covers):

          I would be interested in knowing what runtime dependencies this has.

          One of our deployment configurations is JBoss messaging "standalone", which is basically just the Microcontainer running the JBM POJOs. We would like a management capability in there too, but would want to keep the run time dependencies and footprint to a minumu - otherwise we just end becoming JBoss AS.

          You mention remoting - this implies to me that you're not a web UI.

          Also I'm guessing a web server, and seam - anything else.

          Or maybe I am confusing the whole issue and confusing two different management solutions...

          • 17. Re: JBM 2 Management Interfaces
            Aaron Walker Newbie

            correct me if I'm wrong

            rhq consists of a server and agent component. To integrate you would write an agent plugin which could interact with the JBM Management API directly. This could be a totally separate project and wouldn't directly add any dependencies to JBM. Since it's added to the rhq agent which runs in a separate JVM.

            The rhq agent communicates with the server via JBoss Remoting but has a web-app to interact with it. You would probably need to customize the web-app to add support for JBM management functions. This is the part I'm unfamiliar with.

            • 18. Re: JBM 2 Management Interfaces
              Tim Fox Master

              Ok, so I am hopelessly confused.

              The thing I saw demoed was a web interface that uses Seam and interfaced directly with the MC profile service.

              I've no idea what this other thing is, and how the two projects compare or whether there is an overlap. :D

              • 19. Re: JBM 2 Management Interfaces
                Aaron Walker Newbie

                rhq is what JBoss ON is built on top of.

                The MC profile management app your talking about I haven't seen but it does sound like it has some overlap with rhq & JBoss ON.


                • 20. Re: JBM 2 Management Interfaces
                  Scott Stark Master

                  The rhq stuff is the native jon/console api. The profileservice @MangementObject type of annotations are used by the profileservice for the mc/jbossas5 style of management api. The jon open console has a rhq plugin that uses the profileservice api for integration with jbossas5 and/or other mc based configurations using its managed object api.

                  • 21. Re: JBM 2 Management Interfaces
                    Tim Fox Master

                    I won't pretend I have fully got my head around this yet. :)

                    To summarise my understanding so far:

                    JBM 2.0 will have a simple POJO based management API.

                    What we would like to do is:

                    1) Expose that API as a web interface (I'm guessing this is what Charles demo'd at JBW)

                    2) Also expose that API as a non web interface (is this Swing?) which can be controlled from a remote client.

                    The management stuff needs to know what attributes and operations we want to expose - I'm assuming that's the purpose of the plugin.

                    Given a plugin, I'm assuming the management layer is smart enough to be able to provide a web or non web (remote) interface. (This is just a view on the same underlying API).

                    We want to avoid non standard JDK annotations in our POJOs to define management interfaces, since JBM is also designed to be included in Joe Bloggs third party project and we don't want to force them to pull in an unnecessary build time dependency on other (MC) jboss libraries.

                    If all this is to run in the MC, I am also interested in what runtime dependencies are needed for this all to function.

                    So far I have gleaned:

                    1) JBossWeb
                    2) Seam
                    3) Remoting 2
                    4) Profile service (?)
                    Anything else?

                    • 22. Re: JBM 2 Management Interfaces
                      mazz Master

                      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.




                      The wiki home is here, poke around for more design doc info, user guide type info, etc.:


                      • 23. Re: JBM 2 Management Interfaces
                        mazz Master

                        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).

                        • 24. Re: JBM 2 Management Interfaces
                          mazz Master

                          Watch this short, 2 minute demo:


                          All the features you see in this core UI comes out of box from RHQ - you write a plugin that sits in our agent, and you get all of these features without having to write any UI or server-side code. You just write code that talks to the new remoting management interface and RHQ takes care of the rest.

                          So, for example, if you want to support the ability for your customers to remotely view and edit configuration for your remoting services, you have your plugin implement the Configuration facet:


                          Your configuration facet implementation would talk to your remoting services management interface to set configuration properties directly on your remoting objects.

                          If you want to monitor your remoting services, you implement the MeasurementFacet:


                          The measurement facet implementation talks to your remoting services management interface to obtain measurements emitted by them.

                          Take a look at our other facets:


                          to see what management features are supported. You can implement one, some or all of the facets. If you do not implement one, RHQ simply ignores that functionality for your plugin and assumes it is not supported (so if you do not implement the Configuration facet, the core UI will not show you the config screens that would have allowed you to remotely configure your remoting services).

                          • 25. Re: JBM 2 Management Interfaces
                            Andy Taylor Master

                            so basically to expose a set of operations we implement the OperationFacet and it will look something like this:

                            OperationResult invokeOperation(String name, Configuration parameters)
                             String queue = parameters.get("queue").getStringValue();
                             String binding = parameters.get("binding").getStringValue();
                             jmsServerManager.createQueue(queue, binding);
                             return new OperationResult("success");
                             else if(name......)

                            For standalone though, we probably won't be able to use this. There won't be a jboss instance to run it in!

                            • 26. Re: JBM 2 Management Interfaces
                              mazz Master


                              For standalone though, we probably won't be able to use this. There won't be a jboss instance to run it in!

                              Depends on how you are exposing your remote management interface. If its just JMX, you can piggy back on our JMX plugin and have your plugin connect to your remoting services using direct JMX.

                              You can extend existing plugins to reuse existing plugin capabilities. This is how we wrote several of our plugins. For example, the JBossAS4 plugin as well as the Hibernate plugin use the JMX plugin to connect to the JMX MBeanServer hosting the services we want to manage. Under the covers it uses MC4J's EMS library so it supports all different kinds of JMX MBeanServers (standalone JDK5 platform MBS, JBossAS MBeanServer, BEA WebLogic, etc. etc.).



                              In that case, there is no Java code to write. You just write your plugin's XML descriptor and tell it which JMX operations/attributes your services support, and we utilize the JMX plugin to do the dirty work of calling the appropriate JMX APIs. So, for example, write simple JMX MBeans that manage your remoting services and just write the XML descriptor that describe your management MBean interfaces and the JMX plugin takes care of the actual connection to and calling the MBeans.

                              • 27. Re: JBM 2 Management Interfaces
                                Aaron Walker Newbie


                                For standalone though, we probably won't be able to use this. There won't be a jboss instance to run it in!

                                If they want to manage that standalone jbm server then they will run a rhq/jon server somewhere else and run an agent on the server running jbm


                                • 28. Re: JBM 2 Management Interfaces
                                  mazz Master


                                  There won't be a jboss instance to run it in!

                                  I may have misunderstood you here. So, I want to be clear - your plugins run in the RHQ Agent. The RHQ Agent is NOT a JBoss instance, its a standalone, separate J2SE VM.

                                  If your remoting stuff is running in some standalone VM itself, the plugin would just need to remotely connect to your VM (remember, the agent VM is running on the same box as the products its managing (i.e. your remoting VM is on the same box as the agent VM) so it can connect over, in case there are networking issues that you want to avoid). Using the JMX plugin, you can connect to remote JMX MBeanServer's because it uses the EMS library which can connect to any number of remote MBeanServer implementations (the standard JRE5 platform mbeanserver can be remoted, for example, using the "normal remote JMX way" - the EMS library handles this for us.

                                  • 29. Re: JBM 2 Management Interfaces
                                    mazz Master


                                    "apwalker" wrote:

                                    If they want to manage that standalone jbm server then they will run a rhq/jon server somewhere else and run an agent on the server running jbm


                                    The RHQ/JON Server can run anywhere. The RHQ/JON Agent runs on the same box as where your jbm services are running.