anchor.diff:  == Module Labels
   
   When a stream is comprised of multiple modules with the same name, they must be qualified with labels:
  -
  -  stream create --definition "http | firstLabel: transform --expression=payload.toUpperCase() | secondLabel: transform --expression=payload+'!' | log" --name myStreamWithLabels --deploy
  -
  +```
  +stream create --definition "http | firstLabel: transform --expression=payload.toUpperCase() | secondLabel: transform --expression=payload+'!' | log" --name myStreamWithLabels --deploy
  +```
  +[[tap-dsl]]
  +== Tap DSL
  +
  +Taps can be created at various producer endpoints in a stream. For a stream like this:
  +
  +```
  +stream create --definition "http | step1: transform --expression=payload.toUpperCase() | step2: transform --expression=payload+'!' | log" --name mainstream --deploy
  +
  +```
  +taps can be created at the output of `http`, `step1` and `step2`.
  +
  +To create a stream that acts as a 'tap' on another stream requires to specify the `source destination name` for the tap stream. The syntax for source destination name is:
  +
  +```
  +`<stream-name>.<label/app-name>`
  +```
  +To create a tap at the output of `http` in the stream above, the source destination name is `mainstream.http`
  +To create a tap at the output of the first transform app in the stream above, the source destination name is `mainstream.step1`
  +
  +The tap stream DSL looks like this:
  +
  +```
  +stream create --definition ":mainstream.http > counter" --name tap_at_http --deploy
  +
  +stream create --definition ":mainstream.step1 > jdbc" --name tap_at_step1_transformer --deploy
  +```
  +
  +Note the colon (:) prefix before the destination names. The colon lets the parser parse this as the destination name instead of app name.
  +
  +[[explicit-destination-names]]
  +== Connecting to explicit destination names at the broker
  +
  +One can connect to a specific destination name located in the broker (Rabbit, Kafka etc.,) either at the `source` or at the `sink` position.
  +
  +The following stream has the destination name at the `source` position:
  +
  +```
  +stream create --definition ":myDestination > log" --name ingest_from_broker --deploy
  +```
  +
  +This stream receives messages from the destination `myDestination` located at the broker and connects it to the `log` app.
  +
  +
  +The following stream has the destination name at the `sink` position:
  +
  +```
  +stream create --definition "http > :myDestination" --name ingest_to_broker --deploy
  +```
  +This stream sends the messages from `http` app to the destination `myDestination` located at the broker.
  +
  +From the above streams, notice that the `http` and `log` apps are interacting with each other via `broker` (through the destination `myDestination`) rather than having a pipe directly between `http` and `log` within a single stream.
  +
  +It is also possible to connect two different destinations (`source` and `sink` positions) at the broker in a stream.
  +
  +```
  +stream create --definition ":destination1 > :destination2" --name bridge_destinations --deploy
  +```
  +
  +In the above stream, both the destinations (`destination1` and `destination2`) are located in the broker. The messages flow from the source destination to the sink destination via a `bridge` app that connects them.
  
positive.code: 
  To create a stream using an `http` source, but still using the same `log` sink, we would change the original command above to
  
      dataflow:> stream create --definition "http | log" --name myhttpstream --deploy
  
  which will produce the following output from the server
  
  ....
  2016-01-13 18:42:19.162  INFO 19463 --- [nio-9393-exec-7] o.s.c.d.a.s.l.OutOfProcessModuleDeployer : deploying module org.springframework.cloud.stream.module:log-sink:jar:exec:1.0.0.BUILD-SNAPSHOT instance 0
     Logs will be in /var/folders/hs/h87zy7z17qs6mcnl4hj8_dp00000gp/T/spring-cloud-data-flow-2185888994718649403/myhttpstream.log
  2016-01-13 18:42:19.180  INFO 19463 --- [nio-9393-exec-7] o.s.c.d.a.s.l.OutOfProcessModuleDeployer : deploying module org.springframework.cloud.stream.module:http-source:jar:exec:1.0.0.BUILD-SNAPSHOT instance 0
     Logs will be in /var/folders/hs/h87zy7z17qs6mcnl4hj8_dp00000gp/T/spring-cloud-data-flow-2185888994718649403/myhttpstream.http
  ....
  
  Note that we don't see anydefin other output this time until we actually post some data (using shell command). In order to see the randomly assigned port on which the http source is listening, execute:
  
  	dataflow:> runtime modules
  
  You should see that the corresponding http source has a `url` property containing the host and port information on which it is listening. You are now ready to post to that url, e.g.:
  
    dataflow:> http post --target http://localhost:1234 --data "hello"
    dataflow:> http post --target http://localhost:1234 --data "goodbye"
  
  and the stream will then funnel the data from the http source to the output log implemented by the log sink
  
    2016-01-13 21:15:34.825  INFO 54348 --- [hannel-adapter1] log.sink                                 : hello
    2016-01-13 21:17:36.544  INFO 54348 --- [hannel-adapter1] log.sink                                 : goodbye
  
  Of course, we could also change the sink implementation. You could pipe the output to a file (`file`), to hadoop (`hdfs`) or to any of the other sink modules which are provided. You can also define your own modules.
  
  == Simple Stream Processing
  
  As an example of a simple processing step, we can transform the payload of the HTTP posted data to upper case using the stream definitions
  
      http | transform --expression=payload.toUpperCase() | log
  
  To create this stream enter the following command in the shell
  
      dataflow:> stream create --definition "http | transform --expression=payload.toUpperCase() | log" --name mystream --deploy
  
  Posting some data (using shell command)
  
    dataflow:> http post --target http://localhost:1234 --data "hello"
  
  Will result in an uppercased 'hello' in the log
  
    15:18:21,345  WARN ThreadPoolTaskScheduler-1 logger.myprocstream:141 - HELLO
  
  See the xref:processors#spring-cloud-stream-modules-processors[Processors] section for more information.
  
  == DSL Syntax
  
  In the examples above, we connected a source to a sink using the pipe symbol `|`. You can also pass parameters to the source and sink configurations. The parameter names will depend on the individual module implementations, but as an example, the `http` source module exposes a `server.port` setting which allows you to change the data ingestion port from the default value. To create the stream using port 8000, we would use
  
      dataflow:> stream create --definition "http --server.port=8000 | log" --name myhttpstream
  
  The shell provides tab completion for module parameters and also the shell command `module info` provides some additional documentation.  For more comprehensive documentation on module parameters, please see the xref:modules#modules[Modules] chapter.
  
  == Advanced Features
  
negative.code: 
  A high level DSL is used to create stream definitions. The DSL to define a stream that has an http source and a file sink (with no processors) is shown below
  
  ```
  http | file
  ```
  The DSL mimics a UNIX pipes and filters syntax. Default values for ports and filenames are used in this example but can be overridden using `--` options, such as
  
  ```
  http --port=8091 | file --dir=/tmp/httpdata/
  ```
  To create these stream definitions you make an HTTP POST request to the Spring Cloud Data Flow Server. More details can be found in the sections below.
  
  == Creating a Simple Stream
  