Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify serializer usage #261

Closed
wants to merge 1 commit into from
Closed

Clarify serializer usage #261

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 5 additions & 4 deletions axon-framework/serialization.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,21 +20,22 @@ You may also implement your own serializer simply by creating a class that imple
## Serializer Implementations

`Serializers` come in several flavors in Axon Framework and are used for various things.
Currently, you can choose between the `XStreamSerializer` and `JacksonSerializer` to serialize messages \(commands/queries/events\), tokens, snapshots and sagas in an Axon application.
Currently, you can choose between the `XStreamSerializer` and `JacksonSerializer` to serialize messages \(commands/queries/events\), tokens, snapshots, deadlines and sagas in an Axon application.

As there are several objects to be serialized, it is typically desired to chose which serializer handles which object.
To that end, the `Configuration` API allows you to define default, `message` and `event` serializers, which lead to the following object-serialization break down:

1. The Event `Serializer` is in charge of de-/serializing event messages.
1. The Event `Serializer` is in charge of (de)serializing event message payload and metadata.
Events are typically stored in an event store for a long period of time.
This is the main driver for choosing the event serializer implementation.

2. The Message `Serializer` is in charge of de-/serializing the command and query messages \(used in a distributed application setup\).
2. The Message `Serializer` is in charge of (de)serializing the command and query message payload and metadata \(used in a distributed application setup\).
Messages are shared between nodes and typically need to be interoperable and/or compact.
Take this into account when choosing the message serializer implementation.

3. The default `Serializer` is in charge of de-/serializing the remainder, being the tokens, snapshots and sagas.
3. The default `Serializer` is in charge of (de)serializing the remainder, being the messages (except the payload and metadata), tokens, snapshots, deadlines and sagas.
These objects are generally not shared between different applications, and most of these classes aren't expected to have some of the getters and setters that are, for example, typically required by Jackson based serializers.
For example a QueryMessage consists of a ResponseType, which will be (de)serialized using the `default`serializer, the query request and response payload will be (de)serialized using the`message`serializer.
A flexible, general-purpose serializer like [XStream](http://x-stream.github.io/) is quite ideal for this purpose.

By default, all three `Serializer` flavors are set to use the `XStreamSerializer`, which internally uses [XStream](http://x-stream.github.io/) to serialize objects to an XML format.
Expand Down