5 Replies Latest reply on Jul 7, 2011 3:39 PM by rcernich

    SwitchYard Administrative API

    rcernich

      Hey all,

       

      Our work on an administrative console for SwitchYard has highlighted the need for a more complete administrative API for SwitchYard.  The most immediate need is for the ability to query only those deployments which are SwitchYard applications.  Initially, we were using the AS7 DMR facility, which works well for retrieving/setting information contained within the AS7 server configuration file.

       

      Without getting into details regarding the specific architecture or implementation approach that should be applied, I thought I start with a breakdown of the type of functionality which might be required, broken down by component type (as displayed by the console):

       

      Deployment Artifacts

      • The ability to retrieve a list of deployments on a server which are SwitchYard applications.
      • The ability to determine whether or not a SwitchYard deployment is enabled.
      • The ability to retrieve application meta-data (services, transformations, domains, properties) for a deployment.
      • Provide operational details for a deployment:
        • Messages processed.
        • Message throughput.
        • Average message latency (by service?)
        • Tracing information.
        • Review audit logs.
      • Provide operational functions:
        • Manually trigger reprocessing of unhandled messages, which may include message modification (to "fix" a message).
        • "Fix" a broken pipe/endpoint (e.g. redirect to a different physical address, modify credentials, etc.).

       

      SwitchYard Modules/Components

      • The ability to retrieve a list of all installed SwitchYard components ("modules" section of SwitchYard subsystem configuration).
      • The ability to retrieve a list of any configurable properties for a specific module/component (no components currently expose any configurable properties).
      • The ability to install/update a SwitchYard module/component (not sure whether or not this is a feature requirement for SwitchYard).
      • The ability to enable/disable a SwitchYard module/component (not sure whether or not this is a feature requirement for SwitchYard).

       

      SwitchYard Subsystem

      • The ability to retrieve a list of any configurable properties for the SwitchYard subsystem (currently, there is none).

       

      In addition to being able to query information, the interface should allow for

      some settings to be modified (e.g. configuration properties) or reset (e.g.

      message counts).

       

      Architecture

      With some simple functional requirements, we now need to figure out the best approach for meeting them.  Some possible options:

      • Continue using DMR, adding SwitchYard specific operations.
      • Provide support through management beans (would probably serve as the base for any choice).
      • Provide a RESTful API (which may or may not be built atop management beans).
      • Other approaches?

       

      Any and all feedback and suggestions are welcome (good, bad or ugly ;)).

       

      Rob

        • 1. Re: SwitchYard Administrative API
          antollinim

          Hi Rob,

           

          I agree with most of the functions that you are proposing. However, I think that you are putting two different concepts into the same bucket.

           

          Most of the functions you propose belong to an Administration API. However, the sub-bullets you included under the

          "Provide operational details for a deployment" bullet refer essentially to "Monitoring".

           

          I think both concepts will end up being treated in different ways.

           

          Maybe you could start just thinking about the Administration API and let the monitoring part as part of another task.

           

          Just sharing my thoughts.

          • 2. Re: SwitchYard Administrative API
            rcernich

            Hey Mario,

             

            Thanks for the response.

            Most of the functions you propose belong to an Administration API. However, the sub-bullets you included under the

            "Provide operational details for a deployment" bullet refer essentially to "Monitoring".

             

            I agree.  I just wanted to make sure that this type of functionality was considered in the discussion.  Some of monitoring/operational details will depend on application meta-data, and therefore the direction taken for the administrative API could have an effect on the direction taken for a monitoring API.  For example, in order to display latency for a transformation, one needs to know which transformations are defined within the application.

             

            I think both concepts will end up being treated in different ways.

             

            Did you have any opinion on how either should be treated?  I'd definitely like to hear others' opinions.

             

            Maybe you could start just thinking about the Administration API and let the monitoring part as part of another task.

             

            I agree.  I think it would be good to separate monitoring out into a separate task.  (Although, I still think some of the decisions made regarding administration may have an impact on monitoring.)

             

            Thanks again for the feedback.

             

            Rob

            • 3. Re: SwitchYard Administrative API
              antollinim

              Rob,

               

              I do not have much experience about monitoring in Java, so the obvious way for me would be to go with JMX (maybe there is something newer/better that I am not aware of).

               

              Anyways, I think the chosen architecture will impact over the API, instead of being the other way around. For example, the monitoring might end up needing agregations and policies that would impact on the API. .

               

              So I think the process would be to choose the monitoring architecture first and then to come up with the API suiting that architecture (bottom-up instead of top-down)

               

              Makes sense? Any thoughts?

               

              Regards

              Mario

              • 4. Re: SwitchYard Administrative API
                rcernich

                Hey Mario,

                 

                I agree completely.  Currently, I've been looking at using DMR in AS7, partially because this is the API for retrieving information about AS (e.g. deployments) and because that is what is being used by the AS7 console itself.

                 

                I have read that it _should_ be easy to provide a JMX interface on top of DMR (not sure whether this is built in to DMR or not).  That said, I'm still a little fuzzy on security, etc. (w.r.t. DMR).

                 

                Thanks again for the feedback.

                 

                Rob

                • 5. Re: SwitchYard Administrative API
                  rcernich

                  I've posted a question in AS7 development regarding functionality provided by the management API.  Here's the link to the thread:

                  http://community.jboss.org/thread/169111