Return to Question

I've written a quick and dirty demo application to show you what I've planned to do. The application "supports" two protocol version (V1 and V2). There are two messages defined MyMessage and MyOtherMessage. MyMessage has changed in V2, MyOtherVersion is in V2 still the same as in V1.

I've written a demo application to show you what I've planned to do. The application "supports" two protocol version (V1 and V2). There are two messages defined MyMessage and MyOtherMessage. MyMessage has changed in V2, MyOtherVersion is in V2 still the same as in V1.

• The service will receive messages (strings containing multiple fields (No JSON, no xml just a string)) from a client.

• The format of the messages can change between different protocol versions. And the service needs to support multiple different versions.

• The service will need to deserialize/pars those messages into a message class (version specific).

• After the parsing the service needs to convert the message class to a BLL model. The idea behind the BLL model is to unify the different protocol versions. The same message type (version independently) should be converted to the same BLL model (There will be only version of the BLL model).

• The BLL model will then be passed to the BLL.

• For some messages (not all) the service needs to send a response to the client. This means the service also must be able to convert a BLL model to a version specific message and send this message to the client.

I’ve written a quick and dirty demo application to show you what I’ve planned to do. The application "supports" two protocol version (V1 and V2). There are two messages defined MyMessage and MyOtherMessage. MyMessage has changed in V2, MyOtherVersion is in V2 still the same as in V1. The application contains a class simulating a client which sends both messages in both versions ("totally" random). The "received" messages are getting deserialized into message classes by a version specific serializer. After the deserialization the message classes are getting converted to version independent BLL models. The communication between the different components (receiver, serializer, converter, etc...) is done using the event aggregation pattern.

• How would you implement the version specific message classes? (My idea was to create a namespace per version and implement the messages which has changed in this version)
• How would you select the correct serializer and converter for the version of the received message?
• How would you handle the serialization and conversion of messages which hasn’t changed since the last version? (for example MyOtherMessage has not changed in V2, would you call the V1 serializer from the V2 serializer?)... in the example I’ve "changed" the version of the message to V1 and published the event again. So it gets handled by the V1 serializer
• Do you think it’s a good idea to work with the event aggregation pattern?
• Do you have any experience with that kind of problem (different versions)... how have you solved it?
• Do you have any general input?

Here is my demo application:

I’ve uploaded the whole demo solution to my google drive: https://drive.google.com/file/d/0B9KiKPIFWVbwUlJvc1g3ZGZnUms/view?usp=sharing

Messages V1:

Messages V2:

Converter V1:

Converter V2:

Serializer V1:

Serializer V2:

EventAggregator:

• The service will receive messages (strings containing multiple fields (no JSON, no XML just a string)) from a client.

• The format of the messages can change between different protocol versions. And the service needs to support multiple different versions.

• The service will need to deserialize/pars those messages into a message class (version specific).

• After the parsing the service needs to convert the message class to a BLL model. The idea behind the BLL model is to unify the different protocol versions. The same message type (version independently) should be converted to the same BLL model (There will be only version of the BLL model).

• The BLL model will then be passed to the BLL.

• For some messages (not all) the service needs to send a response to the client. This means the service also must be able to convert a BLL model to a version specific message and send this message to the client.

I've written a quick and dirty demo application to show you what I've planned to do. The application "supports" two protocol version (V1 and V2). There are two messages defined MyMessage and MyOtherMessage. MyMessage has changed in V2, MyOtherVersion is in V2 still the same as in V1.

The application contains a class simulating a client which sends both messages in both versions ("totally" random). The "received" messages are getting deserialized into message classes by a version specific serializer. After the deserialization the message classes are getting converted to version independent BLL models.

The communication between the different components (receiver, serializer, converter, etc...) is done using the event aggregation pattern.

• How would you implement the version specific message classes? (My idea was to create a namespace per version and implement the messages which has changed in this version)
• How would you select the correct serializer and converter for the version of the received message?
• How would you handle the serialization and conversion of messages which hasn't changed since the last version? (for example MyOtherMessage has not changed in V2, would you call the V1 serializer from the V2 serializer?) in the example I've "changed" the version of the message to V1 and published the event again, so it gets handled by the V1 serializer.
• Do you think it's a good idea to work with the event aggregation pattern?
• Do you have any experience with that kind of problem (different versions)... how have you solved it?

I've uploaded the whole demo solution to Google Drive.

Messages V1:

Messages V2:

Converter V1:

Converter V2:

Serializer V1:

Serializer V2:

EventAggregator:

I’ve uploaded the whole demo solution (source only no binaries) to my google drive: https://drive.google.com/file/d/0B9KiKPIFWVbwUlJvc1g3ZGZnUms/view?usp=sharing

I’ve uploaded the whole demo solution to my google drive: https://drive.google.com/file/d/0B9KiKPIFWVbwUlJvc1g3ZGZnUms/view?usp=sharing