2 Replies Latest reply on Nov 12, 2002 7:15 PM by d-ploy

    How to use JMX (design wise)

    tonykl
    tonykl Nov 12, 2002 10:59 AM

      Hi,
      I've recently bought the JMX book and read most of it, however I have a few questions regarding design. Hope this is the right place.
      I originally thought that the advantage of using JMX was that you did not have to alter your existing classes (use Model MBeans) this is a big plus point. However, I am not sure how you set up the registration of your MBeans without having to implement various methods such as preRegister() etc.
      For exmaple, if you take the amazon book scenario, would you register a MBean for each book that amazon sells, this allowing you to manage the book, changing price etc. This seems an aweful lot of MBeans.
      Also, for Model MBeans using the XMBean example using XML to define the metadata, how does this work when your beans you are managing are actually persisted in a DB - for example an EJB ?

      If there are any references to design issues or if I am completely missing the point please say.

      Thanks in advance,

      Tony

      • 3206 Views
      • Tags:
        • 1. Re: How to use JMX (design wise)
          d-ploy
          d-ploy Nov 12, 2002 6:54 PM (in response to tonykl)

          Hi,

          regarding the amazon example:
          You probably wouldn't register an MBean for every book because there are just too many. JMX is not so much about managing data (that's what databases are for), it is about managing applications.

          So a very coarse grained approach would be to have just one MBean for the whole shop. You would probably have start and stop methods to "open" and "close" your shop and you could monitor the well-being of the whole shop.

          Or you could have an MBean for every (software-)component, e.g. one for the database, one for the app-server etc. In this case you could monitor the DB separately from your app-server.

          The most fine-grained approach that I would find reasonable in certain situations, would be to create an MBean for every session/connection of an application. If you have only a few connections which last for a long time you may want to manage things like buffersize or just to shutdown a specific connection. (But I probably would not advise this for the amazon-example).

          Regards,
          d-ploy

            • Actions
          • 2. Re: How to use JMX (design wise)
            d-ploy
            d-ploy Nov 12, 2002 7:15 PM (in response to tonykl)

            Hi,

            regarding the amazon example:
            You probably wouldn't register an MBean for every book because there are just too many. JMX is not so much about managing data (that's what databases are for), it is about managing applications.

            So a very coarse grained approach would be to have just one MBean for the whole shop. You would probably have start and stop methods to "open" and "close" your shop and you could monitor the well-being of the whole shop.

            Or you could have an MBean for every (software-)component, e.g. one for the database, one for the app-server etc. In this case you could monitor the DB separately from your app-server.

            The most fine-grained approach that I would find reasonable in certain situations, would be to create an MBean for every session/connection of an application. If you have only a few connections which last for a long time you may want to manage things like buffersize or just to shutdown a specific connection. (But I probably would not advise this for the amazon-example).

            Regards,
            d-ploy

              • Actions