You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polygene.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2015/07/08 11:57:12 UTC
[Proposal] Drop EventSourcing for 2.1
I have briefly reviewed the eventsourcing codebase, and the immediate
feeling I got was; "This should be with Java 8 Stream API".
So, I think we should simply mothball (drop from settings.gradle) the
eventsourcing libraries and resurrect it somewhere in 3.x when we have Java
8 available.
If anyone is depending on this library (I assume that StreamFlow uses its
own implementation, and still depend on Qi4j 1.4.x), then raise an
objection (together with some docs ;-) )
Cheers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: [Proposal] Drop EventSourcing for 2.1
Posted by Niclas Hedhman <ni...@hedhman.org>.
Perhaps Arvid can provide a bit of high level perspective, since it
originated in StreamFlow.
And Tibor, it isn't super-urgent. I and Paul are whirring around like
tail-roasted squirrels, because there are so many small things that should
be fixed before 2.1 release (which I would like pushed out this month).
// Niclas
On Jul 8, 2015 15:17, "Tibor Mlynarik" <ti...@gmail.com> wrote:
> thanks Jiri, I will ping you.
> cheers,
>
> Tibor
>
> On Jul 8, 2015, at 1:34 PM, Jiri Jetmar <ju...@gmail.com> wrote:
>
> > Hi Tibor,
> >
> > I;m also not an expert of the ES lib, but evtl. I would be able to
> > review/give a feedback
> > an your proposal.
> >
> > Cheers,
> > Jiri
> >
> > 2015-07-08 13:05 GMT+02:00 Tibor Mlynarik <ti...@gmail.com>:
> >
> >> It takes me some time to understand this lib ( as I am not user of it )
> ,
> >> but hopefully I will come with some docs later today.
> >>
> >> cheers,
> >>
> >> Tibor
> >>
> >> On Jul 8, 2015, at 12:57 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> >>
> >>> Ok, I withdraw this suggestion then. Hopes move to Tibor to help with
> >> some
> >>> basic docs. Any other volunteer is appreciated.
> >>>
> >>> On Wed, Jul 8, 2015 at 1:29 PM, Jiri Jetmar <ju...@gmail.com>
> >>> wrote:
> >>>
> >>>> Hi Niclas,
> >>>>
> >>>> we are using it on the DM/Entity level. Any C(R)UD interaction uses
> >> Domain
> >>>> Events. In fact the Entity i.) triggers the Event and consumes it at
> the
> >>>> same time in order to mutate its state.
> >>>>
> >>>> So pls let it in.. :) The Domain Event Library is indeed not perfect,
> >> but
> >>>> at least for us robust enough to be used.
> >>>>
> >>>> Thank you.
> >>>>
> >>>> Cheers,
> >>>> Jiri
> >>>>
> >>>> 2015-07-08 11:57 GMT+02:00 Niclas Hedhman <ni...@hedhman.org>:
> >>>>
> >>>>> I have briefly reviewed the eventsourcing codebase, and the immediate
> >>>>> feeling I got was; "This should be with Java 8 Stream API".
> >>>>>
> >>>>> So, I think we should simply mothball (drop from settings.gradle) the
> >>>>> eventsourcing libraries and resurrect it somewhere in 3.x when we
> have
> >>>> Java
> >>>>> 8 available.
> >>>>>
> >>>>> If anyone is depending on this library (I assume that StreamFlow uses
> >> its
> >>>>> own implementation, and still depend on Qi4j 1.4.x), then raise an
> >>>>> objection (together with some docs ;-) )
> >>>>>
> >>>>>
> >>>>> Cheers
> >>>>> --
> >>>>> Niclas Hedhman, Software Developer
> >>>>> http://zest.apache.org - New Energy for Java
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Niclas Hedhman, Software Developer
> >>> http://zest.apache.org - New Energy for Java
> >>
> >>
>
>
Re: [Proposal] Drop EventSourcing for 2.1
Posted by Tibor Mlynarik <ti...@gmail.com>.
thanks Jiri, I will ping you.
cheers,
Tibor
On Jul 8, 2015, at 1:34 PM, Jiri Jetmar <ju...@gmail.com> wrote:
> Hi Tibor,
>
> I;m also not an expert of the ES lib, but evtl. I would be able to
> review/give a feedback
> an your proposal.
>
> Cheers,
> Jiri
>
> 2015-07-08 13:05 GMT+02:00 Tibor Mlynarik <ti...@gmail.com>:
>
>> It takes me some time to understand this lib ( as I am not user of it ) ,
>> but hopefully I will come with some docs later today.
>>
>> cheers,
>>
>> Tibor
>>
>> On Jul 8, 2015, at 12:57 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
>>
>>> Ok, I withdraw this suggestion then. Hopes move to Tibor to help with
>> some
>>> basic docs. Any other volunteer is appreciated.
>>>
>>> On Wed, Jul 8, 2015 at 1:29 PM, Jiri Jetmar <ju...@gmail.com>
>>> wrote:
>>>
>>>> Hi Niclas,
>>>>
>>>> we are using it on the DM/Entity level. Any C(R)UD interaction uses
>> Domain
>>>> Events. In fact the Entity i.) triggers the Event and consumes it at the
>>>> same time in order to mutate its state.
>>>>
>>>> So pls let it in.. :) The Domain Event Library is indeed not perfect,
>> but
>>>> at least for us robust enough to be used.
>>>>
>>>> Thank you.
>>>>
>>>> Cheers,
>>>> Jiri
>>>>
>>>> 2015-07-08 11:57 GMT+02:00 Niclas Hedhman <ni...@hedhman.org>:
>>>>
>>>>> I have briefly reviewed the eventsourcing codebase, and the immediate
>>>>> feeling I got was; "This should be with Java 8 Stream API".
>>>>>
>>>>> So, I think we should simply mothball (drop from settings.gradle) the
>>>>> eventsourcing libraries and resurrect it somewhere in 3.x when we have
>>>> Java
>>>>> 8 available.
>>>>>
>>>>> If anyone is depending on this library (I assume that StreamFlow uses
>> its
>>>>> own implementation, and still depend on Qi4j 1.4.x), then raise an
>>>>> objection (together with some docs ;-) )
>>>>>
>>>>>
>>>>> Cheers
>>>>> --
>>>>> Niclas Hedhman, Software Developer
>>>>> http://zest.apache.org - New Energy for Java
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Niclas Hedhman, Software Developer
>>> http://zest.apache.org - New Energy for Java
>>
>>
Re: [Proposal] Drop EventSourcing for 2.1
Posted by Tibor Mlynarik <ti...@gmail.com>.
Hi Paul,
I see, backward traverse was broken.
Thanks for fixing. It is much cleaner now.
cheers,
Tibor
On Jul 20, 2015, at 5:36 PM, Paul Merlin <pa...@nosphere.org> wrote:
> Hey Tibor,
>
> Tibor Mlynarik a écrit :
>> Assembler, MemoryApplicationEventStoreService and application events test was added also.
> ApplicationEventTest was failing intermitently.
>
> See
> https://builds.apache.org/view/S-Z/view/Zest/job/Zest%20-%20Check%20develop%20branch%20on%20Java7%20(Oracle%20JDK)/60/testReport/junit/org.qi4j.library.eventsourcing.application/ApplicationEventTest/testApplicationEvent/
>
> I fixed the backward EventSource implementation and stabilized the test,
> see commit 9f02f2c. The test now pass every time. Could you please do a
> quick review of my fixes in case I did something wrong?
>
> Thanks!
>
> /Paul
>
Re: [Proposal] Drop EventSourcing for 2.1
Posted by Paul Merlin <pa...@nosphere.org>.
Hey Tibor,
Tibor Mlynarik a écrit :
> Assembler, MemoryApplicationEventStoreService and application events test was added also.
ApplicationEventTest was failing intermitently.
See
https://builds.apache.org/view/S-Z/view/Zest/job/Zest%20-%20Check%20develop%20branch%20on%20Java7%20(Oracle%20JDK)/60/testReport/junit/org.qi4j.library.eventsourcing.application/ApplicationEventTest/testApplicationEvent/
I fixed the backward EventSource implementation and stabilized the test,
see commit 9f02f2c. The test now pass every time. Could you please do a
quick review of my fixes in case I did something wrong?
Thanks!
/Paul
Re: [Proposal] Drop EventSourcing for 2.1
Posted by Paul Merlin <pa...@nosphere.org>.
Tibor Mlynarik a écrit :
> Hi ,
>
> I have created pull request with basic eventsourcing docs :
> https://github.com/apache/zest-qi4j/pull/1
>
> Assembler, MemoryApplicationEventStoreService and application events test was added also.
Excellent!
@Tibor: don't mind the two comments I just made @github, I'll merge your
changes fixing some typos directly
Thanks a lot!
Re: [Proposal] Drop EventSourcing for 2.1
Posted by Tibor Mlynarik <ti...@gmail.com>.
Hi ,
I have created pull request with basic eventsourcing docs :
https://github.com/apache/zest-qi4j/pull/1
Assembler, MemoryApplicationEventStoreService and application events test was added also.
cheers,
Tibor
On Jul 17, 2015, at 2:21 PM, Paul Merlin <pa...@nosphere.org> wrote:
> Tibor, Jiri,
>
> Thanks for putting effort into this.
>
> A bit more is needed to actually include the documentation in Zest.
> For example, some assembly guidance would be a huge plus.
>
> For now the non-existent documentation is split across:
>
> - libraries/eventsourcing/src/docs/eventsourcing.txt
> - libraries/eventsourcing-jdbm/src/docs/eventsourcing-jdbm.txt
> - libraries/eventsourcing-rest/src/docs/eventsourcing-rest.txt
>
> But, like it's done for SQL libraries (libraries/sql-*), we can put the
> EventSourcing documentation in a single file/page. See
> libraries/sql/src/docs/sql.txt for a sample.
>
> This would mean putting your documentation covering the three
> eventsourcing librairies in
> `libraries/eventsourcing/src/docs/eventsourcing.txt` removing the two
> other files and their inclusion in
> `manual/src/docs/userguide/libraries.txt`.
>
> Or, we can keep the three files/pages, whatever suits your contribution
> mood :)
>
>
> Ping me if you need anything.
>
> Cheers
>
> /Paul
>
>
> Jiri Jetmar a écrit :
>> Hi Tibor,
>>
>> sorry for the late answer, I somehow overlooked your proposal in the flood
>> of other Qi4j notifications.. :-)
>>
>> Pls see my comments below :
>>
>> 2015-07-09 3:12 GMT+02:00 Tibor Mlynarik <ti...@gmail.com>:
>>
>>> Hi Jiri,
>>>
>>> pls review my findings about eventsourcing library.
>>>
>>> I see whole library as nice building blocks from which one can build
>>> solution for decoupling between external systems/subsystems.
>>>
>>
>> As I understood the idea behind event sourcing, the purpose is to
>> trigger/generate an event whenever the state of an application has been
>> mutated.
>>
>> On can generate events on very different levels in the application, but I
>> would see the main benefit somewhere very close
>> to the entities, typicaly directly in the domain model level.
>>
>>
>>> To support reproducible entity store I am not sure.
>>>
>>
>> Yes, the general assumption is when you have something like a event-store
>> and you are going to resend (or replay) all of the
>> previously sent domain events one would be able to reproduce 1:1 the entire
>> domain model state. In the
>> practical implementation one would need a kind of snapshotting mechanism,
>> otherwise you are going to resend always
>> anything from event n(0).
>>
>> We are using for now the event sourcing mechanism mostly for
>> history-keeping purposes. So any mutation
>> of the domain model generates an event that is routed using a messaging
>> infrastructure to a dedicated
>> history-keeping domain model, that uses the same code base (including
>> versioning) as the original model. The nice
>> side-effect is that one can use different storage technology for the online
>> DM and the history-keeping DM.
>>
>> Cheers,
>> Jiri
>>
>>
>>
>>> thanks,
>>>
>>> Tibor
>>>
>>
>> Thank you Tibor, I think your description is fine. We do not need to
>> explain the theory behind ES, but the implementation details of Qi4j, what
>> you did.
>>
>>
>>> * Overview *
>>> Library supports generating, storing and replying two types of events:
>>> application-events and domain-events.
>>>
>>> Application events are bound to usecase and are produced by execution of
>>> specific methods ( ones with ApplicationEvent as their first parameter )
>>> Each application event holds information about usecase, method name and
>>> json serialized values of method parameters.
>>>
>>> Domain events are bound to entity instances and are produced by execution
>>> of annotated ( see @DomainEvent) method that belongs to EntityComposite.
>>> Each domain event ( see DomainEventValue) holds information about entity
>>> type, identity, method name and json serialized values of method parameters.
>>>
>>> Both application and domain events are captured during UnitOfWork lifetime
>>> and are stored in event store after successfully completed UnitOfWork as
>>> collection together. ( see UnitOfWorkDomainEventsValue and
>>> TransactionApplicationEvents).
>>>
>>> There is support for replying events. When events are replied the same
>>> code is executed but no new events are generated.
>>>
>>> Event store supports indexed and streamed access to events feed. There is
>>> in-memory and JDBM backed implementation.
>>> For remote access to feed there is eventsourcing-rest library that exposes
>>> events as Atom feeds.
>>>
>>> There are helper classes that enables a service to easily track event
>>> feed, and
>>> for domain events there is event router that allow specify
>>> specification->receiver routes.
>>>
>>> * Not not so good parts, limitations *
>>>
>>> Application events part seems to be not finished.
>>> ApplicationEventFactoryService has wrong concern associated.
>>> There is only abstract base for event store ( thought should be easy
>>> copied from domain events). And missing tests.
>>>
>>> Parameters serialization and deserialization seems to be not symmetric in
>>> supported types.
>>>
>>> There is support for events reply , but there seems to be those
>>> limitations for domain events:
>>>
>>> - all entity mutations has to go via annotated methods, otherwise one
>>> cannot rebuild entity state fully
>>> - no support for entity removal
>>> - no suport for entity properties constraints ( blank entity instance is
>>> created when it's id is not existing yet)
>>> - limited support for parameter types (?)
>>>
>>> as for application events mapping from usecase name to target instance has
>>> to be managed somehow.
>>>
>>> * Blog post + slides *
>>>
>>> [1]
>>> http://www.jroller.com/rickard/entry/application_event_distribution_through_rest
>>> [2] http://www.slideshare.net/Rickardberg/eventsourcing-applied
>
Re: [Proposal] Drop EventSourcing for 2.1
Posted by Tibor Mlynarik <ti...@gmail.com>.
Jiri thanks for review.
I am going to make docs in proper places.
cheers,
Tibor
On Jul 17, 2015, at 2:21 PM, Paul Merlin <pa...@nosphere.org> wrote:
> Tibor, Jiri,
>
> Thanks for putting effort into this.
>
> A bit more is needed to actually include the documentation in Zest.
> For example, some assembly guidance would be a huge plus.
>
> For now the non-existent documentation is split across:
>
> - libraries/eventsourcing/src/docs/eventsourcing.txt
> - libraries/eventsourcing-jdbm/src/docs/eventsourcing-jdbm.txt
> - libraries/eventsourcing-rest/src/docs/eventsourcing-rest.txt
>
> But, like it's done for SQL libraries (libraries/sql-*), we can put the
> EventSourcing documentation in a single file/page. See
> libraries/sql/src/docs/sql.txt for a sample.
>
> This would mean putting your documentation covering the three
> eventsourcing librairies in
> `libraries/eventsourcing/src/docs/eventsourcing.txt` removing the two
> other files and their inclusion in
> `manual/src/docs/userguide/libraries.txt`.
>
> Or, we can keep the three files/pages, whatever suits your contribution
> mood :)
>
>
> Ping me if you need anything.
>
> Cheers
>
> /Paul
>
>
> Jiri Jetmar a écrit :
>> Hi Tibor,
>>
>> sorry for the late answer, I somehow overlooked your proposal in the flood
>> of other Qi4j notifications.. :-)
>>
>> Pls see my comments below :
>>
>> 2015-07-09 3:12 GMT+02:00 Tibor Mlynarik <ti...@gmail.com>:
>>
>>> Hi Jiri,
>>>
>>> pls review my findings about eventsourcing library.
>>>
>>> I see whole library as nice building blocks from which one can build
>>> solution for decoupling between external systems/subsystems.
>>>
>>
>> As I understood the idea behind event sourcing, the purpose is to
>> trigger/generate an event whenever the state of an application has been
>> mutated.
>>
>> On can generate events on very different levels in the application, but I
>> would see the main benefit somewhere very close
>> to the entities, typicaly directly in the domain model level.
>>
>>
>>> To support reproducible entity store I am not sure.
>>>
>>
>> Yes, the general assumption is when you have something like a event-store
>> and you are going to resend (or replay) all of the
>> previously sent domain events one would be able to reproduce 1:1 the entire
>> domain model state. In the
>> practical implementation one would need a kind of snapshotting mechanism,
>> otherwise you are going to resend always
>> anything from event n(0).
>>
>> We are using for now the event sourcing mechanism mostly for
>> history-keeping purposes. So any mutation
>> of the domain model generates an event that is routed using a messaging
>> infrastructure to a dedicated
>> history-keeping domain model, that uses the same code base (including
>> versioning) as the original model. The nice
>> side-effect is that one can use different storage technology for the online
>> DM and the history-keeping DM.
>>
>> Cheers,
>> Jiri
>>
>>
>>
>>> thanks,
>>>
>>> Tibor
>>>
>>
>> Thank you Tibor, I think your description is fine. We do not need to
>> explain the theory behind ES, but the implementation details of Qi4j, what
>> you did.
>>
>>
>>> * Overview *
>>> Library supports generating, storing and replying two types of events:
>>> application-events and domain-events.
>>>
>>> Application events are bound to usecase and are produced by execution of
>>> specific methods ( ones with ApplicationEvent as their first parameter )
>>> Each application event holds information about usecase, method name and
>>> json serialized values of method parameters.
>>>
>>> Domain events are bound to entity instances and are produced by execution
>>> of annotated ( see @DomainEvent) method that belongs to EntityComposite.
>>> Each domain event ( see DomainEventValue) holds information about entity
>>> type, identity, method name and json serialized values of method parameters.
>>>
>>> Both application and domain events are captured during UnitOfWork lifetime
>>> and are stored in event store after successfully completed UnitOfWork as
>>> collection together. ( see UnitOfWorkDomainEventsValue and
>>> TransactionApplicationEvents).
>>>
>>> There is support for replying events. When events are replied the same
>>> code is executed but no new events are generated.
>>>
>>> Event store supports indexed and streamed access to events feed. There is
>>> in-memory and JDBM backed implementation.
>>> For remote access to feed there is eventsourcing-rest library that exposes
>>> events as Atom feeds.
>>>
>>> There are helper classes that enables a service to easily track event
>>> feed, and
>>> for domain events there is event router that allow specify
>>> specification->receiver routes.
>>>
>>> * Not not so good parts, limitations *
>>>
>>> Application events part seems to be not finished.
>>> ApplicationEventFactoryService has wrong concern associated.
>>> There is only abstract base for event store ( thought should be easy
>>> copied from domain events). And missing tests.
>>>
>>> Parameters serialization and deserialization seems to be not symmetric in
>>> supported types.
>>>
>>> There is support for events reply , but there seems to be those
>>> limitations for domain events:
>>>
>>> - all entity mutations has to go via annotated methods, otherwise one
>>> cannot rebuild entity state fully
>>> - no support for entity removal
>>> - no suport for entity properties constraints ( blank entity instance is
>>> created when it's id is not existing yet)
>>> - limited support for parameter types (?)
>>>
>>> as for application events mapping from usecase name to target instance has
>>> to be managed somehow.
>>>
>>> * Blog post + slides *
>>>
>>> [1]
>>> http://www.jroller.com/rickard/entry/application_event_distribution_through_rest
>>> [2] http://www.slideshare.net/Rickardberg/eventsourcing-applied
>
Re: [Proposal] Drop EventSourcing for 2.1
Posted by Paul Merlin <pa...@nosphere.org>.
Tibor, Jiri,
Thanks for putting effort into this.
A bit more is needed to actually include the documentation in Zest.
For example, some assembly guidance would be a huge plus.
For now the non-existent documentation is split across:
- libraries/eventsourcing/src/docs/eventsourcing.txt
- libraries/eventsourcing-jdbm/src/docs/eventsourcing-jdbm.txt
- libraries/eventsourcing-rest/src/docs/eventsourcing-rest.txt
But, like it's done for SQL libraries (libraries/sql-*), we can put the
EventSourcing documentation in a single file/page. See
libraries/sql/src/docs/sql.txt for a sample.
This would mean putting your documentation covering the three
eventsourcing librairies in
`libraries/eventsourcing/src/docs/eventsourcing.txt` removing the two
other files and their inclusion in
`manual/src/docs/userguide/libraries.txt`.
Or, we can keep the three files/pages, whatever suits your contribution
mood :)
Ping me if you need anything.
Cheers
/Paul
Jiri Jetmar a écrit :
> Hi Tibor,
>
> sorry for the late answer, I somehow overlooked your proposal in the flood
> of other Qi4j notifications.. :-)
>
> Pls see my comments below :
>
> 2015-07-09 3:12 GMT+02:00 Tibor Mlynarik <ti...@gmail.com>:
>
>> Hi Jiri,
>>
>> pls review my findings about eventsourcing library.
>>
>> I see whole library as nice building blocks from which one can build
>> solution for decoupling between external systems/subsystems.
>>
>
> As I understood the idea behind event sourcing, the purpose is to
> trigger/generate an event whenever the state of an application has been
> mutated.
>
> On can generate events on very different levels in the application, but I
> would see the main benefit somewhere very close
> to the entities, typicaly directly in the domain model level.
>
>
>> To support reproducible entity store I am not sure.
>>
>
> Yes, the general assumption is when you have something like a event-store
> and you are going to resend (or replay) all of the
> previously sent domain events one would be able to reproduce 1:1 the entire
> domain model state. In the
> practical implementation one would need a kind of snapshotting mechanism,
> otherwise you are going to resend always
> anything from event n(0).
>
> We are using for now the event sourcing mechanism mostly for
> history-keeping purposes. So any mutation
> of the domain model generates an event that is routed using a messaging
> infrastructure to a dedicated
> history-keeping domain model, that uses the same code base (including
> versioning) as the original model. The nice
> side-effect is that one can use different storage technology for the online
> DM and the history-keeping DM.
>
> Cheers,
> Jiri
>
>
>
>> thanks,
>>
>> Tibor
>>
>
> Thank you Tibor, I think your description is fine. We do not need to
> explain the theory behind ES, but the implementation details of Qi4j, what
> you did.
>
>
>> * Overview *
>> Library supports generating, storing and replying two types of events:
>> application-events and domain-events.
>>
>> Application events are bound to usecase and are produced by execution of
>> specific methods ( ones with ApplicationEvent as their first parameter )
>> Each application event holds information about usecase, method name and
>> json serialized values of method parameters.
>>
>> Domain events are bound to entity instances and are produced by execution
>> of annotated ( see @DomainEvent) method that belongs to EntityComposite.
>> Each domain event ( see DomainEventValue) holds information about entity
>> type, identity, method name and json serialized values of method parameters.
>>
>> Both application and domain events are captured during UnitOfWork lifetime
>> and are stored in event store after successfully completed UnitOfWork as
>> collection together. ( see UnitOfWorkDomainEventsValue and
>> TransactionApplicationEvents).
>>
>> There is support for replying events. When events are replied the same
>> code is executed but no new events are generated.
>>
>> Event store supports indexed and streamed access to events feed. There is
>> in-memory and JDBM backed implementation.
>> For remote access to feed there is eventsourcing-rest library that exposes
>> events as Atom feeds.
>>
>> There are helper classes that enables a service to easily track event
>> feed, and
>> for domain events there is event router that allow specify
>> specification->receiver routes.
>>
>> * Not not so good parts, limitations *
>>
>> Application events part seems to be not finished.
>> ApplicationEventFactoryService has wrong concern associated.
>> There is only abstract base for event store ( thought should be easy
>> copied from domain events). And missing tests.
>>
>> Parameters serialization and deserialization seems to be not symmetric in
>> supported types.
>>
>> There is support for events reply , but there seems to be those
>> limitations for domain events:
>>
>> - all entity mutations has to go via annotated methods, otherwise one
>> cannot rebuild entity state fully
>> - no support for entity removal
>> - no suport for entity properties constraints ( blank entity instance is
>> created when it's id is not existing yet)
>> - limited support for parameter types (?)
>>
>> as for application events mapping from usecase name to target instance has
>> to be managed somehow.
>>
>> * Blog post + slides *
>>
>> [1]
>> http://www.jroller.com/rickard/entry/application_event_distribution_through_rest
>> [2] http://www.slideshare.net/Rickardberg/eventsourcing-applied
Re: [Proposal] Drop EventSourcing for 2.1
Posted by Jiri Jetmar <ju...@gmail.com>.
Hi Tibor,
sorry for the late answer, I somehow overlooked your proposal in the flood
of other Qi4j notifications.. :-)
Pls see my comments below :
2015-07-09 3:12 GMT+02:00 Tibor Mlynarik <ti...@gmail.com>:
> Hi Jiri,
>
> pls review my findings about eventsourcing library.
>
> I see whole library as nice building blocks from which one can build
> solution for decoupling between external systems/subsystems.
>
As I understood the idea behind event sourcing, the purpose is to
trigger/generate an event whenever the state of an application has been
mutated.
On can generate events on very different levels in the application, but I
would see the main benefit somewhere very close
to the entities, typicaly directly in the domain model level.
> To support reproducible entity store I am not sure.
>
Yes, the general assumption is when you have something like a event-store
and you are going to resend (or replay) all of the
previously sent domain events one would be able to reproduce 1:1 the entire
domain model state. In the
practical implementation one would need a kind of snapshotting mechanism,
otherwise you are going to resend always
anything from event n(0).
We are using for now the event sourcing mechanism mostly for
history-keeping purposes. So any mutation
of the domain model generates an event that is routed using a messaging
infrastructure to a dedicated
history-keeping domain model, that uses the same code base (including
versioning) as the original model. The nice
side-effect is that one can use different storage technology for the online
DM and the history-keeping DM.
Cheers,
Jiri
>
> thanks,
>
> Tibor
>
Thank you Tibor, I think your description is fine. We do not need to
explain the theory behind ES, but the implementation details of Qi4j, what
you did.
>
> * Overview *
> Library supports generating, storing and replying two types of events:
> application-events and domain-events.
>
> Application events are bound to usecase and are produced by execution of
> specific methods ( ones with ApplicationEvent as their first parameter )
> Each application event holds information about usecase, method name and
> json serialized values of method parameters.
>
> Domain events are bound to entity instances and are produced by execution
> of annotated ( see @DomainEvent) method that belongs to EntityComposite.
> Each domain event ( see DomainEventValue) holds information about entity
> type, identity, method name and json serialized values of method parameters.
>
> Both application and domain events are captured during UnitOfWork lifetime
> and are stored in event store after successfully completed UnitOfWork as
> collection together. ( see UnitOfWorkDomainEventsValue and
> TransactionApplicationEvents).
>
> There is support for replying events. When events are replied the same
> code is executed but no new events are generated.
>
> Event store supports indexed and streamed access to events feed. There is
> in-memory and JDBM backed implementation.
> For remote access to feed there is eventsourcing-rest library that exposes
> events as Atom feeds.
>
> There are helper classes that enables a service to easily track event
> feed, and
> for domain events there is event router that allow specify
> specification->receiver routes.
>
> * Not not so good parts, limitations *
>
> Application events part seems to be not finished.
> ApplicationEventFactoryService has wrong concern associated.
> There is only abstract base for event store ( thought should be easy
> copied from domain events). And missing tests.
>
> Parameters serialization and deserialization seems to be not symmetric in
> supported types.
>
> There is support for events reply , but there seems to be those
> limitations for domain events:
>
> - all entity mutations has to go via annotated methods, otherwise one
> cannot rebuild entity state fully
> - no support for entity removal
> - no suport for entity properties constraints ( blank entity instance is
> created when it's id is not existing yet)
> - limited support for parameter types (?)
>
> as for application events mapping from usecase name to target instance has
> to be managed somehow.
>
> * Blog post + slides *
>
> [1]
> http://www.jroller.com/rickard/entry/application_event_distribution_through_rest
> [2] http://www.slideshare.net/Rickardberg/eventsourcing-applied
>
>
> On Jul 8, 2015, at 1:34 PM, Jiri Jetmar <ju...@gmail.com> wrote:
>
> > Hi Tibor,
> >
> > I;m also not an expert of the ES lib, but evtl. I would be able to
> > review/give a feedback
> > an your proposal.
> >
> > Cheers,
> > Jiri
> >
> > 2015-07-08 13:05 GMT+02:00 Tibor Mlynarik <ti...@gmail.com>:
> >
> >> It takes me some time to understand this lib ( as I am not user of it )
> ,
> >> but hopefully I will come with some docs later today.
> >>
> >> cheers,
> >>
> >> Tibor
> >>
> >> On Jul 8, 2015, at 12:57 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> >>
> >>> Ok, I withdraw this suggestion then. Hopes move to Tibor to help with
> >> some
> >>> basic docs. Any other volunteer is appreciated.
> >>>
> >>> On Wed, Jul 8, 2015 at 1:29 PM, Jiri Jetmar <ju...@gmail.com>
> >>> wrote:
> >>>
> >>>> Hi Niclas,
> >>>>
> >>>> we are using it on the DM/Entity level. Any C(R)UD interaction uses
> >> Domain
> >>>> Events. In fact the Entity i.) triggers the Event and consumes it at
> the
> >>>> same time in order to mutate its state.
> >>>>
> >>>> So pls let it in.. :) The Domain Event Library is indeed not perfect,
> >> but
> >>>> at least for us robust enough to be used.
> >>>>
> >>>> Thank you.
> >>>>
> >>>> Cheers,
> >>>> Jiri
> >>>>
> >>>> 2015-07-08 11:57 GMT+02:00 Niclas Hedhman <ni...@hedhman.org>:
> >>>>
> >>>>> I have briefly reviewed the eventsourcing codebase, and the immediate
> >>>>> feeling I got was; "This should be with Java 8 Stream API".
> >>>>>
> >>>>> So, I think we should simply mothball (drop from settings.gradle) the
> >>>>> eventsourcing libraries and resurrect it somewhere in 3.x when we
> have
> >>>> Java
> >>>>> 8 available.
> >>>>>
> >>>>> If anyone is depending on this library (I assume that StreamFlow uses
> >> its
> >>>>> own implementation, and still depend on Qi4j 1.4.x), then raise an
> >>>>> objection (together with some docs ;-) )
> >>>>>
> >>>>>
> >>>>> Cheers
> >>>>> --
> >>>>> Niclas Hedhman, Software Developer
> >>>>> http://zest.apache.org - New Energy for Java
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Niclas Hedhman, Software Developer
> >>> http://zest.apache.org - New Energy for Java
> >>
> >>
>
>
Re: [Proposal] Drop EventSourcing for 2.1
Posted by Tibor Mlynarik <ti...@gmail.com>.
Hi Jiri,
pls review my findings about eventsourcing library.
I see whole library as nice building blocks from which one can build solution for decoupling between external systems/subsystems.
To support reproducible entity store I am not sure.
thanks,
Tibor
* Overview *
Library supports generating, storing and replying two types of events: application-events and domain-events.
Application events are bound to usecase and are produced by execution of specific methods ( ones with ApplicationEvent as their first parameter )
Each application event holds information about usecase, method name and json serialized values of method parameters.
Domain events are bound to entity instances and are produced by execution of annotated ( see @DomainEvent) method that belongs to EntityComposite.
Each domain event ( see DomainEventValue) holds information about entity type, identity, method name and json serialized values of method parameters.
Both application and domain events are captured during UnitOfWork lifetime and are stored in event store after successfully completed UnitOfWork as collection together. ( see UnitOfWorkDomainEventsValue and TransactionApplicationEvents).
There is support for replying events. When events are replied the same code is executed but no new events are generated.
Event store supports indexed and streamed access to events feed. There is in-memory and JDBM backed implementation.
For remote access to feed there is eventsourcing-rest library that exposes events as Atom feeds.
There are helper classes that enables a service to easily track event feed, and
for domain events there is event router that allow specify specification->receiver routes.
* Not not so good parts, limitations *
Application events part seems to be not finished. ApplicationEventFactoryService has wrong concern associated.
There is only abstract base for event store ( thought should be easy copied from domain events). And missing tests.
Parameters serialization and deserialization seems to be not symmetric in supported types.
There is support for events reply , but there seems to be those limitations for domain events:
- all entity mutations has to go via annotated methods, otherwise one cannot rebuild entity state fully
- no support for entity removal
- no suport for entity properties constraints ( blank entity instance is created when it's id is not existing yet)
- limited support for parameter types (?)
as for application events mapping from usecase name to target instance has to be managed somehow.
* Blog post + slides *
[1] http://www.jroller.com/rickard/entry/application_event_distribution_through_rest
[2] http://www.slideshare.net/Rickardberg/eventsourcing-applied
On Jul 8, 2015, at 1:34 PM, Jiri Jetmar <ju...@gmail.com> wrote:
> Hi Tibor,
>
> I;m also not an expert of the ES lib, but evtl. I would be able to
> review/give a feedback
> an your proposal.
>
> Cheers,
> Jiri
>
> 2015-07-08 13:05 GMT+02:00 Tibor Mlynarik <ti...@gmail.com>:
>
>> It takes me some time to understand this lib ( as I am not user of it ) ,
>> but hopefully I will come with some docs later today.
>>
>> cheers,
>>
>> Tibor
>>
>> On Jul 8, 2015, at 12:57 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
>>
>>> Ok, I withdraw this suggestion then. Hopes move to Tibor to help with
>> some
>>> basic docs. Any other volunteer is appreciated.
>>>
>>> On Wed, Jul 8, 2015 at 1:29 PM, Jiri Jetmar <ju...@gmail.com>
>>> wrote:
>>>
>>>> Hi Niclas,
>>>>
>>>> we are using it on the DM/Entity level. Any C(R)UD interaction uses
>> Domain
>>>> Events. In fact the Entity i.) triggers the Event and consumes it at the
>>>> same time in order to mutate its state.
>>>>
>>>> So pls let it in.. :) The Domain Event Library is indeed not perfect,
>> but
>>>> at least for us robust enough to be used.
>>>>
>>>> Thank you.
>>>>
>>>> Cheers,
>>>> Jiri
>>>>
>>>> 2015-07-08 11:57 GMT+02:00 Niclas Hedhman <ni...@hedhman.org>:
>>>>
>>>>> I have briefly reviewed the eventsourcing codebase, and the immediate
>>>>> feeling I got was; "This should be with Java 8 Stream API".
>>>>>
>>>>> So, I think we should simply mothball (drop from settings.gradle) the
>>>>> eventsourcing libraries and resurrect it somewhere in 3.x when we have
>>>> Java
>>>>> 8 available.
>>>>>
>>>>> If anyone is depending on this library (I assume that StreamFlow uses
>> its
>>>>> own implementation, and still depend on Qi4j 1.4.x), then raise an
>>>>> objection (together with some docs ;-) )
>>>>>
>>>>>
>>>>> Cheers
>>>>> --
>>>>> Niclas Hedhman, Software Developer
>>>>> http://zest.apache.org - New Energy for Java
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Niclas Hedhman, Software Developer
>>> http://zest.apache.org - New Energy for Java
>>
>>
Re: [Proposal] Drop EventSourcing for 2.1
Posted by Jiri Jetmar <ju...@gmail.com>.
Hi Tibor,
I;m also not an expert of the ES lib, but evtl. I would be able to
review/give a feedback
an your proposal.
Cheers,
Jiri
2015-07-08 13:05 GMT+02:00 Tibor Mlynarik <ti...@gmail.com>:
> It takes me some time to understand this lib ( as I am not user of it ) ,
> but hopefully I will come with some docs later today.
>
> cheers,
>
> Tibor
>
> On Jul 8, 2015, at 12:57 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
>
> > Ok, I withdraw this suggestion then. Hopes move to Tibor to help with
> some
> > basic docs. Any other volunteer is appreciated.
> >
> > On Wed, Jul 8, 2015 at 1:29 PM, Jiri Jetmar <ju...@gmail.com>
> > wrote:
> >
> >> Hi Niclas,
> >>
> >> we are using it on the DM/Entity level. Any C(R)UD interaction uses
> Domain
> >> Events. In fact the Entity i.) triggers the Event and consumes it at the
> >> same time in order to mutate its state.
> >>
> >> So pls let it in.. :) The Domain Event Library is indeed not perfect,
> but
> >> at least for us robust enough to be used.
> >>
> >> Thank you.
> >>
> >> Cheers,
> >> Jiri
> >>
> >> 2015-07-08 11:57 GMT+02:00 Niclas Hedhman <ni...@hedhman.org>:
> >>
> >>> I have briefly reviewed the eventsourcing codebase, and the immediate
> >>> feeling I got was; "This should be with Java 8 Stream API".
> >>>
> >>> So, I think we should simply mothball (drop from settings.gradle) the
> >>> eventsourcing libraries and resurrect it somewhere in 3.x when we have
> >> Java
> >>> 8 available.
> >>>
> >>> If anyone is depending on this library (I assume that StreamFlow uses
> its
> >>> own implementation, and still depend on Qi4j 1.4.x), then raise an
> >>> objection (together with some docs ;-) )
> >>>
> >>>
> >>> Cheers
> >>> --
> >>> Niclas Hedhman, Software Developer
> >>> http://zest.apache.org - New Energy for Java
> >>>
> >>
> >
> >
> >
> > --
> > Niclas Hedhman, Software Developer
> > http://zest.apache.org - New Energy for Java
>
>
Re: [Proposal] Drop EventSourcing for 2.1
Posted by Tibor Mlynarik <ti...@gmail.com>.
It takes me some time to understand this lib ( as I am not user of it ) ,
but hopefully I will come with some docs later today.
cheers,
Tibor
On Jul 8, 2015, at 12:57 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> Ok, I withdraw this suggestion then. Hopes move to Tibor to help with some
> basic docs. Any other volunteer is appreciated.
>
> On Wed, Jul 8, 2015 at 1:29 PM, Jiri Jetmar <ju...@gmail.com>
> wrote:
>
>> Hi Niclas,
>>
>> we are using it on the DM/Entity level. Any C(R)UD interaction uses Domain
>> Events. In fact the Entity i.) triggers the Event and consumes it at the
>> same time in order to mutate its state.
>>
>> So pls let it in.. :) The Domain Event Library is indeed not perfect, but
>> at least for us robust enough to be used.
>>
>> Thank you.
>>
>> Cheers,
>> Jiri
>>
>> 2015-07-08 11:57 GMT+02:00 Niclas Hedhman <ni...@hedhman.org>:
>>
>>> I have briefly reviewed the eventsourcing codebase, and the immediate
>>> feeling I got was; "This should be with Java 8 Stream API".
>>>
>>> So, I think we should simply mothball (drop from settings.gradle) the
>>> eventsourcing libraries and resurrect it somewhere in 3.x when we have
>> Java
>>> 8 available.
>>>
>>> If anyone is depending on this library (I assume that StreamFlow uses its
>>> own implementation, and still depend on Qi4j 1.4.x), then raise an
>>> objection (together with some docs ;-) )
>>>
>>>
>>> Cheers
>>> --
>>> Niclas Hedhman, Software Developer
>>> http://zest.apache.org - New Energy for Java
>>>
>>
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
Re: [Proposal] Drop EventSourcing for 2.1
Posted by Niclas Hedhman <ni...@hedhman.org>.
Ok, I withdraw this suggestion then. Hopes move to Tibor to help with some
basic docs. Any other volunteer is appreciated.
On Wed, Jul 8, 2015 at 1:29 PM, Jiri Jetmar <ju...@gmail.com>
wrote:
> Hi Niclas,
>
> we are using it on the DM/Entity level. Any C(R)UD interaction uses Domain
> Events. In fact the Entity i.) triggers the Event and consumes it at the
> same time in order to mutate its state.
>
> So pls let it in.. :) The Domain Event Library is indeed not perfect, but
> at least for us robust enough to be used.
>
> Thank you.
>
> Cheers,
> Jiri
>
> 2015-07-08 11:57 GMT+02:00 Niclas Hedhman <ni...@hedhman.org>:
>
> > I have briefly reviewed the eventsourcing codebase, and the immediate
> > feeling I got was; "This should be with Java 8 Stream API".
> >
> > So, I think we should simply mothball (drop from settings.gradle) the
> > eventsourcing libraries and resurrect it somewhere in 3.x when we have
> Java
> > 8 available.
> >
> > If anyone is depending on this library (I assume that StreamFlow uses its
> > own implementation, and still depend on Qi4j 1.4.x), then raise an
> > objection (together with some docs ;-) )
> >
> >
> > Cheers
> > --
> > Niclas Hedhman, Software Developer
> > http://zest.apache.org - New Energy for Java
> >
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: [Proposal] Drop EventSourcing for 2.1
Posted by Jiri Jetmar <ju...@gmail.com>.
Hi Niclas,
we are using it on the DM/Entity level. Any C(R)UD interaction uses Domain
Events. In fact the Entity i.) triggers the Event and consumes it at the
same time in order to mutate its state.
So pls let it in.. :) The Domain Event Library is indeed not perfect, but
at least for us robust enough to be used.
Thank you.
Cheers,
Jiri
2015-07-08 11:57 GMT+02:00 Niclas Hedhman <ni...@hedhman.org>:
> I have briefly reviewed the eventsourcing codebase, and the immediate
> feeling I got was; "This should be with Java 8 Stream API".
>
> So, I think we should simply mothball (drop from settings.gradle) the
> eventsourcing libraries and resurrect it somewhere in 3.x when we have Java
> 8 available.
>
> If anyone is depending on this library (I assume that StreamFlow uses its
> own implementation, and still depend on Qi4j 1.4.x), then raise an
> objection (together with some docs ;-) )
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>
Re: [Proposal] Drop EventSourcing for 2.1
Posted by Arvid Huss <ar...@jayway.com>.
Hi,
Yes - your assumption is right. SF is using its own implementation and
depends still on 1.3.x Qi4j
/arvid
2015-07-08 11:57 GMT+02:00 Niclas Hedhman <ni...@hedhman.org>:
> I have briefly reviewed the eventsourcing codebase, and the immediate
> feeling I got was; "This should be with Java 8 Stream API".
>
> So, I think we should simply mothball (drop from settings.gradle) the
> eventsourcing libraries and resurrect it somewhere in 3.x when we have Java
> 8 available.
>
> If anyone is depending on this library (I assume that StreamFlow uses its
> own implementation, and still depend on Qi4j 1.4.x), then raise an
> objection (together with some docs ;-) )
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>
--
Arvid Huss
Senior Java Developer
+46 70 146 92 63
http://www.jayway.com