I think there is info that will be shared between components, so it's needed to define a shared/common model between components. For example, alerts component should "listen" from some point data/events to evaluate when to trigger an alert. In the first prototypes we are supposing that it will be a "MetricsTopic" in the bus where alerts component can subscribe for this data. This is a minimalist scenario. But, also, yesterday we were discussing with Jay that we can have more complex scenarios, where an alert definition can compare two periods of time (for example, if this week was better than before), in this last scenario we can have requeriments to ask for aggregate data, and transform it in some model that alerts can use to evaluate alerts conditions. In this last scenario, it seems that an alert definition could ask for data to metrics subsystem. So, it would be nice if we can progress in the shared data between components to define what it could be best design to implement these scenarios. I would start with common data (for example, queues/topic identified, data format shared, etc).

FWIW: we could base these on the JSON-encoded BasicMessage [1] - Jay has already prototyped his stuff using this, where a "metric" is JSON-encoded (and thus can be handled across any client in any language) but yet is a strongly-typed Java object that can be used. [1] https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-common/...

IMO, the preferred method is to use JSON as a general payload to open up the ability for clients to be non-Java based. Java clients/servers can use these Java objects as a "convenience" but as Jay and I have shown in our demos, utilizing JSON as the payload opens things up to being able to send and receive information via simple "curl" clients or other non-Java clients.

On 01/20/2015 11:14 AM, Lukas Krejci wrote: I am not saying that they would not need to communicate, they don't necessarily have to communicate directly together How ? Component API should not change, that's the contract. And this is what needs to be properly tested and hammered. Behavior would unlikely need to change as well if the scope is well defined (HWK Metrics store metrics, there is not a lot of behavior to change, behavior would likely change at the glue level). Why ? It doesn't necessarily have to change how it works but more how it is decomposed. Also what are the plans to apply security uniformly across components ? We need to make sure that we don't duplicate efforts (and increase security issues), today there is keycloak integration in RHQ Metrics, I hope we can extract this into the "glue" and share with others. Thomas

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.

Can you elaborate more? What would be the benefit of implementing them as a separate java process as opposed to e.g. a message driven bean listening on the bus? How would standalone processes be used in a scenario where all of Hawkular is deployed on one hardware and inside e.g. one WildFly server?