Axon has two technical solution to getting the events from the EventBus/EventStore over to the event handlers you’d write yourself.
These are the SubscribingEventProcessor and the TrackingEventProcessor.
The first receives events as they are published, by subscribing to a source of those messages.
This event handling happens in the same thread as the thread which has originally published the event.
Thus, the SubscribingEventProcessor requires a SubscribableMessageSource, as it needs to subscribe itself to get events.
As you’ve noticed, the EventBus is an implementation of a SubscribableMessageSource, and hence is provided to SubscribingEventProcessors
The TrackingEventProcessor keeps it’s own record of the events it has handled, by storing that knowledge in a token.
As it is doing this on it’s own accord, it is thus a separate thread from the original event publishing thread.
Additionally, it thus requires to be able to retrieve those events itself.
As we typically refer the retrieval of these events as a ‘Stream of Events’, it thus requires a StreamableMessageSource.
The EventStore is an implementation of both the EventBus and the StreamableMessageSource, and due to this it can be used as the source for a TrackingEventProcessor.
The default EventProcessor in Axon 4 and up is the TrackingEventProcessor, as users typically want their event handling to be dealt separately from the event publishing.
Axon 3 however defaults to the SubscribingEventProcessor, as it does involve less moving parts to think about when you’re starting off your Axon based application.
A very short rule of thumb when to use what, could be something along the lines off:
- Are you updating a query model you need to replay in the future? Use a TrackingEventProcessor. Is the event handler a fire-and-forget like operation? Use a SubscribingEventProcessor.
Hope this sheds some light on your options Azeem.