2 Replies Latest reply on Jul 8, 2011 10:27 AM by rcernich

    Extending the Management Model for a Subsystem

    rcernich

      Hey all,

       

      I'm working on an administrative console for SwitchYard and have a couple of questions regarding the management model.

       

      1.  Will the management API (eventually) support node level ACL?  (I assume so based on http://community.jboss.org/wiki/ManagementAPISecurityAuthorizationResponsibility)

      2.  Is the management API the best architectural choice for exposing operational metrics and operations (e.g. reprocessing messages in a dead-letter queue)?

      3.  Is the management API the best architectural choice for exposing application specific meta-data (e.g. services defined within a SwitchYard application)?  (My concern here relates to transforming SwitchYard application meta-data from its native XML/Java form to a JSON/ModelNode form.)

      4.  I've read somewhere that the management API plays nicely with JMX.  Are there plans to expose the management API through JMX?  If so, will additional work be required of the subsystem developer?

       

      For more specific details regarding basic SwitchYard requirements, please refer to the following thread: http://community.jboss.org/thread/168791

       

      Overall, I've been very happy with the functionality provided by the management API and have found it fairly easy to work with.  I also like the fact that any functionality I add is easily accessible through the CLI (nice for testing).  I just want to make sure I'm heading in the right direction before I get too far along.

       

      Thanks in advance,

      Rob

        • 1. Re: Extending the Management Model for a Subsystem
          emuckenhuber

          Rob Cernich wrote:

           

          1.  Will the management API (eventually) support node level ACL?  (I assume so based on http://community.jboss.org/wiki/ManagementAPISecurityAuthorizationResponsibility)

          Eventually yes, although i'm not sure about the detailed roadmap for this.

           

          Rob Cernich wrote:

           

          2.  Is the management API the best architectural choice for exposing operational metrics and operations (e.g. reprocessing messages in a dead-letter queue)?

          Yes, configuration, metrics and runtime operations should all be exposed through the native management API. This is especially important for the managed domain, in order to be able to execute the same operation for server instances on different hosts.

           

          Rob Cernich wrote:

           

          3.  Is the management API the best architectural choice for exposing application specific meta-data (e.g. services defined within a SwitchYard application)?  (My concern here relates to transforming SwitchYard application meta-data from its native XML/Java form to a JSON/ModelNode form.)

          We provide a more or less read-only view for deployments, where you can register subsystem specific resources and operations - similar the subsystem configuration. Currently we only expose some information about servlets and WS-endpoints. You could look e.g. at the WSExtension. I can also provide more examples if needed.

          Rob Cernich wrote:

           

          4.  I've read somewhere that the management API plays nicely with JMX.  Are there plans to expose the management API through JMX?  If so, will additional work be required of the subsystem developer?

          Yes, we plan to provide a generic JMX mapping layer to the management API, this should not require any additional work from the subsystem developer. However as mentioned before basically everything needs to be registered as part of the AS7 management API, since JMX is not a required subsystem as well the requirement to manage instances in the management domain.

          • 2. Re: Extending the Management Model for a Subsystem
            rcernich

            Hey Emanuel,

             

            Thanks for the response.  It was very helpful in confirming that we're moving in the right direction w.r.t. SwitchYard's management needs.

             

            Thanks again,

            Rob