[Hawkular-dev] Event Store

[Lucas Ponce]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>