Easynetq Use (vi) "polymorphic Publishing and subscriptions, message versioning"

You can subscribe to an interface and then publish implementations based on this interface.

Let's look at the next example. I have an interface IAnimal and two implementations of cat and dog:

Public interface IAnimal
{
    string Name {get; set;}
}

public class Cat:ianimal
{public
    string Name {get; set;}
    public string Meow {get; set;}
}

public class Dog:ianimal
{public
    string Name {get; set;}
    public string Bark {get; set;}
}

I am able to subscribe to the IAnimal interface and receive cat and dog this two classes:

Bus. Subscribe<ianimal> ("Polymorphic_test",
    @interface =>
    {
        var cat = @interface as cat;
        var dog = @interface as dog;

        if (cat!= null)
        {
            Console.WriteLine ("Name = {0}", Cat. Name);
            Console.WriteLine ("Meow = {0}", Cat. meow);
        }
        else if (dog!= null)
        {
            Console.WriteLine ("Name = {0}", dog. Name);
            Console.WriteLine ("Bark = {0}", dog.) Bark);
        }
        else
        {
            Console.WriteLine ("Message is not a
                dog or a cat");
        }
);

Let's post cat and dog:

var cat = new Cat
{
    Name = "Gobbolino",
    meow = "Purr"
};

var dog = new Dog
{
    Name = "Rover",
    Bark = "Woof"
};

Bus. Publish<ianimal> (cat);
Bus. Publish<ianimal> (dog);

Note: The IAnimal interface must be displayed for the specified publication. EASYNETQ specifies generics to publish and subscribe in the Publish and subscribe methods.

To be able to support message versioning, you need to make sure that the necessary components are configured. The simplest implementation is this:

var bus = Rabbithutch.createbus ("Host=localhost", 
    services => services. Enablemessageversioning ());

Once the message version function starts, you must display the selection you want to version the message to add version control.

This message is not versioned, and when this message is released, it is processed with the same release as other messages. Public
class Mymessage
{public
    string Text {get; set;}
}

This message is versioned. There are two kinds of messages for subscribers, MYMESSAGEV2 and Mymessage public
class Mymessagev2:mymessage, isupersede<mymessage>
{
    public int number {get; set;}
}

how it works.

When you post a message, EASYNETQ typically creates a switch for this message type and then publishes the message to the switch. Subscribers create queues that bind to the switch, so they can receive any messages posted to the switch.

When a versioned message is enabled, EASYNETQ creates a switch for each of the versioned message types of the inheritance structure, and then binds the switches together. When you post a MYMESSAGEV2 message, the message is sent to the MYMESSAGEV2 switch and automatically forwarded up to the mymessage switch.

When the message is serialized, EASYNETQ stores the message type name into the type attribute of the message. This metadata is sent along with the message to any subscriber, and the Subscriber can then deserialize the message with this metadata.

When a versioning message is enabled, EASYNETQ also stores all the superseded message types into this message header property. Subscribers will use this property to find the first available message type to serialize, even if the endpoint does not have the latest version of the message, as long as there is a version, it can be deserialized and processed. The Message Versioning guide is not a new version of the message if it cannot be implemented by extending the original message type. It is a new message type. If you are unsure, rather than create a new message type, instead of versioning an existing Shaw. versioned messages should not be used in Request/response as message types, and request and response are different, even if V2 extensions are different from V1. versioned messages should not be used for send/receive because this is a targeted send, because there is a dependency between the sender and the recipient. Conversely versioning of message support has been developed and tested in the publish-subscribe scenario. It has not been tested in send-receive or request-response scenarios. In other modes outside of the publish-subscribe, the risk is at your peril. Versioning message support this time has not yet been extended to the next publish scenario. Additional work has been planned, but due to potential disruptions, the project owner and the community need some necessary discussion.