Nibiru Message Format

Remember that Nibiru has no fixed data model and a single installation could support a Key Value store or even a graph DB store side by side. As a result the message format for server-to-server and client-server needs to flexible as well. Here is an example of the current payload.

public class Message {
  private String keyspace;
  private String store;
  private String personality;
  private Map<String,Object> payload;
}

The main intent is that the payload is opaque as possible because based on the store the payload will be different. The fields keyspace, store, and personality have been pulled out from the payload because the server needs to be able to pull out these fields for routing before it knows what the "personality" of the message is.

Currently we are using Jackson to serialize the content between systems. This makes challenges with the opaqueness of the message body as some fields get converted into Map when they are really nested objects.