9:55 a.m.
On 1/11/11 4:00 AM, Heiko Braun wrote:
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
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).
That's correct. The only way to have consistency between configuration
and management is if subsystems are part of AS and thus interface
directly with the AS7 APIs. So all of our subsystems need to be
implemented this way.
What's the purpose of having another intermediary layer like the
plugin container?
It would certainly be redundant. The only advantage I can think of to
doing this is that it allows you to manage things that are outside of AS
(like say a database). However, this would be completely disconnected
from the domain topology views, and not have the same shared
configuration persistence. For this reason an ISV wanting to extend AS
would probably favor a domain extension vs a RHQ plugin.
Lastly, even if RHQ is needed to support external component management
(which isn't a requirement right now), it will likely save time to just
use the AS APIs for talking to AS, and RHQ for talking to whatever is
managed by it.
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.
Retrofitting existing plugins for AS functionality is a non-option. They
have to be integration with the domain APIs, else we just can't do
unified configuration.
But is this an actual requirement?
I have not seen any requirements on reusing existing RHQ plugins. I am
not sure what the JON schedule is, but at some point it will be updated
to use the AS7 domain APIs, and I assume that the JON team will likely
use an RHQ plugin to do that, since that is their architecture.
However, IMO, in the interest of time (and where we are in our schedule)
we should worry about one UI at a time, and focus on what is best for
the embedded console.
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?
See above.
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?
Yet another alternative, which IMO is probably the best contender is
using the small detyped Java API. That essentially has all of the
benefits of an HTTP interface, but without the need to marshal to and
from plain text JSON/XML (less serialization overhead).
--
Jason T. Greene
JBoss, a division of Red Hat