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.
and V2.
:
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
.
V1Subscriber
has: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.