anchor.diff:  [source,java]
   ----
   public interface Binder<T, C extends ConsumerProperties, P extends ProducerProperties> {
  -    Binding<T> bindConsumer(String name, String group, T inboundBindTarget, C consumerProperties);
  -
  -    Binding<T> bindProducer(String name, T outboundBindTarget, P producerProperties);
  +    Binding<T> bindConsumer(String bindingName, String group, T inboundBindTarget, C consumerProperties);
  +
  +    Binding<T> bindProducer(String bindingName, T outboundBindTarget, P producerProperties);
   }
   ----
   
  
positive.code: Spring Cloud Stream also includes a test binder for integration testing of your applications as spring-cloud-stream application. See <<Testing>> section for more details.
  
  Spring Cloud Stream uses Spring Boot for configuration, and the Binder abstraction makes it possible for a Spring Cloud Stream application to be flexible in how it connects to middleware.
  For example, deployers can dynamically choose, at runtime, the destinations (such as the Kafka topics or RabbitMQ exchanges) to which channels connect.
  Such configuration can be provided through external configuration properties and in any form supported by Spring Boot (including application arguments, environment variables, and `application.yml` or `application.properties` files).
  In the sink example from the <<spring-cloud-stream-overview-introducing>> section, setting the `spring.cloud.stream.bindings.input.destination` application property to `raw-sensor-data` causes it to read from the `raw-sensor-data` Kafka topic or from a queue bound to the `raw-sensor-data` RabbitMQ exchange.
  
  Spring Cloud Stream automatically detects and uses a binder found on the classpath.
  You can use different types of middleware with the same code.
  To do so, include a different binder at build time.
  For more complex use cases, you can also package multiple binders with your application and have it choose the binder( and even whether to use different binders for different channels) at runtime.
  
  [[spring-cloud-stream-overview-persistent-publish-subscribe-support]]
  === Persistent Publish-Subscribe Support
  
negative.code: .Producers and Consumers
  image::{github-raw}/docs/src/main/asciidoc/images/producers-consumers.png[width=800,scaledwidth="75%",align="center"]
  
  A producer is any component that sends messages to a binding destination.
  The binding destination can be bound to an external message broker with a `Binder` implementation for that broker.
  When invoking the `bindProducer()` method, the first parameter is the name of the destination within the broker, the second parameter is the instance if local destination to which the producer sends messages, and the third parameter contains properties (such as a partition key expression) to be used within the adapter that is created for that binding destination.
  
  A consumer is any component that receives messages from the binding destination.
  As with a producer, the consumer's channel can be bound to an external message broker.
  When invoking the `bindConsumer()` method, the first parameter is the destination name, and a second parameter provides the name of a logical group of consumers.
  Each group that is represented by consumer bindings for a given destination receives a copy of each message that a producer sends to that destination (that is, it follows normal publish-subscribe semantics).
  