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

[Heiko W.Rupp]

On 10 Nov 2015, at 17:25, Stefan Negrea wrote:

> The user-facing feature proposed in the document will require 
> request-reply communication with endpoints in Alerts. Also, there is 
> the part about introducing a filtering mechanism for publishing only 
> metrics of interest to Alerts. This also requires request-reply

So this is where the meat starts - we feel like we may need
this filter. And this is something that is independent on any
communication channel and/or co-location of/between the
two involved entities. having alerts inform metrics of
a potential filter can even be done via REST while at the
same time the data itself flows via messaging (in which case
we need to be careful not to filter out metrics that other
consumers may want).

> So just for Phase 0, we will need a good number (5 or 6) of 
> request-reply operations exposed over the

Can you elaborate about those endpoints?
What are the semantics of each?

> 2) Use JMS as the communication channel and then publish the REST API 
> over JMS. And by "publishing the REST API over JMS", I mean making 
> every single public end-point available over the JMS channel so there 
> is no need in

Why would that be needed? Having data distributed over
messaging does not mean the control needs to be over messaging
too. In fact, messaging is an internal detail, while outside clients
should always talk to our REST endpoints.

> generic solution, we will never have to touch this again

;-)

>
> 1) Addressability -> the current solution does not work in the 
> distributed environment because there is no clear way how to access 
> the public API of the services deployed. Let's say the installation 
> spread across 5 containers. How can I make a public API call from a 
> Metrics instance to an Alerts instance. There is no directory to know 
> where the Alerts or Metrics instances are deployed.

That can be solved by such a directory service and then
HATEOAS


> 2) Load distribution -> there is no clear way on how the load 
> distribution works or who is responsible for it.

And just replacing the internal messaging by rest-calls
between alerts and metrics is solving this how?

> 3) Availability of the existing public API -> There is no reason to 
> implement a new API just for the purposes of communicating between the 
> components. Given that we strive for this micro-service architecture, 
> the one and single public API should be the main method for 
> communicating between components for request-reply. We might need to 
> extend what we have but the public API should be front and centre. So 
> if we use JMS or HTTP (or

http://de.slideshare.net/ewolff/rest-vs-messaging-for-microservices
may be interesting in this context.