Lokad Message Format is compact cross-platform way of serializing message envelopes.

Introduction

Lokad Message Format was introduced to Lokad in July 2010 as a way to:
  • Transfer and persist messages efficiently between Lokad.CQRS and Lokad.Cloud applications.
  • Persist message streams and explore them efficiently.
  • Provide logical compatibility with Azure Queues, AMQP, MSMQ and other messaging transports.
  • Provide extensibility.

You don't need to bother about the details. LMF is used internally by Lokad frameworks.

However, if you need to pursue some advanced scenario, integrate with some custom message bus, transport or persistence, it is out there for you.

2010-07-04_LMF.jpg

Sample

This is what information message might contain (if represented in human-readable form):

Message Header
{
  MessageFormatVerstion : 2010020701 (data message)
  AttributesLength : XXX
  ContentLength : XXX
}

Message Attributes
{
  Topic          : PingPongCommand
  ContractName   : PingPongCommand
  Sender         : http://127.0.0.1:10001/devstoreaccount1/sample-01
  Identity       : 0d2e1149-30aa-46cb-a428-9dbd00551693
  CreatedUtc     : 07/24/2010 05:09:47
}

Content
{
  "Ball": 30,
  "Game": "erat"
}


This is how it will look in binary format, if the content is serialized with ProtoBuf as well:

2010-07-24_LMF_Binary.png

Details

Lokad Message Format defines:
  • Binary (byte-level) format of message envelopes for storage and transfer.
  • Set of predefined message attributes as well as extensibility for adding custom ones to the message body.
  • Recommendation to use ProtoBuf for encoding message content.

Message contains:
  • Header
  • Attributes
  • Content

Message Header

Message Header is a fixed-length (28 bytes) binary structure serialized with ProtoBuf. It contains following required fields:

int MessageFormatVersion;
long AttributesLength;
long ContentLength;
int Checksum;

Where Message Format Version currently could be either of:
  • `2010020701` - defines data message.
  • `2010020702` - defines data reference to a message stored somewhere else (i.e.: large Azure Queue message). Content Length should be zero.

Message Attributes

Second part of the Message is variable-length `MessageAttributes` structure, which contains the array of `MessageAttribute` records. Messaging and service bus infrastructures use these fields to pass important system information around.

Full size of this structure should be defined in the Header, as in data message and data reference specifications.

Order Name .NET Type Required
1 Type MessageAttributeType enum Yes
2 Custom Attribute Name string
3 Binary Value byte []
4 String Value string
5 Numeric Value int64


MessageAttributeType is an enumeration (unsigned int) with following predefined values:

Undefined = 0,
ContractName = 1,
ContractDefinition = 2,
BinaryBody = 3,
CustomString = 4,
CustomBinary = 5,
CustomNumber = 6,
Topic = 7,
Sender = 8,
Identity = 9,
CreatedUtc =10,
StorageReference = 11,
StorageContainer = 12,
ErrorText = 13

This structure allows to save size, while sending predefined attribute over the wire. Yet, one can easily add custom attributes, by providing their name, type (custom string, binary or number) and actual value.

Message Content

Message content represents actual contents of the message, serialized in whatever format accepted by the project. Yet, we recommend to use ProtoBuf.NET serialization, which is included in Lokad.CQRS project by default. Latter would allow you to reuse some really nice features (dynamic content-based routing) that might show up in Lokad.CQRS some time later.

Last edited Apr 11, 2011 at 11:07 PM by AlexandrYZ, version 4

Comments

No comments yet.