[Hawkular-dev] Should the components depend on the bus ?

[Heiko W.Rupp]

> Am 20.01.2015 um 10:28 schrieb Thomas Heute <theute at redhat.com>:
> 
> When we started the hawkular efforts, I had in mind that the components 
> would do minimum tasks as a library with REST/Java APIs and do them well.

Yes, as sort of what today are called (asynchronous) Micro-Services.

> 
> Hawkular project would then be a firm/comprehensive solution that are 
> using all those components, would proxy the APIs, add security there 
> (instead of in each component),...

Yes exactly. This is what I tried to picture in https://developer.jboss.org/en/rhq/blog/2014/08/14/thoughts-on-rhqnext-server-architecture
> 
> But now I start to see that client aspect of the communication bus is 
> part of those components I think I understand the motivation for that 
> but not sure that this is what we really need. Am I the only one 
> thinking that the communication aspect should be left out of the 
> components ?

The question is probably how this central Hawkular thing talks to the individual
components. One approach is certainly to use REST-calls, where some central
registry knows about the endpoints, so that e.g. for alerts to fetch some metric values
from some time ago, it would look up the metrics service endpoint for this and then do
the rest-call. I think this is what Netflix does with good success.

The other option is to use a (message) bus system, where Hawkular and parts
put messages on a bus Queue/Topic and the respective component can subscribe and
receive those messages. For example for incoming metrics, Hawkular would put them
into a topic and metrics and alerts would both subscribe to the topic and get incoming
metric data.
Similar if alerts needs past metrics it would put a message on a Destination where metrics
(and possibly other components) would wait for commands and react on them, putting the
result back on the bus (e.g. in a temporary destination that has been passed when sending
the command). Of course this also requires some wiring 

If I understand you correctly, the question is about the api between bus ("JMS") and the
components that so far have a REST-api and where it lives. 
If we try not to "pollute" the individual sub-projects with integration code, which makes a lot of
sense, we probably need to easily define "bus-listeners" inside the bus module, that read
a configuration (file) and know where to listen for events, how to invoke which rest-call and
how to proceed with responses. 

> 
> For instance in http://docs.hawkularinventory.apiary.io/ for the 
> DumbFeed, I don't think it's the role of the Metrics to send 
> notification to the bus, if we need more than collecting metrics then it 
> is a job for Hawkular IMO (who may proxy the metrics request and send 
> notification to the bus).

I guess that depends on the component. E.g. Metrics (and I am not sure
if I agree with the Dumb feed story ) could be a component that only reacts
to incoming requests, but does not initiate requests on its own.
Alerts on the other hand would also initiate requests, as e.g. the notification
senders would be (micro) services on their own, so if an alert fires the alert
engine would put a message on the bus to an alert notification sender to 
do its work.