anchor.diff:      $ cf create-user-provided-service mylogger -r https://logger.cf.example.com
       </pre>
   
  -1. Push a sample app like [Spring Music](https://github.com/cloudfoundry-samples/spring-music). By default this will create a route `spring-music.cf.example.com`.
  +1. Push a sample app like [Spring Music](https://github.com/cloudfoundry-samples/spring-music). By default this creates a route `spring-music.cf.example.com`.
   
       <pre class="terminal">
       $ cf push spring-music
  
positive.code: **Disadvantages:**
  
  - Adding route services requires manual infrastructure configuration.
  - Unnecessary network hops for traffic to apps that do not use the route service; requests for all apps hosted by the deployment pass through the route service component.
  
  ### <a id="user-provided"></a>User-Provided Service ###
  
  If a route service is not listed in the CF marketplace by a broker, a developer can still bind it to their app as a User-Provided service. The service can run anywhere, either inside or outside of CF, but it must fulfill the integration requirements described in [Service Instance Responsibilities](#service-instance-responsibilities). The service also needs to be reachable by an outbound connection from the CF router.
  
  ![User-provided](images/route-services-user-provided.png)
  
  This model is identical to the [fully-brokered service](#fully-brokered) model, except without the broker. Developers configure the service manually, outside of Cloud Foundry. They can then create a user-provided service instance and bind it to their application with the following commands, supplying the URL of their route service:
  
  `cf create-user-provided-service SERVICE_INSTANCE -r ROUTE_SERVICE_URL`
  `cf bind-route-service DOMAIN SERVICE_INSTANCE [--hostname HOSTNAME]`
  
  **Advantages:**
  
  - Adding route services requires no manual infrastructure configuration.
  - Traffic to apps that do not use the service makes fewer network hops; requests for those apps do not pass through the route service.
  
  **Disadvantages:**
  
  - Developers must manually provision/configure route services out of the context of Cloud Foundry; no service broker automates these operations.
  - Traffic to apps that use the route service makes additional network hops, as compared to the static model.
  
  ### <a id="architecture-comparison"></a>Architecture Comparison ###
  
  The models above require the [broker](#broker-responsibilities) and [service instance](#service-instance-responsibilities) responsibilities below, as summarized in the following table:
  
  <table id='architecture-comparison' border="1" class="nice" >
    <tr>
  
negative.code: 
  <strong><%= modified_date %></strong>
  
  This documentation is intended for service authors who are interested in 
  offering a service to a Cloud Foundry (CF) services marketplace. Developers 
  interested in consuming these services can read the [Manage Application Requests with Route Services](../devguide/services/route-binding.html) topic.
  
  <%= vars.route_services %>
  
  ## <a id='introduction'></a>Introduction ##
  
  Cloud Foundry application developers may wish to apply transformation or 
  processing to requests before they reach an application. Common examples of use 
  cases include authentication, rate limiting, and caching services. Route 
  Services are a kind of Marketplace Service that developers can use to apply 
  various transformations to application requests by binding an application's 
  route to a service instance. Through integrations with service brokers and,  
  optionally, with the Cloud Foundry routing tier, providers can offer these 
  services to developers with a familiar, automated, self-service, and on-demand 
  user experience.
  
  <%= vars.route_services_appsman1 %>
  
  ## <a id='architecture'></a>Architecture ##
  
  Cloud Foundry supports the following three models for Route Services: 
  
  * [Fully-brokered services](#fully-brokered)
  * [Static, brokered services](#static-brokered)
  * [User-provided services](#user-provided)
  
  In each model, you configure a route service to process traffic addressed to an 
  app.
  
  ### <a id="fully-brokered"></a>Fully-Brokered Service ###
  
  In the fully-Brokered Service model, the CF router receives all traffic to apps 
  in the deployment before any processing by the route service. Developers can 
  bind a route service to any app, and if an app is bound to a route service, the 
  CF router sends its traffic to the service. After the route service processes 
  requests, it sends them back to the load balancer in front of the CF router. 
  The second time through, the CF router recognizes that the route service has 
  already handled them, and forwards them directly to app instances.
  
  ![Fully brokered](images/route-services-fully-brokered.png)
  
  The route service can run inside or outside of CF, so long as it fulfills the 
  [Service Instance Responsibilities](#service-instance-responsibilities) to 
  integrate it with the CF router. A service broker publishes the route service 
  to the CF marketplace, making it available to developers. Developers can then 
  create an instance of the service and bind it to their apps with the following 
  commands:
  
  `cf create-service BROKER-SERVICE-PLAN SERVICE-INSTANCE`
  `cf bind-route-service YOUR-APP-DOMAIN SERVICE-INSTANCE [--hostname HOSTNAME]`
  
  Developers configure the service either through the service provider's web 
  interface or by passing [arbitrary parameters](../devguide/services/managing-services.html#arbitrary-params-create)
   to their `cf create-service` call through the `-c` flag.
  
  **Advantages:**
  
  - Developers can use a Service Broker to dynamically configure how the route service processes traffic to specific applications.
  - Adding route services requires no manual infrastructure configuration.
  - Traffic to apps that do not use the service makes fewer network hops because requests for those apps do not pass through the route service.
  
  **Disadvantages:**
  
  