4:07 a.m.
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.