Publish Subscriber 3.0 - Migrating an old project

Feb 15, 2013 at 12:12 PM
Hello Keith,

We have an old project that depends alot on publishers/subscribers and it always had problems with it. For some reason the project has problems with publishings getting lost etc Since the publishing/subscribing is a crital part of this project we're discussing migrating it to your event system.

The biggest problem I see is that we have over 100 data contracts classes that we serialize, some through remoting others are published. This means alot of diferen events.

From what I've read for the new version 3.0, you say we can use our own serializor. So lets say I have this class bellow
   [DataContract]
    public class CommuteMessage
    {
        [DataMember]
        public int SourceID { get; set; }

        [DataMember]
        public string SourceName { get; set; }

        [DataMember]
        public int SinkID { get; set; }

        [DataMember]
        public int? ChannelID { get; set; }

        [DataMember]
        public int MacroID { get; set; }

        [DataMember]
        public DateTime DateTime { get; set; }

        [DataMember]
        public int UserID { get; set; }

        [DataMember]
        public bool IsFromSituation { get; set; }

        [DataMember]
        public bool IsFromMacro { get; set; }
    }
In the new version, if we wanted to send this class as an event we should do one of the following:
  1. Make this classe derive from the class Events and implement the GetObjectData and SetElement and then we could use the built-in serialize or ours;
  2. Creat a new class as follows:
public class SendCommuteMessage : Event
{
        public CommuteMessage Message { get; set; }
        
        public override void GetObjectData(WspBuffer buffer)
        {
           ...
         } 

        public override bool SetElement(string elementName, object elementValue)
        {
            ...
        }
}
The second solution seems to be what would work best, because we have alot of classes that have more complex types than int, bool etc. By complex types I mean classes that reference other classes, have generic lists of other classes.

Having said all that, what do you recomend in terms of migrating to this event system?
Coordinator
Feb 15, 2013 at 2:31 PM
The format for the events in 3.0 are similar to the format of http. You have standard headers, user-defined headers, and the body. This is the structure of WspEvent. The body is a serialized version of your .Net object and you can use any technology you want to serialize/deserialize the body.

Since you say you have many types of objects, you could consider doing it one of two ways. You could publish each type of object as its own event type. An event type is a guid. On the subscription side, you know what type of object you're receiving by the guid you're subscribing to. Or at publishing time, you could put the fully qualified object type in a header. The subscriber would get the object type from the header and then invoke the corresponding deserializer. You could use reflection to invoke the Deserialize method on an object type dynamically which could simplify things but you incur the overhead of reflection.

Have you looked at using Protobuf-Net for serialization? (http://code.google.com/p/protobuf-net/)

After you decide on serialization, the publishing and subscribing is really trivial.