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

[Lukas Krejci]

IMHO, the communication should be built into the components precisely because 
they are meant to be components - parts of a bigger picture.

In that scenario, you will rarely encounter usecases where no communication 
between the components is needed. Fabric1 have zookeeper for similar purpose, 
kubernetes have etcd similarly, too.

I am a little bit nervous about using a bespoke solution for that though - but 
as long as it is made such that clients NOT using our bus implementation can 
still communicate with "us" over the actual channel, I'm ok with that (which 
from the little I have read seems to be the case).

Granted, we could abstract the communication out into the glue code as you 
suggest and it would work but I think the potential problems with that 
approach outweigh the requirement for the components to publish events onto 
the bus. Any change in the component API (or behavior!) would have to be 
reflected in the glue, too. The glue would become the bottleneck or would be 
massively harder to deploy in a distributed manner.

>From the POV of purity of the API and functionality, you are absolutely right 
that we should strive for separation of concerns as much as possible. But 
given the fact that our components are meant to work together, I think that 
communication over bus is one of the core requirements for each of them. Maybe 
there should be a config flag to switch such communication off for the times 
where the components will be used outside of hawkular. But I don't think it is 
worth the effort to suppose that the components will primarily be used and 
deployed on their own - I think the opposite is true.

On Tuesday, January 20, 2015 10:28:30 Thomas Heute wrote:
> When we started the hawkular efforts, I had in mind that the components
> would do minimum tasks as a library with REST/Java APIs and do them well.
> 
> Inventory would manage resources (user defined (an "application", a
> cluster) or architecture defined (an EAP server, a VM, a Kube pod...)),
> assign ids...
> Metrics would store/aggregate/compact metrics (like it is today)
> Alerts would define some alert definition "model" and run an engine to
> define when to trigger an alert.
> ...
> 
> Hawkular project would then be a firm/comprehensive solution that are
> using all those components, would proxy the APIs, add security there
> (instead of in each component),...
> 
> But now I start to see that client aspect of the communication bus is
> part of those components I think I understand the motivation for that
> but not sure that this is what we really need. Am I the only one
> thinking that the communication aspect should be left out of the
> components ?
> 
> For instance in http://docs.hawkularinventory.apiary.io/ for the
> DumbFeed, I don't think it's the role of the Metrics to send
> notification to the bus, if we need more than collecting metrics then it
> is a job for Hawkular IMO (who may proxy the metrics request and send
> notification to the bus).
> 

Note that in the DumbFeed example, things would work even without the 
notification. Things would just not be that friendly - basically stuff would 
not automagically appear in the "discovery queue". The user would still be 
able to set up the resource with the metric. They would just have to "remember 
to do so" and use manual look-up to stitch things together.

> Thomas
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev