I was looking at the proposal my alter ego send to this list a couple of weeks ago:
http://www.rhq-project.org/display/RHQ/AS7+console
What I don't understand is, why should there be an interim layer between the AS7
management API's
(configuration, deployment, etc) and the web-UI?
As described, management of the domain model would be another plugin to the RHQ
container,
equivalent to any other plugin, like the JMX and HornetQ plugins.
I was expecting that any subsystem (i.e. hornetq) would be directly interfacing the AS7
management API's (domain model, deployment, etc). What's the purpose of having
another intermediary layer like the plugin container?
I am trying get a better understanding how all the pieces fit together, especially bearing
in mind that we have an
"embedded console" legacy and that AS7 products will be managed by JON,
somewhere upstream in the product chain.
On a first glance I did assume that any subsystem directly interfaces the new API's
that are currently fleshed out. Instead of retrofit existing plugins on the new API. But
maybe that's because I don't see the big picture, especially how this integrates
with JON later on. But is this an actual requirement? I guess it all boils down to the
question what API customers should get to see, when they want to extend the management
capabilities or integrate with it? Will it it be the RHQ plugin API or the new AS7
management API?
Why RHQ in the first place? How does it relate to JON?
An alternative would be: AS7 Management API <-> REST interface <-> Web-UI.
What are the benefits, drawbacks of each approach?
Ike
(formerly know as Heiko Braun, in order to avoid confusion)