[jboss-as7-dev] AS7 console, RHQ

[Jason T. Greene]

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