anchor.diff:  ==== Schema Resolution Process (Deserialization)
   
   When reading messages that contain version information (i.e. a `contentType` header with a scheme like above), the converter will query the Schema server to fetch the *writer* schema of the message.
  -Once it has found the correct schema of the incoming message, it then retrieves the reader schema and using Avro's schema resolution support reads it into the reader definition (setting defaults and missing properties).
  +Ones it has found the correct schema of the incoming message, it then retrieves the reader schema and using Avro's schema resolution support reads it into the reader definition (setting defaults and missing properties).
   
   .Schema Reading Resolution Process
   image::schema_reading.png[width=300,scaledwidth="75%",align="center"]
  
positive.code: In the example above, we are creating an application that has an input and an output channel, bound through the `Processor` interface.
  The bound interface is injected into the test so we can have access to both channels.
  We are sending a message on the input channel and we are using the `MessageCollector` provided by Spring Cloud Stream's test support to capture the message has been sent to the output channel as a result.
  Once we have received the message, we can validate that the component functions correctly.
  
  === Disabling the test binder autoconfiguration
  
  
negative.code: .Schema Writer Resolution Process
  image::schema_resolution.png[width=300,scaledwidth="75%",align="center"]
  
  Ones a schema is obtained, the converter will then load its metadata (version) from the remote server.
  First it queries a local cache, and if not found it then submits the data to the server that will reply with versioning information.
  The converter will always cache the results to avoid the overhead of querying the Schema Server for every new message that needs to be serialized.
  
  