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

Yes, as sort of what today are called (asynchronous) Micro-Services. Yes exactly. This is what I tried to picture in https://developer.jboss.org/en/rhq/blog/2014/08/14/thoughts-on-rhqnext-se... 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. 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.