Versioning

This sample shows how to handle message schema evolution in a backward-compatible manner. The project consists of a publishing endpoint that has evolved from one version of the schema to the next. The newer subscriber has access to the additional information in the newest version of the scheam while the older keeps operating without interruptions.

In this sample there are two message projects: V1.Messages and V2.Messages:

namespace V1.Messages
{
    public interface ISomethingHappened :
        IEvent
    {
        int SomeData { get; set; }
    }
}

The Version 2 message schema inherits from the Version 1 schema as shown below, adding another property on top of the properties in the Version 1 schema.

namespace V2.Messages
{
    public interface ISomethingHappened :
        V1.Messages.ISomethingHappened
    {
        string MoreInfo { get; set; }
    }
}

There are two subscribers, one subscribed to the version 1 message schema, V1Subscriber; and the other subscribed to the Version 2 message schema, V2Subscriber.

var routing = transport.Routing();
routing.RegisterPublisher(
    assembly: typeof(V1.Messages.ISomethingHappened).Assembly,
    publisherEndpoint: "Samples.Versioning.V2Publisher");

While V2Subscriber has:

var routing = transport.Routing();
routing.RegisterPublisher(
    assembly: typeof(V2.Messages.ISomethingHappened).Assembly,
    publisherEndpoint: "Samples.Versioning.V2Publisher");

The only difference is that each subscriber declares the version of the schema on which it dependents.

V2Publisher is publishing a message from the Version 2 schema only. However, when the project is run, V1Subscriber receives these messages as well:

Publisher output

Press 'Enter' to publish a message, Ctrl + C to exit.
Published event.

V1Subscriber output

Press any key to stop program
Something happened with some data 1 and no more info

V2Subscriber output

Press any key to stop program
Something happened with some data 1 and more information It's a secret.