11:33 a.m.
Hi Lucas
I think we probably need to revisit the use cases for the event store - possibly Thomas
can outline his use case again and we start from there.
Unfortunately I wasn't in the architecture session, as I wanted to hear about the
testing strategy, but sounds like treating each component standalone with the ability to
publish relevant information of interest to other components via the bus (in certain
configurations) is a good way to go.
Regards
Gary
----- Original Message -----
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
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev