Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0

>> >> Lastly and most importantly, if you want push for an alternative >> communication mechanism between components in H-Metrics and H-Alerts, then >> you push for the same across all of Hawkular because it does not make to >> have to support two different mechanisms. > > I do not understand this contention point. The alternatives on the table > are JMS and REST over HTTP. Both of these are in Hawkular today. All what > the document proposes up to this point is to take one of those > alternatives and deliver more functional on top of that foundation (I > outlined in my previous email the differences between alternatives). > > I also mentioned in my previous email the hybrid approach: collocated > services, keep JMS for metric insertion events, keep all the other > inter-component communication over local REST calls (it's a mix between 1 > and 2 above). That is exactly Hawkular with an extension to add needed > pieces, such as event filtering and implementing the features purposed in > the document. Do you see even this proposal a departure from the current > Hawkular architecture? Yes, I do see the proposals as a departure from the current Hawkuar architecture which I think is the most important aspect of the whole discussion. Let’s review the current state of Hawkular with respect to the discussion. The public APIs in Hawkular are the REST APIs. The REST APIs are the only “supported” public APIs. Components and services in Hawkular communicate with each other via the bus, i.e., JMS. To the best of my knowledge,the APIs we implement over JMS are for internal communication between components running in the Hawkular server (regardless of whether those components are co-located in or separate processes). I am not aware of any other plans, discussions, etc., to have the all of the REST API also expose via JMS. Based on these things, it does seem like your proposals are a departure from the current architecture.