As 0.4 is nearing completion, I've been thinking about how the management console might evolve for 0.5. I think there are a few general areas that could be improved in the next release:
- Views taylored for specific component types (e.g. SOAP, Camel, etc.)
- Separation of components and component services (currently treated as 1:1, so components without services are not displayed)
- Ability to modify configuration settings
- Improve runtime metrics and message tracing
The first item would simply display configuration in a view appropriate for the specific component being used. This would provide the user with a better experience than simply seeing an xml fragment from the switchyard.xml file.
The second item would allow components not implementing a service to be displayed in the console. Currently, the admin API (and console) assumes every component implements one and only one service. (It would also be good to know if a component may ever implement more than one service.)
The third item moves the console from being a read-only view into SwitchYard to a true management console. In order to enable something like this, the admin and deployment services in the runtime would need to be modified to support reading, storing and merging configuration fragments from the server configuration. This may be too big a task for 0.5, but perhaps we could experiment with component runtime settings (e.g. default SOAP port).
The fourth item requires a bit of design on the backend before any changes are made in the console. I think the current functionality in the console is a great and would like to expand the capabilities. (I'm still trying to work out what this might look like on the backend.)
I think we should have JIRAs for all four of these for sure. My comments:
1) Interesting as an eventually item, but my guess this one could take some time and there's likely higher priority stuff for 0.5.
2) Not sure what the ripple effects would be, but this sounds good for 0.5 if it's not particularly expensive.
3) Definitely want this, but before we even go down this path we will need to get the runtime support down. There are two JIRAs in 0.5 around this already, so maybe we let the design/implementation of those surface before we decide whether console support is possible in 0.5?
4) Operation-level metrics, ability to sort all services based on performance (i.e. hotspot identification), and the ability to show metrics for a given context (message trace, business context key, etc.) would all be great.
3) agree. Depending on when the runtime details (i.e. management interface) is worked out, we should be able hack something together for 0.5.
4) agree. Same as 3, if there's enough time left in the 0.5, this should be doable. I'll start researching what, if any support might be available for displaying heat maps.