1:18 p.m.
Hi,
Hi Lucas
----- Original Message -----
> > Although it could be provided as a separate component, I am not sure we
> > have
> > any use cases where it would be used independent of the bus, so think it
> > is
> > probably best to include it as additional functionality within the Bus
> > component.
> >
> > Agree/disagree?
> >
>
> In terms of archicture I would suggest to follow a similar architecture
> discussed for metrics/alerts/inventory.
>
> A main component with this persistence/Java API dependencies and then to a
> Listener/CDI/TBD (glue) project that integrate the component with the Bus,
> so then if needed, component could work without Bus dependencies.
> Perhaps we don't have an isolated use case without kettle/bus but I think
> that in that way we can unify the picture.
>
That sounds reasonable - although it is slightly different to how the
events/alerts discussion went (I believe) where I think the suggestion was
that events were persisted off the bus, including Alerts being published and
stored, rather than locally storing - possibly my misunderstanding.
However on reflection that would make the components more dependent upon the
bus, so probably better to have a shared 'persistence' component, as you
suggest, which could be used by all of the other components to persist
information directly, and then use the bus to publish the data for further
processing.
In terms of Elasticsearch - this 'persistence' component could initially
simply wrap Cassandra and then as we understand the query requirements, add
(possibly optional) support for Elasticsearch to do the advanced queries.
Only component I am not sure about how it may use this shared 'persistence'
component is Inventory, as it uses Cassandra via Titan?
my points are two discuss perhaps in two layers:
- the business aspect, to map better what an Event needs to be (what not) to identify the
business implications in terms of lifecycle, where/when is generated, how interacts with
alerts/metrics/possible inventory as well. It was an interesting meeting, as I think that
the Event can be also mapped with log entries/audit/other messages, etc. But on this layer
I would like to get the busines concept.
- In the architecture aspect, I guess you are right, perhaps I didn't detail better my
previous email, for example, in alerts, the architecture is to have a main engine that
have a dependency with the cassandra cluster that can be shared (or not, this could be a
future discussion) with metrics or other components, but the engine itself it has not a
direct dependency with the bus, we add the bus dependency in an additional project, so we
can have both alternatives: a use case where we can use the component in a standalone way
or with the bus scenario, so it's a configuration/packaging option. My suggestion is
that would be also interesting for EventsStore. Also, perhaps the ElasticSearch service
can be shared as well for other components in the future.
Regards,
Lucas
Regards
Gary
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev