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