Personally I really don't like having a data contract extendable. A contract is a contract, so the data must conform.
From our way of thinking, we want to be tightly coupled to the data contract, but having expendable end points for older data contract versions.
Message in Json format
i. Date Created
ii. Source ID
iii. Data Object Type Name
iv. Data Object Type Version
v. Package data
a. Any Json data but schema valid the the type version
1) "A" creates data object which is serialised to a json message (wrapper and data).
2) Json messge is added to a queue.
3) B Serialiser dequeues messages that it has an understanding about the type and version number.
4) B Rehydrates and schema verifies data object from message package data.
Available - you can run B version 7 next to B version 6 until there are no more messages for version 6 in the queue.
Scalability - as you can spin up new B's in different versions to process messages.
Performance - as B only tries to dequeue, deserialse and validate packages that are for them.
Timeliness – You can check many queues and even specialize queues for data types if you want.
Data – basic json strings.
Other advantages are:
Monitoring – you can peek at the queue to see the progress of an upgrade.
Deployment – you can monitor the queue to see which A's which have not been upgraded.